WO2006103857A1

WO2006103857A1 - 通信監視装置、通信監視方法、通信監視プログラムおよび記録媒体

Info

Publication number: WO2006103857A1
Application number: PCT/JP2006/303568
Authority: WO
Inventors: Myrine Maekawa; Kinya Ono
Original assignee: Pioneer Corporation
Priority date: 2005-03-29
Filing date: 2006-02-27
Publication date: 2006-10-05
Also published as: EP1865663A1; US7724686B2; US20080198758A1; JP4252611B2; JPWO2006103857A1

Abstract

　通信監視装置（１００）は、ＩＥＥＥ１３９４シリアルバスを用いて複数の機器が接続されたネットワーク（１３０）を監視する。取得部（１１１）は、ネットワーク（１３０）における他の機器が決定または管理する通信制御値に関する情報を取得する。判断部（１１２）は、取得部（１１１）によって取得された通信制御値に関する情報に基づいて、通信制御値に関する情報がネットワーク（１３０）に適合しているか否かを判断する。通知部（１１３）は、判断部（１１１）による判断結果を通知する。

Description

明細書

通信監視装置、通信監視方法、通信監視プログラムおよび記録媒体技術分野

[0001] この発明は、ネットワークの通信状態を監視する通信監視装置、通信監視方法、通信監視プログラムおよび記録媒体に関する。ただし、この発明の利用は、上述した通信監視装置、通信監視方法、通信監視プログラムおよび記録媒体に限られない。背景技術

[0002] 従来、主にマルチメディアデータ転送のためのインターフェースとして、 IEEE1394 規格のシリアルバス（以下、 IEEE1394バスという）が用いられている。 IEEE1394ノスは、高速データ転送が可能であり、ホストとなる機器を必要とせず、機器の動作中においても接続 ·切断を自由におこなうことができるなどの特徴を有する。 IEEE139 4規格には、従来から用いられてきた IEEE1394— 1995、 IEEE1394a、および IE EE1394aを改良させた IEEE1394bが存在する。

[0003] IEEE1394規格では、接続されているいずれの機器 (ノード)も通信をおこなってはならないアイドル時間（Gap)があり、アイドル時間の元となる値を Gap— Countという。たとえば、あるノードから同じ 1394バスに接続されている他のノードにデータを送信した場合、受信側で正しくデータが受理された力どうかを確認するためにァクノリッジノケット (ACK)を送り返す必要がある。データを送信してから ACKが返ってくるまでの間、他のノードは通信の邪魔をしてはならず、ある一定時間待機しなければならない。

[0004] このときの待機時間を ACKnowledge— Gapといい、 Gap— Countの値を基準にして ACKnowledge— Gapを示す時間が決定される。 Gap— Count値は、バスのトポロジによって異なるものであり、バスのトポロジに変化が生じると、各ノードに対して Gap— Count値の再設定がおこなわれる。 Gap— Countの設定は、バス上でバスマネージャになったノード、また、バス上にバスマネージャが存在しない場合は IRM (Is ochronous Resource Managerリによつておこなわれる。以下、このよつに Gap _ Countの設定をおこなうノードを Gap— Count設定ノードという。 [0005] Gap— Count設定ノードは、 Gap— Count値を算出し、算出した Gap— Count値を各ノードに設定するパケット（PHY configuration packet)をブロードキャストする。各ノードは、受信した Gap— Count値を PHYレジスタに設定する。そして、各ノードがバスリセット信号を受信することによって、 PHYレジスタに設定した Gap— Count 値が有効になる。

[0006] Gap— Countの設定が適切におこなわれて!/、な!/、場合、たとえば、 Gap— Count 値が小さすぎる場合は、 ACKが返る前に他のノードが通信を始めてしまう可能性があるので、バスの動作が不安定になってしまう。一方、 Gap— Count値が大きすぎる場合は、必要以上に待機することになるので、機器のスループットが下がってしまう。このため、各ノードに設定された Gap— Countが等しい値であるかを確認することによって、 Gap— Countの設定が適切におこなわれたかを判断する技術が考案されている（たとえば、下記特許文献 1および 2参照。 )₀

[0007] 特許文献 1 :特開平 10— 285236号公報

特許文献 2 :特開平 11 331214号公報

発明の開示

発明が解決しょうとする課題

[0008] しかしながら、前述した先行技術によれば、すべてのノードに同じ Gap— Count値が設定されて、るかを確認することはできるものの、設定された Gap— Count値で、正常なデータ通信をおこなうことができるかは判断することができない。たとえば、 IE EE1394b準拠のノードからなるネットワークに IEEE1394— 1995、 IEEE1394a準拠のいずれかのノードが少なくとも一つ含まれるネットワーク（以下、 1394混在ネットワークという）において、 IEEE1394b以外のノードが Gap— Count設定ノードになつた場合、 IEEE1394— 1995や IEEE1394aバスのみに対応した Gap— Count算出方法が用いられる可能性がある。

