JP2022125972A - マルチルート通信システムおよびルート選択システム - Google Patents

Abstract

【課題】すでに確立された通信セッションの切断を引き起こすことなく、短時間のうちに通信へのＱｏＳレベルの割り当てを動的に変更する。【解決手段】本明細書に記載されている例示の実装形態は、基礎となる装置のターゲットアプリケーションと対応するサーバとの通信セッションの管理に関するものである。このような例示の実装形態は、ターゲットアプリケーションの複数の状態（各々が遅延要件に対応する）を取得し、各々が異なるネットワークスライスを使用して複数の状態を満たす複数の通信セッションを確立し、現在の状態を満たすネットワークスライスを指定して、指定されたネットワークスライスを使用してデータを送信することを含む。ターゲットアプリケーションの状態が変更されると、通信セッションやネットワークスライスも新しい状態を満たす別の通信セッションに変更される。【選択図】図７

Description

本開示は、一般的には通信ネットワークに関するものであり、より具体的には、ルート選択を伴うマルチルート通信システムに関するものである。

近年、工場で行われるプロセスの高度化に伴い、工場に設置されたデバイス間の通信ネットワークの重要性が高まっている。遅延や速度など、通信に求められる条件は、その通信を通して実行されるプロセスによって異なる。また、通信資源は有限であるため、デバイス間の通信には必要最低限の通信資源（ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）レベルなど）を割り当てることが重要になる場合がある。

関連技術の実装形態には、送信されるデータの内容に応じてＱｏＳレベルを通信に動的に割り当てるシステムを含むことができる。しかし、ＱｏＳ割り当て変更の実装には長い時間がかかる場合がある。ＱｏＳの割り当てを動的に変更すると、すでに確立された通信セッションが切断される可能性がある。

米国特許出願公開第２０２０／００３６６５２号明細書

本明細書に記載の例示の実装形態では、すでに確立された通信セッションの切断を引き起こすことなく、短時間のうちに通信へのＱｏＳレベルの割り当てを動的に変更するシステムおよび方法について説明する。特に、例示の実装形態では、製造現場の各デバイスに最適なＱｏＳレベルの割り当てを円滑に進めることができる。

本開示の態様は、複数の装置を含むシステムの管理方法であって、複数の装置の各々は、サーバからの命令に基づいて、対応するターゲットアプリケーションを管理し、前記複数の装置は、ネットワークを通してサーバと通信し、前記方法は、複数の装置の各々について、対応するターゲットアプリケーションの複数の状態を取得することであって、前記複数の状態の各々は、遅延要件に対応する、取得することと、複数の通信セッションを確立することであって、前記複数の通信セッションの各々が、ネットワーク（ＮＷ）スライスおよび関連するポートによって円滑に進み、前記複数の通信セッションの各々は、前記複数の状態のうちの対応する１つを満たすように構成されている、確立することと、前記複数の通信セッションのうち、対応するターゲットアプリケーションの現在の状態を満たす１つを指定することと、前記複数の装置の各々について、前記複数の通信セッションのうち前記指定された１つのセッションを通してデータを送信することと、前記対応するターゲットアプリケーションを前記現在の状態から別の状態へ変更するために、前記複数の通信セッションの１つを、前記別の状態を満たすように構成された前記複数の通信セッションの別の１つに変更することと、を含む。

本開示の態様は、複数の装置を含むシステムを管理するためのコンピュータプログラムであって、前記複数の装置の各々は、サーバからの命令に基づいて、対応するターゲットアプリケーションを管理し、前記複数の装置は、ネットワークを通してサーバと通信し、前記コンピュータプログラムは、前記複数の装置の各々について、対応するターゲットアプリケーションの複数の状態を取得することであって、前記複数の状態の各々は、遅延要件に対応する、取得することと、数の通信セッションを確立することであって、前記複数の通信セッションの各々が、ネットワーク（ＮＷ）スライスおよび関連するポートによって円滑に進み、前記複数の通信セッションの各々は、前記複数の状態のうちの対応する１つを満たすように構成されている、確立することと、前記複数の通信セッションのうち、対応するターゲットアプリケーションの現在の状態を満たす１つを指定することと、前記複数の装置の各々について、前記複数の通信セッションのうち前記指定された１つのセッションを通してデータを送信することと、前記対応するターゲットアプリケーションを前記現在の状態から別の状態へ変更するために、前記複数の通信セッションの１つを、前記別の状態を満たすように構成された前記複数の通信セッションの別の１つに変更することと、を含む。前記命令は、非一時的なコンピュータ可読媒体上に格納でき、１つ以上のプロセスによって実行されるように構成されている。

本開示の態様は、複数の装置を含むシステムを管理するためのコンピュータデバイスであって、複数の装置の各々は、サーバからの命令に基づいて、対応するターゲットアプリケーションを管理し、前記複数の装置は、ネットワークを通して前記サーバと通信し、前記コンピュータデバイスは、複数の装置の各々について、対応するターゲットアプリケーションの複数の状態を取得することであって、前記複数の状態の各々は、遅延要件に対応する、取得することと、複数の通信セッションを確立することであって、前記複数の通信セッションの各々は、ネットワーク（ＮＷ）スライスおよび関連するポートによって円滑に進み、前記複数の通信セッションの各々は、前記複数の状態のうちの対応する１つを満たすように構成されている、確立することと、前記複数の通信セッションのうち、対応するターゲットアプリケーションの現在の状態を満たす１つを指定することと、前記複数の装置の各々について、前記複数の通信セッションのうち前記指定された１つのセッションを通してデータを送信することと、前記対応するターゲットアプリケーションを前記現在の状態から別の状態へ変更するために、前記複数の通信セッションの１つを、前記別の状態を満たすように構成された前記複数の通信セッションの別の１つに変更することと、を行うように構成されたプロセッサを含む。

本開示の態様は、複数の装置を含むシステムであって、前記複数の装置の各々は、サーバからの命令に基づいて、対応するターゲットアプリケーションを管理し、前記複数の装置は、ネットワークを通して前記サーバと通信し、前記システムは、前記複数の装置の各々について、対応するターゲットアプリケーションの複数の状態を取得する手段であって、前記複数の状態の各々は、遅延要件に対応する、取得する手段と、複数の通信セッションを確立する手段であって、前記複数の通信セッションの各々は、ネットワーク（ＮＷ）スライスおよび関連するポートによって円滑に進み、前記複数の通信セッションの各々は、前記複数の状態のうちの対応する１つを満たすように構成されている、確立する手段と、前記複数の通信セッションのうち、対応するターゲットアプリケーションの現在の状態を満たす１つを指定する手段と、前記複数の装置の各々について、前記複数の通信セッションのうち前記指定された１つのセッションを通してデータを送信する手段と、前記対応するターゲットアプリケーションを前記現在の状態から別の状態へ変更するために、前記複数の通信セッションの１つを、前記別の状態を満たすように構成された前記複数の通信セッションの別の１つに変更する手段と、を含む。

例示の実装形態が適用され得るシステムアーキテクチャを示す図である。 例示の実装形態による、ネットワーク管理サーバの機能ブロック図である。 例示の実装形態による、アプリケーション要件テーブルの一例を示す図である。 例示の実装形態による、ＱｏＳテーブルの一例を示す図である。 例示の実装形態によるフィールドサーバの機能ブロック図である。 例示の実装形態による、ＭＥＣサーバの機能図である。 例示の実装形態による、ルート管理サーバのフローチャートである。 例示の実装形態による、ルート管理クライアント５０３のフローチャートである。 例示の実装形態による、サーバセッションテーブルの反復の一例を示す図である。 例示の実装形態による、クライアントセッションテーブルの反復の一例を示す図である。 例示の実装形態による、エリア緊急状態テーブルを示す図である。 例示の実装形態による、アプリケーション要件テーブルを示す図である。 いくつかの例示の実装形態で使用するのに好適な、例示のコンピュータデバイスを備えた例示のコンピューティング環境を示す図である。

