特表 2023-515911 ネットワークにおいてメッセージを送信する方法、デバイス及びシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-04-14

(54)【発明の名称】ネットワークにおいてメッセージを送信する方法、デバイス及びシステム

(51)【国際特許分類】

   H04L 47/43 20220101AFI20230407BHJP

【ＦＩ】

H04L47/43

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2022578016

(86)(22)【出願日】2021-03-04

(85)【翻訳文提出日】2022-08-29

(86)【国際出願番号】 JP2021009697

(87)【国際公開番号】W WO2021250960

(87)【国際公開日】2021-12-16

(31)【優先権主張番号】20305628.8

(32)【優先日】2020-06-10

(33)【優先権主張国・地域又は機関】EP

(81)【指定国・地域】

(71)【出願人】

【識別番号】503163527

【氏名又は名称】ミツビシ・エレクトリック・アールアンドディー・センター・ヨーロッパ・ビーヴィ

【氏名又は名称原語表記】ＭＩＴＳＵＢＩＳＨＩ ＥＬＥＣＴＲＩＣ Ｒ＆Ｄ ＣＥＮＴＲＥ ＥＵＲＯＰＥ Ｂ．Ｖ．

【住所又は居所原語表記】Ｃａｐｒｏｎｉｌａａｎ ４６， １１１９ ＮＳ Ｓｃｈｉｐｈｏｌ Ｒｉｊｋ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ

(74)【代理人】

【識別番号】100110423

【弁理士】

【氏名又は名称】曾我 道治

(74)【代理人】

【識別番号】100111648

【弁理士】

【氏名又は名称】梶並 順

(74)【代理人】

【識別番号】100122437

【弁理士】

【氏名又は名称】大宅 一宏

(74)【代理人】

【識別番号】100147566

【弁理士】

【氏名又は名称】上田 俊一

(74)【代理人】

【識別番号】100161171

【弁理士】

【氏名又は名称】吉田 潤一郎

(72)【発明者】

【氏名】マンガン、クリストフ

【テーマコード（参考）】

5K030

【Ｆターム（参考）】

5K030GA03

5K030HA08

5K030HD03

5K030JA11

5K030LE13

(57)【要約】

本発明は、ネットワーク上にパブリッシャデバイス及びサブスクライバデバイスを含む通信モードを有するネットワークにおいてメッセージを送信する方法であって、該方法は、受信されたメッセージのペイロード（データセットメッセージ）を抽出し、当該ペイロードを同じ組み合わされたメッセージ内で連結することと、上記組み合わされたメッセージにヘッダを追加することであって、当該ヘッダは、パブリッシャデバイスの単一の識別子（パブリッシャＩｄ＝ｋ）を含み、当該パブリッシャ識別子は、組み合わされたメッセージを少なくとも１つの選ばれたサブスクライバデバイスに向けるように予め定められることとを含む方法に関する。

【特許請求の範囲】

【請求項1】

ネットワーク上にパブリッシャデバイス及びサブスクライバデバイスを含む通信モードを有する前記ネットワークにおいてメッセージを送信する方法であって、該方法は、
受信されたメッセージのペイロードを抽出し、前記ペイロードを同じ組み合わされたメッセージ内で連結することと、
前記組み合わされたメッセージにヘッダを追加することであって、前記ヘッダは、パブリッシャデバイスの単一の識別子を含み、前記パブリッシャ識別子は、前記組み合わされたメッセージを少なくとも１つの選ばれたサブスクライバデバイスに向けるように予め定められることと
を含む方法。

【請求項2】

前記選ばれたサブスクライバデバイスは、前記受信されたメッセージを送出するネットワークデバイスのコントローラデバイスである請求項１に記載の方法。

【請求項3】

前記ネットワークデバイスの中で前記方法を実施するデバイスが、前記コントローラデバイス及び／又は前記送出デバイスに対して基準に基づいて選択される請求項２に記載の方法。

【請求項4】

前記基準は、少なくとも前記ネットワークの現在のトポロジを含む請求項３に記載の方法。

【請求項5】

前記受信されたメッセージは、同じパブリッシャ識別子を有するヘッダを有する一方、前記受信されたメッセージは、複数の異なるパブリッシャデバイスによって送出される請求項１から請求項４までのいずれか１項に記載の方法。

【請求項6】

各受信されたメッセージは、該受信されたメッセージを送出したデバイスに関連した識別子を含み、前記送出機識別子は、前記ペイロードの連結内の前記受信されたメッセージの前記ペイロードの順序を定義する請求項１から請求項５までのいずれか１項に記載の方法。

【請求項7】

前記ネットワークは、オープンプラットフォーム通信統一アーキテクチャというタイプの規格に従って運用され、パブリッシャデバイスの前記単一の識別子は、パブリッシャＩＤ識別子である請求項１から請求項６までのいずれか１項に記載の方法。

【請求項8】

前記ネットワークは、タイムセンシティブネットワーキングというタイプの規格に従って更に運用される請求項７に記載の方法。

【請求項9】

前記送出機識別子は、パブリッシングオフセットのタイミングを定義し、それによって、前記ペイロードの連結内の前記受信されたメッセージの前記ペイロードの順序を定義するライタグループＩＤである請求項６と組み合わせた請求項７又は請求項８に記載の方法。

【請求項10】

前記連結されたペイロードは、同じ所定のサイクル継続時間（パブリッシング間隔）内で受信されたメッセージから抽出される請求項１から請求項９までのいずれか１項に記載の方法。

【請求項11】

マルチプレクサデバイスとして動作するように選択され、請求項１から請求項１０までのいずれか１項に記載の方法を実施するように構成されるネットワークデバイス。

【請求項12】

メッセージを送出するネットワークデバイスと、前記メッセージを受信し、請求項１から請求項１０までのいずれか１項に記載の方法を実施するように構成されるマルチプレクサデバイスとを備えるシステム。

【請求項13】

請求項１２に記載のシステムのコントローラデバイスであって、前記所定のパブリッシャ識別子を有する前記組み合わされたメッセージを受信し、前記ペイロードの連結を解釈するように構成されるコントローラデバイス。

【請求項14】

命令を含むコンピュータプログラムであって、該命令は、ネットワークデバイスのプロセッサ（ＰＲＯＣＣ；ＰＲＯＣＤ）によって実行されると、請求項１から請求項１０までのいずれか１項に記載の方法を前記ネットワークデバイスに実施させるコンピュータプログラム。

【請求項15】

ネットワークのパブリッシャデバイス及びサブスクライバデバイスを含む通信モードを有する前記ネットワークにおいてパブリッシュされるメッセージのデータを含む信号であって、
該信号は、
パブリッシャデバイスの単一の識別子を含むヘッダのデータと、
前記ネットワークのそれぞれのデバイスによって開始される複数の連結されたペイロードのデータと
を含む信号。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ネットワーク上にパブリッシャデバイス及びサブスクライバデバイスを含む通信モードを有するネットワークにおいてメッセージを送信する方法、デバイス、及びシステムに関する。

【背景技術】

【0002】

オープンプラットフォーム通信統一アーキテクチャ（ＯＰＣ ＵＡ：Open Platform Communications Unified Architecture）が、ＯＰＣクラシックに加えて多くのベンダー固有のプロトコルに次第に取って代わり、オートメーションにおけるフレキシブルなベストエフォート型通信に広く使用されている。ＯＰＣ ＵＡは、アプリケーションドメイン及びオートメーション制御階層レベルにわたって均一で標準化されたセキュアな通信を達成するように設計されている。

【0003】

ＯＰＣ ＵＡ仕様は、パブリッシュ／サブスクライブ（Publish/Subscribe）データ交換（以下「ＰｕｂＳｕｂ」）の原理に基づく通信を用いて拡張されており、「多対多」通信を含む新たな使用シナリオをもたらす。加えて、ＯＰＣ ＵＡ ＰｕｂＳｕｂとタイムセンシティブネットワーキング（ＴＳＮ：Time-Sensitive Networking）との統合は、クリティカルなリアルタイム要件を有する通信を可能にするように設計されている。

