JP2022504483A - 無線ネットワークを介したコントローラと被制御デバイスとの間の通信 - Google Patents

Abstract

ソースインターフェースデバイスにおいて実行される、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法。本方法は、着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第１の経路と、ＩＰ（インターネットプロトコル）トラフィックを搬送する第２の経路とにスプリットすること（１０２）と、ＩＰトラフィックのパケットのＩＰアドレスを、３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイスのＩＰアドレスに対して再マッピングすること（１０６）と、ネイティブイーサネットトラフィックを、３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイスのＩＰアドレスをもつＩＰトラフィック中にカプセル化すること（１０４）と、３ＧＰＰ無線ネットワークを介した宛先インターフェースデバイスへの送信（１１０）のために前記第１の経路と前記第２の経路とからのＩＰトラフィックをスケジュールすること（１０８）とを含む。
【選択図】図１

Description

本発明は、一般に、被制御デバイスとリモートコントローラとの間の通信に関し、特に、３ＧＰＰ無線ネットワークを介したそのような通信のための方法およびインターフェースデバイスに関する。

将来の工場は製造プロセスおよびプラントのデジタル化によって実現されるであろう。デジタル変換は、製造プロセスのフレキシビリティを高めるために、工場において前には分離されていたデバイスとシステムとを接続することによって始まる。製造業者は、持続可能性、フレキシビリティ、トレーサビリティ、または安全性を犠牲にすることなしに、生産高を最大にするために、彼らの製造を個別化することを希望する。互いとおよび人間と通信することが可能な新しいクラウド駆動型ロボティックデバイスが必要とされるであろう。

一般的な産業環境において、生産ラインは、それぞれ製品の特定の部品を製造することに専用の、様々な作業セルから構成される。生産ラインは、タスクを調整し、各作業セルに割り当てるプログラマブル論理コントローラ（ＰＬＣ）によって制御される。作業セルまたは製造ステーションは、ロボティックデバイスと、コンベヤと、部品ポジショナーおよび安全環境などの他の周辺機器とを含む、完全なシステムである。作業セル全体はステーションＰＬＣによって制御される。各ロボティックデバイスは、ステーションＰＬＣによって管理されるそれ自体のロボットコントローラを有する。

ＰＬＣは、機械とプロセスとを制御するために使用される専用コンピュータである。ＰＬＣは、したがって、中央処理ユニット、メモリ、ソフトウェアおよび通信のような、一般的なＰＣと共通の用語を共有する。パーソナルコンピュータとは異なり、しかしながら、ＰＬＣは、厳しい産業環境において存続し、ＰＬＣが実世界への入力および出力とどのようにインターフェースするかにおいて極めてフレキシブルであるように設計される。ＰＬＣは、（たとえば、スイッチ、センサーおよびロボティックデバイスからの）入力信号を出力（たとえば、運動指令（ｍｏｔｏｒ ｃｏｍｍａｎｄ）、ロボットコマンド、ＬＥＤ、リレーなど）に処理するシステムを連続的に監視し、逐次プロセス中のすべてのステップが適切なシーケンスにおいて実行されることを保証するために被制御プロセスに関して必要な行動を取る。

ステーションＰＬＣは、リモートＩ／Ｏ（入力／出力）、他のＰＬＣ（たとえば、生産ラインのためのＰＬＣ）およびロボットコントローラなどのように、異なるデバイスと通信する。すべてのこれらの通信は、配線および接続構成要素である物理接続と、ネットワーク化されたデバイス間の通信を可能にする共通語である共有プロトコルとを必要とする。通信プロトコル、たとえばフィールドバスは、デバイス間の通信において使用されるべきルールのセットを記述する。今日の産業ロボット工学において使用されるプロトコルのリストはかなり大きく、使用されるプロトコルの多くは、イーサネットおよび／またはＩＰネットワーキング、またはプロプライエタリネットワーキングプロトコルをもつシリアルケーブルのいずれかに基づく。パフォーマンスはしばしば物理レイヤ（最下位レイヤ）によって決定されるが、産業ロボット工学において使用される通信プロトコルはたいていアプリケーションレイヤ（上位レイヤ）の特徴と異なる。工業において使用される主要なイーサネットベースプロトコルはイーサネット／ＩＰ、Ｍｏｄｂｕｓ ＴＣＰ／ＩＰ、Ｐｒｏｆｉｎｅｔ、ＥｔｈｅｒＣＡＴである。

工業プロトコルは、それらの機能を実行するために異なるタイプの通信を処理する。たとえば、ＰＲＯＦＩＮＥＴ ＩＯは、プログラマブルコントローラおよび他のデバイスとデータを交換するために異なる通信チャネルを使用する。
－ リアルタイム（ＲＴ）通信－Ｉ／ＯおよびアラームデータはリアルタイムＰＲＯＦＩＮＥＴ ＩＯチャネルを介して伝達される。ＲＴデータは以下であり得る。
－ ＲＴ非周期データ－スケジュールされていないオンデマンド通信。ＩＯスーパーバイザからＩ／Ｏデバイスへの診断メッセージは非周期である。
－ ＲＴ周期データ－スケジュールされた反復通信。Ｉ／Ｏデータ伝達およびアラーム伝達は周期的である。
－ 非リアルタイム通信－設定メッセージおよび診断メッセージは非リアルタイムＰＲＯＦＩＮＥＴ ＩＯチャネルを介して伝達される。

特に製造およびプロセス自動化における工業用通信は時間に正確で確定的なデータ送信を必要とする。この理由で、ＴＣＰ／ＩＰは、Ｐｒｏｆｉｎｅｔアプリケーションが必要とするほど速くも確定的でもないが、純粋なイーサネットトラフィックであるので、タイムクリティカルなＩ／Ｏユーザデータの周期的な交換のために、ＰＲＯＦＩＮＥＴ ＩＯはＴＣＰ／ＩＰを使用しない。ＴＣＰ／ＵＤＰは、主に始動設定のために使用され、まれであるが、予防的監視とともに、ＴＣＰ／ＵＤＰの使用は増加するであろう。

今日、生産ラインは、イーサネット接続を使用した固定有線ネットワークに基づいている。しかしながら、成熟したプラントは最高１０００個の可動部品＋はるかに多いデバイスとセンサーとを有するので、データトラフィックはもはや既存の有線内部ネットワークによってサポートされ得ず、したがって現在のプラントネットワークはボトルネックを生じ始めている。

レガシーネットワークを支援して第２の有線ネットワークを追加することは可能であるが、両方のネットワークを一体化することは容易ではない。同時に、たとえば光ファイバーを使用した、プラントの完全な再ケーブリングは非常に広範になり得る。

したがって、そのようなシナリオでは、無線接続性は最良のソリューションであると思われる。市場で、現在利用可能なソリューションは、ＰＬＣと、ロボットを動作させるためのロボティックデバイスとの間の通信をカバーしない。代わりに、それらは、様々な局所制御モジュールへのリモートアクセスのための上部レイヤＳＣＡＤＡ（監視制御およびデータ収集）に向けた監視および一般的な管理機能に焦点を合わせている。センサーは、ＬＴＥを介してリモートサーバにクライアントとして接続され得、場合によっては、ＰＬＣは、ＳＣＡＤＡに向かってＬＴＥを介して通信することができる。

この種類の接続性は、ＩＰクライアントが、いくつかの管理／監視機能が動作するリモートサーバと連絡を取る、典型的なＩｏＴ方式に従う。工業ＩｏＴ ＬＴＥベースの例は、たとえば、Ｓｉｅｍｅｎｓ、Ｓｉｅｒｒａ ＷｉｒｅｌｅｓｓおよびＭｏｘａによって提供されるものである。

ＳｉｅｍｅｎｓのＳＣＡＬＡＮＣＥ Ｍ８７６－４ ＬＴＥ（ＵＥ）は、ＬＴＥを介したイーサネットに基づく無線ＩＰ通信のための４Ｇルータである。Ｓｉｅｍｅｎｓは、ＳＣＡＬＡＮＣＥ Ｍ８７６－４ ＬＴＥ（ＵＥ）がＰｒｏｆｉｎｅｔプロトコルをサポートすると述べているが、それは、このサポートを、監視と管理とのみのために使用されるプロトコルのＩＰトラフィックのみに限定する。ロボティックデバイスを制御するために使用されるリアルタイムネイティブイーサネットＰｒｏｆｉｎｅｔトラフィックはサポートされない。