以下の詳細な説明は、本出願の図面および例示の実装形態の詳細を提供するものである。図面間の冗長要素の参照番号および説明は、明確のため、省略する。本明細書全体を通して使用される用語は、例として提供されるものであり、限定することを意図するものではない。例えば、「自動」という用語の使用は、本出願の実装形態を実施する当業者の所望の実装形態に応じて、実装形態のいくつかの態様では、ユーザまたは管理者の制御を含む完全自動または半自動の実装を含んでいてもよい。選択は、ユーザインターフェースまたは他の入力手段を通してユーザによって行われ、または所望のアルゴリズムを通して行うことができる。本明細書で説明する例示の実装形態は、単独で、または組み合わせて利用することができ、例示の実装形態の機能性は、所望の実装形態に従った任意の手段を通して実装することができる。

第１の例示の実装形態では、ターゲットアプリケーションの複数の状態を取得することができるシステムおよび方法があり、状態の各々は、遅延要件に対応している。このようなシステムおよび方法は、複数の通信セッションを確立することができ、その各々は、異なるネットワーク（ＮＷ）スライス（その各々は、異なるサービス水準合意（ＳＬＡ）を有し得る）を使用することによって、複数の状態を満たす。このシステムおよび方法は、現在の状態を満たすＮＷスライス／ポートを指定し、指定したＮＷスライスを用いてデータを送信することができる。第２の状態への変化を検出するため、そのようなシステムおよび方法は、第２の状態を満たすＮＷスライス／ポートに変更することができる。

図１は、例示の実装形態が適用され得るシステムアーキテクチャを示す。このシステムには、ネットワーク管理サーバ１０１、フィールドサーバ１０２、１０３、センサ１０７、１０８、アクチュエータ１０９、１１０、ＭＥＣ（モバイルエッジコンピューティング）サーバ１０４、１０５、および通信ネットワーク１０６を含むことができる。センサ１０７、１０８とアクチュエータ１０９、１１０は、フィールドサーバ１０２、１０３に接続されている。フィールドサーバ１０２、１０３、ＭＥＣサーバ１０４、１０５、およびネットワーク管理サーバは、通信ネットワーク１０６を通して相互に接続されている。

センサ１０７、１０８とアクチュエータ１０９、１１０は、プラントの製造プロセスを実行するために使用される。フィールドサーバ１０２、１０３は、センサ１０７、１０８で取得したセンサデータをＭＥＣサーバ１０４、１０５に送信し、ＭＥＣサーバ１０４、１０５から受信した制御データに応じてアクチュエータ１０９、１１０を制御する。ＭＥＣサーバ１０４、１０５は、通信ネットワークを通してフィールドサーバ１０２、１０３からセンサデータを受信し、センサデータに応じた制御データを生成し、通信ネットワーク１０６を通してフィールドサーバに制御データを送信する。通信ネットワーク１０６は、ネットワークスライシングなどのＱｏＳ機能をサポートしている。５Ｇは、ＱｏＳ機能をサポートする通信ネットワークの一例である。ネットワーク管理サーバ１０１は、通信ネットワーク１０６でどのようなＱｏＳ制御が行われているかを示すＱｏＳ構成情報と、フィールドサーバ１０２、１０３やＭＥＣサーバ１０４、１０５で実行されるアプリケーションの通信要件を管理する。

図２は、例示の実装形態による、ネットワーク管理サーバ１０１の機能ブロック図である。ネットワーク管理サーバ１０１には、アプリケーション要件テーブル２０１とＱｏＳテーブル２０２がある。アプリケーション要件テーブル２０１は、アプリケーション名、アプリケーションが動作するポート番号、アプリケーションが遷移することができる状態、各状態においてアプリケーションが要求する通信品質のマッピングを格納している。ＱｏＳテーブル２０２には、ネットワークスライス識別子（ＩＤ）の保証と、ネットワークスライスが提供する通信遅延の保証と、ネットワークスライスにルーティングされるデータが使用するポート番号とのマッピングが格納されている。

図３は、例示の実装形態による、アプリケーション要件テーブル２０１の一例を示す図である。アプリケーション要件テーブル２０１には、アプリケーション名３０１、ポート番号３０２、アプリケーション状態３０３、遅延要件３０４が含まれる。図３の例では、「ねじ回し」というアプリケーションがポート４０００１上で動作し、「緊密な連携」と「ノーマル」を含む２つの状態を有する。アプリケーション状態が「緊密な連携」である場合、アプリケーションの通信遅延は１０［ｍｓ］未満である必要がある。アプリケーション状態が「ノーマル」の場合、アプリケーションの通信遅延は１００［ｍｓ］未満である必要がある。

アプリケーション「部品切削」では、アプリケーションはポート４０００２で動作し、「高精度モード」と「低精度モード」の２つの状態がある。アプリケーション状態が「高精度モード」の場合、アプリケーションの通信遅延は５［ｍｓ］未満である必要がある。アプリケーション状態が「低精度モード」の場合、アプリケーションの通信遅延は５０［ｍｓ］未満である必要がある。

図４は、例示の実装形態によるＱｏＳテーブル２０２の例を示したものである。ＱｏＳテーブル２０２には、ネットワークスライスＩＤ４０１、遅延４０２、ポート番号４０３が含まれている。ネットワークスライスとは、特定の通信遅延が保証された仮想通信ネットワークのことである。図４の例では、ネットワークスライスが「１」の場合、保証される遅延の値は１［ｍｓ］である。ポート番号が５０００１である通信パケットは、ネットワークスライス１を経由する。

図５は、例示の実装形態による、フィールドサーバ１０２の機能ブロック図である。フィールドサーバ１０２は、クライアントアプリケーション５０１、クライアントセッションテーブル５０２、ルート管理クライアント５０３を含むことができる。アプリケーション５０１は、ＭＥＣサーバ１０４で動作するサーバアプリケーションと通信することにより、製造プロセスを実行するために使用される。クライアントセッションテーブル５０２は、ルート管理クライアント５０３によってどのような通信セッションを確立し、参照しているかを格納するために使用される。ルート管理クライアント５０３は、アプリケーションの通信要件を満たす通信セッションを確立し、適切なセッションを通してデータをルーティングする。なお、クライアントアプリケーション５０１がルート管理クライアント５０３に接続されていれば、クライアントアプリケーションは必ずしもフィールドサーバ１０２内になくてもよい。例えば、イーサネットケーブルを介してフィールドサーバ１０２をルーティングするために接続されているコンピュータの中であってもよい。その他の構成についても、所望の実装形態に応じて可能である。

図６は、例示の実装形態によるＭＥＣサーバ１０４の機能図を示す。ＭＥＣサーバ１０４は、サーバアプリケーション６０１、サーバセッションテーブル６０２、ルート管理サーバ６０３、アプリケーション状態検出器６０４を含む。サーバアプリケーション６０１は、クライアントアプリケーション５０１との通信により、製造プロセスを実行するために使用される。ルート管理サーバ６０３は、アプリケーションの通信要件を満たす通信セッションを確立し、適切なセッションを通してデータをルーティングする。アプリケーション状態検出器は、アプリケーションの現在の状態を検出し、その状態をルート管理サーバ６０３に通知する。サーバセッションテーブル６０２は、ルート管理サーバ６０３によってどのような通信セッションを確立し、参照しているかを格納するものである。なお、サーバアプリケーション６０１がルート管理サーバ６０３に接続されていれば、サーバアプリケーション６０１は必ずしもＭＥＣサーバ１０４内になくてもよい。例えば、イーサネットケーブルを介してＭＥＣサーバ１０４に接続されているコンピュータの中であってもよい。クライアントアプリケーション５０１とサーバアプリケーション６０１は互いに連携して動作しており、同じアプリケーション状態を共通して有している。その他の構成についても、所望の実装形態に応じて可能である。

