(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-06-17
(45)【発行日】2024-06-25
(54)【発明の名称】無線ネットワークを介したコントローラと被制御デバイスとの間の通信
(51)【国際特許分類】
H04L 61/2592 20220101AFI20240618BHJP
H04L 61/2517 20220101ALI20240618BHJP
H04L 47/2416 20220101ALI20240618BHJP
H04L 45/24 20220101ALI20240618BHJP
【FI】
H04L61/2592
H04L61/2517
H04L47/2416
H04L45/24
【外国語出願】
(21)【出願番号】P 2022169105
(22)【出願日】2022-10-21
(62)【分割の表示】P 2021519166の分割
【原出願日】2018-10-11
【審査請求日】2022-11-18
(73)【特許権者】
【識別番号】598036300
【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン(パブル)
(74)【代理人】
【識別番号】100109726
【氏名又は名称】園田 吉隆
(74)【代理人】
【識別番号】100150670
【氏名又は名称】小梶 晴美
(74)【代理人】
【識別番号】100194294
【氏名又は名称】石岡 利康
(72)【発明者】
【氏名】プレリ, マルツィオ
(72)【発明者】
【氏名】ペペ, テレザ
(72)【発明者】
【氏名】カタラーノ, シモナ
【審査官】速水 雄太
(56)【参考文献】
【文献】米国特許出願公開第2013/0121346(US,A1)
【文献】米国特許出願公開第2007/0189158(US,A1)
【文献】米国特許出願公開第2003/0063611(US,A1)
【文献】特開2015-111754(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 12/00-12/66
41/00-101/695
(57)【特許請求の範囲】
【請求項1】
3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法であって、前記方法は、ソースインターフェースデバイスにおいて実行され、
- 着信トラフィックを、ネイティブイーサネットトラフィックと、IP(インターネットプロトコル)トラフィックとにスプリットすること(102)と、
- 前記IPトラフィックのパケットのIPアドレスを、前記3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイスのIPアドレスに対して再マッピングすること(106)と、
- 前記ネイティブイーサネットトラフィックを、前記宛先インターフェースデバイスの前記IPアドレスをもつIPトラフィック中にカプセル化すること(104)と、
- 再マッピングされたIPアドレスをもつ前記パケットと前記カプセル化されたネイティブイーサネットトラフィックを、前記3GPP無線ネットワークを介して、前記宛先インターフェースデバイスに送信すること(110)であって、
前記IPトラフィック中の設定および管理トラフィックよりも
前記ネイティブイーサネットトラフィック中のリアルタイム制御トラフィックが優先される、ことと
を含む、方法。
【請求項2】
前記3GPP無線ネットワークの前記リモートエンドにある前記宛先インターフェースデバイスが複数の被制御デバイスに接続される場合、前記再マッピングと前記カプセル化の動作(104)が、前記3GPP無線ネットワークのリモートエンドにある前記宛先インターフェースデバイスの前記IPアドレスに、前記トラフィックをそれぞれの前記被制御デバイスにルーティングするためのポート番号を追加すること(106-1、104-1)を含む、請求項1に記載の方法。
【請求項3】
前記着信トラフィックが工業イーサネットトラフィックを含む、請求項1または2に記載の方法。
【請求項4】
前記スプリットする動作(102)が、IPヘッダをもつパケットを第2の経路に転送することと、残りのパケットを第1の経路に転送することとを含む、請求項1から3のいずれか一項に記載の方法。
【請求項5】
前記カプセル化する動作が、前記宛先インターフェースデバイスの前記IPアドレスに、カプセル化解除動作に割り当てられた事前定義されたポート番号を追加すること(104-1)を含む、請求項1から4のいずれか一項に記載の方法。
【請求項6】
前記カプセル化する動作が、IPヘッダに、前記カプセル化する動作に関連付けられた識別子を追加すること(104-2)を含む、請求項1から5のいずれか一項に記載の方法。
【請求項7】
第1の無線回路(306-2)から第2の無線回路(306-3)への前記
送信されたトラフィックの保護切替えを含む、請求項1から6のいずれか一項に記載の方法。
【請求項8】
3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法であって、前記方法は、宛先インターフェースデバイスにおいて実行され、
- 着信トラフィックを、IP(インターネットプロトコル)パケット中にカプセル化されたネイティブイーサネットトラフィックと、IPトラフィックとにスプリットすること(202)と、
- 前記IPトラフィックから前記ネイティブイーサネットトラフィックをカプセル化解除すること(204)と、
- 前記IPトラフィックのパケットのIPアドレスを、少なくとも1つの被制御デバイスまたはコントローラのIPアドレスに対して再マッピングすること(206)と、
- 再マッピングされたIPアドレスをもつ前記パケットと前記カプセル化解除されたネイティブイーサネットトラフィックを、前記宛先インターフェースデバイスに接続された少なくとも1つの被制御デバイスまたはコントローラに送信すること(210)であって、
前記IPトラフィック中の設定および管理トラフィックよりも
前記ネイティブイーサネットトラフィック中のリアルタイム制御トラフィックが優先される、ことと
を含む、方法。
【請求項9】
前記スプリットする動作(202)が、カプセル化解除動作に割り当てられた事前定義されたポート番号によって識別されたIPパケットを第3の経路に転送することと、残りのIPパケットを第4の経路に転送することとを含む、請求項8に記載の方法。
【請求項10】
前記スプリットする動作(202)が、カプセル化動作に関連付けられた識別子によって識別されたIPパケットを第3の経路に転送することと、残りのIPパケットを第4の経路に転送することとを含む、請求項8に記載の方法。
【請求項11】
3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイス(300)であって、前記インターフェースデバイス(300)は、
- 着信トラフィックを、ネイティブイーサネットトラフィックと、IP(インターネットプロトコル)トラフィックとにスプリットすることと、
- 前記IPトラフィックのパケットのIPアドレスを、前記3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイスのIPアドレスに対して再マッピングすることと、
- 前記ネイティブイーサネットトラフィックを、前記3GPP無線ネットワークのリモートエンドにある前記宛先インターフェースデバイスの前記IPアドレスをもつIPトラフィック中にカプセル化することと、
- 再マッピングされたIPアドレスをもつ前記パケットと前記カプセル化されたネイティブイーサネットトラフィックを、前記3GPP無線ネットワークを介して、前記宛先インターフェースデバイスに送信することであって、
前記IPトラフィック中の設定および管理トラフィックよりも
前記ネイティブイーサネットトラフィック中のリアルタイム制御トラフィックが優先される、ことと
を行うように適合された、インターフェースデバイス(300)。
【請求項12】
前記3GPP無線ネットワークの前記リモートエンドにある前記宛先インターフェースデバイスが複数の被制御デバイスに接続される場合、前記インターフェースデバイスが、前記再マッピングと前記カプセル化の動作とにおいて、前記宛先インターフェースデバイスの前記IPアドレスに、前記トラフィックをそれぞれの前記被制御デバイスにルーティングするためのポート番号を追加するように適合された、請求項11に記載のインターフェースデバイス(300)。
【請求項13】
前記スプリットする動作において、IPヘッダをもつパケットを第2の経路に転送し、残りのパケットを第1の経路に転送するように適合された、請求項11または12に記載のインターフェースデバイス(300)。
【請求項14】
前記カプセル化する動作において、前記宛先インターフェースデバイスの前記IPアドレスに、カプセル化解除動作に割り当てられた事前定義されたポート番号を追加するように適合された、請求項11から13のいずれか一項に記載のインターフェースデバイス(300)。
【請求項15】
前記カプセル化する動作において、IPヘッダに、前記カプセル化する動作に関連付けられた識別子を追加するように適合された、請求項11から14のいずれか一項に記載のインターフェースデバイス(300)。
【請求項16】
第1の無線回路(306-2)から第2の無線回路(306-3)への前記
送信されたトラフィックの保護切替えを実行するように適合された、請求項11から15のいずれか一項に記載のインターフェースデバイス(300)。
【請求項17】
3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイス(300)であって、前記インターフェースデバイス(300)は、
- 着信トラフィックを、IP(インターネットプロトコル)パケット中にカプセル化されたネイティブイーサネットトラフィックと、IPトラフィックとにスプリットすることと、
- 前記IPトラフィックから前記ネイティブイーサネットトラフィックをカプセル化解除することと、
- 前記IPトラフィックのパケットのIPアドレスを、少なくとも1つの被制御デバイスまたはコントローラのIPアドレスに対して再マッピングすることと、
- 再マッピングされたIPアドレスをもつ前記パケットと前記カプセル化解除されたネイティブイーサネットトラフィックを、前
記インターフェースデバイスに接続された少なくとも1つの被制御デバイスまたはコントローラに送信することであって、
前記IPトラフィック中の設定および管理トラフィックよりも
前記ネイティブイーサネットトラフィック中のリアルタイム制御トラフィックが優先される、ことと
を行うように適合された、インターフェースデバイス(300)。
【請求項18】
カプセル化解除動作に割り当てられた事前定義されたポート番号によって識別されたIPパケットを第3の経路に転送し、残りのIPパケットを第4の経路に転送することによって、前記着信トラフィックをスプリットするように適合された、請求項17に記載のインターフェースデバイス(300)。
【請求項19】
カプセル化動作に関連付けられた識別子によって識別されたIPパケットを第3の経路に転送し、残りのIPパケットを第4の経路に転送することによって、前記着信トラフィックをスプリットするように適合された、請求項17に記載のインターフェースデバイス(300)。
【請求項20】
前記インターフェースデバイスに接続された前記少なくとも1つの被制御デバイスまたはコントローラへの送信のための前記トラフィックが、工業イーサネットトラフィックを含む、請求項17から19のいずれか一項に記載のインターフェースデバイス(300)。
【請求項21】
3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイス(300)であって、前記インターフェースデバイス(300)は処理回路(302)とメモリ(304)とを備え、前記メモリ(304)は、前記インターフェースデバイス(300)が、
- 着信トラフィックを、ネイティブイーサネットトラフィックと、IP(インターネットプロトコル)トラフィックとにスプリットすることと、
- 前記IPトラフィックのパケットのIPアドレスを、前記3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイスのIPアドレスに対して再マッピングすることと、
- 前記ネイティブイーサネットトラフィックを、前記3GPP無線ネットワークのリモートエンドにある前記宛先インターフェースデバイスの前記IPアドレスをもつIPトラフィック中にカプセル化することと、
- 再マッピングされたIPアドレスをもつ前記パケットと前記カプセル化されたネイティブイーサネットトラフィックを、前記3GPP無線ネットワークを介して、前記宛先インターフェースデバイスに送信することであって、
前記IPトラフィック中の設定および管理トラフィックよりも
前記ネイティブイーサネットトラフィック中のリアルタイム制御トラフィックが優先される、ことと
を行うように動作可能であるように、前記処理回路(302)によって実行可能な命令を含んでいる、インターフェースデバイス(300)。
【請求項22】
3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイス(300)であって、前記インターフェースデバイス(300)が処理回路(302)とメモリ(304)とを備え、前記メモリ(304)は、前記インターフェースデバイス(300)が、
- 着信トラフィックを、IP(インターネットプロトコル)パケット中にカプセル化されたネイティブイーサネットトラフィックとIPトラフィックとにスプリットすることと、
- 前記IPトラフィックから前記ネイティブイーサネットトラフィックをカプセル化解除することと、
- 前記IPトラフィックのパケットのIPアドレスを、少なくとも1つの被制御デバイスまたはコントローラのIPアドレスに対して再マッピングすることと、
- 再マッピングされたIPアドレスをもつ前記パケットと前記カプセル化解除されたネイティブイーサネットトラフィックを、前
記インターフェースデバイスに接続された少なくとも1つの被制御デバイスまたはコントローラに送信することであって、
前記IPトラフィック中の設定および管理トラフィックよりも
前記ネイティブイーサネットトラフィック中のリアルタイム制御トラフィックが優先される、ことと
を行うように動作可能であるように、前記処理回路(302)によって実行可能な命令を含んでいる、インターフェースデバイス(300)。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、一般に、被制御デバイスとリモートコントローラとの間の通信に関し、特に、3GPP無線ネットワークを介したそのような通信のための方法およびインターフェースデバイスに関する。
【背景技術】
【0002】
将来の工場は製造プロセスおよびプラントのデジタル化によって実現されるであろう。デジタル変換は、製造プロセスのフレキシビリティを高めるために、工場において前には分離されていたデバイスとシステムとを接続することによって始まる。製造業者は、持続可能性、フレキシビリティ、トレーサビリティ、または安全性を犠牲にすることなしに、生産高を最大にするために、彼らの製造を個別化することを希望する。互いとおよび人間と通信することが可能な新しいクラウド駆動型ロボティックデバイスが必要とされるであろう。
【0003】
一般的な産業環境において、生産ラインは、それぞれ製品の特定の部品を製造することに専用の、様々な作業セルから構成される。生産ラインは、タスクを調整し、各作業セルに割り当てるプログラマブル論理コントローラ(PLC)によって制御される。作業セルまたは製造ステーションは、ロボティックデバイスと、コンベヤと、部品ポジショナーおよび安全環境などの他の周辺機器とを含む、完全なシステムである。作業セル全体はステーションPLCによって制御される。各ロボティックデバイスは、ステーションPLCによって管理されるそれ自体のロボットコントローラを有する。
【0004】
PLCは、機械とプロセスとを制御するために使用される専用コンピュータである。PLCは、したがって、中央処理ユニット、メモリ、ソフトウェアおよび通信のような、一般的なPCと共通の用語を共有する。パーソナルコンピュータとは異なり、しかしながら、PLCは、厳しい産業環境において存続し、PLCが実世界への入力および出力とどのようにインターフェースするかにおいて極めてフレキシブルであるように設計される。PLCは、(たとえば、スイッチ、センサーおよびロボティックデバイスからの)入力信号を出力(たとえば、運動指令(motor command)、ロボットコマンド、LED、リレーなど)に処理するシステムを連続的に監視し、逐次プロセス中のすべてのステップが適切なシーケンスにおいて実行されることを保証するために被制御プロセスに関して必要な行動を取る。
【0005】
ステーションPLCは、リモートI/O(入力/出力)、他のPLC(たとえば、生産ラインのためのPLC)およびロボットコントローラなどのように、異なるデバイスと通信する。すべてのこれらの通信は、配線および接続構成要素である物理接続と、ネットワーク化されたデバイス間の通信を可能にする共通語である共有プロトコルとを必要とする。通信プロトコル、たとえばフィールドバスは、デバイス間の通信において使用されるべきルールのセットを記述する。今日の産業ロボット工学において使用されるプロトコルのリストはかなり大きく、使用されるプロトコルの多くは、イーサネットおよび/またはIPネットワーキング、またはプロプライエタリネットワーキングプロトコルをもつシリアルケーブルのいずれかに基づく。パフォーマンスはしばしば物理レイヤ(最下位レイヤ)によって決定されるが、産業ロボット工学において使用される通信プロトコルはたいていアプリケーションレイヤ(上位レイヤ)の特徴と異なる。工業において使用される主要なイーサネットベースプロトコルはイーサネット/IP、Modbus TCP/IP、Profinet、EtherCATである。
【0006】
工業プロトコルは、それらの機能を実行するために異なるタイプの通信を処理する。たとえば、PROFINET IOは、プログラマブルコントローラおよび他のデバイスとデータを交換するために異なる通信チャネルを使用する。
- リアルタイム(RT)通信-I/OおよびアラームデータはリアルタイムPROFINET IOチャネルを介して伝達される。RTデータは以下であり得る。
- RT非周期データ-スケジュールされていないオンデマンド通信。IOスーパーバイザからI/Oデバイスへの診断メッセージは非周期である。
- RT周期データ-スケジュールされた反復通信。I/Oデータ伝達およびアラーム伝達は周期的である。
- 非リアルタイム通信-設定メッセージおよび診断メッセージは非リアルタイムPROFINET IOチャネルを介して伝達される。
【0007】
特に製造およびプロセス自動化における工業用通信は時間に正確で確定的なデータ送信を必要とする。この理由で、TCP/IPは、Profinetアプリケーションが必要とするほど速くも確定的でもないが、純粋なイーサネットトラフィックであるので、タイムクリティカルなI/Oユーザデータの周期的な交換のために、PROFINET IOはTCP/IPを使用しない。TCP/UDPは、主に始動設定のために使用され、まれであるが、予防的監視とともに、TCP/UDPの使用は増加するであろう。
【0008】
今日、生産ラインは、イーサネット接続を使用した固定有線ネットワークに基づいている。しかしながら、成熟したプラントは最高1000個の可動部品+はるかに多いデバイスとセンサーとを有するので、データトラフィックはもはや既存の有線内部ネットワークによってサポートされ得ず、したがって現在のプラントネットワークはボトルネックを生じ始めている。
【0009】
レガシーネットワークを支援して第2の有線ネットワークを追加することは可能であるが、両方のネットワークを一体化することは容易ではない。同時に、たとえば光ファイバーを使用した、プラントの完全な再ケーブリングは非常に広範になり得る。
【0010】
したがって、そのようなシナリオでは、無線接続性は最良のソリューションであると思われる。市場で、現在利用可能なソリューションは、PLCと、ロボットを動作させるためのロボティックデバイスとの間の通信をカバーしない。代わりに、それらは、様々な局所制御モジュールへのリモートアクセスのための上部レイヤSCADA(監視制御およびデータ収集)に向けた監視および一般的な管理機能に焦点を合わせている。センサーは、LTEを介してリモートサーバにクライアントとして接続され得、場合によっては、PLCは、SCADAに向かってLTEを介して通信することができる。
【0011】
この種類の接続性は、IPクライアントが、いくつかの管理/監視機能が動作するリモートサーバと連絡を取る、典型的なIoT方式に従う。工業IoT LTEベースの例は、たとえば、Siemens、Sierra WirelessおよびMoxaによって提供されるものである。
【0012】
SiemensのSCALANCE M876-4 LTE(UE)は、LTEを介したイーサネットに基づく無線IP通信のための4Gルータである。Siemensは、SCALANCE M876-4 LTE(UE)がProfinetプロトコルをサポートすると述べているが、それは、このサポートを、監視と管理とのみのために使用されるプロトコルのIPトラフィックのみに限定する。ロボティックデバイスを制御するために使用されるリアルタイムネイティブイーサネットProfinetトラフィックはサポートされない。
【0013】
同様に、Sierra Wirelessのような他の製造業者によって提供されるデバイス(たとえば、AirLink RV50産業用LTEゲートウェイ)も、LTEと、たとえば、SCADAが動作するリモートアプリケーションサーバとに対するローカルルータによって処理されるIP接続性のみを可能にする。したがって、それらは、監視および管理/設定目的のためにPLCと上位レイヤとの間の接続を可能にするが、それらは、作業セルにおけるロボティックデバイスの、それのPLCによるランタイム制御のためには好適ではない。
【0014】
使用され得る別のデバイスは、Moxaによって提供されるもの(たとえばOnCell G3470A-LTEシリーズ-産業用LTEセルラーゲートウェイ)のような、LTEゲートウェイである。クライアントとサーバとの間のVPN接続性を使用すると、両方の側で同じLANを接続することが可能である。このソリューションでは、ソリューションが、センサーおよびPLCのようないくつかのデバイスをリモート管理および監視システムに接続するために使用されることになっているので、VPNが使用される。インターネットを通る際、IPsecをもつVPNは良好なレベルの暗号化を行う。この場合も、PLCを直接ロボティックデバイスに接続することはサポートされない。
【0015】
上記で説明したように、数百個のロボットとセンサーとそれらのコントローラとへの接続性を与える追加の(電気または光)ケーブリングは現実的でなく、非常に費用がかかる。したがって、コストを低減し、インフラストラクチャを簡略化するために、無線接続性が展開される予定である。
【0016】
同時に、現在のWi-Fiは、いくつかのモチベーションにとって、工場環境において実行可能でない。
- 現在のWi-Fiは、帯域幅について競合する複数のアクセスポイントの存在により、同一チャネル干渉に対してロバストでない、共有スペクトル上の「ベストエフォート」通信技術である。
- パフォーマンスは接続されるデバイスの数とともに低下するので、(たとえば、新しいセンサーおよびデバイスを追加するための)工場において必要とされるスケーラビリティはWi-Fiによって保証され得ない。
- 「信号強度マッピング」は、かなり不正確であり、生産現場の周りを移動する「オブジェクト」によって動的な影響を受け得るので、プラントの安定したWi-Fiカバレッジプランニングを行うことは容易でない。
- WiFiは、工場中の機械から来る干渉と、高いトラフィック負荷との影響を受け得る。
【発明の概要】
【0017】
本発明の目的は、上記の欠点のうちの少なくともいくつかをなくし、3GPP無線ネットワークを介した被制御デバイスとリモートコントローラとの間の通信のための改善された方法およびインターフェースデバイスを提供することである。
【0018】
したがって、本発明は、好ましくは、上述の欠点のうちの1つまたは複数を、単独でまたは任意の組合せで、緩和すること、軽減すること、またはなくすことを求める。
【0019】
本発明の第1の態様によれば、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法が提供される。ソースインターフェースデバイスにおいて実行される方法は、着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第1の経路と、IP(インターネットプロトコル)トラフィックを搬送する第2の経路とにスプリットすることを含む。本方法はまた、IPトラフィックのパケットのIPアドレスを、3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイスのIPアドレスに対して再マッピングすることと、ネイティブイーサネットトラフィックを、3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイスのIPアドレスをもつIPトラフィック中にカプセル化することとを含む。本方法は、3GPP無線ネットワークを介した宛先インターフェースデバイスへの送信のために前記第1の経路と前記第2の経路とからのIPトラフィックをスケジュールすることをさらに含む。
【0020】
本発明の第2の態様によれば、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法が提供される。宛先インターフェースデバイスにおいて実行される方法は、着信トラフィックを、IP(インターネットプロトコル)パケット中にカプセル化されたネイティブイーサネットトラフィックを搬送する第3の経路と、IPトラフィックを搬送する第4の経路とにスプリットすることを含む。本方法はまた、第4の経路上のIPトラフィックのパケットのIPアドレスを、少なくとも1つの被制御デバイスまたはコントローラのIPアドレスに対して再マッピングすることと、第3の経路上のIPトラフィックからのネイティブイーサネットトラフィックをカプセル化解除することとを含む。本方法は、宛先インターフェースデバイスに接続された少なくとも1つの被制御デバイスまたはコントローラへの送信のために前記第3の経路と前記第4の経路とからのトラフィックをスケジュールすることをさらに含む。
【0021】
本発明の第3の態様によれば、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスが提供される。インターフェースデバイスは、着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第1の経路と、IP(インターネットプロトコル)トラフィックを搬送する第2の経路とにスプリットするように適合される。インターフェースデバイスはまた、IPトラフィックのパケットのIPアドレスを、3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイスのIPアドレスに対して再マッピングし、ネイティブイーサネットトラフィックを、3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイスのIPアドレスをもつIPトラフィック中にカプセル化するように適合される。さらに、インターフェースデバイスは、3GPP無線ネットワークを介した宛先インターフェースデバイスへの送信のために第1の経路と第2の経路とからのIPトラフィックをスケジュールするように適合される。
【0022】
本発明の第4の態様によれば、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスが提供される。インターフェースデバイスは、着信トラフィックを、IP(インターネットプロトコル)パケット中にカプセル化されたネイティブイーサネットトラフィックを搬送する第3の経路と、IPトラフィックを搬送する第4の経路とにスプリットするように適合される。インターフェースデバイスはまた、第4の経路上のIPトラフィックのパケットのIPアドレスを、少なくとも1つの被制御デバイスまたはコントローラのIPアドレスに対して再マッピングし、第3の経路上のIPトラフィックからのネイティブイーサネットトラフィックをカプセル化解除するように適合される。さらに、インターフェースデバイスは、インターフェースデバイスに接続された少なくとも1つの被制御デバイスまたはコントローラへの送信のために第3の経路と第4の経路とからのトラフィックをスケジュールするように適合される。
【0023】
本発明の第5の態様によれば、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスが提供される。インターフェースデバイスは処理回路とメモリとを備え、メモリは、インターフェースデバイスが、着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第1の経路と、IP(インターネットプロトコル)トラフィックを搬送する第2の経路とにスプリットするように動作可能であるように、処理回路によって実行可能な命令を含んでいる。インターフェースデバイスはまた、IPトラフィックのパケットのIPアドレスを、3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイスのIPアドレスに対して再マッピングし、ネイティブイーサネットトラフィックを、3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイスのIPアドレスをもつIPトラフィック中にカプセル化するように動作可能である。さらに、インターフェースデバイスは、3GPP無線ネットワークを介した宛先インターフェースデバイスへの送信のために第1の経路と第2の経路とからのIPトラフィックをスケジュールするように動作可能である。
【0024】
本発明の第6の態様によれば、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスが提供される。インターフェースデバイスは処理回路とメモリとを備え、メモリは、インターフェースデバイスが、着信トラフィックを、IP(インターネットプロトコル)パケット中にカプセル化されたネイティブイーサネットトラフィックを搬送する第3の経路と、IPトラフィックを搬送する第4の経路とにスプリットするように動作可能であるように、処理回路によって実行可能な命令を含んでいる。インターフェースデバイスはまた、第4の経路上のIPトラフィックのパケットのIPアドレスを、少なくとも1つの被制御デバイスまたはコントローラのIPアドレスに対して再マッピングし、第3の経路上のIPトラフィックからのネイティブイーサネットトラフィックをカプセル化解除するように動作可能である。さらに、インターフェースデバイスは、インターフェースデバイスに接続された少なくとも1つの被制御デバイスまたはコントローラへの送信のために第3の経路と第4の経路とからのトラフィックをスケジュールするように動作可能である。
【0025】
本発明のさらなる特徴は従属クレームに記載されている。
【0026】
本発明は多数の利益を提供し、それらのうちのいくつかについて次に手短に述べる。方法およびデバイスは、それらの様々な実施形態において、工業プロトコルに対してアグノスティック(agnostic)である。ソリューションは、工業プロトコルを用いた4G無線通信と5G無線通信との両立性を与える。ソリューションは、ケーブル接続の必要をなくすことによるインフラストラクチャコストの低減を可能にし、機能を仮想化することによる生産ラインのフレキシビリティを高める。ケーブリングの削除は、ローカルクラウド中のサーバ上のリモートな場所において動作するステーションPLC機能の伝達を促進し、PLCよりもはるかに強力な、そのような機械によって与えられる計算能力を活用する可能性を与える。したがって、よりフレキシブルな、洗練された制御機能がもたらされ得る。このソリューションはまた、ケーブリングを並べ替える必要がないので、組立ラインの並べ替えのために必要とされる停止時間を低減する。
【0027】
本発明は、図面とともに行われる以下の詳細な説明からより十分に理解され、諒解されよう。
【図面の簡単な説明】
【0028】
【
図1】本発明の一実施形態における、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法を示すフローチャートである。
【
図2】本発明の別の実施形態における、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法を示すフローチャートである。
【
図3】本発明の一実施形態における、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスを示すダイヤグラムである。
【
図3a】本発明の一実施形態における、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスを示すダイヤグラムである。
【
図4】本発明の一実施形態における、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスを示すダイヤグラムである。
【
図5】動作中の3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスを示す図である。
【
図6】動作中の3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイスを示す図である。
【
図7】本方法の一実施形態における、イーサネットトラフィックのカプセル化の動作を示す図である。
【
図8】
図3および
図4に示されたインターフェースデバイスの接続および切断を示すメッセージシーケンスチャートである。
【発明を実施するための形態】
【0029】
以下の説明では、本発明についての完全な理解を与えるために、限定ではなく説明の目的で、特定のアーキテクチャ、インターフェース、技法などの具体的な詳細が記載されている。しかしながら、本発明が、これらの具体的な詳細から逸脱する他の実施形態においても実施され得ることは、当業者には明らかであろう。他の事例では、本発明の説明を不要な詳細によって不明瞭にしないように、よく知られているデバイス、回路、および方法についての詳細な説明は省略されている。
【0030】
明細書全体にわたる「一実施形態」または「実施形態」への言及は、実施形態に関して説明した特定の特徴、構造、または特性が本発明の少なくとも1つの実施形態中に含まれることを意味する。したがって、本明細書全体にわたる様々な場所における「一実施形態では」または「実施形態では」というフレーズの出現は、必ずしもすべて同じ実施形態を指しているとは限らない。さらに、特定の特徴、構造または特性は1つまたは複数の実施形態において何らかの好適な様式で組み合わせられ得る。
【0031】
WiFi接続に関する問題の多くは、LTE無線接続を使用することによって対処され得る。しかしながら、帯域幅およびレイテンシの視点からより厳しい要件がある場合、5G無線接続性は、それの標準化されたネットワーキング機能、ビルトインセキュリティ、サービスの保証されたグレードならびにネットワークスライシングコンセプトとともに、デジタル変換を活用することを希望する先進産業のための最良のソリューションである。
【0032】
しかしながら、発明者らは、IEEE802.3イーサネットフレーム規格内でI/Oおよびロボット制御トラフィックのみを直接トランスポートするProfinetまたはEtherCATプロトコルが使用されるとき、イーサネット上でトランスポートされる工業プロトコルとLTE/5GのIPベースネットワークアーキテクチャとの間の互換性問題が明らかになることに気が付いた。したがって、工業プロトコル(たとえば、Profinet、Ethercat)と工業用通信のための無線接続性を使用するLTE/5G通信との間の互換性問題を解くことが重要である。
【0033】
産業用デバイスの圧倒的多数は、コマンドを起動するのではなくコマンドに応答するように設計されているので、これはIP通信についての問題である。インターネット上のユーザまたはマスタデバイスは、動的IPアドレスを割り当てられた産業用デバイスまたはセンサーとの接触を開始することができなくなる。このIPアドレス問題に対処するために、VXLAN(仮想拡張ローカルエリアネットワーク)、VPN(仮想プライベートネットワーク)または同様の技法を使用したIPトンネリングが使用され得る。
【0034】
しかしながら、トンネリングはトラフィックのトランスポートを最適化しない。ネイティブイーサネット(たとえば、profinet RTおよびethercat RTトラフィック)とネイティブIPトラフィック(たとえば、設定、保守および監視)の両方がカプセル化されて、あらゆるものがトンネリングされる。このようにして、ネイティブIPトラフィックが別のIPストリームにパックされると、オーバーヘッドが2倍になり、帯域幅の浪費につながる。
【0035】
ネイティブイーサネットトラフィックがIPネットワークを介してトランスポートされるためには、カプセル化が必須であるが、より効率的に処理され得るネイティブIPトラフィックのためには必須ではない。しかしながら、IP(TCPおよびUDP)トラフィックも、今日サポートされない適切な方法で処理されなければならない。カプセル化が回避されるべき場合、IPアドレスとポート番号とを、デバイスを接続するためにモバイルネットワークによって使用されるアドレスに再マッピングする必要があるが、NAT(ネットワークアドレス変換)機能はこのタスクのために好適でない。
【0036】
発明者らは、今日、最適化された工業用通信のために欠けていることは、イーサネットをIPとは異なるように処理するために、(同じMACアドレスを有する)同じソースから来たネイティブIPトラフィックからネイティブイーサネットトラフィックを分離して、イーサネットをカプセル化し、IPを再マッピングする可能性であることに気が付いた。
【0037】
さらに、発明者らは、IPベースの監視および管理トラフィックから、リアルタイムトラフィックをトランスポートするネイティブイーサネットと一般のリアルタイムトラフィックとの間のトラフィックフローを分離することは、タイムクリティカルなサービス上のジッタを低減することができることに気が付いた。
【0038】
この文書は、被制御デバイスが、4Gまたは5G無線ネットワークによって与えられる無線接続性を使用して(クラウドに達し得る)リモートコントローラと最適化された方法で通信することを可能にする、方法およびインターフェースデバイスを開示する。
【0039】
インターフェースデバイスは、工業イーサネットトラフィック(たとえばProfinet、EtherCAT)を受信し、ネイティブイーサネットをカプセル化し、IPトラフィックを再マッピングすることによって効率的な方法でモバイル無線通信を介して送られるように工業イーサネットトラフィックを適合させることが可能である。モバイルネットワーク輻輳、または(たとえば4G/5G無線モジュールのカテゴリーによる)ロボットLANレートに対する限られたアップリンクレートの場合に、タイムクリティカルなサービス上のジッタを低減するために、通信クラス(CBR、VBR、UBR)におけるこのトラフィックフローのさらなるマッピングが導入され得る。
【0040】
次に、
図1を参照しながら、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信の方法の一実施形態について説明する。被制御デバイスは、たとえば、ロボット、ロボットセル中のデバイスまたはセンサーであり得、コントローラは、たとえば、プログラマブル論理コントローラ(PLC)であり得る。3GPP無線ネットワークは、たとえば、4Gネットワークまたは5Gネットワークとしても知られる、LTE(Long Term Evolution)ネットワークであり得る。本方法については、ロボット508がそれのPLCコントローラ502から遠隔にある、
図5に示された簡単な実装の例のコンテキストにおいて説明する。PLC502は第1のインターフェースデバイス504に接続され、ロボット508は第2のインターフェースデバイス506に接続される。PLCと第1のインターフェースデバイスとの間の接続、ならびにロボットと第2のインターフェースデバイスとの間の接続は、たとえば、電気または光ケーブルを介して製造プラントにおいて同じローカルネットワークを介して実現され得る。PLCおよびロボット(およびそれらのローカルに接続されたインターフェースデバイス504および506)は同じ建築物中、異なる建築物中、またはさらにはより遠いロケーションに位置し得る。インターフェースデバイス504とインターフェースデバイス506との間の通信は3GPP無線ネットワーク520、たとえば4Gまたは5Gネットワークを介して実現される。
【0041】
動作中に、PLC502は、たとえば制御コマンドを含むトラフィックならびに設定および管理トラフィックを、PLC502が制御するロボット508に送り得る。3GPP無線ネットワーク520を介したPLC502とロボット508との間の通信の方法は第1のインターフェースデバイス520において実行される。第1のインターフェースデバイス520がPLC502からのトラフィックを、第2のインターフェースデバイス506に接続されたロボット508に送信するとき、第1のインターフェースデバイス504はソースインターフェースデバイスと呼ばれることがあり、第2のインターフェースデバイス506は宛先インターフェースデバイスと呼ばれることがある。
【0042】
ソースインターフェースデバイス504において実行される方法は、着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第1の経路と、IP(インターネットプロトコル)トラフィックを搬送する第2の経路とにスプリットすること102を含む。IPトラフィックは、その場合、3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイス506のIPアドレスに対して再マッピング106された、それのパケットのIPアドレスを有する。ネイティブイーサネットトラフィックは、一方、イーサネットフレームにIPヘッダを追加することによってIPトラフィック中にカプセル化され、IPヘッダは、3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイス506のIPアドレスを含む。好ましくは、再マッピング106の動作とカプセル化104の動作とは並行して実行される。以下の動作において、前記第1の経路と前記第2の経路とからのIPトラフィックは、3GPP無線ネットワークを介した宛先インターフェースデバイス506への、次いでロボット508に向かう、送信110のためにスケジュール108される。もちろん、前述のように、ロボットの代わりに、センサーまたはロボットセル中のデバイスがPLC502からのトラフィックの受信側であり得る。
【0043】
図5で示されているシナリオにおける再マッピングの動作について、以下の表1においてさらに説明する。PLC502からの、ソースインターフェースデバイス504によって受信されたIPパケットは、第1のロボット508のアドレス、たとえば120.100.1.10/1000を含んでいる。PLC502と第1のロボット508とは同じローカルネットワークにおいて動作する。ソースインターフェースデバイス504は、ローカルネットワークからのIPアドレスを宛先インターフェースデバイス506のIPアドレス、たとえば10.10.10.2/1000に再マッピングし、このIPアドレスを用いて、パケットが4Gまたは5G無線通信ネットワークを介してソースから宛先インターフェースデバイスに送信される。ただ1つのロボット508が宛先インターフェースデバイス506に接続されているので、ポート番号の再マッピングを実行する必要はない。したがって、10000の値はすべてのインターフェース上で使用される。これは表1の右側(TX側)に示されている。
【0044】
図6は、3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイス506が複数の被制御デバイス508、510、512に接続されている、開示されたソリューションの実際的な展開を示す。この実施形態における方法は、再マッピング106およびカプセル化104の動作中に、宛先インターフェースデバイス506のIPアドレスに、トラフィックをそれぞれの被制御デバイスにルーティングするためのポート番号を追加する動作106-1および104-1を含む。
【0045】
図6に示されているシナリオにおける再マッピングの動作は、
図5と表1とに関して上記で説明した動作と同様である。差異は以下の表2に説明されている。
【0046】
最初に、ソースインターフェースデバイス504によってPLC502から受信されたIPパケットは、宛先インターフェースデバイス506に接続された3つのロボット508、510および512のアドレス指定、たとえば120.100.1.10/1000、120.100.1.11/1000および120.100.1.12/1000を含んでいる。これらのIPアドレスは、次いで、宛先インターフェースデバイス506の無線ネットワークインターフェースのIPアドレス、たとえば10.10.10.2に再マッピングされるが、トラフィックのこれらの3つの別個のストリームを区別するために、それらは異なるポート番号を使用し、各ポート番号は、宛先インターフェースデバイス506に接続されたロボットのうちの1つを識別する。IPアドレスは10.10.10.2/5000、10.10.10.2/5001および10.10.10.2/5002に再マッピングされる。これらの再マッピングされたIPアドレスを用いて、パケットは4Gまたは5G無線通信ネットワークを介してソースから宛先インターフェースデバイスに送信される。表2、
図6および上記の説明に示されているように、いくつかのロボットが単一のインターフェースデバイスに接続されているとき、ポート番号は再マッピングされる。
【0047】
上記の例では、PLCから単一のロボットまたは複数のロボットへのトラフィックの送信について説明したが、同じソリューションは、トラフィックが、単一のロボットから単一のPLCに、および1つのインターフェースデバイスに接続された複数のロボットから、単一のインターフェースデバイスに接続された複数のPLCに進むシナリオに等しく適用可能である。また、ロボットの代わりに、別の被制御デバイス、たとえば、センサーまたはロボットセル中の任意の他のデバイスが、
図5および
図6に示されたシナリオにおいて実装され得る。
【0048】
図7は、ローカルネットワーク中のネイティブイーサネットトラフィックのハンドリング、特に、4Gまたは5Gネットワークを介した送信のためのネイティブイーサネットトラフィックのカプセル化を示す。
図7に示された例示的なネットワークは、
図6に示されたものと同じであるが、明快のために、IPアドレス指定の詳細のうちのいくつかは削除されている。
【0049】
ソースインターフェースデバイス502はイーサネット側でブリッジ(またはスイッチ)のように動作し、そのことは、ソースインターフェースデバイス502が、宛先MACアドレスに関わらず、すべての着信トラフィックを受け付けることを意味する。このようにして、フレーム中の宛先MACアドレスは他方の側のロボットのうちの1つに直接設定され得る。簡潔のために、ここでは、第2のロボット510に宛てられたネイティブイーサネットトラフィックのみについて考える。第2のロボット510は、MACアドレスMAC_2をもつネットワークインターフェースを使用する。PLC502は、MAC_2アドレスを含むイーサネットフレーム702をソースインターフェースデバイス504に送ることによって第2のロボット510にネイティブイーサネットトラフィックを送信する。
【0050】
ソースインターフェースデバイス502は、カプセル化解除機能に割り当てられたポート番号と一緒に、宛先インターフェースデバイス506の無線ネットワークインターフェースのIPアドレス、たとえば10.10.10.2/6001を含んでいるIPヘッダを取り付けることによってイーサネットフレームのカプセル化を実行する。これは、4Gまたは5Gネットワークを介して宛先インターフェースデバイス506に向かって送信されるIPパケット704を形成する。
【0051】
イーサネットフレームおよびカプセル化されたイーサネットフレームは、明快および簡潔のために簡略化された形態で
図7に示されている。カプセル化の概念を示す他の方法も可能であるが、それらは本開示の教示を変更しない。
【0052】
上記では、一方の側にただ1つのPLCがあり、他方の側に1つのロボットがある単純な状況について説明する。1つのPLCと複数のロボットとがあるシナリオでは、カプセル化解除の後に、IPヘッダが削除され、イーサネットフレームが、次いで、MACアドレス、
図7に示された実施形態ではMAC_1、MAC_2およびMAC_3に基づいてそれぞれのロボットに転送されるので、カプセル化プロセスは、単一のIPアドレスと、カプセル化解除機能に割り当てられた単一のポート番号とを使用し得る。一方の側にいくつかのPLCがあるシナリオでは、それぞれのいくつかのカプセル化解除機能のために使用されるいくつかのポート番号があり得る。代替的に、異なるカプセル化解除機能は、たとえば、VxLANカプセル化の場合のように、カプセル化/カプセル化解除機能に割り当てられたカプセル化IDによって識別され得る。VxLANは標準化文書RFC7348-「Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks」において詳細に説明されている。また別の代替実施形態では、4G/5G無線ネットワークの一方の側にいくつかのPLCがあり、他方の側にいくつかのロボットがあるシナリオでさえ、IPヘッダがカプセル化解除機能によって削除されると、次いで、あらわにされたMACアドレスが、イーサネットフレームをそれの宛先ロボットに転送するために使用されるので、単一のカプセル化解除機能(およびこのカプセル化解除機能に割り当てられた単一のポート番号)が使用され得る。
【0053】
一実施形態では、カプセル化する動作は、IPヘッダに、カプセル化動作に関連する識別子(ID)を追加すること104-2を含む。VxLANカプセル化の場合、カプセル化IDは、VxLANネットワーク識別子またはVNIと呼ばれ、VxLANヘッダ(すなわち、カプセル化中に追加されたヘッダ)中に位置する。これは、
図7の要素704において極めて簡略化された形態で示されている。代替実施形態では、カプセル化の他の方法、たとえば、OpenVPNまたはIPsecのような、VPNを使用する方法が使用され得る。これらの方法では、データは、適切なヘッダをもつIPパケット(TCP、UDP)にカプセル化される。VxLANと比較した主要な差異は、VPNベースのカプセル化において使用される暗号化であり、それは、VxLANと比較してVPNベースのカプセル化の複雑さを増加させる。
【0054】
ソースインターフェースデバイスによってPLCから受信されるトラフィックはIPトラフィックとイーサネットとの混合を含む。好ましい実施形態では、イーサネットは、工業イーサネット、たとえば、Profinet、EtherCATなどである。好ましい実施形態では、スプリットする動作102は、IPヘッダをもつパケットを第2の経路に転送することと、残りのパケットを第1の経路に転送することとを含む。このようにして、IP再マッピングのためのトラフィックはIPカプセル化のためのトラフィックから分離される。
【0055】
好ましい実施形態では、スケジュールする動作108は設定および管理トラフィックよりもリアルタイム制御トラフィックを優先させる。一般に、スプリットの後に第1の経路上に存在するネイティブイーサネットトラフィックは、最も高い優先度を有するが、スプリットの後に第2の経路上に存在するTCP/UDPは、通常、管理および監視目的のために使用され、したがってより低い優先度を有する。いくつかのタイプのスケジューリング機構がこの目的のために採用され得る。一実施形態では、重み付きラウンドロビン(Weighted Round Robin)(WRR)がスケジュールのために使用され得る。代替実施形態では、しかしながら、異なるスケジューリング技法、たとえば、重み付き公平キューイング(Weighted Fair Queuing)(WFQ)、厳格優先度(Strict Priority)、優先度ベース欠陥重み付きラウンドロビン(Priority-Based Deficit Weighted Round Robin)およびいくつかの他の技法が使用され得る。
【0056】
スケジューリング機能は、4G/5G無線モジュール306が、ロボットとPLCとをそれらのそれぞれのインターフェースデバイス504および506に接続するローカルネットワークよりも低いアップリンク帯域幅をもつカテゴリーであるときに、ジッタを低減するために有用である(たとえば、LANの100Mbpと比較して、cat.4 LTEドングルは50Mbpsアップリンクレートを有する)。また、カプセル化機構はインターフェースデバイス504、506の最大スループットに影響を及ぼすことができ、スケジューリングは、低いジッタでタイムクリティカルなサービスを処理するために必要とされることに留意することが重要である。
【0057】
スケジューリングは、低い優先度をもつトラフィックよりも、高い優先度をもつトラフィックに優先的処理を与えるので、ソリューションは、トラフィックが送信を待ちながらキューイングされるキューを含む。
【0058】
次に、
図2を参照しながら、3GPP無線ネットワーク520を介した被制御デバイス508、510、512とコントローラ502との間の通信の方法の一実施形態について説明する。本方法は、宛先インターフェースデバイス506において実行され、着信トラフィックを、IP(インターネットプロトコル)パケット中にカプセル化されたネイティブイーサネットトラフィックを搬送する第3の経路と、IPトラフィックを搬送する第4の経路とにスプリットすること202を含む。宛先インターフェースデバイス506は、前に説明したように、好ましい実施形態では4Gまたは5Gネットワークであり得る、3GPP無線ネットワーク520を介してトラフィックを受信する。トラフィックのパケットは、宛先インターフェースデバイス506の3GPP無線ネットワークインターフェースのIPアドレスに対してアドレス指定される。
図5、
図6および
図7に示された例では、このIPアドレスは10.10.10.2である。受信されたパケットは、さらに、宛先インターフェースデバイス506に接続された異なるロボット508~512のためのトラフィック、ならびにカプセル化されたイーサネットフレームを含んでいるトラフィックを区別することを可能にする、ポート番号に対してアドレス指定される。カプセル化されたイーサネットフレームを搬送する受信されたトラフィックの部分は、カプセル化解除機能に割り当てられたポート番号を使用する。さらに、いくつかのタイプのカプセル化のために、カプセル化されたイーサネットフレームを搬送するトラフィックのヘッダはカプセル化ID(たとえば、VxLANカプセル化の場合はVNI)を含む。VxLANカプセル化が使用される場合、カプセル化されたネイティブイーサネットトラフィックは、VxLAN識別子(VNI)と、VxLANのIPアドレスおよびポートとによって規定される。この場合、トラフィックスプリッタはルータのように挙動する。VxLANに関連付けられたIPアドレスとポートとをもつパケットはカプセル化解除機能に向かってルーティングされるが、IPトラフィックの残りは、システムをキューイングするTCP/UDPに送られる。随意に、トラフィックスプリッタはまた、2つ以上のVxLANのセットアップの場合、VxLAN識別子を検査することができ、状況は一般にPLC側に対応して起こる。したがって、一実施形態におけるスプリットする動作は、カプセル化解除機能に割り当てられたポート番号をもつパケットを第3の経路上に(およびカプセル化解除機能に)転送し得るか、または、代替実施形態では、スプリットする動作は、カプセル化ID(たとえばVNI)を含んでいるIPパケットを第3の経路に転送し得る。トラフィックの残りの部分は第4の経路に転送される。
【0059】
トラフィックがスプリットされると、第3の経路上の部分はカプセル化解除され204、IPヘッダを削除した後に元のネイティブイーサネットフレームが生成される。VxLANまたはVPNベースのカプセル化を使用する実施形態でも、対応するヘッダは削除されなければならず、VPNの場合、データも解読されるべきである。第4の経路上で、少なくとも1つの被制御デバイスまたはコントローラのIPアドレスをもつ受信されたパケットのIPアドレスの再マッピング206が実行される。
図5~
図7に示されたシナリオでは、トラフィックはPLCコントローラ502からロボット508~512に流れるが、ソリューションは、トラフィックがロボット508~512からPLCコントローラ502に流れる場合同様に働く。
【0060】
トラフィックが宛先インターフェースデバイス506からロボット508またはロボット508~512に送信される210前に、トラフィックはスケジュールされる208。好ましい実施形態では、スケジュールする動作208は設定および管理トラフィックよりもリアルタイム制御トラフィックを優先させる。
【0061】
図5に示されているシナリオ(宛先インターフェースデバイス506に接続された単一のロボット508)における再マッピングする動作は、前に提示した表1(RX側)において説明される。ネイティブIPパケット(すなわち、カプセル化されたイーサネットフレームを搬送しないIPパケット)は宛先インターフェースデバイス506の無線ネットワークインターフェースのIPアドレス10.10.10.2と、ポート番号10000とともに受信される。IPアドレス10.10.10.2はロボット508のローカルIPアドレス120.100.1.10に再マッピングされる。宛先インターフェースデバイスに接続されたロボットはただ1つであり、ソースインターフェースデバイスから宛先インターフェースデバイスに送られるトラフィックを区別する必要がなかったので、ポート番号は同じままである。
【0062】
図6に示されているシナリオにおける再マッピングする動作は、
図5と表1とに関して上記で説明した動作と同様である。差異は、前に提示した表2(RX側)において説明される。3GPP無線ネットワークから宛先インターフェースデバイス506に到着したパケットは、宛先インターフェースデバイス506の無線ネットワークインターフェースのIPアドレス10.10.10.2に対してアドレス指定され、さらに、宛先インターフェースデバイス506に接続されたロボット508~512に割り当てられた異なるポート番号、すなわち、10.10.10.2/5000、10.10.10.2/5001および10.10.10.2/5002によって区別される。このシナリオでは、無線インターフェース上で使用されたIPアドレスとポート番号とは、LANにおいてロボット508~512によって使用されるIPアドレスとポート番号と、すなわち、120.100.1.10/1000、120.100.1.11/1000および120.100.1.12/1000とに再マッピングされる。
図6に示されたこれらの3つのロボットに向けられたトラフィックはスイッチ602によってそれの受信側に転送される。スイッチ602は
図6および
図7に別個の構成要素として示されており、スイッチ602の機能は、すべてのイーサネットポートを一緒に接続し、トラフィックを意図された宛先に転送することである。代替実施形態では、インターフェースデバイス506は各ロボットのためのポートを有し得、スイッチ機能は、その場合、インターフェースデバイス506内の、スケジューラの後に位置するであろう。
【0063】
次に、
図3を参照しながら、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイス300の実施形態について説明する。この実施形態では、インターフェースデバイス300は、ソースインターフェースデバイス(たとえば、
図5~
図7におけるデバイス504)として動作するように適合される。好ましい実施形態では、インターフェースデバイス300は処理回路302とメモリ304とを備える。メモリ304は、インターフェースデバイス300が、着信トラフィックを、ネイティブイーサネットトラフィックを搬送する第1の経路と、IP(インターネットプロトコル)トラフィックを搬送する第2の経路とにスプリットするように動作可能であるように、処理回路302によって実行可能な命令を含んでいる。インターフェースデバイス300はまた、IPトラフィックのパケットのIPアドレスを、3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイスのIPアドレスに対して再マッピングし、ネイティブイーサネットトラフィックを、3GPP無線ネットワークのリモートエンドにある宛先インターフェースデバイスのIPアドレスをもつIPトラフィック中にカプセル化するように動作可能である。さらに、インターフェースデバイス300は、3GPP無線ネットワークを介した宛先インターフェースデバイスへの送信のために第1の経路と第2の経路とからのIPトラフィックをスケジュールするように動作可能である。
【0064】
処理回路302は単一のオフザシェルフ(off-the-shelf)プロセッサまたは複数のオフザシェルフプロセッサであり得、処理回路302はまた、専用特定用途向け集積回路(ASIC)、あるいはデジタルまたはアナログハードウェア構成要素または専用プロセッサを含む任意の他のタイプの処理回路であり得る。同様に、メモリ304は、知られている技術のうちの1つにおいて生成される1つまたは複数のメモリモジュールであり得る。
【0065】
インターフェースデバイス300は、ソースインターフェースデバイスとして動作しているとき、
図1に示され、上記で説明した方法の様々な実施形態を実行するように動作可能である。
【0066】
次に、また別の実施形態における、3GPP無線ネットワークを介した被制御デバイスとコントローラとの間の通信のためのインターフェースデバイス300について説明する。このインターフェースデバイスの一実施形態は
図3に示されている。この実施形態では、インターフェースデバイス300は、
図5~
図7に示された宛先インターフェースデバイス506として動作するように適合される。インターフェースデバイス300は処理回路302とメモリ304とを備える。上記で説明したように、処理回路およびメモリは様々な技術において単一のモジュールまたは複数のモジュールとして実現され得る。メモリ304は、インターフェースデバイス300が、着信トラフィックを、IP(インターネットプロトコル)パケット中にカプセル化されたネイティブイーサネットトラフィックを搬送する第3の経路と、IPトラフィックを搬送する第4の経路とにスプリットするように動作可能であるように、処理回路302によって実行可能な命令を含んでいる。インターフェースデバイス300はまた、第4の経路上のIPトラフィックのパケットのIPアドレスを、少なくとも1つの被制御デバイスまたはコントローラのIPアドレスに対して再マッピングし、第3の経路上のIPトラフィックからのネイティブイーサネットトラフィックをカプセル化解除するように動作可能である。さらに、インターフェースデバイス300は、インターフェースデバイスに接続された少なくとも1つの被制御デバイスまたはコントローラへの送信のために第3の経路と第4の経路とからのトラフィックをスケジュールするように動作可能である。
【0067】
インターフェースデバイス300は、ソースインターフェースデバイスとして動作しているとき、
図2に示され、上記で説明した方法の様々な実施形態を実行するように動作可能である。
【0068】
上記では、インターフェースデバイス300について、好ましい実施形態においてソースインターフェースデバイスとしておよび宛先インターフェースデバイスとして動作するように適合されるとして別個に説明したが、インターフェースデバイスは、両方の機能、すなわちソースインターフェースデバイスと宛先インターフェースデバイスの機能を実行するように適合される。実際的な展開では、トラフィックは両方向においてPLCとロボットとの間で交換され、したがって、PLCに接続されたインターフェースデバイスは、PLCからロボットへのトラフィックを受信し、また、ロボットからPLCへのトラフィックを受信する。ソースと宛先の機能を組み合わせるインターフェースデバイス300の一実施形態が
図4に示されている。
図4に示された機能モジュールは、前に説明したそれらの様々な実施形態における方法の動作に対応する。一実施形態では、これらの機能モジュールは処理回路302中でソフトウェアによって実装され得るか、または、代替的に、それらは、(たとえば、処理回路がASICデバイスとして実装されるときに)専用のハードウェア中で実装され得る。
【0069】
このソリューションの利点のうちの1つは、PLCおよびロボットが部分的にまたは完全にイーサネット(たとえばProfinet、EtherCAT、イーサネットIP)に基づく工業プロトコルを通信のために使用する場合でも、インターフェースデバイスおよび方法が産業シナリオにおいて4G接続または5G接続の最適な使用を可能にすることである。言い換えれば、本ソリューションは、レガシーPLCとロボット上の変更を必要とすることなしに4G接続および/または5G接続の導入を可能にする。モバイル無線ネットワークによる通信は自動的にセットアップされ、ティアダウンされ、工業トラフィックトランスポートがそれの特性に基づいて最適化される。端末側で、インターフェースデバイス306はまた、4G/5G無線回路306-2と、関係するソフトウェアとを含む。これは
図3aに示されている。
【0070】
インターフェースデバイス300は、専用送信および受信モジュール306-1を使用した、4G/5Gネットワークを介した工業イーサネットトラフィックの送信および受信を可能にする。一実施形態では、モジュール306-1のTx部分は、PLC(またはロボット)からの工業イーサネットトラフィックを受信し、トラフィックをスプリットして、TCP/UDPトラフィックとネイティブイーサネットトラフィックとに分離し、それらを4Gまたは5G無線ネットワークを介してロボットデバイス(またはPLC)に送り、上記で説明したように、イーサネットトラフィックをIP中のカプセル化し、ネイティブIPトラフィックを再マッピングする。
【0071】
動作中に、インターフェースデバイスは、通信をセットアップする過程においてサーバとしてまたはクライアントとして稼働し得る。これは
図8に示されている。一般的な実施形態では、PLCに取り付けられたインターフェースデバイス300はサーバ1504として稼働するが、ロボットセル中のロボット、センサー、デバイスなどに接続された他のインターフェースデバイスはクライアント1506として動作する。新しいインターフェースデバイスが、ネットワークに接続することを希望するとき、インターフェースデバイスは、最初に、無線ネットワークに接続すること802を試みる。これが成功した場合、インターフェースデバイスは、特定のアドレスにあるサーバ1504に到達することを試みる。後者は、プリセットされ得るか、またはDNSサービスに接続して獲得され得る。クライアント1506は、少なくとも無線ネットワーク中のそれのIPアドレスを情報として含む接続要求をサーバ1504に送る804。サーバ1504は、その場合、クライアント1506を認証することができ、カプセル化された経路を作成するためのローカル設定を設定する806。次いで、サーバ1504は、カプセル化されたトラフィックフローを識別するための情報(たとえばVxLAN識別パラメータ)を含む動作の結果をクライアント1506に返送する808。この後、インターフェースデバイスと、インターフェースデバイスの接続されたPLCおよびロボットとが4Gまたは5G無線ネットワークを介して互いに通信する810。
【0072】
クライアントインターフェースデバイス1506の切断は、
図8に示されたプロシージャに従う。クライアントインターフェースデバイス1506が切断要求を送り812、それに応答して、サーバインターフェースデバイス1504は、クライアントインターフェースデバイス1506に向かうローカル接続をティアダウンし814、次いで切断確認を送る816。クライアント側では、クライアントインターフェースデバイス1506が、サーバインターフェースデバイス1504に向かうローカル接続をティアダウンし818、次いで無線ネットワークから切断する820。
【0073】
一実施形態では、インターフェースデバイスの無線部分は、無線経路上に1:1保護方式を実装する第2の無線デバイスを使用して保護され得る。第1の無線回路306-2、または第1の無線回路306-2が接続されている無線ネットワークの障害の場合、保護プロシージャは、トラフィックを、第1の無線回路306-2と同じ4Gまたは5G無線ネットワークまたは異なる無線ネットワークに接続され得る第2の無線回路306-3に切り替え得る。
【0074】
ここで説明される保護方式の1つの実際的な態様は、第2の無線回路306-2および306-3に割り当てられたIPアドレスに関する。第2の無線回路306-3は、第1の無線回路306-2とは異なるIPアドレスによって識別される。スイッチオーバーが行われると、新しいカプセル化が作成され、表中のIPアドレスが変更される。VxLANカプセル化の場合、新しいVxLANネットワーク識別子(VNI)が使用される。
【0075】
上記で説明したそれらの様々な実施形態における方法およびインターフェースデバイスは、3GPP無線ネットワーク(特に第4世代および第5世代)の豊富な特徴の恩恵を受ける、被制御デバイスと被制御デバイスのコントローラとの間の通信を可能にする。本明細書で説明し、図に示されたソリューションはたいていPLCからロボット(または複数のロボット)へのトラフィックの方向に基づくが、同じソリューションは、反対方向、すなわち、ロボット(または複数のロボット)からPLCまたは(複数のPLC)に移動するトラフィックに適用可能である。
【0076】
この文書は、PLCコントローラとロボットとの例を使用することによって本発明の実施形態を開示するが、特許請求の範囲において規定されるこのソリューションは、他のタイプのコントローラと被制御デバイスとに、たとえば、医療処置のための外科用デバイスと、外科用デバイスを制御するためのコントローラとに等しく適用され得る。上記で説明した本発明の実施形態の他の適用例は、化学プロセスおよび他の工業プロセスの制御を含む。