JP5040792B2 - マスタ・スレーブ同期通信方法および同期通信システム。 - Google Patents

Description

本発明は、ネットワークのアイソクロナス通信を使用したマスタ・スレーブ同期通信方法および同期通信システムに関する。

一般に製造装置では、ＰＬＣやパソコンなどの制御機器をマスタ機器として、複数台のセンサ、リレー、モータなどのスレーブ機器が周期的にマスタ機器と制御データの交換を行う。制御データの交換は定周期で行われるため、帯域が保証された通信手段が採用される。中でも、工作機械やマウンタなどのモーション制御システムでは、マスタ機器であるモーションコントローラが、通信を介してスレーブ機器と制御ループを組むため、揺らぎのない通信周期での制御データの交換が実現可能な同期通信手段が要求される。

帯域保証のある、高速な汎用ネットワークの一つに、パソコンやＡＶ機器などで一般的なＩＥＥＥ１３９４がある。ＩＥＥＥ１３９４には、アイソクロナス・リソース・マネージャ(以降、ＩＲＭ)により、帯域およびチャネル(以下、両方を合わせて、アイソクロナス・リソースと呼ぶ)が管理されるアイソクロナス通信があり、１２５μsのアイソクロナスサイクル毎にアイソクロナス・パケットの送信を行うことができる。
ＩＥＥＥ１３９４のアイソクロナス通信を応用して同期通信を行う例としてアイソクロナスサイクルの整数倍を制御周期として、制御周期毎に、マスタ機器が制御対象のスレーブ機器と順に制御データの授受を行うことで、マスタ機器とスレーブ機器の同期通信システムが構築できるようにする技術が開示されている（特許文献１参照）。

ところで、ＩＥＥＥ１３９４には接続された機器を動作中のまま抜き差しできるホットプラグ機能がある。機器の抜き差しがあるとバスリセットと呼ばれるＩＥＥＥ１３９４ネットワークの初期化処理が実行されるが、この処理はネットワーク構成確定後のアイソクロナス通信中でも、機器の抜き差しがあると例外なく実行される。この処理が起動されるとアイソクロナス通信は停止する。
製造装置の場合、稼動中に機器構成は変更しないため、バスリセットを伴うホットプラグ機能は必要ないが、振動によるコネクタの接触不良でネットワーク構成が変化したと判断されバスリセットが発生してしまう場合がある。バスリセットが発生すると前述通り通信停止するだけでなく復旧にはアイソクロナス・リソースを取得し直す必要があり、アイソクロナス通信が復旧するまでの間、マスタ機器はスレーブ機器を制御不能となり、製造装置としては致命的な問題となりえる。

以下に、アイソクロナス通信前のアイソクロナス・リソース取得処理について説明する。この処理はバスリセット後のアイソクロナス通信復旧時にも同じ手順が必要である。
アイソクロナス通信に関する資源（アイソクロナス・リソース）の管理は、ＩＲＭが行っており、アイソクロナス通信の資源であるチャンネルと帯域の管理を行っている。
ＩＥＥＥ１３９４規格（非特許文献１参照）によれば、アイソクロナス通信対応ノードはＩＲＭに対して帯域幅とチャンネル（ｃｈａｎｎｅｌ）の割当てを要求して獲得し、データ送信時に調停（アービトレーション）を行い、バス使用の権利を獲得したノードがアイソクロナスパケットを送信するようになっている。

図１６に従来の方法を実施するＩＥＥＥ１３９４機器の構成を示す。図１６において、１は機器（ＩＲＭ）、２は機器、３はＩＥＥＥ１３９４ケーブル、１１は２１はＣＰＵ、１２，２２はＩＥＥＥ１３９４のＬｉｎｋチップ、１３，２３はＰｈｙチップ、１４はＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタ、１５はＣＨＡＮＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタ、２４はアイソクロナス・リソース記憶部である。
機器１（ＩＲＭ）には、チャンネルを管理するＣＨＡＮＮＥＬ＿ＡＶＡＩＬＡＢＬＥレジスタ１４と、バスバンド幅を管理するＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタ１５がある（以下では、総称してアイソクロナス・リソース・レジスタと呼ぶ）。機器１（ＩＲＭ）以外の機器は、アイソクロナス通信を行うに先立って、上記のアイソクロナス・リソース・レジスタにアクセスし、バス使用の権利を獲得する。
ＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタ１４は、シリアルバス依存アドレス空間の始まりからオフセット２２０ｈにマップされ、ＣＨＡＮＮＥＬ＿ＡＶＡＩＬＡＢＬＥレジスタ１５はオフセット２２４ｈにマップされている。

図１７−ａに、ＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタ１４のフォーマットを、図１７−ｂにＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタ１５のフォーマットを示す。
ＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタのｂｗ＿ｒｅｍａｉｎｉｎｇフィールドは、現在割当てに使うことのできるアイソクロナス通信の帯域幅の量を表している。この帯域幅の量は帯域割当て単位と呼ばれる時間によって表され、１単位はＳ１６００（１６００Ｍｂｐｓ）のデータレートで１ｑｕａｄｌｅｔ（＝３２ビット）のデータを送信するのに要する時間（約２０ｎｓ）に相当する。初期値である４９１５は１００μｓになる。したがって、ＩＥＥＥ１３９４機器がＩＲＭにアクセスして帯域を取得するたびに、最大４９１５から取得された帯域の分だけ減っていくことになる。

また、ＣＨＡＮＮＥＬ＿ＡＶＡＩＬＡＢＬＥレジスタ（全６４ビット）は、一つのビットが一つのチャンネル番号に対応しており、ｃｈ０〜ｃｈ６３までを割当てることができる。初期状態では全てのビットが１になっており、ＩＥＥＥ１３９４機器がチャンネルを取得する度に、そのチャンネル番号に相当するビットがゼロになる。
機器１（ＩＲＭ）以外のＩＥＥＥ１３９４機器が機器１（ＩＲＭ）のアイソクロナス・リソースを取得する際にはロックトランザクションと呼ばれる方式で行われる。

