JP3712072B2 - モニタ・ロギング装置 - Google Patents

Description

本発明は、スイッチ，センサ等の制御機器をモニタするモニタ・ロギング装置に関するものである。

従来、制御システムにおいて用いられているモニタ・ロギング装置では、制御の状態をリアルタイムに画面上に表示したり（モニタリング）、制御システムの状態を一定周期で記録しておき（データロギング）、その後、制御状態の解析を行なったりするようになっている。

ところで、近年、制御システムでは、例えば図１４に示すように、マスタ局として機能するプログラマブルコントローラ等の制御装置１０と、マスタ局としての制御装置１０に対してスレーブ局として機能する位置制御コントローラ等の制御機器２０と、モニタ・ロギング装置３０とがネットワーク４０に接続されて構成されている。

このシステムでは、ノード１に有する制御装置１０は、制御機器２０からＩ／Ｏデータを取得しており、この取得したＩ／Ｏデータに基づき、スレーブ局としての制御機器２０を制御するようになっている。

ノード５に有するモニタ・ロギング装置３０は、制御機器２０のＩ／Ｏデータを取得し、この制御データを用いて、制御の状態をリアルタイムに画面上に表示してモニタリングしたり、制御システムの状態を一定周期で記録しておき、後に、制御システムに何らかのトラブルが発生したとき、トラブル原因を解析するのに使用されている。

このような制御システムにおいては、データを送受信する方式として、コマンド・レスポンス方式が一般的に採用されている。

このコマンド・レスポンス方式は、図１５に示すように、制御装置１０が制御機器２０に対してＩ／Ｏデータを取得しようとするときには、制御用のコマンドフレームを制御機器２０に送信し、このコマンドフレームに対するレスポンスフレームを制御機器２０から受信した後、Ｉ／Ｏデータを取得するようになっている。

また、モニタ・ロギング装置３０が制御機器２０に対してモニタ・ロギング用の制御データを取得しようとするときには、モニタ・ロギング用のコマンドフレームを制御機器２０に送信し、このコマンドフレームに対するレスポンスフレームを制御機器２０から受信した後、モニタ・ロギング用の制御データを取得するようになっている。

なお、上述した制御システムは、データを送受信する方式として、コマンド・レスポンス方式が一般的に採用されていると述べたが、使用するネットワークのプロトコルによっては、あるノードが１つ以上のノードと通信できないような方式のものもある。

上述した従来の制御システムに使用されているモニタ・ロギング装置では、上述したようなコマンド・レスポンス方式が採用されているので、以下のような問題点があった。

（１）ネットワークトラフィックの増加
図１５に示すように、モニタ・ロギング装置がネットワーク４０上にモニタ・ロギング用のコマンドを送信し、このコマンドを受信したノードの制御機器２０がそれに対するレスポンスをネットワークに送信するので、この分ネットワーク４０上のトラフィックが増加し、制御システムの機能を低下させてしまうという問題点があった。

特に、制御装置１０がプログラマブルコントローラの場合には、プログラマブルコントローラが、所定のスキャンタイム内に各制御機器２０に対してＩ／Ｏデータを取得しなければシステムエラーとなるため、モニタ・ロギング装置３０からモニタ・ロギング用のコマンドおよびそれに対するレスポンスによるトラフィックの増加は、制御システムの機能を低下させる重大な要因となる。

（２）ノードに対する負荷の増加
従来のモニタ・ロギング装置では、各制御機器２０は、制御装置１０から送信された制御用のコマンドを受信し、このコマンドに対するレスポンスを制御装置１０に送信するとともに、モニタ・ロギング装置３０から受信したモニタリング用のコマンドを受信し、このコマンドに対するレスポンスをモニタ・ロギング装置３０に送信するので、処理の負荷が増加する。

このため、従来のシステムでは、各ノードに有する制御機器２０の処理内容が制限され、強いては、システム全体が制約されるという問題点があった。

（３）ネットワークリソース（ノードアドレス）の占有
一般に、ネットワーク上のあるノードに対してコマンドを送信する場合には、そのコマンドフレーム中に送信元を指定するノードアドレス（例えばＭＡＣ ＩＤ）を有する必要がある。

従って、従来の制御システムでは、モニタ・ロギング装置３０がネットワーク４０に有するノードアドレスの１つを占有してしまい、システム全体の構成を制限してしまうという問題点があった。

（４）ネットワークプロトコルによっては本方式の使用が困難
上述したように、使用するネットワークのプロトコルによって、あるノードが１つ以上のノードと通信できないような方式を有する制御システムでは、モニタ・ロギング装置３０を制御システムに付加することが不可能であるという問題点があった。

そこで、本発明は、上述した問題点に鑑み、（１）ネットワークのトラフィックを増加させず、（２）各ノードに有する制御機器に対する負荷を抑え、（３）ノードアドレスを付加させず、（４）あるノードが１つ以上のノードと通信できないような方式を有するプロトコルを有する制御システムでも、モニタ・ロギングを行なえるモニタ・ロギング装置を提供することを目的とする。

