6247597 制御装置

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6247597

(24)【登録日】2017年11月24日

(45)【発行日】2017年12月13日

(54)【発明の名称】制御装置

(51)【国際特許分類】

   H04L 29/08 20060101AFI20171204BHJP

   H04L 12/42 20060101ALI20171204BHJP

   G06F 9/48 20060101ALI20171204BHJP

   G06F 9/54 20060101ALI20171204BHJP

【ＦＩ】

   H04L13/00 307Z

   H04L12/42 B

   G06F9/46 452F

   G06F9/46 480A

【請求項の数】7

【全頁数】18

(21)【出願番号】特願2014-110402(P2014-110402)

(22)【出願日】2014年5月28日

(65)【公開番号】特開2015-226215(P2015-226215A)

(43)【公開日】2015年12月14日

【審査請求日】2016年11月29日

(73)【特許権者】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110000279

【氏名又は名称】特許業務法人ウィルフォート国際特許事務所

(72)【発明者】

【氏名】望月 義則

(72)【発明者】

【氏名】横田 大輔

(72)【発明者】

【氏名】森 駿介

【審査官】 野元 久道

(56)【参考文献】

【文献】 特開２００６−３３１２０７（ＪＰ，Ａ）

【文献】 特開平０３−０４００３４（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ２９／０８

Ｇ０６Ｆ ９／４８

Ｇ０６Ｆ ９／５４

Ｈ０４Ｌ １２／４２

(57)【特許請求の範囲】

【請求項1】

予め定められたアプリケーション実行周期を示す処理情報と、ネットワークを介して接続された他制御装置との通信の計画を示す通信情報とを記憶する記憶部と、
前記アプリケーション実行周期毎に前記アプリケーションを実行し、処理の要求である処理要求メッセージを前記他制御装置から受信した場合に前記処理を実行し前記処理の結果を含む処理応答メッセージを前記他制御装置へ送信する応答処理を実行する処理部と、
を備え、
前記処理部は、
予め定められた前記アプリケーション実行周期である応答時間内に前記応答処理を完了することを通信条件とし、前記他制御装置からの前記通信の要求を受信した場合、前記処理情報及び前記通信情報に基づいて、前記通信が前記通信条件を満たすか否かを判定し、前記判定の結果を示す判定情報を前記他制御装置へ送信し、
前記通信の要求である通信要求メッセージを前記他制御装置から受信した場合、前記通信が前記通信条件を満たすか否かを判定し、
前記通信が前記通信条件を満たすために、予め定められた前記アプリケーション実行周期である受信時間内に受信可能な処理要求メッセージの数である上限受信数を算出し、
前記通信要求メッセージを前記他制御装置から受信した場合、前記通信情報に基づいて、前記受信時間内に受信される予定の処理要求メッセージの数である受信数を算出し、前記受信数が前記上限受信数以下であることを前記通信条件とし、
前記処理情報は更に、前記アプリケーション実行周期内の前記アプリケーションの動作期間の長さである動作時間と、前記応答処理の時間の長さである応答処理時間とを含み、
前記処理部は、前記アプリケーション実行周期内で前記動作期間以外の期間に実行可能な応答処理の数である上限応答処理数を算出し、前記上限応答処理数に基づいて上限受信数を決定する、
制御装置。

【請求項2】

前記処理情報は更に、前記動作期間中に受信して格納することが可能な処理要求メッセージの数である上限格納数を含み、
前記処理部は、前記上限格納数に基づいて上限受信数を決定する、
請求項１に記載の制御装置。

【請求項3】

前記処理部は、前記上限応答処理数及び前記上限格納数のうち小さい方を前記上限受信数として決定する、
請求項２に記載の制御装置。

【請求項4】

前記通信が前記通信条件を満たすと判定された場合、前記処理部は、処理要求メッセージの送信周期である要求送信周期を示す情報を、前記他制御装置へ送信し、
前記処理要求メッセージは、前記要求送信周期毎に、前記他制御装置から送信される、
請求項３に記載の制御装置。