同様に、Ｓｉｅｒｒａ Ｗｉｒｅｌｅｓｓのような他の製造業者によって提供されるデバイス（たとえば、ＡｉｒＬｉｎｋ ＲＶ５０産業用ＬＴＥゲートウェイ）も、ＬＴＥと、たとえば、ＳＣＡＤＡが動作するリモートアプリケーションサーバとに対するローカルルータによって処理されるＩＰ接続性のみを可能にする。したがって、それらは、監視および管理／設定目的のためにＰＬＣと上位レイヤとの間の接続を可能にするが、それらは、作業セルにおけるロボティックデバイスの、それのＰＬＣによるランタイム制御のためには好適ではない。

使用され得る別のデバイスは、Ｍｏｘａによって提供されるもの（たとえばＯｎＣｅｌｌ Ｇ３４７０Ａ－ＬＴＥシリーズ－産業用ＬＴＥセルラーゲートウェイ）のような、ＬＴＥゲートウェイである。クライアントとサーバとの間のＶＰＮ接続性を使用すると、両方の側で同じＬＡＮを接続することが可能である。このソリューションでは、ソリューションが、センサーおよびＰＬＣのようないくつかのデバイスをリモート管理および監視システムに接続するために使用されることになっているので、ＶＰＮが使用される。インターネットを通る際、ＩＰｓｅｃをもつＶＰＮは良好なレベルの暗号化を行う。この場合も、ＰＬＣを直接ロボティックデバイスに接続することはサポートされない。

上記で説明したように、数百個のロボットとセンサーとそれらのコントローラとへの接続性を与える追加の（電気または光）ケーブリングは現実的でなく、非常に費用がかかる。したがって、コストを低減し、インフラストラクチャを簡略化するために、無線接続性が展開される予定である。

同時に、現在のＷｉ－Ｆｉは、いくつかのモチベーションにとって、工場環境において実行可能でない。
－ 現在のＷｉ－Ｆｉは、帯域幅について競合する複数のアクセスポイントの存在により、同一チャネル干渉に対してロバストでない、共有スペクトル上の「ベストエフォート」通信技術である。
－ パフォーマンスは接続されるデバイスの数とともに低下するので、（たとえば、新しいセンサーおよびデバイスを追加するための）工場において必要とされるスケーラビリティはＷｉ－Ｆｉによって保証され得ない。
－ 「信号強度マッピング」は、かなり不正確であり、生産現場の周りを移動する「オブジェクト」によって動的な影響を受け得るので、プラントの安定したＷｉ－Ｆｉカバレッジプランニングを行うことは容易でない。
－ ＷｉＦｉは、工場中の機械から来る干渉と、高いトラフィック負荷との影響を受け得る。

本発明の目的は、上記の欠点のうちの少なくともいくつかをなくし、３ＧＰＰ無線ネットワークを介した被制御デバイスとリモートコントローラとの間の通信のための改善された方法およびインターフェースデバイスを提供することである。

したがって、本発明は、好ましくは、上述の欠点のうちの１つまたは複数を、単独でまたは任意の組合せで、緩和すること、軽減すること、またはなくすことを求める。

本発明の第１の態様によれば、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法が提供される。ソースインターフェースデバイスにおいて実行される方法は、着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第１の経路と、ＩＰ（インターネットプロトコル）トラフィックを搬送する第２の経路とにスプリットすることを含む。本方法はまた、ＩＰトラフィックのパケットのＩＰアドレスを、３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイスのＩＰアドレスに対して再マッピングすることと、ネイティブイーサネットトラフィックを、３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイスのＩＰアドレスをもつＩＰトラフィック中にカプセル化することとを含む。本方法は、３ＧＰＰ無線ネットワークを介した宛先インターフェースデバイスへの送信のために前記第１の経路と前記第２の経路とからのＩＰトラフィックをスケジュールすることをさらに含む。

本発明の第２の態様によれば、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法が提供される。宛先インターフェースデバイスにおいて実行される方法は、着信トラフィックを、ＩＰ（インターネットプロトコル）パケット中にカプセル化されたネイティブイーサネットトラフィックを搬送する第３の経路と、ＩＰトラフィックを搬送する第４の経路とにスプリットすることを含む。本方法はまた、第４の経路上のＩＰトラフィックのパケットのＩＰアドレスを、少なくとも１つの被制御デバイスまたはコントローラのＩＰアドレスに対して再マッピングすることと、第３の経路上のＩＰトラフィックからのネイティブイーサネットトラフィックをカプセル化解除することとを含む。本方法は、宛先インターフェースデバイスに接続された少なくとも１つの被制御デバイスまたはコントローラへの送信のために前記第３の経路と前記第４の経路とからのトラフィックをスケジュールすることをさらに含む。

本発明の第３の態様によれば、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスが提供される。インターフェースデバイスは、着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第１の経路と、ＩＰ（インターネットプロトコル）トラフィックを搬送する第２の経路とにスプリットするように適合される。インターフェースデバイスはまた、ＩＰトラフィックのパケットのＩＰアドレスを、３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイスのＩＰアドレスに対して再マッピングし、ネイティブイーサネットトラフィックを、３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイスのＩＰアドレスをもつＩＰトラフィック中にカプセル化するように適合される。さらに、インターフェースデバイスは、３ＧＰＰ無線ネットワークを介した宛先インターフェースデバイスへの送信のために第１の経路と第２の経路とからのＩＰトラフィックをスケジュールするように適合される。

本発明の第４の態様によれば、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスが提供される。インターフェースデバイスは、着信トラフィックを、ＩＰ（インターネットプロトコル）パケット中にカプセル化されたネイティブイーサネットトラフィックを搬送する第３の経路と、ＩＰトラフィックを搬送する第４の経路とにスプリットするように適合される。インターフェースデバイスはまた、第４の経路上のＩＰトラフィックのパケットのＩＰアドレスを、少なくとも１つの被制御デバイスまたはコントローラのＩＰアドレスに対して再マッピングし、第３の経路上のＩＰトラフィックからのネイティブイーサネットトラフィックをカプセル化解除するように適合される。さらに、インターフェースデバイスは、インターフェースデバイスに接続された少なくとも１つの被制御デバイスまたはコントローラへの送信のために第３の経路と第４の経路とからのトラフィックをスケジュールするように適合される。

本発明の第５の態様によれば、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスが提供される。インターフェースデバイスは処理回路とメモリとを備え、メモリは、インターフェースデバイスが、着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第１の経路と、ＩＰ（インターネットプロトコル）トラフィックを搬送する第２の経路とにスプリットするように動作可能であるように、処理回路によって実行可能な命令を含んでいる。インターフェースデバイスはまた、ＩＰトラフィックのパケットのＩＰアドレスを、３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイスのＩＰアドレスに対して再マッピングし、ネイティブイーサネットトラフィックを、３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイスのＩＰアドレスをもつＩＰトラフィック中にカプセル化するように動作可能である。さらに、インターフェースデバイスは、３ＧＰＰ無線ネットワークを介した宛先インターフェースデバイスへの送信のために第１の経路と第２の経路とからのＩＰトラフィックをスケジュールするように動作可能である。

本発明の第６の態様によれば、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスが提供される。インターフェースデバイスは処理回路とメモリとを備え、メモリは、インターフェースデバイスが、着信トラフィックを、ＩＰ（インターネットプロトコル）パケット中にカプセル化されたネイティブイーサネットトラフィックを搬送する第３の経路と、ＩＰトラフィックを搬送する第４の経路とにスプリットするように動作可能であるように、処理回路によって実行可能な命令を含んでいる。インターフェースデバイスはまた、第４の経路上のＩＰトラフィックのパケットのＩＰアドレスを、少なくとも１つの被制御デバイスまたはコントローラのＩＰアドレスに対して再マッピングし、第３の経路上のＩＰトラフィックからのネイティブイーサネットトラフィックをカプセル化解除するように動作可能である。さらに、インターフェースデバイスは、インターフェースデバイスに接続された少なくとも１つの被制御デバイスまたはコントローラへの送信のために第３の経路と第４の経路とからのトラフィックをスケジュールするように動作可能である。

本発明のさらなる特徴は従属クレームに記載されている。