【0004】

ＯＰＣ ＵＡに関するより詳細な内容を以下に示す。ＯＰＣ ＵＡは、ＩＥＣ６２５４１として標準化されたＴＣＰ／ＩＰに基づく産業通信用のクライアントサーバプロトコルである。ＯＰＣ ＵＡサーバは、オブジェクト指向情報モデルにおいて構造化されたデータ及び機能へのアクセスを提供する。クライアントは、標準化されたサービスのセットを使用して情報モデルとインタラクトする。各サービスは、インタラクション用の要求メッセージ及び応答メッセージを定義する。ただし、通知が生じたときにのみ通知をプッシュするために、サブスクリプションメカニズムも使用することができる。

【0005】

いわゆる「タイムセンシティブネットワーキング（ＴＳＮ）」に関するより詳細な内容を以下に示す。ＩＥＥＥ８０２．１規格シリーズ内において、当初、オーディオビデオブリッジング（ＡＶＢ：Audio Video Bridging）として開発されたリアルタイム通信のためのイーサネットの強化は、近年、タイムセンシティブネットワーキング（ＴＳＮ）として拡張された。ＩＥＥＥ８０２．１ＡＳにおいて仕様化されたクロック同期方式及びＩＥＥＥ８０２．１Ｑｂｖのタイムスロットを介した伝送容量の確保は、リアルタイム制約を有するオートメーションネットワークにおいて使用される基本規格である。

【0006】

産業通信トラフィックタイプが、それらとＴＳＮ規格との関係を含めて、産業アプリケーションにおいて見られる種々の一般的なユースケースを満たすように定義されている。産業通信へのＴＳＮの導入は、オープン標準フレームワークであるという利点をもたらすことに加えて、以下のいくつかの技術的改良及び性能改善ももたらす。
・潜在的により高いスループット、
・ブリッジされたネットワークにおける複数のホップにわたる差別化及び保証されたサービス品質を有する接続を混合する際のフレキシビリティ、
・産業ユースケース及び消費者デバイスの双方を対象とした広範な技術の規模の経済。

【0007】

パブリッシュされたメッセージがメッセージのトピックの全てのサブスクライバに転送されるＯＰＣ ＵＡにおけるメカニズム「パブリッシュ／サブスクライブ」は、トピックについて多くのサブスクライバに登録を認める。この特徴によって、多くのサブスクライバが、レガシーフィールドバスにおいて実施される通信方式と同様の方法で同じメッセージを受信することが可能になる。パブリッシュされたメッセージの内容は、ＯＰＣ ＵＡサーバの情報モデルからの変数及びイベントソースの集合体を表すいわゆるパブリッシュドデータセット（PublishedDataSet）によって定義される。パブリッシュドデータセットは、フレキシブルに構成することができ、その説明は、パブリッシュされた情報のセマンティクスを解釈するためにサーバ内で検索することができる。

【0008】

ＯＰＣ ＵＡ規格の仕様（セクション１４）は、既存のパブリッシュ／サブスクライブプロトコル、特にＭＱＴＴ（メッセージキューイングテレメトリートランスポート：Message Queuing Telemetry Transport）及びＡＭＱＰ（アドバンストメッセージキューイングプロトコル：Advanced Message Queuing Protocol）上へのＯＰＣ ＵＡ ＰｕｂＳｕｂのマッピングを定義する。これらのプロトコルは、メッセージ配信の中央ブローカを定義し、公衆インターネットにおいて一般に使用される。この規格は、ＩＰ規格によって提供されるマルチキャストメカニズムに依拠したカスタムＵＤＰベースの配信プロトコル及び対応するメッセージレイアウト（ＵＡＤＰ）も定義する。ＵＡＤＰを使用するとき、サブスクライバは、特定のＩＰマルチキャストアドレスによって識別されるマルチキャストグループの登録を行う。

【0009】

バイナリー符号化メッセージを用いたこのトランスポートは、少量のデータを頻繁に送信する本番環境によく適合している。このアドレスに送信されたＰｕｂＳｕｂメッセージは、グループの全てのメンバーに転送される。そのようなマッピングは、パブリッシャの複雑度の大部分を既存のネットワークインフラストラクチャ（ルータ、スイッチ等）に委ねる。最後に、この規格は、データリンクレイヤ、すなわちイーサネットを直接介した、同じＵＡＤＰレイアウトを用いたＰｕｂＳｕｂメッセージのトランスポートも定義する。

【0010】

その構成では、ＯＰＣ ＵＡ ＰｕｂＳｕｂをリアルタイムトランスポート用のＴＳＮと統合することができ、ＵＡＤＰペイロードを運ぶイーサネットフレームは、特定のイーサタイプ（０ｘＢ６２Ｃ）によって識別される。イーサネットＴＳＮ上へのこのマッピングは、固定されたパブリッシュドデータセットを前提とし、ＯＰＣ ＵＡサーバに見られるソフトウェア及びネットワークの交換オーバヘッドを伴わずに所望のネットワークメッセージを直接生成する非常に軽量のＯＰＣ ＵＡ ＰｕｂＳｕｂの実施の可能性を開く。

【0011】

ＯＰＣ ＵＡにおけるＰｕｂ／Ｓｕｂ原理に関するより詳細な内容を以下に示す。データセット（DataSet）は、パブリッシャ（Publisher）によって提供されてサブスクライバ（Subscriber）によって消費されるメッセージのペイロードを構成する。パブリッシャ及びサブスクライバは、疎結合され、それらの主要な関係は、データセットと、これらのデータを含むメッセージのパブリッシュ特性と、メッセージ指向ミドルウェア（Message Oriented Middleware）との理解を共用していることである。ＰｕｂＳｕｂメッセージは、ネットワークメッセージ（NetworkMessage）と呼ばれる。それらのメッセージは、以下のものを含む。
・ヘッダ情報（例えば識別データ及びセキュリティデータ）、及び
・１つ以上のデータセットメッセージ（DataSetMessage）（ペイロード）。

【0012】

各データセットメッセージは、データセットから作成される。データセットライタ（DataSetWriter）と呼ばれるパブリッシャの構成要素は、連続的な一連のデータセットメッセージを生成する。データセットのシンタックス及びセマンティクスは、データセットメタデータ（DataSetMetaData）によって記述される。パブリッシャにおけるデータセットの情報の選択及びデータ取得パラメータは、パブリッシュドデータセットと呼ばれる。

【0013】

図１は、これらの異なる役割及びエンティティを示している。データセットは、イベント又は変数値サンプルから作成される。このアプリケーションデータコレクタの構成は、パブリッシュドデータセットと呼ばれる。データセットフィールドは、パブリッシャ内の内部変数、パブリッシャからのイベント若しくはパブリッシャによって収集されたイベント、ネットワークデータ、又はサブデバイスからのデータを表すことができる。データセットの構造及び内容は、データセットメタデータによって定義される。

【0014】

パブリッシュするために、図２に示すように、データセットは、データセットメッセージに符号化され、データセットメッセージは、場合によっては、他のデータセットメッセージと更に組み合わされてネットワークメッセージのペイロードを形成する。データセットライタは、データセットデータを含むデータセットメッセージの符号化及びトランスポート用に構成される。データセットの構成及びデータがパブリッシングのために取得される方法は、ＯＰＣ ＵＡ ＰｕｂＳｕｂ規格の仕様において定義されたＰｕｂＳｕｂ構成モデルを使用して構成することができる。

【0015】

データセットメッセージフィールド、データセットメッセージ、ネットワークメッセージ及びトランスポートプロトコルを含むネットワークメッセージの構成における種々のレイヤを図３に示す。

【0016】