図７は、例示の実装形態による、ルート管理サーバ６０３のフローチャートを示す。ルート管理サーバ６０３が動作を開始すると、ステップ７０１に進む。ステップ７０１では、ルート管理サーバ６０３は、セッションテーブルを参照して、ＭＥＣサーバで実行または割り当てられているアプリケーションの名称を取得し、アプリケーション要件テーブルを参照して、そのアプリケーションに対応する通信要件を取得する。その後、フローはステップ７０２に進む。

ステップ７０２では、ルート管理サーバは、ＱｏＳテーブルを参照して、アプリケーションの通信要件を満たすポート番号を取得する。その後、フローはステップ７０３に進む。

ステップ７０３では、ルート管理サーバ６０３は、取得したポートとの通信セッションをフィールドサーバ上で確立し、セッション情報をサーバセッションテーブルに格納する。その後、フローはステップ７０４に進む。

ステップ７０４において、ルート管理サーバ６０３がアウトバウンドパケットを検出し、そのパケットのポート番号がサーバセッションテーブルに格納されているポート番号と一致する場合（Ｙｅｓ）、フローは７０５に進む。そうでなければ（Ｎｏ）、フローは７０６に進む。

ステップ７０５において、ルート管理サーバ６０３は、セッションテーブルを参照して、アプリケーションの現在の状態を取得し、アプリケーションの現在の状態に対応するセッションを通してパケットを送信し、検出したパケットのソースポートをセッションテーブルに格納する。その後、フローは７０６に進む。

ステップ７０６において、ルート管理サーバ６０３がインバウンドパケットを検出し、そのパケットのポート番号がサーバセッションテーブルに格納されているものと一致した場合（Ｙｅｓ）、フローはステップ７０７に進む。そうでない場合（Ｎｏ）、フローは７０８に進む。

ステップ７０７では、ルート管理サーバ６０３は、サーバセッションテーブルを参照し、アプリケーションの元のポートにパケットを転送する。その後、フローはステップ７０８に進む。

ステップ７０８において、ルート管理サーバ６０３が、アプリケーション状態変化の通知を受信した場合（Ｙｅｓ）、フローは７０９に進む。そうでない場合（Ｎｏ）、フローは７０４に進む。

ステップ７０９では、ルート管理サーバ６０３は、アプリケーションの現在の状態を、受信したものに更新する。その後、フローは７０４に進む。

図８は、例示の実装形態による、ルート管理クライアント５０３のフローチャートである。ルート管理クライアント５０３が動作を開始すると、フローはステップ８０１に進む。ステップ８０１において、ルート管理クライアント５０３は、セッションテーブルを参照して、フィールドサーバで実行されているアプリケーションの名称を取得し、アプリケーション要件テーブルを参照して、アプリケーションに対する通信要件を取得する。その後、フローはステップ８０２に進む。

ステップ８０２では、ルート管理クライアント５０３は、ＱｏＳテーブルを参照して、アプリケーションの通信要件を満たすポート番号を取得する。その後、ステップ８０３に進む。

ステップ８０３では、ルート管理クライアント５０３は、取得したポートを開放し、ルート管理サーバ６０３からの接続要求を受け付け、クライアントセッションテーブルにセッション情報を格納する。その後、フローはステップ８０４に進む。

ステップ８０４において、ルート管理クライアント５０３が、ポート番号がサーバセッションテーブルに格納されているものと一致するインバウンドパケットを検出した場合（Ｙｅｓ）、その後、フローはステップ８０５に進む。そうでなければ（Ｎｏ）、フローは８０７に進む。

ステップ８０５では、ルート管理クライアント５０３は、クライアントセッションテーブルを参照し、対応するセッションを通して、アプリケーションにパケットを転送する。その後、フローはステップ８０６に進む。

ステップ８０６では、ルート管理クライアント５０３は、アプリケーション状態を、最後のインバウンドパケットが受信されたセッションに関連付けられたものに更新する。その後、フローは８０７に進む。

ステップ８０７において、ルート管理クライアント５０３が、ポートがサーバセッションテーブルに格納されているものと一致するアウトバウンドパケットを検出した場合（Ｙｅｓ）、その後フローは８０８に進む。そうでなければ（Ｎｏ）、その後、フローは８０４に進む。

ステップ８０８では、フローは、セッションテーブルを参照してアプリケーションの現在の状態を取得し、アプリケーションの現在の状態に対応するセッションを通してパケットを送信する。その後、フローは８０４に進む。

ルート管理サーバ６０３の動作フローとルート管理クライアント５０３の動作フローに関するより具体的な例を以下に説明する。本例では、ＭＥＣサーバのサーバセッションテーブルとフィールドサーバのクライアントセッションテーブルに、ネジ打ちアプリケーションが実行アプリケーションとして格納されているものとする。図３に示したアプリケーション要件テーブルと図４に示したＱｏＳテーブルが適用される。本実施例で作成するサーバセッションテーブルとクライアントセッションテーブルをそれぞれ図９と図１０に示す。

まず、ＭＥＣサーバ上のルート管理サーバの運用フローを以下で説明する。

ステップ７０１では、ルート管理サーバは、セッションテーブルを参照して、ＭＥＣサーバで実行されるアプリケーションの名称として、ねじ回しアプリケーション９０１を取得する。その後、ルート管理サーバは、アプリケーション要件テーブル２０１を参照して、ねじ回しの通信要件を取得する。アプリケーション要件テーブル２０１によると、ねじ回しの状態が緊密な連携の場合は１０、ノーマルの場合は１００［ｍｓ］の遅延が必要となる。

ステップ７０２では、ルート管理クライアント６０３は、ＱｏＳテーブルを参照して、遅延が１０および１００［ｍｓ］の場合のポート番号として、それぞれ５０００３および５０００５を取得する。ステップ７０３では、ルート管理サーバ６０３は、図９に示すように、フィールドサーバ上のポート５０００３、５０００５への通信セッションを確立し、セッション情報９０２～９０８をセッションテーブルに記録する。

ステップ７０４では、ルート管理サーバが、宛先ポート番号とソースポート番号がそれぞれ４０００１、１２３４５であるアウトバウンドパケットを検出したものとする。ポート番号は、セッションテーブルに格納されているセッションに対応している。そのため、フローはステップ７０５に進む。ステップ７０５では、アプリケーション状態が「緊密な連携」であるステップを想定している。ルート管理サーバは、アプリケーションの現在の状態として「緊密な連携」９０９を取得し、宛先ポートが５０００３であるセッションを通してパケットを送信する（９０７）。その後、ルート管理サーバは、検出したパケットのソースポートとして１２３４５（９１０）をセッションテーブルに格納し、ステップ７０６に進む。

ステップ７０６では、ルート管理サーバが、ソースポート番号が４０００１であるインバウンドパケットを検出したとする。ソースポート番号は、セッションテーブルに格納されているセッション（９０２）に対応している。したがって、フローはステップ７０７に進む。ステップ７０７において、ルート管理サーバは、セッションテーブルを参照し、ソースポート番号１２３４５を取得し（９１０）、ソースポート番号が１２３４５であるセッションを通して、アプリケーションにパケットを転送する。その後、ルート管理サーバは、ステップ７０８に進む。