図１８に従来のＩＥＥＥ１３９４機器間の通信処理シーケンス図を示す。
はじめにステップ１８０１においてＩＥＥＥ１３９４ネットワークでバスリセットが発生すると、ＩＥＥＥ１３９４ネットワークの初期化が行われ、ステップ１８０２において各機器は自己識別パケットを発行し、各ノードにノードＩＤが割当てられる。たとえば、機器１（ＩＲＭ）のノードＩＤが１、機器２のノードＩＤが０に決定したとする（ステップ１８０３〜１８０４）。

まず機器２が帯域を取得する場合、ステップ１８０５において、機器１（ＩＲＭ）のＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタ１４の値を読み出したあと、ロックトランザクションの一つであるＬｏｃｋＲｅｑｕｓｔパケットのａｒｇ＿ｖａｌｕｅに読み出した値をセットし、希望の帯域幅だけ減らした値をｄａｔａ＿ｖａｌｕｅにセットし、拡張トランザクションコードにｃｏｍｐａｒｅ＿ｓｗａｐを指定して機器１（ＩＲＭ）に対して送信する（ステップ１８０６）。機器１（ＩＲＭ）からのＬｏｃｋ応答のｒｃｏｄｅがｒｅｓｐ＿ｃｏｍｐｌｅｔｅであれば帯域幅の獲得に成功したことになる。帯域を獲得した機器２は、アイソクロナス・リソース記憶部２４に帯域情報を格納し（ステップ１８０７）、アイソクロナス通信時にはこのアイソクロナス・リソース記憶部２４を参照してアイソクロナスパケットを送信する。

ただし、あるノードがＬｏｃｋＲｅｑｕｅｓｔを送る前に他のノードがＬｏｃｋＲｅｑｕｅｓｔにより機器１（ＩＲＭ）のアイソクロナス・リソース・レジスタの値を変えてしまった場合、あとから送信されたＬｏｃｋＲｅｑｕｅｓｔのａｒｇ＿ｖａｌｕｅと機器１（ＩＲＭ）のレジスタ値が一致しなくなるため、機器１（ＩＲＭ）からｒｃｏｄｅがｒｅｓｐ＿ｃｏｍｐｌｅｔｅ以外の応答が返る。この場合は、応答データにｏｌｄ＿ｖａｌｕｅとしてレジスタの現在値が格納されているため、ｏｌｄ＿ｖａｌｕｅをａｒｇ＿ｖａｌｕｅに設定しなおして再度ＬｏｃｋＲｅｑｕｓｔを実行する。以上のような手順をとるため、同じアイソクロナス・リソースを複数のノードが重複して獲得するようなことは起こらない。機器２がチャンネルを取得する場合も同様に行う（ステップ１８０８〜１８１０）。

以上のようにバスリセットが発生すると、上記の処理が発生するため、アイソクロナス通信の再開には時間がかかる。また、前述のとおり、アイソクロナス・リソースの取得には少なくともアイソクロナス・リソース・レジスタの値を読み出す処理と、そしてＬｏｃｋそして、ＬｏｃｋＲｅｑｕｅｓｔによりレジスタを書き換える処理の計２回の動作が必要となり、ＬｏｃｋＲｅｑｕｅｓｔが複数のノードから同時に行われた場合、先にＩＲＭに受け付けられたノードの要求により現在値が更新されるため、後からＩＲＭに受け付けられたノードの要求は失敗する。失敗したノードは再度同じ処理を繰り返す必要があり、その分処理時間は長くなる。

このような問題点を解決するために特許文献２ではＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタとＣＨＡＮＮＥＬ＿ＡＶＡＩＬＡＢＬＥレジスタを読み出す処理を省略できるような手段を採っている。具体的には、初めにアイソクロナス・リソースのレジスタを読み出すことなく、ａｒｇ＿ｖａｌｕｅ予想値を指定したＬｏｃｋリクエストをＩＲＭに送り、失敗した場合は、Ｌｏｃｋ応答に含まれるｏｌｄ＿ｖａｌｕｅがレジスタの現在値となっていることから、その値をａｒｇ＿ｖａｌｕｅとして再度Ｌｏｃｋリクエストを行う、といった手順でアイソクロナス・リソースの取得を行っている。

また、アイソクロナス通信中にバスリセットが起こったとき、アイソクロナスパケットが帯域をオーバーしたり、同じチャンネルが重複するなどが発生し受信側の機器が想定外のパケットを受け取ってしまうことを防ぐ方法として特許文献３がある。
特許文献３では、バスリセット前と後での接続情報の比較やそのバスリセットの種類の判定を行い、アイソクロナス通信再開の可否を判断する。たとえば接続ノード数の変化量が大きい場合や、バスリセットがロングバスリセットの場合は直ちにアイソクロナス通信再開を停止し、上記のような異常な状態の発生を未然に防ぐといったことを行っている。
IEEE Standard for a High Performance Serial Bus(IEEE Std 1394-1995) 特開２００５−２２９１４２号公報（図２、３） 特願２０００−６１９１７６（特ＷＯ２０００／７０８４１） 特開２００３−１８８８９０号公報（図１）

ＩＥＥＥ１３９４通信によりマスタ機器が多数のスレーブ動作を制御するような、転送帯域だけでなく指令パケットの送信タイミングの保証も必要なシステムの場合、特許文献２，３だけでは不十分な点が出てくる。
まず、特許文献２の発明では、レジスタの読み出し処理は省略できてもＬｏｃｋリクエストは全ノードそれぞれが必ず行う手順となっており、アイソクロナス・リソース取得の競合が起こるたびにＬｏｃｋリクエストのリトライが必要なため、接続軸数が増えれば増えるほどアイソクロナス・リソース取得処理に費やす時間は増大する。