【請求項5】

前記処理部は、前記処理要求メッセージを受信した時刻から、前記処理を完了した時刻までの処理時間を計測し、前記処理時間が前記動作時間より長いか否かを判定し、前記処理時間が前記動作時間より長いと判定された場合、前記他制御装置へエラーを示す応答を送信する、
請求項４に記載の制御装置。

【請求項6】

前記処理部は、第２通信を要求する第２通信要求メッセージを前記他制御装置へ送信し、前記他制御装置により前記第２通信が前記通信条件を満たすと判定され、第２要求送信周期を示す情報を前記他制御装置から受信した場合、前記第２要求送信周期毎に、前記第２処理要求メッセージを前記他制御装置へ送信する、
請求項１に記載の制御装置。

【請求項7】

前記通信が前記通信条件を満たすと判定され、且つ前記他制御装置から応答送信周期を示す情報を受信した場合、前記処理部は、前記応答送信周期毎に、前記処理を実行し前記処理の結果を示す処理応答メッセージを前記他制御装置へ送信する、
請求項１に記載の制御装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ノードがネットワークを介して接続された他のノード内のデータにアクセスする技術に関する。

【背景技術】

【0002】

制御システムにおいて、計算機やコントローラ等の処理装置（以下、ノードと呼ぶ）上で動作するアプリケーションは、そのノードにネットワークを介して接続された複数の他ノードに存在するデータを利用して一定周期で動作する。アプリケーションが利用するデータの中には、他ノード上で動作するアプリケーションにより更新されるデータも存在する。この場合、他ノード上で動作するアプリケーションも一定周期で動作しているため、その更新は一定周期で行われる。

【0003】

アプリケーションの実行結果は、更新前のデータを利用した場合と更新後のデータを利用した場合で異なる可能性があるため、アプリケーションを安定的に動作させるためには、常にどちらかのデータを利用する必要がある。

【0004】

このようなデータ品質を一定にする方法として、特許文献１には、複数のノード間において周期的な同報送信によりデータ共有する転写メモリシステムが記載されている。

【0005】

この転写メモリシステムにおいて、アプリケーションが周期的にデータ更新を行ったタイミングで、同報送信を行うことにより、常に更新後のデータがシステム内で共有されることになるため、安定的なアプリケーションの動作を実現することが可能となる。

【0006】

ただし、特許文献１に記載されている技術では、予めノード毎に利用できるメモリ領域を固定化する方法がとられているため、制御アプリケーションがシステム更新を行うときや、メモリ領域の使い勝手の向上させたいときに、各ノードのメモリ使用領域の変更が必要な場合には適用することが困難であった。

【0007】

特許文献１の課題を解決する技術として、特許文献２には、各ノードが、メモリ上の領域毎に、この領域を確保しているノードの識別情報を示す領域管理情報を格納する転写メモリシステムが記載されている。

【0008】

各ノードが領域管理情報を格納することにより、もし、メモリ使用領域を変更する場合には、その領域管理情報にその旨を設定し、同報通信することにより、他ノードにも、その変更を通知することが可能となり、システム動作中のメモリ使用領域の変更が可能となる。

【先行技術文献】

【特許文献】

【0009】

【特許文献1】特開平１１−３４１０３８号公報

【特許文献2】特開２００８−５９４２０号公報

【発明の概要】

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

【0010】

同報通信を送信するノード上のアプリケーションの変更により、システムで共有されるデータを追加する場合、特許文献２に記載の技術を利用することにより、追加されたデータを設定するメモリ領域を確保することが可能となり、追加されたデータをシステム内で共有することが可能となる。

【0011】

しかし、同報通信を受信するノード上のアプリケーションの変更により、システムで共有されていないデータが必要となった場合、そのデータを取得することはできないため、アプリケーションを正確に動作させることができない可能性がある。

【0012】