上記目的を達成するために、本発明は、制御装置側のマスタ局と制御機器側のスレーブ局とがネットワークを介してデータを通信し制御装置は取得したデータに基づき演算処理を行いその演算処理結果に基づき制御機器に対して所定の動作を実行させる制御システムのネットワークに接続し、ネットワークに接続されたマスタ局と複数のスレーブ局との間で通信されるフレームをすべて受信し、そのフレーム中のヘッダおよびデータフィールドを解読してデータを取得するフレーム解読部を備えたモニタ・ロギング装置であって、前記フレーム解読部は、前記受信したすべてのフレームのヘッダを参照して、複数のスレーブ局のうち対象となるスレーブ局に対して送信されたフレームか、前記対象となるスレーブ局が送信したフレームか、前述の両方のフレームか、のいずれかのフレームのみを選択受信するようになっていて、前記選択受信したフレームのデータフィールドが所定の長さか否かを判断し、所定の長さであればフレーム解読をするようになっていて、否であればフレーム解読しないようになっていて、前述の選択受信し、かつフレーム解読する対象のフレームについてのみ、フレーム中のデータフィールドを解読し、対象となるスレーブ局に対して送信されたフレームを選択受信するようにした場合にはマスタ局から対象となるスレーブ局に対して送信されたＯＵＴデータのみを取得し、対象となるスレーブ局が送信したフレームを選択受信するようにした場合には対象となるスレーブ局がマスタ局へ送信したＩＮデータのみを取得し、両方のフレームを選択受信するようにした場合には対象となるスレーブ局に関するＩＮデータおよびＯＵＴデータの両方を取得することにより、モニタ・ロギング用のデータを取得することを特徴とする。

本発明は、制御装置側のマスタ局と制御機器側のスレーブ局とがネットワークを介してデータを通信し制御装置は取得したデータに基づき演算処理を行いその演算処理結果に基づき制御機器に対して所定の動作を実行させる制御システムのネットワークに接続し、ネットワークに接続されたマスタ局と複数のスレーブ局との間で通信されるフレームをすべて受信し、そのフレームからデータを取得するモニタ・ロギング装置であって、前記受信したすべてのフレーム中のヘッダおよびデータフィールドを解読し、その解読をすることによってマスタ局とスレーブ局との間で通信されるＩＮデータとＯＵＴデータとを取得し、取得したデータを内蔵のバッファに書き込むフレーム解読部と、前記フレーム解読部のバッファからＩＮデータとＯＵＴデータを読み出し、これをハードディスク等の記憶手段に格納するアプリケーション部と、を備え、前記フレーム解読部は、前記受信したすべてのフレームのヘッダを参照して、複数のスレーブ局のうち対象となるスレーブ局に対して送信されたフレームか、前記対象となるスレーブ局が送信したフレームか、前述の両方のフレームか、のいずれかのフレームのみを選択受信する受信フィルタ手段と、前記選択受信したフレームのデータフィールドが所定の長さか否かを判断し、所定の長さであればフレーム解読をするようにし、否であればフレーム解読しないようにする有効フレーム受信検知手段と、を備え、前記受信フィルタ手段が選択受信し、かつ有効フレーム受信検知手段がフレーム解読対象としたフレームについてのみ、フレーム中のデータフィールドを解読し、対象となるスレーブ局に対して送信されたフレームを選択受信するようにした場合には、マスタ局から対象となるスレーブ局に対して送信されたＯＵＴデータのみを取得し、前記受信フィルタ手段を対象となるスレーブ局が送信したフレームを選択受信するようにした場合には対象となるスレーブ局がマスタ局へ送信したＩＮデータのみを取得し、前述の両方のフレームを選択受信するようにした場合には対象となるスレーブ局に関するＩＮデータおよびＯＵＴデータの両方を取得することにより、モニタ・ロギング用のデータを前記バッファに書き込むことを特徴とする。

本発明によれば、ネットワーク上で通信されているフレームを、自らネットワークにコマンドを送信することをせずにすべて受信し、この受信した通信データを解読するようにしたことにより、ネットワークアドレスを不要とすることができる。

従って、モニタ・ロギング装置がネットワークアドレスを有していないため、ノードアドレスの占有を免れることができ、その分稼動させる制御機器を増やすことができる。

また、データを取得する際に、データを取得するためのコマンドを送信することなく、フレームを受信できるため、ネットワーク上のトラフィックを減少させるとともに無駄な処理を減少させ、制御システムの機能を高めることができ、更に使用するネットワークのプロトコルの制限に関らず、制御システムのモニタ・ロギングを行なうことができる。

以下、本発明に係るモニタ・ロギング装置の一実施形態を、図面を参照して詳細に説明する。

図１はモニタ・ロギング装置を有する制御システムの構成を示すブロック図である。

本発明に係る制御システムは、ノード１に有する制御装置１０と、ノード２，３，４に有する制御機器２０と、モニタ・ロギング装置３０とが、下位層（物理層、データリンク層）にＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）を利用しているネットワークプロトコルの１つであるデバイスネット（ＤｅｖｉｃｅＮｅｔ）２に接続されて構築されている。

ここで、制御システムを構築する各構成物の内容を説明する前に、デバイスネット２を介して送受信されるフレームについて、図２を参照して説明する。

デバイスネット２を介して送受信されるフレーム６は、ＣＡＮプロトコルで使用され、かつ、リモートＩ／Ｏシステムに対応したプリデファイン マスタ／スレーブ コネクション セット（Ｐｒｅｄｅｆｉｎｅｅｄ Ｍａｓｔｅｒ／Ｓｌａｖｅ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔ）で定義されているフレーム構成を有している。