本発明は多数の利益を提供し、それらのうちのいくつかについて次に手短に述べる。方法およびデバイスは、それらの様々な実施形態において、工業プロトコルに対してアグノスティック（ａｇｎｏｓｔｉｃ）である。ソリューションは、工業プロトコルを用いた４Ｇ無線通信と５Ｇ無線通信との両立性を与える。ソリューションは、ケーブル接続の必要をなくすことによるインフラストラクチャコストの低減を可能にし、機能を仮想化することによる生産ラインのフレキシビリティを高める。ケーブリングの削除は、ローカルクラウド中のサーバ上のリモートな場所において動作するステーションＰＬＣ機能の伝達を促進し、ＰＬＣよりもはるかに強力な、そのような機械によって与えられる計算能力を活用する可能性を与える。したがって、よりフレキシブルな、洗練された制御機能がもたらされ得る。このソリューションはまた、ケーブリングを並べ替える必要がないので、組立ラインの並べ替えのために必要とされる停止時間を低減する。

本発明は、図面とともに行われる以下の詳細な説明からより十分に理解され、諒解されよう。

本発明の一実施形態における、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法を示すフローチャートである。 本発明の別の実施形態における、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法を示すフローチャートである。 本発明の一実施形態における、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスを示すダイヤグラムである。 本発明の一実施形態における、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスを示すダイヤグラムである。 動作中の３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスを示す図である。 動作中の３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスを示す図である。 本方法の一実施形態における、イーサネットトラフィックのカプセル化の動作を示す図である。 図３および図４に示されたインターフェースデバイスの接続および切断を示すメッセージシーケンスチャートである。

以下の説明では、本発明についての完全な理解を与えるために、限定ではなく説明の目的で、特定のアーキテクチャ、インターフェース、技法などの具体的な詳細が記載されている。しかしながら、本発明が、これらの具体的な詳細から逸脱する他の実施形態においても実施され得ることは、当業者には明らかであろう。他の事例では、本発明の説明を不要な詳細によって不明瞭にしないように、よく知られているデバイス、回路、および方法についての詳細な説明は省略されている。

明細書全体にわたる「一実施形態」または「実施形態」への言及は、実施形態に関して説明した特定の特徴、構造、または特性が本発明の少なくとも１つの実施形態中に含まれることを意味する。したがって、本明細書全体にわたる様々な場所における「一実施形態では」または「実施形態では」というフレーズの出現は、必ずしもすべて同じ実施形態を指しているとは限らない。さらに、特定の特徴、構造または特性は１つまたは複数の実施形態において何らかの好適な様式で組み合わせられ得る。

ＷｉＦｉ接続に関する問題の多くは、ＬＴＥ無線接続を使用することによって対処され得る。しかしながら、帯域幅およびレイテンシの視点からより厳しい要件がある場合、５Ｇ無線接続性は、それの標準化されたネットワーキング機能、ビルトインセキュリティ、サービスの保証されたグレードならびにネットワークスライシングコンセプトとともに、デジタル変換を活用することを希望する先進産業のための最良のソリューションである。

しかしながら、発明者らは、ＩＥＥＥ８０２．３イーサネットフレーム規格内でＩ／Ｏおよびロボット制御トラフィックのみを直接トランスポートするＰｒｏｆｉｎｅｔまたはＥｔｈｅｒＣＡＴプロトコルが使用されるとき、イーサネット上でトランスポートされる工業プロトコルとＬＴＥ／５ＧのＩＰベースネットワークアーキテクチャとの間の互換性問題が明らかになることに気が付いた。したがって、工業プロトコル（たとえば、Ｐｒｏｆｉｎｅｔ、Ｅｔｈｅｒｃａｔ）と工業用通信のための無線接続性を使用するＬＴＥ／５Ｇ通信との間の互換性問題を解くことが重要である。

産業用デバイスの圧倒的多数は、コマンドを起動するのではなくコマンドに応答するように設計されているので、これはＩＰ通信についての問題である。インターネット上のユーザまたはマスタデバイスは、動的ＩＰアドレスを割り当てられた産業用デバイスまたはセンサーとの接触を開始することができなくなる。このＩＰアドレス問題に対処するために、ＶＸＬＡＮ（仮想拡張ローカルエリアネットワーク）、ＶＰＮ（仮想プライベートネットワーク）または同様の技法を使用したＩＰトンネリングが使用され得る。

しかしながら、トンネリングはトラフィックのトランスポートを最適化しない。ネイティブイーサネット（たとえば、ｐｒｏｆｉｎｅｔ ＲＴおよびｅｔｈｅｒｃａｔ ＲＴトラフィック）とネイティブＩＰトラフィック（たとえば、設定、保守および監視）の両方がカプセル化されて、あらゆるものがトンネリングされる。このようにして、ネイティブＩＰトラフィックが別のＩＰストリームにパックされると、オーバーヘッドが２倍になり、帯域幅の浪費につながる。

ネイティブイーサネットトラフィックがＩＰネットワークを介してトランスポートされるためには、カプセル化が必須であるが、より効率的に処理され得るネイティブＩＰトラフィックのためには必須ではない。しかしながら、ＩＰ（ＴＣＰおよびＵＤＰ）トラフィックも、今日サポートされない適切な方法で処理されなければならない。カプセル化が回避されるべき場合、ＩＰアドレスとポート番号とを、デバイスを接続するためにモバイルネットワークによって使用されるアドレスに再マッピングする必要があるが、ＮＡＴ（ネットワークアドレス変換）機能はこのタスクのために好適でない。

発明者らは、今日、最適化された工業用通信のために欠けていることは、イーサネットをＩＰとは異なるように処理するために、（同じＭＡＣアドレスを有する）同じソースから来たネイティブＩＰトラフィックからネイティブイーサネットトラフィックを分離して、イーサネットをカプセル化し、ＩＰを再マッピングする可能性であることに気が付いた。

さらに、発明者らは、ＩＰベースの監視および管理トラフィックから、リアルタイムトラフィックをトランスポートするネイティブイーサネットと一般のリアルタイムトラフィックとの間のトラフィックフローを分離することは、タイムクリティカルなサービス上のジッタを低減することができることに気が付いた。

この文書は、被制御デバイスが、４Ｇまたは５Ｇ無線ネットワークによって与えられる無線接続性を使用して（クラウドに達し得る）リモートコントローラと最適化された方法で通信することを可能にする、方法およびインターフェースデバイスを開示する。

インターフェースデバイスは、工業イーサネットトラフィック（たとえばＰｒｏｆｉｎｅｔ、ＥｔｈｅｒＣＡＴ）を受信し、ネイティブイーサネットをカプセル化し、ＩＰトラフィックを再マッピングすることによって効率的な方法でモバイル無線通信を介して送られるように工業イーサネットトラフィックを適合させることが可能である。モバイルネットワーク輻輳、または（たとえば４Ｇ／５Ｇ無線モジュールのカテゴリーによる）ロボットＬＡＮレートに対する限られたアップリンクレートの場合に、タイムクリティカルなサービス上のジッタを低減するために、通信クラス（ＣＢＲ、ＶＢＲ、ＵＢＲ）におけるこのトラフィックフローのさらなるマッピングが導入され得る。

次に、図１を参照しながら、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法の一実施形態について説明する。被制御デバイスは、たとえば、ロボット、ロボットセル中のデバイスまたはセンサーであり得、コントローラは、たとえば、プログラマブル論理コントローラ（ＰＬＣ）であり得る。３ＧＰＰ無線ネットワークは、たとえば、４Ｇネットワークまたは５Ｇネットワークとしても知られる、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）ネットワークであり得る。本方法については、ロボット５０８がそれのＰＬＣコントローラ５０２から遠隔にある、図５に示された簡単な実装の例のコンテキストにおいて説明する。ＰＬＣ５０２は第１のインターフェースデバイス５０４に接続され、ロボット５０８は第２のインターフェースデバイス５０６に接続される。ＰＬＣと第１のインターフェースデバイスとの間の接続、ならびにロボットと第２のインターフェースデバイスとの間の接続は、たとえば、電気または光ケーブルを介して製造プラントにおいて同じローカルネットワークを介して実現され得る。ＰＬＣおよびロボット（およびそれらのローカルに接続されたインターフェースデバイス５０４および５０６）は同じ建築物中、異なる建築物中、またはさらにはより遠いロケーションに位置し得る。インターフェースデバイス５０４とインターフェースデバイス５０６との間の通信は３ＧＰＰ無線ネットワーク５２０、たとえば４Ｇまたは５Ｇネットワークを介して実現される。

動作中に、ＰＬＣ５０２は、たとえば制御コマンドを含むトラフィックならびに設定および管理トラフィックを、ＰＬＣ５０２が制御するロボット５０８に送り得る。３ＧＰＰ無線ネットワーク５２０を介したＰＬＣ５０２とロボット５０８との間の通信の方法は第１のインターフェースデバイス５２０において実行される。第１のインターフェースデバイス５２０がＰＬＣ５０２からのトラフィックを、第２のインターフェースデバイス５０６に接続されたロボット５０８に送信するとき、第１のインターフェースデバイス５０４はソースインターフェースデバイスと呼ばれることがあり、第２のインターフェースデバイス５０６は宛先インターフェースデバイスと呼ばれることがある。