このような状況でアイソクロナス通信中にバスリセットが発生した場合、アイソクロナス通信を再開するにはアイソクロナス・リソース取得処理を繰り返さなければならないが、再開できる状態になるまでマスタ機器はスレーブ機器を制御することができず、かつ、スレーブ機器の状態も知ることができなくなる。このような制御不能状態が長く続くとシステムに致命的な問題を発生させる可能性がある。また、上記ＩＥＥＥ１３９４ネットワークを適用した製造システムでは、各機器の接続構成は固定されていて、ノード数も変化しないため、バスリセットが行われるたびにアイソクロナス・リソースの割当てを変更する必要は無い。従って、製造システムでは、バスリセットの度に各ノードがアイソクロナス・リソースを取得する処理は無駄であり、このような処理を省くことのできるシステムが望ましい。

また、特許文献３では、バスリセット前と後での接続情報の比較結果やそのバスリセットの長さの判断材料としてアイソクロナス通信再開の可否を判断することにより、受信側の機器が、アイソクロナス・リソースが矛盾した想定外のパケットを受け取ってしまうことを防いでいるが、指令パケットの送信タイミングの保証も必要なシステムの場合、アイソクロナス・リソース情報は正しくてもバスリセットの影響でマスタ機器からの指令パケットを正しいタイミングで受信できず、誤動作してしまう問題がある。この問題を図１９を用いて説明する。

図１９は従来のＩＥＥＥ１３９４アイソクロナス通信における通信タイミングを示す図である。１９０１はマスタ機器送信ＦＩＦＯ、１９０２は伝送路、１９０３はスレーブ機器、１９０４は指令パケットである。
図１９の通信タイミング図に示すように、指令パケット１４０４のｍ＋１番目のデータをマスタ機器送信ＦＩＦＯ１９０１から伝送路１９０２に出す際にバスリセットが起こると、ｍ＋１番目の指令パケット１９０４は伝送路１９０２に出せなくなりマスタ機器送信ＦＩＦＯ１９０１に残された指令パケットがバスリセットが治まったあとの制御周期で伝送路１９０２に出されてしまう場合がある。図１９ではマスタ機器がバスリセットを検出して指令パケット作成（ｍ＋２番目、ｍ＋３番目）を一時中止した場合を示している。
マスタ機器が意図しないタイミングで指令パケット（ｍ＋１番目）がスレーブ機器１９０３に渡されてしまうため、スレーブ機器１９０３において誤動作が起こる可能性がある。

本発明は以上のような問題点に鑑みてなされたものであり、製造システムにおいて、バスリセットが発生しても速やかにスレーブ機器の制御を継続できるようにするために、アイソクロナス・リソース取得のための時間を短縮し、マスタ機器が意図した通りのタイミングで指令パケットを出力できるような方法を提供することを目的とする。

上記問題を解決するため、本発明は、次のようにしたのである。
請求項１に記載の発明は、１局のマスタ機器と１局以上のスレーブ機器がネットワーク上に接続され、一定時間の制御周期に同期して、前記マスタ機器と前記スレーブ機器がアイソクロナス通信を使用して通信データを授受するマスタ・スレーブ同期通信方法において、
前記アイソクロナス通信中にバスリセットが発生した場合、
前記マスタ機器と前記スレーブ機器のうち、いずれか１局が備えるアイソクロナス・リソース・マネージャは前記ネットワーク上に接続された機器の数よりなる接続情報が前記バスリセットが発生する前のものから変化していないことを確認したならば、前記接続情報に変化がない旨を他の機器にブロードキャストで通知し、
その後、前記接続情報に変化がない旨を通知された全ての機器は、前記バスリセットが発生する前に取得して自機器にそれぞれ記憶していたアイソクロナス・リソースに従って前記アイソクロナス通信を再開することを特徴としたものである。

請求項２に記載の発明は、請求項１に記載の発明において、前記アイソクロナス・リソース・マネージャは、前記他の機器に通知するとともに、記憶していた前記他の機器の各々のアイソクロナス・リソースを前記他の機器の各々に送信することを特徴としたものである。

請求項３に記載の発明は、請求項１〜２のいずれか１項に記載の発明において、前記スレーブ機器は、前記全ての機器が前記アイソクロナス通信を再開した後、前記マスタ機器から受信した前記アイソクロナス・パケットに含まれるインデックス番号が前回受信したインデックス番号と連続するまで該アイソクロナス・パケットを廃棄することを特徴としたものである。

請求項４に記載の発明は、請求項１〜３のいずれか１項に記載の発明において、前記接続情報が、前記ネットワーク上に接続された機器のノードIDと、少なくともポート情報とチップIDのいずれか１つであることを特徴としたものである。

請求項５に記載の発明は、１局のマスタ機器と１局以上のスレーブ機器がネットワーク上に接続され、一定時間の制御周期に同期して、前記マスタ機器と前記スレーブ機器がアイソクロナス通信を使用して通信データを授受するマスタ・スレーブ同期通信システムにおいて、
前記マスタ機器および前記スレーブ機器の内、アイソクロナス・リソース・マネージャとなる機器が、前記ネットワーク上に接続された機器の数からなる接続情報が格納される不揮発性の接続情報記憶部を備え、
前記マスタ機器および前記スレーブ機器が各々、前記アイソクロナス・リソース・マネージャから取得したアイソクロナス・リソースを格納する不揮発性のアイソクロナス・リソース記憶部を備え、
前記アイソクロナス通信中にバスリセットが発生した場合に、前記アイソクロナス・リソース・マネージャは新たに取得した接続情報が前記バスリセットが発生する前に前記接続情報記憶部に格納した接続情報から変化していないことを確認したならば、前記接続情報に変化がない旨を他の機器にブロードキャストで通知し、
その後、前記接続情報に変化がない旨を通知された全ての機器は、前記バスリセットが発生する前に取得して前記アイソクロナス・リソース記憶部に格納していたアイソクロナス・リソースに従って前記アイソクロナス通信を再開することを特徴としたものである。

