(57)【要約】【課題】  コントローラから複数の被制御機器に同時に送出された制御信号に係るパケットを各被制御機器において遅延差なく受信可能とする遠隔制御システム及び方法を提供する。【解決手段】拠点に設置された複数の被制御機器２０と、ネットワーク上に配置されたコントローラ１０との間の通信経路にパケット転送装置であるエッジノード３０を配置する。エッジノード３０は、前記コントローラ１０から前記被制御機器２０へのパケットを転送する転送処理部３１と、前記コントローラ１０から前記複数の被制御機器２０に対して同時に送出された複数のパケットの前記複数の被制御機器２０への到着時間差が小さくなるよう前記転送処理部３１におけるパケットの送出タイミングを制御するタイミング制御部３２とを備えた。【選択図】図３
2020036072.tif 000002
【特許請求の範囲】
【請求項１】
拠点に設置された複数の被制御機器と、ネットワーク上に配置され制御信号に係るパケットをリアルタイムに送出して前記被制御機器を制御するコントローラとを備えた遠隔制御システムにおいて、
前記コントローラと前記複数の被制御機器との間に形成された１つ以上の通信経路上に配置されたパケット転送装置を備え、
前記パケット転送装置は、前記コントローラから前記被制御機器へのパケットを転送する転送処理部と、前記コントローラから前記複数の被制御機器に対して同時に送出された複数のパケットの前記複数の被制御機器への到着時間差が小さくなるよう前記転送処理部におけるパケットの送出タイミングを制御するタイミング制御部とを備えた
ことを特徴とする遠隔制御システム。
【請求項２】
前記タイミング制御部は、自身のパケット転送装置と前記コントローラとの間のパケット遅延時間と、自身のパケット転送装置が配備された通信経路とは異なる通信経路上の他のパケット転送装置から取得した当該他のパケット転送装置と前記コントローラと間のパケット遅延時間に基づき、前記転送処理部におけるパケットの送出タイミングを制御する
ことを特徴とする請求項１記載の遠隔制御システム。
【請求項３】
前記タイミング制御部は、さらに、自身のパケット転送装置と前記被制御機器との間のパケット遅延時間と、前記他のパケット転送装置から取得した当該他のパケット転送装置と前記被制御機器との間のパケット遅延時間に基づき、前記転送処理部におけるパケットの送出タイミングを制御する
ことを特徴とする請求２記載の遠隔制御システム。
【請求項４】
前記タイミング制御部は、定期的に及び前記コントローラからのパケット受信時の何れか一方又は双方のタイミングで、前記の各パケット遅延時間を取得する
ことを特徴とする請求項２又は３記載の遠隔制御システム。
【請求項５】
ネットワーク上に配置され前記パケット転送装置からのパケットの送出時刻を指示する調停装置を備え、
前記タイミング制御部は、前記コントローラからパケットを受信すると前記調停装置に通知し、前記調停装置から当該パケットの送出時刻を受信し、当該送出時刻にパケットを送出するよう前記転送処理部を制御する
ことを特徴とする請求項１記載の遠隔制御システム。
【請求項６】
前記コントローラは、前記タイミング制御部によるタイミング制御の対象とする複数の被制御機器宛のパケットに対して当該複数の被制御機器の示すグループ識別子を付与し、
前記タイミング制御部は、前記コントローラから受信したパケットに前記グループ識別子が含まれている場合にタイミング制御を行う
ことを特徴とする請求項１乃至５何れか１項記載の遠隔制御システム。
【請求項７】
拠点に設置された複数の被制御機器は、現用の通信経路を形成する現用通信手段と予備用の通信経路を形成する予備用通信手段を備え、
前記パケット転送装置は、前記現用の通信経路上及び前記予備用の通信経路上に配備されている
ことを特徴とする請求項１乃至６何れか１項記載の遠隔制御システム。
【請求項８】
拠点に設置された複数の被制御機器と、ネットワーク上に配置され制御信号に係るパケットをリアルタイムに送出して前記被制御機器を制御するコントローラとを備えた遠隔制御システムにおけるパケット制御方法において、
前記コントローラと前記複数の被制御機器との間に形成された１つ以上の通信経路上にパケット転送装置を配置し、
前記パケット転送装置の転送処理部が、前記コントローラから前記被制御機器へのパケットを受信するステップと、
前記パケット転送装置のタイミング制御部が、前記コントローラから前記複数の被制御機器に対して同時に送出された複数のパケットの前記複数の被制御機器への到着時間差が小さくなるようパケットの送出タイミングを前記転送処理部に指示するステップと、
前記パケット転送装置の前記転送処理部が、前記タイミング制御部により指示された送出タイミングで前記コントローラから受信したパケットを前記被制御機器に送信するステップとを備えた
ことを特徴とする遠隔制御システムにおけるパケット制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、拠点に設置された複数の被制御機器を、ネットワーク上に配置されたコントローラから制御する遠隔制御システムに関し、特にその制御信号に係るパケットの被制御機器への到着タイミングを調整する技術に関する。
【背景技術】
【０００２】
従来、工場などのＯＴ（Operational Technology）環境においては、被制御機器（ロボットアーム、攪拌機、温度計等）の制御を行うコントローラ（ＰＬＣ：Programmable Logic Controller）等はローカルの同一ネットワーク上に配備され、低遅延・潤沢な帯域での通信が行われている（非特許文献１参照）。このネットワークにおける通信では、例えば、ＲＳ−４８５シリアル通信であるＰＲＯＦＩＢＵＳや、ＴＣＰ（Transmission Control Protocol），ＵＤＰ（User Datagram Protocol）／ＩＰ（Internet Protocol）上で動作する産業用イーサネット（登録商標）プロトコルであるＥｔｈｅｒｎｅｔ／ＩＰや、ＴＣＰ／ＩＰ上で動作する産業用イーサネット（登録商標）プロトコルであるＭｏｄｂｕｓ／ＴＣＰなどのプロトコルが用いられる（非特許文献１参照）。
【０００３】
一方、ＰＬＣのソフトウェア実装が市中に存在し、これを用いていわゆるクラウド上にＰＬＣを具備することが可能である。市中においては、この形態での実証実験（空調制御など）が行われている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】内藤辰彦、他１名、「産業用インターネット入門」、初版、ＣＱ出版社、２００９年５月１日、Ｐ．１２−１６，Ｐ．１４４−１６１
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した非特許文献１に記載の技術とＰＬＣのソフトウェア実装技術を組み合わせることにより、クラウド上に具備したコントローラから、例えばロボットアームなどの被制御機器をコントロールすることが可能になる。しかしながら、クラウド内のコントローラが拠点内の複数の被制御機器を制御する際に、コントローラと被制御機器との間の通信経路が被制御機器間で異なる場合がある。このような場合、各通信経路間の遅延差が問題となることが考えられる。
【０００６】
コントローラと被制御機器との間の通信経路が被制御機器間で異なる場合としては、例えば以下のようなケースが想定される。被制御機器は、フォールバック（縮退運転）を可能にするために、有線ＬＡＮ（Local Area Network）用のプライマリＮＩＣ（Network Interface Card）と、ＰｒｉｖａｔｅＬＴＥ（Private Long Term Evolution）用のセカンダリＮＩＣとを備えている。拠点内の各被制御機器はプライマリＮＩＣを用いて拠点内のＬＡＮに接続している。拠点内のＬＡＮは光ファイバ回線等により第１通信事業者網に接続している。第１通信事業者網はインターネットに接続している。通常時は、コントローラと被制御機器との間の通信は第１通信事業者網を介して行われる。ここで、プライマリＮＩＣの故障等があると、被制御機器はセカンダリＮＩＣにフォールバックし、ＰｒｉｖａｔｅＬＴＥを提供する第２通信事業者網を介してコントローラと通信を行う。このようなシステムでは、拠点内の各被制御機器とコントローラとの間の通信経路が、第１通信事業者網を経由するものと第２通信事業者網を経由するものが混在する場合が生じることになる。
【０００７】
このような場合、通信経路間の遅延により以下のような問題が生じることが考えられる。例えば、第１の被制御機器は第１通信事業者網を経由し、第２の被制御機器は第２通信事業者網を経由する場合を想定する。また、第１通信事業者網内の中継装置とコントローラの遅延が８０ｍｓであり、第２通信事業者網内の中継装置とコントローラの遅延が２０ｍｓである。このような場合、第１の被制御機器と第２の被制御機器の動作タイミングにずれが生じることが考えられる。例えば、本来同一のタイミングで動作するべき第１の被制御機器と第２の被制御機器に対する動作の指令（例えば、ターンテーブル（第２の被制御機器）を６０度回転させるという動作と、ラインマーカ（第１の被制御機器）を押下しターンテーブル上の部品に色づけをする等の）のうち、第１の被制御機器へのパケット到着が第２の被制御機器より６０ｍｓ遅延した場合、色づけされる位置が６０ｍｓ移動分だけずれてしまうという問題がある。
【０００８】
この解決方法として、例えば被制御機器間での赤外線通信などによる同期処理や、各被制御機器が正確な時刻同期を行っていることを前提として、コントローラからの指令に実行タイミングを含めた上で実行を同期することも考えられるが、これらのためには全ての被制御機器に追加機能が必要となり、コストが増加する、故障可能性が高くなる、等の問題がある。
【０００９】
また、拠点内の複数の被制御機器が同一の通信経路でコントローラと通信している場合であっても、通信事業者網やインターネットにおいてはパケットの遅延時間が必ずしも保証されているとは限らず、複数の被制御機器間で遅延差が生じる場合もある。
【００１０】
本発明は上記事情に鑑みてなされたものであり、その目的とするところは、コントローラから複数の被制御機器に同時に送出された制御信号に係るパケットを各被制御機器において遅延差なく受信可能とする遠隔制御システム及び方法を提供することにある。
【課題を解決するための手段】
【００１１】
上記目的を達成するために、本願発明は、拠点に設置された複数の被制御機器と、ネットワーク上に配置され制御信号に係るパケットをリアルタイムに送出して前記被制御機器を制御するコントローラとを備えた遠隔制御システムにおいて、前記コントローラと前記複数の被制御機器との間に形成された１つ以上の通信経路上に配置されたパケット転送装置を備え、前記パケット転送装置は、前記コントローラから前記被制御機器へのパケットを転送する転送処理部と、前記コントローラから前記複数の被制御機器に対して同時に送出された複数のパケットの前記複数の被制御機器への到着時間差が小さくなるよう前記転送処理部におけるパケットの送出タイミングを制御するタイミング制御部とを備えたことを特徴とする。
【００１２】
本発明の好適な態様の一例は、前記タイミング制御部は、自身のパケット転送装置と前記コントローラとの間のパケット遅延時間と、自身のパケット転送装置が配備された通信経路とは異なる通信経路上の他のパケット転送装置から取得した当該他のパケット転送装置と前記コントローラと間のパケット遅延時間に基づき、前記転送処理部におけるパケットの送出タイミングを制御することを特徴とする。
【００１３】
本発明の好適な態様の他の例は、ネットワーク上に配置され前記パケット転送装置からのパケットの送出時刻を指示する調停装置を備え、前記タイミング制御部は、前記コントローラからパケットを受信すると前記調停装置に通知し、前記調停装置から当該パケットの送出時刻を受信し、当該送出時刻にパケットを送出するよう前記転送処理部を制御する
ことを特徴とする。
【発明の効果】
【００１４】
本発明によれば、従来同一ＬＡＮ内に存在していたコントローラ・被制御機器のうちコントローラをクラウド化した場合においても、被制御機器への追加機能（例：赤外線通信による同期処理や、各被制御機器での正確な時刻同期を前提とした実行タイミングを含めた実行の同期）無しに、被制御機器の同期した動作が可能になる。
【図面の簡単な説明】
【００１５】
【図１】本発明に係る遠隔制御システムにおいて想定するネットワーク環境の構成図
【図２】本発明において想定するネットワーク環境の変化について説明する図
【図３】方式１に係る遠隔制御システムの概要を説明する図
【図４】方式１のバリエーション１に係る遠隔制御システムの概要を説明する図
【図５】方式１のバリエーション２に係る遠隔制御システムの概要を説明する図
【図６】方式２に係る遠隔制御システムの概要を説明する図
【図７】第１の実施の形態に係る遠隔制御システムの構成図
【図８】第１の実施の形態に係るエッジノードの機能ブロック図
【図９】グループ管理テーブルの一例
【図１０】機器識別子管理テーブルの一例
【図１１】通信経路管理テーブルの一例
【図１２】エッジノードにおける管理情報の更新のフローチャート
【図１３】コントローラ側遅延管理テーブルの一例
【図１４】エッジノードにおける遅延測定及び共有のフローチャート
【図１５】エッジノードにおけるバッファリングのフローチャート
【図１６】第２の実施の形態に係るエッジノードの機能ブロック図
【図１７】機器側遅延管理テーブルの一例
【図１８】エッジノードにおける遅延測定及び共有のフローチャート
【図１９】エッジノードにおけるバッファリングのフローチャート
【図２０】第３の実施の形態の効果を説明する図
【図２１】第４の実施の形態に係る遠隔制御システムの構成図
【図２２】第４の実施の形態に係るアプリケーションサーバの機能ブロック図
【図２３】第４の実施の形態に係るエッジノードの機能ブロック図
【図２４】エッジノード及びアプリケーションサーバにおける同期制御のフローチャート
【発明を実施するための形態】
【００１６】
＜本発明の概要＞
まず本発明に係る遠隔制御システムの概要について図面を参照して説明する。まず、図１を参照して本発明に係る遠隔制御システムにおいて想定するネットワーク環境について説明する。図１は本発明に係る遠隔制御システムにおいて想定するネットワーク環境の構成図である。
【００１７】
なお、以降の説明では、複数の同種の装置・構成については共通の主参照符号を付すとともに、各装置・構成を個別に参照するために前記主参照符号の後に枝番を付した。また、複数の同種の装置・構成を総称する際には主参照符号のみを用いる。
【００１８】
本発明は、図１に示すように、クラウド１上のコントローラ１０からの動作指示を受ける複数の被制御機器（ロボットアーム等）２０が、異なるエッジノード３０配下に存在する場合を想定する。
【００１９】
クラウド１は例えばインターネット等に配備され各種サービスを提供可能なプラットフォームであり、コントローラ１０はクラウド１が提供する物理サーバ又は仮想サーバに実装される。なお、クラウド１の配備位置は不問であり、インターネットに配備されたものだけでなく、通信事業者網の閉域網に配備されたものや、遠隔制御システムの利用者の管理する情報システム内に配備されたもの（所謂「オンプレミスクラウド」）であってもよい。コントローラ１０は、被制御機器２０に対して制御信号に係るパケットをリアルタイムに送出することにより被制御機器２０を制御する。ここで、コントローラ１０は、複数の被制御機器２０に対して、各被制御機器２０が同期して動作するよう、同時に制御信号に係るパケットを送出する場合がある点に留意されたい。
【００２０】
ローカル２に存在する複数の被制御機器２０は、同一の拠点（ロケーション）に配備されている。各被制御機器２０は、それぞれコントローラ１０から制御信号に係るパケットを受信すると、当該制御信号に基づき各種動作を行う。
【００２１】
エッジ３は、遠隔制御システム全体のネットワーク構成におけるエッジノード３０が配備されている位置を示すものであり、典型的な例では、被制御機器２０を収容するようアクセス回線を提供する通信事業者のネットワークの位置や、インターネット接続サービスを提供する通信事業者網のネットワークの位置を示す。エッジノード３０は、エッジ３においてコントローラ１０と被制御機器２０との間の通信経路上に配置され、両者間のパケットを転送する装置である。すなわち、被制御機器２０とコントローラ１０との通信経路は少なくとも１つの通信事業者網が含まれる。なお、エッジ３及びエッジノード３０の他の形態については後述する。
【００２２】
エッジノード３０は、主に半導体装置で構成され、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）等の揮発性記憶装置、ハードディスクやフラッシュメモリ等の不揮発性記憶装置、及び外部との通信のための接続を行う通信インタフェースを有する、いわゆる情報処理機器として構成することができる。エッジノード３０は、専用のハードウェアとして実装してもよいし、汎用のハードウェア上に構築された仮想化環境に実装してもよい。
【００２３】
クラウド１上のコントローラ１０から被制御端末２０に対して制御指示に係るパケットを送出する方法としては、本発明では、ＴＣＰ／ＩＰ上のプロトコルを想定している。具体的には、Ｅｔｈｅｒｎｅｔ／ＩＰ，Ｍｏｄｂｕｓ／ＴＣＰ等の産業用イーサネット（登録商標）プロトコルの他、例えばＨＴＴＰ（Hypertext Transfer Protocol）  Ｒｅｓｔ等のプロトコルを使用してもよい。これらのプロトコルは、トランスポート層にＴＣＰまたはＵＤＰを用いることが一般的である。本発明においても、ＴＣＰまたはＵＤＰを用いることを想定する。
【００２４】
なお、本発明においては、制御指示に係るパケットを取り扱う方法について記載しているが、ＵＤＰパケットの使用時においては、ＴＣＰの場合と異なり、単発のパケットが送信され、当該パケットの取り扱いが行われる。一方、ＴＣＰパケットの使用時においては、制御指示を含むパケットの送出の直前あるいは以前にＴＣＰセッションの確立が行われる。本発明においてＴＣＰパケットが用いられる場合は、ＴＣＰセッションの確立済みを前提として、当該セッションを用いて行われる制御指示パケットについて、処理が行われる。
【００２５】
本発明では、拠点内の複数の被制御機器２０が、互いに異なる通信経路、すなわち互いに異なるエッジ３を経由するケースを想定する。図１の例では、ある被制御機器２０−１は、固定回線を介して接続したエッジ３−１を経由してコントローラ１０と通信し、ある被制御機器２０−２は、ＬＴＥなどのモバイル回線を介して接続したエッジ３−２を経由してコントローラ１０と通信することを想定する。このような例としては、図２に示すように、通常時は、拠点内の全ての被制御機器２０はエッジ３−１を介してコントローラ１０と通信していることを前提として、そのうちの一部の被制御機器２０においてＮＩＣ（有線ＬＡＮ）が故障して、別回線であるエッジ３−２にフォールバックした場合が想定される。なお、フォールバック先の回線としては、通常のＬＴＥだけでなく、フェムトセルや、ＰｒｉｖａｔｅＬＴＥ等など、他の規格・世代、あるいは運用主体が異なる無線回線であってもよい。さらに、フォールバック先の回線としては、フォールバック元の回線とは別の固定回線（有線回線）であってもよい。
【００２６】
本発明では、図１に示すように、クラウド１・エッジ３間（インターネット区間を含む）は遅延が大きく、通信経路によって遅延に差があることを想定する。一方、エッジ３と被制御機器２０間は遅延が十分小さく、通信経路による遅延の差が少ないことを想定する。
【００２７】
本発明は、上記のネットワーク環境を想定し、エッジノード３０において制御信号に係るパケットのバッファリング（後述する方式１）または同期（後述する方式２）を行うことで、上記ネットワーク環境下であっても複数の被制御機器２０への信号到着の時間差を十分小さくする。すなわち、コントローラ１０からの制御指示に係るパケットを同時に被制御機器２０が受け取れるようにするために、ネットワーク側でのパケット転送にあたり、遅延差の吸収を行う。これにより、従来同一ＬＡＮ内に存在していたコントローラ１０・被制御機器２０のうちコントローラ１０をクラウド化した場合においても、被制御機器２０への追加機能（例：赤外線通信による同期処理や、各被制御機器での正確な時刻同期を前提とした実行タイミングを含めた実行の同期）無しに、被制御機器２０の同期した動作が可能になる。
【００２８】
以下に前述の方式及び方式２について説明する。まず方式１の概要について図３を参照して説明する。図３は方式１に係る遠隔制御システムの概要を説明する図である。
【００２９】
［方式１］
本方式１は、受信したパケットの転送を留保し、観測済みクラウド１・エッジ３間の遅延値、具体的にはコントローラ１０・エッジノード３０間の遅延値に基づき、最も遅延が大きい通信経路に合わせるために、遅延が少ない通信経路では遅延を意図的に付加してパケット転送を行うものである。具体的には、コントローラ１０・エッジノード３０間の遅延値を定期的に観測し、各エッジノード３０間で遅延値を共有し、最も遅延の大きいエッジノード３０を基準として、その他のエッジノード３０において遅延値の差分だけパケットをバッファリングする。なお、図３においては、エッジノード３０間の遅延値を被制御機器２０間で共有するための手段については省略している。当該共有手段としては、例えばブローカサーバ経由のＰｕｂ／Ｓｕｂ通信などが挙げられる。
【００３０】
本方式１では、仕組みが単純で機能が少なくてすむ、コントローラ１０が制御指示を発してから被制御機器２０に到着するまでの時間が短い（遅延のワースト値と一致）、などの長所がある。一方、本方式１では、急な遅延揺らぎに弱い、遅延測定のトラフィックが発生する、などの短所がある。
【００３１】
［方式１のバリエーション１］
本方式１の２つのバリエーションについて参照して説明する。まずバリエーション１について図４を参照して説明する。図４は方式１のバリエーション１に係る遠隔制御システムの概要を説明する図である。
【００３２】
バリエーション１は、方式１からさらに機能拡張し、コントローラ１０・エッジノード３０間のみならず、エッジノード３０・被制御機器２０間も定常的に遅延測定を実施し、両データに基づきバッファリング時間を決定する方法である。
【００３３】
このバリエーション１では、各通信経路間の遅延差をより正確に把握することができるので、コントローラ１０による被制御機器２０の制御をより高精度に行うことができる。一方、このバリエーション１は、例えば、コントローラ１０の数が１、被制御機器２０の数が多数（例えば１０００）等の場合においては、コントローラ１０・エッジノード３０間のみ遅延測定を行う場合に比べて、測定パケットが多くなりリソース消費が激しくなるという短所がある。
【００３４】
［方式１のバリエーション２］
本方式１のバリエーション２について図５を参照して説明する。図５は方式１のバリエーション２に係る遠隔制御システムの概要を説明する図である。
【００３５】
バリエーション２では、遅延測定を定常的に行うことに代え、あるいは加えて、制御指示パケットの到着時に遅延を測定し、その結果を以てバッファリング時間を決定する方法である。
【００３６】
このバリエーション２では、より直近の遅延情報に基づき、バッファリング時間を決定することができるので、コントローラ１０による被制御機器２０の制御をより高精度に行うことができる。一方、このバリエーション２は、制御指示到着時にクラウド１上のコントローラ１０およびブローカサーバ（図示省略）との通信が発生するため、コントローラ１０から被制御機器２０への通信のリアルタイム性がやや損なわれてしまうという短所がある。
【００３７】
なお、上記バリエーション１とバリエーション２は同時に適用することもできる。
【００３８】
［方式２］
次に、方式２の概要について図６を参照して説明する。図６は方式２に係る遠隔制御システムの概要を説明する図である。
【００３９】
本方式２は、受信したパケットの転送を留保し、エッジノード３０同士が協調し、同期して配下の被制御機器２０に対して、同時に実行すべき制御信号に係るパケットを転送するものである。具体的には、まず、図６に示すように、被制御機器２０間のパケット送出時刻を調停する調停装置としてのアプリケーションサーバ４０をネットワーク上に配備する。各エッジノード３０とアプリケーションサーバ４０とは定常的にＮＴＰ（Network Time Protocol）などの時刻同期手段により時刻同期しておく。各エッジノード３０はコントローラ１０から制御信号に係るパケットを受信するとパケットを受信したことをアプリケーションサーバ４０に通知し、アプリケーションサーバ４０は被制御機器２０へのパケット転送タイミング（送出時刻Ｔ）を決定して各エッジノード３０に通知する。各エッジノード３０は、アプリケーションサーバ４０から受信した送出時刻Ｔになると当該パケットを送出する。
【００４０】
本方式２では、遅延揺らぎの影響を受けず、確実に同時に被制御機器２０に対するパケット送信が出来る（エッジ３・ローカル２間の遅延が少ない程、有効である）、トラフィック量が少ない、などの長所がある。一方、仕組みが複雑であり同期のためのアプリケーションサーバ４０が必要である、エッジノード３０で待機を行うためリアルタイム性が低い、などの短所がある。
【００４１】
なお、図６の例ではアプリケーションサーバ４０をコントローラ１０と同じクラウド１に配置しているが、ネットワーク上の他の位置に配置してもよい。また、本方式２は、各被制御機器２０が単一のエッジノード３０配下に存在する場合にも有効である。
【００４２】
ところで、本発明においては、コントローラ１０・被制御機器２０間に介在するパケット転送装置をエッジノードと呼んでいるが、本パケット転送装置については、コントローラ１０・被制御機器２０間の通信経路上の任意の場所に具備されて良い。すなわち、パケット転送装置は、通信事業者の管理する場所に設置してもよいし、被制御機器２０の管理者の管理する場所に設置してもよいし、パケット転送装置の本発明に係る機能を被制御機器２０に内包するようにしてもよい。具体的には、以下の配備場所が挙げられる。
【００４３】
・通信事業者網（アクセス提供事業者）からＩＳＰ（Internet Service Provider）網へ接続するＰＯＩ（Point Of Interface）点
・通信事業者網（アクセス提供事業者）が地域網（Metropolitan Area Network）に接続をする通信ビル（電話局など）
・工場などのユーザ宅内ＬＡＮと通信事業者との接続ＧＷ（GateWay）
・ユーザ宅内ＬＡＮ内特定セグメントのＧＷ
・ユーザ宅内被制御機器が接続されているイーサネット（登録商標）コンバータ装置
・工場などのユーザ宅内に具備されたモバイル通信事業者の管理する通信基地局（ＬＴＥ基地局、フェムトセル基地局など）
・工場等のユーザ宅内に具備された、ユーザの管理する通信基地局（ＰｒｉｖａｔｅＬＴＥ基地局、ＷｉＦｉ（登録商標）アクセスポイントなど）
【００４４】
また、被制御機器２０内に当該機能を含めても良い。この場合、上述した「従来同一ＬＡＮ内に存在していたコントローラ１０・被制御機器２０のうちコントローラをクラウド化した場合においても、被制御機器２０への追加機能（例：赤外線通信による同期処理や、各被制御機器での正確な時刻同期を前提とした実行タイミングを含めた実行の同期）無しに、被制御機器２０の同期した動作が可能になる」のうち、「被制御機器２０への追加機能（例：赤外線・通信による同期処理や、各被制御機器での正確な時刻同期を前提として実行タイミングを含めた実行の同期）無しに」という点が満たせない、という短所がある。
【００４５】
また、コントローラ１０に当該機能を含めても良い。この場合、方式１についてはバリエーション１適用の場合のみ有効となり、被制御機器２０が多数の場合には遅延測定パケットが大量に発生する、という短所がある。また、方式２については本質的に意味の無い機能配備となるが、実装は可能である。
【００４６】
以下に本発明のより詳細な実施の形態について詳述する。
【００４７】
＜第１の実施の形態（方式１）＞
まず、本発明の第１の実施の形態に係る遠隔制御システムの詳細について図７を参照して説明する。図７は本発明の第１の実施の形態に係る遠隔制御システムの構成図である。なお、上述した本発明の概要と同一の構成については同一の符号を付した。
【００４８】
方式１は、主に以下の技術からなる。（１）各エッジノード３０における、論理的被制御機器グルーピングと物理構成の管理方法、（２）上記管理情報の作成方法、および構成変更時のアップデート方法、（３）各エッジノード３０における、コントローラ１０・エッジノード３０間の遅延情報の管理方法、（４）定常的なコントローラ１０・エッジノード３０間の遅延測定と結果の共有方法、（５）コントローラ１０からの制御信号に係るパケット到着時のバッファリング方法。なお、「論理的被制御機器グルーピング」とは、コントローラ１０から複数の被制御機器２０を同時に制御したい場合（例えば、ターンテーブルの回転とアームの降下を同時に行う等のケースが想定される）に備え、これら被制御機器２０を論理的にグルーピングすることを指す。また、そのグループを指す。
【００４９】
前述したように、方式１は、あらかじめ測定した遅延情報を基にエッジノード３０でのバッファリングを行うため、クラウド１・エッジ３間の遅延の揺らぎ（ジッタ）が小さい場合に有用である。
【００５０】
本実施の形態に係る遠隔制御システムは、図７に示すように、クラウド１に配置されたコントローラ１０と、ローカル２に配置された複数（図７では３つ）の被制御機器２０と、被制御機器２０をコントローラ１０とを接続するためのネットワークである複数（図７では２つ）のエッジ３にそれぞれ配置されたエッジノード３０と、クラウド１上に配置されエッジノード３０間の情報共有のためのＭＱＴＴ（Message Queuing Telemetry Transport）ブローカサーバ５０を備えている。ＭＱＴＴブローカサーバ５０はＭＱＴＴによるＰｕｂ／Ｓｕｂ通信を中継する装置である。なお、図７では、ＭＱＴＴブローカサーバ５０はクラウド１に配備しているが、各エッジノード３０と通信可能であるなら配備位置は不問である。
【００５１】
エッジノード３０は、コントローラ１０と被制御機器２０の間に介在し、以下の機能を持つ。（ａ）コントローラ１０と被制御機器２０の間でパケットを転送する、（ｂ）コントローラ１０と自エッジノード３０間の遅延時間を定期的に測定する。またその内容を記録する。（ｃ）ＭＱＴＴブローカサーバ５０と通信し、上記測定結果を他エッジノード３０に通知する。また同様に他エッジノード３０からの通知を受け、またその内容を記録する。
【００５２】
上記機能を実現するため、エッジノード３０は、図８に示すように、転送処理部３１と、タイミング制御部３３とを備える。転送処理部３１は前記（ａ）の機能を有するものであり、バッファ３２を含む。タイミング制御部３３は前記（ｂ）及び（ｃ）の機能を有するものであり、遅延計測部３４と、グループ管理テーブル３５と、機器識別子管理テーブル３６と、通信経路管理テーブル３７と、コントローラ側遅延管理テーブル３８とを含む。
【００５３】
以下、前述した（１）〜（５）の構成技術についてそれぞれ説明することにより、本実施の形態に係る遠隔制御システムについて説明する。
【００５４】
［（１）各エッジノード３０における、論理的被制御機器グルーピングと物理構成の管理方法］
各エッジノード３０は、前述したように、グループ管理テーブル３５と、機器識別子管理テーブル３６と、通信経路管理テーブル３７を保持する。グループ管理テーブル３５は、図９に示すように、コントローラ１０からの制御指示に係るパケットを同時に届かせる必要がある被制御機器２０のグルーピングを情報として保持する。機器識別子管理テーブル３６は、図１０に示すように、被制御機器２０の名前と当該被制御機器２０の識別子（例えばＩＰアドレス）の関係を保持する。通信経路管理テーブル３７は、図１１に示すように、各被制御機器２０が接続している上位エッジノード３０を記録する。エッジノード３０の識別子としては、特定の文字列（例：ＥＮ１）を用いる。
【００５５】
［（２）上記管理情報の作成方法、および構成変更時のアップデート方法］
グループ管理テーブル３５、機器識別子管理テーブル３６、通信経路管理テーブル３７は、あらかじめ手動入力により各エッジノード３０に登録される。エッジノード３０における管理情報の更新のフローチャートを図１２に示す。
【００５６】
図１２に示すように、例えば被制御機器２０のＮＩＣ故障により別回線にフォールバックした場合など、被制御機器２０の上流エッジノード３０が変更された場合は、新上流エッジノード３０がこれを自動的に検知し（ステップＳ１１）、各エッジノード３０に情報共有した上で、各エッジノード３０は自テーブルをアップデートする（ステップＳ１２）。また同時に、新上流エッジノード３０はクラウド１上のコントローラ１０に対して被制御機器２０の新ＩＰアドレスを通知する（ステップＳ１３）。これにより、クラウド１上のコントローラ１０は被制御機器２０に対して引き続き指示が行える。
【００５７】
テーブル更新についての、具体的な動作シーケンスは以下の通りである。ここでは、エッジノード３０−１の配下に具備された被制御機器２０−１，２０−２，２０−３のうち、被制御機器２０−３がエッジノード３０−２の配下にフォールバックしたときの例を示す。
【００５８】
１．  被制御機器２０−３の使用ＮＩＣが変更され、新たにエッジノード２０−２配下の回線に接続される。被制御機器２０−３は、あらかじめ自装置の設定情報に記載されているエッジノード２０−２配下の回線接続用のＩＰアドレスを新ＮＩＣに設定する。この際、被制御機器２０−３は、ＧｒａｔｕｉｔｏｕｓＡＲＰ（Gratuitous Address Resolution Protocol）を送信し、これにより同一セグメント上のネットワーク機器のＭＡＣ（Media Access Control）アドレステーブル及びＡＲＰキャッシュを更新させる。
【００５９】
２．  エッジノード３０−２がＧｒａｔｕｉｔｏｕｓＡＲＰを受信し、自配下に新たな被制御機器２０−３が追加されたことを認識する。エッジノード３０−２は、被制御機器２０−３の新たなＩＰアドレスおよび、被制御機器２０−３が新たに追加された旨を、ＭＱＴＴブローカサーバ５０にＰｕｂｌｉｓｈする。また同時に、エッジノード３０−２は自身の機器識別子管理テーブル３６及び通信経路管理テーブル３７を更新する。具体的には、機器識別子管理テーブル３６内の被制御機器２０−３のＩＰアドレスを新しいものに更新する。また、通信経路管理テーブル３７内の被制御機器２０−３に対応するエッジノードを、エッジノード３０−２を示す「ＥＮ２」に変更する。
【００６０】
３．  ＭＱＴＴブローカサーバ５０は、あらかじめ購読登録されている各エッジノード３０に当該情報を通知する。各エッジノード３０は、上記ステップと同様に、自身の機器識別子管理テーブル３６及び通信経路管理テーブル３７を更新する。
【００６１】
［（３）各エッジノード３０における、コントローラ１０・エッジノード３０間の遅延情報の管理方法］
エッジノード３０は、上述したように、クラウド１上のコントローラ１０・各エッジノード３０間の片道遅延をコントローラ側遅延管理テーブル３８として保持する。図１３にコントローラ側遅延管理テーブル３８の一例を示す。コントローラ側遅延管理テーブル３８上の片道遅延値は、後述する構成技術（４）で説明される方法によって随時アップデートされる。
【００６２】
なお、後述する構成技術（４）で説明される方法においては、各エッジノード３０とクラウド１上のコントローラ１０との片道遅延値はエッジノード３０同士で共有される。このため、基本的に各エッジノード３０上のコントローラ側遅延管理テーブル３８は同一のデータとなる。例外としては、例えばネットワークの輻輳により特定エッジノード３０にのみ片道遅延値の変更メッセージ（ＭＱＴＴ）が届かず、アップデートが失敗した場合、等が考えられる。
【００６３】
［（４）定常的なコントローラ１０・エッジノード３０間の遅延測定と結果の共有方法］
本構成技術（４）は、主にタイミング制御部３３の遅延計測部３４により実現される。エッジノード３０における遅延測定及び共有のフローチャートを図１４に示す。
【００６４】
図１４に示すように、各エッジノード３０は、クラウド１上のコントローラ１０と自身の間のＲＴＴ（Round Trip Time）を所定の時間間隔（例えば１秒おき）で測定し（ステップＳ２１）、その値を２で割った値を、コントローラ１０・エッジノード３０間片道遅延として、前記構成技術（３）で説明したように、自身のメモリのコントローラ側遅延管理テーブル３８にストアする（ステップＳ２２）。
【００６５】
また、各エッジノード３０は、それぞれの片道遅延値を所定の時間間隔毎（例えば１秒毎）に共有する（ステップＳ２３）。この方法としては、例えばクラウド１上に具備されたＭＱＴＴブローカサーバ５０と連携したＰｕｂ／Ｓｕｂ通信により実施される。他の方法としては、エッジノード３０間のインターネット経由Ｐ２Ｐ（Peer to Peer）通信（ＷｅｂＲＴＣ（Web Real-Time Communication）等）や、エッジノード３０間を直接結んだリングネットワーク上でのトークン型通信も考えられる。
【００６６】
動作ステップは以下のようになる。以下の説明では、あるエッジノード３０についての動作を説明する。各エッジノード３０の動作はそれぞれ非同期に行われ、それらの動作は当該エッジノード３０の動作と同一のため、詳細を割愛する。
【００６７】
１．  エッジノード３０は、あらかじめクラウド１上のＭＱＴＴブローカサーバ５０に自身を登録しておく。また、本アルゴリズムの動作に必要な情報を取得するための購読（例：トピック名”ｏｎｅｗａｙ＿ｄｅｌａｙ＿ｓｈａｒｅ”）をしておく。
【００６８】
２．  エッジノード３０が、あらかじめ登録されているクラウド１上のコントローラ１０のＩＰアドレスを宛先として、ＩＣＭＰ（Internet Control Message Protocol）  Ｅｃｈｏ  Ｒｅｑｕｅｓｔを送出する。
【００６９】
３．  クラウド１上のコントローラ１０がエッジノード３０に対してＩＣＭＰ  Ｅｃｈｏ  Ｒｅｐｌｙを送出し、エッジノード３０がこれを受信する。
【００７０】
４．  エッジノード３０は、ＩＣＭＰ  ｅｃｈｏ  Ｒｅｑｕｅｓｔの送出タイミングとＩＣＭＰ  Ｅｃｈｏ  Ｒｅｐｌｙの受信タイミングの差を２で割った値を、クラウド１上のコントローラ１０・エッジノード３０間の片道遅延として自身のメモリのコントローラ側遅延管理テーブル３８に記録する。
【００７１】
５．  上記ステップの完了後、即座にエッジノード３０はクラウド１上に具備されたＭＱＴＴブローカサーバ５０に上記片道遅延値をＰｕｂｌｉｓｈする。これは、ＱｏＳ０にて実施される。
【００７２】
６．  上記ステップの完了後、エッジノード３０は１秒間待機したのち、上記ステップ２へ戻る。なお、この待機時間中に、エッジノード３０が購読中のメッセージ、すなわち他エッジノード３０からの、クラウド１上のコントローラ１０・当該エッジノード３０間の片道遅延に関する情報アップデートをＭＱＴＴブローカサーバ５０から受信した場合は、自身のメモリ上のコントローラ側遅延管理テーブル３８の当該エッジノード３０の項にアップデートする。
【００７３】
［（５）コントローラ１０からの制御信号に係るパケット到着時のバッファリング方法］
クラウド１上のコントローラ１０が、各被制御機器２０に対して制御指示に係るパケットを送出する際、制御対象である被制御機器２０のグループを示すグループＩＤをパケット中に埋め込む。具体的には、非特許文献１に示したＥｔｈｅｒｎｅｔ／ＩＰ使用時においては、アプリケーション層であるＣＩＰ（Common Industrial Protocol）内データとして埋め込む。これにより、エッジノード３０では、クラウド１上のコントローラ２０から他の被制御機器２０に対して送出されたパケットの存在を認識することができる。
【００７４】
エッジノード３０におけるバッファリングのフローチャートを図１５に示す。図１５に示すように、エッジノード３０が当該指示に係るパケットを受信し、被制御機器２０に転送する際に、当該グループＩＤをキーに、各テーブル３５，３６，３７を参照して、同一グループＩＤのパケットがどのエッジノード３０を通過するかを取得する（ステップＳ３１）。
【００７５】
エッジノード３０は同一グループＩＤのパケットが通過する他のエッジノード３０のそれぞれについて、自メモリのコントローラ側遅延管理テーブル３８に登録済みの片道遅延値を取得する（ステップＳ３２）。
【００７６】
エッジノード３０は、片道遅延値のリストであるコントローラ側遅延管理テーブル３８を参照し、（最も大きな片道遅延値）−（自エッジノード３０の片道遅延値）の値分だけウェイトした後、被制御機器２０へのパケット転送を実施する（ステップＳ３３）。
【００７７】
以下にパケット到着時のバッファリングの具体例について説明する。ここでの説明では、構成技術（１）の説明において示したテーブル例の状態に基づき説明する。なお、各エッジノード３０のテーブル上には、クラウド１上のコントローラ１０・エッジノード３０−１間が片道遅延８０ｍｓ，クラウド１上のコントローラ１０・エッジノード３０−２間が片道遅延２０ｍｓという情報が登録されている状況を前提とする。また、実際の遅延状態については、クラウド１上のコントローラ１０・エッジノード３０−１間が片道遅延７９ｍｓ，クラウド１上のコントローラ１０・エッジノード３０−２間が片道遅延２１ｍｓという状況を想定する。
【００７８】
詳細な動作ステップは以下のようになる。以下では、各パケットの転送を担うエッジノード３０−１，３０−２の両方を含めた説明をする。
【００７９】
１．  クラウド１上のコントローラ１０が、被制御機器２０−１，２０−２，２０−３を同時に動作させることを目的に、これら被制御機器２０−１，２０−２，２０−３に対して制御パケットを送出する。この際、制御パケットには、「グループＩＤ１」という情報が埋め込まれている。なお、これらの３つのパケットを、以下ではパケット１，パケット２，パケット３と呼称する。
【００８０】
２．  上記ステップ１の２１ｍｓ後、エッジノード３０−２にパケット３が到着する。
【００８１】
３．  上記ステップ２に引き続きエッジノード３０−２は、パケット３の中身を参照し、グループＩＤが１であることを認識する。エッジノード３０−２はグループ管理テーブル３５を参照し、グループＩＤ１に属する被制御機器２０が被制御機器２０−１，２０−２，２０−３であることを認識する。エッジノード３０−２は、パケット３の宛先のＩＰアドレスをキーに各テーブルを参照し、宛先が被制御機器２０−３であることを認識した上で、残りの被制御機器２０−１，２０−２に対応するエッジノード３０がどちらもエッジノード３０−１であることを認識する。エッジノード３０−１の片道遅延値が８０ｍｓ，エッジノード３０−２の片道遅延値が２０ｍｓであることから、エッジノード３０−２は６０ｍｓウェイトをかけることを決定する。
【００８２】
４．  上記ステップ１から数えて７９ｍｓ後、エッジノード３０−１にパケット１，２が到着する。パケット１，２はそれぞれ独立したパケットであるため、厳密には到着が前後する可能性があり、その場合は以下の手順はそのズレをそのまま引きずって動作することになる（動作はパケット１，２に対して独立して行われる）。ここでは、２つのパケットはほぼ同時に、パケット１，２の順番で到着したと想定して動作を説明する。
【００８３】
５．  上記ステップ４に引き続き、エッジノード３０−１は、パケット１の中身を参照し、グループＩＤが１であることを認識する。エッジノード３０−１はグループ管理テーブル３５を参照し、グループＩＤ１に属する被制御機器２０が被制御機器２０−１，２０−２，２０−３であることを認識する。エッジノード３０−１は、パケット１の宛先が被制御機器２０−１であることを認識した上で、残りの被制御機器２０−２，２０−３に対応するエッジノード３０がそれぞれエッジノード３０−１，３０−２であることを認識する。エッジノード３０−１の片道遅延値が８０ｍｓ、エッジノード３０−２の片道遅延値が２０ｍｓであることから、エッジノード３０−１はウェイトをかけないことを決定する。エッジノード３０−１は即座にパケット１の転送を実施する。
【００８４】
６．  引き続き、エッジノード３０−１はパケット２の中身を参照し、グループＩＤが１であることを認識する。エッジノード３０−１はグループ管理テーブル３５を参照し、グループＩＤ１に属する被制御機器２０が被制御機器２０−１，２０−２，２０−３であることを認識する。エッジノード３０−１は、パケット２の宛先が被制御機器２０−２であることを認識した上で、残りの被制御機器２０−１，２０−３に対応するエッジノード３０がそれぞれエッジノード３０−１，エッジノード３０−２であることを認識する。エッジノード３０−１の片道遅延値が８０ｍｓ、エッジノード３０−２の片道遅延値が２０ｍｓであることから、エッジノード３０−１はウェイトをかけないことを決定する。エッジノード３０−１は即座にパケット２の転送を実施する。
【００８５】
７．  上記ステップ１から数えて８０ｍｓ後、パケット１，２が被制御機器２０−１，２０−２に到着する。
【００８６】
８．  上記ステップ１から数えて８１ｍｓ後、エッジノード３０−２はパケット３を被制御機器２０−３に転送する。
【００８７】
９．  上記ステップ１から数えて８２ｍｓ後、パケット３が被制御機器２０−３に到着する。
【００８８】
＜第２の実施の形態（方式１のバリエーション１）＞
次に、本発明の第２の実施の形態に係る遠隔制御システムの詳細について説明する。本実施の形態（方式１のバリエーション１）が第１の実施の形態（方式１）と異なる点は、エッジノード３０と被制御機器２０との間の遅延についても計測し、当該遅延も考慮したパケット送出制御を行う点にある。他の点については第１の実施の形態と同様なのでここでは相違点のみを説明する。
【００８９】
方式１のバリエーション１は、主に以下の技術からなる。（１）各エッジノード３０における、論理的被制御機器グルーピングと物理構成の管理方法、（２）上記管理情報の作成方法、および構成変更時のアップデート方法、（３）各エッジノード３０における、コントローラ１０・エッジノード３０間の遅延情報の管理方法、（４）定常的なコントローラ１０・エッジノード３０間の遅延測定と結果の共有方法、（５）各エッジノード３０における、エッジノード３０・被制御機器２０間の遅延情報の管理方法、（６）定常的なエッジノード３０・被制御機器２０間の遅延測定と結果の共有方法、（７）コントローラからの指示到着時のバッファリング方法。
【００９０】
図１６に示すように、本実施の形態に係る遠隔制御システムは、上記第１の実施形態において説明した構成に加え、機器側遅延管理テーブル３９を備えている。エッジノード３０のタイミング制御部３３は、自エッジノード３０とコントローラ１０間の遅延時間を定期的に測定・記録する機能に加えて、自エッジノード３０と配下の被制御機器２０間の遅延時間を定期的に測定・記録する機能を有する。また、タイミング制御部３３は、ＭＱＴＴブローカサーバ５０と通信し、上記測定結果を他エッジノード３０に通知する。また同様に他エッジノード３０からの通知を受け、その内容を記録する。また、タイミング制御部３３は、バッファリング時間を算出する際に、エッジノード３０とコントローラ１０間の遅延時間だけでなく、エッジノード３０と被制御機器２０間の遅延時間も考慮した計算を行う。
【００９１】
以下、前述した（１）〜（７）の構成技術についてそれぞれ説明することにより、本実施の形態に係る遠隔制御システムについて説明する。構成技術（１）〜（４）については、第１の実施の形態における構成技術（１）〜（４）と同一なので、ここでは説明を省略する。
【００９２】
［（５）各エッジノード３０における、エッジノード３０・被制御機器２０間の遅延情報の管理方法］
エッジノード３０は、各エッジノード３０・被制御機器２０間の片道遅延を機器側遅延管理テーブル２０として保持する。図１７に機器側遅延管理テーブル３９の一例を示す。機器側遅延管理テーブル３９上の片道遅延値は、後述する構成技術（６）で説明される方法によって随時アップデートされる。
【００９３】
なお、後述する構成技術（６）で説明される方法においては、各エッジノード３０と被制御機器２０との間の片道遅延値はエッジノード３０同士で共有される。このため、基本的に各エッジノード３０上の機器側遅延管理テーブル３９は同一のデータとなる。例外としては、例えばネットワークの輻輳により特定エッジノード３０にのみ片道遅延値の変更メッセージ（ＭＱＴＴ）が届かず、アップデートが遅れた場合、等が考えられる。
【００９４】
［（６）定常的なエッジノード３０・被制御機器２０間の遅延測定と結果の共有方法］
本構成技術（６）は、主にタイミング制御部３３の遅延計測部３４により実現される。エッジノード３０における遅延測定及び共有のフローチャートを図１８に示す。
【００９５】
図１８に示すように、各エッジノード３０は、配下の被制御機器２０との間のＲＴＴを所定の時間間隔（例えば１秒おき）で測定し（ステップＳ４１）、その値を２で割った値を、エッジノード３０・被制御機器２０間片道遅延として、前記構成技術（５）で説明したように、自身のメモリの機器側遅延管理テーブル３９にストアする（ステップＳ４２）。なお、この時点では、当然、自配下の被制御機器２０との片道遅延しか更新されない。
【００９６】
また、各エッジノード３０は、それぞれの片道遅延値を所定の時間間隔毎（例えば１秒毎）に共有する（ステップＳ４３）。この方法としては、例えばクラウド１上に具備されたＭＱＴＴブローカサーバ５０と連携したＰｕｂ／Ｓｕｂ通信により実施される。他の方法としては、エッジノード３０間のインターネット経由Ｐ２Ｐ通信（ＷｅｂＲＴＣ等）や、エッジノード３０間を直接結んだリングネットワーク上でのトークン型通信も考えられる。
【００９７】
動作ステップは以下のようになる。以下の説明では、あるエッジノード３０についての動作を説明する。各エッジノード３０の動作はそれぞれ非同期に行われ、それらの動作は当該エッジノード３０の動作と同一のため、詳細を割愛する。
【００９８】
１．  エッジノード３０は、あらかじめクラウド１上のＭＱＴＴブローカサーバ５０に自身を登録しておく。また、本アルゴリズムの動作に必要な情報を取得するための購読（例：トピック名”ＥＮ＿ＬＯＣＡＬ＿ｏｎｅｗａｙ＿ｄｅｌａｙ＿ｓｈａｒｅ”）をしておく。
【００９９】
２．  エッジノード３０は、前記構成技術（１）で説明された通信経路管理テーブル３７を参照し、自エッジノード３０配下に存在する被制御機器２０のリストを作成する。引き続いて、前記構成技術（１）で説明された機器識別子管理テーブル３６を参照し、これら被制御機器のＩＰアドレスを取得する。以下ステップ３〜５を、この機器の数だけ繰り返す。
【０１００】
３．  エッジノード３０は、被制御機器２０に対してＩＣＭＰ  Ｅｃｈｏ  Ｒｅｑｕｅｓｔを送出する。
【０１０１】
４．  被制御機器２０は、エッジノード３０に対してＩＣＭＰ  Ｅｃｈｏ  Ｒｅｐｌｙを送出し、エッジノード３０がこれを受信する。
【０１０２】
５．  エッジノード３０は、ＩＣＭＰ  ｅｃｈｏ  Ｒｅｑｕｅｓｔの送出タイミングとＩＣＭＰ  Ｅｃｈｏ  Ｒｅｐｌｙの受信タイミングの差を２で割った値を、エッジノード３０・当該被制御機器２０間の片道遅延として自身のメモリの機器側遅延管理テーブル３９に記録する。
【０１０３】
６．  上記ステップの完了後、即座にエッジノード３０はクラウド１上に具備されたＭＱＴＴブローカサーバ５０に上記片道遅延値をＰｕｂｌｉｓｈする。これは、ＱｏＳ０にて実施される。
【０１０４】
７．  上記ステップの完了後、エッジノード３０は１秒間待機したのち、上記ステップ２へ戻る。なお、この待機時間中に、エッジノード３０が購読中のメッセージ、すなわち他エッジノード３０からの、当該エッジノード３０・当該エッジノード３０配下の各被制御機器２０間の片道遅延に関する情報アップデートをＭＱＴＴブローカサーバ５０から受信した場合は、自身のメモリ上の機器側遅延管理テーブル３９の当該エッジノード３０の項にアップデートする。
【０１０５】
［（７）コントローラからの指示到着時のバッファリング方法］
クラウド１上のコントローラ１０が、各被制御機器２０に対して制御指示に係るパケットを送出する際、制御対象である被制御機器２０のグループを示すグループＩＤをパケット中に埋め込む。具体的には、非特許文献１に示したＥｔｈｅｒｎｅｔ／ＩＰ使用時においては、アプリケーション層であるＣＩＰ内データとして埋め込む。
【０１０６】
エッジノード３０におけるバッファリングのフローチャートを図１９に示す。図１９に示すように、エッジノード３０が当該指示を受信し、被制御機器２０に転送する際に、当該グループＩＤをキーに、各テーブル３５，３６，３７を参照して、同一グループＩＤのパケットがどのエッジノード３０を通過するかを取得する（ステップＳ５１）。
【０１０７】
エッジノード３０は同一グループＩＤのパケットが通過する他のエッジノード３０のそれぞれについて、自メモリのコントローラ側遅延管理テーブル３８に登録済みの各エッジノード３０・コントローラ１０間の片道遅延値を取得する（ステップＳ５２）。さらにそれに加え、当該グループＩＤに所属する全ての被制御機器２０について、自メモリの機器側遅延管理テーブル３９に登録済みの各エッジノード３０・被制御機器２０間の片道遅延値を取得する（ステップＳ５３）。さらに引き続き、当該グループＩＤに所属する全ての被制御機器２０について、コントローラ１０・エッジノード３０・被制御機器２０間の各片道遅延の合算を計算する（ステップＳ５４）。
【０１０８】
エッジノード３０は、この合算値のリストを参照し、（最も大きなコントローラ１０・エッジノード３０・被制御機器２０間の片道遅延合算値）−（受信した当該指示パケットの宛先に対応するコントローラ１０・エッジノード３０・被制御機器２０間の片道遅延合算値）の差分だけウェイトした後、被制御機器２０へのパケット転送を実施する（ステップＳ５５）。
【０１０９】
以下にパケット到着時のバッファリングについて具体例について説明する。ここでの説明では、構成技術（１）の説明において示したテーブル例の状態に基づき説明する。なお、各エッジノード３０のテーブル上には、クラウド１上のコントローラ１０・エッジノード３０−１間が片道遅延８０ｍｓ，クラウド１上のコントローラ１０・エッジノード３０−２間が片道遅延２０ｍｓという情報が登録されている状況を前提とする。また、実際の遅延状態については、クラウド１上のコントローラ１０・エッジノード３０−１間が片道遅延７９ｍｓ，クラウド１上のコントローラ１０・エッジノード３０−２間が片道遅延２１ｍｓという状況を想定する。
【０１１０】
また、ここでの説明では、各エッジノード３０の機器側遅延管理テーブル３９上には、エッジノード３０−１・被制御機器２０−１間およびエッジノード３０−１・被制御機器２０−２間が１ｍｓ，エッジノード３０−２・被制御機器２０−３間が５ｍｓという情報が登録されている状況を前提とする。また、実際の遅延状態については、エッジノード３０−１・被制御機器２０−１間が１ｍｓ，エッジノード３０−１・被制御機器２０−２間が２ｍｓ，エッジノード３０−２・被制御機器２０−３間が５ｍｓであるという状況を想定する。
【０１１１】
詳細な動作ステップは以下のようになる。以下は、各パケットの転送を担うエッジノード３０−１，３０−２の両方を含めた説明をする。
【０１１２】
１．  クラウド１上のコントローラ１０が、被制御機器２０−１，２０−２，２０−３を同時に動作させることを目的に、これら被制御機器２０−１，２０−２，２０−３に対して制御パケットを送出する。この際、制御パケットには、「グループＩＤ１」という情報が埋め込まれている。なお、これらの３つのパケットを、以下ではパケット１，パケット２，パケット３と呼称する。
【０１１３】
２．  上記ステップ１の２１ｍｓ後、エッジノード３０−２にパケット３が到着する。
【０１１４】
３．  上記ステップ２に引き続きエッジノード３０−２は、パケット３の中身を参照し、グループＩＤが１であることを認識する。エッジノード３０−２はグループ管理テーブル３５を参照し、グループＩＤ１に属する被制御機器２０が被制御機器２０−１，２０−２，２０−３であることを認識する。エッジノード３０−２は、パケット３の宛先のＩＰアドレスをキーに各テーブルを参照し、宛先が被制御機器２０−３であることを認識した上で、残りの被制御機器２０−１，２０−２に対応するエッジノード３０がどちらもエッジノード３０−１であることを認識する。エッジノード３０−１の片道遅延値が８０ｍｓ，エッジノード３０−２の片道遅延値が２０ｍｓであることを確認する。さらに、エッジノード３０−２は、自身の機器側遅延管理テーブル３９を参照し、被制御機器２０−１，２０−２，２０−３に対応するそれぞれのエッジノード３０・被制御機器２０間の片道遅延値が、１ｍｓ，１ｍｓ，５ｍｓであることを確認する。このことから、パケット３に対応する片道遅延合算値が２５ｍｓであること、被制御機器２０−１，２０−２に対応する片道遅延合算値がどちらも８１ｍｓであることから、エッジノード３０−２は５６ｍｓウェイトをかけることを決定する。
【０１１５】
４．  上記ステップ１から数えて７９ｍｓ後、エッジノード３０−１にパケット１，２が到着する。パケット１，２はそれぞれ独立したパケットであるため、厳密には到着が前後する可能性があり、その場合は以下の手順はそのズレをそのまま引きずって動作することになる（動作はパケット１，２に対して独立して行われる）。ここでは、２つのパケットはほぼ同時に、パケット１，２の順番で到着したと想定して動作を説明する。
【０１１６】
５．  上記ステップ４に引き続き、エッジノード３０−１は、パケット１の中身を参照し、グループＩＤが１であることを認識する。エッジノード３０−１はグループ管理テーブル３５を参照し、グループＩＤ１に属する被制御機器２０が被制御機器２０−１，２０−２，２０−３であることを認識する。エッジノード３０−１は、パケット１の宛先が被制御機器３０−１であることを認識した上で、残りの被制御機器２０−２，２０−３に対応するエッジノードがそれぞれエッジノード３０−１，３０−２２であることを認識する。エッジノード３０−１の片道遅延値が８０ｍｓ、エッジノード３０−２の片道遅延値が２０ｍｓであることを確認する。さらに、エッジノード３０−１は、自身の機器側遅延管理テーブル３９を参照し、被制御機器２０−１，２０−２，２０−３に対応するそれぞれのエッジノード３０・被制御機器２０間の片道遅延値が、１ｍｓ，１ｍｓ，５ｍｓであることを確認する。このことから、パケット１に対応する片道遅延合算値が８１ｍｓであること、被制御機器２０−１，２０−２に対応する片道遅延合算値がそれぞれ８１ｍｓ，２５ｍｓであることから、エッジノード３０−１はウェイトをかけないことを決定する。エッジノード３０−１は即座にパケット１の転送を実施する。
【０１１７】
６．  引き続き、エッジノード３０−１はパケット２の中身を参照し、グループＩＤが１であることを認識する。エッジノード３０−１はグループ管理テーブル３５を参照し、グループＩＤ１に属する被制御機器２０が被制御機器２０−１，２０−２，２０−３であることを認識する。エッジノード３０−１は、パケット２の宛先が被制御機器２０−２であることを認識した上で、残りの被制御機器２０−１，２０−３に対応するエッジノード３０がそれぞれエッジノード３０−１，３０−２であることを認識する。エッジノード３０−１の片道遅延値が８０ｍｓ、エッジノード３０−２の片道遅延値が２０ｍｓであることを確認する。さらに、エッジノード３０−１は、自身の機器側遅延管理テーブル３９を参照し、被制御機器２０−１，２０−２，２０−３に対応するそれぞれのエッジノード３０・被制御機器２０間の片道遅延値が、１ｍｓ，１ｍｓ，５ｍｓであることを確認する。このことから、パケット２に対応する片道遅延合算値が８１ｍｓであること、被制御機器２０−１，２０−２に対応する片道遅延合算値がそれぞれ８１ｍｓ，２５ｍｓであることから、エッジノード３０−１はウェイトをかけないことを決定する。エッジノード３０−１は即座にパケット２の転送を実施する。
【０１１８】
７．  上記ステップ１から数えて７７ｍｓ後、エッジノード３０−２はパケット３を被制御機器２０−３に転送する。
【０１１９】
８．  上記ステップ１から数えて８０ｍｓ後、パケット１が被制御機器２０−１に到着する。
【０１２０】
９．  上記ステップ１から数えて８１ｍｓ後、パケット２が被制御機器２０−２に到着する。
【０１２１】
１０．  上記ステップ１から数えて８２ｍｓ後、パケット３が被制御機器２０−３に到着する。
【０１２２】
＜第３の実施の形態（方式１のバリエーション２）＞
次に、本発明の第３の実施の形態に係る遠隔制御システムの詳細について説明する。本実施の形態（方式１のバリエーション２）が第１の実施の形態（方式１）と異なる点は、片道遅延値の測定を、定期的に実施することに代えて、あるいは加えて、制御パケット到着時に実施する点にある。他の点については第１の実施の形態と同様なのでここでは相違点のみを説明する。
【０１２３】
本方式は、今回到着した制御パケットのバッファリング制御に当たっては既に登録済みの片道遅延値を用いて行い、次回以降の通信のために片道遅延値の更新を行うものである。
【０１２４】
本バリエーション２では、まず、制御パケットがエッジノード３０に到着する以前の準備段階として、ＭＱＴＴブローカサーバ５０に対して特定トピック名（例えば、ＳＴＡＲＴ＿ｄｅｌａｙ＿ｍｅａｓｕｒｅ）にて購読登録をあらかじめ実施しておく。そして、制御パケットがあるエッジノード３０に到着した際に、各エッジノード３０は以下のプロセスを実施する。
【０１２５】
・ある制御パケットが到着した際には、方式１あるいは方式１バリエーション１の方法に従い、パケットの転送を実施する。
・引き続き、当該エッジノード３０は、上記トピック名で制御パケットの到着を表すメッセージをＰｕｂｌｉｓｈする。また、当該エッジノード３０は片道遅延の測定および、共有を実施する。
・上記メッセージを受信した各エッジノード３０は、片道遅延の測定および、共有を実施する。
【０１２６】
なお、上記方式においては、同一グループに向けて発信された制御パケットの数だけ、重複して各エッジノード３０が片道遅延の測定および共有を実施することになる。これによるリソースの無駄な消費を回避するために、加えてエッジノード３０は以下の動作をしても良い。
【０１２７】
・エッジノード３０は、過去一定時間内（例：１００ｍｓ）に片道遅延の測定および共有を行っている場合は、新たに片道遅延の測定および共有は行わない。
【０１２８】
本バリエーション２は、図２０に示すように、定常的時間測定の間隔に比して短い間隔で制御パケットが到来する場合、古い測定結果を上書き更新することで、２回目以降の制御指示パケットに対してより高い精度で処理することが出来る。
【０１２９】
＜第４の実施の形態（方式２）＞
次に、本発明の第４の実施の形態に係る遠隔制御システムの詳細について図２１を参照して説明する。図２１は本発明の第４の実施の形態に係る遠隔制御システムの構成図である。なお、上述した本発明の概要と同一の構成については同一の符号を付した。
【０１３０】
方式２は、主に以下の技術からなる。（１）各エッジノード３０における、論理的被制御機器グルーピングと物理構成の管理方法、（２）上記管理情報の作成方法、および構成変更時のアップデート方法、（３）各エッジノード３０における、エッジノード３０間時刻同期方法（既存技術の適用）、（４）コントローラ１０からの制御信号に係るパケット到着時のエッジノード３０間での協調による同期制御方法。
【０１３１】
前述したように、方式２は、コントローラ１０からの制御パケット到着時に行う同期制御のため、リアルタイム性は低下するが、クラウド１・エッジ３間の遅延の揺らぎ（ジッタ）の影響を受けないため、クラウド１・エッジ３間のジッタが大きい場合に有効である。
【０１３２】
本実施の形態に係る遠隔制御システムは、図２１に示すように、クラウド１に配置されたコントローラ１０と、ローカル２に配置された複数（図２１では３つ）の被制御機器２０と、被制御機器２０をコントローラ１０とを接続するためのネットワークである複数（図２１では２つ）のエッジ３にそれぞれ配置されたエッジノード３０と、クラウド１に配置され被制御機器２０間のパケット送出時刻を調停する調停装置としてのアプリケーションサーバ４０とを備えている。なお、図２１では、アプリケーションサーバ４０はクラウド１に配備しているが、各エッジノード３０と通信可能であるなら配備位置は不問である。
【０１３３】
アプリケーションサーバ４０は、以下の機能を有する。（ａ）コントローラ１０からの制御指示に係るパケットを受信したエッジノード３０から、その受信した事実、及び当該制御指示に含まれるグループＩＤ、および、当該グループＩＤに含まれる被制御機器２０が接続されているエッジノード３０（エッジノード３０配下の被制御機器２０の個数を含む）情報を受信する機能、（ｂ）上記情報に基づき、当該グループＩＤに含まれる被制御機器２０の個数だけエッジノード３０からの通知を待機する機能、（ｃ）上記、個数分のエッジノード３０からの通知の到着後、一定時間後の時刻を指定し、各エッジノード３０についてパケットの転送実施時刻を指定する機能、（ｄ）ＮＴＰプロトコルにより時刻同期を行う機能。
【０１３４】
上記機能を実現するために、アプリケーションサーバ４０は、図２２に示すように、前記（ａ）の機能を有する情報取得部４１と、前記（ｂ）及び（ｃ）の機能の一部を有する送出時刻算出部４２と、前記（ｃ）の機能の一部を有する送出時刻通知部４３と、前記（ｄ）の機能を有する時刻同期制御部４４とを備える。
【０１３５】
また、エッジノード３０は、コントローラ１０と被制御機器２０の間に介在し、以下の機能を持つ。（ａ）コントローラ１０と被制御機器２０の間でパケットを転送する機能、特に、コントローラ１０から受信したパケットをアプリケーションサーバ４０からの指示に基づき特定時刻にパケット転送を実施する機能、（ｃ）コントローラ１０からの制御指示に係るパケットを受信した際に、その受信した事実、及び当該制御指示に含まれるグループＩＤ、および当該グループＩＤに含まれる被制御機器２０が接続されているエッジノード３０（エッジノード３０配下の被制御機器２０の個数を含む）情報をアプリケーションサーバ４０に送信する機能、（ｄ）ＮＴＰプロトコルにより時刻同期を行う機能を持つ。
【０１３６】
上記機能を実現するため、エッジノード３０は、図２３に示すように、転送処理部３１と、タイミング制御部３３とを備える。転送処理部３１は前記（ａ）の機能を有するものであり、バッファ３２を含む。タイミング制御部３３は前記（ｂ）〜（ｄ）の機能を有するものであり、グループ管理テーブル３５と、機器識別子管理テーブル３６と、通信経路管理テーブル３７と、時刻同期制御部６０とを含む。
【０１３７】
以下、前述した（１）〜（４）の構成技術についてそれぞれ説明することにより、本実施の形態に係る遠隔制御システムについて説明する。構成技術（１）〜（２）については、第１の実施の形態における構成技術（１）〜（２）と同一なので、ここでは説明を省略する。
【０１３８】
［（３）各エッジノード３０における、エッジノード３０間時刻同期方法］
本構成技術３においては、周知のＮＴＰを活用した時刻同期方法により、各エッジノード３０およびアプリケーションサーバ４０は、所定のＮＴＰサーバ（図示省略）から正確な時刻情報を取得する。
【０１３９】
具体的な動作のシーケンスは以下の通りである。以下の説明は、アプリケーションサーバ４０及びあるエッジノード３０について記載している。他のエッジノード３０についても、独立して同様の動作を行う。
【０１４０】
エッジノード３０およびアプリケーションサーバ４０は、定期的（例えば１分に１回）又は任意時に、既存のＮＴＰクライアントを用いて、クラウド１上のＮＴＰサーバ（図示省略）と時刻同期を行う。なお、ＮＴＰサーバの配備位置はクラウド１に配備しているが、各エッジノード３０及びアプリケーションサーバ４０と通信可能であるなら配備位置は不問である。
【０１４１】
［（４）コントローラ１０からの制御信号に係るパケット到着時のエッジノード３０間での協調による同期制御方法］
クラウド１上のコントローラ１０が、各被制御機器２０に対して制御指示に係るパケットを送出する際、制御対象である被制御機器２０のグループを示すグループＩＤをパケット中に埋め込む。具体的には、非特許文献１に示したＥｔｈｅｒｎｅｔ／ＩＰ使用時においては、アプリケーション層であるＣＩＰ内データとして埋め込む。
【０１４２】
エッジノード３０及びアプリケーションサーバ４０における同期制御のフローチャートを図２３に示す。図２４に示すように、エッジノード３０が当該指示に係るパケットを受信し、被制御機器２０に転送する際に、当該グループＩＤをキーに、各テーブル３５，３６，３７を参照して、同一グループＩＤのパケットがどのエッジノード３０を通過するかを取得する（ステップＳ６１）。
【０１４３】
エッジノード３０は、指示に係るパケットを受信したという事実を示す情報と、上記エッジノード３０のリストをアプリケーションサーバ４０に通知する（ステップＳ６２）。他のエッジノード３０も同様に動作する。
【０１４４】
アプリケーションサーバ４０は、該当する全てのエッジノード３０からの通知を受けた時点で、特定の時刻を各エッジノード３０に返答する（ステップＳ６３）。
【０１４５】
各エッジノード３０は、アプリケーションサーバ４０から連絡を受けた特定時刻に、被制御機器へのパケット転送を実施する（ステップＳ６４）。
【０１４６】
以下にパケット到着時の同期制御方法の具体例について説明する。ここでの説明では、構成技術（１）の説明において示したテーブル例の状態に基づき説明する。また、実際の遅延状態については、クラウド１上コントローラ１０・エッジノード３０−１間が片道遅延７９ｍｓ，クラウド１上のコントローラ１０・エッジノード３０−２間が片道遅延２１ｍｓという状況を想定する。また、アプリケーションサーバ４０・エッジノード３０−１間およびエッジノード３０−２間の片道遅延はそれぞれ１００ｍｓ，３０ｍｓという状況を想定する。
【０１４７】
詳細な動作ステップは以下のようになる。以下では、エッジノード３０−１，３０−２の両方を含めた説明をする。
【０１４８】
１．  クラウド１上のコントローラ１０が、被制御機器２０−１，２０−２，２０−３を同時に動作させることを目的に、これら被制御機器２０−１，２０−２，２０−３に対して制御パケットを送出する。この際、制御パケットには、「グループＩＤ１」という情報が埋め込まれている。なお、これら３つのパケットを、以下ではパケット１，パケット２，パケット３と呼称する。また、このクラウド１上のコントローラ１０がパケットを送出した時刻をＴとし、以下の説明を進める。
【０１４９】
２．  時刻Ｔ＋２１ｍｓに、エッジノード３０−２にパケット３が到着する。
【０１５０】
３．  上記ステップ２に引き続きエッジノード３０−２は、パケット３の中身を参照し、グループＩＤが１であることを認識する。エッジノード３０−２はグループ管理テーブル３５を参照し、グループＩＤ１に属する被制御機器２０が被制御機器２０−１，２０−２，２０−３であることを認識する。エッジノード３０−２は、パケット３の宛先のＩＰアドレスをキーに各テーブルを参照し、宛先が被制御機器２０−３であることを認識した上で、残りの被制御機器２０−１，２０−２に対応するエッジノード３０がどちらもエッジノード３０−１であることを認識する。エッジノード３０−２は、グループＩＤ１に対応する制御指示を受信したこと、また、グループＩＤ１に属するエッジノード３０がエッジノード３０−２（被制御機器数１）およびエッジノード３０−１（被制御機器数２）であることをアプリケーションサーバ４０に通知する。
【０１５１】
４．  時刻Ｔ＋５１ｍｓに、アプリケーションサーバ４０は上記通知を受信する。この通知内容より、アプリケーションサーバ４０はグループＩＤ１に属するエッジノード３０がエッジノード３０−２（被制御機器数１）およびエッジノード３０−１（被制御機器数２）であることを認識し、エッジノード３０−１からのメッセージ到着の待機を開始する。
【０１５２】
５．  時刻Ｔ＋７９ｍｓに、エッジノード３０−１にパケット１，２が到着する。パケット１，２はそれぞれ独立したパケットであるため、厳密には到着が前後する可能性があり、その場合は以下の手順はそのズレをそのまま引きずって動作することになる（動作はパケット１，２に対して独立して行われる）。ここでは、二つのパケットはほぼ同時に、パケット１，２の順番で到着したと想定して動作を説明する。
【０１５３】
６．  上記ステップ５に引き続き、エッジノード３０−１は、パケット１の中身を参照し、グループＩＤが１であることを認識する。エッジノード３０−１はグループ管理テーブル３５を参照し、グループＩＤ１に属する被制御機器２０が制御機器２０−１，２０−２，２０−３であることを認識する。エッジノード３０−１は、パケット１の宛先のＩＰアドレスをキーに各テーブルを参照し、宛先が被制御機器２０−１であることを認識した上で、残りの被制御機器２０−２，２０−３に対応するエッジノードがそれぞれエッジノード３０−１，３０−２であることを認識する。エッジノード３０−１は、グループＩＤ１に対応する制御指示を受信したこと、またグループＩＤに属するエッジノード３０がエッジノード３０−１（被制御機器数２）およびエッジノード３０−２（被制御機器数１）であることを、アプリケーションサーバ４０に通知する。
【０１５４】
７．  上記ステップ６に引き続き、エッジノード３０−１は、パケット２に対して上記ステップ６と同様の動作を実行する。
【０１５５】
８．  時刻Ｔ＋１７９ｍｓに、上記ステップ６においてエッジノード３０−１から発せられたアプリケーションサーバ４０に対する通知が、アプリケーションサーバ４０に到着する。当該通知を受信したアプリケーションサーバ４０は、グループＩＤに属するエッジノード３０のうち、エッジノード３０−１から送信される通知が１件未着であることを認識し、待機を継続する。
【０１５６】
９．  時刻Ｔ＋１７９ｍｓに、上記ステップ８の直後に、上記ステップ７にてエッジノード３０−１から発せられたアプリケーションサーバ４０に対する通知が、引き続きアプリケーションサーバ４０に到着する。当該通知を受信したアプリケーションサーバ４０は、グループＩＤに属するエッジノード３０のうち、エッジノード３０−２から１件の通知、エッジノード３０−１から２件の通知が到着したこと、すなわち全ての通知が到着完了したことを認識する。
【０１５７】
１０．  上記ステップ９に引き続き、アプリケーションサーバ４０は、あらかじめ設定された待機時間（例えば、ここでは１秒とする）後である時刻Ｔ＋１１７９ｍｓにエッジノード３０から被制御機器２０へのパケット転送を実施するよう、エッジノード３０−１およびエッジノード３０−２に通知を行う。
【０１５８】
１１．  時刻Ｔ＋２０９ｍｓに、エッジノード３０−２に上記通知が到着する。エッジノード３０−２は、指定時刻まで待機を開始する。
【０１５９】
１２．  時刻Ｔ＋２７９ｍｓに、エッジノード３０−１に上記通知が到着する。エッジノード３０−１は、指定時刻まで待機を開始する。
【０１６０】
１３．  時刻Ｔ＋１１７９ｍｓに、エッジノード３０−１およびエッジノード３０−２は、それぞれ被制御機器２０−１，２０−２、および被制御機器２０−３へのパケット転送を実施する。
【０１６１】
１４．  時刻Ｔ＋１１８０ｍｓに、被制御機器２０−１，２０−２，２０−３にパケットが到着する。
【０１６２】
以上本発明の概要及び実施の形態について詳述したが、本発明はこれに限定されるものではない。例えば、本発明では、パケット転送処理部とタイミング制御部を備えたパケット転送装置をエッジノードとして通信事業者網に配置したが、上述したように、その配備位置は不問である。
【０１６３】
また、上記実施の形態においての各テーブルのデータ構造やエッジノード間での情報共有のためのプロトコルなどは一例にすぎず、他のデータ構造やプロトコルであっても本発明を適用できる。
【符号の説明】
【０１６４】
１…クラウド
２…ローカル
３…エッジ
１０…コントローラ
２０…被制御機器
３０…エッジノード
３１…転送処理部
３２…バッファ
３３…タイミング制御部
３４…遅延計測部
３５…グループ管理テーブル
３６…機器識別子管理テーブル
３７…通信経路管理テーブル
３８…コントローラ側遅延管理テーブル
３９…機器側遅延管理テーブル
４０…アプリケーションサーバ
４１…情報取得部
４２…送出時刻算出部
４３…送出時刻通知部
４４…時刻同期制御部
５０…ＭＱＴＴブローカサーバ
６０…時刻同期制御部
【図１】
2020036072.tif 000003
【図２】
2020036072.tif 000004
【図３】
2020036072.tif 000005
【図４】
2020036072.tif 000006
【図５】
2020036072.tif 000007
【図６】
2020036072.tif 000008
【図７】
2020036072.tif 000009
【図８】
2020036072.tif 000010
【図９】
2020036072.tif 000011
【図１０】
2020036072.tif 000012
【図１１】
2020036072.tif 000013
【図１２】
2020036072.tif 000014
【図１３】
2020036072.tif 000015
【図１４】
2020036072.tif 000016
【図１５】
2020036072.tif 000017
【図１６】
2020036072.tif 000018
【図１７】
2020036072.tif 000019
【図１８】
2020036072.tif 000020
【図１９】
2020036072.tif 000021
【図２０】
2020036072.tif 000022
【図２１】
2020036072.tif 000023
【図２２】
2020036072.tif 000024
【図２３】
2020036072.tif 000025
【図２４】
2020036072.tif 000026