ソースインターフェースデバイス５０４において実行される方法は、着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第１の経路と、ＩＰ（インターネットプロトコル）トラフィックを搬送する第２の経路とにスプリットすること１０２を含む。ＩＰトラフィックは、その場合、３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイス５０６のＩＰアドレスに対して再マッピング１０６された、それのパケットのＩＰアドレスを有する。ネイティブイーサネットトラフィックは、一方、イーサネットフレームにＩＰヘッダを追加することによってＩＰトラフィック中にカプセル化され、ＩＰヘッダは、３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイス５０６のＩＰアドレスを含む。好ましくは、再マッピング１０６の動作とカプセル化１０４の動作とは並行して実行される。以下の動作において、前記第１の経路と前記第２の経路とからのＩＰトラフィックは、３ＧＰＰ無線ネットワークを介した宛先インターフェースデバイス５０６への、次いでロボット５０８に向かう、送信１１０のためにスケジュール１０８される。もちろん、前述のように、ロボットの代わりに、センサーまたはロボットセル中のデバイスがＰＬＣ５０２からのトラフィックの受信側であり得る。

図５で示されているシナリオにおける再マッピングの動作について、以下の表１においてさらに説明する。ＰＬＣ５０２からの、ソースインターフェースデバイス５０４によって受信されたＩＰパケットは、第１のロボット５０８のアドレス、たとえば１２０．１００．１．１０／１０００を含んでいる。ＰＬＣ５０２と第１のロボット５０８とは同じローカルネットワークにおいて動作する。ソースインターフェースデバイス５０４は、ローカルネットワークからのＩＰアドレスを宛先インターフェースデバイス５０６のＩＰアドレス、たとえば１０．１０．１０．２／１０００に再マッピングし、このＩＰアドレスを用いて、パケットが４Ｇまたは５Ｇ無線通信ネットワークを介してソースから宛先インターフェースデバイスに送信される。ただ１つのロボット５０８が宛先インターフェースデバイス５０６に接続されているので、ポート番号の再マッピングを実行する必要はない。したがって、１００００の値はすべてのインターフェース上で使用される。これは表１の右側（ＴＸ側）に示されている。

図６は、３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイス５０６が複数の被制御デバイス５０８、５１０、５１２に接続されている、開示されたソリューションの実際的な展開を示す。この実施形態における方法は、再マッピング１０６およびカプセル化１０４の動作中に、宛先インターフェースデバイス５０６のＩＰアドレスに、トラフィックをそれぞれの被制御デバイスにルーティングするためのポート番号を追加する動作１０６－１および１０４－１を含む。

図６に示されているシナリオにおける再マッピングの動作は、図５と表１とに関して上記で説明した動作と同様である。差異は以下の表２に説明されている。

最初に、ソースインターフェースデバイス５０４によってＰＬＣ５０２から受信されたＩＰパケットは、宛先インターフェースデバイス５０６に接続された３つのロボット５０８、５１０および５１２のアドレス指定、たとえば１２０．１００．１．１０／１０００、１２０．１００．１．１１／１０００および１２０．１００．１．１２／１０００を含んでいる。これらのＩＰアドレスは、次いで、宛先インターフェースデバイス５０６の無線ネットワークインターフェースのＩＰアドレス、たとえば１０．１０．１０．２に再マッピングされるが、トラフィックのこれらの３つの別個のストリームを区別するために、それらは異なるポート番号を使用し、各ポート番号は、宛先インターフェースデバイス５０６に接続されたロボットのうちの１つを識別する。ＩＰアドレスは１０．１０．１０．２／５０００、１０．１０．１０．２／５００１および１０．１０．１０．２／５００２に再マッピングされる。これらの再マッピングされたＩＰアドレスを用いて、パケットは４Ｇまたは５Ｇ無線通信ネットワークを介してソースから宛先インターフェースデバイスに送信される。表２、図６および上記の説明に示されているように、いくつかのロボットが単一のインターフェースデバイスに接続されているとき、ポート番号は再マッピングされる。

上記の例では、ＰＬＣから単一のロボットまたは複数のロボットへのトラフィックの送信について説明したが、同じソリューションは、トラフィックが、単一のロボットから単一のＰＬＣに、および１つのインターフェースデバイスに接続された複数のロボットから、単一のインターフェースデバイスに接続された複数のＰＬＣに進むシナリオに等しく適用可能である。また、ロボットの代わりに、別の被制御デバイス、たとえば、センサーまたはロボットセル中の任意の他のデバイスが、図５および図６に示されたシナリオにおいて実装され得る。

図７は、ローカルネットワーク中のネイティブイーサネットトラフィックのハンドリング、特に、４Ｇまたは５Ｇネットワークを介した送信のためのネイティブイーサネットトラフィックのカプセル化を示す。図７に示された例示的なネットワークは、図６に示されたものと同じであるが、明快のために、ＩＰアドレス指定の詳細のうちのいくつかは削除されている。

ソースインターフェースデバイス５０２はイーサネット側でブリッジ（またはスイッチ）のように動作し、そのことは、ソースインターフェースデバイス５０２が、宛先ＭＡＣアドレスに関わらず、すべての着信トラフィックを受け付けることを意味する。このようにして、フレーム中の宛先ＭＡＣアドレスは他方の側のロボットのうちの１つに直接設定され得る。簡潔のために、ここでは、第２のロボット５１０に宛てられたネイティブイーサネットトラフィックのみについて考える。第２のロボット５１０は、ＭＡＣアドレスＭＡＣ＿２をもつネットワークインターフェースを使用する。ＰＬＣ５０２は、ＭＡＣ＿２アドレスを含むイーサネットフレーム７０２をソースインターフェースデバイス５０４に送ることによって第２のロボット５１０にネイティブイーサネットトラフィックを送信する。

ソースインターフェースデバイス５０２は、カプセル化解除機能に割り当てられたポート番号と一緒に、宛先インターフェースデバイス５０６の無線ネットワークインターフェースのＩＰアドレス、たとえば１０．１０．１０．２／６００１を含んでいるＩＰヘッダを取り付けることによってイーサネットフレームのカプセル化を実行する。これは、４Ｇまたは５Ｇネットワークを介して宛先インターフェースデバイス５０６に向かって送信されるＩＰパケット７０４を形成する。

イーサネットフレームおよびカプセル化されたイーサネットフレームは、明快および簡潔のために簡略化された形態で図７に示されている。カプセル化の概念を示す他の方法も可能であるが、それらは本開示の教示を変更しない。

上記では、一方の側にただ１つのＰＬＣがあり、他方の側に１つのロボットがある単純な状況について説明する。１つのＰＬＣと複数のロボットとがあるシナリオでは、カプセル化解除の後に、ＩＰヘッダが削除され、イーサネットフレームが、次いで、ＭＡＣアドレス、図７に示された実施形態ではＭＡＣ＿１、ＭＡＣ＿２およびＭＡＣ＿３に基づいてそれぞれのロボットに転送されるので、カプセル化プロセスは、単一のＩＰアドレスと、カプセル化解除機能に割り当てられた単一のポート番号とを使用し得る。一方の側にいくつかのＰＬＣがあるシナリオでは、それぞれのいくつかのカプセル化解除機能のために使用されるいくつかのポート番号があり得る。代替的に、異なるカプセル化解除機能は、たとえば、ＶｘＬＡＮカプセル化の場合のように、カプセル化／カプセル化解除機能に割り当てられたカプセル化ＩＤによって識別され得る。ＶｘＬＡＮは標準化文書ＲＦＣ７３４８－「Ｖｉｒｔｕａｌ ｅＸｔｅｎｓｉｂｌｅ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ （ＶＸＬＡＮ）： Ａ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ｏｖｅｒｌａｙｉｎｇ Ｖｉｒｔｕａｌｉｚｅｄ Ｌａｙｅｒ ２ Ｎｅｔｗｏｒｋｓ ｏｖｅｒ Ｌａｙｅｒ ３ Ｎｅｔｗｏｒｋｓ」において詳細に説明されている。また別の代替実施形態では、４Ｇ／５Ｇ無線ネットワークの一方の側にいくつかのＰＬＣがあり、他方の側にいくつかのロボットがあるシナリオでさえ、ＩＰヘッダがカプセル化解除機能によって削除されると、次いで、あらわにされたＭＡＣアドレスが、イーサネットフレームをそれの宛先ロボットに転送するために使用されるので、単一のカプセル化解除機能（およびこのカプセル化解除機能に割り当てられた単一のポート番号）が使用され得る。