請求項６に記載の発明は、請求項５に記載の発明において、前記アイソクロナス・リソース・マネージャは、全ての機器のアイソクロナス・リソースを格納する不揮発性の全機器アイソクロナス・リソース記憶部をも備え、
前記アイソクロナス・リソース・マネージャは、前記他の機器に通知するとともに、記憶していた前記他の機器の各々のアイソクロナス・リソースを前記他の機器の各々に与えることを特徴としたものである。

請求項７に記載の発明は、請求項５〜６のいずれか１項に記載の発明において、前記スレーブ機器は、前記全ての機器が前記アイソクロナス通信を再開した後、前記マスタ機器から受信したアイソクロナス・パケットに含まれるインデックス番号が前回受信したインデックス番号と連続するまで該アイソクロナス・パケットを廃棄することを特徴としたものである。

請求項８に記載の発明は、請求項５〜７のいずれか１項に記載の発明において、前記接続情報が、前記ネットワーク上に接続された機器のノードIDと、少なくともポート情報とチップIDのいずれか１つであることを特徴としたものである。

本発明に記載の請求項１、請求項４、請求項５、または請求項８の発明によると、アイソクロナス通信中にノイズや振動によりバスリセットが発生しても、各機器は自身が持つアイソクロナス・リソース記憶部を参照すれば自身が使用するアイソクロナス・リソースを取得できるため、ロックトランザクションによるアイソクロナス・リソース取得処理を省くことができる。その結果、バスリセット後も直ちにアイソクロナス通信を再開することが可能となる。

請求項２、請求項４、請求項６、または請求項８に記載の発明によると、ネットワークシステムの接続構成を組んで電源投入したときに、各機器が使用するアイソクロナス・リソース情報を自動的に各機器のアイソクロナス・リソース記憶部に設定することができる。また、接続構成を変えない限り各機器が改めてアイソクロナス・リソース取得のためにロックトランザクションなどの処理を行う必要が無いため、電源投入後直ちにアイソクロナス通信を開始することができる。

請求項３、請求項４、請求項７、または請求項８に記載の発明によると、ネットワークシステムの接続構成を組んで電源投入したときに、各機器が使用するアイソクロナス・リソース情報を自動的に各機器のアイソクロナス・リソース記憶部に設定することができる。また、接続構成を変えない限り各機器が改めてアイソクロナス・リソース取得のためにロックトランザクションなどの処理を行う必要が無いため、電源投入後直ちにアイソクロナス通信を開始することができる。

以下、本発明の方法の具体的実施例について、図に基づいて説明する。本発明の適用範囲は、1局のマスタ機器と1局以上のスレーブ機器が接続された通信システムであるが、以下の説明においては、1局のマスタ機器と1局のスレーブ機器が接続された例とし、機器１をマスタ機器、機器２をスレーブ機器とする。
また、アイソクロナス通信には、アイソクロナス・リソース・マネージャ（ＩＲＭ）が必要であり、ＩＲＭはネットワークに接続されたどの機器が対応しても良いが、以下の説明において、機器1をＩＲＭとする。

図１は、本発明第１の実施例を示すＩＥＥＥ１３９４機器の構成図である。図２において、１は機器（ＩＲＭ）、２は機器、３はＩＥＥＥ１３９４ケーブル、１１、２１はＣＰＵ、１２，２２はＩＥＥＥ１３９４のＬｉｎｋチップ、１３，２３はＰｈｙチップ、１４はＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタ、１５はＣＨＡＮＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタ、１７は接続情報記憶部、１８はアイソクロナス・リソース記憶部である。２４はアイソクロナス・リソース記憶部である。

機器１（ＩＲＭ）にある接続情報記憶部１７とアイソクロナス・リソース記憶部１８、ＩＥＥＥ１３９４機器２にあるアイソクロナス・リソース記憶部２４は不揮発性メモリ上に設け、電源を落としても内容が消えないようにする。
図３は本発明第２の実施例におけるＩＥＥＥ１３９４機器間の通信処理シーケンスを示した図である。図３は接続情報が前回電源起動時と異なる場合に、図１に示す機器１、機器２に注目したものである。

はじめにステップ３０１においてＩＥＥＥ１３９４ネットワークに接続されている全ての機器の電源を入れる。電源投入によりバスリセットが発生すると、ＩＥＥＥ１３９４ネットワークの初期化が行われ、ステップ３０２において各機器は自己識別パケットを発行し、各ノードにノードＩＤが割当てられる。たとえば、機器１（ＩＲＭ）のノードＩＤが１、機器２のノードＩＤが０に決定したとする（ステップ３０３〜３０４）。
そして、機器１（ＩＲＭ）はステップ３０５において、接続情報が前回電源投入した際のものと変わっていないかのチェックを行う。

接続情報の比較には、ＩＥＥＥ１３９４機器の接続ノード数を使用する。ＩＥＥＥ１３９４では、バスリセット後の自己識別フェーズで、全ての接続機器が自己認識パケットを送出し、送出された自己識別パケットは全ての機器が受信する。
図１１は自己識別パケットのフォーマットを示す図である（非特許文献１、付属書Ｅ．３．４参照）。このうち、ＰｈｙＩＤがノードＩＤに相当し、ｐ０からｐ２が、それぞれポート０からポート２の状態（ポート情報）に相当する。機器が実装しているポート数が4以上の場合は、複数の自己識別パケットが送出されるが、その中に含まれるノードIDは同一であるので、自己識別パケットを参照すれば接続ノード数を算出できる。
但し、本発明では、接続機器の構成の変化を判定する目的であるので、単に自己識別パケットの数だけで比較可能なので、ここでは接続ノード数とは自己識別パケットの数とする。接続情報記憶部１７には前回電源投入時の接続ノード数（自己識別パケットの数）が格納されており、図３のステップ３０５において、ステップ３０２で発行された自己識別パケットの数と接続情報記憶部１７の値と比較を行う。