データセットメッセージフィールドは、データセットメッセージ内の特定のデータセットフィールドを表すものと定義することができる。データセットフィールドは、実際の値を、その値に関連したステータス及びタイムスタンプ等の付加情報とともに含む。データセットメッセージは、データセットから生成され、ヘッダと、データセットの符号化されたフィールドとからなる。構成に応じて、データセットメッセージヘッダは、以下のような付加情報を含むことができる。
・データセットライタを識別するとともに、パブリッシュドデータセットを間接的に識別する識別子であるデータセットライタＩｄ（DataSetWriterId）、
・シーケンス番号、
・タイムスタンプ、
・バージョンＩＤ、
・「キープアライブ」ステータス。

【0017】

データコントラクトとしてのデータセットメタデータは、データセットメッセージに含まれるフィールドを定義する。データセットメッセージ及びネットワークメッセージのヘッダの設定は、パブリッシャとサブスクライバとの間の通信コントラクトを定義する。ネットワークメッセージは、データセットメッセージに共通の以下の情報を搬送するヘッダを含むデータセットメッセージのコンテナである。
・パブリッシャＩｄ（PublisherId）：パブリッシャを識別する。
・セキュリティデータ：メッセージセキュリティをサポートする符号化にのみ利用可能である。関連のある情報は、メッセージマッピングにおいて指定される。
・昇格フィールド（promoted field）：ヘッダにおいても送信されるデータセットから選択されたフィールド。
・ペイロード：１つ以上のデータセットメッセージ。

【0018】

データセットメッセージからなるペイロードは、構成されたメッセージセキュリティに従って暗号化することができる。データセットメッセージの個々のフィールドは、暗号化を「免れる（escape）」ように「昇格（promoted）」させることができ、したがって、フィルタリング及び転送に使用することができる。昇格フィールドの構成は、ネットワークメッセージのフォーマット及び使用されるプロトコルに依存する。いずれにしても、ネットワークメッセージヘッダは、フィルタリング及び転送を可能にするために暗号化されない。

【0019】

次に、このメッセージ交換に関与するエンティティに関して、パブリッシャは、（図２に示すように）ネットワークメッセージを送信するＰｕｂＳｕｂエンティティである。このエンティティは、任意のエンティティであり、必ずしも特定のネットワークノード（例えば、特定のＩＰアドレス又はＭＡＣアドレスを有するノード）又はアプリケーションでない。パブリッシャは、通常、メッセージを送信する１つ以上のネットワークノードからなることができる。

【0020】

単一のパブリッシャが、複数のパブリッシュドデータセット及び複数のデータセットライタをサポートすることができる。データセットライタは、パブリッシャの論理的な構成要素である。メッセージ送信のために、メッセージの作成は、パブリッシュドデータセットに従って、パブリッシュされるデータ（データセット）を収集し、データセットの個々のフィールドを生成することから開始する。

【0021】

データセットライタは、その後、データセットからデータセットメッセージを作成する。同じライタグループ（WriterGroup）に属するデータセットライタからのデータセットメッセージは、単一のネットワークメッセージ内に挿入することができる。データセットメッセージのフォーマット及び符号化は、いくつかの構成パラメータ（ここでは定義しない）によって定められる。

【0022】

ネットワークメッセージは、ＰｕｂＳｕｂ接続（PubSubConnection）上で定義されるパブリッシャＩｄとともに、データセットメッセージ、データセットライタＩｄ、データセットクラスＩｄ（DataSetClassId）、データセットメタデータから得られる構成バージョン（ConfigurationVersion）から作成される。メッセージの構造は、プロトコル固有である。

【0023】

ネットワークメッセージは、ライタグループに関連付けられたパブリッシング間隔（PublishingInterval）に基づいて、各パブリッシング間隔の開始からの所与のオフセットであるパブリッシングオフセット（PublishingOffset）において、サイクリックに送信することができる。

【0024】

サブスクライバは、どのデータセットメッセージについて、どのメッセージ指向ミドルウェア上でサブスクライブするのかを判断するように構成され、及び／又は、発見メカニズムを使用してこれを判断する。ネットワークメッセージヘッダ内の暗号化されていないデータは、サブスクライバが、関連のあるパブリッシャ、データセットメッセージ、データセットクラス（DataSetClass）を識別してフィルタリングするために使用される。

【0025】

データセットメッセージは、関連があると判断されると、データセットへの復号化を行う対応するデータセットリーダ（DataSetReader）に転送される。その結果のデータセットは、その後、サブスクライバ内で更に処理又はディスパッチされる。

【0026】

サブスクライバは、接続を確立することによって、例えばＵＤＰマルチキャストグループ又はイーサネットマルチキャストグループに参加することによって、メッセージ指向ミドルウェアによってサポートされる配信グループに登録される。

【0027】

サブスクライバは、関連のあるネットワークメッセージにおいて対象となるデータセットメッセージを各データセットリーダにディスパッチし、各データセットリーダは、それらを、データセットメタデータにおいて提供される情報を使用してデータセットに復号化する。

【0028】

図４は、ＰｕｂＳｕｂ構成要素と、種々のメッセージ符号化ステージを作成する際のそれらの役割との間の関係を要約している。ＰｕｂＳｕｂメッセージマッピングに関して、以下の説明は、ＵＤＰ／ＩＰ又はイーサネットを介してトランスポートすることができるメッセージのＵＡＤＰ符号化に関連した一例として与えることができる。ＵＡＤＰメッセージマッピングは、種々の任意選択のヘッダフィールドと、フィールド設定と、種々のメッセージタイプ及びデータ符号化とを定義する。

【0029】

一般的なＵＡＤＰ ネットワークメッセージのレイアウトを図５に示す。ＰｕｂＳｕｂ通信構成パラメータに応じて、異なるヘッダ及びフィールドが存在する又は存在しない。セキュリティを使用するとき、ペイロード及びパディングフィールドが暗号化され、署名及び暗号化がアクティブとして構成されている場合には、ネットワークメッセージ全体が署名される。ネットワークメッセージは、署名のみがアクティブである場合にのみ署名される。

【0030】

図６は、ネットワークメッセージのペイロード及びペイロードヘッダの一般的なフォーマットを更に示している。ここでも同様に、ヘッダ及びフィールドは、データセットメッセージのレイアウト構成に応じて存在する場合もあるし、無視される場合もある。

【0031】

ＯＰＣ ＵＡ ＵＤＰ及びＯＰＣ ＵＡイーサネットの２つのトランスポートプロトコルが、ネットワークメッセージのトランスポート用に指定される。以下の詳細な説明では、ＯＰＣ ＵＡイーサネットのみが説明される。ＵＡＤＰ ネットワークメッセージは、１５２２バイトの最大サイズのＶＬＡＮタグ付きイーサネットＩＩフレームのペイロードとしてトランスポートされる。ＵＡＤＰ通信用にＩＥＥＥに登録されたＯＰＣ ＵＡイーサタイプは０ｘＢ６２Ｃである。

【0032】

ＴＳＮを介したトランスポートの場合には、ライタグループによって作成されたネットワークメッセージは、ＩＥＥＥ８０２．１ＣＢに仕様化されたストリーム識別機能によって識別することができるＴＳＮストリームを介して送信される。通常の識別機能は、デスティネーションＭＡＣアドレス又はソースＭＡＣアドレスを、ネットワークメッセージをカプセル化したイーサネットフレームのＶＬＡＮ－ＩＤと組み合わせて使用する。

【0033】

ＴＳＮタイミングパラメータ上へのＰｕｂＳｕｂレベルタイミングパラメータ（パブリッシング間隔及びパブリッシングオフセット）のマッピングは、主として、送信サイクルと、これらのサイクル内の送信時刻、すなわち送信オフセットとを定義することを可能にするＩＥＥＥ８０２．１Ｑｂｖによって提供されるスケジューリング方式を使用することによって行われる。

【0034】

固定されたレイアウトデータを有する周期的な通信のネットワークメッセージのフォーマットを以下に説明する。ネットワークメッセージ及びデータセットメッセージのＵＡＤＰヘッダフォーマットは、ヘッダ内の個々のフィールドを有効又は無効にすることによって、フレキシブルであるとともに種々のユースケースをサポートするように設計される。

【0035】