このようなデータを取得するために、アプリケーションの動作に必要なデータを持つノードに対して直接データを要求する問合せ型データアクセス方式が考えられる。しかし、問合せ型データアクセス方式では、問合せ元のタイミングでデータを要求するため、応答として得られるデータの品質を一定に保つことが難しい。データの品質が一定に保たれなければ、アプリケーションを安定して動作させることができない場合がある。

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

【0013】

上記課題を解決するために、本発明の一態様である制御装置は、予め定められたアプリケーション実行周期を示す処理情報と、ネットワークを介して接続された他制御装置との通信の計画を示す通信情報とを記憶する記憶部と、前記アプリケーション実行周期毎に前記アプリケーションを実行し、処理の要求である処理要求メッセージを前記他制御装置から受信した場合に前記処理を実行し前記処理の結果を含む処理応答メッセージを前記他制御装置へ送信する応答処理を実行する処理部と、を備える。前記処理部は、予め定められた応答時間内に前記応答処理を完了することを通信条件とし、前記他制御装置からの前記通信の要求を受信した場合、前記処理情報及び前記通信情報に基づいて、前記通信が前記通信条件を満たすか否かを判定し、前記判定の結果を示す判定情報を前記他制御装置へ送信する。

【発明の効果】

【0014】

本発明の一態様によれば、制御装置は、要求の受信からその応答の送信までの時間を予め定められた時間内に完了することができる。

【図面の簡単な説明】

【0015】

【図1】本発明の実施形態の制御システムの構成を示す。

【図2】ノード１００の構成を示す。

【図3】アプリケーション実行周期１７１とアプリケーション実行時間１７２との関係を示す。

【図4】応答送信管理テーブル１３０と要求送信管理テーブル１４０を示す。

【図5】通信ミドルウェア１６０の機能構成を示す。

【図6】上限受信量決定処理のフローを示す。

【図7】通信処理のシーケンスを示す。

【図8】要求元におけるコネクション確立処理及びデータ取得処理のフローを示す。

【図9】要求先におけるコネクション確立処理及びデータ取得処理のフローを示す。

【図10】データ取得要求メッセージの受信タイミングを示す。

【図11】要求先におけるデータ取得処理のフローを示す。

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

【0016】

以下、本発明の実施形態を図面に基づいて詳細に説明する。尚、本発明の実施形態を説明する図において、同一部には同一の符号を付し、その繰り返しの説明は、省略することにする。

【0017】

図１は、本発明の実施形態の制御システムの構成を示す。この制御システムは、複数のノード１００（１００ａ，１００ｂ，１００ｃ，１００ｄ）を含む。或るノード１００は、ネットワーク１１４経由で、他ノードに記憶されたデータへのアクセスを行う。なお、システム内のノード数は、この図に例示した数に限定されない。例えば、各ノードは、制御対象機器に接続され、制御対象装置の監視や制御を行う制御装置である。

【0018】

図２は、ノード１００の構成を示す。ノード１００は、コントローラ（制御装置）、ワークステーション、パーソナルコンピュータ等のコンピュータである。

【0019】

ノード１００は、ハードウェアモジュールとして、揮発／不揮発性メモリやハードディスク装置等を含む記憶部１１１と、中央処理装置（ＣＰＵ：Central Processing Unit）等を含む処理部１１２と、通信インタフェース（通信Ｉ／Ｆ）１１３とを含む。この通信インタフェース１１３は、ネットワーク１１４との接続を行うインタフェースであり、イーサネット（登録商標）や無線ＬＡＮ（Local Area Network）などの通信インタフェースが該当する。記憶部１１１は、プログラム及びデータを格納する。処理部１１２は、記憶部１１１に格納されたプログラムを実行する。

【0020】

記憶部１１１は、プログラムとして、ＯＳ１５０、通信ミドルウェア１６０、アプリケーション１７０（１７０ａ、１７０ｂ）を実行する。記憶部１１１は更に、データとして、設定ファイル１２０と、応答送信管理テーブル１３０と、要求送信管理テーブル１４０とを格納する。記憶部１１１は更に、他ノードからアクセス可能な領域である共有メモリ領域１８０を含む。

