(57)【特許請求の範囲】
【請求項１】
ネットワークを介して接続された第１ノードと複数の第２ノードとを備え、
前記第１ノードが、それぞれ時間経過に応じて変化する複数の第１データを記憶する第１記憶手段を備え、
前記第１ノードが、一の前記第１データが変化する度に、その第１データの変化内容を示す変化通知を前記複数の第２ノードにマルチキャスト送信し、
前記複数の第２ノードの各々が、前記変化通知を受信した時に、該変化通知に基づき所定の動作を行う通信システムであって、
前記第１ノードに、
所定の同期タイミングを生成するタイミング生成手段と、
各同期タイミングからその次の同期タイミングまでの期間である各同期期間に、その同期期間を特定する同期ＩＤを付す同期ＩＤ生成手段と、
一の前記第１データが変化した場合に、該変化した第１データを特定するデータＩＤを、前記同期期間毎に記憶する変化データ記憶手段と、
前記同期期間が終わる毎に、その次の同期期間の同期ＩＤを含む同期データを生成して前記複数の制御装置にマルチキャスト送信する同期データ送信手段とを有し、
前記複数の第２ノードの各々が、
前記変化通知又は前記同期データの受信エラーを検出した時に、その検出の時点で記憶している同期ＩＤを含み、該同期ＩＤが示す同期期間以降でかつその時点で終了している１乃至複数の同期期間に変化した全ての第１データの値を示す訂正情報を要求する送信要求を、前記第１ノードにユニキャスト送信する送信要求手段と、
前記同期データを受信した場合に、該同期データに含まれる同期ＩＤを記憶すると共に、該同期データに前記送信要求で要求した前記訂正情報が含まれていた場合に、該訂正情報に基づき前記所定の動作に対する訂正動作を行う同期データ処理手段とを有し、
前記第１ノードの同期データ送信手段は、各同期期間の終わりに前記同期データを生成する際に、当該同期期間内にいずれかの第２ノードから前記送信要求を受信したか否か判断し、受信していれば、該送信要求に含まれる同期ＩＤが特定する同期期間以降当該同期期間までの全同期期間について、前記変化データ記憶手段が記憶している全てのデータＩＤを読み出し、前記第１記憶手段に記憶している第１データのうちの、該読み出されたデータＩＤが示す第１データを前記同期データに付加する手段を有することを特徴とする通信システム。
【請求項２】
請求項１に記載の通信システムであって、
前記各第２ノードが、前記同期データを受信した場合に、該同期データに含まれる同期ＩＤの連続性を確認することにより、マルチキャスト通信のエラー有無を判断する手段を有することを特徴とする通信システム。
【請求項３】
請求項１又は２に記載の通信システムであって、
前記第１ノードが、マルチキャスト送信するデータに通し番号を付す手段を有し、
前記各第２ノードが、マルチキャスト送信されたを受信した場合に、該受信したデータに付された通し番号の連続性を確認することにより、マルチキャスト通信のエラー有無を判断する手段を有することを特徴とする通信システム。
【請求項４】
請求項１乃至３のいずれか一項に記載の通信システムであって、
前記同期データには、所定の上限サイズが規定されており、
前記第１ノードの同期データ送信手段が前記同期データに取り込む第１データは、各同期期間と対応する部分データの集まりとして構成し、
前記同期データ送信手段は、前記送信要求で指定された全ての同期期間について前記部分データを前記同期データに取り込むと該同期データのサイズが前記上限サイズを超えてしまう場合には、一部の部分データの送信を次回以降の同期データに取り込むようにして、送信しようとする同期データのサイズを前記上限サイズ以下に抑えることを特徴とする通信システム。
【請求項５】
請求項１乃至３のいずれか一項に記載の通信システムであって、
前記送信要求を送信した第２ノードは、その送信後、前記送信要求で要求した第１データを全て受信するまで、所定時間毎に同じ送信要求を繰り返し送信し、さらに、該送信要求を所定回送信しても前記送信要求で要求した第１データを全て受信できない場合は、前記第１ノードとの通信が切断されたと判断することを特徴とする通信システム。
【請求項６】
請求項１乃至５のいずれか一項に記載の通信システムであって、
前記第１ノードの変化データ記憶手段が記憶するデータＩＤは有限個の同期ＩＤについてのデータＩＤであり、
前記第１ノードに、いずれかの前記第２ノードから前記送信要求を受信した場合に、前記変化データ記憶手段が該送信要求で指定された同期期間に関するデータＩＤを記憶しているか否か判断し、記憶していない場合には、前記送信要求を送信してきた第２ノードに対し、前記第１ノードとの接続が切れた旨の通知を行う手段を設けたことを特徴とする通信システム。
【請求項７】
請求項１乃至６のいずれか一項に記載の通信システムであって、
前記各第２ノードが受信した変化通知及び受信した同期データに含まれていた第１データに基づいて行う所定の動作は、その第２ノードが有する表示器に対する該第１データに基づく表示の制御であることを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、第１ノードから複数の第２ノードへ、変化する複数のデータを伝達する通信システムに関する。
【背景技術】
【０００２】
従来から、第１ノードから複数の第２ノードへ、変化する複数のデータを伝達する通信システムの一例として、アンプ等の音響信号処理装置と、ＰＣ（パーソナルコンピュータ）等の制御装置とをネットワークを介して接続し、ユーザが制御装置を操作して音響信号処理装置におけるパラメータの値を制御できるようにしたリモート制御システムが知られている。そのネットワークとしては、最も普及の進んでいるイーサネット（Ethernet：登録商標）を使用するのが一般的である。
【０００３】
また、このようなリモート制御システムにおいて、パラメータの値の制御を以下の手順で行うことが知られている。すなわち、まず、ユーザからパラメータの値を変更する指示を受けた制御装置が、制御対象である音響信号処理装置（被制御装置）に対し、パラメータの値を変更するよう要求する変更命令を送信する。次に、その変更命令を受けた音響信号処理装置が、要求に従ってカレントメモリの内容を変更する。そして、音響信号処理装置が、変更結果を制御装置に通知し、制御装置が、その変更結果に基づいて、変更が正しく行われたことを確認する。
【０００４】
そしてこのとき、制御装置が複数ある場合でも、音響信号処理装置（第１ノード）が、自身を制御している全ての制御装置（第２ノード）に対して変更後のパラメータの値の通知（変化する複数のデータの伝達）を行うことにより、変更要求を行った制御装置だけでなく、他の制御装置も、音響信号処理装置におけるパラメータの値の変更結果を把握し、変更後のパラメータの値の表示等を行うことができる。
このようなシステムについては、例えば特許文献１及び特許文献２に記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−２１８９３７号公報
【特許文献２】特開２００９−２１８９４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、上記のようなデータ伝達機能を備えたシステムを構成する場合、音響信号処理装置から制御装置への、パラメータの値の変更結果の通知をどのように行うかが問題となる。
変更後に速やかに通知を行わないと、直接変更指示を受けた制御装置以外の制御装置での表示への反映が遅れる一方、頻繁にかつ信頼性よく通知を行おうとすると、送信すべきデータの量が増え、ネットワークの通信帯域に対する負荷が大きくなってしまう。
このような問題は、第１ノードから複数の第２ノードへ、変化する複数のデータを伝達しようとする場合には、ノードの用途や、伝達するデータの内容によらず、同様に発生するものである。
【０００７】
この点につき、特許文献１に記載のシステムにおいては、音響信号処理装置から制御装置への変更結果の通知を、設定変更メッセージのブロードキャストにより行っている（段落０１５２参照）。この手法では、変更結果の通知を行うために送信するパケット数が少なく、通信帯域の圧迫は少ないが、通知が制御装置へ伝達されることは保証できない。そして、特許文献１には、変更結果伝達の信頼性を確保するための特段の仕組みは開示されていない。
【０００８】
また、特許文献２に記載のシステムにおいては、音響信号処理装置から制御装置への変更結果の通知を、その音響信号処理装置とオンライン状態になっているか又はその音響信号処理装置をモニタしている制御装置に対して個別にアドレス指定して（ユニキャストで）変更されたパラメータの情報を送信することによって行っている（段落００７７参照）。
【０００９】
ＯＳＩ参照モデルのネットワーク層にイーサネットを使用する場合、ユニキャストには、トランスポート層のＴＣＰ（Transmission Control Protocol）を使用するのが一般的である。ユニキャストによるパラメータの送信では、ＴＣＰにより伝達保証されているので、送信されたパラメータを確実に制御装置に届けることができるが、制御装置の台数分のパケットを送信しなければならない、送信された全てのパケットに対してそれぞれ確認用のパケット（ＡＣＫ）が返信される、等々の事情により、ネットワーク上に送信されるパケット数が増大し、ネットワークの通信帯域が圧迫されたり、パラメータを送信する音響信号処理制御装置の制御ＣＰＵの負荷が大きくなっていた。
【００１０】
なお、特許文献２に記載のシステムでは、音響信号処理装置が、パラメータの値が変更された場合に直ちにその情報を送信するのではなく、１０ミリ秒毎に、直前の１０ミリ秒間の変更結果をまとめて１パケットで送信することにより、送信するパケット数を減らしている。しかしこれでも、変更結果を通知すべき制御装置の数が多い場合には、通信帯域の圧迫が大きくなってしまうことが考えられる。
【００１１】
この発明は、このような背景に鑑みてなされたものであり、第１ノードから複数の第２ノードへ、変化する複数のデータを伝達する場合において、ネットワークに送出されるパケット数を少なくすることで必要とされるネットワークの通信帯域や被制御装置の処理負荷を下げ、通信帯域に対する負荷が小さく（送信すべきデータ量が小さく）、パラメータの値の伝達の信頼性が適度に確保され、かつデータの伝達を少ない時間遅れで行うことができるようにすることを目的とする。
【課題を解決するための手段】
【００１２】
上記の目的を達成するため、この発明の通信システムは、ネットワークを介して接続された第１ノードと複数の第２ノードとを備え、上記第１ノードが、それぞれ時間経過に応じて変化する複数の第１データを記憶する第１記憶手段を備え、上記第１ノードが、一の上記第１データが変化する度に、その第１データの変化内容を示す変化通知を上記複数の第２ノードにマルチキャスト送信し、上記複数の第２ノードの各々が、上記変化通知を受信した時に、その変化通知に基づき所定の動作を行う通信システムにおいて、上記第１ノードに、所定の同期タイミングを生成するタイミング生成手段と、各同期タイミングからその次の同期タイミングまでの期間である各同期期間に、その同期期間を特定する同期ＩＤを付す同期ＩＤ生成手段と、一の上記第１データが変化した場合に、その変化した第１データを特定するデータＩＤを、上記同期期間毎に記憶する変化データ記憶手段と、上記同期期間が終わる毎に、その次の同期期間の同期ＩＤを含む同期データを生成して上記複数の制御装置にマルチキャスト送信する同期データ送信手段とを設け、上記複数の第２ノードの各々に、上記変化通知又は上記同期データの受信エラーを検出した時に、その検出の時点で記憶している同期ＩＤを含み、その同期ＩＤが示す同期期間以降でかつその時点で終了している１乃至複数の同期期間に変化した全ての第１データの値を示す訂正情報を要求する送信要求を、上記第１ノードにユニキャスト送信する送信要求手段と、上記同期データを受信した場合に、その同期データに含まれる同期ＩＤを記憶すると共に、その同期データに上記送信要求で要求した上記訂正情報が含まれていた場合に、その訂正情報に基づき上記所定の動作に対する訂正動作を行う同期データ処理手段とを設け、上記第１ノードの同期データ送信手段に、各同期期間の終わりに上記同期データを生成する際に、その同期期間内にいずれかの第２ノードから上記送信要求を受信したか否か判断し、受信していれば、その送信要求に含まれる同期ＩＤが特定する同期期間以降その同期期間までの全同期期間について、上記変化データ記憶手段が記憶している全てのデータＩＤを読み出し、上記第１記憶手段に記憶している第１データのうちの、その読み出されたデータＩＤが示す第１データを上記同期データに付加する手段を設けたものである。
【００１３】
このような通信システムにおいて、上記各第２ノードに、上記同期データを受信した場合に、その同期データに含まれる同期ＩＤの連続性を確認することにより、マルチキャスト通信のエラー有無を判断する手段を設けるとよい。
さらに、上記第１ノードに、マルチキャスト送信するデータに通し番号を付す手段を設け、上記各第２ノードに、マルチキャスト送信されたを受信した場合に、その受信したデータに付された通し番号の連続性を確認することにより、マルチキャスト通信のエラー有無を判断する手段を設けるとよい。
【００１４】
さらにまた、上記同期データに、所定の上限サイズが規定し、上記第１ノードの同期データ送信手段が上記同期データに取り込む第１データを、各同期期間と対応する部分データの集まりとして構成し、上記同期データ送信手段が、上記送信要求で指定された全ての同期期間について上記部分データを上記同期データに取り込むとその同期データのサイズが上記上限サイズを超えてしまう場合には、一部の部分データの送信を次回以降の同期データに取り込むようにして、送信しようとする同期データのサイズを上記上限サイズ以下に抑えるようにするとよい。
【００１５】
あるいは、上記送信要求を送信した第２ノードが、その送信後、上記送信要求で要求した第１データを全て受信するまで、所定時間毎に同じ送信要求を繰り返し送信し、さらに、その送信要求を所定回送信しても上記送信要求で要求した第１データを全て受信できない場合は、上記第１ノードとの通信が切断されたと判断するようにするとよい。
【００１６】
また、上記の各通信システムにおいて、上記第１ノードの変化データ記憶手段が記憶するデータＩＤを有限個の同期ＩＤについてのデータＩＤとし、上記第１ノードに、いずれかの上記第２ノードから上記送信要求を受信した場合に、上記変化データ記憶手段がその送信要求で指定された同期期間に関するデータＩＤを記憶しているか否か判断し、記憶していない場合には、上記送信要求を送信してきた第２ノードに対し、上記第１ノードとの接続が切れた旨の通知を行う手段を設けるとよい。
さらに、上記各第２ノードが受信した変化通知及び受信した同期データに含まれていた第１データに基づいて行う所定の動作を、その第２ノードが有する表示器に対するその第１データに基づく表示の制御とするとよい。
【発明の効果】
【００１７】
以上のようなこの発明のリモート制御システムによれば、第１ノードから複数の第２ノードへ、変化する複数のデータを伝達する場合において、ネットワークに送出されるパケット数を少なくすることで必要とされるネットワークの通信帯域や被制御装置の処理負荷を下げ、通信帯域に対する負荷が小さく（送信すべきデータ量が小さく）、パラメータの値の伝達の信頼性が適度に確保され、かつデータの伝達を少ない時間遅れで行うことができるようにすることができる。
【図面の簡単な説明】
【００１８】
【図１】この発明のリモート制御システムの実施形態である通信システムの概略構成を示す図である。
【図２】図１に示したＰＣのハードウェア構成を示す図である。
【図３】図１に示したアンプのハードウェア構成を示す図である。
【図４】図１に示したデジタルミキサのハードウェア構成を示す図である。
【図５】図１に示した通信システムにおいて、被制御装置のカレントメモリの内容を変更する際の動作の手順の説明図である。
【図６】図５に示した手順を実行する際に制御装置と被制御装置との間で用いる通信プロトコルの説明図である。
【図７】図１に示した通信システムにおける制御装置と被制御装置との間の通信シーケンスの例を示す図である。
【図８】その別の例を示す図である。
【図９】被制御装置が記憶するデータの例を示す図である。
【図１０】制御装置が記憶するデータの例を示す図である。
【００１９】
【図１１】制御装置が実行するリモート制御準備処理のフローチャートである。
【図１２】制御装置が実行する同期化処理のフローチャートである。
【図１３】仮想カレントメモリの内容を表示する画面の例を示す図である。
【図１４】制御装置がパラメータの変更指示を検出した場合に制御装置及び被制御装置が実行する処理のフローチャートである。
【図１５】被制御装置がパラメータの変更指示を検出した場合に実行する処理のフローチャートである。
【図１６】被制御装置が実行する更新情報送信処理のフローチャートである。
【図１７】制御装置が実行する、マルチキャストアドレス宛のパケットを受信した場合の処理のフローチャートである。
【図１８】制御装置及び被制御装置が実行する、被制御装置からマルチキャストで送信されてくるパケットの受信にエラーを検出した場合の処理のフローチャートである。
【図１９】制御装置がマルチキャストで送信されてくるパケットの受信のエラーを検出するタイミングについて説明するための図である。
【図２０】被制御装置が実行する同期データ送信処理のフローチャートである。
【００２０】
【図２１】制御装置が被制御装置から同期データを受信した場合に実行する処理のフローチャートである。
【図２２】図２１に示した再同期化処理のフローチャートである。
【図２３】制御装置が実行する送信要求の再送処理のフローチャートである。
【発明を実施するための形態】
【００２１】
以下、この発明を実施するための形態を図面に基づいて具体的に説明する。
まず図１に、この発明のリモート制御システムの実施形態である通信システムの概略構成を示す。
この図に示すように、通信システム１は、ＰＣ１０ａ〜１０ｃ，アンプ２０ａ，２０ｂ，デジタルミキサ３０，入出力装置４０，エフェクタ５０を、制御ネットワーク６０により接続して構成している。また、ＰＣ１０ａ〜１０ｃ以外の各装置は、音響信号処理装置であり、これらの装置はオーディオネットワーク７０によっても接続している（アルファベット付きの符号で示した装置につき、個体を特定しない場合にはアルファベットなしの符号を用いる）。
【００２２】
また、制御ネットワーク６０は、接続される各装置の間で、要求（コマンド）、要求に対する応答、通知等のパケットを送受信するため、ユニキャスト送信とマルチキャスト送信の双方が可能なネットワークである。オーディオネットワーク７０は、接続される各装置の間で、オーディオ形式のデジタル波形データ（音響信号）をリアルタイムで送受信するためのネットワークである。ただし、本発明は、制御ネットワークに関するものであり、オーディオネットワークは必須ではない。例えば、オーディオ信号の伝送が必要な各２装置間をそれぞれケーブルで結び、オーディオネットワーク無しのシステムとしてもよい。
また、どちらのネットワークも、これらのデータが送受信可能であれば、ハードウェアや接続トポロジー等は任意のものでよい。有線か無線かも問わない。ただし、この発明は、比較的通信が途切れ易い、無線通信を行うシステムに適用すると特に効果が大きい。
【００２３】
制御ネットワーク６０の通信プロトコルについては、ＯＳＩ参照モデルのネットワーク層にイーサネットを使用する場合、トランスポート層にはＴＣＰ（Transmission Control Protocol）やＵＤＰ（User Datagram Protocol）を用いることが一般的である。その場合、ＴＣＰを用いたユニキャスト送信は、ＴＣＰが提供する到達保証により信頼性の高いデータ送信が可能であるが、ＵＤＰを用いたマルチキャスト送信では、それだけでは何の到達保証も提供されておらず、データが届いたかどうか判断できない。本発明は、このようなマルチキャスト送信に、ネットワークの帯域を大きく消費したり、被制御装置に大きな負担をかけることなく、ある一定レベルの到達保証を与えるものである。
【００２４】
なお、ユニキャスト送信ないしマルチキャスト送信に使用するトランスポート層のプロトコルは、必ずしもＴＣＰとＵＤＰでなくてもよい。ユニキャスト送信に関しては、ＴＣＰに限らず、到達保証が提供されている場合が多く、マルチキャスト送信に関しては、ＵＤＰに限らず到達保証が提供されていない場合が多い。
なお、オーディオネットワーク７０については、Cobranet（商標）やEtherSound（商標）やDante（商標）などを適宜用いればよい。
【００２５】
また、通信システム１を構成する装置のうち、ＰＣ１０が制御装置であり、アンプ２０、デジタルミキサ３０，入出力装置４０，エフェクタ５０が、ＰＣ１０によりパラメータの値を制御される被制御装置である。
以下、これらのうち代表としてＰＣ１０、アンプ２０及びデジタルミキサ３０について、ハードウェア構成を説明する。
【００２６】
まず図２に、所定の基本ソフト（ＯＳ：オペレーション・システム）が走るＰＣ１０のハードウェア構成を示す。
図２に示すように、ＰＣ１０は、ＣＰＵ１０１，ＲＯＭ１０２，ＲＡＭ１０３，ＨＤＤ（ハードディスクドライブ）１０４，表示器１０５，入力装置１０６，ネットワークＩ／Ｆ１０７を備え、これらをシステムバス１０８により接続している。
【００２７】
そして、ＣＰＵ１０１が、基本ソフト上で所要のリモート制御用のアプリケーションプログラム（リモート制御プログラム）を実行することにより、ＰＣ１０全体を制御し、ユーザの操作に従って被制御装置に対してパラメータの値の変更を要求する、被制御装置からの通知に基づいてＰＣ１０と被制御装置との間でパラメータの値の同期を取る等の、後述する制御装置としての機能を始め、種々の機能を実現する。
【００２８】
また、制御装置としての動作のために、ＣＰＵ１０１がＲＡＭ１０３中に用意し使用するデータ（図１０）は、リモート制御プログラムの停止時に、ユーザのセーブ操作に応じて、ないし、自動的に、設定ファイルとしてＨＤＤ１０４に保存される。そして、ＨＤＤ１０４に記憶された設定ファイルは、リモート制御プログラムの次の起動時に、ユーザのロード操作に応じて、ないし、自動的にＲＡＭ１０３に読み込まれる。
【００２９】
表示器１０５は、ユーザに情報を提示するためのディスプレイ等の表示手段である。
入力装置１０６は、ユーザからの操作を受け付けるためのキーボードやポインティングデバイス等の入力手段である。
ネットワークＩ／Ｆ１０７は、ＰＣ１０を制御ネットワーク６０に接続するためのインタフェースである。
これらの構成については、ハードウェアとしては公知のものを適宜採用すればよい。
【００３０】
次に、図３に、アンプ２０のハードウェア構成を示す。
図３に示すように、アンプ２０は、ＣＰＵ２０１，ＲＯＭ２０２，ＲＡＭ２０３，ネットワークＩ／Ｆ２０４，簡易ＵＩ（ユーザインタフェース）２０５，オーディオ入出力部２０６，ＤＳＰ（デジタルシグナルプロセッサ）２０７，アンプ回路２０８を備え、これらをシステムバス２０９により接続している。また、ネットワークＩ／Ｆ２０４、オーディオ入出力部２０６及びＤＳＰ２０７は、デジタル波形データ伝送用のオーディオバス２１０によっても接続している。
【００３１】
そして、ＣＰＵ２０１が、ＲＡＭ２０３をワークメモリとしてＲＯＭ２０２に記憶している所要のプログラムを実行することにより、アンプ２０全体を制御し、制御装置からの要求に基づいてＲＡＭ２０３上に設けられたカレントメモリに記憶しているパラメータの値を変更する、その変更の結果を制御装置に通知する等の、後述する被制御装置としての機能や、ＤＳＰ２０７及びアンプ回路２０８における信号処理を制御する機能等、種々の機能を実現する。
【００３２】
ネットワークＩ／Ｆ２０４は、アンプ２０を制御ネットワーク６０及びオーディオネットワーク７０に接続するためのインタフェースである。オーディオネットワーク７０を介してアンプ２０が受信し、アンプ２０において処理する音響信号は、ネットワークＩ／Ｆ２０４がオーディオバス２１０に供給する。逆に、アンプ２０からオーディオネットワーク７０に送出する音響信号は、ネットワークＩ／Ｆ２０４がオーディオバス２１０から読み出してオーディオネットワーク７０へ送出する。
【００３３】
簡易ＵＩ２０５は、ユーザによる操作を受け付けるための、少数のボタン及び小型の表示器等からなる操作部である。アンプ２０の操作は、ほぼ全て制御装置からのリモート制御により行うことができるようにしているため、アンプ２０に設けるＵＩは簡単なものでよい。
【００３４】
オーディオ入出力部２０６は、外部のマイク、ミキサ、エフェクタ、入出力装置、レコーダ等の音響機器と接続し、これらの音響機器からデジタルないしアナログの音響信号の入力を受け付けるための入力端子と、これらの音響機器へデジタルないしアナログの音響信号を出力するための出力端子とを有する。外部からオーディオ入出力部２０６に入力する音響信号はオーディオバス２１０に供給し、オーディオ入出力部２０６から外部へ出力する音響信号はオーディオバス２１０から読み出して取得する。なお、外部からオーディオ入出力部２０６に入力するアナログ音響信号は、アナログ信号のままアンプ回路２０８に供給することも可能である。
【００３５】
ＤＳＰ２０７は、信号処理回路を含み、オーディオバス２１０から入力する複数の音響信号に対し、カレントメモリに設定されている各種処理パラメータに従って、ミキサ、コンプレッサ、イコライザ、チャンネルディバイダ、アッテネータ、ディレイ等の何れか１ないし複数の各種信号処理を施した上で、デジタル信号のままないしアナログ信号に変換し、アンプ回路２０８に出力する信号処理部である。すなわち、アンプ回路２０８で電力増幅すべき信号に対し、前処理としての特性調整を行う機能を有する。
アンプ回路２０８は、オーディオ入出力部２０６あるいはＤＳＰ２０７から供給されるアナログ音響信号に対し、電力増幅を行って出力する回路である。そして、アンプ回路２０８からの出力信号は、スピーカに供給され、音声として出力される。
【００３６】
以上のアンプ２０において、ＤＳＰ２０７で実行する信号処理や、アンプ回路２０８における電力増幅、オーディオ入出力部２０６及びネットワークＩ／Ｆ２０４における入出力ポートとＤＳＰ２０７の信号処理ｃｈとの間の信号伝送経路（パッチ）等の、アンプ２０が実行する音響信号処理の内容を規定するパラメータの値は、ＲＡＭ２０３に設けたカレントメモリに記憶されており、ユーザは、ＰＣ１０等の制御装置を操作することにより、そのパラメータの値をリモートで変更したり確認したりすることができる。
【００３７】
また、図４に、デジタルミキサ３０のハードウェア構成を示す。
図４に示すように、デジタルミキサ３０は、ＣＰＵ３０１，ＲＯＭ３０２，ＲＡＭ３０３，ネットワークＩ／Ｆ３０４，パネル表示器３０５，パネル操作子３０６，電動フェーダ３０７，オーディオ入出力部３０８，ＤＳＰ３０９を備え、これらをシステムバス３１０により接続している。また、ネットワークＩ／Ｆ３０４、オーディオ入出力部３０８及びＤＳＰ３０９は、デジタル波形データ伝送用のオーディオバス３１１によっても接続している。
【００３８】
そして、ＣＰＵ３０１が、ＲＡＭ３０３をワークメモリとしてＲＯＭ３０２に記憶している所要のプログラムを実行することにより、デジタルミキサ３０全体を制御し、後述する被制御装置としての機能や、ＤＳＰ３０９における信号処理の制御や、パネル操作子３０６及び電動フェーダ３０７により受け付けたユーザの操作に従ったパラメータの値の制御に関する機能を始め、種々の機能を実現する。
ネットワークＩ／Ｆ３０４は、アンプ２０の場合と同様に、デジタルミキサ３０を制御ネットワーク６０及びオーディオネットワーク７０に接続するためのインタフェースである。
【００３９】
パネル表示器３０５は、ＣＰＵ３０１による制御に従って種々の情報を表示する表示手段であり、例えば液晶パネル（ＬＣＤ）や発光ダイオード（ＬＥＤ）によって構成することができる。
パネル操作子３０６は、デジタルミキサ３０に対する操作を受け付けるためのものであり、種々のキー、ボタン、ロータリーエンコーダ、スライダ等によって構成することができる。ＬＣＤに積層したタッチパネル等を用い、パネル表示器３０５と一体化した構成とすることもできる。
【００４０】
電動フェーダ３０７は、モータ等の駆動手段を備えたスライダ操作子であり、ＣＰＵ３０１の制御により、つまみを任意の位置に移動させることができる。
デジタルミキサ３０においては、制御装置からのリモート制御の他、ユーザが直接デジタルミキサ３０を操作してローカルでパラメータの値を編集することも想定し、これらのように、パラメータの値の操作や参照のための多数の操作子や大型の表示器を設けている。
【００４１】
オーディオ入出力部３０８は、外部のマイク、エフェクタ、入出力装置、アンプ、レコーダ等の音響機器と接続し、これらの音響機器からデジタルないしアナログの音響信号の入力を受け付けるための入力端子と、これらの音響機器へデジタルないしアナログの音響信号を出力するための出力端子とを有する。外部からオーディオ入出力部３０８に入力する音響信号はオーディオバス３１１に供給し、オーディオ入出力部３０８から外部へ出力する音響信号はオーディオバス３１１から読み出して取得する。
【００４２】
ＤＳＰ３０９は、信号処理回路を含み、オーディオバス３１１から入力する複数の音響信号に対し、カレントメモリに設定されている各種処理パラメータに従って、複数の各入力チャンネルにおけるその音響信号の特性制御処理、複数の各混合バスにおける入力チャンネルからの音響信号の混合処理、複数の各出力チャンネルにおける混合バスからの音響信号の特性制御処理等を含む信号処理（ミキシング処理）を施した上でオーディオバス３１１へ出力する機能を有する。
【００４３】
以上のデジタルミキサ３０において、ＤＳＰ３０９で実行する信号処理や、オーディオ入出力部３０８及びネットワークＩ／Ｆ３０４における入出力ポートとＤＳＰ３０９の信号処理ｃｈとの間の信号伝送経路（パッチ）等の内容を規定するパラメータの値は、ＲＡＭ３０３に設けたカレントメモリに記憶されている。ユーザは、パネル表示器３０５、パネル操作子３０６及び電動フェーダ３０７を用いる他、ＰＣ１０等の制御装置を操作することによっても、そのパラメータの値をリモートで変更したり確認したりすることができる。
【００４４】
なお、アンプ２０、デジタルミキサ３０等の被制御装置のカレントメモリのパラメータは、図示しないバッテリーによるバックアップや、図示しないフラッシュメモリによるバックアップによって、電源を落としたときに失われず、電源を再投入したとき復活できるようにしておくとよい。また、被制御装置のオーディオネットワーク７０への接続は必須ではなく、ネットワークＩ／Ｆ２０４、３０４は、それぞれ、制御ネットワーク６０にのみ接続されるようにしてもよい。
【００４５】
この実施形態の特徴は、複数の制御装置により１又は複数の被制御装置のパラメータの値を制御する場合において、ある制御装置からの指示により被制御装置が行ったパラメータの値の変更を、他の制御装置に伝達する手法である。そこで、次にこの点について説明する。
まず図５に、通信システム１における、被制御装置のカレントメモリに記憶されているパラメータの値（カレントメモリの内容）を変更する際の動作の手順を示す。
【００４６】
なお、以下の説明については、通信システム１を構成する装置のうち、パラメータの値の変更を他の装置に指示する装置（図１の例ではＰＣ１０）を制御装置２と、制御装置２からの指示に応じてパラメータの値を変更し、その内容を制御装置に伝達する装置（図１の例ではアンプ２０ａ，２０ｂ，デジタルミキサ３０，入出力装置４０，エフェクタ５０）を被制御装置３と呼ぶことにする。
また、図５においては、制御装置２が受け付けた操作に基づきリモート制御で被制御装置３のカレントメモリ３ａの内容を変更する場合の手順を実線で、被制御装置３自身が受け付けた操作に基づきローカルでカレントメモリ３ａの内容を変更する場合の手順を破線で示した。
【００４７】
通信システム１において、図５に示すように、各制御装置２，２は、ＲＡＭ１０３上に、自身が制御する（又はモニタする）被制御装置３のカレントメモリ３ａと同じ内容を記憶する、仮想カレントメモリ２ａを備えている。そして、初めに被制御装置３の制御を開始する際に、仮想カレントメモリ２ａの内容とカレントメモリ３ａの内容とを一致させ、以後、制御を継続する間はその状態を保つようにする。
【００４８】
このカレントメモリ３ａと仮想カレントメモリ２ａの記憶内容を相互に「一致させる」動作を「同期化」と言い、「一致した状態が保たれている」状態を「同期している」と言う。リモート制御プログラムに基づいて、ＣＰＵ１０１は、各被制御装置３に対応する仮想カレントメモリ２ａを用意し、その仮想カレントメモリ２ａに記憶されているパラメータを表示器１０５に表示し、或いは、ユーザからの編集操作に応じてその仮想カレントメモリ２ａに記憶されているパラメータの値を変更する。すなわち、パラメータに関して、ＰＣ１０の内部に、被制御装置３に対応する仮想的なデバイスが存在していると看做すことができる。
【００４９】
そして、制御装置２が、ユーザから被制御装置３におけるパラメータの値の変更を指示する操作を受け付けると、まずその変更を仮想カレントメモリ２ａに対して行う。その後、被制御装置３に対して変更命令を送信し、カレントメモリ３ａの内容を変更するよう要求する。ここで、先に仮想カレントメモリ２ａの内容を変更するのは、被制御装置３との通信に時間がかかる場合でも、仮想カレントメモリ２ａの内容に基づき、ユーザから受け付けた操作の結果（変更後のパラメータの値）をレスポンスよく表示するためである。
【００５０】
また、変更命令を受信した被制御装置３は、その変更命令に従ってカレントメモリ３ａの内容を変更すると共に、その変更の内容又は変更後のパラメータの値を、更新情報として、自身を制御している各制御装置２に送信する。
そして、この更新情報を受信した制御装置２がその更新情報に従って仮想カレントメモリ２ａの内容を更新することにより、変更操作を受け付けていない制御装置２においても、被制御装置３とカレントメモリの内容が同期した状態を維持することができる。
【００５１】
なお、変更操作を受け付けた制御装置２に対しては、更新情報の送信は行わなくてもよいが、送信を行えば、変更命令に従ったカレントメモリ３ａの内容の変更が確かに行われたことを確認できる。
一方、被制御装置３がユーザから被制御装置３自身におけるパラメータの値の変更を指示する操作を受け付けると、被制御装置３は、まずその変更をカレントメモリ３ａの内容に対して行う。そしてその後、その変更の内容又は変更後のパラメータの値を、更新情報として、自身を制御している各制御装置２に送信する。
【００５２】
そして、この更新情報を受信した制御装置２がその更新情報に従って仮想カレントメモリ２ａの内容を更新することにより、各制御装置２と被制御装置３とでカレントメモリの内容が同期した状態を維持することができる。
更新情報の送信とそれに伴う仮想カレントメモリ２ａの内容変更は、実線の場合も破線の場合も、同じように行うことができる。
また、全部又は一部の制御装置２を、被制御装置３に対してパラメータの値の変更を要求せず、単に被制御装置３とカレントメモリの内容を同期させてその内容を監視する装置として機能させることもできる。
【００５３】
次に図６に、通信システム１において、図５に示した手順を実行する際に制御装置と被制御装置との間で用いる通信プロトコルを示す。
図６に示すように、通信システム１においては、制御装置２と被制御装置３との間でのリモート制御に関するデータの送受信には、ユニキャストと、マルチキャストとを用いる。
【００５４】
このうちユニキャストは、データを、１つの送信先に対応する１つのアドレス宛てに送信するものである。ここでは、送信元装置と送信先装置との間にコネクションを形成し、パケットに対するシーケンス番号の付与や確認応答の返送などにより、送信元装置が、データが送信先装置に到達したことを確認でき、データが到達できなかった場合には再送信を行う、到達保証の機能を有するコネクション型の通信プロトコルが用いられる。このようなプロトコルとしては、例えばＴＣＰを用いることができる。
【００５５】
またマルチキャストは、データを、複数の送信先に対応する１つのアドレス宛てに送信するものである。ここでは、コネクションの形成を行わず、データの到達保証も提供しない代わりに、高速にデータを届けることができるコネクションレス型の通信プロトコルが用いられる。このようなプロトコルとしては、例えばＵＤＰを用いることができる。一般に、マルチキャストにおいては、送信先装置に確実にデータが到達することは保証されない。しかし、マルチキャストは、ユニキャストに比べ、同じサイズのデータを送信先に到達させるために必要な通信量が小さく、ネットワークの通信帯域に対する負荷が小さいという特性がある。
【００５６】
そこで、この実施形態においては、確実に送信先に到達させる必要がある、制御装置２から被制御装置３への変更命令の送信は到達保証のあるユニキャスト送信により送信し、多少データのロストがあっても動作に大きな支障がない、被制御装置３から制御装置２への更新情報の送信はマルチキャスト送信で行い、そのマルチキャスト送信の際に生じるデータの欠落を補正する機能を別途設けることにより、通信の帯域及び負荷低減とデータ伝送の安定性の両立を図ったものである。
【００５７】
次に、このデータ欠落の補正機能の概略について説明する。
図７及び図８に、通信システム１における制御装置２と被制御装置３との間の通信シーケンスの例を示す。
図７に示すのは、被制御装置３のカレントメモリ３ａの内容を変更する際の通信シーケンスであり、ステップＳ１１〜Ｓ１７が、制御装置２によりリモートで変更する場合、ステップＳ２１〜Ｓ２６が、被制御装置３がローカルで変更操作を受け付けた場合の例である。
【００５８】
詳細については図５の説明と重複するので省略するが、リモートの場合もローカルの場合も、被制御装置３は、カレントメモリ３ａに記憶しているパラメータの値を変更すると、そのパラメータのＩＤを記憶しておく（Ｓ１５，Ｓ２３）。この点が、１つのポイントとなる。
【００５９】
また、図８に示すのは、１つの制御装置２と被制御装置３との間の関係に着目し、図７よりも長いスパンで見た、制御装置２と被制御装置３との間でのデータ送受信のシーケンスである。
図５及び図７に示した通り、被制御装置３は、カレントメモリ３ａの内容を変更すると、その内容を、被制御装置３を制御又は監視している制御装置２に通知すべく、更新情報ＵＰＤＡＴＥを制御装置２にマルチキャストで送信する（Ｓ３２，Ｓ３３，Ｓ３５〜Ｓ３７）。
【００６０】
また、被制御装置３は、これとは別に、定期的に、同期データＳＹＮＣを、被制御装置３を制御又は監視している各制御装置２に送信する（Ｓ３１，Ｓ３４）。この送信も、マルチキャストで行う。そして、被制御装置３が同期データＳＹＮＣを送信してから次に同期データＳＹＮＣを送信するまでの期間を、１つの同期期間と定める。この同期期間は、データ欠落を補正する際のその補正処理の実行単位を定めるものであり、同期データＳＹＮＣは、この同期期間を制御装置２に伝達するためのデータである。
【００６１】
ここで、更新情報ＵＰＤＡＴＥも、同期データＳＹＮＣも、マルチキャストで送信するため、被制御装置３が送信したデータが制御装置２に到達しない場合がある（Ｓ３５，Ｓ３６）。しかし、例えば被制御装置３が、マルチキャストで送信するパケットに通し番号を付すようにすれば、制御装置２側で、その通し番号の連続性を確認することにより、受信エラーの有無を判断することができる。
【００６２】
そして、制御装置２が受信エラーを検出した場合（Ｓ３８）、パケットを全て正常に受信できていた最後の同期期間の次の同期期間を特定し（Ｓ３９）、特定された同期期間以降の１又は複数の同期期間において変更されたパラメータの情報を要求する送信要求ＲＥＱ＿ＳＹＮＣを、被制御装置３に送信する（Ｓ４０）。この送信要求は、確実に被制御装置３に到達させる必要があるため、ユニキャストで送信する。
【００６３】
また、被制御装置３は、送信要求ＲＥＱ＿ＳＹＮＣを受信すると、その送信要求で要求された各同期期間において値が変更されたパラメータを、図７のステップＳ１５及びＳ２３で記憶したＩＤに基づき特定する（Ｓ４１）。そして、その特定したパラメータの現在値を、次に送信する同期データＳＹＮＣに含めて制御装置２に送信する（Ｓ４２，Ｓ４３）。
この同期データＳＹＮＣを受信した制御装置２は、受信した同期データに含まれるパラメータの現在値に基づき仮想カレントメモリ２ａの内容を訂正する（Ｓ４４）。
【００６４】
以上のステップＳ３９乃至Ｓ４４の処理により、更新情報ＵＰＤＡＴＥが受信できなかった期間に値が変更されたパラメータについて、カレントメモリ３ａにおける最新の値を仮想カレントメモリ２ａに記憶させることができる。従って、更新情報ＵＰＤＡＴＥの欠落により損なわれたと考えられる仮想カレントメモリ２ａとカレントメモリ３ａの同期を、回復させることができる。
【００６５】
以下、この更新情報ＵＰＤＡＴＥ及び同期データＳＹＮＣを用いたデータの伝送エラーの補正のために制御装置２及び被制御装置３のＣＰＵが実行する処理につき、詳細に説明する。
まず、図９及び図１０に、被制御装置３及び制御装置２が記憶する、この通信エラーの補正の処理に使用するデータを示す。
被制御装置３は、ＲＡＭ２０３、３０３に、図９に示すような、機種ＩＤ、デバイスＩＤ、ＩＰ(Internet Protocol)アドレス、同期ＩＤ（ＳＩＤ）、マルチキャストＩＤ（ＭＩＤ）、動作パラメータ、マルチキャストグループ情報、その他各種レジスタの値を記憶する。
【００６６】
これらのうち機種ＩＤは、被制御装置３の機種を示す識別情報であり、被制御装置３のメーカーが設定する値である。
デバイスＩＤは、被制御装置３の個体を識別するための識別情報であり、ユーザが設定可能な値である。従って、被制御装置３毎に必ずしもユニークな値となるとは限らず、複数の被制御装置３に同じデバイスＩＤが設定されている場合がある。
ＩＰアドレスは、ユニキャストの送信先として被制御装置３を指定する際に用いるアドレスである。
【００６７】
同期ＩＤは、現在の同期期間が何番目の同期期間であるかを示す番号であり、同期期間毎に変化させる。
マルチキャストＩＤは、被制御装置３が次にマルチキャストするパケットに付す連続番号であり、パケットをマルチキャストする度に変化させる。
動作パラメータは、被制御装置３が音響信号処理に使用するパラメータであり、これを記憶する領域がカレントメモリ３ａに当たる。被制御装置３の各パラメータは、その被制御装置の内部でユニークなＩＤ（ｐＩＤと呼ぶ）により特定される。
【００６８】
マルチキャストグループ情報は、被制御装置３を制御する制御装置２に対してパケットをマルチキャストするために使用するマルチキャストアドレスを示す情報である。これに対応して、制御装置２側では、どのアドレスにマルチキャストされたパケットを受信するかを設定しておく。
【００６９】
そして、例えば、ある５台の制御装置２ａ〜２ｅがあって、うち３台の制御装置２ａ，２ｂ，２ｃはアドレスＡ宛てにマルチキャストされたパケットを受信し、また、３台の制御装置２ａ，２ｃ，２ｄはアドレスＢ宛てにマルチキャストされたパケットを受信するよう設定されていたとすると、ある被制御装置３ａは、マルチキャストの送信先アドレスとしてアドレスＡを指定することにより、制御装置２ａ，２ｂ，２ｃのみに対してパケットを送信できる。また、別の被制御装置３ｂは、アドレスＢ宛てにマルチキャスト送信することにより、制御装置２ａ，２ｃ，２ｄのみに対してパケットを選択的に送信できる。
すなわち、１つのグループに対応する１つのグループアドレスが宛先として記載された１つのＩＰパケットは、そのグループに属する複数の制御装置によって、選択的に、かつ、同時に受信されるのである。
【００７０】
このように、通信システム１においては、１つの被制御装置につき１つのマルチキャストアドレスに対する送信で、被制御装置を制御又は監視する全ての制御装置２に対してパケットを送信できるように、マルチキャストグループが定められている。１つの被管理装置が同じデータを複数のアドレス宛てに送信すると、ネットワークの通信帯域をよけいに消費するだけでなく、その被制御装置のＣＰＵにより負担をかけることになるからである。
各種レジスタは、通信エラーの補正のための処理において随時内容を変更する変数が記憶されており、詳細についてはフローチャートの説明において後述する。
【００７１】
一方、制御装置２は、ＲＡＭ１０３に、図１０に示すような、仮想デバイス数、仮想デバイスデータ、各機種のパラメータ構成情報、ＩＰアドレス、マルチキャストグループ情報、その他各種レジスタの値を記憶する。
制御装置２では、用意された複数機種のデバイスのライブラリ中から、ユーザが、制御又は監視の対象としようとする機種を、それぞれ、任意数、仮想デバイスとして選択して登録することができる。そして、制御装置２は、ＲＡＭ１０３中に、登録された各仮想デバイスの仮想デバイスデータの記憶領域を用意するとともに、登録された仮想デバイスの数Ｎｕｍを記録する。
【００７２】
なお、ある制御装置２に、ある被制御装置３と同じ機種の仮想デバイスが登録され、対応する仮想デバイスデータが用意されていたとしても、その制御装置２が、その被制御装置３を制御可能（ないし監視可能）であるとは限らない。その被制御装置３が制御ネットワークに接続されていない場合には、当然ながら制御（ないし監視）できないし、接続されていたとしても、その被制御装置３との対応付けがされていなければ、その被制御装置３は制御（ないし監視）の対象とならない。
【００７３】
制御装置２への仮想デバイスの登録は、各制御装置毎に独立であり、ある制御装置に登録されている仮想デバイスが、他の制御装置には登録されていなくてもよい。また、各制御装置毎に、制御又は監視の対象とする被制御デバイス３を異ならせたい場合があるので、登録された仮想デバイスと被制御装置３との対応付けについては、各制御装置毎に独立にできるようにするとよい。
【００７４】
また、各仮想デバイスデータは、機種ＩＤ、デバイスＩＤ（省略形：ｄＩＤ）、ＩＰアドレス、同期ＩＤ、マルチキャストＩＤ、動作パラメータ、オンラインフラグ、同期状態を含む。
このうち機種ＩＤ、デバイスＩＤ、ＩＰアドレスについては、後述の図１１の処理で仮想デバイスと対応づけるべき被制御装置３を特定するための情報である。制御装置２は、各仮想デバイスに対し、制御ネットワークに接続された被制御デバイス３のうち、機種ＩＤとデバイスＩＤとＩＰアドレスとが一致する被制御デバイス３を自動的に対応付け、３つともが一致する被制御デバイス３が存在しない場合は、機種ＩＤとデバイスＩＤが一致する被制御デバイス３の何れか１つを、ユーザの指示に従って対応付け、その被制御デバイスのＩＰアドレスを、その仮想デバイスデータ領域にＩＰアドレスとして記憶する。
【００７５】
同期ＩＤ及びマルチキャストＩＤは、被制御装置３から受信したデータに基づいて把握した、被制御装置３における最新の同期ＩＤ及びマルチキャストＩＤの値である。これらの値は仮想デバイス毎に管理するため、ｄＩＤで特定される仮想デバイスについてのデータという意味で、図１０にはそれぞれＳＩＤ（ｄＩＤ）及びＭＩＤ（ｄＩＤ）と表記した。
【００７６】
この「ｄＩＤ」は、各制御装置２内の複数の仮想デバイスに同じｄＩＤが付与されないよう（ユニークとなるよう）管理されており、従って、「ｄＩＤ」を、各制御装置における１つの仮想デバイスを特定するＩＤであると捉えることができる。なお、制御装置２の各仮想デバイスの同期ＩＤ及びマルチキャストＩＤは、後述の通り、その対応付けられた被制御装置３側で管理されている同期ＩＤやマルチキャストＩＤと常に一致しているとは限らない。
【００７７】
動作パラメータは、被制御装置３側のカレントメモリ３ａと内容を同期させる仮想カレントメモリ２ａに当たる。なお、制御装置２が記憶する「各機種のパラメータ構成情報」が、各機種の被制御装置３におけるカレントメモリ３ａのパラメータ構成を示し、この情報と機種ＩＤとに基づき、制御装置２側でカレントメモリ３ａと同じパラメータ構成を有する仮想カレントメモリ２ａの記憶領域を確保している。従って、記憶されている各パラメータは、被制御装置３側と同様に、ｐＩＤで特定することができる。
【００７８】
オンラインフラグＯＦ（ｄＩＤ）は、仮想デバイス（と対応付けた被制御装置３）が制御装置２からリモート制御可能な状態（オンライン）であるか否かを示すフラグである。
同期状態ＳＳ（ｄＩＤ）は、仮想カレントメモリの内容が、仮想デバイスと対応付けた被制御装置３のカレントメモリの内容と一致しているか（カレントメモリの同期が取れているか）否かを示すフラグである。ただし、一致と不一致以外にも、データ欠落の補正により一致状態に復帰可能な「一時的に不一致」の値も取ることができる。
以上の仮想デバイスデータは、ユーザの操作により又は自動的に、制御対象になり得る被制御装置が仮想デバイスとして制御装置２に登録された時点で制御装置２のＣＰＵが作成し、保存する。
【００７９】
また、左側のカラムに示したＩＰアドレスは、制御装置２のＩＰアドレスである。
マルチキャストグループ情報は、制御装置２がどのアドレスにマルチキャストされたパケットを受信するかの設定、すなわち、受信すべきマルチキャストアドレスの設定であり、各制御装置には、複数のマルチキャストアドレスを設定することができる。
各種レジスタは、通信エラーの補正のための処理において随時値が変更される各種変数が記憶され、詳細についてはフローチャートの説明において後述する。
【００８０】
以下、これらのデータを用いた処理の内容を、フローチャートを用いて説明する。なお、以下の説明において、各処理は、制御装置２又は被制御装置３が実行するとして説明するが、実際には、制御装置２又は被制御装置３のＣＰＵが所要のプログラムを実行することにより行うものである。
【００８１】
まず、図１１に、制御装置２のＣＰＵ１０１が実行するリモート制御準備処理のフローチャートを示す。この処理は、制御装置２が通信システム１を構成するネットワークに新たに接続され、その制御装置２がそのネットワークに接続されている被制御装置３を検出したとき（一通り終わるまで待ってからでもよい）、制御ネットワーク６０に接続されたＰＣ１０においてリモート制御プログラムが起動され、設定ファイルが読み込まれ制御装置２としての動作を開始したとき、制御ネットワーク６０全体のリセットが指示されたとき、等に実行されるものである。
【００８２】
そして、これらの場合、制御装置２は自動的に図１１に示す処理を開始する。
図１１の処理において、制御装置２はまず、複数の仮想デバイスデータを含む制御ファイルを読み込み、そこに登録されている仮想デバイスのプロセスを起動するとともに、ＲＡＭ１０３中に、対応する仮想デバイスデータの記憶領域を用意して設定ファイルの対応するデータを書き込む（Ｓ１０１）。このプロセスは仮想デバイスデータの管理及び対応付けられた被制御装置３との通信を担うプロセスであり、その起動により、制御装置２中に仮想デバイスが生成される。
【００８３】
次に、ステップＳ１０１で生成された各仮想デバイスに対し、制御ネットワーク上で検出された被制御装置３（現実のデバイス）のいずれか１を対応付ける（Ｓ１０２）。ここでは、機種ＩＤ、デバイスＩＤ、ＩＰアドレス等を制御ネットワークに接続された全ての被制御装置３から収集し、各仮想デバイスに対し、これらの情報が一致する被制御装置を自動的に対応付ける。
そして、全仮想デバイスについて、ＯＦ（ｄＩＤ）及びＳＳ（ｄＩＤ）に初期値として０を設定し、後述するオンラインランプ４０２及び同期ランプ４０３を消灯して、処理を終了する（Ｓ１０３）。なお、ＯＦ（ｄＩＤ）及びＳＳ（ｄＩＤ）が取り得る値とその意味は、表１に示す通りである。
【００８４】
【表１】
0005533504.tif 000002
【００８５】
以上の処理により、制御装置２は、自身に登録されている仮想デバイスの中で、対応する現実のデバイス（被制御装置３）が通信可能な位置に存在しているものを特定し、リモート制御の準備をすることができる。
【００８６】
次に、図１２に、制御装置２のＣＰＵ１０１が実行する同期化処理のフローチャートを示す。この同期化処理は、制御装置２による被制御装置３のリモート制御（又は被制御装置３の状態監視）を開始するための処理である。
制御装置２は、ユーザからｄＩＤで特定される仮想デバイスのリモート制御を開始する指示を受け付けると、図１２に示す処理を開始する。なお、リモート制御開始の指示は、仮想デバイス毎ではなく、仮想デバイスのグループについて一括して行うことも可能である。その場合、そのグループを構成する各仮想デバイスについて、図１２の処理を実行する。
【００８７】
図１２の処理においては、制御装置２は、そのｄＩＤで特定される仮想デバイスが図１１の処理でいずれかの被制御装置３と対応付けられていれば（Ｓ１１１のＹＥＳ）、ｄＩＤで特定される仮想デバイスの仮想カレントメモリと、その仮想デバイスと対応付けた被制御装置３のカレントメモリとの間で、ユニキャスト送信を用いて、予め設定された方向に動作データ（パラメータ）をコピー（同期化）する（Ｓ１１２）。ここでは、１パラメータずつコピーするのではなく、全パラメータを１つのパケットに入れて、または分割して数個のパケットに入れて、複数パラメータ一括でのコピー（バルクダンプ）を行うことにより、多数のパラメータのコピーを効率的に短時間で終わらせることができる。
【００８８】
ここで、上述のように、各被制御装置３は、制御装置２に記憶されている仮想カレントメモリのパラメータではなく、被制御装置３自身が記憶しているカレントメモリのパラメータの値に従って信号処理を行う。そこで、この処理の状態を維持することを優先する場合（例えば、稼働中のシステムに後から制御装置２を接続し、そのシステムの動作を継続させたい場合など）には、被制御装置３側から制御装置２側へコピーすればよい。
【００８９】
一方、制御装置２の記憶している仮想デバイスのパラメータに従った信号処理を被制御装置３に行わせたい場合（例えば、新たにシステムを稼動させたい場合や、稼働中のシステムを止めて別の論理構成のシステムを立ち上げたい場合など）は、制御装置２側から被制御装置３側へコピーすればよい。
【００９０】
ユーザは、どちらの方向にコピーを行うかを、全仮想デバイスについて一括して、又は仮想デバイス毎に個別に設定することができる。
どちらの方向へコピーしても、このステップＳ１１２の処理により、仮想カレントメモリの内容がカレントメモリの内容と完全に一致することになる。そして、制御装置２は、このことを示すべくＳＳ（ｄＩＤ）に１を設定し、その仮想デバイスの同期ランプ４０３（後述）を点灯する（Ｓ１１３）。
【００９１】
その後、制御装置２がｄＩＤで特定される仮想デバイスと対応付けた被制御装置３の制御権を有しているか否か判断し（Ｓ１１４）、有していれば、ＯＦ（ｄＩＤ）に１を設定し、その仮想デバイスのオンラインランプ４０２（後述）を点灯して（Ｓ１１５）、その被制御装置３のリモート制御を行う状態に移行する。被制御装置３の制御権は、通信システム１の管理者が、制御装置２毎に、あるいは、制御装置２にログオンするユーザ毎に、制御装置２の表示器１０５及び入力装置１０６を用いて設定可能なものである。各被制御装置３に関して設定された制御権のデータは、その被制御装置３のＲＡＭ２０３，３０３中に保持される。
また、ステップＳ１１１でＮＯの場合や、ステップＳ１１４でＮＯの場合には、そのまま処理を終了する。
【００９２】
以上の処理により、制御装置２は、ｄＩＤで特定される仮想デバイスと対応する被制御装置３のリモート制御（ステップＳ１１４でＹＥＳの場合）ないしリモート監視（同ＮＯの場合）を開始することができる。これ以降、被制御装置３のカレントメモリの何れかのパラメータの値が変更された際には、制御装置２に対してその変更が被制御装置３から通知され、変更通知（後述の更新情報）を受けた制御装置２は、その変更通知に従って、対応する仮想カレントメモリに記憶されている対応するパラメータの値を同じ値に変更する。ある被制御装置３と仮想デバイスとが同期している状態において、制御装置２の対応する仮想カレントメモリには、被制御装置３のカレントメモリに記憶されているパラメータと同じ値のパラメータが記憶されており、制御装置２は、表示器１０５に、仮想カレントメモリのパラメータの値を、被制御装置３のパラメータの値として表示することができる。
【００９３】
なお、カレントメモリが同期化している／していないは、制御装置と被制御装置のペア毎に独立である。また、図示はしていないが、図１２の処理の際、制御装置２は、仮想デバイスと被制御装置３との同期化が完了したとき（Ｓ１１３）、その被制御装置３に対し同期化の完了を通知し、さらに、オンライン化したとき（Ｓ１１５）、その被制御装置３に対しオンライン化の完了を通知する。被制御装置３は、どの制御装置２のどの仮想デバイスと同期状態（ＳＳ（ｄＩＤ）≠０）になったか、および、その仮想デバイスとオンラインになったかを、制御装置２からの通知によって把握可能である。
【００９４】
また、図示はしていないが、マルチキャストを行えるようにするための設定も、ここで行われる。その詳細について説明する。各被制御装置３に対しては、予め、マルチキャスト送信に使用するための相互に異なる１つのアドレスが割り当てられ、そのマルチキャストアドレスが、図９のマルチキャストグループ情報中に記憶されている。また、制御装置２は、各被制御装置３に対して、その被制御装置が使用するマルチキャストアドレスを問い合わせることができる。
【００９５】
図１２において、制御装置２は、ある仮想デバイスとある被制御装置３との同期化が完了したとき（Ｓ１１３）、既知のＩＧＭＰプロトコル（Internet Group Management Protocol）を使用して、制御ネットワーク６０におけるルーティングを制御しているルータ乃至スイッチ（図示せず）に対し、その被制御装置３が使用しているマルチキャストアドレス宛てのパケットを当該制御装置２に配送するよう通知し、かつ、図１０のマルチキャストグループ情報中にそのマルチキャストアドレスを加えて、当該制御装置２がその配送されたパケットを受信するように設定する。
【００９６】
この通知および設定によって、被制御装置３がそのマルチキャストアドレス宛てに送信する更新情報ＵＰＤＡＴＥ及び同期データＳＹＮＣ（詳細は後述する）のパケットが、その被制御装置３と同期状態にある仮想デバイスを有する全ての制御装置２に到達し、受信されるようになる。複数の被制御装置３は相互に異なるマルチキャストアドレスを使用するので、各被制御装置３がマルチキャスト送信したパケットは、その被制御装置と同期した状態にある仮想デバイスを有する１又は複数の制御装置２に選択的に且つ平行して配送され受信される。
【００９７】
また、図１２の処理の結果、１台の制御装置２が複数の被制御装置３を制御又は監視する状態になることもあるし、１台の被制御装置３が複数の制御装置２に制御又は監視される状態になることもある。さらに、１台の制御装置２が複数の被制御装置３の一部を制御し、他の一部を監視する状態になることもあるし、１台の被制御装置３が複数の制御装置２の一部から制御され、他の一部から監視される状態になることもある。
いずれの場合も、ある被制御装置３が送信に用いるマルチキャストアドレス宛のパケットは、その被管理装置３と同期した状態にある仮想デバイスを有する１又は複数の制御装置のみに受信されるように、各制御装置のマルチキャストグループの設定を行うことが好ましい。
【００９８】
ここで、図１３に、仮想カレントメモリの内容を表示する画面の例を示す。
この図に示すパラメータ表示画面４００は、１つの仮想デバイスの仮想カレントメモリのパラメータの値を表示する画面であるが、その仮想デバイスと、対応付けられている被制御装置３とが同期している場合には、その被制御装置３のカレントメモリのパラメータと同じ値のパラメータを表示していることになる。また、この画面においては、ユーザからの、パラメータの値を変更する操作を受け付けることができる。
【００９９】
パラメータ値表示部４１０が、この表示と変更指示の受付を行うエリアである。１つの枠が１つのパラメータの値を示し、つまみやボタン等により、パラメータの値の表示を行っている。また、変更指示は、選択したパラメータを割り当てた操作パネル上の物理操作子や、選択したパラメータについて呼び出したＧＵＩ（グラフィカルユーザインタフェース）等により行うことができる。
また、ページ切り替えボタン４２０により、パラメータ値表示部４１０に表示させるパラメータの種類を変更することもできる。
【０１００】
なお、パラメータ値表示部４１０に表示されるパラメータの値は、カレントメモリの同期が取れている状態では、わずかなタイミングずれを除けば被制御装置３のカレントメモリの内容と完全に一致しているが、後述のように同期が取れていない状態では、カレントメモリの内容と一致しない場合もある。
【０１０１】
また、パラメータ表示画面４００は、当該仮想デバイス（ないし対応付けられた被制御装置３）にユーザが付与した名称を表示するデバイス名表示部４０１、当該仮想デバイスと対応付けられた被制御装置３とがオンラインであるか否かを示すオンラインランプ４０（ＯＦ（ｄＩＤ）が１のとき点灯し、０のとき消灯）、及び、当該仮想デバイスと、対応付けられた被制御装置３とが同期しているか否かを示す同期ランプ４０３（ＳＳ（ｄＩＤ）が１のとき点灯し、０のとき消灯し、２のとき点滅）を有している。オンラインランプ４０２と同期ランプ４０３の表示はリアルタイムで更新され、ユーザは常に最新の状態を把握可能である。
【０１０２】
次に、図１４に、制御装置２がユーザからのパラメータ値の変更操作を受け付けた場合に、制御装置２のＣＰＵ１０１及び被制御装置３のＣＰＵ２０１ないし３０１が実行する処理のフローチャートを示す。
制御装置２は、パラメータ表示画面４００等により、ｄＩＤで特定される仮想デバイス（と対応付けられた被制御装置３）について、ｐＩＤで特定されるパラメータを、変化量ｖａｌ分だけ変化させる操作が行われたことを検出した場合、図１４の左側のフローチャートに示す処理を開始する。
【０１０３】
そしてまず、ＯＦ（ｄＩＤ）＝１かつＳＳ（ｄＩＤ）＝２であるか否か判断する（Ｓ１２１）。これがＹＥＳであれば、そのまま処理を終了する。ユーザの変更操作に係る被制御装置３をリモート制御中の場合は、カレントメモリの同期がとれていない状態では、ユーザは、被制御装置３の実際のパラメータの値とは違うパラメータ値を見て操作している可能性があるため、同期が回復するまでパラメータの値を変更しないように、指示を無視するものである。
なお、リモート制御中であれば、カレントメモリの同期を取っていない（ＳＳ（ｄＩＤ）＝０）ということはないため、リモート制御中（ＯＦ（ｄＩＤ）＝１）の場合であれば、実質、同期が取れている（ＳＳ（ｄＩＤ）＝１）場合のみ以下の処理に進むことになる。また、ステップＳ１２１の分岐は必須ではなく、無条件にＮＯに分岐するように、すなわち、一時的に同期が損なわれていたとしても、それを無視してパラメータ値の変更をできるようにしてもよい。
【０１０４】
またステップＳ１２１でＮＯであれば、ＯＦ（ｄＩＤ）＝０かつＳＳ（ｄＩＤ）≠０であるか否か判断する（Ｓ１２２）。これがＹＥＳである場合も、そのまま処理を終了する。被制御装置３と同期状態にあり（ＳＳ（ｄＩＤ）≠０：一時的に同期が損なわれている場合を含む）、かつ、その被制御装置３をリモート制御中でない場合（ＯＦ（ｄＩＤ）＝０）は、この制御装置２がその被制御装置３をリモート監視中であるということであり、この制御装置３側からのパラメータ値の変更ができないのは当然のことである。他方、同期を取っていない状態（ＳＳ（ｄＩＤ）＝０）であれば、単に制御装置２がローカルで仮想カレントメモリの内容を変更するだけであるので、このような変更は許可する（Ｓ１２２でＮＯになる）ようにしている。
【０１０５】
そして、ステップＳ１２２でもＮＯの場合、すなわち（ＯＦ（ｄＩＤ），ＳＳ（ｄＩＤ））＝（１，１）又は（０，０）の場合（ステップＳ１２１の分岐を行わないならば（１，０〜２）又は（０，０）の場合）は、制御装置２は、検出した操作に従い、ｄＩＤで特定される仮想デバイスの仮想カレントメモリにおける、ｐＩＤで特定されるパラメータの値を、変化量ｖａｌに応じて変更し（Ｓ１２３）、その変更後の値に従って、パラメータ表示画面４００等の表示を更新する（Ｓ１２４）。
【０１０６】
その後、ＯＦ（ｄＩＤ）＝１かつＳＳ（ｄＩＤ）＝１であれば（Ｓ１２５）、ｄＩＤで特定される仮想デバイスと対応する被制御装置３に、検出した操作に従ってｐＩＤで特定されるパラメータの値を変化量ｖａｌに応じて変更するよう要求する変更命令ＳＥＴ（ｐＩＤ，ｖａｌ）をユニキャスト送信し（Ｓ１２６）、処理を終了する。
ステップＳ１２５でＮＯであれば、オフライン中であり、被制御装置３に対する指示は不要であるので、そのまま処理を終了する。
【０１０７】
一方、被制御装置３は、制御装置２がステップＳ１２６で送信した変更命令ＳＥＴ（ｐＩＤ，ｖａｌ）を受信すると、図１４の右側のフローチャートに示す処理を開始する。
そして、カレントメモリにおけるｐＩＤで特定されるパラメータの値を変化量ｖａｌに応じて変更する（Ｓ３０１）と共に、同期ＩＤの値がＳＩＤ（図９に示した現在の同期期間を示す値）の同期期間についての変更パラメータリストＭＰ（ＳＩＤ）及び、更新情報用パラメータリストＵＰに、値を変更したパラメータを特定するｐＩＤを追加し（Ｓ３０２）、処理を終了する。なお、ステップＳ３０２において、ｐＩＤの値が既にＭＰ（ＳＩＤ）やＵＰに登録されていれば、同じ値を再度登録する必要はない。
【０１０８】
ここで、変更パラメータリストＭＰ（ＳＩＤ）は、同期ＩＤの値がＳＩＤである同期期間内に被制御装置３において値が変更されたパラメータのＩＤを登録するリストである。
更新情報用パラメータリストＵＰは、前回更新情報ＵＰＤＡＴＥ（図７，図８参照）を送信した後で値が変更されたパラメータのＩＤを登録するリストである。ある更新情報を送信してから次の更新情報を送信するまでの期間を更新期間とすると、ＵＰは、最新の更新期間内に値が変更されたパラメータのリストということになる。
【０１０９】
なお、更新期間は数ミリ秒〜十数ミリ秒程度、同期期間は更新期間の１０倍〜１０００倍程度、すなわち、数百ミリ秒から数秒程度の長さとするとよい。この更新期間の長さに応じて、被制御装置３側で行われたパラメータ値の変更が、それを監視している制御装置２側の表示に反映されるまでの遅れの時間（平均値）が決まり、また、この同期期間の長さによって、通信エラーが検出された場合の仮想カレントメモリ中のパラメータがエラー修正できるまでの遅れ時間（平均値）が決まる。なお、ここで示した更新期間と同期期間の長さはそれぞれ絶対的なものではなく、これから外れた値を採用してもリモート制御システムを動作させることはできる。ただ、如何なる場合であっても、同期期間の長さは、更新期間よりも充分に長くすることが望ましい。
【０１１０】
以上の処理により、制御装置２は検出した指示に応じて仮想カレントメモリの内容を更新すると共に、オンライン中であれば、被制御装置３のカレントメモリの内容も同様に更新することができる。また、被制御装置３は、後でパラメータの値の変更内容を他の制御装置２に通知できるよう、変更したパラメータの種類を記憶しておくことができる。
【０１１１】
次に、図１５に、被制御装置３のＣＰＵ２０１ないし３０１が、被制御装置３が備えるユーザインターフェース２０５，３０５，３０６または３０７において、ユーザからのパラメータの変更操作が受け付けられた場合に実行する処理のフローチャートを示す。
上述したように、被制御装置３は、自身が備える操作子により、ローカルでパラメータの変更指示を受け付けることができる。そして、ｐＩＤで特定されるパラメータを、変化量ｖａｌ分だけ変化させる指示を検出した場合、図１５のフローチャートに示す処理を開始する。
【０１１２】
そして、図１４のステップＳ３０１及びＳ３０２の場合と同様に、カレントメモリにおけるｐＩＤで特定されるパラメータの値を変化量ｖａｌに応じて変更する（Ｓ３１１）と共に、変更パラメータリストＭＰ（ＳＩＤ）及び更新情報用パラメータリストＵＰにｐＩＤを追加し（Ｓ３１２）、処理を終了する。
以上の処理により、被制御装置３は、ローカルで受け付けた指示に応じてパラメータの値を変更した場合も、リモートで受け付けた要求に応じた変更の場合と同様、後で変更内容を制御装置２に通知できるよう、変更したパラメータの種類を記憶しておくことができる。
【０１１３】
次に、図１６に、被制御装置３のＣＰＵ２０１ないし３０１が実行する更新情報送信処理のフローチャートを示す。この処理は、図７及び図８に示した更新情報ＵＰＤＡＴＥの送信に係る処理である。
なお、図７及び図８ではパラメータの値を変更する度に更新情報を送信するとして説明したが、実際には１つの更新期間内に値が変更されたパラメータについて、その更新期間の終わりにまとめて更新情報を送信する。ロータリーエンコーダが操作された場合等、短時間の間に連続的にパラメータの値を変更する場合があり、このような場合には、変更内容をまとめて通知することにより、通信トラフィックを低減できるためである。
【０１１４】
このため、被制御装置３は、更新情報ＵＰＤＡＴＥを送信するタイミング（＝ある更新期間から次の更新期間に変わるタイミング）になる度に、図１６の左側のフローチャートに示す処理を開始する。
そして、その時点で更新情報用パラメータリストＵＰにパラメータのｐＩＤが登録されていれば（Ｓ３２１のＹＥＳ）、その登録されている各ｐＩＤについて、そのｐＩＤで特定されるパラメータの現在値をカレントメモリから読み出し（Ｓ３２２）、その各ｐＩＤと、そのｐＩＤに関して読み出されたパラメータの現在値（そのｐＩＤに対応する現在値）とを含む更新情報ＵＰＤＡＴＥを、最新の更新期間におけるパラメータの値の変更内容を示すデータとして生成する（Ｓ３２３）。１つの更新期間内に同じ種類のパラメータの値が複数回変更された場合でも、最終的にどの値になったかがわかればよいので、途中の値を更新情報ＵＰＤＡＴＥに含める必要はない。
【０１１５】
そして、被制御装置３は、生成した更新情報ＵＰＤＡＴＥを、自身に割り当てられているマルチキャストアドレス宛てに送信し（Ｓ３２４）、更新情報用パラメータリストＵＰをクリアして（Ｓ３２５）、処理を終了する。各被制御装置３がマルチキャスト送信する（マルチキャストアドレス宛ての）一連のパケットには、その内容に関わらず、その被制御装置３に関して連番となるマルチキャストＩＤが付与される。ここでは更新情報ＵＰＤＡＴＥに対しマルチキャストＩＤが付与された後、マルチキャスト送信される。ただし、このマルチキャストＩＤは、マルチキャスト送信であれば、更新情報ＵＰＤＡＴＥ以外のパケット（例えば同期データＳＹＮＣ）にも付すため、更新情報ＵＰＤＡＴＥ自体に連番を付すわけではない。
【０１１６】
また、ステップＳ３２１でＮＯであれば、制御装置２に通知すべき情報がないことがわかるので、そのまま処理を終了する。すなわち、更新情報ＵＰＤＡＴＥを送信するのは、その更新期間に被制御装置３のカレントメモリの何れかのパラメータの値が変更された場合のみであり、何れのパラメータも変更されていない場合には、更新情報ＵＰＤＡＴＥは送信されないのである。
【０１１７】
一方、ステップＳ３２４での送信に係るマルチキャストアドレス宛てのパケットを受信するよう設定されている各制御装置２はそれぞれ、被制御装置３がステップＳ３２４でマルチキャスト送信した更新情報ＵＰＤＡＴＥを受信し、図１７を用いて後述するように通信エラーがなく正常に受信できたことを確認すると、図１６の右側のフローチャートに示す処理を開始する。ここで、送信元の被制御装置３と制御装置２の仮想デバイスとを対応付けるのに使用したデバイスＩＤをｄＩＤとする。
【０１１８】
そして、この処理において、制御装置２は、更新情報ＵＰＤＡＴＥに基づいて、ｄＩＤで特定される仮想デバイスの仮想カレントメモリのパラメータのうちの、ＵＰＤＡＴＥに含まれる各ｐＩＤで特定されるパラメータの値を、ＵＰＤＡＴＥに含まれるそのｐＩＤに対応する現在値に変更し（Ｓ１３１）、その変更後の値に従って、パラメータ表示画面４００等の表示を更新する（Ｓ１３２）。
【０１１９】
以上の処理により、パラメータの値が変更された被制御装置３と同期している仮想デバイスを有する全ての制御装置２が、それぞれ、被制御装置３においてなされたパラメータの値の変更に合わせて、その仮想デバイスの仮想カレントメモリの対応するパラメータの値を変更することにより、被制御装置３と仮想デバイスとが同期している状態を維持することができる。これは、被制御装置３においてなされたパラメータの値の変更が、リモート制御によるものでも、ローカルの操作によるものでも、同じである。
【０１２０】
なお、図１４のステップＳ１２６で変更命令を送信した制御装置２にとっては、被制御装置３から受信する更新情報ＵＰＤＡＴＥは、基本的には、自身が送信した変更命令と同じ内容の変更を通知されるものとなるが、それにより、被制御装置３側で実際に変更されたパラメータの値を確認できることになるので、この処理は無駄ではない。
【０１２１】
次に、図１７に、制御装置２のＣＰＵ１０１が実行する、マルチキャストアドレス宛のパケットを受信した場合の処理のフローチャートを示す。
制御装置２は、何れかのマルチキャストアドレス宛のパケットを受信すると、図１７に示す処理を開始する。そしてまず、受信したパケットにつき、データエラーの有無、宛先のマルチキャストグループ、送信元の被制御装置と対応する仮想デバイスを特定するｄＩＤ、及びパケットに付されているマルチキャストＩＤを確認する（Ｓ１４１）。
【０１２２】
そして、データエラー有無及び、宛先のマルチキャストアドレスが自分の属するグループのアドレスか否かにより、処理を分岐させる（Ｓ１４２）。当該制御装置２が受信すべき全てのマルチキャストアドレスが、図１０に示したマルチキャストグループ情報に含まれている。
【０１２３】
ここで受信すべきマルチキャストアドレスではない、すなわち、他のグループ宛てのパケットである場合は、エラー有無に関わらず、パケットを読み捨てるため、そのまま処理を終了する。
自身の属するグループ宛であっても、データエラーがあれば、発生したマルチキャスト通信エラーに係るｄＩＤを引数としてエラー処理ルーチン（図１８）を起動させ、ｄＩＤで特定される仮想デバイスに対応付けられた被制御装置からのパケットの当該エラーに対処する処理を行わせ（Ｓ１４６）、処理を終了する。
【０１２４】
また、ステップＳ１４２で自身の属するグループ宛かつデータエラーなしであれば、送信元と対応する仮想デバイスがありかつその仮想デバイスについて同期状態ＳＳ（ｄＩＤ）が０でないか判断する（Ｓ１４３）。すなわち、送信元が、自身とカレントメモリを同期させている被制御装置３であるか否か確認する。ここでＮＯであれば、受信したパケットを仮想カレントメモリの内容に反映させる必要がないため、そのまま処理を終了する。
【０１２５】
ステップＳ１４３でＹＥＳであれば、次に、マルチキャストＩＤが前回同じ送信元から受信したパケットと連続したものとなっているか否か判断する（Ｓ１４４）。被制御装置３は、図１６のステップＳ３２４の説明で述べたように、各被制御装置３は、マルチキャスト送信する全てのパケットに、その被制御装置３に関して連番となるマルチキャストＩＤを付しているので、制御装置２がマルチキャスト送信されたパケットを受信したときに、その被制御装置３に関してマルチキャストＩＤに抜けがあるか否かを検出することにより、前回受信時以後にロストしたパケットがあるか否か、すなわち通信エラー発生の有無を判定できる。ロストしたパケットの内容まではわからないが、これがわかる必要はない。
【０１２６】
そこで、ステップＳ１４４でＮＯであった場合も、発生したマルチキャスト通信エラーに係るｄＩＤを引数としてエラー処理ルーチン（図１８）を起動させ、ｄＩＤで特定される仮想デバイスに対応付けられた被制御装置からのパケットの当該エラーに対処する処理を行わせる（Ｓ１４６）。
【０１２７】
また、ステップＳ１４４でＹＥＳであれば、被制御装置３から正常にパケットを受信したと判断できるため、受信したパケットのデータを引数として、そのデータ種別に応じた処理ルーチンを起動させ、ｄＩＤで特定される仮想デバイスに対応付けられた被制御装置から受信したパケットのデータの処理を行わせて（Ｓ１４５）、処理を終了する。
この場合、例えば、受信したパケットのデータが更新情報ＵＰＤＡＴＥである場合には、図１６の右側のフローチャートに示す処理が起動され、同期情報ＳＹＮＣである場合には、図２１に示す処理が起動される。
【０１２８】
以上の処理により、制御装置２は、被制御装置３からマルチキャストで送信されてくるパケットの受信のエラー有無を確認した上で、エラー有無に応じた処理を行うことができる。
なお、ステップＳ１４２のマルチキャストアドレスを判定する処理に関しては、ＣＰＵ１０１の負荷を低減するために、ＣＰＵ１０１の代わりにネットワークＩ／Ｆ１０７が行うようにするのが好ましい。その場合、ネットワークＩ／Ｆ１０７は、その制御装置２のマルチキャストグループ情報（図１０）に記載されたマルチキャストアドレスのパケットを受信した場合にのみＣＰＵ１０１に対して通知し、他のマルチキャストアドレス宛てのパケットを受信してもＣＰＵ１０１に通知しないようにする。
【０１２９】
次に、図１８に、制御装置２のＣＰＵ１０１及び被制御装置３のＣＰＵ２０１ないし３０１が実行する、被制御装置３からマルチキャストで送信されてくるパケットの受信にエラーを検出した場合の処理のフローチャートを示す。また、この図以降で説明する処理に使用する各種変数を、表２及び表３にまとめた。ＳＳ（ｄＩＤ）については表１に記載したものである。
【０１３０】
【表２】
0005533504.tif 000003
【０１３１】
【表３】
0005533504.tif 000004
【０１３２】
制御装置２は、図１７のステップＳ１４６での起動により、図１８の左上のフローチャートに示すエラー処理を開始する。
そして、まずＳＳ（ｄＩＤ）＝２かつＳＰｔ（ｄＩＤ）≦ＳＩＤ（ｄＩＤ）であるか否か判断する（Ｓ１５１）。これがＹＥＳの場合、ＳＳ（ｄＩＤ）＝２であることから、現在は一時的にカレントメモリの同期が損なわれた状態であり、同期の回復を試みている最中であることがわかる。また、ＳＰｔ（ｄＩＤ）≦ＳＩＤ（ｄＩＤ）であることから、今回のエラーに応じて要求しようとしている通信エラー補正用のデータを、対応する被制御装置３に既に要求済みであることがわかる。」
一方、ステップＳ１５１でＮＯの場合、今回のエラーに応じて要求しようとしている通信エラー補正用のデータを、対応する被制御装置３に未だ要求していないということである。
【０１３３】
ここで、図１９に、制御装置２がマルチキャストで送信されてくるパケットの受信のエラーを検出するタイミングの具体例を、被制御装置３側と制御装置２側の同期ＩＤの変化と合わせて示す。
被制御装置３側の同期ＩＤであるＳＩＤの値は、図２０を用いて後述するように所定の同期タイミング毎に変化し、そのタイミングで同期データＳＹＮＣを送信して制御装置２にその旨を伝達する。例えば、ＳＩＤが８から９に変わるタイミングで、次の同期ＩＤが９である旨の情報を含む同期データＳＹＮＣを送信する等である。
【０１３４】
そして、制御装置２は、その同期データＳＹＮＣを正常に受信すると、自身が記憶する、被制御装置３に関する同期ＩＤであるＳＩＤ（ｄＩＤ）を、同期データＳＹＮＣに含まれていた値に変更する。そしてこのことにより、制御装置２が同期データＳＹＮＣを正常に受信している限りは、被制御装置３のＳＩＤと制御装置２のＳＩＤ（ｄＩＤ）は、ほぼ同じタイミングで同じ値に変化することになる。
【０１３５】
しかし、図１９のＳＩＤが９から１０あるいは１０から１１に変わるタイミングの同期データＳＹＮＣのように、何らかの理由で同期データＳＹＮＣが制御装置２に届かない場合、被制御装置３においてはＳＩＤの値が変化しても、制御装置２はそれを認識せず、ＳＩＤ（ｄＩＤ）の値は変化しない。ただこのため、制御装置２が再度パケットを受信できるようになるまで、ＳＩＤ（ｄＩＤ）の値を変化させずに保つことができる、とも言える。
【０１３６】
従って、制御装置２がエラーの発生を認識するのが、被制御装置３においてＳＩＤが変化しないうちである場合はもちろん、認識までに被制御装置３側ではＳＩＤの値が変化してしまっていたとしても、制御装置２は、パケットを受信できなかった可能性があるのは、被制御装置３におけるＳＩＤの値が、エラー検出時のＳＩＤ（ｄＩＤ）、図１９の例では９である同期期間以降の期間であることを認識できる。
これは、（ａ）に示すように同期データＳＹＮＣのパケットを受信した際にエラーを検出した場合も、（ｂ）に示すように更新情報ＵＰＤＡＴＥを受信した際にエラーを検出した場合も、同じである。
【０１３７】
以上の通りであるので、図１８の説明に戻ると、ステップＳ１５１でＮＯの場合、制御装置２がパケットを受信できなかった可能性がある期間に被制御装置３側で変更されたパラメータの値を取得できれば、これを仮想カレントメモリに反映させて同期を回復できると考えられる。そこで、制御装置２は、ＳＩＤ（ｄＩＤ）の値をパラメータとして有しており、かつ、そのパラメータで特定される同期期間以降の同期期間に変更されたパラメータの値の送信を要求する送信要求ＲＥＱ＿ＳＹＮＣ（ＳＩＤ（ｄＩＤ））を生成し（Ｓ１５２）、ｄＩＤで特定される仮想デバイスに対応付けられた被制御装置３に送信する（Ｓ１５３）。この送信は、図１９におけるＲＥＱ＿ＳＹＮＣ（９）の送信に当たるものであり、確実に被制御装置３に届くように、ユニキャストで行う。
【０１３８】
そして、ＳＳ（ｄＩＤ）に、ｄＩＤで特定される仮想デバイスにおいて、一次的に同期が損なわれていることを示す２を設定し、要同期期間ＳＰｔ（ｄＩＤ）には、カレントメモリの同期を保証できない最初の同期期間のＩＤであるＳＩＤ（ｄＩＤ）を設定する。また、送信要求ＲＥＱ＿ＳＹＮＣの送信回数を示す再送カウンタＲＣ（ｄＩＤ）に初期値として０を設定すると共に、送信要求ＲＥＱ＿ＳＹＮＣの再送タイミング（所定時間毎）を計測するためのハードウェアである再送タイマ（ｄＩＤ）をスタートさせる（Ｓ１５４）。さらに、ｄＩＤで特定される仮想デバイスに一時的な同期の不具合が発生した旨を、ディスプレイの、例えばパラメータ表示画面４００の同期ランプ４０３に表示させて（Ｓ１５５）、処理を終了する。
【０１３９】
一方被制御装置３は、制御装置２から送信要求ＲＥＱ＿ＳＹＮＣを受信すると、図１８の右側のフローチャートに示す処理を開始する。なおこの処理は、どの制御装置２から要求を受信したかによらず、実行するものであるが、上述したように、被制御装置３は、どの制御装置２がその被制御装置と同期状態（ＳＳ（ｄＩＤ）≠０）にある仮想デバイスを有しているかを把握しているので、それら該当する制御装置２から要求された場合のみに実行するようにしてもよい。
登場する変数も、制御装置２毎に管理するものではない（従って「（ｄＩＤ）」といった記載はない）。また、被制御装置３は、送信要求ＲＥＱ＿ＳＹＮＣのパラメータの値が制御装置２側でどのように定められたかを把握する必要はなく、単に値だけ取得できればよい。ここでは、その値がＳＩＤ′であるとする。
【０１４０】
そしてこの処理において、被制御装置３はまず、ＳＩＤ′＜ＳＰｏか否か判断する（Ｓ３３１）。これがＹＥＳであれば、制御装置２から要求された同期期間については既に変更パラメータリストＭＰを廃棄してしまっており、要求に応えることができないと判断する。そこで、送信要求ＲＥＱ＿ＳＹＮＣの送信元の制御装置２に対し、欠落したデータの補正が不可能であり、被制御装置３との間の接続が切断されたと認識すべきことを示す再同期不能通知をユニキャスト送信する（Ｓ３３２）。
【０１４１】
そして、これを受信した制御装置２は、被制御装置３との間でカレントメモリの同期を回復できないことがわかるため、図１８の左下のフローチャートに示す処理により、ＳＳ（ｄＩＤ）とＯＦ（ｄＩＤ）に０を設定し（Ｓ１５６）、被制御装置３をオフライン状態とすると共に、その仮想デバイスの同期ランプ４０３およびオンラインランプ４０２を消灯することにより、その旨をディスプレイに表示させる（Ｓ１５７）。
【０１４２】
また、被制御装置３は、ステップＳ３３１でＮＯの場合、制御装置２からの要求に応えることができると判断する。そして、ＲＳＦ＝１かつＳＩＤ’≧ＳＰｘであるか否か判断する（Ｓ３３３）。
ここでＹＥＳであれば、過去に受信した送信要求（何れの制御装置２から受信したかは問わない）に基づき、今回の要求に係る同期期間を含む同期期間のパラメータの値が、既に送信される予定になっているため、ここでは特に設定を行わずに終了する。
【０１４３】
一方、ステップＳ３３３でＮＯであれば、そのままでは今回の要求に係る全ての同期期間のパラメータの値は送信されないので、送信要求フラグＲＳＦに、制御装置２に送信すべきパラメータの値があることを示す１を、ＳＰｘに、パラメータの値を制御装置２に送信する必要がある最先の同期期間の同期ＩＤとして、制御装置２からの要求に基づきＳＩＤ′を設定する（Ｓ３３４）。これらのデータは、図２０の処理で参照する。
【０１４４】
以上の処理により、制御装置２は、被制御装置３からマルチキャストで送信されてくる更新情報ＵＰＤＡＴＥ及び同期データＳＹＮＣの受信にエラーを検出した時に、その検出の時点で記憶している同期ＩＤが示す同期期間以降に変更されたパラメータの値の送信を被制御装置３に要求することができる。また、被制御装置３側では、その要求に応えることが可能であれば、要求されたパラメータの値を次回の送信時に同期データＳＹＮＣに含めて送信するよう、必要な設定を行うことができる。
【０１４５】
次に、図２０に、被制御装置３のＣＰＵ２０１ないし３０１が実行する同期データ送信処理のフローチャートを示す。
被制御装置３は、現在の同期期間を終了して次の同期期間に移行する所定の同期タイミングになると、図２０に示す処理を開始する。同期期間の長さは、一定となるよう制御されている（多少の揺らぎはあり）が、これを状況によって変えられるようにしてもよい。
【０１４６】
そして、この処理において、被制御装置３はまず、同期ＩＤであるＳＩＤの値を１増加させ、次の同期期間に入ったことを示す（Ｓ３４１）と共に、その同期期間についての空の変更パラメータリストＭＰ（ＳＩＤ）を作成する（Ｓ３４２）。
その後、ＲＳＦが１であれば（Ｓ３４３のＹＥＳ）、送信要求ＲＥＱ＿ＳＹＮＣに応じて制御装置２に送信すべきパラメータの値を準備すべく、ステップＳ３４４乃至Ｓ３４９の処理を行う。
【０１４７】
ここでは、生成した再同期用データの数をカウントするための変数ｄｎに初期値０を設定した後（Ｓ３４４）、パラメータの値を制御装置２に送信する必要がある最先の同期期間である、ＳＰｘで特定される同期期間から順に、同期期間毎に、その同期期間に変更されたパラメータの値を示す再同期用データを作成していく。
【０１４８】
すなわち、まず、更新パラメータリストＭＰ（ＳＰｘ）に登録されている各ｐＩＤについて、そのｐＩＤで特定されるパラメータの現在値をカレントメモリから読み出し、ＳＰｘで特定される同期期間の再同期用データＤＡＴＡ（ＳＰｘ）として、ＳＰｘの値、及び、更新パラメータリストＭＰ（ＳＰｘ）の各ｐＩＤと、そのｐＩＤに関して読み出されたパラメータの現在値（そのｐＩＤに対応する現在値）とを含むデータを生成する（Ｓ３４５）。
【０１４９】
ここで、同期ＩＤ＝ＳＰｘの同期期間の時点の値ではなく現在値を使うのは、再同期用データが、発生したデータ欠落を補正して仮想カレントメモリの内容をカレントメモリの内容と一致させ、カレントメモリの同期を回復させるためのものであり、パラメータの値の変更過程を忠実に再現するためのものではないからである。なお、更新パラメータリストＭＰ（ＳＰｘ）にｐＩＤが１つも登録されていない場合は、ｐＩＤと現在値をそれぞれ１つも含まない再同期用データＤＡＴＡ（ＳＰｘ）を生成する。
【０１５０】
そして、ステップＳ３４５の後は、ｄｎとＳＰｘをそれぞれ１ずつ増加させ（Ｓ３４６）、ＳＰｘがＳＩＤに達しておらず（Ｓ３４７のＹＥＳ）、次の同期期間の再同期用データを追加しても同期データＳＹＮＣのサイズが規定値以下に収まる場合には（Ｓ３４８のＹＥＳ）、ステップＳ３４５に戻り、次の同期期間（同期ＩＤが１増加したＳＰｘである同期期間）に関する再同期用データを生成する。
ステップＳ３４７でＳＰｘ＝ＳＩＤであれば、直近の同期期間の分まで再同期用データを生成したことになり、それ以上は制御装置２に送信すべきパラメータの値がなくなったことがわかるので、ＲＳＦにそのことを示す０を設定して（Ｓ３４９）、ステップＳ３５０に進む。
【０１５１】
また、ステップＳ３４８でＮＯの場合には、これ以上再同期用データを追加できないため、以降の再同期用データの作成及び送信は次の同期タイミングに行うものとして、ＲＳＦの値が１のままの状態でステップＳ３５０に進む。
またステップＳ３４３でＮＯの場合には、再同期用データの作成はせずにステップＳ３５０に進む。
【０１５２】
いずれの場合も、ステップＳ３５０では、ステップＳ３４５で生成した各再同期用データＤＡＴＡと、その再同期用データの数ｄｎ（０の場合もある）と、次の同期期間の同期ＩＤ（＝ＳＩＤ）とを含む同期データＳＹＮＣ（ＳＩＤ，ｄｎ，ＤＡＴＡ（），―――）を生成する。例えば図１９（ａ）の例では、同期ＩＤの値が、送信要求で指定された９から同期データ送信時の直近の１１までの同期期間についての再同期用データを含む同期データを生成する。図１９（ｂ）の例では、同期データ送信時の直近の同期ＩＤが１２であるので、同期ＩＤが９から１２までの同期期間についての再同期用データを含む同期データを生成する。
【０１５３】
そして、生成した同期データを、自身に割り当てられているマルチキャストアドレス宛てに送信する（Ｓ３５１）。このとき、図１６のステップＳ３２４の場合と同様、実際のデータ転送を司るプロセスにおいて、マルチキャスト送信する（マルチキャストアドレス宛の）パケットに、連番のマルチキャストＩＤを付す。
その後、ＳＰｏの値をＳＩＤ−ＨＮとし、同期ＩＤがＳＰｏ−１以下の同期期間についての変更パラメータリストＭＰを廃棄して（Ｓ３５２）、すなわち、最新のＨＮ個以外の同期期間についての変更パラメータリストＭＰを廃棄して、処理を終了する。
【０１５４】
以上の処理により、被制御装置３は、同期期間が終わる毎に、その同期期間の同期ＩＤを含む同期データＳＹＮＣを生成して各制御装置２にマルチキャスト送信し、いずれかの制御装置から送信要求ＲＥＱ＿ＳＹＮＣを受けていた場合には、送信要求で指定された各同期期間について、その同期期間内に値を変更したパラメータの現在値をその同期データＳＹＮＣに含めて送信することができる。
【０１５５】
また、同期データＳＹＮＣのサイズを規定値以内に収めるので、制御ネットワークにおける、他の装置がデータを送信するのに使用する帯域や、自身が他のデータを送信するのに使用する帯域を残しておくことができる。また、記憶する変更パラメータリストＭＰを、有限のＨＮ個の同期期間に関するもののみとし、使用するメモリ容量を抑えることができる。
【０１５６】
次に、図２１に、制御装置２が被制御装置３から同期データＳＹＮＣを受信した場合に実行する処理のフローチャートを示す。
制御装置２は、ｄＩＤで特定される仮想デバイスと同期している被制御装置３がマルチキャストで送信してくる同期データＳＹＮＣ（同期ＩＤとしてＳＩＤ′が、再同期用データ数としてｎ′が含まれているものとする）を受信したとき、図１７のステップＳ１４５において、図２１のフローチャートに示す処理を起動する。なお、通信エラーがあった場合には、図２１の処理ではなく図１８に示した処理が起動される。
【０１５７】
そして、図２１の処理においては、制御装置２はまず、ＳＩＤ′＝ＳＩＤ（ｄＩＤ）＋１であるか否か、すなわち今回受信した同期データと、前回受信した同期データとで同期ＩＤが連番になっているか否かを判断する（Ｓ１６１）。
ここでＮＯであれば、間に同期データが欠落していると考えられるため、マルチキャストＩＤが連番でなかった場合と同様、パケットの受信にエラーがあったものとして図１８に示した処理を実行する（Ｓ１６２）。
【０１５８】
マルチキャスト送信されたパケットが受信できなかったことにより同期データが欠落したのであれば、マルチキャストＩＤにも飛びが発生するため図１７のステップＳ１４４の判断で検出できるはずであるが、例えば被制御装置３側でパケットの送信自体が行われなかったような場合には、同期データが欠落していてもマルチキャストＩＤは連番になっていることも考えられる。従ってここでは、同期ＩＤの連続性も確認するようにしている。なお、ここで図１８の処理を実行した場合、その処理の終了後は図２１の処理に戻り、ステップＳ１６３以降の処理に進む。
ステップＳ１６１でＹＥＳの場合は、受信した同期データＳＹＮＣに問題がないことがわかるので、そのままステップＳ１６３以降の処理に進む。
【０１５９】
いずれの場合もステップＳ１６３では、ＳＩＤ（ｄＩＤ）の値をＳＩＤ′の値に更新する（Ｓ１６３）。
次に、ＳＳ（ｄＩＤ）≠２又はｎ′＝０であるか否か判断する（Ｓ１６４）。ＳＳ（ｄＩＤ）≠２であれば、現在は同期の回復を行う必要がない状態であり、受信した同期データＳＹＮＣに含まれる再同期用データを参照する必要がないことがわかる。また、ｎ′＝０であれば、受信した同期データＳＹＮＣにはそもそも参照すべき再同期用データがないことがわかる。そこで、いずれの場合もそのまま処理を終了する。
【０１６０】
また、ステップＳ１６４でＮＯであれば、受信した同期データＳＹＮＣに含まれる先頭の（最も同期ＩＤの値が小さい）再同期用データＤＡＴＡに含まれる同期ＩＤが、ＳＰｔ（ｄＩＤ）以下であるか否か判断する（Ｓ１６５）。これがＮＯであれば、今回受信した同期データＳＹＮＣに含まれる再同期用データは、自身における同期の回復には用いることができない（もっと古い同期期間に関するデータが必要である）ことがわかる。従ってこの場合も、そのまま処理を終了する。
【０１６１】
このようになるケースとしては、送信要求ＲＥＱ＿ＳＹＮＣの被制御装置３への到達が、同期データＳＹＮＣの生成及び送信と前後したため、今回の同期データには、自身が送信した送信要求の内容が反映されていない場合が考えられる。しかし、このような場合であっても、次回以降の同期データとして、自身が送信した送信要求の内容を反映されたものを受信して、同期を回復できる可能性はある。
また、ステップＳ１６５でＹＥＳであれば、その制御装置２がｄＩＤで特定される被制御装置に対して送信要求ＲＥＱ＿ＳＹＮＣで要求した再同期用データを含む再同期用データが、その被制御装置から送られてくるということを意味するので、再送タイマ（ｄＩＤ）を停止する（Ｓ１６６）と共に、図２２に示す再同期化処理を行う（Ｓ１６７）。
【０１６２】
この再同期化処理においては、制御装置２は、ｎを１からｎ′まで１ずつ増加させながら（Ｓ１７１，Ｓ１７２，Ｓ１８０）、ステップＳ１７３乃至Ｓ１７９の処理により、受信した同期データＳＹＮＣに含まれるｎ番目の再同期用データＤＡＴＡ（ＳＰｎ）を用いたデータ欠落の補正を順次行っていく。ただし、番号の若い再同期用データほど同期ＩＤの値が小さい同期期間に関するデータであるとする。
【０１６３】
この補正の処理では、まず再同期用データＤＡＴＡ（ＳＰｎ）に含まれる同期ＩＤの値が、ＳＰｔ（ｄＩＤ）であるか否か判断する（Ｓ１７３）。ここでＮＯであれば、ｎ番目の再同期用データは、同期が保証できなくなるより前の同期期間のデータであり、参照する必要がないことがわかるので、そのままステップＳ１８０に進む。
【０１６４】
ステップＳ１７３でＹＥＳであれば、ｎ番目の再同期用データの内容を仮想カレントメモリに反映させるべく、再同期用データＤＡＴＡ（ＳＰｎ）に含まれる各ｐＩＤにつき、ｄＩＤで特定される仮想デバイスの仮想カレントメモリにおける、そのｐＩＤで特定されるパラメータの値を、ＤＡＴＡ（ＳＰｎ）に含まれるそのｐＩＤに対応する現在値に変更する（Ｓ１７４）。なお、再同期用データＤＡＴＡ（ＳＰｎ）にｐＩＤが１つも含まれていない場合には、パラメータ値の変更は行われない。変更が行われた場合は、その変更後の値に従ってディスプレイ上のパラメータ表示画面４００の表示を更新する（Ｓ１７５）。
【０１６５】
これで同期ＩＤがＳＰｔ（ｄＩＤ）の同期期間において値が変更されたパラメータについては仮想カレントメモリに記憶する値を被制御装置３における最新の値に更新できたので、その同期期間において通信エラーが生じていたとしても、その通信エラーによる同期の損傷を修正できたものとして、ＳＰｔ（ｄＩＤ）を１増加させる（Ｓ１７６）。
【０１６６】
そして、この時点でＳＰｔ（ｄＩＤ）＝ＳＩＤ（ｄＩＤ）であれば（Ｓ１７７のＹＥＳ）、直前の同期期間までの全ての通信エラーを補正し、カレントメモリの同期を回復できたものとして、ＳＳ（ｄＩＤ）にその旨を示す１を設定する（Ｓ１７８）とともに、ｄＩＤ番目の仮想デバイスの同期エラーが解消した旨を、ディスプレイの、例えばパラメータ表示画面４００の同期ランプ４０３を点滅から点灯に変更して表示し（Ｓ１７９）、ステップＳ１８０に進む。
また、ステップＳ１７７でＮＯの場合、次の再同期用データを用いてさらに同期の回復を試みるべく、そのままステップＳ１８０に進む。
【０１６７】
そして、ステップＳ１８０でＹＥＳになると、図２１の処理に戻って処理を終了する。なお、ステップＳ１７７でＹＥＳであれば、ＤＡＴＡ（ＳＰｎ）が直前の同期期間に係るものであることになり、これは必ず最後の（＝ｎ′番目の）再同期用データであるので、ステップＳ１８０の判断はＹＥＳになる。
【０１６８】
以上の図２１及び図２２の処理により、制御装置２は、同期データＳＹＮＣを受信した場合に、その同期データに含まれる同期ＩＤを最新の同期期間の同期ＩＤとして記憶すると共に、その同期データに、同期の回復のために被制御装置３に送信を要求した、変更されたパラメータの値の情報が含まれていた場合に、その情報に基づいて仮想カレントメモリの内容を訂正し、通信エラーにより失われた同期を回復させることができる。
【０１６９】
例えば図１９の（ａ）は、ある被制御装置３の同期ＩＤが９の同期期間（９）の途中から同期ＩＤが１１の同期期間（１１）の途中まで、ある制御装置２との間で通信エラーが生じており、その通信エラーが、同期期間（１１）の途中にマルチキャスト送信された更新情報ＵＰＤＡＴＥの時点で検出された例である。その時点で、該制御装置２は、該被制御装置３に対して、送信要求ＲＥＱ＿ＳＹＮＣ（９）をユニキャスト送信し、それに応じて、該被制御装置３は、次の同期期間（１２）の始めに送信する同期データＳＹＮＣに、同期ＩＤの値が９から１１までの同期期間の再同期データＤＡＴＡ（９）、ＤＡＴＡ（１０）、ＤＡＴＡ（１１）を付加してマルチキャスト送信する。該制御装置２は、受信した再同期用データに基づいて、該被制御装置３に対応付けた仮想デバイスに生じた同期の損傷を修正する。
【０１７０】
同様に、図１９の（ｂ）は、ある被制御装置３の同期期間（９）の途中から同期期間（１１）まで、ある制御装置２との間で通信エラーが生じており、その通信エラーが、次の同期期間（１２）の始めにマルチキャスト送信された同期データＳＹＮＣの時点で検出された例である。その時点で、該制御装置２は、該被制御装置３に対して、送信要求ＲＥＱ＿ＳＹＮＣ（９）をユニキャスト送信し、それに応じて、該被制御装置３は、更に次の同期期間（１３）の始めに送信する同期データＳＹＮＣに、同期ＩＤの値が９から１２までの同期期間の再同期データＤＡＴＡ（９）〜ＤＡＴＡ（１２）を付加してマルチキャスト送信して、該被制御装置３に対応付けた仮想デバイスに生じた同期の損傷を修正する。この例では、同期期間（１２）については、おそらく何の通信エラーが生じていないが、再同期データＤＡＴＡ（１２）に基づく変更では、一部パラメータに同じ値の現在値を上書きするだけなので、特に不都合はない。
【０１７１】
従って、被制御装置３から制御装置２への更新情報ＵＰＤＡＴＥの送信に到達保証のないマルチキャストを用いたとしても、通信エラー等によるデータの欠落が発生した場合には、同期期間の長さ程度の、少ない遅れ時間でこれを検出して修正し、カレントメモリの同期を維持し、パラメータの値の伝達の信頼性を適度に確保することができる。また、パラメータの値の変更内容の伝達に最低限必要なデータに加えてエラー監視のために追加的に送信する必要があるデータは、エラーのない定常状態では、各パケットに付すマルチキャストＩＤと、同期データＳＹＮＣのみであり、通信帯域に対する負荷は小さい。
【０１７２】
なお、図２２の処理において、ステップＳ１７３の判断を省略し、ここが常にＹＥＳになるようにしてもよい。同期が保証できている期間に変更されたパラメータの値を仮想カレントメモリに反映させたとしても、そのパラメータの値は被制御装置３における最新の値になるため、同期が取れている状態なら、もともと最新の値になっているものが維持されるだけであり、同期の維持に支障はないためである。ただし、ステップＳ１７４以下の処理を無駄に行うことになるので、若干動作が遅くなることが考えられる。
【０１７３】
また、図２０のステップＳ３４８でＮＯとなり、被制御装置３が同期データＳＹＮＣに最新の同期期間（ＳＩＤ−１）までの再同期用データを含めることができなかった場合（途中のＳＰｘ−１で特定される同期期間の再同期用データまでで打ち切った場合）、制御装置側の図２２の再同期化処理では、途中のＳＰｘ−１で特定される同期期間までの修正が行われる（ＳＰｔ（ｄＩＤ）＝ＳＩＤ（ｄＩＤ）とならない）。このような場合、被制御装置３側のＲＳＦは１のままであり、次の同期タイミングにおいて、被制御装置３は、次の同期データＳＹＮＣに、その続きのＳＰｘで特定される同期期間以降の再同期用データを含めて送信する。
【０１７４】
また、制御装置２側のＳＳ（ｄＩＤ）は２のままであり、該次の同期データＳＹＮＣを受信すると、図２２の再同期化処理では、その続きのＳＰｘで特定される同期期間の修正が行われる。このようにして、要求された再同期用データが、連続する何回かの同期データＳＹＮＣに分散して伝達され、最終的にはＳＰｔ（ｄＩＤ）＝ＳＩＤ（ｄＩＤ）となって、制御装置２において、仮想デバイスの同期が回復される（ＳＳ（ｄＩＤ）が１となる）。
【０１７５】
次に、図２３に、制御装置２が実行する送信要求の再送処理のフローチャートを示す。
制御装置２は、いずれかのｄＩＤについて再送タイマ（ｄＩＤ）が所定時間毎の再送タイミングを検出すると、図２３のフローチャートに示す処理を開始する。
そしてまず、再送カウンタＲＣ（ｄＩＤ）を１増加させる（Ｓ１９１）。そして、ＲＣ（ｄＩＤ）が最大再送回数ＲＣｍａｘを超えていなければ（Ｓ１９２のＮＯ）、その時点のＳＰｔ（ｄＩＤ）に基づき、まだ取得できていない、同期ＩＤの値がＳＰｔ（ｄＩＤ）の同期期間以降に被制御装置３側で変更されたパラメータの値の送信を要求する送信要求ＲＥＱ＿ＳＹＮＣ（ＳＰｔ（ｄＩＤ））を生成し（Ｓ１９３）、これをｄＩＤで特定される仮想デバイスと対応する被制御装置３にユニキャスト送信して（Ｓ１９４）、処理を終了する。
【０１７６】
また、ステップＳ１９２でＹＥＳの場合には、もはや被制御装置３との接続は切断され、被制御装置３からは同期を回復するための再同期用データは取得できないと判断し、ＯＦ（ｄＩＤ）及びＳＳ（ｄＩＤ）に０を設定して、ｄＩＤで特定される仮想デバイスをオフライン状態とする（Ｓ１９５）。そして、再送タイマ（ｄＩＤ）を停止する（Ｓ１９６）と共に、ｄＩＤで特定される仮想デバイスのパラメータ表示画面４００のオンラインランプ４０２及び同期ランプ４０３を消灯することにより、該仮想デバイスと対応付けられた被制御装置３とが非同期になった旨を表示して（Ｓ１９７）、処理を終了する。
【０１７７】
以上の処理により、図１８のステップＳ１５３で被制御装置３に要求したデータを全て受信するまで、所定時間毎に送信要求を繰り返し送信し、さらに、所定回送信してもデータを全て受信できない場合は、被制御装置３との通信が切断されたと判断することができる。
カレントメモリの同期が長期間切断されると、その間に被制御装置３において多数のパラメータの値が変更されてしまい、同期の回復が困難になることが考えられる。そこで、このような場合には一旦接続が切断されたものとして、必要に応じて図１２の処理により再度バルクダンプによる同期化を行うことが好ましい。
【０１７８】
以上で実施形態の説明を終了するが、装置の構成、システムを構成する装置の種類や数、データの形式、具体的な処理内容等が上述の実施形態で説明したものに限られないことはもちろんである。
例えば、上述の実施形態では、制御装置２と被制御装置３との間の、リモート制御に関するデータの転送を例として述べたが、この発明は、リモート制御に関係ないものも含め、任意のデータを複数の装置へマルチキャスト送信する際の信頼性確保にも適用することができる。
【０１７９】
従って、上述の実施形態において制御装置２と被制御装置３として示した装置が、一方が他方をリモート制御する、という関係にあることは必須ではない。例えば、被制御装置３と対応する第１ノードが、制御装置２と対応する複数の第２ノードに対し、随時変化する表示用のデータを、リアルタイム又はそれに近いタイミングで同時に伝送するようなシステムにおいても、上述の実施形態と同様な手法で、その伝送の信頼性を確保することができる。より具体的には、先生が電子ボードに書いた絵や文字を、複数の生徒の端末に表示するシステムや、刻々と変化するイベントのスケジュールを、関係者にリアルタイムに知らせるシステムなどが考えられる。
【０１８０】
この場合において、第２ノードは、第１ノードから伝送されたデータを表示する装置であったり、そのデータを単に記憶する装置であったり、またそのデータの内容に応じて何らかの処理を実行する装置であったりすることが考えられる。例えば、１又は複数の測定機（第１ノード）により複数の測定ポイントで測定を行って得たデータを、複数の監視装置（第２ノード）により複数箇所で監視するシステムや、同様に１又は複数の保護ポイントの状態を複数箇所で管理するセキュリティシステム、１又は複数の制御機から複数の表示器に同じデータを表示させる表示システム、１又は複数の放送機から複数の受信機へデータの放送をする放送システム、複数の地点で行われている会議内容を相互伝達する会議システムなど、様々なシステムに適用可能である。
【０１８１】
また、データ放送システムなど、第２ノードが、単に第１ノードにおいて新たに追加されたデータの情報を得られればいいような場合には、第２ノードに仮想カレントメモリを設ける必要はなく、従って図１２のステップＳ１１２の処理も不要である。
また、制御装置２側に、被制御装置３のカレントメモリと同じパラメータ構成の仮想カレントメモリを用意するようになっていたが、それを減らして、制御装置２が、ＲＡＭ１０３に表示器１０５に表示するパラメータだけを記憶する表示用バッファを用意するようにしてもよい。ただし、パラメータ表示画面４００に表示されるパラメータが変わる都度、表示用バッファを構成しなおさなければならず、制御装置２のレスポンスは悪化する。
【０１８２】
また、被制御装置３が同期データＳＹＮＣを送信する際に、その同期データＳＹＮＣに付加している同期ＩＤは、制御装置２のその被制御装置３に同期している仮想デバイスの同期ＩＤを、その被制御装置３の同期ＩＤに一致させるための情報である。実施例のように、各同期タイミングにおいて、新たに始まる同期期間の同期ＩＤを付与するのが最適であるが、同じ目的が達成できるのであれば、それ以外の同期ＩＤ、例えば、その時点で終了した前の同期期間の同期ＩＤ、前の前の同期期間の同期ＩＤ、又は、未来の同期ＩＤを付与するようにしてもよく、その場合も、実質的に本発明の範疇に入っている。
【０１８３】
また、ある同期期間ＳＩＤ′の再同期用データＤＡＴＡ（ＳＩＤ′）を生成する際、その同期期間ＳＩＤ′の更新パラメータリストＭＰ（ＳＩＤ′）に含まれているｐＩＤと同じｐＩＤが、それより後の同期期間ＳＩＤ″の更新パラメータリストＭＰ（ＳＩＤ″）に含まれていれば、そのｐＩＤを、その再同期用データＤＡＴＡ（ＳＩＤ′）に含めないようにしても、後の同期用データＤＡＴＡ（ＳＩＤ″）で訂正されるため、本発明の動作には何の問題も生じない。
【０１８４】
また、実施形態の説明において述べたものも含め、以上において述べた変形は、矛盾しない範囲で任意に組み合わせて適用可能である。また逆に、ネットワークシステムが実施形態の説明において述べた特徴を全て有している必要もない。
【産業上の利用可能性】
【０１８５】
以上の説明から明らかなように、この発明のリモート制御システムによれば、第１ノードから複数の第２ノードへ、変化する複数のデータを伝達する場合において、ネットワークに送出されるパケット数を少なくすることで必要とされるネットワークの通信帯域や被制御装置の処理負荷を下げ、通信帯域に対する負荷が小さく（送信すべきデータ量が小さく）、パラメータの値の伝達の信頼性が適度に確保され、かつデータの伝達を少ない時間遅れで行うことができるようにすることができる。
従って、この発明を適用することにより、リモート制御システムの利便性を向上させることができる。
【符号の説明】
【０１８６】
１…通信システム、２…制御装置、２ａ…仮想カレントメモリ、３…被制御装置、３ａ…カレントメモリ、１０…ＰＣ、２０…アンプ、３０…デジタルミキサ、４０…入出力装置、５０…エフェクタ、４００…パラメータ表示画面
【図１】
0005533504.tif 000005
【図２】
0005533504.tif 000006
【図３】
0005533504.tif 000007
【図４】
0005533504.tif 000008
【図５】
0005533504.tif 000009
【図６】
0005533504.tif 000010
【図７】
0005533504.tif 000011
【図８】
0005533504.tif 000012
【図９】
0005533504.tif 000013
【図１０】
0005533504.tif 000014
【図１１】
0005533504.tif 000015
【図１２】
0005533504.tif 000016
【図１３】
0005533504.tif 000017
【図１４】
0005533504.tif 000018
【図１５】
0005533504.tif 000019
【図１６】
0005533504.tif 000020
【図１７】
0005533504.tif 000021
【図１８】
0005533504.tif 000022
【図１９】
0005533504.tif 000023
【図２０】
0005533504.tif 000024
【図２１】
0005533504.tif 000025
【図２２】
0005533504.tif 000026
【図２３】
0005533504.tif 000027