このフレーム６は、図２（ａ）に示すように、１９ビット（Ｂｉｔ）からなるＣＡＮヘッダフィールド（ＣＡＮ ＨＥＡＤＥＲ ＦＩＥＬＤ）６１と、最大６４ビット（８バイト）からなるデータフィールド（ＤＡＴＡ ＦＩＥＬＤ）６２と、２５ビットからなるＣＡＮトレイラーフィールド（ＣＡＮＮ ＴＲＡＩＬＥＲ ＦＩＥＬＤ）６３とから構成されている。

１）ＣＡＮヘッダフィールド６１について
ＣＡＮヘッダフィールド６１は、図２（ｂ）に示すように、１ビットからなるスタートビット（Ｓｔａｒｔ Ｂｉｔ）と、１１ビットからなるＣＡＮアイデンティファイアー（ＣＡＮ Ｉｄｅｎｔｉｆｉｉｅｒ）ビット６１２と、１ビットからなるＲＴＲビット６１３と、６ビットからなるコントロールビット６１４とから構成されている。

スタートビット（Ｓｔａｒｔ Ｂｉｔ）６１１は、フレームの開始を示す情報を有しており、ＣＡＮアイデンティファイアー（ＣＡＮ Ｉｄｅｎｔｉｆｉｅｒ）ビット６１２は、マスタ／スレーブ コネクション セットの定義、すなわち送受信先がマスタであるかスレーブであるかを示すノード役割情報，ノードアドレスを示すノードアドレス情報，および使用する通信方式を示す通信方式情報を有している。

ノードアドレス情報は、デバイスネット２ではＭＡＣ ＩＤとよばれ、６ビットで表わされており、そのため、使用できる数値は１０進数として０から６３である。

なお、デバイスネット２上では、各ノードは、異なるＭＡＣ ＩＤが割り当てられている。

通信方式情報には、高速なデータ通信が可能なビットストローブ（Ｂｉｔ−Ｓｔｒｏｂｅ）方式と、大量なデータの送信が可能なポール（Ｐｏｌｌ）方式とがある。

ビットストローブ方式は、マスタ局としての制御装置１０から送信されたコマンドフレームがすべてのスレーブ局としての制御機器２０に受信される通信方式であり、コマンドフレームを受信した制御機器２０は、このフレームのデータフィールド６２のうち、自己のＭＡＣ ＩＤに対応した１ビットに有する情報を、自己に対する出力データとして認識するようになっている。

例えば、図３に示すように、０ビットから順に６３ビットにセットされた情報は、ＭＡＣ ＩＤが“０”を有する制御機器２０から順にＭＡＣ ＩＤが“６３”を有する制御機器２０に対する出力情報を示している。

ＲＴＲビット６１３はエラーを検出する情報を有しており、コントロールビット６１４はコントロール情報を有している。

ここで、上述したビットストローブとポール方式との通信方式について、更に詳細に図４に基づいて説明する。

ａ）ビットストローブ方式について
図４（ａ）の（１）の欄に示すように、マスタ局としての制御装置１０がスレーブ局として制御機器２０に対して送信するフレームの場合には、９ビットに“０”と１０ビットに“１”がセットされ、また、３ビットから８ビットにかけてマスタ局としての制御装置１０のＭＡＣ ＩＤがセットされ、更に０ビットから２ビットに“０，０，０”がセットされる。

ここで、例えば、制御装置１０のＭＡＣ ＩＤを１０進法で“６３”とした場合には、３ビットから８ビットには、“１，１，１，１，１，１”がセットされる。

図４（ａ）の（２）の欄に示すように、スレーブ局としての制御機器２０がマスタ局としての制御装置１０に対して送信するフレームの場合には、９ビットに“１”と１０ビットに“０”がセットされ、６ビットから９ビットにかけて“１，１，１，０”がセットされ、更に、０ビットから５ビットにかけて制御機器２０のＭＡＣ ＩＤがセットされる。

例えば、制御機器２０のＭＡＣ ＩＤを１０進法で“０”とした場合には、０ビットから５ビットには、“０，０，０，０，０，０”がセットされる。

ｂ）ポール方式について
図４（ｂ）の（１）の欄に示すように、マスタ局としての制御装置１０がスレーブ局として制御機器２０に対して送信するフレームの場合には、９ビットに“０”と１０ビットに“１”がセットされ、また、３ビットから８ビットにかけて送信先の制御機器２０のＭＡＣ ＩＤがセットされ、更に０ビットから２ビットに“１，０，１”がセットされる。

例えば、フレームを送信する制御機器２０のＭＡＣ ＩＤを１０進法で“６２”とした場合には、３ビットから８ビットにかけて“１，１，１，１，１，０”がセットされる。

図４（ｂ）の（２）の欄に示すように、スレーブ局としての制御機器２０がマスタ局としての制御装置１０に対して送信するフレームの場合には、９ビットに“１”と１０ビットに“０”がセットされ、６ビットから９ビットにかけて“１，１，１，１”がセットされ、更に、０ビットから５ビットにかけて制御機器２０のＭＡＣ ＩＤがセットされる。