【0021】

設定ファイル１２０は、アプリケーション１７０の実行の周期を示すアプリケーション実行周期１７１と、アプリケーション実行周期１７１内のアプリケーション１７０の実行時間であるアプリケーション実行時間１７２と、他ノードからのデータ取得要求メッセージの受信からその応答メッセージの送信までのデータ取得処理に掛かる時間（以下、データ取得処理時間と呼ぶ）と、ＯＳ１５０により確保されたバッファにおいて、通信インタフェース１１３により受信されバッファに保存できるメッセージの最大数である最大格納メッセージ数と、それぞれのノード１００を一意に識別するノードアドレスに関する情報とを含む。

【0022】

データ取得要求メッセージは、システム内のノード１００に対して、そのノード１００の記憶部１１１に格納されたデータにアクセスするために送信されるメッセージである。以後、データ取得要求メッセージを送信するノード１００を要求元と呼び、データ取得要求メッセージを受信するノード１００を要求先と呼ぶ。

【0023】

本実施形態の制御システム、データ取得要求メッセージの送受信方式として、単発型要求メッセージ方式と、周期型要求メッセージ方式がある。

【0024】

単発型要求メッセージ方式において、データ取得要求メッセージを受信したノード１００は、その受信毎に、記憶部１１１に格納されたデータをデータ取得応答メッセージとして送信する。これにより、要求先は、要求元からのデータ取得要求メッセージに応じてデータ取得応答メッセージを送信することができる。

【0025】

一方、周期型要求メッセージ方式において、一度だけデータ取得要求メッセージを受信したノード１００は、データ取得要求メッセージに示された周期で応答メッセージを自発的に送信する。これにより、その後、要求元がデータ取得要求メッセージを送信しなくても要求先が与えられた周期でデータ取得応答メッセージを送信することができる。

【0026】

なお、データ取得要求メッセージには、データアクセスの対象データの数、要求先の共有メモリ領域１８０内で対象データが格納された先頭のメモリアドレス、そのデータサイズ、周期型要求メッセージ方式のために応答メッセージを送信する周期などを含む。

【0027】

図３は、アプリケーション実行周期１７１とアプリケーション実行時間１７２との関係を示す。この図に示すように、一般的に、制御システム上で動作するアプリケーション１７０は一定の周期であるアプリケーション実行周期１７１が経過する度に、一定のアプリケーション実行時間１７２の長さを有するアプリケーション実行期間だけ動作する。ノード１００が複数のアプリケーション１７０ａ、１７０ｂを実行する場合、アプリケーション実行期間は、複数のアプリケーション１７０ａ、１７０ｂの実行期間を合わせた期間である。この場合のアプリケーション実行時間１７２は、複数のアプリケーション１７０ａ、１７０ｂの実行時間の合計である。アプリケーション実行周期１７１の中で、アプリケーション実行期間以外の期間をアプリケーション待機期間と呼ぶ。

【0028】

ノード１００は、他ノードよりデータ取得要求メッセージを受信すると、アプリケーション待機期間においてデータ取得要求メッセージを解析し、データ取得要求メッセージにより指定されたデータを記憶部１１１から取得し、取得されたデータを応答メッセージとして他ノードへ送信するデータ取得処理を行う。

【0029】

アプリケーション実行周期１７１と比較して、アプリケーション実行時間１７２が小さい場合や、受信したデータ取得要求メッセージの数が少ない場合、ノード１００は、アプリケーション待機期間にデータ取得処理を行うことが可能である。

【0030】

しかし、アプリケーション実行周期１７１とアプリケーション実行時間１７２がほとんど同じ場合などは、そのデータ取得処理を行う時間がほとんどないため、ノード１００は、或るアプリケーション実行周期で受信されたデータ取得要求メッセージのデータ取得処理を、次のアプリケーション実行周期に行う可能性がある。

【0031】