一実施形態では、カプセル化する動作は、ＩＰヘッダに、カプセル化動作に関連する識別子（ＩＤ）を追加すること１０４－２を含む。ＶｘＬＡＮカプセル化の場合、カプセル化ＩＤは、ＶｘＬＡＮネットワーク識別子またはＶＮＩと呼ばれ、ＶｘＬＡＮヘッダ（すなわち、カプセル化中に追加されたヘッダ）中に位置する。これは、図７の要素７０４において極めて簡略化された形態で示されている。代替実施形態では、カプセル化の他の方法、たとえば、ＯｐｅｎＶＰＮまたはＩＰｓｅｃのような、ＶＰＮを使用する方法が使用され得る。これらの方法では、データは、適切なヘッダをもつＩＰパケット（ＴＣＰ、ＵＤＰ）にカプセル化される。ＶｘＬＡＮと比較した主要な差異は、ＶＰＮベースのカプセル化において使用される暗号化であり、それは、ＶｘＬＡＮと比較してＶＰＮベースのカプセル化の複雑さを増加させる。

ソースインターフェースデバイスによってＰＬＣから受信されるトラフィックはＩＰトラフィックとイーサネットとの混合を含む。好ましい実施形態では、イーサネットは、工業イーサネット、たとえば、Ｐｒｏｆｉｎｅｔ、ＥｔｈｅｒＣＡＴなどである。好ましい実施形態では、スプリットする動作１０２は、ＩＰヘッダをもつパケットを第２の経路に転送することと、残りのパケットを第１の経路に転送することとを含む。このようにして、ＩＰ再マッピングのためのトラフィックはＩＰカプセル化のためのトラフィックから分離される。

好ましい実施形態では、スケジュールする動作１０８は設定および管理トラフィックよりもリアルタイム制御トラフィックを優先させる。一般に、スプリットの後に第１の経路上に存在するネイティブイーサネットトラフィックは、最も高い優先度を有するが、スプリットの後に第２の経路上に存在するＴＣＰ／ＵＤＰは、通常、管理および監視目的のために使用され、したがってより低い優先度を有する。いくつかのタイプのスケジューリング機構がこの目的のために採用され得る。一実施形態では、重み付きラウンドロビン（Ｗｅｉｇｈｔｅｄ Ｒｏｕｎｄ Ｒｏｂｉｎ）（ＷＲＲ）がスケジュールのために使用され得る。代替実施形態では、しかしながら、異なるスケジューリング技法、たとえば、重み付き公平キューイング（Ｗｅｉｇｈｔｅｄ Ｆａｉｒ Ｑｕｅｕｉｎｇ）（ＷＦＱ）、厳格優先度（Ｓｔｒｉｃｔ Ｐｒｉｏｒｉｔｙ）、優先度ベース欠陥重み付きラウンドロビン（Ｐｒｉｏｒｉｔｙ－Ｂａｓｅｄ Ｄｅｆｉｃｉｔ Ｗｅｉｇｈｔｅｄ Ｒｏｕｎｄ Ｒｏｂｉｎ）およびいくつかの他の技法が使用され得る。

スケジューリング機能は、４Ｇ／５Ｇ無線モジュール３０６が、ロボットとＰＬＣとをそれらのそれぞれのインターフェースデバイス５０４および５０６に接続するローカルネットワークよりも低いアップリンク帯域幅をもつカテゴリーであるときに、ジッタを低減するために有用である（たとえば、ＬＡＮの１００Ｍｂｐと比較して、ｃａｔ．４ ＬＴＥドングルは５０Ｍｂｐｓアップリンクレートを有する）。また、カプセル化機構はインターフェースデバイス５０４、５０６の最大スループットに影響を及ぼすことができ、スケジューリングは、低いジッタでタイムクリティカルなサービスを処理するために必要とされることに留意することが重要である。

スケジューリングは、低い優先度をもつトラフィックよりも、高い優先度をもつトラフィックに優先的処理を与えるので、ソリューションは、トラフィックが送信を待ちながらキューイングされるキューを含む。

次に、図２を参照しながら、３ＧＰＰ無線ネットワーク５２０を介した被制御デバイス５０８、５１０、５１２とコントローラ５０２との間の通信の方法の一実施形態について説明する。本方法は、宛先インターフェースデバイス５０６において実行され、着信トラフィックを、ＩＰ（インターネットプロトコル）パケット中にカプセル化されたネイティブイーサネットトラフィックを搬送する第３の経路と、ＩＰトラフィックを搬送する第４の経路とにスプリットすること２０２を含む。宛先インターフェースデバイス５０６は、前に説明したように、好ましい実施形態では４Ｇまたは５Ｇネットワークであり得る、３ＧＰＰ無線ネットワーク５２０を介してトラフィックを受信する。トラフィックのパケットは、宛先インターフェースデバイス５０６の３ＧＰＰ無線ネットワークインターフェースのＩＰアドレスに対してアドレス指定される。図５、図６および図７に示された例では、このＩＰアドレスは１０．１０．１０．２である。受信されたパケットは、さらに、宛先インターフェースデバイス５０６に接続された異なるロボット５０８～５１２のためのトラフィック、ならびにカプセル化されたイーサネットフレームを含んでいるトラフィックを区別することを可能にする、ポート番号に対してアドレス指定される。カプセル化されたイーサネットフレームを搬送する受信されたトラフィックの部分は、カプセル化解除機能に割り当てられたポート番号を使用する。さらに、いくつかのタイプのカプセル化のために、カプセル化されたイーサネットフレームを搬送するトラフィックのヘッダはカプセル化ＩＤ（たとえば、ＶｘＬＡＮカプセル化の場合はＶＮＩ）を含む。ＶｘＬＡＮカプセル化が使用される場合、カプセル化されたネイティブイーサネットトラフィックは、ＶｘＬＡＮ識別子（ＶＮＩ）と、ＶｘＬＡＮのＩＰアドレスおよびポートとによって規定される。この場合、トラフィックスプリッタはルータのように挙動する。ＶｘＬＡＮに関連付けられたＩＰアドレスとポートとをもつパケットはカプセル化解除機能に向かってルーティングされるが、ＩＰトラフィックの残りは、システムをキューイングするＴＣＰ／ＵＤＰに送られる。随意に、トラフィックスプリッタはまた、２つ以上のＶｘＬＡＮのセットアップの場合、ＶｘＬＡＮ識別子を検査することができ、状況は一般にＰＬＣ側に対応して起こる。したがって、一実施形態におけるスプリットする動作は、カプセル化解除機能に割り当てられたポート番号をもつパケットを第３の経路上に（およびカプセル化解除機能に）転送し得るか、または、代替実施形態では、スプリットする動作は、カプセル化ＩＤ（たとえばＶＮＩ）を含んでいるＩＰパケットを第３の経路に転送し得る。トラフィックの残りの部分は第４の経路に転送される。

トラフィックがスプリットされると、第３の経路上の部分はカプセル化解除され２０４、ＩＰヘッダを削除した後に元のネイティブイーサネットフレームが生成される。ＶｘＬＡＮまたはＶＰＮベースのカプセル化を使用する実施形態でも、対応するヘッダは削除されなければならず、ＶＰＮの場合、データも解読されるべきである。第４の経路上で、少なくとも１つの被制御デバイスまたはコントローラのＩＰアドレスをもつ受信されたパケットのＩＰアドレスの再マッピング２０６が実行される。図５～図７に示されたシナリオでは、トラフィックはＰＬＣコントローラ５０２からロボット５０８～５１２に流れるが、ソリューションは、トラフィックがロボット５０８～５１２からＰＬＣコントローラ５０２に流れる場合同様に働く。

トラフィックが宛先インターフェースデバイス５０６からロボット５０８またはロボット５０８～５１２に送信される２１０前に、トラフィックはスケジュールされる２０８。好ましい実施形態では、スケジュールする動作２０８は設定および管理トラフィックよりもリアルタイム制御トラフィックを優先させる。