その結果、可能なヘッダフィールドの組み合わせの数は、それらの実施態様の複雑度を増加させる。逆に、特定のユースケースを有する或るアプリケーションドメインは、ヘッダレイアウトが、種々のユースケースのフレキシビリティ、相互運用性及びサポートの間の妥協を提供するヘッダオプションの妥当なセットを含む構成に依拠することができる。

【0036】

ＯＰＣ ＵＡパート１４の付属書Ｃは、これらのユースケースのうちの１つ、すなわち、リアルタイムデータのサイクリックな交換におけるＰｕｂＳｕｂの使用を示している。この構成では、あらゆるパブリッシング間隔の際に伝送されるデータのレイアウトは固定され、構成によってパブリッシャ及びサブスクライバから知られている。最適化は、データセットメッセージのサイズが一定であるときに更に推し進めることもできる。

【0037】

次に、以下の条件が仮定される。
・各ネットワークメッセージは、同じ数のデータセットメッセージを含む、
・ネットワークメッセージ内のデータセットメッセージのシーケンスは、あらゆるパブリッシング間隔にわたって同一である、
・あらゆるデータセットメッセージ内のフィールドのレイアウトは、あらゆるパブリッシング間隔にわたって同一である。

【0038】

パブリッシャＩｄ及びライタグループＩｄ（WriterGroupId）は、ライタグループを識別する。ネットワークメッセージ番号（NetworkMessageNumber）は、いくつかのネットワークメッセージにおいてそれらのデータセットを送信するライタグループに使用される。グループバージョン（GroupVersion）は、サブスクライバが、データセットメッセージ及びそれらのデータセットフィールドの予想されるレイアウトを検証することを可能にする。

【0039】

図７に示すヘッダのレイアウトは、セキュリティが実施されないときのこのユースケースを示している。セキュリティ（例えば署名のみ）が実施されるとき、ヘッダレイアウトは、図８ａに示すような追加のセキュリティヘッダ及び署名を含む。データセットメッセージのヘッダは、図８ｂに示すフィールドに削減される。

【0040】

メッセージレイアウトの例を以下に示す。第１の例は、セキュリティを有しない固定されたメッセージレイアウトである。この構成は、あらゆるネットワークメッセージが一定のヘッダ及びデータセットフィールドのレイアウトを有することを保証する。メッセージの符号化及び復号化は、全てのフィールドの一定のオフセットに起因して簡単化される。ペイロードヘッダ（Payload Header）は省略され、このヘッダが通常含む情報は、データセットメタデータ、データセットライタ及びライタグループの設定からサブスクライバによって導出される。この構成は、構成によって保証することができる各データセットメッセージの一定のサイズを仮定する。

【0041】

適切な構成は、データセットメッセージの数及びネットワークメッセージ内のそれらのシーケンスが、送信された全てのネットワークメッセージにわたって同一のままであることも保証する。これらの特性を図９に示す。

【0042】

第２の例は、セキュリティを有する固定されたメッセージレイアウトである。同じ構成は、セキュリティを用いて拡張することができ、図１０に示すコンパクト化されたネットワークメッセージフォーマットを与える。

【発明の概要】

【発明が解決しようとする課題】

【0043】

ＯＰＣ ＵＡは、その場合に、多種多様なアプリケーションドメインをサポートすることができる複雑なシステムのエンティティ間の情報の交換のための非常にフレキシブルな方式を指定する。このフレキシビリティは、これらの交換をサポートする通信プロトコルに反映される。

【0044】

このフレキシビリティは、図５に示す基本のネットワークメッセージのフォーマットによって示されるように、潜在的に拡大するオーバヘッドを犠牲にして得られる。図１９は、セキュリティを有しないＰｕｂＳｕｂ ネットワークメッセージに見ることができる種々のヘッダによって引き起こされるオーバヘッドをまとめた表を示している。

【0045】

（Ｎ＋１）個のデータセットライタの場合、このレイアウトは、
２１＋１１＋［１＋（Ｎ＋１）×２］＋１０＋ＰＦ＋（Ｎ＋１）×２＋ＰＬバイト
の最大メッセージ長をもたらす可能性がある。

【0046】

フィールドが昇格されない（ネットワークメッセージの非暗号化部分に複製されない）ことを考慮すると、これは、４７＋４Ｎバイトの潜在的なオーバヘッドを与える。

【0047】

上述したコンパクト化されたＵＡＤＰレイアウトを使用してサイクリックなデータを送信するとき、オーバヘッドは、図２０に示す残りの白地の行によって要約されるように削減される。

【0048】

データセットライタの数がいくつであっても、セキュリティを有しないコンパクト化されたレイアウトは、
４＋１１＋ＰＬバイト
の最大メッセージ長をもたらす可能性があり、１５バイトの潜在的なオーバヘッドを与える。

【0049】

コンパクト化されたＵＡＤＰレイアウトは、ＰｕｂＳｕｂオーバヘッドの大幅な削減をもたらすが、ＰｕｂＳｕｂオーバヘッドは、そのアプリケーション環境、特にペイロードが多くの場合に約１００バイトに制限される高速イーサネットＴＳＮベースの制御の環境では依然として考慮されなければならない。

【0050】

そのような構成では、
・ＭＡＣデスティネーションアドレス（６バイト）、
・ＭＡＣソースアドレス（６バイト）、
・ＶＬＡＮタグ（４バイト）、
・イーサタイプ（２バイト）、
から構成される最小のＭＡＣレイヤイーサネットオーバヘッドが、別の１８バイトをＯＰＣ ＵＡメッセージに加える。

【課題を解決するための手段】

【0051】

本発明は、この状況を改善することを目的とする。そのため、本発明は、ネットワーク上にパブリッシャデバイス及びサブスクライバデバイスを含む通信モードを有するネットワークにおいてメッセージを送信する方法であって、該方法は、
・受信されたメッセージのペイロードを抽出し、当該ペイロードを同じ組み合わされたメッセージ内で連結することと、
・上記組み合わされたメッセージにヘッダを追加することであって、当該ヘッダは、パブリッシャデバイスの単一の識別子を含み、当該パブリッシャ識別子は、組み合わされたメッセージを少なくとも１つの選ばれたサブスクライバデバイスに向けるように予め定められることと
を含む方法を対象とする。

【0052】

そのような実施態様の一例は、以下で解説する図１４に示されている。この図は、特に、前述の組み合わされたメッセージの構造（１つのヘッダを有するが、それぞれのデバイスから到来する多数の連結されたペイロードを有する）を示している。この実施態様によって、とりわけ、通常のコントローラデバイスのオーバヘッドを削減することが可能になる。

【0053】

通常、一実施の形態において、前述の選ばれたサブスクライバデバイスをそのコントローラデバイスとすることができる。このコントローラデバイスは、前述の受信されたメッセージを送出したネットワーク内のデバイスを制御する。

【0054】

特に、これらのネットワークデバイスの中でこの方法を実施する１つのデバイスを、コントローラデバイス及び／又は送出デバイスに対して基準に基づいて選択することができる。より詳細には、上記に示したような方法は、これらの送出デバイスのうちの１つによって実施することもできるし、これらの送出デバイスに接続され、それらのコントローラデバイスに関連した１つのデバイスによって実施することもできる。

【0055】

通常、前述の基準は、少なくともネットワークの現在のトポロジ（一方において送出デバイスと他方においてそれらのコントローラデバイスとの間の最適な中間デバイスを指定して上記方法を実施するために考慮される）を含むことができる。

【0056】

一実施の形態において、受信されたメッセージは、同じパブリッシャ識別子（図１４におけるパブリッシャＩｄ＝ｋ）を有するヘッダを有する一方、受信されたメッセージは、複数の異なるパブリッシャデバイスによって送出される。この方法を実行するデバイスは、その後、これらのメッセージを識別し、図１４に示すような１つの単一の組み合わされたメッセージに集約することができる。

【0057】