ステップ７０８では、ルート管理サーバが「ノーマル」の状態通知を受信することを想定している。ルート管理サーバは、ステップ７０４に進み、アプリケーションの現在の状態を「ノーマル」に更新する。

フィールドサーバでの運用フローは以下のようになる。ステップ８０１において、ルート管理クライアントは、セッションテーブルを参照して、フィールドサーバで実行されるアプリケーションの名称として、ねじ運転アプリケーション１００１を取得する。その後、アプリケーション要件テーブルを参照して、ねじ回しのための通信要件を取得する。アプリケーション要件管理テーブルによると、ねじ回しの状態が緊密な連携の場合は１０、ノーマルの場合は１００［ｍｓ］の遅延が必要となる。

ステップ８０２では、ルート管理クライアントは、ＱｏＳテーブルを参照して、遅延が１０および１００［ｍｓ］の場合のポート番号として、それぞれ５０００３および５０００５を取得する。ステップ８０３では、ルート管理クライアントは、５０００３と５０００５のポートを開き、ポートへの接続要求を受け付け、セッションテーブルにセッション情報（１００２～１００８）を格納する。その後、ルート管理クライアントは、ステップ８０４に進む。

ステップ８０４では、ルート管理クライアントが、宛先ポート番号が５０００３であるインバウンドパケットを検出したとする。これは、セッションテーブルに格納されているポート番号１００７に相当する。その後、ルート管理クライアントは、ステップ８０５に進む。ステップ８０５では、ルート管理クライアントは、セッションテーブルを参照し、ポート番号が４０００１であるセッションを通して、アプリケーションにパケットを転送する（１００２）。その後、ルート管理クライアントは、ステップ８０６に進む。

ステップ８０６では、ルート管理クライアントは、状態を、ポート５０００３に関連付けられている「緊密な連携」１００９に更新する。

ステップ８０７では、ルート管理サーバが、ソースポート番号が４０００１のアウトバウンドパケットを検出したとする。セッションテーブルに格納されているポート番号４０００１（１００２）と関連付けられ、ルート管理クライアントはステップ８０８に進む。

ステップ８０８では、アプリケーション状態が「緊密な連携」であることを想定している１００９。ステップ８０８では、ルート管理クライアントは、アプリケーションの現在の状態として「緊密な連携」８０８を取得し、状態「緊密な連携」に対応するポート番号が５０００３（１００７）のセッションを通してパケットを送信する。その後、ルート管理クライアントは８０４に進む。

例示の実装形態は、製造プロセスだけでなく、複数の状態を伴う他のアプリケーションにも適用可能である。例えば、例示の実装形態は、情報技術（ＩＴ）アプリケーションの一例として、ビデオストリーミングアプリケーションに適用することができる。ビデオストリーミングアプリケーションは、「起動」と「安定」の、２つの状態を有することができる。動画配信が開始されると、アプリケーション状態は、アプリケーションは遅延が短くてすむ「起動」となり、ユーザがすぐに動画の視聴を開始して、よりよい経験ができる。ストリーミングビデオが再生されると、ユーザは既にストリーミングビデオを視聴しているため、アプリケーション状態は、アプリケーションが中程度または大きな遅延を必要とする「安定」に遷移する。

製造業用アプリケーションでは、通信要件を厳密に保証する必要があるため、例示の実装形態により、高い数値を提供することができる。製造業用アプリケーションの通信では、予期せぬ遅延が発生すると、機械の事故や故障につながったり、多くの機械が連携する可能性があるためカスケード現象が発生したりする。本明細書に記載されている例示の実装形態では、時間依存の製造プロセスを、適切なＱｏＳレベルまたは遅延レベルの通信セッションを通して確実に接続して、基礎となる製造プロセスを円滑に進めることができる。

本例示の実装形態では、通信に対するＱｏＳレベルの割り当てを動的に変更することができ、既に確立された通信セッションの切断を引き起こすことなく、短時間で変更を有効にすることができる。

第２の例示の実装形態において、アプリケーション要件テーブルが各アプリケーションの緊急状態を定義するシステムと方法が考えられる。また、エリア緊急状態テーブルでは、どのアプリケーションがどのエリアで動作しているか、各アプリケーションが緊急状態にあるかどうかを管理している。あるエリアのアプリケーションが緊急状態になると、同じエリアで動作している他のアプリケーションに、そのエリアの緊急状態が通知され、それによって緊急状態用の通信セッションの使用が開始される。

図１１は、例示の実装形態による、エリア緊急状態テーブルを示す図である。第２の例示の実装形態の一例では、ネットワーク管理サーバは、第１の例示の実装形態で例示した機能に加えて、図１１に示すエリア緊急状態テーブル１１００と、緊急状態配信装置を利用する。エリア緊急状態テーブル１１００は、エリアＩＤ１１０１、クライアントＩＤ１１０２、アプリケーション名１１０３、および緊急状態１１０４を含むことができる。このテーブルには、どのアプリケーションがどのエリアやフィールドサーバで動作しているか、アプリケーションの状態が緊急状態であるかどうかが格納されている。

各エリアの緊急状態を管理するのが緊急状態配信装置である。緊急状態配信装置は、アプリケーション状態検出器から緊急状態の通知を受け取ると、同じエリアで動作しているすべてのアプリケーションに緊急状態を通知し、緊急状態に関連付けられた通信セッションを使用できるようにする。緊急状態配信装置は、緊急状態から他の状態への状態遷移の通知を受け取ると、同じエリアにあるすべてのアプリケーションに遷移を通知し、現在の状態に関連付けられた通信セッションを使用できるようにする。

図１２は、例示の実装形態による、アプリケーション要件テーブルを示す図である。アプリケーション要件テーブル１２００では、アプリケーションごとに「緊急」状態１２０１、１２０２を定義している。

ＭＥＣサーバのアプリケーション状態検出器には、ＭＥＣサーバと通信しているアプリケーションを実行しているフィールドサーバのＩＤが格納されている。アプリケーション状態検出器は、緊急状態へのアプリケーション状態遷移を検出すると、その通知をネットワーク管理サーバに送信する。通知内容は、アプリケーション名、フィールドサーバＩＤ、緊急状態へのアプリケーション状態遷移などである。アプリケーション状態検出器は、緊急状態から他の状態へのアプリケーション状態遷移を検出すると、アプリケーション名、フィールドサーバＩＤ、緊急状態から他の状態へのアプリケーション状態遷移を含む別の通知をネットワーク管理サーバに送信する。状態検出器は、エリア内で緊急状態への状態遷移の通知を受けると、セッションテーブルの現在の状態を緊急状態に変更する。状態検出器は、緊急状態から他の状態への状態遷移の通知を受け取ると、現在の状態をアプリケーションの実際の状態に変更する。