[0009] ここで、 IEEE1394— 1995や IEEE1394aバスのみに対応した Gap— Count算出方法とは、ホップ数（二つのノード間の経路で使用したケーブルの数）による算出方法や、あら力じめ定数として宣言する方法などである。たとえば、ホップ数による算出方法は、バス上で最も長いパス (経路）のホップ数を求めて、規格に定められた表（以下、 Gap— Countテーブルと!/、う）力対応するホップ数の Gap— Countを参照する。

[0010] Gap— Countは、最も長いパスを使ってデータ伝送したときの伝搬時間から求められる。 IEEE1394— 1995や IEEE1394aはケーブルの長さが 4. 5mまでという制限があり、かつ、使用するケーブルの種類が限られている。このため、 1ホップでデータ伝送したときの伝搬時間を定数として定めることができる。そこで、ホップ数ごとに Ga p— Countを算出し、 Gap— Countテーブルを作成することができる。

[0011] Gap— Count設定ノードは、バスリセットが発生すると接続の中で最も長、パスのホップ数を調べ、そのホップ数に対応する Gap— Countを Gap— Countテーブルから参照し、各ノードに設定する。し力し、このテーブルは IEEE1394— 1995や IEEE1 394aノードのみがバス上に存在することが前提で作成されており、 IEEE1394bノードについては考慮されていない。このため、 1394混在ネットワークにおいて、適切な Gap— Countの設定をおこなうことができないという問題が一例として挙げられる。

[0012] また、 1394混在ネットワークにおいては、バス上に IEEE1394bノードも存在するため、「最も長いパス」 =「ホップ数の最も多いパス」であるとは限らない。仮に、偶然「最も長いパス」 =「ホップ数の最も多いパス」であったとしても、 Gap— Countテーブルは IEEE1394— 1995や IEEE1394aノードのみからなるパスを前提として作成されているため、パスの途中に IEEE1394bノードが存在した場合の Gap— Countとは異なる値となる可能性が高い。このように、 1394混在ネットワークにおいては、不正な Gap— Count値が設定される可能性があるという問題が一例として挙げられる。

[0013] また、このように不適切な Gap— Countが設定されたままでネットワークの使用を続けると、ネットワークの動作が不安定になったり、機器のスループットが下がってしまうという問題が一例として挙げられる。

[0014] この発明は、上述した従来技術による問題点を解消するため、不適切な通信制御値が設定されるのを防止することができる通信監視装置、通信監視方法、通信監視プログラムおよび記録媒体を提供することを目的とする。

課題を解決するための手段

[0015] 上述した課題を解決し、目的を達成するため、請求項 1の発明にかかる通信監視装置は、 IEEE1394シリアルバスを用いて複数の機器が接続されたネットワークを監視する通信監視装置であって、前記ネットワークにおける他の機器が決定または管理する通信制御値に関する情報を取得する取得手段と、前記取得手段によって取得された通信制御値に関する情報に基づいて、前記通信制御値に関する情報が前記ネットワークに適合して、る力否かを判断する判断手段と、前記判断手段による判断結果を通知する通知手段と、を備えることを特徴とする。

[0016] また、請求項 11の発明に力かる通信監視方法は、 IEEE 1394シリアルバスを用いて複数の機器が接続されたネットワークを監視する通信監視方法であって、前記ネットワークにおける他の機器が決定または管理する通信制御値に関する情報を取得する取得工程と、前記取得工程によって取得された通信制御値に関する情報に基づ、て、前記通信制御値に関する情報が前記ネットワークに適合している力否かを判断する判断工程と、前記判断工程による判断結果を通知する通知工程と、を含むことを特徴とする。

[0017] また、請求項 12の発明に力かる通信監視プログラムは、請求項 11に記載の通信監視方法をコンピュータに実行させることを特徴とする。

[0018] また、請求項 13の発明にかかる記録媒体は、請求項 12に記載の通信監視プログラムを記録したコンピュータに読み取り可能なことを特徴とする。

図面の簡単な説明

[0019] [図 1]図 1は、実施の形態にかかる通信監視装置の機能的構成を示すブロック図である。

[図 2]図 2は、通信監視装置の通信監視処理の手順を示すフローチャートである。

[図 3]図 3は、実施例にかかる通信監視装置が監視するネットワークの構成機器を示す図である。

[図 4]図 4は、図 3に示したネットワークの構成を模式的に示した図である。

[図 5]図 5は、 Gap— Count設定ノードがおこなう Gap— Count設定処理の手順を示すフローチャートである。

[図 6]図 6は、監視ノードがおこなう Gap— Countの監視処理の手順を示すフローチヤートである。 [図 7]図 7は、監視ノードがおこなう Gap— Countの監視処理の手順を示すフロヤートである。

[図 8]図 8は、ユーザへの警告を示す表示画面の一例を示す図である。

[図 9]図 9は、ユーザへの警告を示す表示画面の一例を示す図である。

[図 10]図 10は、ユーザへの警告を示す表示画面の一例を示す図である。

符号の説明

[0020] 100 通信監視装置

111 取得部

112 判断部

113 通知部

114 算出部

115 機器特定部

116 切断部

121 IEEE 1394bに：対応した機器

122 IEEE 1394bに：対応していない機器

130 ネットワーク

発明を実施するための最良の形態

[0021] 以下に添付図面を参照して、本発明にかかる通信監視装置、通信監視方法、通信監視プログラムおよび記録媒体の好適な実施の形態を詳細に説明する。

[0022] (実施の形態）

(通信監視装置 100の機能的構成）

図 1は、実施の形態にかかる通信監視装置の機能的構成を示すブロック図である。実施の形態にかかる通信監視装置 100は、 IEEE 1394シリアルバスを用いて複数の機器が接続されたネットワーク 130を監視する。ネットワーク 130は 1394混在ネットヮークであり、 IEEE 1394bに対応した機器 121および IEEE 1394bに対応して!/、な!/ヽ機器 122がそれぞれ少なくとも 1つずつ接続される。通信監視装置 100は、取得部 1 11、判断部 112、通知部 113、算出部 114、機器特定部 115、切断部 116によって構成される。 [0023] 取得部 111は、ネットワーク 130における他の機器が決定または管理する通信制御値に関する情報を取得する。通信制御値に関する情報とは、たとえば、ネットワーク 1 30における Gap— Count値や、 Gap— Count値の設定のために送信される PHYパケットの発行の有無や、 Gap— Count値が記述されて!、る Self— IDパケットの発行の有無、前記 Self— IDパケットの発行を促すための Pingパケット発行の有無、 Gap —Count設定ノードの機器情報（Gap— Count設定ノードが IEEE1394bに対応している機器である力否かの情報も含む)などである。また、通信制御値に関する情報には、通信制御値そのものを含むものとする。

[0024] 判断部 112は、取得部 111によって取得された通信制御値に関する情報に基づ、て、通信制御値に関する情報がネットワーク 130に適合している力否かを判断する。判断部 112は、たとえば、 IEEE1394bに対応していない機器 122によって通信制御値が決定された場合に、通信制御値に関する情報がネットワーク 130に適合しないと判断する。

[0025] または後述する算出部 114によって算出された通信制御値と、取得部 111によって取得された通信制御値に関する情報とを比較して、ネットワーク 130における他の機器が決定または管理する通信制御値に関する情報がネットワーク 130に適合しているカゝ否かを判断する。また、たとえば、特定の値が通信制御値として設定された場合には、通信制御値に関する情報がネットワーク 130に適合しないと判断することとしてちょい。

[0026] 通知部 113は、判断部 112による判断結果を通知する。通知部 113による通知は、たとえば、表示画面へのメッセージ表示やァニ入音声などである。また、ネットワーク 130に接続された他の機器に前述のような通知の出力をおこなわせるための制御信号を出力するものであってもよ、。

[0027] 算出部 114は、ネットワーク 130に適合した通信制御値を算出する。算出部 114は、たとえば、ネットワーク 130に接続された各機器に Pingパケットを送信し、送信した Pingパケットへの返答として各機器カゝら送信される Self— IDパケットを受信するまでの時間に基づいて、通信制御値を算出する。

[0028] 機器特定部 115は、判断部 112によって通信制御値に関する情報がネットワーク 1 30に適合しないと判断された場合に、その原因となる機器を特定する。機器特定部 115によって、原因となる機器が特定された場合、通知部 113は、機器特定部 115 によって特定された機器に関する情報を報知する。具体的には、たとえば、機器の名称や識別番号、これらの機器の取り外しを求めるメッセージを表示する。

[0029] 切断部 116は、機器特定部 115によって特定された機器とネットワーク 130との接続を切断する。切断部 116は、たとえば、機器特定部 115によって特定された機器に対して、 Remote command packetを送信し、他の機器と接続されているポートを停止させる。

[0030] (通信監視装置 100の通信監視処理）

図 2は、通信監視装置の通信監視処理の手順を示すフローチャートである。まず、取得部 111によって、ネットワーク 130における他の機器が決定または管理する通信制御値に関する情報を取得する (ステップ S201)。つぎに、算出部 114によって、ネットワーク 130に適合した通信制御値を算出する (ステップ S202)。そして、判断部 1 12によって、ステップ S201で取得した通信制御値に関する情報と、ステップ S202 で算出した通信制御値とを比較する (ステップ S203)。

[0031] 判断部 112は、ステップ S203でおこなった比較の結果から、ネットワーク 130における他の機器が決定または管理する通信制御値に関する情報がネットワーク 130に適合して、るかを判断する (ステップ S204)。ネットワーク 130に適合して、る場合は (ステップ S204 : Yes)、特に処理をおこなわずに本フローチャートによる処理を終了する。

[0032] 一方、ネットワーク 130に適合していない場合は (ステップ S204 :No)、機器特定部 115によって原因となる機器を特定する (ステップ S205)。そして、通知部 113によつて、ステップ S205で特定された機器に関する情報を報知する (ステップ S 206)。また、特定された機器とネットワーク 130との接続を切断して (ステップ S207)、本フローチャートによる処理を終了する。

[0033] 以上説明したように、実施の形態に力かる通信監視装置 100によれば、 IEEE139 4シリアルバスを用いて複数の機器が接続されるネットワーク 130において、設定された通信制御値に関する情報がネットワーク 130に適合しているかを判断することができる。通信制御値に関する情報がネットワーク 130における Gap— Count値である場合、ネットワーク 130が不安定となったり、スループットが低下するのを防止したりすることができる。

[0034] また、不正な値が通信制御値に設定された場合、または設定される可能性がある場合に、ユーザにその旨を通知することができる。さらに、通信制御値に関する情報がネットワーク 130に適合しないと判断された場合に、その原因となる機器を通知したり、ネットワーク 130との接続を切断したりすることによって、不正な通信制御値が設定されるのを防止することができる。

実施例

[0035] (通信監視装置の構成機器）

図 3は、実施例にかかる通信監視装置が監視するネットワークの構成機器を示す図である。実施例にかかる通信監視装置は、車内に設置された機器を接続する車内ネットワークを監視する。車内には、ナビゲーシヨン装置 301、カーステレオ 302、 ETC ユニット 303が設置されている。本実施例において、通信監視装置はナビゲーシヨン装置 301に設けられているものとする。また、通信監視装置が監視する通信制御値は Gap— Count値とする。

[0036] なお、本実施例にお!、ては、通信監視装置はナビゲーシヨン装置 301やカーステレオ 302などの車載機器をつなぐ車内ネットワークを監視するものとした力本発明の利用はこれに限るものではない。たとえば、家庭用電化製品どうしの接続や、車載装置と家電製品との接続にも用いることができる。

[0037] ナビゲーシヨン装置 301は、実施例に力かる通信監視装置を含み、車内ネットヮークにおける Gap— Count値を監視する。また、目的地までの経路を探索し、走行中に経路の誘導をおこなう。さらに、ナビゲーシヨン装置 301は、地図情報や周辺の施設情報などが記憶された記憶媒体を有しており、余った記憶領域に音楽データなどを蓄積することができる。

[0038] 図示した例では、ナビゲーシヨン装置 301の表示画面 301aには、車両後方の様子が表示されている。これは、車両の後部に取り付けられているノックカメラ（図示せず )によって撮影された映像を、表示画面 301aに表示しているものである。ユーザはバックカメラからの映像によって、後方の安全確認をおこなうことができる。なお、ナビゲーシヨン装置 301とバックカメラは、 IEEE1394バスによって接続されている。

[0039] カーステレオ 302は、 CDや MDなどに記録された音楽データを再生し、図示しないスピーカから音声出力させる。 ETCユニット 303は、 ETC情報の処理部、 ETC力ード揷入部およびアンテナを有し、 ETCシステムを用いた料金所における通行料金の授受に用いられる。

[0040] ナビゲーシヨン装置 301とカーステレオ 302は、相互に IEEE1394バスによって接続されている。これにより、カーステレオ 302において、ナビゲーシヨン装置 301の記憶領域に記憶された音楽データの再生をおこなうことができる。また、ナビゲーシヨン装置 301と ETCユニット 303も、同様に IEEE1394バスによって接続されている。これにより、ナビゲーシヨン装置 301において、 ETCユニット 303が搭載されていることを認識し、 ETC専用レーンなどを考慮した経路探索をおこなうことができる。

[0041] また、カーステレオ 302には、ポータブルオーディオプレイヤー 304が接続されている。ポータブルオーディオプレイヤー 304は、機器内部に搭載されたノヽードディスクやフラッシュメモリなどに記憶した音楽データを再生する。また、このようにカーステレォ 302に接続することによって、ポータブルオーディオプレイヤー 304に記憶された音楽データをカーステレオ 302で再生したり、ポータブルオーディオプレイヤー 304 で再生した音楽をカーステレオ 302のスピーカから出力することができる。

[0042] (ネットワーク構成）

図 4は、図 3に示したネットワークの構成を模式的に示した図である。ナビゲーシヨン装置 301は、カーステレオ 302、 ETCユニット 303、バックカメラとそれぞれ接続されている。また、カーステレオ 302は、ナビゲーシヨン装置 301の他、ポータブルオーディォプレイヤー 304と接続されて、る。

[0043] 以下において、各機器をネットワーク上におけるノードとおき、ナビゲーシヨン装置 3 01 ίまノード 401、カーステレ才 302ίまノード 402、 ETCユニット 303ίまノード 403、ポ一タブルオーディオプレイヤー 304はノード 404、バックカメラはノード 405とする。各ノード 401〜405は、それぞれ IEEE 1394バスによって接続されて!ヽる。

[0044] ここで、これらの機器は IEEE1394規格による接続をおこなっている力ノード 403 , 404、 405は IEEE1394— 1995又は IEEE1394aに準拠するノード（以下、 IEEE 1394— 1995 又は IEEE1394aノードという）である。一方、網掛けで示したノード 4 01, 402は、 IEEE1394bに準拠するノード（以下、 IEEE1394bノードと! /、う）である。 IEEE1394bは、 IEEE1394aを改良した規格であり、最大転送速度は 800Mbps (IEEE1394aは 400Mbps)、ケーブルには光ファイバ一、 Ethernet (登録商標）ケ一ブルなどを用いることができる（IEEE1394aはメタルケーブル)。また、最大接続距離は 100m (IEEE1394aは 4. 5m)となっている。

[0045] このように、 IEEE1394bは、 IEEE1394— 1995や IEEE1394aと異なる点が多く、 Gap— Countの算出も、 IEEE1394— 1995や IEEE1394aと同様におこなうことはできない。前述のように、 IEEE1394— 1995や IEEE1394aはケーブルの長さが 4. 5mまでという制限があり、かつ使用するケーブルの種類が限られているため、 1ホップでデータ伝送したときの伝搬時間をホップ数ごとに定数として定めている。

[0046] 一方で、 1394混在ネットワーク構成においては、ケーブルの長さや種類が異なるため、ホップ数によって Gap— Countを設定することはできない。この場合、 Gap— C ount設定ノードは、 Pingパケットを利用し、最長のパスにおけるデータの伝播時間を元に Gap— Countを算出する。

[0047] 具体的には、 Gap— Count設定ノードは、他のすべてのノードに対して Pingバケツトを送信する。各ノードは、 Gap— Count設定ノードからの Pingパケットを受けて、 Se If— IDパケットをブロードキャストする。 Gap— Count設定ノードは、 Pingパケットを送信してから、すべてのノードから Self— IDパケットを受信するまでの時間をもとに G ap— Countを設定する。

[0048] 図 4に示したようなネットワーク構成において、 Gap— Count設定ノードはネットヮークのトポロジに変化が生じるごとに変化する。このとき、 IEEE1394bに対応しないノードが Gap— Count設定ノードとなってしまった場合、 IEEE 1394bノードを考慮せずに Gap— Countを設定してしま!/、、不適切な Gap— Countのためネットワークが不安定になったり、ネットワークのスループットが低下してしまう場合がある。

[0049] これを防止するため、 Gap— Count設定ノードが設定する Gap— Countが適切に設定されているかを監視する監視ノード (通信監視装置)を置く。ここで、監視ノードは IEEE1394bに対応するノードもしくは前述した Pingパケットによる Gap— Count の算出をおこなうことができるノードである必要がある。本実施例では、 Gap— Count 設定ノードを IEEE1394aノードであるノード 404、監視ノードを IEEE1394bノードであるノード 401として説明する。

[0050] (Gap— Count設定ノードによる Gap— Count設定処理）

図 5は、 Gap— Count設定ノードがおこなう Gap— Count設定処理の手順を示すフローチャートである。まず、バスリセットが発生すると（ステップ S501 : Yes)、各ノードはバスリセット信号を受けて、 Self— IDパケットを送信し、 Gap— Count設定ノード (ノード 404)は、各ノードの Self— IDパケットを受信する（ステップ S502)。そして、 G ap— Count設定ノードは、バス上でトポロジが変化したかどうかを判断する (ステップ S503)。バス上のトポロジが変化すると（ステップ S503 : Yes)、 Gap— Count設定ノードは、変化後のトポロジに対応した Gap— Countの算出をおこなう（ステップ S504

) o

[0051] そして、算出した Gap— Countが各ノードに既に設定されている Gap— Countと等しいかを判断する（ステップ S505)。算出した Gap— Countが各ノードに既に設定されて、る Gap— Countと等し、場合は（ステップ S505： Yes)、 Gap— Countの再設定をおこなう必要がないため、本フローチャートによる処理を終了する。