比較した結果が不一致（ステップ３０６）であった場合、機器１（ＩＲＭ）は、他の機器２に対して、接続情報変化有りの情報の通知を行う（ステップ３０７）。
前記通知を受信した機器２は、機器１（ＩＲＭ）に対してアイソクロナス・リソースの取得を開始する。この場合のアイソクロナス・リソースの取得方法は、従来と同様である（ステップ３０８〜３０９）。
機器２が取得した帯域情報は、機器２が持つアイソクロナス・リソース記憶部２４に保存する（ステップ３１０）。
チャンネルの取得も帯域の場合と同様に取得（ステップ３１１〜３１２）し、機器２が持つアイソクロナス・リソース記憶部２４に保存する（ステップ３１３）。
機器１（ＩＲＭ）はステップ３１４において自身のアイソクロナス・リソースをアイソクロナス・リソース記憶部１８に保存し、ステップ３１５において今回の接続情報（接続ノード数）を接続情報記憶部１７に保存する（ステップ３１４）。
そしてステップ３１６、３１７において、機器それぞれがアイソクロナス通信を開始する。

次に、ステップ３０５において接続情報が前回電源投入したときと一致した場合について説明する。
図４は図３と同様に本発明第1の実施例におけるＩＥＥＥ１３９４機器間の通信処理シーケンスを示した図であるが、図３と異なり接続情報が前回電源投入時と一致した場合を示す。
ステップ４０６において接続情報が一致していた場合、機器１（ＩＲＭ）は他の機器２に対して接続情報変化無しをブロードキャストで通知する（ステップ４０７）。
前記通知を受信した機器２は、図３のステップ３０８〜３１３で行われたようなアイソクロナス・リソース取得処理は行わず、自身が持つアイソクロナス・リソース記憶部１７に既に格納されているアイソクロナス・リソース情報を読み出す（ステップ４０８）。
そしてステップ４０９、４１０において、機器それぞれがアイソクロナス通信を開始する。
図２に、図３のステップ３０７および図４のステップ４０７で機器１（ＩＲＭ）から機器２に送信される接続情報変化有無通知のフォーマット例を示す。接続情報変化有りの場合は、３２ｂｉｔの最上位ビットを１にして全ての機器２に対してブロードキャストで送信する。

図６は、本発明第１の実施例におけるＩＥＥＥ１３９４の指令パケットのフォーマットを示す図である。６０２は制御指令データ、６０３はＣＲＣ、６０４はインデックス番号である。
マスタ機器は、図６に示すように、ＩＥＥＥ１３９４パケットにインデックス番号を付加して伝送路に指令パケットを送信する。インデックス番号は、指令パケットを送信するごとに毎回１ずつインクリメントするようにする。
なお、インデックス番号は毎回１ずつインクリメントされるものに限るわけではなく、毎回１ずつディクリメントされるもの等、そのインデックス番号の連続性を判断できるものであればよい。

次に、アイソクロナス通信中のスレーブ機器における指令パケットの受信処理について説明する。
図７は、本発明第１の実施例を示すスレーブ機器における受信処理フロー図を示す。
受信処理７０１は、スレーブ機器において制御周期先頭で毎回実行する。この受信処理では通信状態を示す通信ステータス変数によって処理内容を管理する。通信が正常な場合は通信ステータス変数を「通常状態」とし、バスリセットを検出した直後では通信ステータス変数を「バスリセット検出状態」、そして正常な通信に戻るまでは通信ステータス変数を「回復待ち状態」と設定する。そしてこの通信ステータス変数の設定値を参照することによりそれぞれの状態に応じた処理を行う。以下にその詳細を説明する。

まず、ステップ７０２においてバスリセットの有無を判別する。バスリセットの検出は、例えば、ＯＨＣＩ（Ｏｐｅｎ Ｈｏｓｔ Ｃｏｎｔｒｏｌｌｅｒ Ｉｎｔｅｒｆａｃｅ）の割込み要因レジスタＩｎｔＥｖｅｎｔを参照することによって行う。
バスリセットが無い場合は、ステップ７０５に移行し、通信ステータス変数が「通常状態」であればステップ７０６において指令パケットから制御指令データを読み出す。
ステップ７０１においてバスリセットを検出した場合、ステップ７０３において指令パケットを廃棄し、ステップ７０４において通信ステータス変数を「バスリセット検出」に設定する。ステップ７０３において指令パケットを廃棄しているのは、バスリセットが発生した制御周期と同じ制御周期中にマスタ機器からの指令パケットがマスタ機器送信ＦＩＦＯに残らずに伝送路に出た場合、バスリセットによって通信パケットが壊れている可能性があるためである。その後、ステップ７０７において指令パケットの有無をチェックするが、既にステップ７０３において指令パケットを廃棄しているため、ステップ７０８、ステップ７０９は通らずに受信処理を終了する。