フィールドサーバ、ＭＥＣ、ネットワーク管理サーバの動作について、より具体的な例を挙げて以下に説明する。エリア緊急状態テーブル１１００として図１１を適用し、アプリケーション要件テーブル１２００として図１２を適用したとする。図１１に示すように、緊急状態ではアプリケーションはない。そのため、ＭＥＣサーバとフィールドサーバ間の通信には、アプリケーションの実際の状態に関連付けられた通信セッションが使用される。次に、エリアＩＤとクライアントＩＤがそれぞれ１と２であるフィールドサーバで、「部品切削」アプリケーションの緊急状態への状態遷移が機能しているとする。フィールドサーバと通信しているＭＥＣサーバのアプリケーション検出器は、緊急状態へのアプリケーション状態遷移を検出し、それをネットワーク管理サーバに送信する。ネットワーク管理サーバは、エリアＩＤとクライアントＩＤがそれぞれ１と２のフィールドサーバで動作しているアプリケーション「部品切削」の緊急状態への状態遷移を受信し、その変更をエリア緊急状態テーブルに反映させる。エリア緊急状態テーブルによると、エリアＩＤ１には、クライアントＩＤが１である別のフィールドサーバが存在する。そのため、ネットワーク管理サーバの緊急状態配信装置は、クライアントＩＤが１のフィールドサーバと連携しているＭＥＣサーバに緊急状態の通知を送信する。アプリケーション状態検出器は、ネットワーク管理サーバからの通知を受けて、アプリケーション状態を緊急状態に変更する。その後、緊急状態用の通信セッションの使用を開始する。

次に、エリアＩＤとクライアントＩＤがそれぞれ１と２であるフィールドサーバで、アプリケーション「部品切削」の緊急状態から他の状態への状態遷移が発生したとする。フィールドサーバと通信しているＭＥＣサーバのアプリケーション検出器は、緊急状態から別の状態へのアプリケーション状態遷移を検出し、それをネットワーク管理サーバに送信する。ネットワーク管理サーバは、エリアＩＤとクライアントＩＤがそれぞれ１と２のフィールドサーバで動作しているアプリケーション「部品切削」の緊急状態から別の状態への状態遷移を受信し、その変更をエリア緊急状態テーブルに反映させる。エリア緊急状態テーブルによると、エリアＩＤ１には、クライアントＩＤが１である他のフィールドサーバが存在する。そこで、ネットワーク管理サーバの緊急状態配信装置は、緊急状態から他の状態への状態遷移を、クライアントＩＤが１のフィールドサーバと連携しているＭＥＣサーバに送信する。アプリケーション状態検出器は、ネットワーク管理サーバからの通知を受けて、アプリケーション状態をその実際の状態に変更する。その後、その現実の状態の通信セッションの使用を開始する。

製造プラントでは、電波やフィールドサーバ周辺の温度などの環境変化により、アプリケーションの緊急状態が発生することがある。そのような変化が発生すると、その変化の元に近いフィールドサーバで動作するアプリケーションに影響を与える可能性がある。アプリケーションの緊急状態では、アプリケーションを直ちにシャットダウンする必要があるため、その通信にはより高い要件が必要となる。この実行では、あるエリアのアプリケーションが緊急状態に遷移すると、実際に緊急状態になる前に、同じエリアのアプリケーションが緊急状態用の通信を利用することができる。そのため、製造プロセスの安全操業が円滑に進むようになる。

例示の実装形態としては、製造現場で各デバイスに最適なＱｏＳレベルを割り当てる方法を提供できる。

図１３は、図１に示されたネットワーク管理サーバ１０１、フィールドサーバ１０２、またはＭＥＣサーバ１０４など、いくつかの例示の実装で使用するのに適した例示のコンピュータデバイスを備えた例示のコンピューティング環境を示している。

コンピューティング環境１３００のコンピュータデバイス１３０５は、１つ以上の処理ユニット、コア、またはプロセッサ１３１０、メモリ１３１５（例えば、ＲＡＭ、ＲＯＭ、および／または同様のもの）、内部ストレージ１３２０（例えば、磁気、光学、ソリッドステートストレージ、および／または有機）、および／またはＩ／Ｏインターフェース１３２５を含むことができ、これらはすべて、情報を通信するための通信機構またはバス１３３０上に連結するか、またはコンピュータデバイス１３０５に組み込むことができる。また、Ｉ／Ｏインターフェース１３２５は、所望の実装形態に応じて、カメラから画像を受信したり、プロジェクタやディスプレイに画像を提供したりするように構成されている。

コンピュータデバイス１３０５は、入力／ユーザインターフェース１３３５および出力デバイス／インターフェース１３４０に通信可能に連結することができる。入力／ユーザインターフェース１３３５および出力デバイス／インターフェース１３４０のいずれか一方または両方は、有線または無線のインターフェースとすることができ、着脱可能とすることができる。入力／ユーザインターフェース１３３５は、入力を提供するために使用することができる、物理的または仮想的な任意のデバイス、コンポーネント、センサ、またはインターフェース（例えば、ボタン、タッチスクリーンインターフェース、キーボード、ポインティング／カーソルコントロール、マイク、カメラ、点字、モーションセンサ、光学リーダなど）を含むことができる。出力デバイス／インターフェース１３４０は、ディスプレイ、テレビ、モニタ、プリンタ、スピーカ、点字などを含んでもよい。いくつかの例示の実装形態では、入力／ユーザインターフェース１３３５および出力デバイス／インターフェース１３４０は、コンピュータデバイス１３０５とともに埋め込まれてもよく、またはコンピュータデバイス１３０５に物理的に連結されてもよい。他の例示の実装形態では、他のコンピュータデバイスは、コンピュータデバイス１３０５のための入力／ユーザインターフェース１３３５および出力デバイス／インターフェース１３４０の機能として機能してもよく、またはその機能を提供してもよい。

コンピュータデバイス１３０５の例には、移動性の高いデバイス（例えば、スマートフォン、車両やその他の機械に搭載されたデバイス、人間や動物が持ち運ぶデバイスなど）、モバイルデバイス（例えば、タブレット、ノートブック、ラップトップ、パーソナルコンピュータ、ポータブルテレビ、ラジオなど）、および移動用として設計されていないデバイス（例えば、デスクトップコンピュータ、その他のコンピュータ、情報キオスク、１つ以上のプロセッサがその中に組み込まれたおよび／またはそれに連結されたテレビ、ラジオなど）が含まれ得るが、これらに限定されない。

コンピュータデバイス１３０５は、同じ構成または異なる構成の１つ以上のコンピュータデバイスを含む、任意の数のネットワーク化されたコンポーネント、デバイス、およびシステムと通信するために、外部ストレージ１３４５およびネットワーク１３５０に（例えば、Ｉ／Ｏインターフェース１３２５を介して）通信可能に連結してもよい。コンピュータデバイス１３０５または任意の接続されたコンピュータデバイスは、サーバ、クライアント、シンサーバ、一般機械、特別目的機械、または別のラベルとして機能し、サービスを提供し、または参照することができる。

Ｉ／Ｏインターフェース１３２５は、コンピューティング環境１３００の少なくともすべての接続されたコンポーネント、デバイス、およびネットワークとの間で情報を通信するための、任意の通信またはＩ／Ｏプロトコルまたは標準（例えば、イーサネット、８０２．１１ｘ、ユニバーサルシステムバス、ＷｉＭａｘ、モデム、セルラーネットワークプロトコルなど）を使用する有線および／または無線インターフェースを含むことができるが、これらに限定されない。ネットワーク１３５０は、任意のネットワークまたはネットワークの組み合わせ（例えば、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、電話回線網、セルラーネットワーク、衛星ネットワークなど）でよい。

コンピュータデバイス１３０５は、一時的な媒体および非一時的な媒体を含む、コンピュータで使用可能な媒体またはコンピュータで読み取り可能な媒体を使用することおよび／または使用して通信することができる。一時的な媒体としては、伝送媒体（金属ケーブル、光ファイバーなど）、信号、搬送波などがある。非一時的な媒体には、磁気媒体（ディスク、テープなど）、光媒体（ＣＤ ＲＯＭ、デジタルビデオディスク、ブルーレイディスクなど）、ソリッドステート媒体（ＲＡＭ、ＲＯＭ、フラッシュメモリ、ソリッドステートストレージなど）、その他の不揮発性のストレージやメモリなどがある。