各受信されたメッセージは、当該受信されたメッセージを送出したデバイスに関連した識別子（通常のパブリッシャＩｄと異なる識別子とすることができ、例えば、これらのメッセージの受信の順序を定義することができるいわゆる「ライタグループＩｄ」（図１４では、＝１，２，３・・・）とすることができる）を含むことができる。加えて、この送出機識別子は、その実施の形態において、前述のペイロードの連結内の受信されたメッセージのペイロードの順序を定義する。これらの識別子は、規格の仕様「オープンプラットフォーム通信統一アーキテクチャ」から既に知られている。

【0058】

より一般的には、一実施の形態において、この方法に関与するデバイスを接続するネットワークは、「オープンプラットフォーム通信統一アーキテクチャ」というタイプの規格に従って運用され、パブリッシャデバイスの前述の単一の識別子はパブリッシャＩＤ識別子である。

【0059】

より詳細には、ネットワークは、「タイムセンシティブネットワーキング」というタイプの規格に従って更に運用することができる。

【0060】

通常、上記に示したように、送出機識別子は、パブリッシングオフセットのタイミングを定義し、それによって、上記ペイロードの連結内の受信されたメッセージのペイロードの順序を定義するライタグループＩＤのタイプとすることができる。

【0061】

その上、図１４に示すように、連結されたペイロードは、同じ所定のサイクル継続時間で受信されたメッセージから抽出することができる。通常、図１５に示す実施の形態において、このサイクル継続時間は、マルチプレクサデバイスのパブリッシング間隔に対応することができる。

【0062】

本発明は、マルチプレクサデバイスとして動作するように選択され、上記に示したような方法を実施するように構成される、ネットワークデバイスも対象とする。このデバイスは、現在のトポロジ（例えば、他のデバイスに対するネットワークにおけるその中心性）等の基準に従って、及び／又は、以下に示すように、デバイスのそれぞれの特定の機能にも従って選択することができる。

【0063】

本発明は、メッセージを送出するネットワークデバイスと、上記メッセージを受信し、上記に示したような方法を実施するように構成されるマルチプレクサデバイスとを備えるシステムも対象とする。

【0064】

本発明は、そのようなシステムのコントローラデバイスであって、
・所定のパブリッシャ識別子を有する組み合わされたメッセージを受信し、
・ペイロードの連結を解釈するように構成される
コントローラデバイスも対象とする。

【0065】

本発明は、命令を含むコンピュータプログラムであって、該命令は、ネットワークデバイスのプロセッサによって実行されると、上記に示したような方法をそのネットワークデバイスに実施させる、コンピュータプログラムも対象とする。本発明は、そのような命令を記憶する非一時的コンピュータ記憶媒体も対象とする。

【0066】

ネットワークのデバイス（通常は例えばコントローラデバイス）における上記に示すような組み合わされたメッセージ構造を含む信号の受信は、このデバイスにその信号を特定の方法で解釈させるので、本発明は、そのような信号も対象とする。この信号は、通常、ネットワークのパブリッシャデバイス及びサブスクライバデバイスを含む通信モードを有するネットワークにおいてパブリッシュされたメッセージのデータを含み、この信号は、
・パブリッシャデバイスの単一の識別子を含むヘッダのデータと、
・ネットワークのそれぞれのデバイスによって開始される複数の連結されたペイロードのデータと
を含む。

【0067】

本発明の可能な実施形態のより詳細な内容及び利点を、添付図面を参照して以下に示す。

【図面の簡単な説明】

【0068】

【図1】従来のパブリッシュ／サブスクライブ方式を示す図である。

【図2】データセット及びデータセットメッセージを示す図である。

【図3】ＰｕｂＳｕｂメッセージレイヤ及びカプセル化を示す図である。

【図4】ＰｕｂＳｕｂエンティティ及び交換メッセージを示す図である。

【図5】一般的なＵＡＤＰ ネットワークメッセージのフォーマットを示す図である。

【図6】ネットワークメッセージのペイロードの詳細及びデータセットメッセージのヘッダフォーマットを示す図である。

【図7】セキュリティを有しないサイクリックなＰｕｂＳｕｂ通信用のコンパクト化されたネットワークメッセージのフォーマットを示す図である。

【図8A】署名のみを有するサイクリックなＰｕｂＳｕｂ通信用のコンパクト化されたネットワークメッセージのフォーマットを示す図である。

【図8B】署名のみを有するサイクリックなＰｕｂＳｕｂ通信用のコンパクト化されたネットワークメッセージのフォーマットを示す図である。

【図9】セキュリティを有しない固定のコンパクト化されたメッセージレイアウトを示す図である。

【図10】セキュリティ（署名のみ）を有する固定のコンパクト化されたメッセージレイアウトを示す図である。

【図11】産業制御用のネットワークトポロジと、実施形態の一例に従って本発明を実施する特定のトポロジ（図１１の下部）の使用とを示す図である。

【図12】従来技術によるコントローラデバイスＰＬＣに向けた独立したネットワークメッセージを示す図である。

【図13】本発明による組み合わされたネットワークメッセージを示す図である。

【図14】マルチプレクサの動作を示す図である。

【図15】実施形態の一例における多重化レイテンシを最小にするネットワークメッセージのスケジューリングを示す図である。

【図16】いくつかのデバイス、この例ではネットワーク内のいくつかのコントローラを有するシステムを概略的に示す図である。

【図17】ネットワークのトポロジ及び／又はネットワーク内のデバイスの機能に従って作成され、特定のコントローラにリンクされたデバイスの各グループの可能なマルチプレクサデバイスを定義する対応表を示す図であり、このコントローラは、そのグループのデバイスによってパブリッシュされたメッセージに対するサブスクライバとして定義される。

【図18】本発明による方法（場合によっては、本発明によるコンピュータプログラムの一般的なアルゴリズムを表す）の可能なステップを示す図である。

【図19】セキュリティを有しないＰｕｂＳｕｂ ネットワークメッセージに見ることができる異なるヘッダによって引き起こされるオーバヘッドをまとめた表を示す図である。

【図20】サイクリックなデータがコンパクト化されたＵＡＤＰレイアウトを使用して送信されるときに、セキュリティを有しないＰｕｂＳｕｂ ネットワークメッセージに見ることができる種々のヘッダによって引き起こされるオーバヘッドをまとめた表を示す図である。

【発明を実施するための形態】

【0069】

本発明は、デバイス（通常、ネットワークにおける通信デバイスとしてのセンサ及び／又はアクチュエータ）のセットによって送信された独立したネットワークメッセージを単一のネットワークメッセージに組み合わせることによってＰｕｂＳｕｂ通信におけるオーバヘッドを削減することを提案する。以下に示すように、マルチプレクサデバイス（図１１の下部の参照符号ｍｕｘ）が、そのために以下のことを実施することができる。
・デバイスのＰｕｂＳｕｂパブリッシング機能の適合された構成を使用する。
・ＰｕｂＳｕｂ多重化機能を実施する。この多重化は、とりわけ、ネットワークトポロジにおけるロケーションに依存する可能性がある。
・ネットワークメッセージのスケジューリング機能を実施する。

【0070】

この実施によって、当初デバイスのセットによって生成された複数のネットワークメッセージを、サブスクライバによって受信される単一のネットワークメッセージに組み合わせることが可能になる。一実施形態において、サブスクライバは、単一のエンティティとすることができ、好ましくは、（図１１に示すようなＰＬＣリンクにわたる）ネットワークトポロジにおけるデバイス（センサ及び／又はアクチュエータ）のセットをローカルに制御するいわゆる「プログラマブルロジックコントローラ」（以下、ＰＬＣ（Programmable Logic Controller））等のコントローラデバイスとすることができる。

【0071】

図１１は、ＰＬＣ（プログラマブルロジックコントローラ）がデバイス（センサ及び／又はアクチュエータ）のセットを制御する産業生産ライン又は機械内に見ることができる制御トポロジの通常の実施形態を示している。コントローラとデバイスとの間の情報及びコマンドは、サイクリックに交換され、各デバイスは、通常、短い情報データ（例えば、１６ビットコマンド、８ビットカウンタ値等）をハンドリングする。

【0072】