例えば、フレームを送信する制御機器２０のＭＡＣ ＩＤを１０進法で“１”とした場合には、３ビットから８ビットにかけて“０，０，０，０，０，１”がセットされる。

２）データフィールド６２について
ところで、デバイスネット２では、一回に送信可能なデータのデータ量が最大８バイト（Ｂｙｔｅ）である。このため、それ以上のデータ量を有するデータを送信する場合には、分割送信しなければならない。

図５は分割送信する場合のデータフィールドの内容を説明する図である。

図５に示すように、分割送信する場合におけるデータフィールド６２は、バイトナンバー（Ｂｙｔｅ Ｎｕｍｂｅｒ）が“０”で示された１バイトの０ビットから５ビットにかけて、何フレーム目のデータであるかを識別するフラグメントカウント（Ｆｒａｇｍｅｎｔ Ｃｏｕｎｔ）情報を有しており、また、６ビットと７ビットとに送信したデータの属性を示すフラグメントタイプ（Ｆｒａｇｍｅｎｔ Ｔｙｐｅ）情報を有している。

また、このデータフィールド６２は、バイトナンバーが“１”から“７”で示された２バイトから８バイトにわたってＩ／Ｏメッセージを有している。

上述したフラグメントタイプについて、図６を参照して更に詳細に説明する。

図６に示すように、フラグメントタイプは、その値が“０”の場合には、ファーストフラグメント（Ｆｉｒｓｔ Ｆｒａｇｍｅｎｔ）、すなわちフレーム中の最初のデータであることを示し、値が“２”の場合には、ラストフラグメント（Ｌａｓｔ Ｆｒａｇｍｅｎｔ）、すなわちフレーム中の最後のデータであることを示し、値が“１”の場合には、ミドルフラグメント（Ｍｉｄｄｌｅ Ｆｒａｇｍｅｎｔ）、すなわちファーストフラグメントに該当するデータとラストフラグメントに該当するデータの間にあるデータを示している。

上述したフラグメントカウンタは、６ビットで表現されるので、最大３Ｆ（ヘキサデシマル表示）までセットすることができる。フレーム数が３Ｆ以上の場合には、再度０からセットされる。

なお、ファーストフラグメントの場合には、そのフラグメントカウンタが０または３Ｆでなければならない。デバイスネット２のＩ／Ｏ通信では、マスタ、スレーブ間で分割送信を使用するかどうかは実際のＩ／Ｏデータの交換を開始する前に初期設定により決定される。

そのため、１度分割送信ありで通信を開始すると、データ量が１フレームで終了するものであっても、分割送信の手順に従うことになる。この場合、ファーストフラグメントでありラストフラグメントということになる。つまり、ファーストフラグメントにおけるフラグメントカウンタが３Ｆを有するものは、最初で最後のフラグメントという特殊な意味を示す。

図７はフラグメントでない場合のデータフィールド６２の内容を説明する図である。

この場合には、データフィールド６２は、図に示すように、１バイト目にフラグメントタイプおよびフラグメントカウントを有しない。

次に、モニタ・ロギング装置を構築する各構成物の構成について説明する。なお、モニタ・ロギング装置はＷｉｎｄｏｗｓ（登録商標）ソフトウェアとして実装したものである。

ノード１に有する制御装置１０は、例えばプログラマブルロジックコントローラ（ＰＬＣ），ソフトＰＬＣが実装されているＰＣ（パーソナル コンピュータ）等からなり、ノード２，３，４に有する制御機器２０からＩ／Ｏデータを取得しており、この取得したＩ／Ｏデータに基づき演算処理を行い、その演算処理結果に基づき、ノード２，３，４の制御機器２０に対して所定の動作を実行させるコマンドを出力するようになっている。

制御機器２０は、スイッチ，リレー，温度センサ，インバータ、アクチュエータ等からなり、制御装置１０の制御に基づき、Ｉ／Ｏデータを制御装置１０に送信するとともに所定の動作を実行するようになっている。

モニタ・ロギング装置３０は、自身がノードとしてのアドレスを有していないものであって、自らネットワークコマンドを送信することなしにデバイスネット２を介してフレーム６を受信し（図１の（１）参照）、受信したフレーム６をフレーム情報に基づきフレーム中のＣＡＮヘッダ６１およびデータフィールド６２の詳細情報を解読するようになっている(図１の（２）参照)。

すなわち、モニタ・ロギング装置３０は、デバイスネット２を介して制御装置１０と制御機器２０間に送受信されているフレーム６を受動的に受信することを特徴とするものである。

さらに言換えると、モニタ・ロギング装置は、自らネットワークコマンドを送信することなく、制御装置１０と制御機器２０間の外的作用でデバイスネット２に通信されているフレーム６を受信するようになっている。

また、モニタ・ロギング装置３０は、フレーム情報に基づきフレームの内容を解読した結果（図１の（３）参照）、モニタリングまたはロギングに必要なフレームである場合には、ノード情報に基づきこのフレームを取得するようになっている。

前記フレーム情報は、デバイスネットプロトコル情報を示す情報であって、その情報にはマスタ・スレーブ間でやり取りするメッセージのフォーマットや意味を全て含んでいる。