コンピュータデバイス１３０５を使用して、いくつかの例示のコンピューティング環境において、技術、方法、アプリケーション、プロセス、またはコンピュータ実行可能な命令を実装することができる。コンピュータ実行可能な命令は、一時的な媒体から取得することも、非一時的な媒体に格納して取得することもできる。実行可能な命令は、任意のプログラミング言語、スクリプト言語、および機械言語（Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｐｙｔｈｏｎ、Ｐｅｒｌ、ＪａｖａＳｃｒｉｐｔ、他など）のうちの１つ以上で作成されてもよい。

プロセッサ（単数または複数）１３１０は、任意のオペレーティングシステム（ＯＳ）（図示せず）の下で、ネイティブ環境または仮想環境で実行することができる。論理ユニット１３６０、アプリケーションプログラミングインターフェース（ＡＰＩ）ユニット１３６５、入力ユニット１３７０、出力ユニット１３７５、および異なるユニットが相互に、ＯＳと、および他のアプリケーション（図示せず）と通信するためのユニット間通信機構１３９５を含む、１つ以上のアプリケーションを展開することができる。記載されているユニットや要素は、デザイン、機能、構成、または実装形態において様々であり、記載されている内容に限定されるものではない。

いくつかの例示の実装形態では、情報または実行命令がＡＰＩユニット１３６５によって受信されると、それは１つ以上の他のユニット（例えば、論理ユニット１３６０、入力ユニット１３７０、出力ユニット１３７５）に通信されてもよい。いくつかの例では、論理ユニット１３６０は、上述のいくつかの例示の実装形態において、ユニット間の情報フローを制御し、ＡＰＩユニット１３６５、入力ユニット１３７０、出力ユニット１３７５によって提供されるサービスを命令するように構成されてもよい。例えば、１つ以上のプロセスまたは実装形態のフローは、論理ユニット１３６０単独で、またはＡＰＩユニット１３６５と組み合わせて制御されてもよい。入力ユニット１３７０は、例示の実装形態で説明した計算のための入力を得るように構成されてもよく、出力ユニット１３７５は、例示の実装形態で説明した計算に基づいて出力を提供するように構成されてもよい。

図１に示したような例示の実装形態では、コンピュータデバイス１３０５は、（例えば、センサおよびアクチュエータに関連付けられたデバイスを製造する）複数の装置を含むシステムを管理するために使用でき、前記複数の装置の各々は、サーバからの命令に基づいて、対応するターゲットアプリケーションを管理し、前記複数の装置は、ネットワークを通して前記サーバ（例えば、ネットワーク管理サーバ）と通信し、コンピュータデバイスは、複数の装置の各々について、対応するターゲットアプリケーションの複数の状態を取得することであって、前記複数の状態の各々は、遅延要件に対応する、取得することと、複数の通信セッションを確立することであって、前記複数の通信セッションの各々は、ネットワーク（ＮＷ）スライス（例えば、各々のスライスは異なるＳＬＡを有する）および関連するポートによって円滑に進み、前記複数の通信セッションの各々は、複数の状態のうちの対応する１つを満たすように構成されている、確立することと、前記複数の通信セッションのうち、対応するターゲットアプリケーションの現在の状態を満たす１つを指定することと、前記複数の装置の各々について、前記複数の通信セッションのうち前記指定された１つのセッションを通してデータを送信することと、前記対応するターゲットアプリケーションを前記現在の状態から別の状態へ変更するために、図４および図７の７０８～７０９に示すように、前記複数の通信セッションの１つを、前記別の状態を満たすように構成された前記複数の通信セッションの別の１つに変更することと、を行うように構成されたプロセッサ（複数可）１３１０を含む。例示の実装形態では、対応するターゲットアプリケーションは、本明細書に記載された複数の装置の各々によって実行される製造プロセスとすることができる。

プロセッサ（複数可）１３１０は、複数の装置の各々に送信されるパケットであり、宛先ポートに向けられたものである前記データに対して、複数の装置の各々に対応するターゲットアプリケーションの現在の状態を判定することと、複数の通信セッションのうち指定された１つのセッションを通して、アウトバウンドパケットを宛先ポートに送信することと、図７の７０４～７０５に示されるように、インバウンドパケットを処理するためのセッション情報に、アウトバウンドパケットのソースポート番号を格納することと、によって、複数の通信セッションのうちの指定された一つを通してデータを送信するように構成することができる。

プロセッサ（複数可）１３１０は、ポートに向けられたインバウンドパケットの受信のために、セッション情報に基づいてインバウンドパケットに対応するソースポートを識別し、図７の７０６～７０７に示されているように、インバウンドパケットを識別されたソースポートに転送するように構成することができる。

ＭＥＣサーバの一例では、プロセッサ（複数可）１３１０は、図１１に示されるエリアを管理するネットワーク管理サーバによって提供されるように、複数のエリアから同一のエリアで動作する複数の装置のうちの１つについて、対応するターゲットアプリケーションの現在の状態から別の状態への変更を取得するように構成することができる。あるエリアの装置の１つのアプリケーションの緊急状態の変更が、同じエリアのすべての装置のすべてのアプリケーションを緊急状態に切り替える図１１および図１２の例では、プロセッサ（複数可）１３１０は、複数の装置の１つからの対応するターゲットアプリケーションの現在の状態から緊急状態である別の状態への変更のために、前記複数の通信セッションのうちの１つを、前記複数の装置のうちの１つと前記複数のエリアの同じエリアで動作する前記複数の装置のうちのすべてのものの対応するターゲットアプリケーションについて、前記緊急状態を満たすように構成された前記複数の通信セッションのうちの別の１つに変更するように構成することができる。

図８に示す例では、プロセッサ（複数可）１３１０は、複数の装置のうちの１つの対応するターゲットアプリケーションに向けられたクライアントデバイスによるインバウンドパケットの受信のために、インバウンドパケットに関連付けられた複数の装置のうちの１つの宛先ポートにインバウンドパケットを送信し、インバウンドパケットが受信された複数の通信セッションのソースセッションに基づいて、対応するターゲットアプリケーションの現在の状態を更新するように構成することができる。

詳細な説明のうちの一部は、コンピュータ内の操作のアルゴリズムおよび記号表現に関して提示される。これらのアルゴリズム記述および記号表現は、データプロセス技術の当業者が使用することにより、当業者にそれらの技術革新の本質を伝える手段である。アルゴリズムは、所望の終了状態または結果をもたらす、定義された一連のステップである。例示の実装形態では、実行されるステップは、有形の結果を達成するための有形量の物理的操作を必要とする。

特に記載がない限り、議論から明らかなように、明細書の議論全体を通して「プロセスする」、「演算する」、「算出する」、「判定する」、「表示する」などの用語を使用する場合は、物理電子工学として表されるコンピュータシステムのレジスタおよびメモリ内のデータを演算システムのメモリ、レジスタ、または他の情報ストレージ、伝送または表示デバイス内の物理量として同様に表される他のデータに操作および変換するコンピュータシステム、または他の情報処理デバイスの動作およびプロセスを含むことができることは理解できよう。