[0052] 一方、算出した Gap— Countが各ノードに既に設定されている Gap— Countと異なっている場合は（ステップ S505 :No)、 Gap— Countの再設定をおこなうため、 Ga p— Count設定ノードは、各ノードに算出した Gap— Countを含んだ PHYパケットを送信する（ステップ S506)。各ノードは、送信された PHYパケットに含まれる Gap— C ountを PHYレジスタに設定する。そして、 Gap— Count設定ノードは再度バスリセット信号を送信し (ステップ S507)、本フローチャートによる処理を終了する。この再度のバスリセット信号によって、各ノードが設定した Gap— Countが有効になる。

[0053] 以上のような処理によって、 Gap— Count設定ノードはバスにトポロジの変化が発生するごとに Gap— Countの設定をおこなう。ステップ S504においておこなわれる G ap— Countの算出は、 Gap— Count設定ノードが対応する規格によっておこなわれる。すなわち、 IEEE1394aノードであるノード 404は、バス上に IEEE1394bノードが存在することを考慮せずに Gap— Countの算出をおこなってしまう。このため、監視ノードであるノード 401は、以下に示すような処理によって Gap— Countの監視をおこな!/、、不適切な Gap— Countが設定されるのを防止して!/、る。

[0054] (監視ノードによる Gap_Count監視処理）

図 6および図 7は、監視ノードがおこなう Gap— Countの監視処理の手順を示すフローチャートである。なお、監視ノードがおこなう監視処理は、 Gap— Count設定ノードが Gap— Countの設定をおこなった後におこなうのが望ましい。このため、図 6に示す処理は、 Gap— Count設定ノードが Gap— Countの設定をおこなつたかを監視する処理であり、図 7に示す処理は、 Gap— Count設定ノードが設定した Gap— Count が適切な値であるかを監視する処理である。

[0055] まず、監視ノード (ノード 401)は、バスリセット信号を受信したかを監視する (ステツプ S601)。バスリセット信号を受信すると（ステップ S601 : Yes)、バス上のトポロジが変化したか、または他のすべてのノードに設定された Gap— Countが不一致であるかを判断する (ステップ S602)。