前記ノード情報は、データ収集する対象のノード（スレーブ）が、マスタとのポール、ストローブの各Ｉ／Ｏ通信方式において通信を行なうＩ／Ｏデータのサイズ（ＩＮＰＵＴ，ＯＵＴＰＵＴ）の情報を含んでいる。

図８はモニタ・ロギング装置の概略構成を示すブロック図である。

このモニタ・ロギング装置３０は、アプリケーション（Ａｐｐｌｃａｔｉｏｎ）部３１０と、フレーム解読部（Ｃｏｒｅ Ｍｏｄｕｌｅ ＤＬＬ部）３２０と、ＤｅｖｉｃｅＮｅｔ Ｉ／Ｆ部３３０とから構成されている。

アプリケーション部３１０は、後述するノード情報をソフトウェア上に有している。

フレーム解読部３２０は、アプリケーション（Ａｐｐｌｃａｔｉｏｎ）部３１０より、ノード情報を読み込むようになっており、このノード情報は、フレーム解読部３２０に記憶される。

先に述べたノード情報について更に詳細に説明すると、ノード情報は、図９に示すように、通信方式がポール方式によるものであるか、またはビットストローブ方式によるものであるかを示す情報と、各方式で通信Ｉ／Ｏデータのデータサイズを示す情報を有している。

なお、図中のＯＵＴＳｉｚｅ１、ＩＮＳｉｚｅ１は、ポール通信方式を使用する場合のデータサイズを示しており、ＯＵＴＳｉｚｅ２、ＩＮＳｉｚｅ２は、ビットストローブ通信方式のデータサイズを示している。

また、アプリケーション（Ａｐｐｌｃａｔｉｏｎ）部３１０は、後述するフレーム解読部３２０で形成されたモニタ・ロギングデータを一定間隔ごと、Ｉ／Ｏデータエリアから取得し、これをハードディスク等の記憶手段（図示せず）に格納するようになっている。

フレーム解読部３２０は、アプリケーション部３１０から受けたノード情報と、ソフトウェアに記述されているフレーム情報とに基づき、受信したフレーム６を解読し、この解読したフレーム６からＩ／Ｏデータを形成するようになっている。

先に述べたフレーム情報について、図１０を参照して説明する。

ここで、グループ ＩＤ（Ｇｒｏｕｐ ＩＤ）は、デバイスネット２で使用できる１１ビットのＣＡＮ ＩＤをグループ（Ｇｒｏｕｐ）１，グループ（Ｇｒｏｕｐ）２，グループ（Ｇｒｏｕｐ）３，グループ（Ｇｒｏｕｐ）４という用途別にグループ分けしたときのグループを識別する値（１〜４）である。

メッセージ ＩＤ（Ｍｅｓｓａｇｅ ＩＤ）は、あるエンドポイントにおいてメッセージグループ内の各メッセージを識別する値である。

Ａの欄に示したポールコマンド（Ｐｏｌｌ Ｃｏｍｍａｎｄ）は、グループ ＩＤとして“２”を、また、メッセージ ＩＤとして“５”を有しており、このコマンドがＯＵＴデータであることを示している。

また、Ｂの欄に示したビットストローブコマンド（Ｂｉｔ−Ｓｔｒｏｂｅ Ｃｏｍｍａｎｄ）は、グループ ＩＤとして“２”を、また、メッセージ ＩＤとして“０”を有しており、このコマンドが１点のみのＯＵＴデータであることを示している。

ＤｅｖｉｃｅＮｅｔ Ｉ／Ｆ部３３０は、デバイスネット２上に送信されているすべてのフレームを受信するようになっている。

ここで、上述したフレーム解読部３２０を更に詳細に説明する。

図１１はフレーム解読部の構成を示すブロック図である。

フレーム解読部３２０は、受信フィルタ手段３２０ａと、有効フレーム受信検知手段３２０ｂと、フレーム解析手段３２０ｃと、フラグバッファ（Ｆｒａｇｍｅｎｔ Ｂｕｆｆｅｒ）３２０ｄと、Ｉ／Ｏデータバッファ３２０ｅと、フラグメントカウンタ３２０ｆと、フレーム情報を有するフレーム情報憶部３２０ｇと、ノード情報記憶部３２０ｈとから構成されている。

受信フィルタ手段３２０ａは、デバイスネット Ｉ／Ｆ３３０を介して受信したフレーム６のＣＡＮヘッダーフールド６１に有するＣＡＮアイデンティファイアー６１２を参照し、受信すべきフレームのみを選択するようになっている（フィルタをかける）。

受信フィルタ手段３２０ａが選択受信するフレーム６は、図１２に示すようなものである。

（１）ＯＵＴデータのみの場合、すなわち対象となるＭＡＣ ＩＤを有する制御機器２０に対して送信されたフレームが、ポールコマンドフレーム、または、すべてのビットストローブコマンドフレームのもの
（２）ＩＮデータのみの場合、すなわち対象となるＭＡＣ ＩＤを有する制御機器２０から制御装置１０に対して送信されたフレームが、ポールレスポンフレーム、または、ビットストローブレスポンスフレームのもの
（３）ＯＵＴおよびＩＮデータ両方のもの、すなわち前述の（１）および（２）のフレームのもの

有効フレーム受信検知手段３２０ｂは、受信フィルタ手段３２０ａからフレーム６を受けると、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有しているか否かを判断し、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有していると判断した場合には、その旨をフレーム解析手段３２０ｃに通知するようになっている。