例示の実装形態は、本明細書での操作を実行するための装置にも関連する場合もある。この装置は、必要な目的のために特別に構成することができ、あるいは１つ以上のコンピュータプログラムを選択的に起動または再構成する１つ以上の汎用コンピュータを含んでいてもよい。このようなコンピュータプログラムは、コンピュータ可読ストレージ媒体またはコンピュータ可読信号媒体などのコンピュータ可読媒体に格納されてもよい。コンピュータ可読ストレージ媒体は、限定されるものではないが、光ディスク、磁気ディスク、読み取り専用メモリ、ランダムアクセスメモリ、ソリッドステートデバイスおよびドライブなどの有形媒体、または電子情報を格納するのに好適な任意の他のタイプの有形または非一時的媒体を含んでいてもよい。コンピュータ可読信号媒体は、搬送波のような媒体を含んでいてもよい。本明細書で提示されるアルゴリズムおよび表示は、いかなる特別のコンピュータまたは他の装置にも本質的に関連するものではない。コンピュータプログラムは、所望の実装形態の操作を実行する命令を含む純粋なソフトウェア実装を含むことができる。

様々な汎用システムを、本明細書の実施例に従ってプログラムおよびモジュールと共に使用することができ、または所望の方法ステップを実行するためのより特化された装置を構築することが便利であると証明することができる。さらに、例示の実装形態の説明には、任意の識別のプログラミング言語を参照していない。本明細書に記載された例示の実装形態の技術を実装するために、様々なプログラミング言語を使用することができることは理解できよう。プログラミング言語（複数可）の命令は、１つ以上の処理デバイス、例えば中央処理装置（ＣＰＵ）、プロセッサ、またはコントローラによって実行してもよい。

当該技術分野で知られているように、上述した操作は、ハードウェア、ソフトウェア、またはソフトウェアとハードウェアのいくつかの組み合わせによって実行することができる。例示の実装形態の様々な態様は、回路および論理デバイス（ハードウェア）を使用して実装してもよく、他の態様は、プロセッサによって実行される場合、プロセッサに本出願の実装を実行する方法を実行させる、機械可読媒体（ソフトウェア）上に格納された命令を用いて実装してもよい。さらに、本出願のいくつかの例示の実装形態は、ハードウェアのみで実行してもよく、他の例示の実装形態は、ソフトウェアでのみ実行してもよい。さらに、記載された様々な機能は、単一のユニット内で実行することができ、またはいくつかの方法でいくつかのコンポーネントにわたって拡散することができる。ソフトウェアによって実行される場合、方法は、コンピュータ可読媒体上に格納された命令に基づいて、汎用コンピュータなどのプロセッサによって実行してもよい。所望であれば、命令は、圧縮されたフォーマットおよび／または暗号化されたフォーマットで媒体上に格納することができる。

さらに、本出願のその他の実装形態は、本出願の教示内容および技術内容を考慮することによって、当業者には明らかであろう。記載された例示の実装形態の様々な態様および／またはコンポーネントは、単独で、または任意の組み合わせで使用してもよい。本明細書および例示の実装形態は、例示に過ぎず、本出願の真の範囲と精神は、下記の特許請求の範囲によって示されるものである。

１０１ ネットワーク管理サーバ
１０２ フィールドサーバ
１０４ ＭＥＣサーバ
１０６ 通信ネットワーク
１０７ センサ
１０９ アクチュエータ
２０１ アプリケーション要件テーブル
２０２ ＱｏＳテーブル
４０１ ネットワークスライスＩＤ
４０２ 遅延
４０３ ポート
５０１ クライアントアプリケーション
５０２ クライアントセッションテーブル
５０３ ルートマネジメントクライアント
６０１ サーバアプリケーション
６０２ サーバセッションテーブル
６０３ ルート管理サーバ
６０４ アプリケーション状態検出器
１３０５ コンピューティングデバイス
１３２５ Ｉ／Ｏインターフェース
１３２０ 内部ストレージ
１３１５ メモリ
１３１０ プロセッサ（複数可）
１３３５ 入力／ユーザインターフェース
１３４０ 出力デバイス／インターフェース
１３４５ 外部ストレージ
１３５０ ネットワーク
１３６０ 論理ユニット
１３６５ ＡＰＩユニット
１３７０ 入力ユニット
１３７５ 出力ユニット

Claims (18)

1. 複数の装置を含むシステムの管理方法であって、前記複数の装置の各々は、サーバからの命令に基づいて、対応するターゲットアプリケーションを管理し、前記複数の装置は、ネットワークを通して前記サーバと通信し、
   前記複数の装置の各々について
   前記対応するターゲットアプリケーションの複数の状態を取得することであって、前記複数の状態の各々は、遅延要件に対応する、取得することと、
   複数の通信セッションを確立することであって、前記複数の通信セッションの各々が、ネットワーク（ＮＷ）スライスおよび関連するポートによって円滑に進み、前記複数の通信セッションの各々は、前記複数の状態のうちの対応する１つを満たすように構成されている、確立することと、
   前記複数の通信セッションのうち、前記対応するターゲットアプリケーションの現在の状態を満たす１つを指定することと、
   前記複数の装置の前記各々について、前記複数の通信セッションのうち前記指定された１つのセッションを通してデータを送信することと、
   前記対応するターゲットアプリケーションを前記現在の状態から別の状態へ変更するために、前記複数の通信セッションの前記１つを、前記別の状態を満たすように構成された前記複数の通信セッションの別の１つに変更することと、を含む、方法。
2. 前記対応するターゲットアプリケーションは、前記複数の装置の前記各々によって実行される製造プロセスである、請求項１に記載の方法。
3. 前記複数の通信セッションのうち前記指定された１つを通して前記データを送信することは、
   前記複数の装置の前記各々に対するアウトバウンドパケットであり、宛先ポートに向けられたものである前記データに対して、
   前記複数の装置の前記各々に対応する前記対応するターゲットアプリケーションの前記現在の状態を判定することと、
   前記複数の通信セッションのうち前記指定された１つのセッションを通して、前記アウトバウンドパケットを前記宛先ポートに送信することと、
   インバウンドパケットを処理するためのセッション情報に、前記アウトバウンドパケットのソースポート番号を格納することと、を含む、請求項１に記載の方法。
4. ポートに向けられたインバウンドパケットの受信のために、セッション情報に基づいて、前記インバウンドパケットに対応するソースポートを識別することと、
   前記識別されたソースポートに前記インバウンドパケットを転送することと、をさらに含む、請求項１に記載の方法。
5. 複数のエリアを管理することであって、前記複数のエリアの各々は、前記複数のエリアの前記各々で動作する前記複数の装置のうちの前記対応するターゲットアプリケーションに対応する１つ以上の緊急状態の表示に関連付けられており、
   前記対応するターゲットアプリケーションの前記複数の状態のうちの１つが前記緊急状態である、管理することと、
   前記対応するターゲットアプリケーションの、前記複数の装置の１つから、前記現在の状態から前記緊急状態への前記変更に対し、前記複数の通信セッションのうちの前記１つを、前記複数の装置のうちの１つと同じエリアで動作する前記複数の装置のうちのすべての装置の前記対応するターゲットアプリケーションについて、前記緊急状態を満たすように構成された前記複数の通信セッションのうちの別の１つに変更することと、をさらに含む、請求項１に記載の方法。
6. クライアントデバイスが、前記複数の装置のうちの１つの前記対応するターゲットアプリケーションに向けられたインバウンドパケットの受信のために、
   前記インバウンドパケットを、前記インバウンドパケットに関連付けられた前記複数の装置のうちの前記１つの宛先ポートに送信することと、
   前記インバウンドパケットを受信した前記複数の通信セッションのうちのソースセッションに基づいて、前記対応するターゲットアプリケーションの前記現在の状態を更新することと、をさらに含む、請求項１に記載の方法。
