(57)【要約】      （修正有）【課題】要求メッセージを送信したノードの状態に応じて，自発的に行っていた同報通信を停止する手段や，要求メッセージに含まれる周期がメッセージ毎に異なる場合でも，トラフィック量を減らすことを可能にするシステム及び方法を提供する。【解決手段】要求メッセージを受信したノードが，自身がデータ送信可能な周期にて，データ送信する仕組みと，各ノードからの要求メッセージを管理する応答送信周期管理テーブル１２３と，他ノードの状態を管理する装置死活管理テーブル１２４を具備する。応答送信周期管理テーブルと，装置死活管理テーブルを定期的に更新することにより，他ノードの状態を把握し，要求メッセージを送信したノードが停止状態の場合には，データ送信を停止する手段を有する。さらに，ノード上のアプリケーションが要求する周期と，データが送信される周期の差違を吸収する手段を有する。【選択図】図３
2016100659.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードが接続されたネットワークでノードが周期的に他のノードに送信するデータ共有システムであって、
データの送信を要求する要求元ノードは要求先ノードへ送信を要求するデータとデータの送信周期を含むデータ要求メッセージを送信する送信部を備え、
要求先ノードは前記送信部から送信されたデータ要求メッセージを受信する受信部と、
前記データ要求メッセージに含まれる前記データを前記送信周期で送信できるかどうか判断し、送信可能な場合は前記送信周期で送信するよう管理する周期応答管理部を備えることを特徴とするデータ共有システム。
【請求項２】
前記周期応答管理部は前記指定された送信周期で送信できないと判断し、送信可能な送信周期で送信することを示す情報がデータ要求メッセージに含まれていないとき、指定されたデータを送信しないことを特徴とする請求項１に記載のデータ共有システム。
【請求項３】
前記要求元ノードの前記送信部から前記データの送信中止を指示するデータ要求メッセージを前記要求先ノードの受信部が受け取ったとき、
前記周期応答管理部は前記データの送信をしないよう送信部へ指示することを特徴とする請求項２に記載のデータ共有システム。
【請求項４】
前記周期応答管理部は前記データの送信中止の指示を受け取ったとき、前記データの送信中止の指示を受け取っていない他の要求元ノードがあれば前記データの送信を継続することを特徴とする請求項３に記載のデータ共有システム。
【請求項５】
ネットワークに接続されたノードの死活管理を行う装置死活監視部を備え、停止しているノードが有ったとき、当該ノードへのデータ送信を行わないよう前記周期応答管理部へ指示することを特徴とする請求項１に記載のデータ共用システム。
【請求項６】
前記要求元ノードの要求するデータの前記送信周期が要求先ノードの送信可能な送信周期より長い場合、要求先ノードから送信されたデータを間引いてアプリケーションへ送信するアプリケーションインタフェース部を備えることを特徴とする請求項１に記載のデータ共有システム。
【請求項７】
前記要求元ノードの要求するデータの前記送信周期が要求先ノードの送信可能な送信周期より短い場合、要求先ノードから送信されたデータを補間してアプリケーションへ送信するアプリケーションインタフェース部を備えることを特徴とする請求項１に記載のデータ共有システム。
【請求項８】
複数のノードが接続されたネットワークでノードが周期的に他のノードに送信するデータ共有方法であって、
データの送信を要求する要求元ノードの送信部が要求先ノードへ送信を要求するデータとデータの送信周期を含むデータ要求メッセージを送信し、
要求先ノードの受信部は前記送信部から送信されたデータ要求メッセージを受信し、
周期応答管理部は前記データ要求メッセージに含まれる前記データを前記送信周期で送信できるかどうか判断し、送信可能な場合は前記送信周期で送信するよう管理することを特徴とするデータ共有方法。
【請求項９】
前記周期応答管理部は前記指定された送信周期で送信できないと判断し、送信可能な送信周期で送信することを示す情報がデータ要求メッセージに含まれていないとき、指定されたデータを送信しないことを特徴とする請求項８に記載のデータ共有方法。
【請求項１０】
前記要求元ノードの前記送信部から前記データの送信中止を指示するデータ要求メッセージを前記要求先ノードの受信部が受け取ったとき、
前記周期応答管理部は前記データの送信をしないよう送信部へ指示することを特徴とする請求項９に記載のデータ共有方法。
【請求項１１】
前記周期応答管理部は前記データの送信中止の指示を受け取ったとき、前記データの送信中止の指示を受け取っていない他の要求元ノードがあれば前記データの送信を継続することを特徴とする請求項１０に記載のデータ共有方法。
【請求項１２】
装置死活監視部はネットワークに接続されたノードの死活管理を行い、停止しているノードが有ったとき、当該ノードへのデータ送信を行わないよう前記周期応答管理部へ指示することを特徴とする請求項８に記載のデータ共用方法。
【請求項１３】
アプリケーションインタフェース部は前記要求元ノードの要求するデータの前記送信周期が要求先ノードの送信可能な送信周期より長い場合、要求先ノードから送信されたデータを間引いてアプリケーションへ送信することを特徴とする請求項８に記載のデータ共有方法。
【請求項１４】
アプリケーションインタフェース部は前記要求元ノードの要求するデータの前記送信周期が要求先ノードの送信可能な送信周期より短い場合、要求先ノードから送信されたデータを補間してアプリケーションへ送信することを特徴とする請求項８に記載のデータ共有方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，複数のノードがネットワークを介して接続されたシステムにおいて，ノードが持つデータを取得する要求に対する応答として，一定周期でデータ送信を行うデータ共有方法に関する．
【背景技術】
【０００２】
サーバやコントローラなどの複数のノードがネットワークを介して接続されたシステムにおけるノード間のデータ通信方法として，例えば，産業システムで利用されるＭｏｄｂｕｓ(登録商法)に代表されるように，取得したいデータを持つノードに対して，データ取得に関する要求メッセージを送信し，そのメッセージを受信したノードは，応答メッセージとして，受信したメッセージにて指定されたデータを送信する方法がある．
このデータ通信方法を利用して，一定周期でデータ取得を行う場合，データ取得を要求するメッセージを一定周期で送信する必要があり，ネットワークトラフィックが増大する恐れがある．そのため，一般的には，要求メッセージに，データ取得周期を含めて送信し，そのメッセージを受信したノードは，そのメッセージに含まれる周期に合わせて自発的にデータを送信する方法が利用される．
この方法により，要求メッセージの数を減らすことは可能となるが，例えば，１つのノードに対して，複数のノードが周期を含む要求メッセージを送信した場合，各ノードが送信した要求メッセージ毎にデータを一定周期で送信する必要があるため，上記のネットワークのトラフィックに関する問題が解消されない．
上記の問題点を解決する方法として，特許文献１に示すように，一定期間内で受信した要求メッセージに対する応答メッセージを同報通信で送信する方法がある．この方法を利用することにより，周期を含む要求メッセージを複数のノードから受信した場合でも，要求メッセージ毎に応答メッセージを送信せず，複数の応答メッセージを纏めて，一定周期毎に同報通信することが可能となり，トラフィック量を減らすことが可能となる．
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２ー３５９６２１
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら，特許文献１には以下の課題がある．
特許文献１の技術を利用することにより，複数の応答メッセージを纏めて送信することが可能となり，トラフィック量を減らすことが可能となるが，要求メッセージを受信したノードが自発的に同報通信を利用して，データ送信を行うため，例えば，要求メッセージを送信したノードが，ハードウェアの故障などにより，動作していない場合でも，データ送信は行われるため，ネットワーク帯域を無駄に使用する恐れがある．
また，要求メッセージに含まれる周期がメッセージ毎に異なる場合，周期毎に同報通信を行う必要があるため，トラフィック量を減らすことが難しい．
そこで，本発明は，要求メッセージを送信したノードの状態に応じて，自発的に行っていた同報通信を停止する手段を提供や要求メッセージに含まれる周期がメッセージ毎に異なる場合でも，トラフィック量を減らすことを可能にする． 
【課題を解決するための手段】
【０００５】
本発明は，周期データ送信に関する要求メッセージを受信したノードに，送信可能な周期にて，データ送信を行う仕組みと，各ノードが送信した要求メッセージを管理する応答送信周期管理テーブルと，要求メッセージを送信したノードの状態を管理する装置死活管理テーブルを具備する．また，応答送信周期管理テーブルと，装置死活管理テーブルを定期的に更新することにより，要求メッセージを送信したノードの状態を把握し，もし，ノードが停止状態の場合には，データ送信を停止する手段を有する．一方，要求メッセージを送信したノードには，ノード上のアプリケーションが要求するデータ取得周期と，実際にデータを受信する周期の差違を吸収する手段を具備する．
【発明の効果】
【０００６】
ネットワークトラフィック量を軽減することを可能にする。
【図面の簡単な説明】
【０００７】
【図１】実施形態におけるシステムの全体構成図の例
【図２】実施形態におけるノードの構成を示すブロック図の例
【図３】実施形態におけるミドルウェアの構成を示すブロック図の例
【図４（ａ）】実施形態におけるデータ要求管理テーブルの例
【図４（ｂ）】実施形態における応答送信周期管理テーブルの例
【図４（ｃ）】実施形態における装置死活監視管理テーブルの例
【図５】実施形態におけるノード１００の処理シーケンスの例
【図６（ａ）】実施形態におけるノード１００aの処理フローの例
【図６（ｂ）】実施形態におけるノード１００aの処理フローの例
【図７（ａ）】実施形態におけるノード１００bの処理フローの例
【図７（ｂ）】実施形態におけるノード１００bの処理フローの例
【図８】実施形態におけるミドルウェアの構成を示すブロック図の例
【図９】実施形態における共有メモリの構成を示すブロック図
【図１０】実施形態におけるミドルウェア140の構成を示すブロック図
【図１１】データ送信中止要求処理
【図１２】データ送信間隔の調整
【発明を実施するための形態】
【０００８】
以下，本発明の実施形態を図面に基づいて詳細に説明する．なお，本発明の実施形態を説明する図において，同一部には同一の符号を付し，その繰り返しの説明は，省略することにする．
＜第１の実施形態＞
図１は，本発明の実施の形態のシステムの全体構成を例示した図である．図１において，ノード１００（１００a，１００b，１００c，１００d）はネットワーク１０２を経由で，他ノード１００の不揮発性メモリ１１２や，揮発性メモリ１１３や，記憶装置１２０に保存されているデータへのアクセスを行う．なお，システム内のノード数は，図１に例示した数に限定されない．
制御対象プロセス１０３（１０３a，１０３b，１０３c）はノード１００がモニタ、制御している対象のプロセスである。各ノードは対象とするプロセスの温度、圧力、消費電力等のデータを定められた周期でモニタしている。各ノード１００はモニタしたデータに基づいて対応するプロセス１０３の制御を行っていてもよい。
【０００９】
図２は，図１のノード１００の構成を示すブロック図である．ノード１００は，パーソナルコンピュータ等のコンピュータ，ワークステーション，コントローラ（制御装置）などが該当する．
ノード１００には，ハードウェアモジュール１１０と，ＯＳ１３０と，ミドルウェア１４０と，アプリケーション１５０（１５０a，１５０b，１５０c）とを含んで構成される．
ハードウェアモジュール１１０とは，ノード１００を動作させるために必要なハードウェアであり，ＣＰＵ１１１や，不揮発性メモリ１１２や，揮発性メモリ１１３や，他ノード１００とデータ通信を行う通信インタフェース（Ｉ／Ｆ）１１４や，タイマ１１５や，ディスプレイやタッチパネルなどの表示部１１６や，ハードディスク装置などの記憶装置１２０を含んで構成される．
記憶装置１２０には，設定ファイル１２１と，データ要求管理テーブル１２２と，応答送信周期管理テーブル１２３と，装置死活管理テーブル１２４とを備える．
設定ファイル１２１とは，後に説明する他ノード１００に対して周期データ送信を行う際の周期（以下，応答周期と呼ぶ）を含む，ノード１００の動作に必要なパラメータ，例えばノード１００のアドレスなどを記したファイルである．
図４(a)〜(c)を用いてデータ要求管理テーブル１２２と，応答送信周期管理テーブル１２３と，装置死活管理テーブル１２４を説明する．
データ要求管理テーブル１２２とは，ノード１００上で動作するアプリケーション１５０が，後に説明するミドルウェア１４０に送信する，他ノード１００の不揮発性メモリ１１２や，揮発性メモリ１１３や，記憶装置１２０に保存されているデータを一定周期で取得する要求(以下，データ要求と呼ぶ)を管理するテーブルであり，要求先ノードアドレス４０２と，要求データ４０４と，要求周期４０６と，応答周期４０８とを備える．なお，データ要求を受信したミドルウェア１４０は，データ要求メッセージを作成した後，アプリケーション１５０が周期データ送信を要求するノード１００に対して送信する．
要求先ノードアドレス４０２とは，アプリケーション１５０がデータの周期取得を要求する他ノード１００のアドレスを示したものであり，例えば，ノード１００のＩＰアドレスなどが該当する．
要求データ４０４とは，アプリケーション１５０が周期データ送信を要求するデータのデータ名を示したものである．なお，要求データ４０４には，データ名に加えて，ファイル名や，データが保存されている不揮発性メモリ１１２や揮発性メモリ１１３のメモリアドレスを格納してもよい．ただし，メモリアドレスを要求データ４０４に格納する場合には，データの長さも合わせて格納する必要がある．
要求周期４０６とは，アプリケーション１５０が周期データ送信を要求する周期を示したものである．
応答周期４０８とは，アプリケーション１５０が送信したデータ要求に対して，他ノード１００が実際にデータ送信を行う周期である．なお，応答周期は，データ要求メッセージに対する応答メッセージに含まれる．
応答送信周期管理テーブル１２３とは，ノード１００が受信したデータ要求メッセージに応じたデータ送信を管理するテーブルであり，周期送信データ４１２と，要求元ノードアドレス４１４とを備える．
周期送信データ４１２とは，ノード１００が設定ファイル１２１に記された応答周期で，データ送信を行うデータのデータ名を示したものである．なお，周期送信データ４１２には，データ名に加えて，ファイル名や，データが保存されている不揮発性メモリ１１２や揮発性メモリ１１３のメモリアドレスを格納してもよい．ただし，メモリアドレスを周期送信データ４１２に格納する場合には，データの長さも合わせて格納する必要がある．
要求元ノードアドレス４１４とは，データ要求メッセージを利用して，周期送信データ４１２に示す周期データ送信を要求したノード１００のアドレスを示したものであり，例えば，ノード１００のＩＰアドレスなどが該当する．
装置死活管理テーブル１２４とは，データ要求メッセージを送信したノード１００の状態（動作中／停止中／故障中／メンテナンス中など）を管理するテーブルであり，ノードアドレス４２２と，状態４２４と，状態更新時刻４２６とを備える．
ノードアドレス４２２とは，データ要求メッセージを送信したノード１００のアドレスを示したものであり，例えば，他ノード１００のＩＰアドレスなどが該当する．
状態４２４とは，データ要求メッセージを送信したノード１００の状態（動作中／停止中／故障中／メンテナンス中など）を示したものである．
状態更新時刻４２６とは，ノードアドレス４２２が示す状態４２４を更新した時刻を示すものである．
以上が，記憶装置１２０に備える各テーブルの説明である．
ＯＳ１３０とは，ノード１００の動作を制御する基本ソフトウェアである．
ミドルウェア１４０とは，他ノード１００が送信したデータ要求メッセージが示すデータを，設定ファイル１２１に記された周期で送信するための機能に加えて，他ノード１００が一定周期で送信するデータを，アプリケーション１５０が要求した周期に合わせて，アプリケーション１５０に送信する機能を実現するものであり，図３に示すように，メッセージ生成部１４１と，送信部１４７、メッセージ解析部１４２と，受信部１４８と、アプリケーション１５０とインタフェースを取る部分であるデータ要求受付部１４３と，データ取得部１４５と，周期応答管理部１４４と，装置死活監視部１４６とを備える．
メッセージ生成部１４１とは，他モジュールからの要求に応じて，メッセージを生成し，その生成したメッセージを送信部１４７が通信Ｉ／Ｆ１１４を通じて，他ノード１００に送信するモジュールである．
メッセージ解析部１４２とは，他ノード１００が送信したメッセージを，受信部１４８が通信Ｉ／Ｆ１１４を通じて受信し，その受信したメッセージを解析した後，解析結果に応じて，他モジュールにその結果を送信するモジュールである．
データ要求受付部１４３とは，アプリケーション１５０からのデータ要求を受付け，その要求を解析した後，その解析結果をデータ要求管理テーブル１２２に格納するとともに，その要求を，データ要求メッセージとして，該当する他ノード１００に送信するため，その要求のメッセージをメッセージ生成部１４１へ通知するモジュールである．さらに，このモジュールは，受信部１４２が受信し、更にメッセージ解析部１４２で解析したデータ要求に対する応答を受信し、その応答をデータ要求管理テーブル１２２に格納するとともに，該当するアプリケーション１５０へその応答を通知するモジュールでもある．
周期応答管理部１４４とは，メッセージ解析部１４２が通知する他ノード１００が送信したデータ要求メッセージの解析結果を，応答送信周期管理テーブル１２３に格納し，その応答を，データ取得部１４５に通知するモジュールである．さらに，タイマ１１５を利用して，設定ファイル１２１に記された応答周期毎に，データ取得部１４５に対して，応答送信周期テーブル１２２に記載されている周期送信データ４１２に格納されているデータを送信するように要求するモジュールでもある．
なお，応答周期の設定方法として，設定ファイル１２１を利用する他に，例えば，システム構築時にユーザが通信Ｉ／Ｆ１１４に接続された端末を通じて，応答周期を予め設定しておく方法や，ノード１００の電源起動時に，ミドルウェア１４０がアプリケーション１５０の動作を一定時間監視し，その監視結果から，データを周期送信可能な周期を算出する方法でもよい．
周期送信可能な周期は各ノードからネットワークへ送信する負荷に起因して決まる周期と各ノードが制御対象プロセスからデータを受け取りノードの記憶領域に格納する頻度に基づいて決まる周期があり、これらの制約に基づいて周期は決定される。
【００１０】
データ取得部１４５とは，周期応答管理部１４４が通知する要求に応じて，不揮発性メモリ１１２や，揮発性メモリ１１３や，記憶装置１２０からデータを取得し，メッセージ生成部１４１に，取得したデータを通知するモジュールである．
装置死活管理部１４６とは，メッセージ受信・解析部１４２が通知する他ノード１００が送信した死活監視メッセージの解析結果を，装置死活管理テーブル１２４に保存する．また，タイマ１１５を利用して，定期的に，装置死活管理テーブル１２４の状態更新時刻４２６を監視し，一定期間，更新がない場合には，その該当するノードの状態４２４を停止中に変更するモジュールである．さらに，タイマ１１５を利用して，周期的に，他ノード１００に対して，メッセージ生成部１４１、送信部１４７を通じて，装置死監視メッセージを送信するモジュールでもある．
アプリケーション１５０とは，ノード１００上で動作するアプリケーションであり、制御対象の監視、制御を行うプログラムである。
【００１１】
以上が，ノード１００の構成の説明である．
図５は，ノード１００a上のアプリケーション１５０がミドルウェア１４０を通じて，ノード１００bに対して，データ要求メッセージ送信する際の処理シーケンスを示した図である．
ノード１００a上のアプリケーション１５０は，他ノード１００の不揮発性メモリ１１２や，揮発性メモリ１１３や，記憶装置１２０に存在するデータを一定周期で取得した場合，ミドルウェア１４０に対して，データ要求を送信する（Ｓ５１０）．
データ要求には，要求先のノードアドレスと，要求データと，要求周期と，格納先アドレスと，オプションとを備えている．
オプションには，例えば，アプリケーション１５０が要求する要求周期と，要求先のノード１００の応答周期に差違が発生した場合の処理方法などが含まれる．なお，上記の詳細に関しては，後に説明する．
データ要求を受信したミドルウェア１４０は，データ要求に含まれる要求先ノードアドレスが示すノード１００b上のミドルウェア１４０と，データ要求処理（Ｓ６００）を行い，その結果をアプリケーション１５０にデータ周期取得応答として，送信する．なお，データ要求処理の詳細は後に説明する．
次に，ノード１００a上のミドルウェア１４０と，ノード１００b上のミドルウェア１４０はデータ取得処理（Ｓ７００），ならびに装置死活管理処理（Ｓ８００）を行う．なお，各処理の詳細は後に説明する．
最後に，ノード１００a上のアプリケーション１５０からミドルウェア１４０に対して，他ノード１００からの周期データ送信を停止するデータ停止要求を送信されると，ノード１００a上のミドルウェア１４０と，ノード１００b上のミドルウェア１４０とでデータ停止処理（Ｓ９００）を行い，その結果をアプリケーション１５０にデータ停止応答として，送信する．なお，データ停止処理（Ｓ９００）の詳細は後に説明する．
アプリケーション１５０が送信するデータ停止要求には，要求先ノードアドレスと，要求データとを備える．
以上が，ノード１００a上のアプリケーション１５０がミドルウェア１４０を通じて，ノード１００bに対してデータ要求メッセージ送信する際の処理シーケンスである．
次に，図６(a)(b)，ならびに図７(a)(b)を用いてデータ要求処理（Ｓ６００），データ取得処理（Ｓ７００），装置死活管理処理（Ｓ８００），ならびにデータ停止処理（Ｓ９００）の詳細を説明する．なお，図６(a)(b)はデータ要求を送信するノード１００aの処理フロー，図７はデータ要求を受信するノード１００bの処理フローをそれぞれ示しているが，データ取得処理はノード１００相互で行われるため，ミドルウェア１４０は，２つの処理シーケンスを同時に実行することとなる．
ノード１００a上のミドルウェア１４０は，データ要求受付部１４３を通じて，アプリケーション１５０より，データ要求を受信すると，メッセージ生成・送信部１４１を利用して，データ要求メッセージを生成した後，該当するノード１００bに対してメッセージを送信する（Ｓ６０２，Ｓ６０４）．
データ要求メッセージを送信したミドルウェア１４０は，データ要求応答メッセージの受信を待つ（Ｓ６０６）．
一定期間待った後，データ要求応答メッセージを受信していない場合，再送処理を実施する．さらに，所定回数の再送処理を行っても，データ要求応答メッセージを受信しない場合には，アプリケーション１５０に対して，エラーを通知する（Ｓ６１６，Ｓ６１８）．
ミドルウェア１４０上のメッセージ解析部１４２は，データ要求応答メッセージを受信すると，ミドルウェア１４０は受信したメッセージの解析を行い，その結果をデータ要求受付部１４３に通知する（Ｓ６０８）．
データ要求受付部１４３は，受信した解析結果から，その応答メッセージに含まれる応答周期が，アプリケーション１５０が要求した要求周期より長く，かつオプションにて，応答周期が要求周期よりも長い場合を許可していない場合には，その旨をエラーとしてアプリケーション１５０に通知する（Ｓ６１０，Ｓ６１２，Ｓ６１８）．また，データ要求受付部１４３は，メッセージ生成・送信部１４１に介して，Ｓ６０４にて要求したデータに対するデータ周期取得停止要求メッセージを送信する．
一方，要求周期が応答周期より長い場合，もしくはオプションにて，要求周期より応答周期が長いことを許可している場合には，データ要求管理テーブル１２２に応答可能な応答周期を保存し，アプリケーション１５０に対して，アプリケーション１５０が要求したデータが応答可能な応答周期で周期送信される旨を通知する（Ｓ６１４）．このとき応答可能な応答周期をアプリケーション１５０に送信するようにすれば、アプリケーションは応答周期に応じた処理が可能となる。以上が，ノード１００aにおけるデータ要求処理（Ｓ６００）の処理フローである．
なお，図１２の前半に記載したように応答周期が要求周期よりも長い場合，例えば，応答周期が２００ｍｓ，要求周期が１００ｍｓの場合，データは２００ｍｓ毎にしか受信できないが，ノード１００a上のミドルウェア１４０は，１００ｍｓ毎にアプリケーション１５０にデータを送信する必要がある．このように，アプリケーション１５０に対して，最新のデータを送信できない場合，ミドルウェア１４０は，直近に受信したデータを記憶しておき、記憶されたデータをアプリケーション１５０に送信するデータの補完が可能であるが，このような処理がアプリケーション１５０にとって不適切な場合がある．
上記のようにアプリケーション１５０にとって不適切な場合を避けるため，オプションを利用して，応答周期が要求周期よりも長い場合は，アプリケーション１５０に対して，データ送信を行わないようにする仕組みを搭載する．
また，ノード１００bにおけるデータ要求処理（Ｓ６００）の処理フローを，図７(a)(b)を用いて説明する．
ノード１００b上のミドルウェア１４０のメッセージ解析部１４２は，他ノード１００よりメッセージを取得すると，その受信したメッセージの解析を行う（Ｓ６２０，Ｓ６２２）．
解析した結果，そのメッセージがデータ要求メッセージの場合，その解析結果を，周期応答管理部１４４に通知する．周期応答管理部１４４は，受信した結果を，応答送信周期管理テーブル１２３に反映させた後，データ取得部１４５，ならびにメッセージ生成部１４１を通じて，データ要求応答メッセージ生成，該当ノード１００に送信する（Ｓ６２４，Ｓ６２６，Ｓ６２８）．以上が，ノード１００bにおけるデータ要求処理（Ｓ６００）の処理フローである．なお，要求メッセージに含まれる要求周期，ならびにオプションと，ノード１００bがデータ送信できる周期を比較し，データ送信できる周期が要求周期より長く，オプションでも，その条件を許可していない場合には，周期応答管理部１４４は，エラーを応答メッセージとして送信してもよい．  次に，ノードa１００，ならびにノードb１００におけるデータ停止処理（Ｓ９００）の処理フローを説明する．
ノード１００a上のミドルウェア１４０は、データ要求受付部１４３を通じてアプリケーション１５０よりデータ停止要求を受信すると、メッセージ生成部１４１、ならびに送信部１４７を利用して、データ停止要求メッセージを作成,該当するノード１００に送信する（Ｓ９０２,Ｓ９０４）
ノード１００b上のミドルウェア１４０のメッセージ解析部１４２は，データ停止要求メッセージを受信すると，その解析結果を，周期応答管理部１４４に通知する．周期応答管理部１４４は，解析結果に含まれる要求元ノードアドレス，ならびに周期データ送信を停止するデータ名を応答送信周期管理テーブル１２３から削除した後，データ取得部１４５，ならびにメッセージ生成部１４１を通じて，データ停止要求応答メッセージを生成し，要求メッセージを送信したノード１００aに送信する（Ｓ９２２，Ｓ９２４，Ｓ９２６）．以上が，ノード１００a，ならびにノード１００bにおけるデータ停止処理（Ｓ９００）の処理フローである．
データ停止要求メッセージを，例えば，ノード１００が停止する直前などに送信することにより，停止するノード１００のみが利用しているデータの送信が行われずに済むため，ネットワーク帯域を有効活用することが可能となる．
次に，図７を用いてノード１００a，ならびにノード１００bにおける図５のデータ取得処理（Ｓ７００）の処理フローを説明する．
ノード１００b上のミドルウェア１４０の周期応答管理部１４４は，タイマ１１５を参照し，データを送信するタイミングか否かを確認する（Ｓ７２３，Ｓ７２４）．
確認した結果，データを送信するタイミングの場合，応答送信周期管理テーブル１２３を参照し，送信すべきデータが存在するか否かを確認する（Ｓ７２６，Ｓ７２８）．
確認した結果，送信すべきデータが存在する場合には，データ取得部１４５，ならびにメッセージ生成部１４１を通じて，周期データメッセージを生成し，該当するノード１００に対して，その生成したメッセージを送信する（Ｓ７３０）．なお，複数のノード１００に送信する必要がある場合には，ブロードキャスト通信やマルチキャスト通信を利用して周期データメッセージを送信する．一方，データを送信すべきノード１００が１つの場合には，他ノード１００への負荷軽減を実現するため，ユニキャスト通信を利用して送信を行う．ただし，ネットワーク帯域に余裕がある場合には，全てブロードキャスト通信，マルチキャスト通信でもよい．
また，周期応答管理部１４４が，タイマ１１５を参照した結果，応答送信周期管理テーブル１２３を更新するタイミングであった場合（Ｓ８２２），応答送信周期管理テーブル１２３と装置死活管理テーブル１２４を参照し（Ｓ８２４），応答送信周期管理テーブル１２３の要求元ノードアドレスに記されているアドレスの中で，装置死活管理テーブル１２４の状態４２４が停止中、面テンス中、故障中等のノード１００が存在するようなら，該当するノード１００のノードアドレス，ならびにデータを削除するよう応答送信周期管理テーブル１２３を更新する（Ｓ８２６，Ｓ８２８）．なお，他ノード１００にも送信するデータに関しては削除を行わない．
例えば図１１のように要求先ノードが要求元ノード１と要求元ノード２の両方からデータＢを送信する要求を受けている場合、要求元ノード１からデータＡの送信中止要求を受けても、要求ノード２から送信中止要求を受けていなければ、要求先ノードはデータＡの送信を継続する。
【００１２】
要求元ノード２が停止、故障、メンテナンス状態であれば、要求元ノード１からのデータＡの送信中止要求のみによってデータＡの送信を中止しても良い。
【００１３】
上記のように，装置死活管理テーブル１２４を利用して，定期的に応答送信周期管理テーブル１２３の更新を行うことにより，データ停止処理（Ｓ９００）を行わず停止した装置に対する周期データ送信を停止することが可能となり，無駄なネットワーク帯域の利用を防ぐことが可能となる．
一方，図６（ｂ）のようにノード１００a上のミドルウェア１４０は，受信部１４８により，他ノード１００よりメッセージを受信し，メッセージ解析部１４２がその受信したメッセージを解析した結果，周期データメッセージだった場合（Ｓ７０２，Ｓ７０４，Ｓ７０６），その結果をデータ要求受付部１４３に通知する．データ要求受付部１４３は，データ要求管理テーブル１２２を参照し，そのテーブルに含まれているデータか確認する（Ｓ７０８）．
確認した結果，データ要求管理テーブル１２２に含まれていないデータの場合，受信したメッセージを破棄する（Ｓ７１６）．
確認した結果，データ要求管理テーブル１２２に含まれるデータの場合，要求周期と応答周期の関係を確認し，要求周期の方が応答周期より長い場合，データ要求受付部１４３は，その受信したデータをアプリケーション１５０に通知するタイミングが否かを確認する（Ｓ７１０，Ｓ７１２）．
確認した結果，通知するタイミングの場合は，アプリケーション１５０に受信したデータを通知する（Ｓ７１４）．通知するタイミングではない場合には，図１２の後半に示したように受信したメッセージを破棄しデータを間引いて送信（Ｓ７１６）してもよい．
また，Ｓ７１０にて，要求周期と応答周期の関係性を確認した結果，応答周期の方が要求周期よりも長い場合には，受信したデータをアプリケーション１５０に通知する．
上記のＳ７１０〜Ｓ７１６の処理を行うことにより，データを送信する側のノード１００は，複数のノード１００に対して同一周期でデータ送信を行うことが可能となるため，無駄なネットワーク帯域の利用を減らすことが可能となる．
例えば１０ｍｓ、２０ｍｓ、３０ｍｓの決められた数値を各ノードの応答周期や要求周期として使用したり、２０ｍｓの倍数、２００ｍｓの倍数を各ノードの応答周期、要求周期に使用すればさらにネットワーク帯域を効率的に使用することができる。
【００１４】
以上が，ノード１００a，ならびにノード１００bにおけるデータ取得処理（Ｓ７００）の処理フローである．
最後に，図６、図７を用いてノード１００a，ならびにノード１００bにおける図５の装置死活管理処理（Ｓ８００）の処理フローを説明する．
ノード１００a，ならびにノード１００b上のミドルウェア１４０の装置死活管理部１４６，はタイマ１１５を参照し，死活監視データを送信するタイミングの場合，メッセージ生成部１４１を通じて，死活監視データメッセージを生成した後，他ノード１００に対してそのメッセージを送信する（Ｓ８３０，Ｓ８３２）．なお，死活監視データメッセージはブロードキャスト通信，またはマルチキャスト通信で送信することにより，ネットワーク帯域の無駄を軽減することが可能となる．
一方，ノード１００a，ならびにノード１００b上のミドルウェア１４０のメッセージ解析部１４２が死活監視データメッセージを受信すると，その解析結果を装置死活監視部１４６に通知する．装置死活監視部１４６は，装置死活管理テーブル１２４の状態更新時刻４２６の時刻を，そのメッセージを受信した時刻に更新する（Ｓ８０２，Ｓ８０４）．
以上が，データ要求処理（Ｓ６００），データ取得処理（Ｓ７００），装置死活管理処理（Ｓ８００），ならびにデータ停止処理（Ｓ９００）におけるノード１００aの処理フロー，ならびにノード１００bの処理フローの説明である．
装置死活管理処理（Ｓ８００）により，データ要求メッセージを送信したノード１００の状態を監視することが可能となるが，定期的に，死活監視メッセージを送信する必要があり，そのメッセージがトラフィックを圧迫する恐れがある．一方，例えば，産業システムのようなシステムでは，ノード１００間のデータ通信には共有メモリによるサイクリック通信が利用されることが多い．このサイクリック通信を利用することで，定期的に死活監視メッセージを送信せず，ノード１００の状態を監視すること可能となる．図８は，サイクリック通信を行うミドルウェア１４０の構成，図９は，共有メモリの構成をそれぞれ示した図である．
ミドルウェア１４０は，図９に示す共有メモリ９００によるサイクリック通信を行うため，サイクリック通信部８０２を具備する．
共有メモリ９００は，ノード１００aの書込み領域９１０と，ノード１００aの状態管理領域９２０とを具備する．
ノード１００aの書込み領域９１０とは，ノード１００aがデータ書込みを行うことができる領域であり，サイクリック通信部８０２が，データ要求受付部１４３を介して，アプリケーション１５０からのデータ書込み要求に従ってデータの書込みを行う．なお，他の領域に関しては，アプリケーション１５０は書き込むことはできないが，読出しを行うことは可能である．
ノード１００aの状態管理領域９２０とは，ノード１００aの状態を書き込む領域であり，ノード１００aの状態９２２と，状態更新時刻９２４を具備する．
ノード１００aの状態９２２とは，ノード１００aの状態（動作中／停止中／故障中／メンテナンス中など）を格納する領域である．
状態更新時刻９２４とは，ノード１００aの状態９２２を更新した時刻を格納する領域である．
サイクリック通信部８０２は，タイマ１１５を利用して，定期的にメッセージ生成部１４１、送信部１４７を通じて，自ノード１００aの書込み領域９１０と，状態管理領域９２０を他ノード１００に対して送信する．
また，受信部１４８、メッセージ解析部１４２を通じて，ノード１００ｂの書込み領域９３０と，ノード１００ｂの状態管理領域９４０を受信したサイクリック通信部８０２は，状態管理領域９４０のノード１００bの状態９４２と，状態更新時刻９４４をもとに装置死活管理テーブル１２４を更新する．なお，本更新は，死活監視メッセージを利用した場合（Ｓ８０２，Ｓ８０４）と同様であるため，詳細説明は省略する．
上記のように，死活管理メッセージの代わりに，既に利用しているサイクリック通信を活用することで，ネットワークトラフィック量を減らすことが可能となる．
また，データ取得処理（Ｓ７００）にて，データを周期送信する際に，設定ファイル１２１に記載されている応答周期を利用して自発的にデータ送信を行っている．しかしながら，ノード１００が自発的にデータ送信を行っていることから，ノード１００上のアプリケーション１５０の挙動に依っては，応答周期通りのデータ送信が行われない可能性がある．このような場合に，データ送信を強制的に停止させる手段が必要となる．
図１０は，データ送信を強制的に停止する手段を具備するミドルウェア１４０の構成を示した図である．
ミドルウェア１４０はデータ周期送信管理部８１０を具備する．データ周期送信管理部８１０は，周期データメッセージを送信する際に生成される周期データ送信ログを定期的に監視するモジュールである．
この場合の処理フローは図７（b）のフローチャートにおいて、Ｓ７３０で周期データメッセージの生成と送信を行ったあとに送信ログを不揮発性メモリ１１２へ保存する処理追加する。
【００１５】
また、Ｓ８３０で死活監視データを送信するタイミングかどうかを判断したときに送信するタイミングでなければ、送信ログを確認するタイミングかどうかを判断し、送信ログを確認するタイミングであれば確認する。
【００１６】
確認の結果送信周期に異常があるようであればデータ周期送信停止処理を行い、Ｓ６２０の他のノードよりメッセージを取得する処理をおこなう。
【００１７】
送信ログを確認するタイミングでなかった場合、送信周期に異常が無かった場合も同様にＳ６２０の他のノードよりメッセージを取得する処理を行えばよい。
【００１８】
以上により，応答周期通りにデータ送信が行われていない場合，データ通信を停止するともに，他ノード１００に対してその旨を通知することが可能となり，送信周期の乱れるに依る他ノード１００の誤動作を防ぐことが可能となる．
以上、実施形態を具体的に説明したが，上記開示に限定されるものでなく、その趣旨を逸脱しない範囲において種々変更可能であることは言うまでもない．
【符号の説明】
【００１９】
１００・・・ノード，１０２・・・ネットワーク，１０３・・・制御対象プロセス，１１０・・・ハードウェアモジュール，１１１・・・ＣＰＵ，１１２・・・不揮発性メモリ，１１３・・・揮発性メモリ，１１４・・・通信Ｉ／Ｆ，１１５・・・タイマ，１１６・・・表示部，１２０・・・記憶装置，１３０・・・ＯＳ，１４０・・・ミドルウェア，１４１・・・メッセージ生成部，１４２・・・メッセージ解析部，１４３・・・データ要求受付部，１４４・・・データ取得部，１４５・・・周期応答管理部，１４６・・・装置死活監視部，１４７・・・送信部，１４８・・・受信部，１５０・・・アプリケーション
【図１】
2016100659.tif 000003
【図２】
2016100659.tif 000004
【図３】
2016100659.tif 000005
【図４（ａ）】
2016100659.tif 000006
【図４（ｂ）】
2016100659.tif 000007
【図４（ｃ）】
2016100659.tif 000008
【図５】
2016100659.tif 000009
【図６（ａ）】
2016100659.tif 000010
【図６（ｂ）】
2016100659.tif 000011
【図７（ａ）】
2016100659.tif 000012
【図７（ｂ）】
2016100659.tif 000013
【図８】
2016100659.tif 000014
【図９】
2016100659.tif 000015
【図１０】
2016100659.tif 000016
【図１１】
2016100659.tif 000017
【図１２】
2016100659.tif 000018