フレーム解析手段３２０ｃは、フレーム情報記憶部３２０ｇに有するフレーム情報に基づき、受信したフレーム６を解読するようになっている。

なお、その詳細な内容は、後述するこの実施形態に係るモニタ・ロギング装置の動作において説明されているので、その詳細説明を省略する。

フラグメントバッファ（Ｆｒａｇｍｅｎｔ Ｂｕｆｆｅｒ）３２０ｄは、受信したフレームがポール通信方式のもので、かつ、フラグメントを使用している場合には、そのフレーム６のデータを一時記憶するものである。

Ｉ／Ｏデータバッファ３２０ｅは、形成したＩ／Ｏデータを記憶するものである。

フラグメントカウンタ３２０ｆは、ポール通信方式のものであって、かつ、フラグメントがあるフレーム６のデータを受信するごとに、フレーム解析手段３２０ｃの指示のもとカウンタ値に１を加算し、送信されてきたデータがラストフラグメントの場合には、フレーム解析手段３２０ｃの指示のもとカウント値をクリアするようになっている。なお、これらの処理は、各ＭＡＣ ＩＤ毎に行なわれる。

フレーム情報記憶部３２０ｇはフレーム情報を有するものであり、ノード情報記憶部３２０ｈは、アプリケーション部３１０から取得したノード情報を記憶するものである。

続いて、この実施形態のモニタ・ロギング装置の動作を、図１３のフローチャートを参照して説明する。

フレーム解読部３２０は、デバイスネット Ｉ／Ｆ３３０で受信したフレーム６を受けると、受信フィルタ手段３２０ａが予め決定されているデバイスＩ／Ｏタイプ（図１０を参照）のフレーム６のみを選択的に受信し（フィルタをかけ）、選択的に受信したフレーム６を有効フレーム受信手段３２０ｂに出力する（ステップ１１０）。

有効フレーム受信検知手段３２０ｂは、受信フィルタ手段３２０ａからフレーム６を受けると、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有しているか否かを判断する（ステップ１２０）。

有効フレーム受信検知手段３２０ｂは、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有していると判断した場合には（ステップ１２０；Ｙ）、その旨をフレーム解析手段３２０ｃに通知する。

一方、有効フレーム受信検知手段３２０ｃは、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有していないと判断した場合には（ステップ１２０；Ｎ）、ステップ１１０に移行して上述したと同様な処理を続行する。

フレーム解析手段３２０ｃは、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有している旨の通知を有効フレーム受信検知手段３２０ｂから受けると、フレーム６中のＣＡＮヘッダ６１を参照し、受信したフレーム６がポール通信方式によるメッセージ（Ｐｏｌｌ Ｍｅｓｓａｇｅ）であるか否かを判断する（ステップ１３０）。

フレーム解析手段３２０ｃは、ポール通信方式によるＩ／Ｏデータ（メッセージ）でないと判断した場合、すなわちビットストローブ通信方式によるＩ／Ｏデータである場合には（ステップ１３０；Ｎ）、Ｉ／Ｏデータバッファ３２０ｅにＩ／Ｏデータをリフレッシュする（ステップ１４０）、その後、ステップ１１０に移行して上述したと同様な処理を続行する。

一方、フレーム解析手段３２０ｃは、ポール通信方式によるＩ／Ｏデータであると判断した場合には（ステップ１３０；Ｙ）、ノード情報に基づきフラグメントカウントを有しているか否かを判断する（ステップ１５０）。

フレーム解析手段３２０ｃは、受信したフレーム６中のＩ／Ｏデータがノード情報に基づき、フラグメントタイプおよびフラグメントカウントを有していないと判断した場合には（ステップ１５０；Ｎ）、後述するステップ２１０に移行する一方、データフィールド６２にフラグメントタイプおよびフラグメントカウントを有していると判断した場合には（ステップ１５０；Ｙ）、内部状態がファーストフラグメント待ちの状態であるか否かを判断する（ステップ１６０）。

フレーム解析手段３２０ｃは、内部状態がファーストフラグメント待ちの状態でないと判断した場合には（ステップ１６０；Ｎ）、後述するステップ１７０に移行する一方、内部状態がファーストフラグメント待ちの状態であると判断した場合には（ステップ１６０；Ｙ）、受信したフレーム６中のデータフィールド６２中のフラグメントタイプがファーストフラグメントであるか否かを判断する（ステップ１８０）。

フレーム解析手段３２０ｃは、受信したフレーム６中のデータフィールド６２中のフラグメントタイプがファーストフラグメントでないと判断した場合には（ステップ１８０；Ｎ）、後述するステップ２２０に移行する一方、受信したフレーム６中のデータフィールド６２中のフラグメントタイプがファーストフラグメントであると判断した場合には（ステップ１８０；Ｙ）、フラグメントカウントが“０Ｘ３Ｆ”であるか否かを判断する（ステップ１９０）。

フレーム解析手段３２０ｃは、フラグメントカウントが“０Ｘ３Ｆ”でないと判断した場合には（ステップ１９０；Ｎ）、後述するステップ２００に移行する。一方、フレーム解析手段３２０ｃは、フラグメントカウントが“０Ｘ３Ｆ”であると判断した場合には（ステップ１９０；Ｙ）、フレーム６を該当するＭＡＣ ＩＤの箇所のＩ／Ｏデータバッファ３２０ｅに記憶させる（ステップ２１０）。