[0056] トポロジが変化した、または他のすべてのノードに設定された Gap— Countが不一致である場合は (ステップ S602 : Yes)、再度他のすべてのノードに設定された Gap —Countがー致しているかを確認する（ステップ S603)。一方、トポロジが変化せず、かつ他のすべてのノードに設定された Gap— Countがー致する（不一致ではない）場合は（ステップ S602 :No)、図 7の Aに移行して、本フローチャートによる処理を終了する（図 7参照)。

[0057] つぎに、ステップ S603において、他のすべてのノードに設定された Gap— Count がー致する場合は (ステップ S603 : Yes)、所定の時間内にバスリセット信号を受信したかを判断する（ステップ S604)。これは、 Gap— Countの再設定がおこなわれるかが不明な状態なため、所定の時間待機しているものである。バスリセットが発生した場合であっても、たとえば、 Gap— Count設定ノード力バスリセット後算出した Gap— C ount力各ノードに既に設定されている Gap— Countと等しい場合には、 Gap— Co untの再設定はおこなわれな!/、（図 5のステップ S504参照）。

[0058] 所定の時間内にバスリセット信号を受信した場合は (ステップ S604 : Yes)、 Gap— Countの再設定がおこなわれたとして、図 7の Bに移行する。一方、所定の時間内にバスリセット信号を受信しなかった場合は（ステップ S604 : No)、 Gap— Countの再設定はおこなわれなかったものとして、図 7の Aに移行して、本フローチャートによる処理を終了する（図 7参照)。ここで、バスリセット信号の受信を待機している時間は任意であるが (ステップ S604の「所定の時間」）、たとえば、バスリセット信号の受信から 1秒とすることができる。

[0059] IEEE1394の規格上、 Gap— Countがいつまでに決定されていなければならないとの規定は明記されていない。しかし、 Gap_Countの設定は、機器どうしのコネクシヨンを確立する際に使用する overheadIDに関係している。バスリセットが発生した場合、ノスリセット発生前のコネクションを継続させるためには、ノスリセット発生後 1秒以内にコネクションを再確立しなくてはならない旨が規定されている。このため、バスリセット発生後 1秒以内には Gap— Countが決定されていることが予想される。この予想を元に、ステップ S604において待機する時間を 1秒と設定する。

[0060] また、たとえば、すべてのノードの Gap— Countがー致して!/、ると判断したのち（ステツプ S603 :Yes)、いずれかのノードが送信した SelfIDパケットを受信した場合には、すべてのノードからの Self— IDパケットを受信するまで待機したのちに図 7の Bに移行するようにしてもよい。先述のように、他のすべてのノードに設定された Gap— C ountがー致する場合は、 Gap— Countの再設定がおこなわれるかが不明である。このような状態で監視ノードが Self— IDパケットを受信した場合、 Gap— Count設定ノードが Pingパケットを用いて Gap— Countの算出をおこなおうとしていることが予想される。