次の制御周期で受信処理ステップ７０１が実行され、再びステップ７０７の指令パケット有無のチェックが行われ、指令パケットありとなった場合、ステップ７０８において、その指令パケットのインデックス番号だけを読み出し、制御指令データは使用しない。そしてステップ７０９において通信ステータス変数を「回復待ち状態」に設定する。
そして次の制御周期では通信ステータス変数が「回復待ち状態」になっているため、ステップ７１０で指令パケットの有無をチェックした後、ステップ７１１において指令パケットからインデックス番号を読み出し、ステップ７１２において前回のインデックス番号と比較を行う。インデックス番号が連続していない場合は、受信処理を終了し、インデックス番号が連続したものになるまでステップ７１０〜７１２を繰り返す。
ステップ７１２においてインデックス番号が前回のインデックス番号に１足したものと等しくなったとき、インデックス番号が連続しているとみなして、ステップ７１３において指令パケットから制御指令データの読み出しを行い、ステップ７１４において通信ステータス変数を「通常状態」に設定し、以後は通常の動作を続けるようにする。

次に、アイソクロナス通信中にバスリセットが発生したときの動作を説明する。
図５は、本発明第１の実施例を示すＩＥＥＥ１３９４アイソクロナス通信における通信タイミング図である。５０１はマスタ機器送信ＦＩＦＯ、５０２は伝送路、５０３はスレーブ機器、５０４は指令パケットである。図５は、マスタ機器が、インデックス番号ｍ＋１番の指令パケット５０４を、マスタ機器送信ＦＩＦＯ５０１から伝送路５０２に出す際にバスリセットが発生した例である。

バスリセットが発生したとき、接続情報が一致していれば、図４のステップ４０８と同じ手段でそれぞれが持つアイソクロナス・リソース記憶部にある情報を読み出す。スレーブ機器がアイソクロナス・リソースを取得するため通信処理を一切行わないため、直ちにアイソクロナス通信を再開できる状態になり、マスタ機器は指令パケット５０４の送信を直ちに再開できる。

ただし、マスタ機器送信ＦＩＦＯにバスリセットによって正しいタイミングで伝送路に出ることができなかった指令パケット（ｍ＋１番）が残ってしまい、マスタ機器が指令パケットの送信を再開したときに本来とは遅れたタイミングで伝送路に出される場合がある。図５ではマスタ機器がバスリセットを検出して指令パケット作成（ｍ＋２番目、ｍ＋３番目）を一時中止した場合を示している。
スレーブ機器は、バスリセット検出後、最初に受信した指令パケット、つまりｍ＋１番の指令パケットを受信するが、図７のステップ７０２においてバスリセットが検出されているため廃棄される（ステップ７０３）。そして制御ステータス変数は「バスリセット検出」となる。

次の制御周期で、ｍ＋４番の指令パケットを受信すると、ステップ７０７のパスを通りステップ７０８でインデックスｍ＋４を読み出したあと通信ステータスを「回復待ち」に変更する（ステップ７０９）。
さらに次の周期で、ｍ＋５番の指令パケットを受信すると、ステップ７１０のパスを通り、ステップ７１１でインデックスｍ＋５を読み出したあとステップ７１２において前回のインデックスと比較を行う。前回のインデックスｍ＋４から連続した値であるため、ステップ７１３において指令パケット中の制御指令データを読み出し、通信ステータスを通常状態に戻す（ステップ７１４）。

以上のような操作を行うことにより、バスリセットによってマスタ機器が意図しないタイミングで伝送路に出された指令パケット中の制御指令データを使用することなく、指令パケットの連続性を確認した上で制御指令データを読み出すようになる。
以上、マスタ機器がスレーブ機器に送信する指令パケットについて説明したが、逆にスレーブ機器がマスタ機器に応答パケットを送信する場合も同様である（説明省略）。

図８は、本発明第２の実施例を示すＩＥＥＥ１３９４機器の構成図である。図８において、１は機器（ＩＲＭ）、２は機器、３はＩＥＥＥ１３９４ケーブル、１１と２１はＣＰＵ、１２と２２はＩＥＥＥ１３９４のＬｉｎｋチップ、１３と２３はＰｈｙチップ、１４はＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタ、１５はＣＨＡＮＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタ、１６は全機器アイソクロナス・リソース記憶部、１７は接続情報記憶部、２４はアイソクロナス・リソース記憶部である。
実施例１と異なるのは、機器２のアイソクロナス・リソース記憶部２４が揮発性メモリ上にあり、また、機器１（ＩＲＭ）の不揮発性メモリ上に全機器アイソクロナス・リソース記憶部１６を設けていることである。

図１２は、本発明第２の実施例におけるＩＥＥＥ１３９４機器間の通信処理シーケンスを示した図である。図１２は接続情報が前回電源起動時と異なる場合に、図８に示す機器１、機器２に注目したものである。
図１２のステップ１２０１〜１２０９までの処理は、実施例１（ステップ３０１〜３０９）と同様である。
ステップ１２１０において、機器２によって帯域情報を取得された機器１（ＩＲＭ）は、帯域の獲得を要求してきた機器２のノードＩＤと、獲得された帯域幅の値を対応付けて全機器アイソクロナス・リソース記憶部１６に保存する。
また、機器２は、取得した帯域情報をアイソクロナス・リソース記憶部２４に保存する（ステップ１２１１）。

チャンネルの取得も帯域の場合と同様である。ステップ１２１２〜１２１３でチャンネル情報を取得されたあと、ステップ１２１４において、機器１（ＩＲＭ）はチャンネルの獲得を要求してきた機器２のノードＩＤと、獲得されたチャンネルの値を対応付けて全機器アイソクロナス・リソース記憶部１６に保存する。
また、機器２は、取得したチャンネル番号をアイソクロナス・リソース記憶部２４に保存する（ステップ１２１５）。
その他の機器においても、接続情報変化有りの通知を受信したあとステップ１２０８〜１２１５と同様の処理を実行し、全ての機器がアイソクロナス・リソース取得を完了したあと、機器１（ＩＲＭ）は今回の接続情報（接続ノード数）を接続情報記憶部１７に保存する（ステップ１２１６）。
そしてステップ１２１８、１２１９において、機器それぞれがアイソクロナス通信を開始する。