図５に示されているシナリオ（宛先インターフェースデバイス５０６に接続された単一のロボット５０８）における再マッピングする動作は、前に提示した表１（ＲＸ側）において説明される。ネイティブＩＰパケット（すなわち、カプセル化されたイーサネットフレームを搬送しないＩＰパケット）は宛先インターフェースデバイス５０６の無線ネットワークインターフェースのＩＰアドレス１０．１０．１０．２と、ポート番号１００００とともに受信される。ＩＰアドレス１０．１０．１０．２はロボット５０８のローカルＩＰアドレス１２０．１００．１．１０に再マッピングされる。宛先インターフェースデバイスに接続されたロボットはただ１つであり、ソースインターフェースデバイスから宛先インターフェースデバイスに送られるトラフィックを区別する必要がなかったので、ポート番号は同じままである。

図６に示されているシナリオにおける再マッピングする動作は、図５と表１とに関して上記で説明した動作と同様である。差異は、前に提示した表２（ＲＸ側）において説明される。３ＧＰＰ無線ネットワークから宛先インターフェースデバイス５０６に到着したパケットは、宛先インターフェースデバイス５０６の無線ネットワークインターフェースのＩＰアドレス１０．１０．１０．２に対してアドレス指定され、さらに、宛先インターフェースデバイス５０６に接続されたロボット５０８～５１２に割り当てられた異なるポート番号、すなわち、１０．１０．１０．２／５０００、１０．１０．１０．２／５００１および１０．１０．１０．２／５００２によって区別される。このシナリオでは、無線インターフェース上で使用されたＩＰアドレスとポート番号とは、ＬＡＮにおいてロボット５０８～５１２によって使用されるＩＰアドレスとポート番号と、すなわち、１２０．１００．１．１０／１０００、１２０．１００．１．１１／１０００および１２０．１００．１．１２／１０００とに再マッピングされる。図６に示されたこれらの３つのロボットに向けられたトラフィックはスイッチ６０２によってそれの受信側に転送される。スイッチ６０２は図６および図７に別個の構成要素として示されており、スイッチ６０２の機能は、すべてのイーサネットポートを一緒に接続し、トラフィックを意図された宛先に転送することである。代替実施形態では、インターフェースデバイス５０６は各ロボットのためのポートを有し得、スイッチ機能は、その場合、インターフェースデバイス５０６内の、スケジューラの後に位置するであろう。

次に、図３を参照しながら、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイス３００の実施形態について説明する。この実施形態では、インターフェースデバイス３００は、ソースインターフェースデバイス（たとえば、図５～図７におけるデバイス５０４）として動作するように適合される。好ましい実施形態では、インターフェースデバイス３００は処理回路３０２とメモリ３０４とを備える。メモリ３０４は、インターフェースデバイス３００が、着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第１の経路と、ＩＰ（インターネットプロトコル）トラフィックを搬送する第２の経路とにスプリットするように動作可能であるように、処理回路３０２によって実行可能な命令を含んでいる。インターフェースデバイス３００はまた、ＩＰトラフィックのパケットのＩＰアドレスを、３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイスのＩＰアドレスに対して再マッピングし、ネイティブイーサネットトラフィックを、３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイスのＩＰアドレスをもつＩＰトラフィック中にカプセル化するように動作可能である。さらに、インターフェースデバイス３００は、３ＧＰＰ無線ネットワークを介した宛先インターフェースデバイスへの送信のために第１の経路と第２の経路とからのＩＰトラフィックをスケジュールするように動作可能である。

処理回路３０２は単一のオフザシェルフ（ｏｆｆ－ｔｈｅ－ｓｈｅｌｆ）プロセッサまたは複数のオフザシェルフプロセッサであり得、処理回路３０２はまた、専用特定用途向け集積回路（ＡＳＩＣ）、あるいはデジタルまたはアナログハードウェア構成要素または専用プロセッサを含む任意の他のタイプの処理回路であり得る。同様に、メモリ３０４は、知られている技術のうちの１つにおいて生成される１つまたは複数のメモリモジュールであり得る。

インターフェースデバイス３００は、ソースインターフェースデバイスとして動作しているとき、図１に示され、上記で説明した方法の様々な実施形態を実行するように動作可能である。

次に、また別の実施形態における、３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイス３００について説明する。このインターフェースデバイスの一実施形態は図３に示されている。この実施形態では、インターフェースデバイス３００は、図５～図７に示された宛先インターフェースデバイス５０６として動作するように適合される。インターフェースデバイス３００は処理回路３０２とメモリ３０４とを備える。上記で説明したように、処理回路およびメモリは様々な技術において単一のモジュールまたは複数のモジュールとして実現され得る。メモリ３０４は、インターフェースデバイス３００が、着信トラフィックを、ＩＰ（インターネットプロトコル）パケット中にカプセル化されたネイティブイーサネットトラフィックを搬送する第３の経路と、ＩＰトラフィックを搬送する第４の経路とにスプリットするように動作可能であるように、処理回路３０２によって実行可能な命令を含んでいる。インターフェースデバイス３００はまた、第４の経路上のＩＰトラフィックのパケットのＩＰアドレスを、少なくとも１つの被制御デバイスまたはコントローラのＩＰアドレスに対して再マッピングし、第３の経路上のＩＰトラフィックからのネイティブイーサネットトラフィックをカプセル化解除するように動作可能である。さらに、インターフェースデバイス３００は、インターフェースデバイスに接続された少なくとも１つの被制御デバイスまたはコントローラへの送信のために第３の経路と第４の経路とからのトラフィックをスケジュールするように動作可能である。

インターフェースデバイス３００は、ソースインターフェースデバイスとして動作しているとき、図２に示され、上記で説明した方法の様々な実施形態を実行するように動作可能である。

上記では、インターフェースデバイス３００について、好ましい実施形態においてソースインターフェースデバイスとしておよび宛先インターフェースデバイスとして動作するように適合されるとして別個に説明したが、インターフェースデバイスは、両方の機能、すなわちソースインターフェースデバイスと宛先インターフェースデバイスの機能を実行するように適合される。実際的な展開では、トラフィックは両方向においてＰＬＣとロボットとの間で交換され、したがって、ＰＬＣに接続されたインターフェースデバイスは、ＰＬＣからロボットへのトラフィックを受信し、また、ロボットからＰＬＣへのトラフィックを受信する。ソースと宛先の機能を組み合わせるインターフェースデバイス３００の一実施形態が図４に示されている。図４に示された機能モジュールは、前に説明したそれらの様々な実施形態における方法の動作に対応する。一実施形態では、これらの機能モジュールは処理回路３０２中でソフトウェアによって実装され得るか、または、代替的に、それらは、（たとえば、処理回路がＡＳＩＣデバイスとして実装されるときに）専用のハードウェア中で実装され得る。

このソリューションの利点のうちの１つは、ＰＬＣおよびロボットが部分的にまたは完全にイーサネット（たとえばＰｒｏｆｉｎｅｔ、ＥｔｈｅｒＣＡＴ、イーサネットＩＰ）に基づく工業プロトコルを通信のために使用する場合でも、インターフェースデバイスおよび方法が産業シナリオにおいて４Ｇ接続または５Ｇ接続の最適な使用を可能にすることである。言い換えれば、本ソリューションは、レガシーＰＬＣとロボット上の変更を必要とすることなしに４Ｇ接続および／または５Ｇ接続の導入を可能にする。モバイル無線ネットワークによる通信は自動的にセットアップされ、ティアダウンされ、工業トラフィックトランスポートがそれの特性に基づいて最適化される。端末側で、インターフェースデバイス３０６はまた、４Ｇ／５Ｇ無線回路３０６－２と、関係するソフトウェアとを含む。これは図３ａに示されている。

インターフェースデバイス３００は、専用送信および受信モジュール３０６－１を使用した、４Ｇ／５Ｇネットワークを介した工業イーサネットトラフィックの送信および受信を可能にする。一実施形態では、モジュール３０６－１のＴｘ部分は、ＰＬＣ（またはロボット）からの工業イーサネットトラフィックを受信し、トラフィックをスプリットして、ＴＣＰ／ＵＤＰトラフィックとネイティブイーサネットトラフィックとに分離し、それらを４Ｇまたは５Ｇ無線ネットワークを介してロボットデバイス（またはＰＬＣ）に送り、上記で説明したように、イーサネットトラフィックをＩＰ中のカプセル化し、ネイティブＩＰトラフィックを再マッピングする。