従来技術の解決策では、ＯＰＣ ＵＡ ＰｕｂＳｕｂ通信を使用するとき、簡単な構成は、パブリッシャ及び／又はサブスクライバを含む各デバイスを有することとすることができる。そのようなマッピングでは、パブリッシャは、デバイスによって送信されるデータセットメッセージを含むネットワークメッセージを生成するライタグループを含む。各デバイスは、その場合に、図１２に示すように、ＰＬＣリンク上に一連のメッセージを生成するそれ自身の独立したネットワークメッセージを送信する。

【0073】

各サイクル内で対処することができるデバイスの数は、以下のものの関数である。
・サイクルの継続時間、
・ネットワークメッセージの長さ。

【0074】

ネットワークメッセージのオーバヘッドの総量、すなわちイーサネットオーバヘッド及びＰｕｂＳｕｂオーバヘッドによって占有されるリンク容量の部分は、以下の２つの二重の効果を有する。
・一定数のデバイスの制御サイクル継続時間の制限、
・１つのサイクル内で制御されるデバイスの数の制限。

【0075】

イーサネットＴＳＮネットワーク上でＯＰＣ ＵＡ ＰｕｂＳｕｂを実施するとき、イーサネットフレームヘッダに起因したオーバヘッドは圧縮可能でない。すなわち、双方のＭＡＣアドレス、ＶＬＡＮタグ及びイーサタイプは、ＴＳＮブリッジによる対応するストリームのハンドリングに必要とされる。したがって、ＰｕｂＳｕｂオーバヘッドの削減のみが上述した従来技術の制限の克服を可能にする。

【0076】

実際、図１２及び図１３の比較によって示すように、図１３に示すような本発明による
・異なるデバイスのペイロードを集約するとともに、
・１つの単一のパブリッシャを識別する単一のヘッダと、
・図１３の例における単一のイーサネットヘッダと、
を有する単一のネットワークメッセージが、上述したオーバヘッドを制限することを可能にする。

【0077】

そのような単一のネットワークメッセージのリーダの他方では、ＰＬＣのサブスクライバエンティティのリーダグループ（ReaderGroup）が、本明細書において以下に示すように、そのような単一のネットワークメッセージで受信されたデータセットメッセージを適切に解釈して多重分離するように構成される。

【0078】

デバイスのパブリッシャ構成に関して、ネットワークメッセージヘッダに関連した構成は、一実施形態において、ネットワークメッセージを組み合わせなければならない全てのデバイスが、分散したパブリッシャを形成するとみなされ、同じパブリッシャＩｄを用いて構成されるようになっている。

【0079】

グループヘッダ（Group Header）に関連した構成は、各デバイスがそれらのネットワークメッセージを、パブリッシャ内でデバイスを識別する特定のライタグループＩｄとともに送信するようになっている。

【0080】

ネットワークメッセージ番号は、所与のライタグループが、パブリッシング間隔又はサイクルごとに１つのネットワークメッセージしか送信しないという制約下では無視することができる。ライタグループがパブリッシング間隔ごとに数個のネットワークメッセージを送信する場合には、それらのネットワークメッセージは、一貫したネットワークメッセージ番号とともに連続して送信される。

【0081】

シーケンス番号（SequenceNumber）は、ライタグループによる各ネットワークメッセージの送信の際に単調増加する。

【0082】

ネットワークメッセージのペイロードに関連した構成は、ペイロードのレイアウトが、ＯＰＣ ＵＡパート１４の付属書Ｃに記載されているように保持されるようになっている、すなわち所定の一連の固定フォーマットデータセットメッセージである。

【0083】

データセットメッセージ内の個々のデータセットフィールドは、変更されずに保持される。

【0084】

各データセットメッセージ内のデータセットフィールドのうちの１つは、データセットメッセージ全体にわたって計算された完全性チェックコードの挿入用に確保することができる。この完全性コード（例えばＣＲＣ１６）は、その後、デスティネーションサブスクライバエンティティにおけるデータセットリーダが、データセットメッセージの有効性をチェックするために使用することができる。

【0085】

次に、多重化機能を以下に説明する。
ＰｕｂＳｕｂマルチプレクサは、イーサネットカプセル化ネットワークメッセージをそのネットワーク入力を介して受信することができ、組み合わされたイーサネットカプセル化ネットワークメッセージをそのネットワーク出力を介して送信する。ＰｕｂＳｕｂマルチプレクサは、図１１の下部に示すように、少なくとも２つの入力と単一の出力とを有する。

【0086】

デバイス内に統合されるとき、マルチプレクサの少なくとも１つの入力は、マルチプレクサと同じ場所に配置されたアプリケーションによって生成される未処理のネットワークメッセージ、すなわちイーサネットフレームにカプセル化されていないネットワークメッセージを受信する。

【0087】

図１４に示すように、マルチプレクサは、ネットワークメッセージの組み合わせを行う以下のいくつかのデータ構造及び変数に依拠する。
・各パブリッシャＩｄ、すなわち受信されたネットワークメッセージが組み合わされる各パブリッシャ、に関連付けられたペイロード送信バッファ（ＰＬＴｘＢｕｆ）。
・受信されたネットワークメッセージが組み合わされるパブリッシャに含まれる各ライタグループに関連付けられたペイロードオフセット（ＰＬＯｆｆｓｅｔ）。

【0088】

ＰＬＴｘＢｕｆｋは、パブリッシャｋに関連付けられている。
ＰＬＯｆｆｓｅｔｋｉは、パブリッシャｋ（パブリッシャＩｄ＝ｋ）に含まれるライタグループｉ（ライタグループＩｄ＝ｉ）に関連付けられている。ＰＬＯｆｆｓｅｔｋｉは、パブリッシャＩｄ＝ｋ及びライタグループＩｄ＝ｉとともに受信されたネットワークメッセージのペイロード（データセットメッセージ）が記憶されるＰＬＴｘＢｕｆｋのベースに対するオフセットを示す。

【0089】

マルチプレクサによって生成されるネットワークメッセージは、以下の情報を含む。
・ネットワークメッセージヘッダ内：パブリッシャＩｄ＝ｋ
・グループヘッダ内：
ライタグループＩｄ＝ｍｕｘ。ここで、ｍｕｘは、マルチプレクサに関連付けられた値である。
グループバージョン＝構成によって固定された、マルチプレクサエンティティに関連付けられた値。
ネットワークメッセージ番号＝１：パブリッシング間隔ごとに１つのネットワークメッセージのみがネットワークメッセージの組み合わせから生成されると仮定される。
シーケンス番号＝新たなネットワークメッセージが生成されるごとにマルチプレクサのネットワークメッセージ生成機能によってインクリメントされる値。

【0090】

組み合わされたネットワークメッセージ内のペイロードのレイアウト、特にデータセットメッセージの順序は、マルチプレクサ構成によって定義される。

【0091】

好ましい構成は、マルチプレクサによる余分な並べ替えを回避するために、特定のライタグループに関連付けられたデータセットメッセージを、着信したネットワークメッセージ内において当初からそうであるようにグループ化された状態に維持することである。

【0092】

ネットワークメッセージのスケジューリングを図１５に示す。通常、デバイス及びマルチプレクサに共通のパブリッシング間隔を利用して、ネットワークメッセージの組み合わせ動作のレイテンシを削減することが可能である。これは、デバイスに含まれるライタグループごとに適切なパブリッシングオフセットを構成することによって達成することができる。実際、ＴＳＮタイミングパラメータ上へのＰｕｂＳｕｂレベルタイミングパラメータ（パブリッシング間隔及びパブリッシングオフセット）のマッピングが、主として、送信サイクルに加えてこれらのサイクル内の送信時刻、すなわち送信オフセットを定義することを可能にするＩＥＥＥ８０２．１Ｑｂｖによって提供されるスケジューリング方式を使用することによって行われることを想起されたい。サイクリックな送信タイミングは、そのようなオフセット規格制約によって上記のように定義することができる。

【0093】