次に、ステップ１２０５において接続情報が前回電源投入したときと一致した場合について説明する図１３を用いて説明する。
ステップ１３０６において、接続情報が一致していた場合、機器１（ＩＲＭ）は他の機器２に対して接続情報変化無しをブロードキャストで通知する（ステップ４０７）と、機器２は実施例１の場合と同様にアイソクロナス・リソースの取得処理（ステップ３０８〜３１３）を行わない。

ただし、実施例１と異なり各機器のアイソクロナス・リソースは機器２ではなく機器１（ＩＲＭ）の全機器アイソクロナス・リソース記憶部１６に保存されているため、機器１（ＩＲＭ）は全機器アイソクロナス・リソース記憶部１６にある情報を元に各機器に帯域とチャンネルをＷｒｉｔｅＲｅｑｕｅｓｔによって送信する（ステップ１３０８、１３１０）。
ＷｒｉｔｅＲｅｑｕｅｓｔによって帯域とチャンネルを受信した機器２は、自身のアイソクロナス・リソース記憶部２４に保存する（ステップ１３０９、１３１１）。そしてアイソクロナス・リソース記憶部２４に保存された情報を読み出す（ステップ１３１２）。
そしてステップ１３１３、１３１４において、機器それぞれがアイソクロナス通信を開始する。

図９は、全機器アイソクロナス・リソース記憶部１６の内容を示す図である。１６１はアイソクロナス・リソース・テーブルである。図９では、たとえばノードＩＤ＝０の機器２によって帯域６００、チャンネル０番を取得されたことを示す。

アイソクロナス通信中にバスリセットが発生した場合の動作は実施例１と同様である。

図１０は、本発明第３の実施例を示す接続情報記憶部の構成を示す図である。
実施例１、２では、接続情報として接続ノード数を使用したが、その代わりに全機器のノードＩＤとポート情報を使用する。
図１０において、ポート情報のｐ０からｐ２は、物理ポート０から２に対応し、その内容は自己識別パケットと同じである。たとえばノードＩＤがゼロの機器のポート０番とポート１番は非接続ポートであり、他の機器は接続されていないことを示し、ポート２番に親ノード（自身のノードＩＤよりも大きいノードＩＤを持つノード）が接続されていることを示す。

ＩＲＭは、このノードＩＤとポート情報の対応情報を接続情報記憶部１７に保存しておき、電源投入時に接続情報記憶部１７の内容と今回電源投入時のノードＩＤとポート情報の比較を行う。
なお、ノードＩＤとポート情報は、実施例1にて説明した通り、電源投入時に各機器が発行する自己識別パケットから得ることができる。

実施例３において、電源投入後からアイソクロナス通信開始までの動作や、アイソクロナス通信中にバスリセットが発生した際の動作など、動作については実施例１、２と同様であるため説明を省略する。

図１４は、本発明第４の実施例を示す接続情報記憶部の内容を示す図である。
実施例１，２では、接続情報として接続ノード数を使用したが、その代わりに全機器のノードＩＤとチップＩＤを使用する。
チップＩＤとはＩＥＥＥ１３９４機器ごとにユニークに割当てられる５バイトのＩＤであり、全てのＩＥＥＥ１３９４機器に実装が必須のものである
図１４において、たとえばノードＩＤが２の機器のチップＩＤは１６進数で０４Ｂ４０００００２ｈとなる。

図１５は本発明第４の実施例におけるＩＥＥＥ１３９４機器間の接続情報比較までの通信処理シーケンスを示した図である。
ステップ１５０１〜１５０３によって各機器のノードＩＤが確定したあと、機器１（ＩＲＭ）からチップＩＤの読み出しをＲｅｑｄＲｅｑｕｅｓｔによって行う。
チップＩＤはシリアルバス依存アドレス空間の始まりからオフセット４０Ｃｈと４１０ｈにマップされている。
ステップ１５０６において、読み出したチップＩＤと接続情報記憶部に格納されている情報と比較を行う。

実施例３において、電源投入後からアイソクロナス通信開始までの動作や、アイソクロナス通信中にバスリセットが発生した際の動作など、動作については実施例１、２と同様であるため説明を省略する。

ＩＥＥＥ１３９４ネットワークを使用したマスタ・スレーブ同期通信システムであって、バスリセットが発生しても速やかにアイソクロナス通信を再開してその制御を継続することが必要な、たとえば、モーション・コントロール・システム等に利用可能である。

本発明第１の実施例を示すＩＥＥＥ１３９４機器の構成図 本発明第１の実施例を示す接続情報記憶部の内容を示す図 本発明第１の実施例を示すＩＥＥＥ１３９４機器間のアイソクロナス・リソース取得処理シーケンス図 本発明第１の実施例を示すＩＥＥＥ１３９４機器間のアイソクロナス・リソース取得処理シーケンス図 本発明第１の実施例を示すＩＥＥＥ１３９４アイソクロナス通信における通信タイミングを示す図 本発明第１の実施例を示すＩＥＥＥ１３９４指令パケット図 本発明第１の実施例を示すスレーブ機器における受信処理フロー図 本発明第２の実施例を示すＩＥＥＥ１３９４機器の構成図 本発明第２の実施例を示す全機器アイソクロナス・リソース記憶部の構成図 本発明第３の実施例を示す接続情報記憶部の構成図 自己識別パケットのフォーマットを示す図 本発明第２の実施例におけるＩＥＥＥ１３９４機器間の通信処理シーケンス図 本発明第２の実施例におけるＩＥＥＥ１３９４機器間の通信処理シーケンス図 本発明第４の実施例を示す接続情報記憶部の構成図 本発明第４の実施例を示すＩＥＥＥ１３９４機器間の接続情報比較までの通信処理シーケンス図 従来の方法を実施するＩＥＥＥ１３９４機器の構成図 アイソクロナス・リソース・レジスタのフォーマット図 従来のＩＥＥＥ１３９４機器間のアイソクロナス・リソース取得処理シーケンス図 従来のＩＥＥＥ１３９４アイソクロナス通信における通信タイミングを示す図