動作中に、インターフェースデバイスは、通信をセットアップする過程においてサーバとしてまたはクライアントとして稼働し得る。これは図８に示されている。一般的な実施形態では、ＰＬＣに取り付けられたインターフェースデバイス３００はサーバ１５０４として稼働するが、ロボットセル中のロボット、センサー、デバイスなどに接続された他のインターフェースデバイスはクライアント１５０６として動作する。新しいインターフェースデバイスが、ネットワークに接続することを希望するとき、インターフェースデバイスは、最初に、無線ネットワークに接続すること８０２を試みる。これが成功した場合、インターフェースデバイスは、特定のアドレスにあるサーバ１５０４に到達することを試みる。後者は、プリセットされ得るか、またはＤＮＳサービスに接続して獲得され得る。クライアント１５０６は、少なくとも無線ネットワーク中のそれのＩＰアドレスを情報として含む接続要求をサーバ１５０４に送る８０４。サーバ１５０４は、その場合、クライアント１５０６を認証することができ、カプセル化された経路を作成するためのローカル設定を設定する８０６。次いで、サーバ１５０４は、カプセル化されたトラフィックフローを識別するための情報（たとえばＶｘＬＡＮ識別パラメータ）を含む動作の結果をクライアント１５０６に返送する８０８。この後、インターフェースデバイスと、インターフェースデバイスの接続されたＰＬＣおよびロボットとが４Ｇまたは５Ｇ無線ネットワークを介して互いに通信する８１０。

クライアントインターフェースデバイス１５０６の切断は、図８に示されたプロシージャに従う。クライアントインターフェースデバイス１５０６が切断要求を送り８１２、それに応答して、サーバインターフェースデバイス１５０４は、クライアントインターフェースデバイス１５０６に向かうローカル接続をティアダウンし８１４、次いで切断確認を送る８１６。クライアント側では、クライアントインターフェースデバイス１５０６が、サーバインターフェースデバイス１５０４に向かうローカル接続をティアダウンし８１８、次いで無線ネットワークから切断する８２０。

一実施形態では、インターフェースデバイスの無線部分は、無線経路上に１：１保護方式を実装する第２の無線デバイスを使用して保護され得る。第１の無線回路３０６－２、または第１の無線回路３０６－２が接続されている無線ネットワークの障害の場合、保護プロシージャは、トラフィックを、第１の無線回路３０６－２と同じ４Ｇまたは５Ｇ無線ネットワークまたは異なる無線ネットワークに接続され得る第２の無線回路３０６－３に切り替え得る。

ここで説明される保護方式の１つの実際的な態様は、第２の無線回路３０６－２および３０６－３に割り当てられたＩＰアドレスに関する。第２の無線回路３０６－３は、第１の無線回路３０６－２とは異なるＩＰアドレスによって識別される。スイッチオーバーが行われると、新しいカプセル化が作成され、表中のＩＰアドレスが変更される。ＶｘＬＡＮカプセル化の場合、新しいＶｘＬＡＮネットワーク識別子（ＶＮＩ）が使用される。

上記で説明したそれらの様々な実施形態における方法およびインターフェースデバイスは、３ＧＰＰ無線ネットワーク（特に第４世代および第５世代）の豊富な特徴の恩恵を受ける、被制御デバイスと被制御デバイスのコントローラとの間の通信を可能にする。本明細書で説明し、図に示されたソリューションはたいていＰＬＣからロボット（または複数のロボット）へのトラフィックの方向に基づくが、同じソリューションは、反対方向、すなわち、ロボット（または複数のロボット）からＰＬＣまたは（複数のＰＬＣ）に移動するトラフィックに適用可能である。

この文書は、ＰＬＣコントローラとロボットとの例を使用することによって本発明の実施形態を開示するが、特許請求の範囲において規定されるこのソリューションは、他のタイプのコントローラと被制御デバイスとに、たとえば、医療処置のための外科用デバイスと、外科用デバイスを制御するためのコントローラとに等しく適用され得る。上記で説明した本発明の実施形態の他の適用例は、化学プロセスおよび他の工業プロセスの制御を含む。

Claims (37)

1. ３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法であって、前記方法は、ソースインターフェースデバイスにおいて実行され、
   － 着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第１の経路と、ＩＰ（インターネットプロトコル）トラフィックを搬送する第２の経路とにスプリットすることと、
   － 前記ＩＰトラフィックのパケットのＩＰアドレスを、前記３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイスのＩＰアドレスに対して再マッピングすることと、
   － 前記ネイティブイーサネットトラフィックを、前記３ＧＰＰ無線ネットワークのリモートエンドにある前記宛先インターフェースデバイスの前記ＩＰアドレスをもつＩＰトラフィック中にカプセル化することと、
   － 前記第１の経路と前記第２の経路とからのＩＰトラフィックを、前記３ＧＰＰ無線ネットワークを介した前記宛先インターフェースデバイスへの送信のためにスケジュールすることと
   を含む、通信の方法。
2. 前記３ＧＰＰ無線ネットワークの前記リモートエンドにある前記宛先インターフェースデバイスが複数の被制御デバイスに接続される場合、前記再マッピングする動作と前記カプセル化する動作が、前記３ＧＰＰ無線ネットワークのリモートエンドにある前記宛先インターフェースデバイスの前記ＩＰアドレスに、前記トラフィックをそれぞれの前記被制御デバイスにルーティングするためのポート番号を追加することを含む、請求項１に記載の方法。
3. 前記着信トラフィックが工業イーサネットトラフィックを含む、請求項１または２に記載の方法。
4. 前記スプリットする動作が、ＩＰヘッダをもつパケットを前記第２の経路に転送することと、残りのパケットを前記第１の経路に転送することとを含む、請求項１から３のいずれか一項に記載の方法。
5. 前記スケジュールする動作が、設定および管理トラフィックよりもリアルタイム制御トラフィックを優先させる、請求項１から４のいずれか一項に記載の方法。
6. 前記カプセル化する動作が、前記宛先インターフェースデバイスの前記ＩＰアドレスに、カプセル化解除動作に割り当てられた事前定義されたポート番号を追加することを含む、請求項１から５のいずれか一項に記載の方法。
7. 前記カプセル化する動作が、ＩＰヘッダに、前記カプセル化動作に関連付けられた識別子を追加することを含む、請求項１から６のいずれか一項に記載の方法。
8. 第１の無線回路から第２の無線回路への前記スケジュールされたトラフィックの保護切替えを含む、請求項１から７のいずれか一項に記載の方法。
9. ３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法であって、前記方法は、宛先インターフェースデバイスにおいて実行され、
   － 着信トラフィックを、ＩＰ（インターネットプロトコル）パケット中にカプセル化されたネイティブイーサネットトラフィックを搬送する第３の経路と、ＩＰトラフィックを搬送する第４の経路とにスプリットすることと、
   － 前記第４の経路上の前記ＩＰトラフィックのパケットのＩＰアドレスを、少なくとも１つの被制御デバイスまたはコントローラのＩＰアドレスに対して再マッピングすることと、
   － 前記第３の経路上の前記ＩＰトラフィックからの前記ネイティブイーサネットトラフィックをカプセル化解除することと、
   － 前記宛先インターフェースデバイスに接続された前記少なくとも１つの被制御デバイスまたはコントローラへの送信のために前記第３の経路と前記第４の経路とからのトラフィックをスケジュールすることと
   を含む、通信の方法。
10. 前記スプリットする動作が、カプセル化解除動作に割り当てられた事前定義されたポート番号によって識別されたＩＰパケットを前記第３の経路に転送することと、残りのＩＰパケットを前記第４の経路に転送することとを含む、請求項９に記載の方法。
11. 前記スプリットする動作が、カプセル化動作に関連付けられた識別子によって識別されたＩＰパケットを前記第３の経路に転送することと、残りのＩＰパケットを前記第４の経路に転送することとを含む、請求項９に記載の方法。
12. 前記宛先インターフェースデバイスに接続された前記少なくとも１つの被制御デバイスまたはコントローラへの送信のための前記トラフィックが、工業イーサネットトラフィックを含む、請求項９から１１のいずれか一項に記載の方法。
13. 前記スケジュールする動作が、設定および管理トラフィックよりもリアルタイム制御トラフィックを優先させる、請求項９から１２のいずれか一項に記載の方法。
14. ３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスであって、前記インターフェースデバイスは、
    － 着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第１の経路と、ＩＰ（インターネットプロトコル）トラフィックを搬送する第２の経路とにスプリットすることと、
    － 前記ＩＰトラフィックのパケットのＩＰアドレスを、前記３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイスのＩＰアドレスに対して再マッピングすることと、
    － 前記ネイティブイーサネットトラフィックを、前記３ＧＰＰ無線ネットワークのリモートエンドにある前記宛先インターフェースデバイスの前記ＩＰアドレスをもつＩＰトラフィック中にカプセル化することと、
    － 前記３ＧＰＰ無線ネットワークを介した前記宛先インターフェースデバイスへの送信のために前記第１の経路と前記第２の経路とからのＩＰトラフィックをスケジュールすることと
    を行うように適合された、インターフェースデバイス。