[0061] Gap— Countの算出処理のうち、最も処理に時間を要するのは Pingパケットの送信および Self— IDパケットの受信処理である。このため、すべてのノードから Self— I Dパケットの送信がおこなわれたことが確認できれば、 Gap— Countの算出処理が間もなく完了することを予想することができ、ステップ S604のように所定の時間待つことなく監視処理を開始することができる。

[0062] さらに、 Gap— Countの算出には、最低限リーフノード (先端のノード）とブランチノード (枝分かれしているノード)までの応答時間がわかればよい。このため、監視ノードにおいても、すべてのリーフノードおよびブランチノードから Self— IDパケットを受信したことを確認できれば、 Gap— Countの算出処理が間もなく完了することを予想することができる。

[0063] つぎに、ステップ S603において、他のすべてのノードに設定された Gap— Count がー致しない場合は (ステップ S603 : No)、 2度目のバスリセット信号の受信を待って待機する（ステップ S605 :Noのループ）。他のすべてのノードに設定された Gap— C ountがー致しない場合は、必ず Gap— Countの再設定がおこなわれるため、 PHY パケットによって設定された Gap— Countを有効にするためのバスリセット信号が送信されるためである。

[0064] そして、 2度目のバスリセット信号を受信すると (ステップ S605： Yes)、バス上のトポロジに変化がなぐかつ他のすべてのノードに設定された Gap— Countがー致するかを判断する（ステップ S606)。バス上のトポロジに変化がなぐかつ他のすべてのノードに設定された Gap— Countがー致する場合は（ステップ S606： Yes)、ステップ S 605で受信したバスリセット信号は、 Gap— Countを有効にするためのバスリセットであつたとして、図 7の Bに移行する。