図１５（ネットワーク伝播遅延又は内部伝播遅延によって引き起こされる可能性があるレイテンシを考慮していない説明図）に示すように、デバイスライタグループのパブリッシングオフセットは、マルチプレクサがネットワークメッセージの組み合わせを行うために必要とされる最小のヘッドルームが設けられ、したがって、最小の多重化レイテンシが保証されるように構成することができる。

【0094】

次に図１６を参照すると、デバイスＤＥＶｉ、ＤＥＶｊ、・・・がパブリッシャであるときにＰＬＣ－Ａがサブスクライバとなるように、複数のデバイスＤＥＶｉ、ＤＥＶｊ、・・・をコントローラＰＬＣ－Ａにリンクすることができる。他のコントローラ（ＰＬＣ－Ｂ等）をネットワークに設けることが可能であり、他のパブリッシャデバイスＤＥＶｋ、ＤＥＶｌ等にリンクすることができる。もちろん、デバイスＤＥＶｉ、ＤＥＶｊ、・・・の中の１つ又はいくつかのデバイスを、第２のコントローラＰＬＣ－Ｂのパブリッシャとすることもできるし、逆に、ＤＥＶｋ、ＤＥＶｌ等の中の１つ又はいくつかのデバイスをコントローラＰＬＣ－Ａのパブリッシャとすることもできる。

【0095】

ネットワークの少なくとも１つのノードは、デバイスＤＥＶｉ、ＤＥＶｊ等によって送信されたＰｕｂＳｕｂメッセージを処理するマルチプレクサとして動作することができる。通常（強制的にということではない）、マルチプレクサは、ＤＥＶｉ、ＤＥＶｊ等の中で、ネットワークのトポロジ及び／又はノードのそれぞれの機能等に従って選ばれたデバイスとすることができる。任意選択で、いくつかのマルチプレクサは、一方においてデバイスＤＥＶｉ、・・・、ＤＥＶｍによって送信されたメッセージと、他方においてデバイスＤＥＶｍ＋１、・・・、ＤＥＶｊによって送信されたメッセージとをそれぞれ処理するために選ぶことができる。ここで、第３のマルチプレクサが、デバイスＤＥＶｉ、・・・、ＤＥＶｍのグループと、ＤＥＶｍ＋１、・・・、ＤＥＶｊのグループとの双方から受信されたＰｕｂＳｕｂメッセージを処理して、それらを共通のコントローラＰＬＣ－Ａ用に組み合わせることができる。

【0096】

したがって、ネットワークのノードのうちの少なくともいくつかは、図１３及び図１４に示すように、異なるＰｕｂＳｕｂメッセージを単一のメッセージに組み合わせ、異なるペイロード（データセットメッセージ）を加えるが単一のヘッダを維持するために多重化機能を有するようにプログラミングすることができる。通常、図１４の例では、メッセージを多重化するノードエンティティは、そのような多重化機能を用いてプログラミングされるデバイスｍである。他のデバイス１、２、・・・、ｎは、同じパブリッシャ識別子パブリッシャＩＤ＝ｋを有するそれらのメッセージをパブリッシュするようにプログラミングすることができる。このパブリッシャ識別子は、ｍと等しいものとすることもできるし、ｍと異なるものとすることもできる。デバイスｍが、パブリッシャＩＤ＝ｋの下でパブリッシュされたメッセージを受信したとき、デバイスｍは、それらを組み合わせるようにプログラミングされ、より詳細には、図１５を参照して上記で説明したように、それらのそれぞれのパブリッシングオフセットを考慮するために、それらのペイロードを、各メッセージヘッダに示されたライタグループＩＤに応じた順序で連結するようにプログラミングされる。別の実施形態において、図１４のパブリッシャデバイス１、２、・・・、ｎは、それらのメッセージをそれら自身のパブリッシャＩＤ（１、２、・・・、ｎ）とともにパブリッシュするようにプログラミングすることができ、多重化デバイスｍは、対応するデバイス１、２、・・・、ｎから受信されたメッセージを組み合わせるために、これらの識別子であるパブリッシャＩＤ（１、２、・・・、ｎ）を識別するようにプログラミングすることができる。

【0097】

図１６を再び参照すると、各デバイスは、通常、メモリＭＥＭＤと協働するプロセッサＰＲＯＣＤに接続された通信インタフェースＣＯＭＤを備えることができ、メモリＭＥＭＤは、パブリッシャのそれらの識別子であるパブリッシャＩＤ、ライタグループのそれらの識別子等のデータと、ペイロードととりわけそのような識別子を含むヘッダとを有するネットワークメッセージを作成して送信するコンピュータプログラムの命令とを記憶する。それらのパブリッシャＩＤが多重化デバイスのパブリッシャＩＤＩに置き換えられるいくつかの実施形態において、コンピュータプログラムは、そのような機能を適用することができる。より詳細には、これらのデバイスのうちの１つが、（例えばネットワークのトポロジに従って）多重化デバイスとして動作するように指定された場合に、コンピュータプログラム（このデバイスのメモリＭＥＭＤに記憶される）は、そのような多重化機能を用いて強化することができる。

【0098】

その上、各コントローラＰＬＣも、メモリＭＥＭＣと協働するプロセッサＰＲＯＣＣに接続された通信インタフェースＣＯＭＣを備えることができ、メモリＭＥＭＣは、とりわけ、マルチプレクサデバイスによってパブリッシュされた、組み合わされたメッセージ（及びその組み合わされたペイロード）を解釈するコンピュータプログラムの命令を記憶する。

【0099】

次に図１７を参照すると、とりわけネットワークトポロジ及び／又はネットワークにおけるデバイス機能に従って対応表を（例えばネットワークスケジューラによって）定義することができる。この表は、したがって、各コントローラＰＬＣ－Ａ；ＰＬＣ－Ｂ等については、以下のものを定義することができる。
・このコントローラのパブリッシャデバイスとすることができるデバイス（それぞれＤＥＶｉ、ＤＥＶｊ等；ＤＥＶｋ、ＤＥＶｌ等）、及び
・そのようなパブリッシャデバイスによってパブリッシュされたメッセージを組み合わせるマルチプレクサデバイス（ＤＥＶｍ１；ＤＥＶｍ２）。

【0100】

コントローラＰＬＣ－Ａ、ＰＬＣ－Ｂ等がいくつかのメッセージを受信し、それらのヘッダを解釈するためのオーバヘッドは、したがって、コントローラ側において単一のメッセージで受信されたペイロードのみを処理するために、マルチプレクサＤＥＶｍ１、ＤＥＶｍ２において追放することができる。

【0101】

その上、各コントローラは、１つのサイクル内でより多くのメッセージを処理し、その後、より多くのデバイスを制御することもできるし、同じ数のデータの送信（又は最終的に同じ数のデバイスの制御）を行う制御サイクルをより短くすることもできる。

【0102】

次に図１８を参照すると、第１のステップＳ１において、図１７を参照して上記に示したような対応表を（例えばネットワークスケジューラ側において）定義することができる。この表の命令は、ステップＳ２において少なくとも各マルチプレクサデバイスに送信することができる。各マルチプレクサデバイスは、一実施形態において少なくとも以下のものを記憶する。
・マルチプレクサデバイスｍ及び対応するコントローラＰＬＣ－ＡがリンクされるグループのパブリッシャＩＤ＝ｋ、及び
・任意の今後組み合わされるネットワークメッセージのヘッダが含むライタグループＩＤ＝ｍ。

【0103】

このステップＳ２では、メッセージがサブスクライバとしてのＰＬＣ－Ａを用いてパブリッシュされるときにパブリッシャＩＤ＝ｋを使用するために、パブリッシャＩＤ＝ｋもデバイスＤＥＶ１、ＤＥＶ２等に送信することができる。コントローラＰＬＣ－Ａは、組み合わされたメッセージがそのようなパブリッシャＩＤとともに受信されたときに、この組み合わされたメッセージを考慮するために、パブリッシャＩＤ＝ｋも記憶することができる。

【0104】