その後、フレーム解析手段３２０ｃは、内部で保持しているフラグメント情報（フラグメントカウンタ、ファーストフラグメント待ち状態）を初期化し、一定時間間隔でＩ／Ｏデータバッファ３２０ｅに書き込まれたモニタ・ロギングデータを読み出し、これをハードディスク等の記憶手段に記憶させたのち（ステップ２２０）、ステップ１１０に移行し上述したと同様な処理を行なう。

ステップ１６０において、フレーム解析手段３２０ｃは、内部状態がファーストフラグメント待ちの状態でないと判断した場合には（ステップ１６０；Ｎ）、受信したフレーム６のデータフィールド６２中に有するフラグメントカウントが一致しているか否かを判断する（ステップ１７０）。

フレーム解析手段３２０ｃは、受信したフレーム６のデータフィールド６２中に有するフラグメントカウントが一致していないと判断した場合には（ステップ１７０；Ｎ）、ステップ２２０に移行する一方、受信したフレーム６のデータフィールド６２中に有するフラグメントカウントが一致していると判断した場合には（ステップ１７０；Ｙ）、Ｉ／Ｏデータをフラグメントバッファ３２０ｄに書き込む（ステップ２００）。

次に、フレーム解析手段３２０ｃは、受信したフレーム６のデータフィールド６２中に有するフラグメントカウントがラストフラグメントであるか否かを判断する（ステップ２３０）。

フレーム解析手段３２０ｃは、フレーム６のデータフィールド６２中に有するフラグメントカウントがラストフラグメントであると判断した場合には（ステップ２３０；Ｙ）、ステップ２１０に移行する一方、フレーム６のデータフィールド６２中に有するフラグメントカウントがラストフラグメントでないと判断した場合には（ステップ２３０；Ｎ）、フレーム解読部３２０に有するフラグメントカウンタに１を加算して、新たなカウント値とし（ステップ２４０）、ステップ１１０に移行し、上述したと同様な処理を続行する。

この実施形態のモニタ・ロギング装置では、自らフレーム（コマンド）を送信する必要がないから、ネットワークアドレスを不要とすることができる。

従って、モニタ・ロギング装置３０がネットワークアドレスを有していないため、ノードアドレスの占有を免れることができ、その分稼動させる制御機器２０、例えばスイッチ，リレー等を増やすことができる。

また、Ｉ／Ｏデータを取得する際に、Ｉ／Ｏデータを取得するためのコマンドを送信することなく、フレームを受信できるため、ネットワーク上のトラフィックを減少させるとともに無駄な処理を減少させ、制御システムの機能を高めることができるとともに、１つのノードに対してしか通信できないプロトコルを採用するシステムでも、モニタ・ロギングすることができる。

なお、フレーム解析の実行タイミングは、フレーム受信ごとの場合であってもよいし、また、いったん受信フレームを記憶させておき、周期的にまとめて解析する場合であってもよい。

また、この実施形態のモニタ・ロギン装置は、モニタ表示画面を含むものでもよいし、含まないものでもよい。含まない場合には、別途モニタ表示画面を外付け接続すればよい。

本実施形態によれば、ネットワーク上で通信されているフレームを、自らネットワークにコマンドを送信することをせずにすべて受信し、この受信した通信データを解読するようにしたことにより、ネットワークアドレスを不要とすることができる。

また、データを取得する際に、データを取得するためのコマンドを送信することなく、フレームを受信できるため、ネットワーク上のトラフィックを減少させるとともに、無駄な処理を減少させ、システムの機能を高めることができる。

更に１つのノードに対してしか通信できないプロトコルを採用するシステムでも、モニタ・ロギングすることができる。

本実施形態によると、更にフレーム解読手段で受信したフレームのうち、モニタ・ロギングするフレームを解読するため、モニタ・ロギング用のデータを取得することができる。

本実施形態によると、更にまた、受信フィルタ手段により受信手段で受信したフレームのうち所定のフレームのみを選択するので、モニタ・ロギングに不要なフレームを廃棄することができる。

本実施形態によると、ネットワーク接続時にノードとしてのアドレスを持つことなしに、ネットワーク上で通信されているフレームを受信し、通信データを解読するようになっているので、ノードアドレスの占有を免れることができる。

本実施形態によると、データ取得部が受信フレームを解析して、ネットワークに接続されているノードを特定することと、特定したノードが通信したデータを取得することを行なうようにしたことにより、必要とするノードに対するデータを取得することができる。

本実施形態によると、解読部がフレーム情報に基づき受信したフレームの意味を解読するので、モニタ・ロギング用のデータを取得することができる。