[0065] 一方、バス上のトポロジに変化があった、または他のすべてのノードに設定された G ap— Countがー致しな!/、場合は（ステップ S606： No)、ステップ S605で受信したバスリセットは Gap— Countを有効にするためのバスリセットではなかったとしてステップ S603に戻って、以下の処理を繰り返す。監視ノードは、以上のような処理によって、 Gap— Count設定ノードが Gap— Countの設定をおこなったことを確認し、図 7に示す処理に移行する。

[0066] つぎに、図 7に示す処理（Gap— Count設定ノードが設定した Gap— Countが適切な値であるかを監視する処理）について説明する。まず、監視ノードは、 Observe — Gap— Countを算出する（ステップ S701)。この Observe— Gap— Countは、監視ノードが Gap— Count設定ノードの監視用に算出する値であり、 1394混在ネットワークにおいても正しく Gap— Countが求まる方法 (たとえば、 Pingパケットを利用した方法）によって算出される。

[0067] つぎに、監視ノードは、算出した Observe— Gap— Countと、他のノードに設定されている Gap— Countとを比較する（ステップ S 702)。そして、他のノードに設定されている Gap— Countが明らかに不正かを判断する（ステップ S703)。ここで、明らかに不正と判断する基準は特に限定しないが、たとえば、算出した Observe— Gap—

Countとの誤差が一定以上ある場合や、 Gap— Countが Observe— Gap— Count より小さい場合などが想定される。

[0068] Gap— Countが明らかに不正である場合は（ステップ S703： Yes)、ユーザに警告をおこない（ステップ S704)、本フローチャートによる処理を終了する。一方、 Gap—

Countが不正とは認められない場合は (ステップ S 703 : No)、警告をおこなわず、本フローチャートによる処理を終了する。