この場合、要求先によるデータ取得処理のタイミングが、要求されたデータが更新する前であるのか、更新する後であるのか分からない。そのため、例えば、アプリケーション１７０が制御ロジックや故障／事故の解析のように、データ取得要求を複数回発行する場合、そのデータの更新タイミングの違いにより、予想通りの動作ができない場合があるため、上記のような要求／応答型のデータアクセスを制御システムに適用できない場合がある。

【0032】

そのため、本実施例の制御システムは、一つのアプリケーション実行周期内で、要求先がデータ取得要求メッセージの受信とその応答メッセージの送信とを実行できるように、要求元によるデータ取得要求メッセージの送信を制御する。

【0033】

図４は、応答送信管理テーブル１３０と要求送信管理テーブル１４０を示す。

【0034】

応答送信管理テーブル１３０は、他ノードから受信されたデータ取得要求メッセージを示すテーブルであり、データ取得要求メッセージ毎のエントリを含む。一つのコネクションに対応するエントリは、要求元ノードアドレス１３１と、要求先頭メモリアドレス１３２と、データサイズ１３３と、応答送信周期１３４とを含む。要求元ノードアドレス１３１は、当該データ取得要求メッセージの要求元のノードアドレスを示す。ノードアドレスは例えば、ＩＰ（Internet Protocol）アドレス等のネットワークアドレスである。要求先頭メモリアドレス１３２は、当該データ取得要求メッセージに含まれ、取得の対象データの先頭のメモリアドレスを示す。データサイズ１３３は、当該データ取得要求メッセージに含まれるデータサイズを示す。応答送信周期１３４は、当該データ取得要求メッセージに含まれ、応答メッセージの送信の周期を示す。これらの項目のうち、要求先頭メモリアドレス１３２と、データサイズ１３３と、応答送信周期１３４は、周期型要求メッセージ方式のデータ取得要求メッセージに含まれ、単発型要求メッセージ方式のデータ取得要求メッセージに含まれない。

【0035】

周期型要求メッセージ方式において、要求先は、要求先頭メモリアドレス１３２に示されたアドレスからデータサイズ１３３が示すサイズ分のデータを、応答送信周期１３４に示された周期で、応答メッセージとして送信する。周期型要求メッセージ方式を用いることにより、要求先は、要求元とのコネクションが確立されれば、要求元からのデータ取得要求メッセージを受信しなくても、応答送信周期１３４の経過毎に応答メッセージを送信することができる。

【0036】

この応答送信管理テーブル１３０によれば、要求先は、要求元からの受信の計画を管理することができる。

【0037】

要求送信管理テーブル１４０は、要求元がデータ取得要求メッセージの送信タイミング制御に利用するテーブルであり、コネクションを確立した要求先毎のエントリを含む。一つの要求先に対応するエントリは、要求先ノードアドレス１４１と、要求送信周期１４２とを含む。要求先ノードアドレス１４１は、データ取得要求メッセージを送信するノードアドレスを示す。要求送信周期１４２は、要求先ノードアドレス１４１が示すノード１００にデータ取得要求メッセージを送信する周期を示す。

【0038】

要求元は、要求先ノードアドレス１４１に示されたノード１００に対し、要求送信周期１４２毎にデータ取得要求メッセージを送信する。要求元が要求先から受信した要求送信周期１４２の経過毎にデータ取得要求メッセージを送信することにより、要求先のデータ取得要求メッセージの受信数を制限することができる。

【0039】

この要求送信管理テーブル１４０によれば、要求元は、要求先への送信の計画を管理することができる。

【0040】

ＯＳ１５０は、ノード１００の動作を統括的に制御する基本ソフトウェアである。

【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】

コネクション確立処理（Ｓ７００）の結果、コネクション確立ができる場合（Ｓ７２０のＹｅｓの場合）、通信ミドルウェア１６０はノード１００ｂの記憶部１１１に格納されたデータにアクセスするデータ取得処理を実行し（Ｓ８００）、その実行結果であるデータ取得応答を、アプリケーション１７０ａに通知する（Ｓ８２０）。周期型要求メッセージ方式の場合、Ｓ８００及びＳ８２０が繰り返し行われる。

