(57)【特許請求の範囲】
【請求項１】
ＩＥＥＥ１３９４シリアルバスを用いて複数の機器が接続されたネットワークを監視する通信監視装置であって、
前記ネットワークにおける他の機器が決定または管理する通信制御値に関する情報を取得する取得手段と、
前記ネットワークに適合した前記通信制御値を算出する算出手段と、
前記算出手段によって算出された通信制御値と、前記取得手段によって取得された通信制御値に関する情報とを比較して、前記通信制御値に関する情報が前記ネットワークに適合しているか否かを判断する判断手段と、
前記判断手段による判断結果を通知する通知手段と、
を備えることを特徴とする通信監視装置。
【請求項２】
前記取得手段は、前記通信制御値に関する情報として前記ネットワークにおけるＧａｐ＿Ｃｏｕｎｔ値を取得することを特徴とする請求項１に記載の通信監視装置。
【請求項３】
前記算出手段は、前記ネットワークに接続された各機器にＰｉｎｇパケットを送信し、送信した前記Ｐｉｎｇパケットへの返答として前記各機器から送信されるＳｅｌｆ＿ＩＤパケットを受信するまでの時間に基づいて、前記通信制御値を算出することを特徴とする請求項２に記載の通信監視装置。
【請求項４】
ＩＥＥＥ１３９４シリアルバスを用いて複数の機器が接続されたネットワークを監視する通信監視装置であって、
前記ネットワークにおける他の機器が決定または管理する通信制御値に関する情報を取得する取得手段と、
前記取得手段によって取得された通信制御値に関する情報に基づいて、前記通信制御値に関する情報が前記ネットワークに適合しているか否かを判断する判断手段と、
前記判断手段による判断結果を通知する通知手段と、を備え、
前記取得手段は、前記通信制御値に関する情報として前記ネットワークにおけるＧａｐ＿Ｃｏｕｎｔ値を決定する機器に関する情報を取得することを特徴とする通信監視装置。
【請求項５】
前記取得手段は、前記Ｇａｐ＿Ｃｏｕｎｔ値を決定する機器に関する情報として、前記ネットワークに接続された機器を識別する機器識別情報を取得することを特徴とする請求項４に記載の通信監視装置。
【請求項６】
前記ネットワークは、ＩＥＥＥ１３９４ｂに対応した機器およびＩＥＥＥ１３９４ｂに対応していない機器がそれぞれ少なくとも１つずつ接続され、
前記判断手段は、前記ＩＥＥＥ１３９４ｂに対応していない機器が前記通信制御値を決定する機器になった場合に、前記通信制御値に関する情報が前記ネットワークに適合しないと判断することを特徴とする請求項１または４に記載の通信監視装置。
【請求項８】
前記判断手段によって前記通信制御値に関する情報が前記ネットワークに適合しないと判断された場合に、その原因となる機器を特定する機器特定手段を備え、
前記通知手段は、前記機器特定手段によって特定された機器に関する情報を通知することを特徴とする請求項１または４に記載の通信監視装置。
【請求項９】
前記判断手段によって前記通信制御値に関する情報が前記ネットワークに適合しないと判断された場合に、その原因となる機器を特定する機器特定手段と、
前記機器特定手段によって特定された機器と前記ネットワークとの接続を切断する切断手段と、
を備えることを特徴とする請求項１または４に記載の通信監視装置。
【請求項１０】
ＩＥＥＥ１３９４シリアルバスを用いて複数の機器が接続されたネットワークを監視する通信監視方法であって、
前記ネットワークにおける他の機器が決定または管理する通信制御値に関する情報を取得する取得工程と、
前記ネットワークに適合した前記通信制御値を算出する算出工程と、
前記算出工程で算出された通信制御値と、前記取得工程で取得された通信制御値に関する情報とを比較して、前記通信制御値に関する情報が前記ネットワークに適合しているか否かを判断する判断工程と、
前記判断工程による判断結果を通知する通知工程と、
を含むことを特徴とする通信監視方法。
【請求項１１】
ＩＥＥＥ１３９４シリアルバスを用いて複数の機器が接続されたネットワークを監視する通信監視方法であって、
前記ネットワークにおける他の機器が決定または管理する通信制御値に関する情報を取得する取得工程と、
前記取得工程で取得された通信制御値に関する情報に基づいて、前記通信制御値に関する情報が前記ネットワークに適合しているか否かを判断する判断工程と、
前記判断工程による判断結果を通知する通知工程と、を含み、
前記取得工程は、前記通信制御値に関する情報として前記ネットワークにおけるＧａｐ＿Ｃｏｕｎｔ値を決定する機器に関する情報を取得することを特徴とする通信監視方法。
【請求項１２】
請求項１０または１１に記載の通信監視方法をコンピュータに実行させることを特徴とする通信監視プログラム。
【請求項１３】
請求項１２に記載の通信監視プログラムを記録したコンピュータに読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ネットワークの通信状態を監視する通信監視装置、通信監視方法、通信監視プログラムおよび記録媒体に関する。ただし、この発明の利用は、上述した通信監視装置、通信監視方法、通信監視プログラムおよび記録媒体に限られない。
【背景技術】
【０００２】
従来、主にマルチメディアデータ転送のためのインターフェースとして、ＩＥＥＥ１３９４規格のシリアルバス（以下、ＩＥＥＥ１３９４バスという）が用いられている。ＩＥＥＥ１３９４バスは、高速データ転送が可能であり、ホストとなる機器を必要とせず、機器の動作中においても接続・切断を自由におこなうことができるなどの特徴を有する。ＩＥＥＥ１３９４規格には、従来から用いられてきたＩＥＥＥ１３９４−１９９５、ＩＥＥＥ１３９４ａ、およびＩＥＥＥ１３９４ａを改良させたＩＥＥＥ１３９４ｂが存在する。
【０００３】
ＩＥＥＥ１３９４規格では、接続されているいずれの機器（ノード）も通信をおこなってはならないアイドル時間（Ｇａｐ）があり、アイドル時間の元となる値をＧａｐ＿Ｃｏｕｎｔという。たとえば、あるノードから同じ１３９４バスに接続されている他のノードにデータを送信した場合、受信側で正しくデータが受理されたかどうかを確認するためにアクノリッジパケット（ＡＣＫ）を送り返す必要がある。データを送信してからＡＣＫが返ってくるまでの間、他のノードは通信の邪魔をしてはならず、ある一定時間待機しなければならない。
【０００４】
このときの待機時間をＡＣＫｎｏｗｌｅｄｇｅ＿Ｇａｐといい、Ｇａｐ＿Ｃｏｕｎｔの値を基準にしてＡＣＫｎｏｗｌｅｄｇｅ＿Ｇａｐを示す時間が決定される。Ｇａｐ＿Ｃｏｕｎｔ値は、バスのトポロジによって異なるものであり、バスのトポロジに変化が生じると、各ノードに対してＧａｐ＿Ｃｏｕｎｔ値の再設定がおこなわれる。Ｇａｐ＿Ｃｏｕｎｔの設定は、バス上でバスマネージャになったノード、また、バス上にバスマネージャが存在しない場合はＩＲＭ（Ｉｓｏｃｈｒｏｎｏｕｓ  Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｒ）によっておこなわれる。以下、このようにＧａｐ＿Ｃｏｕｎｔの設定をおこなうノードをＧａｐ＿Ｃｏｕｎｔ設定ノードという。
【０００５】
Ｇａｐ＿Ｃｏｕｎｔ設定ノードは、Ｇａｐ＿Ｃｏｕｎｔ値を算出し、算出したＧａｐ＿Ｃｏｕｎｔ値を各ノードに設定するパケット（ＰＨＹ  ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｐａｃｋｅｔ）をブロードキャストする。各ノードは、受信したＧａｐ＿Ｃｏｕｎｔ値をＰＨＹレジスタに設定する。そして、各ノードがバスリセット信号を受信することによって、ＰＨＹレジスタに設定したＧａｐ＿Ｃｏｕｎｔ値が有効になる。
【０００６】
Ｇａｐ＿Ｃｏｕｎｔの設定が適切におこなわれていない場合、たとえば、Ｇａｐ＿Ｃｏｕｎｔ値が小さすぎる場合は、ＡＣＫが返る前に他のノードが通信を始めてしまう可能性があるので、バスの動作が不安定になってしまう。一方、Ｇａｐ＿Ｃｏｕｎｔ値が大きすぎる場合は、必要以上に待機することになるので、機器のスループットが下がってしまう。このため、各ノードに設定されたＧａｐ＿Ｃｏｕｎｔが等しい値であるかを確認することによって、Ｇａｐ＿Ｃｏｕｎｔの設定が適切におこなわれたかを判断する技術が考案されている（たとえば、下記特許文献１および２参照。）。
【０００７】
【特許文献１】
特開平１０−２８５２３６号公報
【特許文献２】
特開平１１−３３１２１４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、前述した先行技術によれば、すべてのノードに同じＧａｐ＿Ｃｏｕｎｔ値が設定されているかを確認することはできるものの、設定されたＧａｐ＿Ｃｏｕｎｔ値で、正常なデータ通信をおこなうことができるかは判断することができない。たとえば、ＩＥＥＥ１３９４ｂ準拠のノードからなるネットワークにＩＥＥＥ１３９４−１９９５、ＩＥＥＥ１３９４ａ準拠のいずれかのノードが少なくとも一つ含まれるネットワーク（以下、１３９４混在ネットワークという）において、ＩＥＥＥ１３９４ｂ以外のノードがＧａｐ＿Ｃｏｕｎｔ設定ノードになった場合、ＩＥＥＥ１３９４−１９９５やＩＥＥＥ１３９４ａバスのみに対応したＧａｐ＿Ｃｏｕｎｔ算出方法が用いられる可能性がある。
【０００９】
ここで、ＩＥＥＥ１３９４−１９９５やＩＥＥＥ１３９４ａバスのみに対応したＧａｐ＿Ｃｏｕｎｔ算出方法とは、ホップ数（二つのノード間の経路で使用したケーブルの数）による算出方法や、あらかじめ定数として宣言する方法などである。たとえば、ホップ数による算出方法は、バス上で最も長いパス（経路）のホップ数を求めて、規格に定められた表（以下、Ｇａｐ＿Ｃｏｕｎｔテーブルという）から対応するホップ数のＧａｐ＿Ｃｏｕｎｔを参照する。
【００１０】
Ｇａｐ＿Ｃｏｕｎｔは、最も長いパスを使ってデータ伝送したときの伝搬時間から求められる。ＩＥＥＥ１３９４−１９９５やＩＥＥＥ１３９４ａはケーブルの長さが４．５ｍまでという制限があり、かつ、使用するケーブルの種類が限られている。このため、１ホップでデータ伝送したときの伝搬時間を定数として定めることができる。そこで、ホップ数ごとにＧａｐ＿Ｃｏｕｎｔを算出し、Ｇａｐ＿Ｃｏｕｎｔテーブルを作成することができる。
【００１１】
Ｇａｐ＿Ｃｏｕｎｔ設定ノードは、バスリセットが発生すると接続の中で最も長いパスのホップ数を調べ、そのホップ数に対応するＧａｐ＿ＣｏｕｎｔをＧａｐ＿Ｃｏｕｎｔテーブルから参照し、各ノードに設定する。しかし、このテーブルはＩＥＥＥ１３９４−１９９５やＩＥＥＥ１３９４ａノードのみがバス上に存在することが前提で作成されており、ＩＥＥＥ１３９４ｂノードについては考慮されていない。このため、１３９４混在ネットワークにおいて、適切なＧａｐ＿Ｃｏｕｎｔの設定をおこなうことができないという問題が一例として挙げられる。
【００１２】
また、１３９４混在ネットワークにおいては、バス上にＩＥＥＥ１３９４ｂノードも存在するため、「最も長いパス」＝「ホップ数の最も多いパス」であるとは限らない。仮に、偶然「最も長いパス」＝「ホップ数の最も多いパス」であったとしても、Ｇａｐ＿ＣｏｕｎｔテーブルはＩＥＥＥ１３９４−１９９５やＩＥＥＥ１３９４ａノードのみからなるパスを前提として作成されているため、パスの途中にＩＥＥＥ１３９４ｂノードが存在した場合のＧａｐ＿Ｃｏｕｎｔとは異なる値となる可能性が高い。このように、１３９４混在ネットワークにおいては、不正なＧａｐ＿Ｃｏｕｎｔ値が設定される可能性があるという問題が一例として挙げられる。
【００１３】
また、このように不適切なＧａｐ＿Ｃｏｕｎｔが設定されたままでネットワークの使用を続けると、ネットワークの動作が不安定になったり、機器のスループットが下がってしまうという問題が一例として挙げられる。
【００１４】
この発明は、上述した従来技術による問題点を解消するため、不適切な通信制御値が設定されるのを防止することができる通信監視装置、通信監視方法、通信監視プログラムおよび記録媒体を提供することを目的とする。
【課題を解決するための手段】
【００１５】
上述した課題を解決し、目的を達成するため、請求項１の発明にかかる通信監視装置は、ＩＥＥＥ１３９４シリアルバスを用いて複数の機器が接続されたネットワークを監視する通信監視装置であって、前記ネットワークにおける他の機器が決定または管理する通信制御値に関する情報を取得する取得手段と、前記ネットワークに適合した前記通信制御値を算出する算出手段と、前記算出手段によって算出された通信制御値と、前記取得手段によって取得された通信制御値に関する情報とを比較して、前記通信制御値に関する情報が前記ネットワークに適合しているか否かを判断する判断手段と、前記判断手段による判断結果を通知する通知手段と、備えることを特徴とする。また、請求項４の発明にかかる通信監視装置は、ＩＥＥＥ１３９４シリアルバスを用いて複数の機器が接続されたネットワークを監視する通信監視装置であって、前記ネットワークにおける他の機器が決定または管理する通信制御値に関する情報を取得する取得手段と、前記取得手段によって取得された通信制御値に関する情報に基づいて、前記通信制御値に関する情報が前記ネットワークに適合しているか否かを判断する判断手段と、前記判断手段による判断結果を通知する通知手段と、を備え、前記取得手段は、前記通信制御値に関する情報として前記ネットワークにおけるＧａｐ＿Ｃｏｕｎｔ値を決定する機器に関する情報を取得することを特徴とする。
［００１６］
また、請求項１０にかかる通信監視方法は、ＩＥＥＥ１３９４シリアルバスを用いて複数の機器が接続されたネットワークを監視する通信監視方法であって、前記ネットワークにおける他の機器が決定または管理する通信制御値に関する情報を取得する取得工程と、前記ネットワークに適合した前記通信制御値を算出する算出工程と、前記算出工程で算出された通信制御値と、前記取得工程で取得された通信制御値に関する情報とを比較して、前記通信制御値に関する情報が前記ネットワークに適合しているか否かを判断する判断工程と、前記判断工程による判断結果を通知する通知工程と、を含むことを特徴とする。また、請求項１１にかかる通信監視方法は、ＩＥＥＥ１３９４シリアルバスを用いて複数の機器が接続されたネットワークを監視する通信監視方法であって、前記ネットワークにおける他の機器が決定または管理する通信制御値に関する情報を取得する取得工程と、前記取得工程で取得された通信制御値に関する情報に基づいて、前記通信制御値に関する情報が前記ネットワークに適合しているか否かを判断する判断工程と、前記判断工程による判断結果を通知する通知工程と、を含み、前記取得工程は、前記通信制御値に関する情報として前記ネットワークにおけるＧａｐ＿Ｃｏｕｎｔ値を決定する機器に関する情報を取得することを特徴とする。
［００１７］
また、請求項１２にかかる通信監視プログラムは、請求項１０または１１に記載の通信監視方法をコンピュータに実行させることを特徴とする。
［００１８］
また、請求項１３にかかる記録媒体は、請求項１２に記載の通信監視プログラムを記録したことを特徴とする。
【図面の簡単な説明】
［００１９］
［図１］図１は、実施の形態にかかる通信監視装置の機能的構成を示すブロック図である。
［図２］図２は、通信監視装置の通信監視処理の手順を示すフローチャートである。
［図３］図３は、実施例にかかる通信監視装置が監視するネットワークの構成機器を示す図である。
［図４］図４は、図３に示したネットワークの構成を模式的に示した図である。
［図５］図５は、Ｇａｐ＿Ｃｏｕｎｔ設定ノードがおこなうＧａｐ＿Ｃｏｕｎｔ設定処理の手順を示すフローチャートである。
［図６］図６は、監視ノードがおこなうＧａｐ＿Ｃｏｕｎｔの監視処理の手順を示すフローチャートである。
【図７】図７は、監視ノードがおこなうＧａｐ＿Ｃｏｕｎｔの監視処理の手順を示すフローチャートである。
【図８】図８は、ユーザへの警告を示す表示画面の一例を示す図である。
【図９】図９は、ユーザへの警告を示す表示画面の一例を示す図である。
【図１０】図１０は、ユーザへの警告を示す表示画面の一例を示す図である。
【符号の説明】
【００２０】
１００  通信監視装置
１１１  取得部
１１２  判断部
１１３  通知部
１１４  算出部
１１５  機器特定部
１１６  切断部
１２１  ＩＥＥＥ１３９４ｂに対応した機器
１２２  ＩＥＥＥ１３９４ｂに対応していない機器
１３０  ネットワーク
【発明を実施するための最良の形態】
【００２１】
以下に添付図面を参照して、本発明にかかる通信監視装置、通信監視方法、通信監視プログラムおよび記録媒体の好適な実施の形態を詳細に説明する。
【００２２】
（実施の形態）
（通信監視装置１００の機能的構成）
図１は、実施の形態にかかる通信監視装置の機能的構成を示すブロック図である。実施の形態にかかる通信監視装置１００は、ＩＥＥＥ１３９４シリアルバスを用いて複数の機器が接続されたネットワーク１３０を監視する。ネットワーク１３０は１３９４混在ネットワークであり、ＩＥＥＥ１３９４ｂに対応した機器１２１およびＩＥＥＥ１３９４ｂに対応していない機器１２２がそれぞれ少なくとも１つずつ接続される。通信監視装置１００は、取得部１１１、判断部１１２、通知部１１３、算出部１１４、機器特定部１１５、切断部１１６によって構成される。
【００２３】
取得部１１１は、ネットワーク１３０における他の機器が決定または管理する通信制御値に関する情報を取得する。通信制御値に関する情報とは、たとえば、ネットワーク１３０におけるＧａｐ＿Ｃｏｕｎｔ値や、Ｇａｐ＿Ｃｏｕｎｔ値の設定のために送信されるＰＨＹパケットの発行の有無や、Ｇａｐ＿Ｃｏｕｎｔ値が記述されているＳｅｌｆ＿ＩＤパケットの発行の有無、前記Ｓｅｌｆ＿ＩＤパケットの発行を促すためのＰｉｎｇパケット発行の有無、Ｇａｐ＿Ｃｏｕｎｔ設定ノードの機器情報（Ｇａｐ＿Ｃｏｕｎｔ設定ノードがＩＥＥＥ１３９４ｂに対応している機器であるか否かの情報も含む）などである。また、通信制御値に関する情報には、通信制御値そのものを含むものとする。
【００２４】
判断部１１２は、取得部１１１によって取得された通信制御値に関する情報に基づいて、通信制御値に関する情報がネットワーク１３０に適合しているか否かを判断する。判断部１１２は、たとえば、ＩＥＥＥ１３９４ｂに対応していない機器１２２によって通信制御値が決定された場合に、通信制御値に関する情報がネットワーク１３０に適合しないと判断する。
【００２５】
または後述する算出部１１４によって算出された通信制御値と、取得部１１１によって取得された通信制御値に関する情報とを比較して、ネットワーク１３０における他の機器が決定または管理する通信制御値に関する情報がネットワーク１３０に適合しているか否かを判断する。また、たとえば、特定の値が通信制御値として設定された場合には、通信制御値に関する情報がネットワーク１３０に適合しないと判断することとしてもよい。
【００２６】
通知部１１３は、判断部１１２による判断結果を通知する。通知部１１３による通知は、たとえば、表示画面へのメッセージ表示やアニメ、音声などである。また、ネットワーク１３０に接続された他の機器に前述のような通知の出力をおこなわせるための制御信号を出力するものであってもよい。
【００２７】
算出部１１４は、ネットワーク１３０に適合した通信制御値を算出する。算出部１１４は、たとえば、ネットワーク１３０に接続された各機器にＰｉｎｇパケットを送信し、送信したＰｉｎｇパケットへの返答として各機器から送信されるＳｅｌｆ＿ＩＤパケットを受信するまでの時間に基づいて、通信制御値を算出する。
【００２８】
機器特定部１１５は、判断部１１２によって通信制御値に関する情報がネットワーク１３０に適合しないと判断された場合に、その原因となる機器を特定する。機器特定部１１５によって、原因となる機器が特定された場合、通知部１１３は、機器特定部１１５によって特定された機器に関する情報を報知する。具体的には、たとえば、機器の名称や識別番号、これらの機器の取り外しを求めるメッセージを表示する。
【００２９】
切断部１１６は、機器特定部１１５によって特定された機器とネットワーク１３０との接続を切断する。切断部１１６は、たとえば、機器特定部１１５によって特定された機器に対して、Ｒｅｍｏｔｅ  ｃｏｍｍａｎｄ  ｐａｃｋｅｔを送信し、他の機器と接続されているポートを停止させる。
【００３０】
（通信監視装置１００の通信監視処理）
図２は、通信監視装置の通信監視処理の手順を示すフローチャートである。まず、取得部１１１によって、ネットワーク１３０における他の機器が決定または管理する通信制御値に関する情報を取得する（ステップＳ２０１）。つぎに、算出部１１４によって、ネットワーク１３０に適合した通信制御値を算出する（ステップＳ２０２）。そして、判断部１１２によって、ステップＳ２０１で取得した通信制御値に関する情報と、ステップＳ２０２で算出した通信制御値とを比較する（ステップＳ２０３）。
【００３１】
判断部１１２は、ステップＳ２０３でおこなった比較の結果から、ネットワーク１３０における他の機器が決定または管理する通信制御値に関する情報がネットワーク１３０に適合しているかを判断する（ステップＳ２０４）。ネットワーク１３０に適合している場合は（ステップＳ２０４：Ｙｅｓ）、特に処理をおこなわずに本フローチャートによる処理を終了する。
【００３２】
一方、ネットワーク１３０に適合していない場合は（ステップＳ２０４：Ｎｏ）、機器特定部１１５によって原因となる機器を特定する（ステップＳ２０５）。そして、通知部１１３によって、ステップＳ２０５で特定された機器に関する情報を報知する（ステップＳ２０６）。また、特定された機器とネットワーク１３０との接続を切断して（ステップＳ２０７）、本フローチャートによる処理を終了する。
【００３３】
以上説明したように、実施の形態にかかる通信監視装置１００によれば、ＩＥＥＥ１３９４シリアルバスを用いて複数の機器が接続されるネットワーク１３０において、設定された通信制御値に関する情報がネットワーク１３０に適合しているかを判断することができる。通信制御値に関する情報がネットワーク１３０におけるＧａｐ＿Ｃｏｕｎｔ値である場合、ネットワーク１３０が不安定となったり、スループットが低下するのを防止したりすることができる。
【００３４】
また、不正な値が通信制御値に設定された場合、または設定される可能性がある場合に、ユーザにその旨を通知することができる。さらに、通信制御値に関する情報がネットワーク１３０に適合しないと判断された場合に、その原因となる機器を通知したり、ネットワーク１３０との接続を切断したりすることによって、不正な通信制御値が設定されるのを防止することができる。
【実施例】
【００３５】
（通信監視装置の構成機器）
図３は、実施例にかかる通信監視装置が監視するネットワークの構成機器を示す図である。実施例にかかる通信監視装置は、車内に設置された機器を接続する車内ネットワークを監視する。車内には、ナビゲーション装置３０１、カーステレオ３０２、ＥＴＣユニット３０３が設置されている。本実施例において、通信監視装置はナビゲーション装置３０１に設けられているものとする。また、通信監視装置が監視する通信制御値はＧａｐ＿Ｃｏｕｎｔ値とする。
【００３６】
なお、本実施例においては、通信監視装置はナビゲーション装置３０１やカーステレオ３０２などの車載機器をつなぐ車内ネットワークを監視するものとしたが、本発明の利用はこれに限るものではない。たとえば、家庭用電化製品どうしの接続や、車載装置と家電製品との接続にも用いることができる。
【００３７】
ナビゲーション装置３０１は、実施例にかかる通信監視装置を含み、車内ネットワークにおけるＧａｐ＿Ｃｏｕｎｔ値を監視する。また、目的地までの経路を探索し、走行中に経路の誘導をおこなう。さらに、ナビゲーション装置３０１は、地図情報や周辺の施設情報などが記憶された記憶媒体を有しており、余った記憶領域に音楽データなどを蓄積することができる。
【００３８】
図示した例では、ナビゲーション装置３０１の表示画面３０１ａには、車両後方の様子が表示されている。これは、車両の後部に取り付けられているバックカメラ（図示せず）によって撮影された映像を、表示画面３０１ａに表示しているものである。ユーザはバックカメラからの映像によって、後方の安全確認をおこなうことができる。なお、ナビゲーション装置３０１とバックカメラは、ＩＥＥＥ１３９４バスによって接続されている。
【００３９】
カーステレオ３０２は、ＣＤやＭＤなどに記録された音楽データを再生し、図示しないスピーカから音声出力させる。ＥＴＣユニット３０３は、ＥＴＣ情報の処理部、ＥＴＣカード挿入部およびアンテナを有し、ＥＴＣシステムを用いた料金所における通行料金の授受に用いられる。
【００４０】
ナビゲーション装置３０１とカーステレオ３０２は、相互にＩＥＥＥ１３９４バスによって接続されている。これにより、カーステレオ３０２において、ナビゲーション装置３０１の記憶領域に記憶された音楽データの再生をおこなうことができる。また、ナビゲーション装置３０１とＥＴＣユニット３０３も、同様にＩＥＥＥ１３９４バスによって接続されている。これにより、ナビゲーション装置３０１において、ＥＴＣユニット３０３が搭載されていることを認識し、ＥＴＣ専用レーンなどを考慮した経路探索をおこなうことができる。
【００４１】
また、カーステレオ３０２には、ポータブルオーディオプレイヤー３０４が接続されている。ポータブルオーディオプレイヤー３０４は、機器内部に搭載されたハードディスクやフラッシュメモリなどに記憶した音楽データを再生する。また、このようにカーステレオ３０２に接続することによって、ポータブルオーディオプレイヤー３０４に記憶された音楽データをカーステレオ３０２で再生したり、ポータブルオーディオプレイヤー３０４で再生した音楽をカーステレオ３０２のスピーカから出力することができる。
【００４２】
（ネットワーク構成）
図４は、図３に示したネットワークの構成を模式的に示した図である。ナビゲーション装置３０１は、カーステレオ３０２、ＥＴＣユニット３０３、バックカメラとそれぞれ接続されている。また、カーステレオ３０２は、ナビゲーション装置３０１の他、ポータブルオーディオプレイヤー３０４と接続されている。
【００４３】
以下において、各機器をネットワーク上におけるノードとおき、ナビゲーション装置３０１はノード４０１、カーステレオ３０２はノード４０２、ＥＴＣユニット３０３はノード４０３、ポータブルオーディオプレイヤー３０４はノード４０４、バックカメラはノード４０５とする。各ノード４０１〜４０５は、それぞれＩＥＥＥ１３９４バスによって接続されている。
【００４４】
ここで、これらの機器はＩＥＥＥ１３９４規格による接続をおこなっているが、ノード４０３，４０４、４０５はＩＥＥＥ１３９４−１９９５又はＩＥＥＥ１３９４ａに準拠するノード（以下、ＩＥＥＥ１３９４−１９９５  又はＩＥＥＥ１３９４ａノードという）である。一方、網掛けで示したノード４０１，４０２は、ＩＥＥＥ１３９４ｂに準拠するノード（以下、ＩＥＥＥ１３９４ｂノードという）である。ＩＥＥＥ１３９４ｂは、ＩＥＥＥ１３９４ａを改良した規格であり、最大転送速度は８００Ｍｂｐｓ（ＩＥＥＥ１３９４ａは４００Ｍｂｐｓ）、ケーブルには光ファイバー、Ｅｔｈｅｒｎｅｔ（登録商標）ケーブルなどを用いることができる（ＩＥＥＥ１３９４ａはメタルケーブル）。また、最大接続距離は１００ｍ（ＩＥＥＥ１３９４ａは４．５ｍ）となっている。
【００４５】
このように、ＩＥＥＥ１３９４ｂは、ＩＥＥＥ１３９４−１９９５やＩＥＥＥ１３９４ａと異なる点が多く、Ｇａｐ＿Ｃｏｕｎｔの算出も、ＩＥＥＥ１３９４−１９９５やＩＥＥＥ１３９４ａと同様におこなうことはできない。前述のように、ＩＥＥＥ１３９４−１９９５やＩＥＥＥ１３９４ａはケーブルの長さが４．５ｍまでという制限があり、かつ使用するケーブルの種類が限られているため、１ホップでデータ伝送したときの伝搬時間をホップ数ごとに定数として定めている。
【００４６】
一方で、１３９４混在ネットワーク構成においては、ケーブルの長さや種類が異なるため、ホップ数によってＧａｐ＿Ｃｏｕｎｔを設定することはできない。この場合、Ｇａｐ＿Ｃｏｕｎｔ設定ノードは、Ｐｉｎｇパケットを利用し、最長のパスにおけるデータの伝播時間を元にＧａｐ＿Ｃｏｕｎｔを算出する。
【００４７】
具体的には、Ｇａｐ＿Ｃｏｕｎｔ設定ノードは、他のすべてのノードに対してＰｉｎｇパケットを送信する。各ノードは、Ｇａｐ＿Ｃｏｕｎｔ設定ノードからのＰｉｎｇパケットを受けて、Ｓｅｌｆ＿ＩＤパケットをブロードキャストする。Ｇａｐ＿Ｃｏｕｎｔ設定ノードは、Ｐｉｎｇパケットを送信してから、すべてのノードからＳｅｌｆ＿ＩＤパケットを受信するまでの時間をもとにＧａｐ＿Ｃｏｕｎｔを設定する。
【００４８】
図４に示したようなネットワーク構成において、Ｇａｐ＿Ｃｏｕｎｔ設定ノードはネットワークのトポロジに変化が生じるごとに変化する。このとき、ＩＥＥＥ１３９４ｂに対応しないノードがＧａｐ＿Ｃｏｕｎｔ設定ノードとなってしまった場合、ＩＥＥＥ１３９４ｂノードを考慮せずにＧａｐ＿Ｃｏｕｎｔを設定してしまい、不適切なＧａｐ＿Ｃｏｕｎｔのためネットワークが不安定になったり、ネットワークのスループットが低下してしまう場合がある。
【００４９】
これを防止するため、Ｇａｐ＿Ｃｏｕｎｔ設定ノードが設定するＧａｐ＿Ｃｏｕｎｔが適切に設定されているかを監視する監視ノード（通信監視装置）を置く。ここで、監視ノードはＩＥＥＥ１３９４ｂに対応するノードもしくは前述したＰｉｎｇパケットによるＧａｐ＿Ｃｏｕｎｔの算出をおこなうことができるノードである必要がある。本実施例では、Ｇａｐ＿Ｃｏｕｎｔ設定ノードをＩＥＥＥ１３９４ａノードであるノード４０４、監視ノードをＩＥＥＥ１３９４ｂノードであるノード４０１として説明する。
【００５０】
（Ｇａｐ＿Ｃｏｕｎｔ設定ノードによるＧａｐ＿Ｃｏｕｎｔ設定処理）
図５は、Ｇａｐ＿Ｃｏｕｎｔ設定ノードがおこなうＧａｐ＿Ｃｏｕｎｔ設定処理の手順を示すフローチャートである。まず、バスリセットが発生すると（ステップＳ５０１：Ｙｅｓ）、各ノードはバスリセット信号を受けて、Ｓｅｌｆ＿ＩＤパケットを送信し、Ｇａｐ＿Ｃｏｕｎｔ設定ノード（ノード４０４）は、各ノードのＳｅｌｆ＿ＩＤパケットを受信する（ステップＳ５０２）。そして、Ｇａｐ＿Ｃｏｕｎｔ設定ノードは、バス上でトポロジが変化したかどうかを判断する（ステップＳ５０３）。バス上のトポロジが変化すると（ステップＳ５０３：Ｙｅｓ）、Ｇａｐ＿Ｃｏｕｎｔ設定ノードは、変化後のトポロジに対応したＧａｐ＿Ｃｏｕｎｔの算出をおこなう（ステップＳ５０４）。
【００５１】
そして、算出したＧａｐ＿Ｃｏｕｎｔが各ノードに既に設定されているＧａｐ＿Ｃｏｕｎｔと等しいかを判断する（ステップＳ５０５）。算出したＧａｐ＿Ｃｏｕｎｔが各ノードに既に設定されているＧａｐ＿Ｃｏｕｎｔと等しい場合は（ステップＳ５０５：Ｙｅｓ）、Ｇａｐ＿Ｃｏｕｎｔの再設定をおこなう必要がないため、本フローチャートによる処理を終了する。
【００５２】
一方、算出したＧａｐ＿Ｃｏｕｎｔが各ノードに既に設定されているＧａｐ＿Ｃｏｕｎｔと異なっている場合は（ステップＳ５０５：Ｎｏ）、Ｇａｐ＿Ｃｏｕｎｔの再設定をおこなうため、Ｇａｐ＿Ｃｏｕｎｔ設定ノードは、各ノードに算出したＧａｐ＿Ｃｏｕｎｔを含んだＰＨＹパケットを送信する（ステップＳ５０６）。各ノードは、送信されたＰＨＹパケットに含まれるＧａｐ＿ＣｏｕｎｔをＰＨＹレジスタに設定する。そして、Ｇａｐ＿Ｃｏｕｎｔ設定ノードは再度バスリセット信号を送信し（ステップＳ５０７）、本フローチャートによる処理を終了する。この再度のバスリセット信号によって、各ノードが設定したＧａｐ＿Ｃｏｕｎｔが有効になる。
【００５３】
以上のような処理によって、Ｇａｐ＿Ｃｏｕｎｔ設定ノードはバスにトポロジの変化が発生するごとにＧａｐ＿Ｃｏｕｎｔの設定をおこなう。ステップＳ５０４においておこなわれるＧａｐ＿Ｃｏｕｎｔの算出は、Ｇａｐ＿Ｃｏｕｎｔ設定ノードが対応する規格によっておこなわれる。すなわち、ＩＥＥＥ１３９４ａノードであるノード４０４は、バス上にＩＥＥＥ１３９４ｂノードが存在することを考慮せずにＧａｐ＿Ｃｏｕｎｔの算出をおこなってしまう。このため、監視ノードであるノード４０１は、以下に示すような処理によってＧａｐ＿Ｃｏｕｎｔの監視をおこない、不適切なＧａｐ＿Ｃｏｕｎｔが設定されるのを防止している。
【００５４】
（監視ノードによるＧａｐ＿Ｃｏｕｎｔ監視処理）
図６および図７は、監視ノードがおこなうＧａｐ＿Ｃｏｕｎｔの監視処理の手順を示すフローチャートである。なお、監視ノードがおこなう監視処理は、Ｇａｐ＿Ｃｏｕｎｔ設定ノードがＧａｐ＿Ｃｏｕｎｔの設定をおこなった後におこなうのが望ましい。このため、図６に示す処理は、Ｇａｐ＿Ｃｏｕｎｔ設定ノードがＧａｐ＿Ｃｏｕｎｔの設定をおこなったかを監視する処理であり、図７に示す処理は、Ｇａｐ＿Ｃｏｕｎｔ設定ノードが設定したＧａｐ＿Ｃｏｕｎｔが適切な値であるかを監視する処理である。
【００５５】
まず、監視ノード（ノード４０１）は、バスリセット信号を受信したかを監視する（ステップＳ６０１）。バスリセット信号を受信すると（ステップＳ６０１：Ｙｅｓ）、バス上のトポロジが変化したか、または他のすべてのノードに設定されたＧａｐ＿Ｃｏｕｎｔが不一致であるかを判断する（ステップＳ６０２）。
【００５６】
トポロジが変化した、または他のすべてのノードに設定されたＧａｐ＿Ｃｏｕｎｔが不一致である場合は（ステップＳ６０２：Ｙｅｓ）、再度他のすべてのノードに設定されたＧａｐ＿Ｃｏｕｎｔが一致しているかを確認する（ステップＳ６０３）。一方、トポロジが変化せず、かつ他のすべてのノードに設定されたＧａｐ＿Ｃｏｕｎｔが一致する（不一致ではない）場合は（ステップＳ６０２：Ｎｏ）、図７のＡに移行して、本フローチャートによる処理を終了する（図７参照）。
【００５７】
つぎに、ステップＳ６０３において、他のすべてのノードに設定されたＧａｐ＿Ｃｏｕｎｔが一致する場合は（ステップＳ６０３：Ｙｅｓ）、所定の時間内にバスリセット信号を受信したかを判断する（ステップＳ６０４）。これは、Ｇａｐ＿Ｃｏｕｎｔの再設定がおこなわれるかが不明な状態なため、所定の時間待機しているものである。バスリセットが発生した場合であっても、たとえば、Ｇａｐ＿Ｃｏｕｎｔ設定ノードがバスリセット後算出したＧａｐ＿Ｃｏｕｎｔが、各ノードに既に設定されているＧａｐ＿Ｃｏｕｎｔと等しい場合には、Ｇａｐ＿Ｃｏｕｎｔの再設定はおこなわれない（図５のステップＳ５０４参照）。
【００５８】
所定の時間内にバスリセット信号を受信した場合は（ステップＳ６０４：Ｙｅｓ）、Ｇａｐ＿Ｃｏｕｎｔの再設定がおこなわれたとして、図７のＢに移行する。一方、所定の時間内にバスリセット信号を受信しなかった場合は（ステップＳ６０４：Ｎｏ）、Ｇａｐ＿Ｃｏｕｎｔの再設定はおこなわれなかったものとして、図７のＡに移行して、本フローチャートによる処理を終了する（図７参照）。ここで、バスリセット信号の受信を待機している時間は任意であるが（ステップＳ６０４の「所定の時間」）、たとえば、バスリセット信号の受信から１秒とすることができる。
【００５９】
ＩＥＥＥ１３９４の規格上、Ｇａｐ＿Ｃｏｕｎｔがいつまでに決定されていなければならないとの規定は明記されていない。しかし、Ｇａｐ＿Ｃｏｕｎｔの設定は、機器どうしのコネクションを確立する際に使用するｏｖｅｒｈｅａｄＩＤに関係している。バスリセットが発生した場合、バスリセット発生前のコネクションを継続させるためには、バスリセット発生後１秒以内にコネクションを再確立しなくてはならない旨が規定されている。このため、バスリセット発生後１秒以内にはＧａｐ＿Ｃｏｕｎｔが決定されていることが予想される。この予想を元に、ステップＳ６０４において待機する時間を１秒と設定する。
【００６０】
また、たとえば、すべてのノードのＧａｐ＿Ｃｏｕｎｔが一致していると判断したのち（ステップＳ６０３：Ｙｅｓ）、いずれかのノードが送信したＳｅｌｆＩＤパケットを受信した場合には、すべてのノードからのＳｅｌｆ＿ＩＤパケットを受信するまで待機したのちに図７のＢに移行するようにしてもよい。先述のように、他のすべてのノードに設定されたＧａｐ＿Ｃｏｕｎｔが一致する場合は、Ｇａｐ＿Ｃｏｕｎｔの再設定がおこなわれるかが不明である。このような状態で監視ノードがＳｅｌｆ＿ＩＤパケットを受信した場合、Ｇａｐ＿Ｃｏｕｎｔ設定ノードがＰｉｎｇパケットを用いてＧａｐ＿Ｃｏｕｎｔの算出をおこなおうとしていることが予想される。
【００６１】
Ｇａｐ＿Ｃｏｕｎｔの算出処理のうち、最も処理に時間を要するのはＰｉｎｇパケットの送信およびＳｅｌｆ＿ＩＤパケットの受信処理である。このため、すべてのノードからＳｅｌｆ＿ＩＤパケットの送信がおこなわれたことが確認できれば、Ｇａｐ＿Ｃｏｕｎｔの算出処理が間もなく完了することを予想することができ、ステップＳ６０４のように所定の時間待つことなく監視処理を開始することができる。
【００６２】
さらに、Ｇａｐ＿Ｃｏｕｎｔの算出には、最低限リーフノード（先端のノード）とブランチノード（枝分かれしているノード）までの応答時間がわかればよい。このため、監視ノードにおいても、すべてのリーフノードおよびブランチノードからＳｅｌｆ＿ＩＤパケットを受信したことを確認できれば、Ｇａｐ＿Ｃｏｕｎｔの算出処理が間もなく完了することを予想することができる。
【００６３】
つぎに、ステップＳ６０３において、他のすべてのノードに設定されたＧａｐ＿Ｃｏｕｎｔが一致しない場合は（ステップＳ６０３：Ｎｏ）、２度目のバスリセット信号の受信を待って待機する（ステップＳ６０５：Ｎｏのループ）。他のすべてのノードに設定されたＧａｐ＿Ｃｏｕｎｔが一致しない場合は、必ずＧａｐ＿Ｃｏｕｎｔの再設定がおこなわれるため、ＰＨＹパケットによって設定されたＧａｐ＿Ｃｏｕｎｔを有効にするためのバスリセット信号が送信されるためである。
【００６４】
そして、２度目のバスリセット信号を受信すると（ステップＳ６０５：Ｙｅｓ）、バス上のトポロジに変化がなく、かつ他のすべてのノードに設定されたＧａｐ＿Ｃｏｕｎｔが一致するかを判断する（ステップＳ６０６）。バス上のトポロジに変化がなく、かつ他のすべてのノードに設定されたＧａｐ＿Ｃｏｕｎｔが一致する場合は（ステップＳ６０６：Ｙｅｓ）、ステップＳ６０５で受信したバスリセット信号は、Ｇａｐ＿Ｃｏｕｎｔを有効にするためのバスリセットであったとして、図７のＢに移行する。
【００６５】
一方、バス上のトポロジに変化があった、または他のすべてのノードに設定されたＧａｐ＿Ｃｏｕｎｔが一致しない場合は（ステップＳ６０６：Ｎｏ）、ステップＳ６０５で受信したバスリセットはＧａｐ＿Ｃｏｕｎｔを有効にするためのバスリセットではなかったとしてステップＳ６０３に戻って、以下の処理を繰り返す。監視ノードは、以上のような処理によって、Ｇａｐ＿Ｃｏｕｎｔ設定ノードがＧａｐ＿Ｃｏｕｎｔの設定をおこなったことを確認し、図７に示す処理に移行する。
【００６６】
つぎに、図７に示す処理（Ｇａｐ＿Ｃｏｕｎｔ設定ノードが設定したＧａｐ＿Ｃｏｕｎｔが適切な値であるかを監視する処理）について説明する。まず、監視ノードは、Ｏｂｓｅｒｖｅ＿Ｇａｐ＿Ｃｏｕｎｔを算出する（ステップＳ７０１）。このＯｂｓｅｒｖｅ＿Ｇａｐ＿Ｃｏｕｎｔは、監視ノードがＧａｐ＿Ｃｏｕｎｔ設定ノードの監視用に算出する値であり、１３９４混在ネットワークにおいても正しくＧａｐ＿Ｃｏｕｎｔが求まる方法（たとえば、Ｐｉｎｇパケットを利用した方法）によって算出される。
【００６７】
つぎに、監視ノードは、算出したＯｂｓｅｒｖｅ＿Ｇａｐ＿Ｃｏｕｎｔと、他のノードに設定されているＧａｐ＿Ｃｏｕｎｔとを比較する（ステップＳ７０２）。そして、他のノードに設定されているＧａｐ＿Ｃｏｕｎｔが明らかに不正かを判断する（ステップＳ７０３）。ここで、明らかに不正と判断する基準は特に限定しないが、たとえば、算出したＯｂｓｅｒｖｅ＿Ｇａｐ＿Ｃｏｕｎｔとの誤差が一定以上ある場合や、Ｇａｐ＿ＣｏｕｎｔがＯｂｓｅｒｖｅ＿Ｇａｐ＿Ｃｏｕｎｔより小さい場合などが想定される。
【００６８】
Ｇａｐ＿Ｃｏｕｎｔが明らかに不正である場合は（ステップＳ７０３：Ｙｅｓ）、ユーザに警告をおこない（ステップＳ７０４）、本フローチャートによる処理を終了する。一方、Ｇａｐ＿Ｃｏｕｎｔが不正とは認められない場合は（ステップＳ７０３：Ｎｏ）、警告をおこなわず、本フローチャートによる処理を終了する。
【００６９】
（警告の表示例）
図８〜１０は、ユーザへの警告を示す表示画面の一例である。図８においては、監視ノードであるノード４０１（ナビゲーション装置３０１）の表示画面３０１ａに、「ポータブルオーディオプレイヤーを接続しているとネットワークが不安定となる可能性があります」との警告表示８０１が表示されている。Ｇａｐ＿Ｃｏｕｎｔ設定ノードであるノード４０４（ポータブルオーディオプレイヤー３０４）は、ＩＥＥＥ１３９４ａノードであるため、１３９４混在ネットワークには対応することができない。このため、実際に必要なＧａｐ＿Ｃｏｕｎｔより小さい値を設定してしまい、ネットワークが不安定となる可能性があることを示している。
【００７０】
図９においては、「ナビゲーション装置やカーステレオが原因でネットワークが不安定になる可能性があります」との警告表示９０１が表示画面３０１ａに表示されている。図８の例とは異なり、ＩＥＥＥ１３９４ｂノードであるノード４０１（ナビゲーション装置３０１）やノード４０２（カーステレオ３０２）の機器名を通知することによって、これらの機器を取り外し、ＩＥＥＥ１３９４−１９９５やＩＥＥＥ１３９４ａノードのみでネットワークを構成させることができる。
【００７１】
図１０においては、「このままの接続状態では、同時に使用できる機器が通常より少なくなる可能性があります。原因と思われる機器は、ポータブルオーディオプレイヤーです」との警告表示１００１が表示されている。図８および図９は、設定されたＧａｐ＿Ｃｏｕｎｔが小さすぎる場合の例を示したが、図１０は設定されたＧａｐ＿Ｃｏｕｎｔが大きすぎる場合の警告表示の例である。
【００７２】
設定されたＧａｐ＿Ｃｏｕｎｔが大きすぎる場合、ネットワークが不安定となることはないため、機器の取り外しは必要ではない。しかし、ネットワークのスループットが低下してしまう可能性があり、このことをユーザに警告するものである。なお、図示した例ではＧａｐ＿Ｃｏｕｎｔ設定ノードであるノード４０４の機器名（ポータブルオーディオプレイヤー３０４）を表示させることとしたが、ＩＥＥＥ１３９４ｂノードの機器名を表示させることとしてもよい。
【００７３】
また、このように表示画面３０１ａに文字による警告表示をする他にも、アニメや図などでの警告や、警告音・音楽など音声出力による警告、警告灯の点灯などであってもよい。また、監視ノードの機器自体が警告をおこなうのではなく、他の機器に前述のような警告をおこなわせるように制御信号を出力してもよい。たとえば、監視ノードであるナビゲーション装置３０１が、カーステレオ３０２のスピーカから警告用の音声を音声出力させるようにしてもよい。
【００７４】
さらに、不正なＧａｐ＿Ｃｏｕｎｔを設定する可能性のあるノードがＧａｐ＿Ｃｏｕｎｔ設定ノードとなった場合に、そのノードをネットワークから切り離すようにしてもよい。ＩＥＥＥ１３９４においては、Ｒｅｍｏｔｅ  ｃｏｍｍａｎｄ  ｐａｃｋｅｔを送信することによって、所望のノードのポートを停止することができる。監視ノードは、不正なＧａｐ＿Ｃｏｕｎｔを設定する可能性のあるノードがＧａｐ＿Ｃｏｕｎｔ設定ノードとなった場合に、Ｒｅｍｏｔｅ  ｃｏｍｍａｎｄ  ｐａｃｋｅｔを送信し、そのノードと他の機器とが接続されているポートを停止させる。これにより、停止させたポートを介した通信ができなくなり、不正なＧａｐ＿Ｃｏｕｎｔを設定する可能性のあるノードをネットワークから切り離すことができる。
【００７５】
たとえば、図４に示したネットワーク構成において、Ｇａｐ＿Ｃｏｕｎｔ設定ノードがＩＥＥＥ１３９４ａノードであるノード４０４となった場合、監視ノードであるノード４０１は、ノード４０４の有するポートのうち、ノード４０１と接続されているポートを停止する。これにより、ノード４０４の先に接続されているノードとは通信ができなくなるものの、ノード４０１、４０２、４０３、４０５の間であらたなＧａｐ＿Ｃｏｕｎｔ設定ノードが設定され、不正なＧａｐ＿Ｃｏｕｎｔが設定されるのを防ぐことができる。
【００７６】
なお、監視ノードとなり得るノードがネットワーク上に複数存在する場合、１台のみが監視ノードとなるように管理する。たとえば、監視ノードとなり得るノードは、監視処理を始める前に他のノードに対して監視処理開始を宣言し、最も早く監視処理開始を宣言したノードが監視ノードとなるなどの方法がある。また、各ノードに機器識別子を付して、機器識別子によって監視ノードを設定したり、最新の機器を監視ノードに設定するなどの方法であってもよい。
【００７７】
また、監視ノードの処理負担を軽減することによって、より短時間でユーザに警告をおこなうようにしてもよい。前述した実施例において、監視ノードは、Ｇａｐ＿Ｃｏｕｎｔ設定ノードがＧａｐ＿Ｃｏｕｎｔの設定をおこなったかを監視し（図６参照）、Ｇａｐ＿Ｃｏｕｎｔ設定ノードが設定したＧａｐ＿Ｃｏｕｎｔが適切な値であるかを監視した（図７参照）。このような処理に代えて、以下のような処理をおこなうようにしてもよい。
【００７８】
たとえば、ＩＥＥＥ１３９４ｂに対応していないＩＥＥＥ１３９４−１９９５やＩＥＥＥ１３９４ａノードがＧａｐ＿Ｃｏｕｎｔ設定ノードとなった場合、Ｇａｐ＿Ｃｏｕｎｔは、バスのホップ数をもとにあらかじめ計算されたＧａｐ＿Ｃｏｕｎｔ値の表に基づいて設定される。もしくは、ＩＥＥＥ１３９４ａ規格における最大のホップ数である１６のときのＧａｐ＿Ｃｏｕｎｔ値である「４３」や、Ｇａｐ＿Ｃｏｕｎｔは６ビット長の値であるので、２ビット長で表現できる最大値である６３に設定される。
【００７９】
このような値がＧａｐ＿Ｃｏｕｎｔに設定された場合、監視ノードは、１３９４混在ネットワークにおいては不適切な値であるとして、ユーザに警告をおこなう。これにより、Ｏｂｓｅｒｖｅ＿Ｇａｐ＿Ｃｏｕｎｔを算出したり、他のノードに設定されたＧａｐ＿Ｃｏｕｎｔとの比較をしたりする必要がなく、監視ノードの処理負担を軽減させ、より短時間のうちにユーザに警告をおこなうことができる。
【００８０】
また、監視ノードによって、バスリセットの発生後、Ｇａｐ＿Ｃｏｕｎｔの設定がおこなわれる前に他のノードからＰｉｎｇパケットの発行があったかどうかを監視するようにしてもよい。他のノードからＰｉｎｇパケットの発行がない場合、Ｇａｐ＿Ｃｏｕｎｔの算出にＰｉｎｇを使用していないこととなり、１３９４混在ネットワークにおいては不適切な値が設定されたこととなる。これをユーザに警告することによって、監視ノードの処理負担を軽減させ、より短時間のうちにユーザに警告をおこなうことができる。
【００８１】
上述した方法でＧａｐ＿Ｃｏｕｎｔの設定が適切であるかを判断する場合、バス上のノード数とトポロジを考慮することによって、より適切な場合に警告をおこなうことができる。たとえば、車載機器をつなぐネットワーク（以下、車載ネットワークという）は、閉じたネットワークとなることが多く、最大ケーブル長があらかじめ定まったシステム構成とできる場合がある。このとき、ＩＥＥＥ１３９４ｂノード間のデータの伝播時間を固定値とすることができる。
【００８２】
たとえば、ＩＥＥＥ１３９４ｂノード間のケーブル長が最大９メートルのシステムにおいては、最大ケーブル長が４．５ｍのＩＥＥＥ１３９４−１９９５やＩＥＥＥ１３９４ａノードに対して、ホップ数は２倍と考える。このようにＩＥＥＥ１３９４ｂノード間のホップに対して暫定的に重みを付けることによって、１３９４混在ネットワークにおいても、ホップ数によってＧａｐ＿Ｃｏｕｎｔを求めることができる。このように、トポロジ構成を考慮にいれることによって、より精度の高い警告をおこなうことができる。
【００８３】
以上説明したように、実施例にかかる通信監視装置によれば、Ｇａｐ＿Ｃｏｕｎｔ設定ノードによって設定されたＧａｐ＿Ｃｏｕｎｔ値を監視し、不適切な値であるかどうかを判断し、不適切な値であった場合にはユーザに警告をおこなう。これにより、ネットワークが不安定な状態になるのを事前に防止することができる。
【００８４】
また、不適切なＧａｐ＿Ｃｏｕｎｔを設定したＧａｐ＿Ｃｏｕｎｔ設定ノードの機器名称や、Ｇａｐ＿Ｃｏｕｎｔ設定ノードが設定したＧａｐ＿Ｃｏｕｎｔが不適切な値となってしまう原因であるＩＥＥＥ１３９４ｂに対応する機器の名称を、警告の際に呈示する情報を含ませることによって、ユーザにどの機器が原因でバスが不安定になる可能性があるかを示すことができる。
【００８５】
以上説明したように、通信監視装置、通信監視方法、通信監視プログラムおよび記録媒体によれば、不適切な通信制御値が設定されるのを防止することができる。
【００８６】
なお、本実施の形態で説明した通信監視方法は、あらかじめ用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。
【図１】
0004252611.tif 000002
【図２】
0004252611.tif 000003
【図３】
0004252611.tif 000004
【図４】
0004252611.tif 000005
【図５】
0004252611.tif 000006
【図６】
0004252611.tif 000007
【図７】
0004252611.tif 000008
【図８】
0004252611.tif 000009
【図９】
0004252611.tif 000010
【図１０】
0004252611.tif 000011