[0069] (警告の表示例）

図 8〜10は、ユーザへの警告を示す表示画面の一例である。図 8においては、監視ノードであるノード 401 (ナビゲーシヨン装置 301)の表示画面 301aに、「ポータブルオーディオプレイヤーを接続しているとネットワークが不安定となる可能性があります」との警告表示 801が表示されている。 Gap— Count設定ノードであるノード 404 ( ポータブルオーディオプレイヤー 304)は、 IEEE1394aノードであるため、 1394混在ネットワークには対応することができない。このため、実際に必要な Gap— Countより小さ、値を設定してしま、、ネットワークが不安定となる可能性があることを示してヽる。

[0070] 図 9においては、「ナビゲーシヨン装置やカーステレオが原因でネットワークが不安定になる可能性があります」との警告表示 901が表示画面 301aに表示されている。図 8の例とは異なり、 IEEE1394bノードであるノード 401 (ナビゲーシヨン装置 301) やノード 402 (カーステレオ 302)の機器名を通知することによって、これらの機器を取り外し、 IEEE1394— 1995や IEEE1394aノードのみでネットワークを構成させることができる。

[0071] 図 10においては、「このままの接続状態では、同時に使用できる機器が通常より少なくなる可能性があります。原因と思われる機器は、ポータブルオーディオプレイヤーです」との警告表示 1001が表示されている。図 8および図 9は、設定された Gap— C ountが小さすぎる場合の例を示した力図 10は設定された Gap— Countが大きすぎる場合の警告表示の例である。

[0072] 設定された Gap— Countが大きすぎる場合、ネットワークが不安定となることはないため、機器の取り外しは必要ではない。し力し、ネットワークのスループットが低下してしまう可能性があり、このことをユーザに警告するものである。なお、図示した例では G ap— Count設定ノードであるノード 404の機器名（ポータブルオーディオプレイヤー 304)を表示させることとした力 IEEE1394bノードの機器名を表示させることとしてちょい。

[0073] また、このように表示画面 301aに文字による警告表示をする他にも、アニメや図などでの警告や、警告音'音楽など音声出力による警告、警告灯の点灯などであってもよい。また、監視ノードの機器自体が警告をおこなうのではなぐ他の機器に前述のような警告をおこなわせるように制御信号を出力してもよい。たとえば、監視ノードであるナビゲーシヨン装置 301が、カーステレオ 302のスピーカから警告用の音声を音声出力させるようにしてちょい。

[0074] さらに、不正な Gap— Countを設定する可能性のあるノードが Gap— Count設定ノードとなった場合に、そのノードをネットワーク力切り離すようにしてもよい。 IEEE 13 94においては、 Remote command packetを送信することによって、所望のノードのポートを停止することができる。監視ノードは、不正な Gap— Countを設定する可能性のあるノードが Gap— Count設定ノードとなった場合に、 Remote command packetを送信し、そのノードと他の機器とが接続されているポートを停止させる。これにより、停止させたポートを介した通信ができなくなり、不正な Gap— Countを設定する可能性のあるノードをネットワーク力も切り離すことができる。

[0075] たとえば、図 4に示したネットワーク構成において、 Gap— Count設定ノードが IEE E1394aノードであるノード 404となった場合、監視ノードであるノード 401は、ノード 404の有するポートのうち、ノード 401と接続されているポートを停止する。これにより、ノード 404の先に接続されているノードとは通信ができなくなるものの、ノード 401、 402、 403、 405の間であらたな Gap— Count設定ノードが設定され、不正な Gap— Countが設定されるのを防ぐことができる。

[0076] なお、監視ノードとなり得るノードがネットワーク上に複数存在する場合、 1台のみが監視ノードとなるように管理する。たとえば、監視ノードとなり得るノードは、監視処理を始める前に他のノードに対して監視処理開始を宣言し、最も早く監視処理開始を宣言したノードが監視ノードとなるなどの方法がある。また、各ノードに機器識別子を付して、機器識別子によって監視ノードを設定したり、最新の機器を監視ノードに設定するなどの方法であってもよ、。

[0077] また、監視ノードの処理負担を軽減することによって、より短時間でユーザに警告をおこなうようにしてもよい。前述した実施例において、監視ノードは、 Gap— Count設定ノードが Gap— Countの設定をおこなつたかを監視し（図 6参照）、 Gap— Count 設定ノードが設定した Gap— Countが適切な値であるかを監視した（図 7参照）。このような処理に代えて、以下のような処理をおこなうようにしてもょ、。

[0078] たとえば、 IEEE1394bに対応していない IEEE1394— 1995や IEEE1394aノードが Gap— Count設定ノードとなった場合、 Gap— Countは、ノスのホップ数をもとにあらかじめ計算された Gap— Count値の表に基づいて設定される。もしくは、 IEE E1394a規格における最大のホップ数である 16のときの Gap— Count値である「43」や、 Gap— Countは 6ビット長の値であるので、 2ビット長で表現できる最大値である 6 3に設定される。

[0079] このような値が Gap— Countに設定された場合、監視ノードは、 1394混在ネットヮークにおいては不適切な値であるとして、ユーザに警告をおこなう。これにより、 Obse rve— Gap— Countを算出したり、他のノードに設定された Gap— Countとの比較をしたりする必要がなぐ監視ノードの処理負担を軽減させ、より短時間のうちにユーザに警告をおこなうことができる。

[0080] また、監視ノードによって、バスリセットの発生後、 Gap— Countの設定がおこなわれる前に他のノード力 Pingパケットの発行があつたかどうかを監視するようにしてもよい。他のノードから Pingパケットの発行がない場合、 Gap— Countの算出に Ping を使用していないこととなり、 1394混在ネットワークにおいては不適切な値が設定されたこととなる。これをユーザに警告することによって、監視ノードの処理負担を軽減させ、より短時間のうちにユーザに警告をおこなうことができる。

[0081] 上述した方法で Gap— Countの設定が適切であるかを判断する場合、バス上のノード数とトポロジを考慮することによって、より適切な場合に警告をおこなうことができる。たとえば、車載機器をつなぐネットワーク（以下、車載ネットワークという）は、閉じたネットワークとなることが多ぐ最大ケープノレ長があら力じめ定まったシステム構成とできる場合がある。このとき、 IEEE1394bノード間のデータの伝播時間を固定値とすることがでさる。