7. 複数の装置を含むシステムを管理するためのプロセスを実行するための命令を格納する、非一時的なコンピュータ可読媒体であって、前記複数の装置の各々は、サーバからの命令に基づいて、対応するターゲットアプリケーションを管理し、前記複数の装置は、ネットワークを通して前記サーバと通信し、前記命令は、
   前記複数の装置の前記各々について
   対応するターゲットアプリケーションの複数の状態を取得することであって、前記複数の状態の各々は、遅延要件に対応する、取得することと、
   複数の通信セッションを確立することであって、前記複数の通信セッションの各々が、ネットワーク（ＮＷ）スライスおよび関連するポートによって円滑に進み、前記複数の通信セッションの各々は、前記複数の状態のうちの対応する１つを満たすように構成されている、確立することと、
   前記複数の通信セッションのうち、前記対応するターゲットアプリケーションの現在の状態を満たす１つを指定することと、
   前記複数の装置の前記各々について、前記複数の通信セッションのうち前記指定された１つのセッションを通してデータを送信することと、
   前記対応するターゲットアプリケーションを前記現在の状態から別の状態へ変更するために、前記複数の通信セッションの前記１つを、前記別の状態を満たすように構成された前記複数の通信セッションの別の１つに変更することと、を含む、非一時的なコンピュータ可読媒体。
8. 前記対応するターゲットアプリケーションは、前記複数の装置の前記各々が実行する製造プロセスであることを特徴とする、請求項７に記載の非一時的なコンピュータ可読媒体。
9. 前記複数の通信セッションのうち前記指定された１つを通して前記データを送信することは、
   前記複数の装置の前記各々に対するアウトバウンドパケットであり、宛先ポートに向けられたものである前記データに対して、
   前記複数の装置の前記各々に対応する前記対応するターゲットアプリケーションの前記現在の状態を判定することと、
   前記複数の通信セッションのうち前記指定された１つのセッションを通して、前記アウトバウンドパケットを前記宛先ポートに送信することと、
   インバウンドパケットを処理するためのセッション情報に、前記アウトバウンドパケットのソースポート番号を格納することと、を含む、請求項７に記載の非一時的なコンピュータ可読媒体。
10. 前記命令が、
    ポートに向けられたインバウンドパケットの受信のために、セッション情報に基づいて、前記インバウンドパケットに対応するソースポートを識別することと、
    前記識別されたソースポートに前記インバウンドパケットを転送することと、をさらに含む、請求項７に記載の非一時的なコンピュータ可読媒体。
11. 前記命令が、
    複数のエリアを管理することであって、前記複数のエリアの各々は、前記複数のエリアの前記各々で動作する前記複数の装置のうちの前記対応するターゲットアプリケーションに対応する１つ以上の緊急状態の表示に関連付けられている、管理することと、
    前記対応するターゲットアプリケーションの前記複数の状態のうちの１つが緊急状態である、管理することと、
    前記対応するターゲットアプリケーションの、前記複数の装置の１つから、前記現在の状態から前記緊急状態への前記変更に対し、前記複数の通信セッションのうちの前記１つを、前記複数の装置のうちの前記１つと同じエリアで動作する前記複数の装置のうちのすべての装置の前記対応するターゲットアプリケーションについて、前記緊急状態を満たすように構成された前記複数の通信セッションのうちの別の１つに変更することと、をさらに含む、請求項７に記載の非一時的なコンピュータ可読媒体。
12. 前記命令が、
    クライアントデバイスが、前記複数の装置のうちの１つの前記対応するターゲットアプリケーションに向けられたインバウンドパケットの受信のために、
    前記インバウンドパケットを、前記インバウンドパケットに関連付けられた前記複数の装置のうちの前記１つの宛先ポートに送信することと、
    前記インバウンドパケットを受信した前記複数の通信セッションのうちのソースセッションに基づいて、前記対応するターゲットアプリケーションの前記現在の状態を更新することと、をさらに含む、請求項７に記載の非一時的なコンピュータ可読媒体。
13. 複数の装置を含むシステムの管理のためのコンピュータデバイスであって、前記複数の装置の各々は、サーバからの命令に基づいて、対応するターゲットアプリケーションを管理し、前記複数の装置は、ネットワークを通して前記サーバと通信し、
    コンピュータデバイスは、
    前記複数の装置の各々に対して、
    前記対応するターゲットアプリケーションの複数の状態を取得することであって、前記複数の状態の各々は、遅延要件に対応する、取得することと、
    複数の通信セッションを確立することであって、前記複数の通信セッションの各々は、ネットワーク（ＮＷ）スライスおよび関連するポートによって円滑に進み、前記複数の通信セッションの前記各々は、前記複数の状態のうちの対応する１つを満たすように構成されている、確立することと、
    前記複数の通信セッションのうち、前記対応するターゲットアプリケーションの現在の状態を満たす１つを指定することと、
    前記複数の装置の前記各々について、前記複数の通信セッションのうち前記指定された１つのセッションを通してデータを送信することと、
    前記対応するターゲットアプリケーションを前記現在の状態から別の状態へ変更するために、前記複数の通信セッションの前記１つを、前記別の状態を満たすように構成された前記複数の通信セッションの別の１つに変更することと、を行うように構成されたプロセッサを含む、コンピュータデバイス。
14. 前記対応するターゲットアプリケーションは、前記複数の装置の前記各々によって実行される製造プロセスである、請求項１３に記載のコンピュータデバイス。
15. 前記プロセッサは、
    前記複数の装置の前記各々に対するアウトバウンドパケットであり、宛先ポートに向けられたものである前記データに対して、
    前記複数の装置の前記各々に対応する前記対応するターゲットアプリケーションの前記現在の状態を判定することと、
    前記複数の通信セッションのうち前記指定された１つのセッションを通して、前記アウトバウンドパケットを前記宛先ポートに送信することと、
    インバウンドパケットを処理するためのセッション情報に、前記アウトバウンドパケットのソースポート番号を格納することと、によって、前記複数の通信セッションのうち前記指定された１つを通して前記データを送信するように構成されている、請求項１３に記載のコンピュータデバイス。
16. 前記プロセッサが、
    ポートに向けられたインバウンドパケットの受信のために、セッション情報に基づいて、インバウンドパケットに対応するソースポートを識別し、
    前記識別されたソースポートに前記インバウンドパケットを転送するように構成された、請求項１３に記載のコンピュータデバイス。
17. 前記プロセッサが、
    複数のエリアから同じエリアで動作する複数の装置のうち、前記対応するターゲットアプリケーションの前記現在の状態から別の状態への変化を取得し、
    前記対応するターゲットアプリケーションの、前記複数の装置の１つから、前記現在の状態から緊急状態である前記別の状態への前記変更に対し、前記プロセッサは、前記複数の通信セッションのうちの１つを、前記複数の装置のうちの前記１つと同じエリアで動作する前記複数の装置のうちのすべての装置の前記対応するターゲットアプリケーションについて、前記緊急状態を満たすように構成された前記複数の通信セッションのうちの別の１つに変更するように構成された、請求項１３に記載のコンピュータデバイス。
18. 前記プロセッサが、
    クライアントデバイスが、前記複数の装置のうちの１つの前記対応するターゲットアプリケーションに向けられたインバウンドパケットの受信のために、
    前記インバウンドパケットを、前記インバウンドパケットに関連付けられた前記複数の装置のうちの１つの宛先ポートに送信し、
    前記インバウンドパケットを受信した前記複数の通信セッションのうちのソースセッションに基づいて、前記対応するターゲットアプリケーションの前記現在の状態を更新するように構成されている、請求項１３に記載のコンピュータデバイス。

Images