本発明の一実施形態の構成を示すブロック図。 図１中のデバイスネットを介して送受信されるフレームの構成を示すブロック図。 ビットストローブ通信方式におけるコマンドフレームの構成を示すブロック図。 図２中のＣＡＮアイデンティファイアーの構成を示すブロック図。 図２中のデータフィールドの構成を示すブロック図（フラグメント時）。 図５中フラグメントタイプとフラグメントカウントとの内容を説明する図。 図２中のデータフィールドの構成を示すブロック図。 図１中のモニタ・ロギング装置の概略構成を示すブロック図。 デバイスＩ／Ｏ割付を示すブロック図。 図９中の有効フレームチェック手段により選択されるフレームの内容を示す図。 図８中のフレーム解読部の構成を示すブロック図。 Ｉ／Ｏデータとデバイスネットメッセージとの対応を示す図。 図１中のモニタ・ロギング装置の処理動作を示すフローチャート。 従来のモニタ・ロギング装置がコマンドを送信して制御システム内のＩ／Ｏデータを取得する内容を説明する図。 従来のモニタ・ロギングシステムの構成を示す図。

符号の説明

１ 制御システム
２ デバイスネット
１０ 制御装置
２０ 制御機器
３０ モニタ・ロギング装置
３１０ アプリケーション部
３２０ フレーム解読部
３２０ａ 受信フィルタ手段
３２０ｂ 有効フレーム受信検知手段
３２０ｃ フレーム解析手段
３２０ｄ フラグメントバッファ
３２０ｅ Ｉ／Ｏデータバッファ
３２０ｆ フラグメントカウンタ
３２０ｇ フレーム情報記憶部
３２０ｈ ノード情報記憶部
３３０ デバイスネット Ｉ／Ｆ

Claims (2)

1. 制御装置側のマスタ局と制御機器側のスレーブ局とがネットワークを介してデータを通信し制御装置は取得したデータに基づき演算処理を行いその演算処理結果に基づき制御機器に対して所定の動作を実行させる制御システムのネットワークに接続し、ネットワークに接続されたマスタ局と複数のスレーブ局との間で通信されるフレームをすべて受信し、そのフレーム中のヘッダおよびデータフィールドを解読してデータを取得するフレーム解読部を備えたモニタ・ロギング装置であって、
   前記フレーム解読部は、
   前記受信したすべてのフレームのヘッダを参照して、複数のスレーブ局のうち対象となるスレーブ局に対して送信されたフレームか、前記対象となるスレーブ局が送信したフレームか、前述の両方のフレームか、のいずれかのフレームのみを選択受信するようになっていて、
   前記選択受信したフレームのデータフィールドが所定の長さか否かを判断し、所定の長さであればフレーム解読をするようになっていて、否であればフレーム解読しないようになっていて、
   前述の選択受信し、かつフレーム解読する対象のフレームについてのみ、フレーム中のデータフィールドを解読し、対象となるスレーブ局に対して送信されたフレームを選択受信するようにした場合にはマスタ局から対象となるスレーブ局に対して送信されたＯＵＴデータのみを取得し、対象となるスレーブ局が送信したフレームを選択受信するようにした場合には対象となるスレーブ局がマスタ局へ送信したＩＮデータのみを取得し、両方のフレームを選択受信するようにした場合には対象となるスレーブ局に関するＩＮデータおよびＯＵＴデータの両方を取得することにより、モニタ・ロギング用のデータを取得する
   ことを特徴とするモニタ・ロギング装置。
2. 制御装置側のマスタ局と制御機器側のスレーブ局とがネットワークを介してデータを通信し制御装置は取得したデータに基づき演算処理を行いその演算処理結果に基づき制御機器に対して所定の動作を実行させる制御システムのネットワークに接続し、ネットワークに接続されたマスタ局と複数のスレーブ局との間で通信されるフレームをすべて受信し、そのフレームからデータを取得するモニタ・ロギング装置であって、
   前記受信したすべてのフレーム中のヘッダおよびデータフィールドを解読し、その解読をすることによってマスタ局とスレーブ局との間で通信されるＩＮデータとＯＵＴデータとを取得し、取得したデータを内蔵のバッファに書き込むフレーム解読部と、
   前記フレーム解読部のバッファからＩＮデータとＯＵＴデータを読み出し、これをハードディスク等の記憶手段に格納するアプリケーション部と、を備え、
   前記フレーム解読部は、
   前記受信したすべてのフレームのヘッダを参照して、複数のスレーブ局のうち対象となるスレーブ局に対して送信されたフレームか、前記対象となるスレーブ局が送信したフレームか、前述の両方のフレームか、のいずれかのフレームのみを選択受信する受信フィルタ手段と、
   前記選択受信したフレームのデータフィールドが所定の長さか否かを判断し、所定の長さであればフレーム解読をするようにし、否であればフレーム解読しないようにする有効フレーム受信検知手段と、を備え、
   前記受信フィルタ手段が選択受信し、かつ有効フレーム受信検知手段がフレーム解読対象としたフレームについてのみ、フレーム中のデータフィールドを解読し、対象となるスレーブ局に対して送信されたフレームを選択受信するようにした場合には、マスタ局から対象となるスレーブ局に対して送信されたＯＵＴデータのみを取得し、前記受信フィルタ手段を対象となるスレーブ局が送信したフレームを選択受信するようにした場合には対象となるスレーブ局がマスタ局へ送信したＩＮデータのみを取得し、前述の両方のフレームを選択受信するようにした場合には対象となるスレーブ局に関するＩＮデータおよびＯＵＴデータの両方を取得することにより、モニタ・ロギング用のデータを前記バッファに書き込む
   ことを特徴とするモニタ・ロギング装置。

Images