15. 前記３ＧＰＰ無線ネットワークの前記リモートエンドにある前記宛先インターフェースデバイスが複数の被制御デバイスに接続される場合、前記インターフェースデバイスが、前記再マッピングする動作と前記カプセル化する動作とにおいて、前記宛先インターフェースデバイスの前記ＩＰアドレスに、前記トラフィックをそれぞれの前記被制御デバイスにルーティングするためのポート番号を追加するように適合された、請求項１４に記載のインターフェースデバイス。
16. 前記スプリットする動作において、ＩＰヘッダをもつパケットを前記第２の経路に転送し、残りのパケットを前記第１の経路に転送するように適合された、請求項１４または１５に記載のインターフェースデバイス。
17. 前記スケジュールする動作において、設定および管理トラフィックよりもリアルタイム制御トラフィックを優先させるように適合された、請求項１４から１６のいずれか一項に記載のインターフェースデバイス。
18. 前記カプセル化する動作において、前記宛先インターフェースデバイスの前記ＩＰアドレスに、カプセル化解除動作に割り当てられた事前定義されたポート番号を追加するように適合された、請求項１４から１７のいずれか一項に記載のインターフェースデバイス。
19. 前記カプセル化する動作において、ＩＰヘッダに、前記カプセル化動作に関連付けられた識別子を追加するように適合された、請求項１４から１８のいずれか一項に記載のインターフェースデバイス。
20. 第１の無線回路から第２の無線回路への前記スケジュールされたトラフィックの保護切替えを実行するように適合された、請求項１４から１９のいずれか一項に記載のインターフェースデバイス。
21. ３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスであって、前記インターフェースデバイスは、
    － 着信トラフィックを、ＩＰ（インターネットプロトコル）パケット中にカプセル化されたネイティブイーサネットトラフィックを搬送する第３の経路と、ＩＰトラフィックを搬送する第４の経路とにスプリットすることと、
    － 前記第４の経路上の前記ＩＰトラフィックのパケットのＩＰアドレスを、少なくとも１つの被制御デバイスまたはコントローラのＩＰアドレスに対して再マッピングすることと、
    － 前記第３の経路上の前記ＩＰトラフィックからの前記ネイティブイーサネットトラフィックをカプセル化解除することと、
    － 前記インターフェースデバイスに接続された前記少なくとも１つの被制御デバイスまたはコントローラへの送信のために前記第３の経路と前記第４の経路とからのトラフィックをスケジュールすることと
    を行うように適合された、インターフェースデバイス。
22. カプセル化解除動作に割り当てられた事前定義されたポート番号によって識別されたＩＰパケットを前記第３の経路に転送し、残りのＩＰパケットを前記第４の経路に転送することによって、前記着信トラフィックをスプリットするように適合された、請求項２１に記載のインターフェースデバイス。
23. カプセル化動作に関連付けられた識別子によって識別されたＩＰパケットを前記第３の経路に転送し、残りのＩＰパケットを前記第４の経路に転送することによって、前記着信トラフィックをスプリットするように適合された、請求項２１に記載のインターフェースデバイス。
24. 前記インターフェースデバイスに接続された前記少なくとも１つの被制御デバイスまたはコントローラへの送信のための前記トラフィックが、工業イーサネットトラフィックを含む、請求項１９から２１のいずれか一項に記載のインターフェースデバイス。
25. 設定および管理トラフィックよりもリアルタイム制御トラフィックを優先させることによって前記第３の経路と前記第４の経路とからの前記トラフィックをスケジュールするように適合された、請求項２１から２４のいずれか一項に記載のインターフェースデバイス。
26. ３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスであって、前記インターフェースデバイスは処理回路とメモリとを備え、前記メモリは、前記インターフェースデバイスが、
    － 着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第１の経路と、ＩＰ（インターネットプロトコル）トラフィックを搬送する第２の経路とにスプリットすることと、
    － 前記ＩＰトラフィックのパケットのＩＰアドレスを、前記３ＧＰＰ無線ネットワークのリモートエンドにある宛先インターフェースデバイスのＩＰアドレスに対して再マッピングすることと、
    － 前記ネイティブイーサネットトラフィックを、前記３ＧＰＰ無線ネットワークのリモートエンドにある前記宛先インターフェースデバイスの前記ＩＰアドレスをもつＩＰトラフィック中にカプセル化することと、
    － 前記３ＧＰＰ無線ネットワークを介した前記宛先インターフェースデバイスへの送信のために前記第１の経路と前記第２の経路とからのＩＰトラフィックをスケジュールすることと
    を行うように動作可能であるように、前記処理回路によって実行可能な命令を含んでいる、インターフェースデバイス。
27. 前記３ＧＰＰ無線ネットワークの前記リモートエンドにある前記宛先インターフェースデバイスが複数の被制御デバイスに接続される場合、前記インターフェースデバイスが、前記再マッピングする動作と前記カプセル化する動作とにおいて、前記宛先インターフェースデバイスの前記ＩＰアドレスに、前記トラフィックをそれぞれの前記被制御デバイスにルーティングするためのポート番号を追加するように動作可能である、請求項２６に記載のインターフェースデバイス。
28. 前記スプリットする動作において、ＩＰヘッダをもつパケットを前記第２の経路に転送し、残りのパケットを前記第１の経路に転送するように動作可能な、請求項２６または２７に記載のインターフェースデバイス。
29. 前記スケジュールする動作において、設定および管理トラフィックよりもリアルタイム制御トラフィックを優先させるように動作可能な、請求項２６から２８のいずれか一項に記載のインターフェースデバイス。
30. 前記カプセル化する動作において、前記宛先インターフェースデバイスの前記ＩＰアドレスに、カプセル化解除動作に割り当てられた事前定義されたポート番号を追加するように動作可能な、請求項２６から２９のいずれか一項に記載のインターフェースデバイス。
31. 前記カプセル化する動作において、ＩＰヘッダに、前記カプセル化動作に関連付けられた識別子を追加するように動作可能な、請求項２６から３０のいずれか一項に記載のインターフェースデバイス。
32. 第１の無線回路から第２の無線回路への前記スケジュールされたトラフィックの保護切替えを実行するように動作可能な、請求項２６から３１のいずれか一項に記載のインターフェースデバイス。
33. ３ＧＰＰ無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスであって、前記インターフェースデバイスが処理回路とメモリとを備え、前記メモリは、前記インターフェースデバイスが、
    － 着信トラフィックを、ＩＰ（インターネットプロトコル）パケット中にカプセル化されたネイティブイーサネットトラフィックを搬送する第３の経路とＩＰトラフィックを搬送する第４の経路とにスプリットすることと、
    － 前記第４の経路上の前記ＩＰトラフィックのパケットのＩＰアドレスを、少なくとも１つの被制御デバイスまたはコントローラのＩＰアドレスに対して再マッピングすることと、
    － 前記第３の経路上の前記ＩＰトラフィックからの前記ネイティブイーサネットトラフィックをカプセル化解除することと、
    － 前記インターフェースデバイスに接続された前記少なくとも１つの被制御デバイスまたはコントローラへの送信のために前記第３の経路と前記第４の経路とからのトラフィックをスケジュールすることと
    を行うように動作可能であるように、前記処理回路によって実行可能な命令を含んでいる、インターフェースデバイス。
34. カプセル化解除動作に割り当てられた事前定義されたポート番号によって識別されたＩＰパケットを前記第３の経路に転送し、残りのＩＰパケットを前記第４の経路に転送することによって、前記着信トラフィックをスプリットするように動作可能な、請求項３３に記載のインターフェースデバイス。
35. カプセル化動作に関連付けられた識別子によって識別されたＩＰパケットを前記第３の経路に転送し、残りのＩＰパケットを前記第４の経路に転送することによって前記着信トラフィックをスプリットするように動作可能な、請求項３３に記載のインターフェースデバイス。
36. 前記インターフェースデバイスに接続された前記少なくとも１つの被制御デバイスまたはコントローラへの送信のための前記トラフィックが、工業イーサネットトラフィックを含む、請求項３３から３５のいずれか一項に記載のインターフェースデバイス。
37. 設定および管理トラフィックよりもリアルタイム制御トラフィックを優先させることによって前記第３の経路と前記第４の経路とからの前記トラフィックをスケジュールするように動作可能な、請求項３３から３６のいずれか一項に記載のインターフェースデバイス。

Images