符号の説明

１ ＩＲＭ（アイソクロナス・リソース・マネージャ）
１１ ＣＰＵ
１２ Ｌｉｎｋチップ
１３ Ｐｈｙチップ
１４ ＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタ
１５ ＣＨＡＮＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタ
１６ 全機器アイソクロナス・リソース記憶部
１６１ アイソクロナス・リソース・テーブル
１７ 接続情報記憶部
１８ アイソクロナス・リソース記憶部
２ ＩＥＥＥ１３９４機器
２１ ＣＰＵ
２２ Ｌｉｎｋチップ
２３ Ｐｈｙチップ
２４ アイソクロナス・リソース記憶部
３ ＩＥＥＥ１３９４ケーブル
５０１ マスタ機器送信ＦＩＦＯ
５０２ 伝送路
５０３ スレーブ機器
５０４ 指令パケット
１９０１ マスタ機器送信ＦＩＦＯ
１９０２ 伝送路
１９０３ スレーブ機器
１９０４ 指令パケット
６０１ ＩＥＥＥ１３９４ヘッダ
６０２ 制御指令データ部
６０３ ＣＲＣ
６０４ インデックス番号

Claims (8)

1. １局のマスタ機器と１局以上のスレーブ機器がネットワーク上に接続され、一定時間の制御周期に同期して、前記マスタ機器と前記スレーブ機器がアイソクロナス通信を使用して通信データを授受するマスタ・スレーブ同期通信方法において、
   前記アイソクロナス通信中にバスリセットが発生した場合、
   前記マスタ機器と前記スレーブ機器のうち、いずれか１局が備えるアイソクロナス・リソース・マネージャは前記ネットワーク上に接続された機器の数よりなる接続情報が前記バスリセットが発生する前のものから変化していないことを確認したならば、前記接続情報に変化がない旨を他の機器にブロードキャストで通知し、
   その後、前記接続情報に変化がない旨を通知された全ての機器は、前記バスリセットが発生する前に取得して自機器にそれぞれ記憶していたアイソクロナス・リソースに従って前記アイソクロナス通信を再開することを特徴とするマスタ・スレーブ同期通信方法。
2. 前記アイソクロナス・リソース・マネージャは、前記他の機器に通知するとともに、記憶していた前記他の機器の各々のアイソクロナス・リソースを前記他の機器の各々に送信することを特徴とする請求項１記載のマスタ・スレーブ同期通信方法。
3. 前記スレーブ機器は、前記全ての機器が前記アイソクロナス通信を再開した後、前記マスタ機器から受信した前記アイソクロナス・パケットに含まれるインデックス番号が前回受信したインデックス番号と連続するまで該アイソクロナス・パケットを廃棄することを特徴とする請求項１〜２のいずれか１項に記載のマスタ・スレーブ同期通信方法。
4. 前記接続情報が、前記ネットワーク上に接続された機器のノードIDと、少なくともポート情報とチップIDのいずれか１つであることを特徴とする請求項１〜３のいずれか１項に記載のマスタ・スレーブ同期通信方法。
5. １局のマスタ機器と１局以上のスレーブ機器がネットワーク上に接続され、一定時間の制御周期に同期して、前記マスタ機器と前記スレーブ機器がアイソクロナス通信を使用して通信データを授受するマスタ・スレーブ同期通信システムにおいて、
   前記マスタ機器および前記スレーブ機器の内、アイソクロナス・リソース・マネージャとなる機器が、前記ネットワーク上に接続された機器の数からなる接続情報が格納される不揮発性の接続情報記憶部を備え、
   前記マスタ機器および前記スレーブ機器が各々、前記アイソクロナス・リソース・マネージャから取得したアイソクロナス・リソースを格納する不揮発性のアイソクロナス・リソース記憶部を備え、
   前記アイソクロナス通信中にバスリセットが発生した場合に、前記アイソクロナス・リソース・マネージャは新たに取得した接続情報が前記バスリセットが発生する前に前記接続情報記憶部に格納した接続情報から変化していないことを確認したならば、前記接続情報に変化がない旨を他の機器にブロードキャストで通知し、
   その後、前記接続情報に変化がない旨を通知された全ての機器は、前記バスリセットが発生する前に取得して前記アイソクロナス・リソース記憶部に格納していたアイソクロナス・リソースに従って前記アイソクロナス通信を再開することを特徴とするマスタ・スレーブ同期通信システム。
6. 前記アイソクロナス・リソース・マネージャは、全ての機器のアイソクロナス・リソースを格納する不揮発性の全機器アイソクロナス・リソース記憶部をも備え、
   前記アイソクロナス・リソース・マネージャは、前記他の機器に通知するとともに、記憶していた前記他の機器の各々のアイソクロナス・リソースを前記他の機器の各々に与えることを特徴とする請求項５に記載のマスタ・スレーブ同期通信システム。
7. 前記スレーブ機器は、前記全ての機器が前記アイソクロナス通信を再開した後、前記マスタ機器から受信したアイソクロナス・パケットに含まれるインデックス番号が前回受信したインデックス番号と連続するまで該アイソクロナス・パケットを廃棄することを特徴とする請求項５〜６のいずれか１項に記載のマスタ・スレーブ同期通信システム。
8. 前記接続情報が、前記ネットワーク上に接続された機器のノードIDと、少なくともポート情報とチップIDのいずれか１つであることを特徴とする請求項５〜７のいずれか１項に記載のマスタ・スレーブ同期通信システム。
   

Images