この実施形態においては、ステップＳ３において、マルチプレクサデバイスＭＵＸは、デバイスＤＥＶ１、ＤＥＶ２、ＤＥＶ３等によってパブリッシュされたメッセージを、パブリッシャＩＤ＝ｋ（マルチプレクサデバイスにそれらのメッセージを考慮させる）及びそれら自身のライタグループＩＤ＝１、３、２等とともに受信する。これらのそれぞれの識別子であるライタグループＩＤ＝１、３、２に基づいて、マルチプレクサデバイスは、ステップＳ４において、対応するオフセットを用いて、これらのメッセージのペイロードの順序を管理し、場合によっては、その順序を並べ替える（ペイロードの順序は、例えば＃１、次に＃２、次に＃３となる）ように構成される。

【0105】

グループ（パブリッシャＩＤ＝ｋ）からメッセージを受信し、それらのペイロードを組み合わせるステップＳ３及びＳ４は、１つのサイクルがステップＳ５において終了するまで実行することができる。好ましくは、ペイロードは、メッセージがデバイスＤＥＶ１、ＤＥＶ２及びＤＥＶ３から受信されるとすぐに組み合わされ、ペイロードの組み合わせを実施するためにサイクルの終了を待つ必要はない。そのサイクルの継続時間は、図１５に示すように、マルチプレクサデバイスのパブリッシング間隔によって定義することができる。パブリッシングオフセットは、ネットワークメッセージを送信することができる時刻をサイクルの開始を基準として定義する。そのために、パブリッシング間隔及びパブリッシングオフセットは、ステップＳ２においてマルチプレクサデバイスによって記憶される他のデータとすることができる。

【0106】

サイクルの終了前（テストＳ５からの矢印ＫＯ）、マルチプレクサは、デバイスＤＥＶ１、ＤＥＶ２、ＤＥＶ３から連続して受信され、その順序で配置されたメッセージの連続するペイロードを含む連結されたネットワークメッセージを送信することができる。マルチプレクサは、このペイロードに少なくとも以下のものを追加する。
・コントローラＰＬＣ－Ａが、その順序で配置されたこれらのペイロードの組み合わせから得られるメッセージを考慮するように、グループのパブリッシャＩＤ（＝ｋ）、
・いくつかの組み合わされたメッセージ間で優先順位を調停する必要がある他の任意のマルチプレクサ又はコントローラがライタグループＩＤ＝ｍによって与えられるそのオフセットを使用することができるように、それ自身のライタグループＩＤ（＝ｍ）。

【0107】

実際、この情報ライタグループＩＤは、ＰｕｂＳｕｂメッセージの一般的にはパブリッシングオフセットを管理することを確かに可能にすることが想起される。

【0108】

最後に、ステップＳ７において、マルチプレクサデバイスは、サブスクライバとしてのコントローラＰＬＣ－Ａによって考慮されるように、このヘッダを有する組み合わされた新たなメッセージをパブリッシュする。

【0109】

テストＳ５からの矢印ＯＫは、現在のサイクルが終了したときの状況に対応し、新たなサイクルを開始するために、マルチプレクサデバイスは、新たなメッセージがデバイスＤＥＶ１、ＤＥＶ２、ＤＥＶ３、又は場合によっては他のデバイスから受信されるのを待機する。

【0110】

したがって、本発明は、ＩＥＥＥ８０２．１ＴＳＮ規格及びＯＰＣ ＵＡパート１４（ＰｕｂＳｕｂ）規格に仕様化された異なるメカニズムを利用し、その実施に更なる標準化は必要とされないことは明らかである。

【0111】

この最適化は、ＯＰＣ ＵＡ Ｐｕｂ通信性能の改善を可能にするので、本発明は、もちろんＯＰＣ ＵＡ ＰｕｂＳｕｂベースの制御システムに有利に適用することができ、したがって、高性能（短い制御ループ）のＯＰＣ ＵＡ ＰｕｂＳｕｂベースのファクトリオートメーション製品を提供する。ただし、同じ原理は、同種の情報編成を使用する他の通信プロトコルに適用することができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【手続補正書】

【提出日】2022-08-29

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

オープンプラットフォーム通信統一アーキテクチャというタイプの規格に従って運用されるネットワークにおいてネットワークメッセージを送信する方法であって、前記ネットワークは、該ネットワーク上にパブリッシャデバイス及びサブスクライバデバイスを含む通信モードを有し、該方法は、
受信されたネットワークメッセージのペイロード（データセットメッセージ）を抽出することであって、各受信されたネットワークメッセージは、該受信されたネットワークメッセージを送出したデバイスである送出デバイスに関連したパブリッシングオフセットのタイミングを定義する識別子であるライタグループＩＤを含むことと、
前記ペイロードを同じ組み合わされたネットワークメッセージ内で連結することであって、送出機識別子である前記ライタグループＩＤは、前記パブリッシングオフセットのタイミングを定義し、それによって、前記ペイロードの連結内の前記受信されたメッセージの前記ペイロードの順序を定義することと、
前記組み合わされたネットワークメッセージにヘッダを追加することであって、前記ヘッダは、パブリッシャデバイスの単一の識別子（パブリッシャＩＤ＝ｋ）であるパブリッシャ識別子を含み、前記パブリッシャ識別子は、パブリッシャＩＤのタイプを有し、前記組み合わされたネットワークメッセージを少なくとも１つの選ばれたサブスクライバデバイスに向けるように予め定められることと
を含む方法。

【請求項2】

前記選ばれたサブスクライバデバイスは、前記受信されたネットワークメッセージを送出するネットワークデバイスのコントローラデバイスである請求項１に記載の方法。

【請求項3】

前記ネットワークデバイスの中で前記方法を実施するデバイスが、前記コントローラデバイス及び／又は前記送出デバイスに対する基準に基づいて選択される請求項２に記載の方法。

【請求項4】

前記基準は、少なくとも前記ネットワークの現在のトポロジを含む請求項３に記載の方法。

【請求項5】

前記受信されたネットワークメッセージは、同じ前記パブリッシャ識別子を有するヘッダを有する一方、前記受信されたネットワークメッセージは、複数の異なるパブリッシャデバイスによって送出される請求項１から請求項４までのいずれか１項に記載の方法。

【請求項6】

前記ネットワークは、タイムセンシティブネットワーキングというタイプの規格に従って更に運用される請求項１から請求項５までのいずれか１項に記載の方法。

【請求項7】

前記連結されたペイロードは、同じ所定のサイクル継続時間（パブリッシング間隔）内で受信されたメッセージから抽出される請求項１から請求項６までのいずれか１項に記載の方法。

【請求項8】

マルチプレクサデバイスとして動作するように選択され、請求項１から請求項７までのいずれか１項に記載の方法を実施するように構成されるネットワークデバイス。

【請求項9】

前記ネットワークメッセージを送出するネットワークデバイスと、前記ネットワークメッセージを受信し、請求項１から請求項７までのいずれか１項に記載の方法を実施するように構成されるマルチプレクサデバイスとを備えるシステム。

【請求項10】

請求項９に記載のシステムのコントローラデバイスであって、所定の前記パブリッシャ識別子を有する前記組み合わされたネットワークメッセージを受信し、前記ペイロードの連結を解釈するように構成されるコントローラデバイス。

【請求項11】

命令を含むコンピュータプログラムであって、該命令は、ネットワークデバイスのプロセッサ（ＰＲＯＣＣ；ＰＲＯＣＤ）によって実行されると、請求項１から請求項７までのいずれか１項に記載の方法を前記ネットワークデバイスに実施させるコンピュータプログラム。

【請求項12】

請求項１から請求項７までのいずれか１項に記載の方法の実施から得られ、したがって、ネットワークのパブリッシャデバイス及びサブスクライバデバイスを含む通信モードを有する前記ネットワークにおいてパブリッシュされるネットワークメッセージのデータを含む信号であって、
該信号は、
パブリッシャデバイスの単一の識別子を含むヘッダのデータと、
前記ネットワークのそれぞれのデバイスによって開始される複数の連結されたペイロードのデータと
を含む信号。

【国際調査報告】