【0069】

以上の通信処理によれば、要求元は、要求先との通信によりコネクションを確立し、コネクションが確立されれば、要求先からデータを取得することができる。

【0070】

図８は、要求元におけるコネクション確立処理及びデータ取得処理のフローを示す。

【0071】

コネクション確立処理（Ｓ７００）において、ノード１００ａの通信ミドルウェア１６０のデータ取得要求受付部１６３は、アプリケーション１７０ａよりデータ取得要求を受信すると、その受信内容を解析し、要求送信管理テーブル１４０を参照する（Ｓ７１０、Ｓ７１２）。

【0072】

要求送信管理テーブル１４０に、要求先のノードアドレスが含まれている場合、データ取得要求受付部１６３は、コネクション確立済みと判断し（Ｓ７１４のＹｅｓの場合）、データ取得処理（Ｓ８１０以降）を実行する。

【0073】

要求送信管理テーブル１４０に、要求先のノードアドレスが含まれていない場合、データ取得要求受付部１６３は、コネクションが未確立と判断し（Ｓ７１４のＮｏの場合）、コネクション処理を実行するために、メッセージ生成／送信部１６１は、コネクション確立要求メッセージを生成し、コネクション確立要求メッセージをノード１００ｂに対して送信する（Ｓ７１６）。

【0074】

コネクション確立要求メッセージを送信後、メッセージ解析／受信部１６２が、その要求に対するコネクション確立応答メッセージを受信、解析した結果（Ｓ７１８）、コネクション確立が可能と判断された場合（Ｓ７２０のＹｅｓの場合）、データ取得要求受付部１６３は、要求先ノードアドレス１４１と、その応答に含まれる要求送信周期１４１とを、要求送信管理テーブル１４０に設定し、データ取得処理（Ｓ８１０以降）へ移行する。

【0075】

解析した結果、コネクション確立が困難と判断された場合（Ｓ７２０のＮｏの場合）、データ取得要求受付部１６３は、アプリケーション１７０ａに対して、データ取得ができないことを通知する（Ｓ８２０）。

【0076】

以上が要求元のノード１００ａにおけるコネクション確立処理の説明である。次に、ノード１００ａにおけるデータ取得処理（Ｓ８００）を説明する。

【0077】

通信ミドルウェア１６０のデータ取得要求受付部１６３は、要求送信管理テーブル１４０に含まれる要求送信周期１４２を参照して、データ取得要求メッセージを送信するタイミングか否かを判断する（Ｓ８１０）。

【0078】

送信するタイミングであると判断された場合（Ｓ８１０のＹｅｓの場合）、メッセージ生成／送信部１６１は、データ取得要求メッセージの生成、ならびに送信を行う（Ｓ８１２）。

【0079】

送信したデータ取得要求メッセージに対する応答メッセージを、メッセージ解析／受信部１６２が受信し解析すると（Ｓ８１４）、データ取得要求受付部１６３は、その結果をアプリケーション１７０ａに通知する（Ｓ８２０）。

【0080】

一方、データ取得要求メッセージを送信するタイミングではないと判断された場合（Ｓ８１０のＮｏの場合）、データ取得要求受付部１６３は、データ取得要求メッセージの待ち状態になり、アプリケーション１７０ａ又は他アプリケーションからのデータ取得要求を待つ（Ｓ８１６）。

【0081】

以上の要求元の処理によれば、要求先とのコネクションが確立されていなければ、コネクションを確立すると共に、要求先から要求送信周期を受信することができる。これにより、要求元は、要求送信周期に従ってデータ取得要求メッセージを送信することができる。

【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】

１００…ノード １１１…記憶部 １１２…処理部 １１３…通信インタフェース １１４…ネットワーク １２０…設定ファイル １３０…応答送信管理テーブル １４０…要求送信管理テーブル １５０…ＯＳ １６０…通信ミドルウェア １７０…アプリケーション １８０…共有メモリ領域

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】