[0082] たとえば、 IEEE1394bノード間のケーブル長が最大 9メートルのシステムにおいては、最大ケーブル長が 4. 5mの IEEE1394— 1995や IEEE1394aノードに対して、ホップ数は 2倍と考える。このように IEEE1394bノード間のホップに対して暫定的に重みを付けることによって、 1394混在ネットワークにおいても、ホップ数によって Gap —Countを求めることができる。このように、トポロジ構成を考慮にいれることによって、より精度の高い警告をおこなうことができる。

[0083] 以上説明したように、実施例にかかる通信監視装置によれば、 Gap— Count設定ノードによって設定された Gap— Count値を監視し、不適切な値であるかどうかを判断し、不適切な値であった場合にはユーザに警告をおこなう。これにより、ネットヮークが不安定な状態になるのを事前に防止することができる。

[0084] また、不適切な Gap— Countを設定した Gap— Count設定ノードの機器名称や、 Gap— Count設定ノードが設定した Gap— Countが不適切な値となってしまう原因である IEEE1394bに対応する機器の名称を、警告の際に呈示する情報を含ませることによって、ユーザにどの機器が原因でバスが不安定になる可能性があるかを示すことができる。

[0085] 以上説明したように、通信監視装置、通信監視方法、通信監視プログラムおよび記録媒体によれば、不適切な通信制御値が設定されるのを防止することができる。

[0086] なお、本実施の形態で説明した通信監視方法は、あら力じめ用意されたプログラムをパーソナル.コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、 C D— ROM、 MO、 DVD等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体力読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。

Claims

請求の範囲

[1] IEEE1394シリアルバスを用いて複数の機器が接続されたネットワークを監視する通信監視装置であって、

前記ネットワークにおける他の機器が決定または管理する通信制御値に関する情報を取得する取得手段と、

前記取得手段によって取得された通信制御値に関する情報に基づ、て、前記通信制御値に関する情報が前記ネットワークに適合している力否かを判断する判断手段と、

前記判断手段による判断結果を通知する通知手段と、

を備えることを特徴とする通信監視装置。

[2] 前記ネットワークに適合した前記通信制御値を算出する算出手段を備え、

前記判断手段は、前記算出手段によって算出された前記通信制御値と、前記取得手段によって取得された前記通信制御値に関する情報とを比較して、前記判断をおこなうことを特徴とする請求項 1に記載の通信監視装置。

[3] 前記取得手段は、前記通信制御値に関する情報として前記ネットワークにおける G ap— Count値を取得することを特徴とする請求項 1または 2に記載の通信監視装置

[4] 前記算出手段は、前記ネットワークに接続された各機器に Pingパケットを送信し、送信した前記 Pingパケットへの返答として前記各機器力も送信される Self— IDパケットを受信するまでの時間に基づいて、前記通信制御値を算出することを特徴とする請求項 2に記載の通信監視装置。

[5] 前記ネットワークは、 IEEE 1394bに対応した機器および IEEE 1394bに対応して

V、な、機器がそれぞれ少なくとも 1つずつ接続され、

前記判断手段は、前記 IEEE1394bに対応して、な、機器が前記通信制御値を決定する機器になった場合に、前記通信制御値に関する情報が前記ネットワークに適合しな!ヽと判断することを特徴とする請求項 1に記載の通信監視装置。

[6] 前記判断手段は、前記ネットワーク上の特定のポートに接続された機器が通信制御値を決定する機器になった場合に、前記通信制御値に関する情報が前記ネットヮークに適合しないと判断することを特徴とする請求項 1に記載の通信監視装置。

[7] 前記取得手段は、前記通信制御値に関する情報として前記ネットワークにおける G ap— Count値を決定する機器に関する情報を取得することを特徴とする請求項 1に記載の通信監視装置。

[8] 前記取得手段は、前記 Gap— Count値を決定する機器に関する情報として、前記ネットワークに接続された機器を識別する機器識別情報を取得することを特徴とする請求項 7に記載の通信監視装置。

[9] 前記判断手段によって前記通信制御値に関する情報が前記ネットワークに適合しないと判断された場合に、その原因となる機器を特定する機器特定手段を備え、前記通知手段は、前記機器特定手段によって特定された機器に関する情報を通知することを特徴とする請求項 1に記載の通信監視装置。

[10] 前記判断手段によって前記通信制御値に関する情報が前記ネットワークに適合しないと判断された場合に、その原因となる機器を特定する機器特定手段と、前記機器特定手段によって特定された機器と前記ネットワークとの接続を切断する切断手段と、

を備えることを特徴とする請求項 1に記載の通信監視装置。

[11] IEEE1394シリアルバスを用いて複数の機器が接続されたネットワークを監視する通信監視方法であって、

前記ネットワークにおける他の機器が決定または管理する通信制御値に関する情報を取得する取得工程と、

前記取得工程によって取得された通信制御値に関する情報に基づ、て、前記通信制御値に関する情報が前記ネットワークに適合している力否かを判断する判断ェ程と、

前記判断工程による判断結果を通知する通知工程と、

を含むことを特徴とする通信監視方法。

[12] 請求項 11に記載の通信監視方法をコンピュータに実行させることを特徴とする通信監視プログラム。

[13] 請求項 12に記載の通信監視プログラムを記録したコンピュータに読み取り可能な記録媒体。