(57)【特許請求の範囲】
【請求項１】
予め定められた周期でアプリケーションの制御を行う複数の制御装置で構成された制御システムであって、各々の制御装置は予め定められた周期で他の制御装置へ同報通信するための通信制御部を備え、
前記通信制御部は他の制御装置からの同報通信要求を受付けるメッセージ受信部と、メッセージ受信部が受付けた同報通信要求に応えて同報通信を実行したときアプリケーションの制御周期遅延が発生するかどうかを判定する応答管理部と、
応答管理部がアプリケーションの制御周期遅延が発生しないと判定したとき応答管理テーブルに要求のあった同報通信を登録し、同報通信を周期的に行う周期応答部を備えることを特徴とする制御システム。
【請求項２】
前記応答管理部は前記制御装置がアプリケーションの制御を行う周期の時間から、アプリケーションの制御処理時間を差し引いた空き時間が受付けた同報処理要求を行う時間よりも長い場合に制御周期遅延が発生しないと判定することを特徴とする請求項１に記載の制御システム。
【請求項３】
アプリケーション制御を行う周期の中で、複数のアプリケーションの制御処理が実行される場合は、アプリケーションの制御を行う周期の時間から、全てのアプリケーションの制御処理時間を差し引いた時間を空き時間とすることを特徴とする請求項２に記載の制御システム。
【請求項４】
アプリケーションの処理優先度は通信制御部の処理優先度よりも高いことを特徴とする請求項２に記載の制御システム。
【請求項５】
前記通信制御部はアプリケーションの動作を監視する動作監視部を備え、動作監視部がアプリケーションの動作が変化したことを検出したとき同報通信のメッセージの中に、アプリケーションの動作が変化したことを示すエラーフラグを付加する周期応答部を備えることを特徴とする請求項２に記載の制御システム。
【請求項６】
前記エラーフラグは前記同報通信のメッセージを予め定めた周期を超えて送信することを示す情報であることを特徴とする請求項５に記載の制御システム。
【請求項７】
前記エラーフラグは一度周期を超えて同報通信のメッセージを予め定めた周期を超えて送信したとき、その後、周期を守って同報通信のメッセージを送信するときにも前記エラーフラグを付加することを特徴とする請求項６に記載の制御システム。
【請求項８】
前記通信制御部はデータ取得要求受付部を備え、前記データ取得要求受付部はアプリケーションから取得を要求するデータとデータに対応したエラーフラグの設定情報を受付け要求送信管理テーブルに格納することを特徴とする請求項５に記載の制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のノード（計算機）がネットワークを介して接続されたシステムにおいて、ノードが持つデータを取得する要求に対する応答として、一定周期でデータ送信を行う制御システムに関する。
【背景技術】
【０００２】
サーバやコントローラなどの複数のノードがネットワークを介して接続されたシステムにおけるノード間のデータ通信方法として、例えば、産業システムで利用されるＭｏｄｂｕｓ(登録商標)に代表されるように、取得したいデータを持つノードに対して、データ取得に関する要求メッセージを送信し、そのメッセージを受信したノードは、応答メッセージとして、受信したメッセージにて指定されたデータを送信する方法がある。
【０００３】
このデータ通信方法を利用して、一定周期でデータ取得を行う場合、データ取得を要求するメッセージを一定周期で送信する必要があり、ネットワークトラフィックが増大する恐れがある。そのため、一般的には、要求メッセージに、データ取得周期を含めて送信し、そのメッセージを受信したノードは、そのメッセージに含まれる周期に合わせて自発的にデータを送信する方法が利用される。
【０００４】
この方法により、要求メッセージの数を減らすことは可能となるが、例えば、１つのノードに対して、複数のノードが周期を含む要求メッセージを送信した場合、各ノードが送信した要求メッセージ毎にデータを一定周期で送信する必要があるため、上記のネットワークのトラフィックに関する問題が解消されない。
【０００５】
上記の問題点を解決する方法として、特許文献１に示すように、一定期間内で受信した要求メッセージに対する応答メッセージを同報通信で送信する方法がある。この方法を利用することにより、周期を含む要求メッセージを複数のノードから受信した場合でも、要求メッセージ毎に応答メッセージを送信せず、複数の応答メッセージを纏めて、一定周期毎に同報通信することが可能となり、トラフィック量を減らすことが可能となる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００２-３５９６２１
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１には以下の課題がある。
【０００８】
産業システムを含む制御システムに存在するコントローラには、コントローラと繋がるアクチュエータを制御する制御アプリケーションが搭載されていることが一般的である。このような制御アプリケーションは一定周期間隔で動作させる必要があるため、上記のデータ通信を行う通信制御部より制御アプリケーションの動作優先度を高く設定する必要がある。
【０００９】
一方、データ通信を行う通信制御部は制御アプリケーションの動作していない隙間時間を利用して動作する必要があるため、特許文献１に示すような複数の応答メッセージを纏めて、一定周期毎に同報通信を行うことが困難となる場合がある。さらに、制御アプリケーションの挙動が動作中に変化した場合、同報通信を行う通信制御部にもその影響が波及するため、同報通信の周期が乱れる恐れがある。
【００１０】
そこで、本発明では、制御アプリケーションが動作していない隙間時間を活用しつつ一定周期毎の同報通信を行いつつ、制御アプリケーションの挙動を監視し、その挙動が同報通信に影響を与える場合には、他のノードに対してエラー通知を送信する手段を提供する。
【課題を解決するための手段】
【００１１】
本発明は、制御アプリケーションが動作していない隙間時間から、一定周期毎の同報通信を行うことが可能な応答数を管理する応答管理テーブルと、制御アプリケーションの挙動を監視し、制御アプリケーションの挙動が、同報通信の周期が乱れる程、変化した場合には、同報通信で送付するメッセージの中にエラーフラグを設定することにより、他ノードに対して同報通信の周期が乱れていることを通知する手段を具備する。
【発明の効果】
【００１２】
これらの処理により、制御アプリケーションが動作していない隙間時間を利用して動作する通信制御部において一定周期毎の同報通信を可能とするとともに、制御アプリケーションの挙動が動作中に変化した場合でも、その変化の状況に応じて、他ノードに対して同報通信の周期が乱れていることを通知することが可能となる。
【図面の簡単な説明】
【００１３】
【図１】実施例におけるシステム全体構成図の例
【図２】実施例におけるノードの構成を示すブロック図の例
【図３】実施例における通信制御部の構成を示すブロック図の例
【図４】実施例における制御アプリケーションタイミングチャートの例
【図５（ａ）】実施例における要求送信管理テーブルの例
【図５（ｂ）】実施例における応答送信管理テーブルの例
【図５（ｃ）】実施例における設定ファイルの例
【図６】実施例におけるノード１００の電源起動時の処理フローの例
【図７】実施例におけるノード１００の処理シーケンスの例
【図８（ａ）】実施例におけるノード１００aの通信制御部の処理フローの例
【図８（ｂ）】実施例におけるノード１００aの通信制御部の処理フローの例
【図９（ａ）】実施例におけるノード１００bの通信制御部の処理フローの例
【図９（ｂ）】実施例におけるノード１００bの通信制御部の処理フローの例
【図１０】実施例におけるノード１００bの通信制御部の処理フローの例
【図１１】実施例における通信制御部の構成を示すブロック図の例
【図１２】実施例における共有メモリの構成を示すブロック図
【図１３（ａ）】実施例における要求送信管理テーブルの例
【図１３（ｂ）】実施例における応答送信管理テーブルの例
【発明を実施するための形態】
【００１４】
以下、本発明の実施例を図面に基づいて詳細に説明する。なお、本発明の実施例を説明する図において、同一部には同一の符号を付し、その繰り返しの説明は、省略することにする。
【００１５】
＜実施例１＞
図１は、本発明の実施例のシステムの全体構成を例示した図である。図１において、ノード１００（１００a、１００b、１００c、１００d）はネットワーク１０２を経由で、他ノード１００の不揮発性メモリや、揮発性メモリや、記憶装置１１４に保存されているデータへのアクセスを行う制御装置である。各々の制御装置は周期的に制御対象の制御を行う制御アプリケーションを備える。なお、システム内のノード数は、図１に例示した数に限定されない。また、ノードの中には制御を行わずモニタだけを行うようなノードが有っても良いが、本実施例では全てのノードが最大構成を備えることを前提に説明する。
【００１６】
図２は、図１のノード１００の構成を示すブロック図である。ノード１００は、パーソナルコンピュータ等のコンピュータ、ワークステーション、コントローラ（制御装置）などが該当する。
【００１７】
ノード１００には、ハードウェアモジュール１１０と、ＯＳ１５０と、通信制御部１６０と、制御を実行する制御アプリケーション１７０（１７０a、１７０b、１７０c）とを含んで構成される。
【００１８】
ハードウェアモジュール１１０には、中央処理装置（ＣＰＵ，Central Processing Unit）等からなる処理部１１１と、通信インタフェース(通信Ｉ／Ｆ)１１２と、制御アプリケーション１７０の動作の監視や、一定周期毎のデータ送信を行うために利用するタイマ１１３と、揮発/不揮発性メモリやハードディスク装置を含む記憶部１１４とを備える。この通信インタフェース１１２は、ネットワーク１０２との接続を行うインタフェースであり、イーサネット（登録商標）や無線ＬＡＮ(Local Area Network)などの通信インタフェースが該当する。
【００１９】
記憶装置１１４には、設定ファイル１２０と、要求管理テーブル１３０と、応答管理テーブル１４０とを備える。
【００２０】
設定ファイル１２０は最大周期応答数を算出する際に必要となる情報を記したファイルである。設定ファイル１２０の構成の詳細は後に説明する。
【００２１】
図４は、制御アプリケーション実行周期時間１７２と制御アプリケーション実行時間１７３との関係を示す。図４に示すように，一般的に，制御システム上で動作する制御アプリケーション１７０は一定周期/期間動作する必要がある。その動作保証はＯＳ１５０が行う。
【００２２】
制御アプリケーション実行周期１７２から制御アプリケーション実行時間１７３を除いた空き時間がノード間で同報通信を含む通信を行う通信時間である。この例では通信時間は連続しているが、制御アプリケーションの実行が制御アプリケーション実行周期の中で不連続に実行される場合は空き時間の合計時間を通信時間とする。
【００２３】
図５(a)(b)を用いて要求管理テーブル１３０と、応答送信管理テーブル１４０を説明する。
【００２４】
データ要求テーブル１３０とは、ノード１００上で動作する制御アプリケーション１７０が、後に説明する通信制御部１６０に送信する、他ノード１００の不揮発性メモリや、揮発性メモリや、記憶装置１１４に保存されているデータを一定周期で取得する要求(以下、データ取得要求と呼ぶ)を管理するテーブルであり、要求先ノードアドレス１３１と、要求データ１３２と、要求周期１３３と、応答周期１３４と、エラーフラグ１３５を備える。
【００２５】
なお、データ取得要求を受信した通信制御部１６０は、データ取得要求メッセージを作成した後、制御アプリケーション１７０がデータの周期取得を要求するノード１００に対して送信する。
制御アプリケーション１７０からデータ取得要求受付部１６３が取得するデータの情報を受け取り、要求管理テーブル１３０に格納する。以下、要求管理テーブル１３０に格納する各々の取得するデータに関する情報を説明する。
【００２６】
要求先ノードアドレス１３１とは、制御アプリケーション１７０がデータの周期取得を要求する他ノード１００のアドレスを示したものであり、例えば、ノード１００のＩＰアドレスなどである。
【００２７】
要求データ１３２とは、制御アプリケーション１７０がデータの周期取得を要求するデータのデータ名を示したものである。なお、要求データ１３２には、データ名に加えて、ファイル名や、データが保存されている不揮発性メモリや揮発性メモリのメモリアドレスを格納してもよい。ただし、メモリアドレスを要求データ１３２に格納する場合には、データの長さも合わせて格納する必要がある。
【００２８】
要求周期１３３とは、制御アプリケーション１７０がデータの周期取得を要求する周期を示したものである。
【００２９】
応答周期１３４とは、制御アプリケーション１７０が送信したデータ取得要求に対して、他ノード１００が実際にデータ送信を行う周期である。なお、応答周期は、データ取得要求メッセージに対する応答メッセージに含まれる。
【００３０】
他ノード１００が一定周期で送信する周期データメッセージの中に、送信周期が乱れたことを示すエラーフラグが存在する。エラーフラグ１３５とは、このエラーフラグが設定されている周期データメッセージを受信した際の処理を示しており、「許可」の場合には、エラーフラグが設定されている場合でも制御アプリケーション１７０に受信したデータを通知し、「禁止」の場合には、エラーフラグが設定されている場合には、そのメッセージを破棄することを示す。  応答送信管理テーブル１４０とは、ノード１００が受信したデータ取得要求メッセージに応じたデータ送信を管理するテーブルであり、要求データ１４１と、要求元ノードアドレス１４２とを備える。
【００３１】
要求データ１４１とは、ノード１００が設定ファイル１２０に記された応答周期で、周期データメッセージにより、データ送信を行うデータのデータ名を示したものである。なお、要求データ１４１には、データ名に加えて、ファイル名や、データが保存されている不揮発性メモリや揮発性メモリのメモリアドレスを格納してもよい。ただし、メモリアドレスを要求データ１４１に格納する場合には、データの長さも合わせて格納する必要がある。
【００３２】
要求元ノードアドレス１４２とは、データ取得要求メッセージを利用して、要求データ１４１に示すデータの周期取得を要求したノード１００のアドレスを示したものであり、例えば、ノード１００のＩＰアドレスなどが該当する。
【００３３】
以上が、記憶装置１１４に備える各テーブルの説明である。
【００３４】
ＯＳ１５０とは、ノード１００の動作を統括的に制御する基本ソフトウェアである。
【００３５】
通信制御部１６０は、少なくとも通信制御を行うモジュールを備える。ここでは通信制御部を中心に説明を進める。通信制御部１６０は他ノード１００が送信したデータ周期要求メッセージが示すデータを、設定ファイル１２０に記された周期で送信する機能に加えて、他ノード１００が一定周期で送信するデータを、制御アプリケーション１７０が要求した周期に合わせて、制御アプリケーション１７０に送信する機能や、制御アプリケーション１７０の動作を監視し、設定ファイル１２０に記された制御アプリケーション実行周期１７２や制御アプリケーション実行時間１７３から乱れたことを検出する機能を実現するものであり、図３に示すように、メッセージ生成/送信部１６１と、メッセージ解析/受信部１６２と、データ取得要求受付部１６３と、周期応答部１６４と、データ取得部１６５と、応答管理部１６６と、アプリ動作監視部１６７とを備える。
【００３６】
メッセージ生成/送信部１６１とは、他モジュールからの要求に応じて、メッセージを生成し、その生成したメッセージを通信Ｉ／Ｆ１１２を通じて、他ノード１００に送信するモジュールである。
【００３７】
メッセージ解析/受信部１６２とは、他ノード１００が送信したメッセージを、通信Ｉ／Ｆ１１２を通じて受信し、その受信したメッセージを解析した後、解析結果に応じて、他モジュールにその結果を送信するモジュールである。
【００３８】
データ取得要求受付部１６３とは、制御アプリケーション１７０からのデータ取得要求を受付け、その要求を解析した後、その解析結果を要求管理テーブル１３０に格納するとともに、その要求を、データ取得要求メッセージとして、該当する他ノード１００に送信するため、その要求をメッセージ生成/送信部１６１へ通知するモジュールである。さらに、このモジュールは、データ取得要求に対する応答を、メッセージ解析/受信部１６２から受信し、その応答を要求管理テーブル１３０に格納するととともに、該当する制御アプリケーション１７０へその応答を通知するモジュールでもある。
【００３９】
周期応答部１６４とは、メッセージ解析/受信部１６２が通知する他ノード１００が送信したデータ取得要求メッセージの解析結果を、応答管理テーブル１４０に格納し、その応答を、データ取得部１６５に通知するモジュールである。さらに、タイマ１１３を利用して、設定ファイル１２０に記された応答周期毎に、データ取得部１６５に対して、応答管理テーブル１４０に記載されている要求データ１４１に格納されているデータを送信するように要求するモジュールでもある。なお、応答周期の設定方法として、設定ファイル１２０を利用する他に、例えば、システム構築時に通信Ｉ／Ｆ１１２を通じて、応答周期を設定する方法や、ノード１００の電源起動時に、通信制御部１６０が制御アプリケーション１７０の動作を一定時間監視し、その監視結果から、データ周期送信可能な周期を算出する方法でもよい。
【００４０】
データ取得部１６５とは、周期応答部１６４が通知する要求に応じて、不揮発性メモリや、揮発性メモリや、記憶装置１１４からデータを取得し、メッセージ生成/送信部１６１に、取得したデータを通知するモジュールである。
【００４１】
応答管理部１６６とは、後に述べる電源起動時に最大周期応答数を算出し、その算出した応答数に応じて、他ノード１００が送信するデータ取得要求メッセージに対する応答を制御するモジュールである。
【００４２】
アプリ動作監視部１６７とは、タイマ１１３を利用して、制御アプリケーション１７０の動作を監視し、設定ファイル１２０に記された制御アプリケーション実行周期１７２や制御アプリケーション実行時間１７３から乱れたことを検出する機能である。制御アプリケーション１７０の動作の監視方法の詳細は後に説明する。
【００４３】
制御アプリケーション１７０とは、ノード１００上で動作するアプリケーションである。
【００４４】
図５(c)は設定ファイル１２０の例を示す。設定ファイル１２０とは、後に説明する最大周期応答数を算出する際に必要となる情報を記したファイルである。設定ファイル１２０はノードアドレス、１７１制御アプリケーション実行周期１７２、制御アプリケーション実行時間１７３、応答周期１７４と応答時間１７５とを備える。ノードアドレス１７１は、ノード１００を一意に識別するアドレスを示すものである。制御アプリケーション実行周期１７２は、制御アプリケーション１７０の実行周期を示すものである。制御アプリケーション実行時間１７３は、制御アプリケーション１７０の実行時間を示すものである。応答周期１７４は、他ノード１００に対して後に説明する周期データメッセージを送信する周期を示すものである。応答処理時間１７５は、他ノード１００に対して後に説明する周期データメッセージの送信を行う際に要する処理時間を示すものである。  以上が、ノード１００を構成する各々の構成要素の説明である。
【００４５】
図６は，起動時に応答管理部１６６が最大周期応答数を算出するフローを示した図である．
起動後，応答管理部１６６は，記憶部１１４に存在する設定ファイル１２０を読込み，制御アプリケーション実行周期時間１７２や，制御アプリケーション実行時間１７３、応答周期１７４、応答処理時間１７５を取得する（ステップ６００）．なお，これらの情報の中で，ＯＳ１５０を通じて取得できる情報がある場合には，設定ファイル１２０を利用せず，ＯＳ１５０を通じて取得してもよい．
次に，応答管理部１６６は，取得した情報を利用して，最大周期応答数を算出する（ステップ６１０）。
【００４６】
最大周期応答数とは，制御アプリケーション実行周期時間１７２と制御アプリケーション実行時間１７３の間の時間で，送信できる最大周期データメッセージ数であり，例えば，制御アプリケーション実行周期時間１７２が５０ｍｓ，制御アプリケーション実行時間１７３が３０ｍｓ，応答処理時間１７５が１ｍｓの場合，最大周期応答数は（制御アプリケーション実行周期時間１７２−制御アプリケーション実行時間１７３）÷応答処理時間１７５＝（５０ｍｓ−３０ｍｓ）÷１ｍｓ＝２０/５０ｍｓとなる。
【００４７】
この値を超えたメッセージ数を送信する場合，周期データメッセージの送信周期が乱れる恐れがある。
【００４８】
図７は、要求元ノード１００a上の制御アプリケーション１７０が通信制御部１６０を通じて、要求先ノード１００bに対して、データ取得要求メッセージ送信する際の処理シーケンスを示した図である。
【００４９】
要求元ノード１００a上の制御アプリケーション１７０は、他ノード１００の不揮発性メモリや、揮発性メモリや、記憶装置１１４に存在するデータを一定周期で取得した場合、通信制御部１６０に対して、データ取得要求を送信する（ステップ７１０）。
【００５０】
データ取得要求には、要求先のノードアドレスと、要求データと、要求周期と、格納先アドレスと、オプションとを備えている。
【００５１】
オプションには、周期データメッセージに含まれるエラーフラグに対する処理方法が含まれる。
【００５２】
データ取得要求を受信した通信制御部１６０は、データ取得要求に含まれる要求先ノードアドレスが示すノード１００b上の通信制御部１６０と、データ要求処理（ステップ８００）を行い、その結果を制御アプリケーション１７０にデータ周期取得応答として送信する。
【００５３】
次に、要求元ノード１００a上の通信制御部１６０と、ノード１００b上の通信制御部１６０はデータ取得処理（ステップ９００）を行う。
【００５４】
最後に、要求元ノード１００a上の制御アプリケーション１７０から通信制御部１６０に対して、他ノード１００からのデータの周期取得を停止するデータ取得停止要求を送信されると（ステップ７２０）、ノード１００a上の通信制御部１６０と、ノード１００b上の通信制御部１６０とでデータ停止処理（ステップ１０００）を行い、その結果を制御アプリケーション１７０にデータ取得停止応答として、送信する。
【００５５】
制御アプリケーション１７０が送信するデータ取得停止要求には、要求先ノードアドレスと、要求データとを備える。
【００５６】
以上が、ノード１００a上の制御アプリケーション１７０が通信制御部１６０を通じて、ノード１００bに対してデータ取得要求メッセージ送信する際の処理シーケンスである。
【００５７】
次に、データ要求処理（ステップ８００）、データ取得処理（ステップ９００）、ならびにデータ停止処理（ステップ１０００）の詳細を図８、ならびに図９を用いて説明する。なお、図８(a)(b)はデータ取得要求を送信するノード１００aの処理フロー、図９(a)(b)はデータ取得要求を受信する要求先ノード１００bの処理フローをそれぞれ示しているが、データ取得処理はノード１００相互で行われるため、通信制御部１６０は、２つの処理シーケンスを同時に実行することとなる。
【００５８】
要求元ノード１００a上の通信制御部１６０は、データ取得要求受付部１６３を通じて、制御アプリケーション１７０より、データ取得要求を受信すると、メッセージ生成/送信部１６１を利用して、データ取得要求メッセージを生成した後、要求先ノード１００bに対してメッセージを送信する（ステップ８１０、ステップ８１２）。
【００５９】
データ取得要求メッセージを送信した通信制御部１６０は、データ取得要求応答メッセージの受信を待つ（ステップ８１４）。
【００６０】
一定期間要求先ノードからの応答を待った後、データ取得要求に対する応答メッセージを受信していない場合、再送処理を実施する。さらに、所定回数の再送処理を行っても、データ取得要求に対する応答メッセージを受信しない場合には、制御アプリケーション１７０に対して、エラーを通知する（ステップ８２２、ステップ８２４）。
【００６１】
通信制御部１６０上のメッセージ解析/受信部１６２は、要求先ノードからデータ取得要求に対する応答メッセージを受信すると、受信したメッセージの解析を行い、その結果をデータ取得要求受付部１６３に通知する（ステップ８１６）。
【００６２】
データ取得要求受付部１６３は、受信した解析結果から、その応答メッセージに含まれる応答周期が、制御アプリケーション１７０が要求した要求周期より長い場合には、その旨をエラーとして制御アプリケーション１７０に通知する（ステップ８１８、ステップ８２４）。また、データ取得要求受付部１６３は、メッセージ生成/送信部１６１に介して、ステップ８１０にて要求したデータに対するデータ取得停止要求メッセージを送信する。
【００６３】
一方、要求周期が応答周期より長い場合（ステップ８１８のＹｅｓの場合）、データ取得要求受付部１６３は要求管理テーブル１３０に応答内容を保存し、制御アプリケーション１７０に対して、制御アプリケーション１７０が要求したデータが周期送信される旨を通知する。以上が、ノード１００aにおけるデータ要求処理（ステップ８００）の処理フローである。
【００６４】
また、ノード１００bにおけるデータ要求処理（ステップ８００）の処理フローを、図９(a)を用いて説明する。
【００６５】
ノード１００b上の通信制御部１６０のメッセージ解析/受信部１６２は、他ノード１００よりメッセージを取得すると、その受信したメッセージの解析を行う（ステップ８５０、ステップ８５２）。
【００６６】
解析した結果、そのメッセージがデータ取得要求メッセージの場合（ステップ８５４のＹｅｓの場合）、その解析結果を、応答管理部１６６に通知する。応答管理部１６６は、応答管理テーブル１４０を参照した後（ステップ８５６）、受信した要求に対する周期データメッセージによって、ノード１００bが送信する周期データメッセージ数が、ステップ６１０にて算出した最大周期応答数を超えるか否かを判断する。
【００６７】
判断した結果、最大周期応答数を超えない場合（ステップ８５８のＹｅｓの場合）、受信した要求に対する周期データメッセージを送信できると判断し、応答管理テーブル１４０に受け付けた要求を追加し（ステップ８６０）、メッセージ生成/送信部１６１を通じて、データ取得要求応答メッセージを生成し、要求元ノード１００に送信する（ステップ８６２）。
【００６８】
一方、応答管理部１６６は判断した結果、最大周期応答数を超える場合（ステップ８５８のＮｏの場合）、受信した要求に対する周期データメッセージを送信できないと判断し、メッセージ生成/送信部１６１を通じて、エラーメッセージを生成し、要求元ノード１００に送信する（ステップ８６４）。
【００６９】
以上が、ノード１００bにおけるデータ要求処理（ステップ８００）の処理フローである。
【００７０】
データ取得要求メッセージを受信するノード１００が応答管理部１６６を利用して、その要求メッセージに対する周期データメッセージの送信が、他の周期データメッセージの送信周期に影響を与えないことを確認する仕組みを搭載することにより、制御アプリケーション１７０より動作優先度が低い通信制御部１６０においても、一定周期毎の同報通信を行うことが可能となる。
【００７１】
次に、ノード１００a、ならびにノード１００bにおけるデータ停止処理（ステップ１０００）の処理フローを説明する。
【００７２】
ノード１００a上の通信制御部１６０は、データ取得要求受付部１６３を通じて、制御アプリケーション１７０よりデータ取得停止要求を受信すると、メッセージ生成/送信部１６１を利用して、データ取得停止要求メッセージを作成した後、該当するノード１００に送信する（ステップ１００２、ステップ１００４）。  要求先ノード１００b上の通信制御部１６０のメッセージ解析/受信部１６２は、データ取得停止要求メッセージを受信すると、その解析結果を、応答管理部１６６に通知する。応答管理部１６６は、解析結果に含まれる要求元ノードアドレス、ならびにデータの周期取得の停止を要求するデータ名を応答管理テーブル１４０から削除した後、メッセージ生成/送信部１６１を通じて、データ取得停止要求応答メッセージを生成し、要求メッセージを送信したノード１００aに送信する（ステップ１０５０、ステップ１０５２、ステップ１０５４）。
【００７３】
以上が、送信元ノード１００a、ならびに送信先ノード１００bにおけるデータ停止処理（ステップ１０００）の処理フローである。
【００７４】
データ取得停止要求メッセージを、例えば、ノード１００が停止する直前などに送信することにより、停止するノード１００のみが利用しているデータの送信が行われずに済むため、ネットワーク帯域を有効活用することが可能となる。
【００７５】
次に、ノード１００a、ならびにノード１００bにおけるデータ取得処理（ステップ９００）の処理フローを説明する。
【００７６】
送信先ノード１００b上の通信制御部１６０の周期応答部１６４は、設定ファイル１２０から得た周期情報とタイマ１１３を参照し、データを送信するタイミングか否かを確認する（ステップ９５０、ステップ９５２）。
【００７７】
確認した結果、データを送信するタイミングの場合（ステップ９５２のＹｅｓの場合）、応答管理テーブル１４０を参照し、送信すべきデータが存在するか否かを確認する（ステップ９５４、ステップ９５６）。
【００７８】
周期応答部１６４はデータ取得部１６５へ指示し、確認した結果、送信すべきデータが存在する場合には（ステップ９５６のＹｅｓの場合）、データ取得部１６５は、アプリ動作監視部１６７を通じて、該当データ取得開始時の時刻Ｔ１を取得する（ステップ９５８）。データ取得部１６５は該当データを取得した後（ステップ９６０）、周期エラーフラグの状態と合わせて、その取得したデータをメッセージ生成/送信部１６１を通じて、周期データメッセージを生成し、該当するノード１００に対して、その生成したメッセージを送信する（ステップ９６２）。なお、複数のノード１００に送信する必要がある場合には、ブロードキャスト通信やマルチキャスト通信を利用して周期データメッセージを送信する。一方、データを送信すべき送信先ノード１００が１つの場合には、他ノード１００への負荷軽減を実現するため、ユニキャスト通信を利用して送信を行う。ただし、ネットワーク帯域に余裕がある場合には、全てブロードキャスト通信、マルチキャスト通信でもよい。
【００７９】
データ取得部１６５は周期応答部から要求のあった送信すべきデータの送信が全て完了したか否かを確認する（ステップ９６４）。
【００８０】
確認した結果、全てのデータ送信が完了している場合（ステップ９６４のＹｅｓの場合）、データ取得処理を終了する。
【００８１】
確認した結果、全てのデータ送信が完了していない場合（ステップ９６４のＮｏの場合）、アプリ動作監視部１６７を利用して、現時刻Ｔ２を取得し（ステップ９６８）、データ取得時開始時の時刻Ｔ１と現時刻Ｔ２の差分を算出する（ステップ９６８）。
【００８２】
アプリケーション実行周期１７１とアプリケーション実行時間１７２の差分から算出した通信制御部動作時間と、ステップ９６８にて算出した差分時刻を比較した結果、差分の方が大きい場合（ステップ９７０のＹｅｓの場合）、制御アプリケーション１７０の動作が設定ファイル１２０に記している動作から変化したと判断し、周期エラーフラグを設定する（ステップ９７２）。
【００８３】
一方、差分時刻の方が小さい場合（ステップ９７０のＮｏの場合）、制御アプリケーション１７０の動作が設定ファイル１２０に記している動作から変化してないと判断し、周期エラーフラグにエラーなしを示す情報を設定する（ステップ９７４）。
【００８４】
ステップ９７２、もしくはステップ９７４の処理を行った後、データ取得部１６５はステップ９６０の処理を再び実行する。
【００８５】
以上が、ノードb１００におけるデータ取得処理（ステップ９００）の処理フローの説明である。
【００８６】
ステップ９５８、ならびにステップ９６６〜ステップ９７４に記載した制御アプリケーション１７０の動作監視はタイマ１１３による時刻を利用した方法であるため、動作優先度の高い制御アプリケーション１７０の動作を妨げることなく、その制御アプリケーション１７０の動作が当初設定した動作との違いを検出することが可能となる。
【００８７】
図９で示した方法は、制御アプリケーション１７０の動作状況を、データを取得する毎に監視し、動作状況に合わせて、周期エラーフラグの状態を変化させる方法である。一方、周期データメッセージを受信する制御アプリケーション１７０によっては、一度、周期が乱れた場合、それ以降の周期データメッセージには、周期エラーフラグを設定した方が良い場合がある。
【００８８】
図１０は、図９(b)のフローチャートにおいて、一度、周期が乱れた場合には、それ以降の周期データメッセージには、周期エラーフラグにエラー有りを示す情報を設定する処理フローを示した図である。
【００８９】
ステップ９５６にて送信すべきデータが存在する場合、データ取得部１６５は周期エラーフラグにエラー有りを示す情報が既に設定されているか否かを確認する（ステップ９８０）。
【００９０】
確認した結果、周期エラーフラグにエラー有りを示す情報が設定されていない場合（ステップ９８０のＮｏの場合）、ステップ９５８以降の処理を実行する。
【００９１】
一方、確認した結果、周期エラーフラグにエラー有りを示す情報が既に設定されている場合（ステップ９８０のＹｅｓの場合）、データ取得処理は行わず、メッセージ生成/送信部１６１を通じて、周期データメッセージを生成し、該当するノード１００に対して、周期エラーフラグの状態を示す情報を含む生成したメッセージを送信する（ステップ９８２）。
【００９２】
以上の処理フローにより、一度、周期が乱れた場合には、それ以降の周期データメッセージに、周期エラーフラグがエラー有りの状態であることを示す情報を設定することが可能となる。
【００９３】
一方、ノードa１００上の通信制御部１６０は、メッセージ解析/受信部１６２により、他ノード１００よりメッセージを受信し、その受信したメッセージを解析した結果、周期データメッセージだった場合（ステップ９１０、ステップ９１２、ステップ９１４）、その結果をデータ取得要求受付部１６３に通知する。データ取得要求受付部１６３は、要求管理テーブル１３０を参照し、そのテーブルに含まれているデータか確認する（ステップ９１６）。
【００９４】
確認した結果、データ要求管理テーブル１２２に含まれていないデータの場合（ステップ９１６のＮｏの場合）、受信したメッセージを破棄する（ステップ９３０）。
【００９５】
確認した結果、データ要求管理テーブル１２２に含まれるデータの場合（ステップ９１６のＹｅｓの場合）、メッセージに周期エラーフラグが設定されているか否かを確認する（ステップ９１８）。
【００９６】
確認した結果、周期エラーフラグが設定していない場合（ステップ９１８のＮｏの場合）、要求周期と応答周期の関係を確認し、要求周期の方が応答周期より長い場合、データ取得要求受付部１６３は、その受信したデータを制御アプリケーション１７０に通知するタイミングが否かを確認する（ステップ９２４、ステップ９２６）。
【００９７】
確認した結果、通知するタイミングの場合は（ステップ９２６のＹｅｓの場合）、制御アプリケーション１７０に受信したデータを通知する（ステップ９２８）。通知するタイミングではない場合には（ステップ９２６のＮｏの場合）、受信したメッセージを破棄する（ステップ９３０）。
【００９８】
また、ステップ９２４にて、要求周期と応答周期の関係性を確認した結果、応答周期の方が要求周期よりも長い場合には、受信したデータを制御アプリケーション１７０に通知する。
【００９９】
上記のステップ９１０〜ステップ９３０の処理を行うことにより、データを送信する側のノード１００は、複数のノード１００に対して同一周期でデータ送信を行うことが可能となるため、無駄なネットワーク帯域の利用を減らすことが可能となる。
【０１００】
また、ステップ９１８にて周期データメッセージに周期エラーフラグが設定されている場合（ステップ９１８のＹｅｓの場合）、要求管理テーブル１３０を参照し、周期エラーフラグがエラー有りを示しているデータの受付を許可しているか否かを確認する（ステップ９２０）。
【０１０１】
確認した結果、受付を許可している場合（ステップ９２０のＹｅｓの場合）、ステップ９２４以降の処理を実行する。
【０１０２】
確認した結果、受付を許可されていない場合（ステップ９２０のＮｏの場合）、制御アプリケーション１７０にエラーを通知する（ステップ９２２）。
【０１０３】
以上が、要求元ノードa１００、ならびに要求先ノードb１００におけるデータ取得処理（ステップ９００）の処理フローである。
【０１０４】
例えば、設備監視のような制御アプリケーション１７０では、周期データメッセージの送信周期は重要ではなく、ある程度の間隔で、設備状態が送信されることが重要である。一方、プロセス制御のような制御アプリケーション１７０では、周期データメッセージの送信周期が重要であり、周期が乱れたデータは利用できない恐れがある。
【０１０５】
あるシステムの中には、上記のような異なるニーズの制御アプリケーションが混在しているため、周期データメッセージの送信側では、送信周期が乱れたことを通知する周期エラーフラグだけを設定し、周期データメッセージの受信側で、周期エラーフラグの設定状況に応じて処理実行する方が効率がよい。
【０１０６】
一方、例えば、鉄鋼システムのようなシステムでは、ノード１００間のデータ通信には共有メモリによるサイクリック通信が利用されることが多い。周期データメッセージを利用せず、このサイクリック通信を利用することで、一定周期毎の同報通信を行うことが可能となる。図１１は、サイクリック通信を行う通信制御部１６０の構成、図１２は、共有メモリの構成をそれぞれ示した図である。共有メモリ１２００は各々のノードにアドレスが特定されており、各ノードは他のノードにある共有メモリ１２００の予め定められたアドレスへデータを書き込むことができる。
【０１０７】
通信制御部１６０は、図１１に示す共有メモリ１２００によるサイクリック通信を行うため、サイクリック通信部１６８を具備する。
【０１０８】
共有メモリ１２００は、ノード１００aの書込み領域１２１０と、ノード１００bの書込み領域１２２０と、ノード１００cの書込み領域１２３０と、ノード１００dの書込み領域１２４０とを具備する。
【０１０９】
各ノードの書込み領域とは、ノード１００がデータ書込みを行うことができる領域であり、周期応答部１６４は、データ取得部１６５を介して、データ書込みを行う。なお、他の領域に関しては、他ノード１００は書き込むことはできないが、読出しを行うことは可能である。
【０１１０】
サイクリック通信部１６８は、タイマ１１３を利用して、定期的にメッセージ生成/送信部１６１を通じて、自ノード１００の書込み領域を他ノード１００に対して送信する。
【０１１１】
また、メッセージ解析/受信部１６２を通じて、他ノード１００の書込み領域を受信したサイクリック通信部１６８はデータ取得要求受付部１６３を介して、制御アプリケーション１７０にデータを通知する。
【０１１２】
サイクリック通信を利用するためには、図１３(a)に要求管理テーブル１３０、図１３(b)に応答管理テーブル１４０にそれぞれ共有メモリアドレス１３１０を追加する。
【０１１３】
データ取得要求受付部１６３、ならびに周期応答部１６４は共有メモリアドレス１３１０が追加されたテーブルを参照して、データの読み込み、ならびに書き込みを行う。
【０１１４】
なお、ステップ６１０と同様、サイクリック通信を利用する場合でも、サイクリック通信に必要な処理時間から最大周期応答数を算出し、ステップ８５６〜ステップ８６２で示した方法により、サイクリック通信部１６８を利用したデータの周期取得が、制御アプリケーション１７０の動作を妨げず、一定周期で行うことを可能とする。
【０１１５】
ステップ９５８〜ステップ９７２で示した方法により検出した制御アプリケーション１７０の動作変化を、共有メモリに周期エラーフラグとして設定することにより、ステップ９２０〜ステップ９２８と同様の処理が可能となる。
【０１１６】
以上、実施例を具体的に説明したが、上記開示に限定されるものでなく、その趣旨を逸脱しない範囲において種々変更可能であることは言うまでもない。
【符号の説明】
【０１１７】
１００・・・ノード、１０２・・・ネットワーク、１１０・・・ハードウェアモジュール、１１１・・・処理部、１１２・・・通信ＩＦ、１１３・・・タイマ、１１４・・・記憶装置、１２０・・・設定ファイル、１３０・・・要求管理テーブル、１４０・・・応答管理テーブル、１５０…ＯＳ、１６０…通信制御部、１６１…メッセージ生成/送信部、１６２・・・メッセージ解析/受信部、１６３・・・データ取得要求受付部、１６４・・・周期応答部、１６５…データ取得部、１６６・・・応答管理部、１６７…アプリ動作監視部、１６８…サイクリック通信部、１７０・・・制御アプリケーション、１２００…共有メモリ
【図１】
0006464035.tif 000002
【図２】
0006464035.tif 000003
【図３】
0006464035.tif 000004
【図４】
0006464035.tif 000005
【図５（ａ）】
0006464035.tif 000006
【図５（ｂ）】
0006464035.tif 000007
【図５（ｃ）】
0006464035.tif 000008
【図６】
0006464035.tif 000009
【図７】
0006464035.tif 000010
【図８（ａ）】
0006464035.tif 000011
【図８（ｂ）】
0006464035.tif 000012
【図９（ａ）】
0006464035.tif 000013
【図９（ｂ）】
0006464035.tif 000014
【図１０】
0006464035.tif 000015
【図１１】
0006464035.tif 000016
【図１２】
0006464035.tif 000017
【図１３（ａ）】
0006464035.tif 000018
【図１３（ｂ）】
0006464035.tif 000019