JP3682838B2 - モニタ・ロギング装置 - Google Patents
モニタ・ロギング装置 Download PDFInfo
- Publication number
- JP3682838B2 JP3682838B2 JP01717899A JP1717899A JP3682838B2 JP 3682838 B2 JP3682838 B2 JP 3682838B2 JP 01717899 A JP01717899 A JP 01717899A JP 1717899 A JP1717899 A JP 1717899A JP 3682838 B2 JP3682838 B2 JP 3682838B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- frame
- communication
- fragment
- monitor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Small-Scale Networks (AREA)
- Maintenance And Management Of Digital Transmission (AREA)
- Control By Computers (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、スイッチ，センサ等の制御機器をモニタするモニタ・ロギング装置に関するものである。
【０００２】
【従来の技術】
従来、制御システムにおいて用いられているモニタ・ロギング装置では、制御の状態をリアルタイムに画面上に表示したり（モニタリング）、制御システムの状態を一定周期で記録しておき（データロギング）、その後、制御状態の解析を行うようになっている。
【０００３】
ところで、近年、制御システムでは、例えば図１４に示すように、マスタ局として機能するプログラマブルコントローラ等の制御装置１０と、マスタ局としての制御装置１０に対してスレーブ局として機能する位置制御コントローラ等の制御機器２０と、モニタ・ロギング装置３０とがネットワーク４０に接続されて構成されている。
【０００４】
このシステムでは、ノード１に有する制御装置１０は、制御機器２０からＩ／Ｏデータを取得しており、この取得したＩ／Ｏデータに基づき、スレーブ局としての制御機器２０を制御するようになっている。
【０００５】
ノード５に有するモニタ・ロギング装置３０は、制御機器２０のＩ／Ｏデータを取得し、この制御データを用いて、制御の状態をリアルタイムに画面上に表示してモニタリングしたり、制御システムの状態を一定周期で記録しておき、後に、制御システムに何らかのトラブルが発生したとき、トラブル原因を解析するのに使用されている。
【０００６】
このような制御システムにおいては、データを送受信する方式として、コマンド・レスポンス方式が一般的に採用されている。
【０００７】
このコマンド・レスポンス方式は、図１５に示すように、制御装置１０が制御機器２０に対してＩ／Ｏデータを取得しようとするときには、制御用のコマンドフレームを制御機器２０に送信し、このコマンドフレームに対するレスポンスフレームを制御機器２０から受信した後、Ｉ／Ｏデータを取得するようになっている。
【０００８】
また、モニタ・ロギング装置３０が制御機器２０に対してモニタ・ロギング用の制御データを取得しようとするときには、モニタ・ロギング用のコマンドフレームを制御機器２０に送信し、このコマンドフレームに対するレスポンスフレームを制御機器２０から受信した後、モニタ・ロギング用の制御データを取得するようになっている。
【０００９】
なお、上述した制御システムは、データを送受信する方式として、コマンド・レスポンス方式が一般的に採用されていると述べたが、使用するネットワークのプロトコルによっては、あるノードが１つ以上のノードと通信できないような方式のものもある。
【００１０】
【発明が解決しようとする課題】
上述した従来の制御システムに使用されているモニタ・ロギング装置では、上述したようなコマンド・レスポンス方式が採用されているので、以下のような問題点があった。
【００１１】
（１）ネットワークトラフィックの増加
図１５に示すように、モニタ・ロギング装置がネットワーク４０上にモニタ・ロギング用のコマンドを送信し、このコマンドを受信したノードの制御機器２０がそれに対するレスポンスをネットワークに送信するので、この分ネットワーク４０上のトラフィックが増加し、制御システムの機能を低下させてしまうという問題点があった。
【００１２】
特に、制御装置１０がプログラマブルコントローラの場合には、プログラマブルコントローラが、所定のスキャンタイム内に各制御機器２０に対してＩ／Ｏデータを取得しなければシステムエラーとなるため、モニタ・ロギング装置３０からモニタ・ロギング用のコマンドおよびそれに対するレスポンスによるトラフィックの増加は、制御システムの機能を低下させる重大な要因となる。
【００１３】
（２）ノードに対する負荷の増加
従来のモニタ・ロギング装置では、各制御機器２０は、制御装置１０から送信された制御用のコマンドを受信し、このコマンドに対するレスポンスを制御装置１０に送信するとともに、モニタ・ロギング装置３０から受信したモニタリング用のコマンドを受信し、このコマンドに対するレスポンスをモニタ・ロギング装置３０に送信するので、処理の負荷が増加する。
【００１４】
このため、従来のシステムでは、各ノードに有する制御機器２０の処理内容が制限され、強いては、システム全体が制約されるという問題点があった。
【００１５】
（３）ネットワークリソース（ノードアドレス）の占有
一般に、ネットワーク上のあるノードに対してコマンドを送信する場合には、そのコマンドフレーム中に送信元を指定するノードアドレス（例えばＭＡＣ ＩＤ）を有する必要がある。
【００１６】
従って、従来の制御システムでは、モニタ・ロギング装置３０がネットワーク４０に有するノードアドレスの１つを占有してしまい、システム全体の構成を制限してしまうという問題点があった。
【００１７】
（４）ネットワークプロトコルによっては本方式の使用が困難
上述したように、使用するネットワークのプロトコルによって、あるノードが１つ以上のノードと通信できないような方式を有する制御システムでは、モニタ・ロギング装置３０を制御システムに付加することが不可能であるという問題点があった。
【００１８】
そこで、本発明は上述した問題点に鑑み、▲１▼ネットワークのトラフィックを増加させず、▲２▼各ノードに有する制御機器に対する負荷を抑え、▲３▼ノードアドレスを付加させず、▲４▼あるノードが１つ以上のノードと通信できないような方式を有するプロトコルを有する制御システムでも、モニタ・ロギングを行えるモニタ・ロギング装置を提供することを目的とする。
【００１９】
【課題を解決するための手段】
上述した目的を達成するために、本発明は、ネットワークに接続されたプログラマブルコントローラ側のマスタ局と制御機器側のスレーブ局との間で、１回の通信で相対的に高速なデータ通信が可能なビットストローブ通信方式と、１回に通信可能なデータ量が決まっていてそれ以上のデータ量を通信するには複数回にわたって通信することで相対的に大量なデータ通信が可能なポール通信方式とのいずれの方式においても通信されている通信フレームを取得でき、マスタ局とスレーブ局との間で通信されるＩ／Ｏデータをモニタ・ロギングするモニタ・ロギング装置であって、前記モニタ・ロギング装置は、前記ネットワーク上で通信されているマスタ局からスレーブ局への通信フレームおよびスレーブ局からマスタ局への通信フレームを、その通信がビットストローブ通信方式またはポール通信方式のいずれの場合であってもすべて受信する受信手段と、前記受信手段で受信した通信フレームを解読するフレーム解読手段と、前記フレーム解読手段で解読されたデータから形成したＩ／Ｏデータを記憶するＩ／Ｏデータバッファと、を備え、前記フレーム解読手段は、受信した通信フレームがビットストローブ通信方式によるものかポール通信方式によるものかを判断し、ビットストローブ通信方式によるものであると判断した場合には、通信フレームから解読して得たＩ／ＯデータをＩ／Ｏデータバッファに記憶し、ポール通信方式によるものであると判断した場合には、前記ネットワーク上でデータを分割して送信する際に使用されるフラグメントが前記受信した通信フレームに含まれているか否かを判断し、ここで、前記フラグメントを含まないと判断した場合には、通信フレームから解読して得たＩ／ＯデータをＩ／Ｏデータバッファに記憶し、いっぽう、前記フラグメントを含むと判断した場合には、分割送信に係る最初のデータであることを示すファーストフラグメントを含む通信フレームの受信から分割送信に係る最後のデータであることを示すラストフラグメントを含む通信フレームの受信までの間、その受信した各通信フレームから解読して得たＩ／Ｏデータをフラグメントバッファに積み上げていく形式で格納し、この格納した各Ｉ／ＯデータをＩ／Ｏデータバッファに記憶することを特徴とする。
【００２０】
また、（２）本発明は、ネットワークに接続された各ノード装置の間でビットストローブ通信方式またはポール通信方式のいずれかの方式により通信されている通信フレームを取得するモニタ・ロギング装置であって、前記モニタ・ロギング装置は、前記ネットワーク上で通信されている通信フレームをすべて受信する受信手段と、前記受信手段で受信した通信フレームを解読するフレーム解読手段と、前記フレーム解読手段で解読されたデータから形成したＩ／Ｏデータを記憶するＩ／Ｏデータバッファと、を備え、前記フレーム解読手段は、受信した通信フレームがビットストローブ通信方式によるものかポール通信方式によるものかを判断し、ビットストローブ通信方式によるものであると判断した場合には、通信フレームから解読して得たデータをＩ／Ｏデータバッファに記憶し、ポール通信方式によるものであると判断した場合には、データを分割して送信する際に使用されるフラグメントに基づいて、分割送信に係る最初のデータであることを示すファーストフラグメントを含む通信フレームの受信から分割送信に係る最後のデータであることを示すラストフラグメントを含む通信フレームの受信までの間、その受信した各通信フレームから解読して得たデータをフラグメントバッファに積み上げていく形式で格納し、この格納した各データをＩ／Ｏデータバッファに記憶することを特徴とする。
【００２１】
前記本発明において、前記フレーム解読手段は、ポール通信方式によるものであると判断した場合において、ファーストフラグメントが、ファーストフラグメントでありラストフラグメントである意味を示すものである場合は、分割送信であるがデータ量が１フレームで終了するものとして、通信フレームから解読して得たＩ／ＯデータをＩ／Ｏデータバッファに記憶するようにしてもよい。
【００２２】
前記本発明において、前記モニタ・ロギング装置は、ノード情報とフレーム情報とを有し、前記ノード情報は、ネットワークに接続された各ノード装置の間の通信方式がビットストローブ通信方式によるものかポール通信方式によるものかを示す情報と、各方式で通信されるＩ／Ｏデータのサイズを示す情報を含むものであり、前記フレーム情報は、ノード間で通信するメッセージのフォーマットなどのプロトコル情報を含むものであり、前記フレーム解読手段は、前記ノード情報と前記プロトコル情報とに基づいて、受信した通信フレームを解読するように構成してもよい。
【００２３】
前記（１）と（２）の本発明において、前記モニタ・ロギング装置は、ＣＡＮを利用したプロトコルであって、マスタ局とスレーブ局間でＩＮデータ、ＯＵＴデータを通信するものであるデバイスネットに接続され、前記受信手段で受信する通信フレームは、ビットストローブ通信方式によるものかポール通信方式によるものかを示す情報がセットされたヘッダと、ファーストフラグメントかラストフラグメントを示すデータおよびマスタ局とスレーブ局間で通信されるＩＮデータかＯＵＴデータであるＩ／Ｏデータがセットされたデータフィールドと、を含み、前記フレーム解読手段が通信フレームから解読して得たデータは、マスタ局とスレーブ局間で通信されるＩＮデータかＯＵＴデータであるＩ／Ｏデータであるものとしてよい。
【００２５】
本発明によれば、ネットワーク上で通信されているフレームを、自からネットワークにコマンドを送信することをせずに受信し、この受信した通信データを解読するようにしたことにより、ネットワークアドレスを不要とすることができる。
【００２６】
従って、モニタ・ロギング装置がネットワークアドレスを有していないため、ノードアドレスの占有を免れることができ、その分稼動させる制御機器を増やすことができる。
【００２７】
また、データを取得する際に、データを取得するためのコマンドを送信することなく、フレームを受信できるため、ネットワーク上のトラフィックを減少させるとともに無駄な処理を減少させ、制御システムの機能を高めることができ、更に使用するネットワークのプロトコルの制限に関らず、制御システムのモニタ・ロギングを行うことができる。
【００２８】
【発明の実施の形態】
以下、本発明に係るモニタ・ロギング装置の一実施形態を、図面を参照して詳細に説明する。
【００２９】
図１はモニタ・ロギング装置を有する制御システムの構成を示すブロック図である。
【００３０】
本発明に係る制御システムは、ノード１に有する制御装置１０と、ノード２，３，４に有する制御機器２０と、モニタ・ロギング装置３０とが、下位層（物理層、データリンク層）にＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）を利用しているネットワークプロトコルの１つであるデバイスネット（ＤｅｖｉｃｅＮｅｔ）２に接続されて構築されている。
【００３１】
ここで、制御システムを構築する各構成物の内容を説明する前に、デバイスネット２を介して送受信されるフレームについて、図２を参照して説明する。
【００３２】
デバイスネット２を介して送受信されるフレーム６は、ＣＡＮプロトコルで使用され、かつ、リモートＩ／Ｏシステムに対応したプリデファイン マスタ／スレーブ コネクション セット（Ｐｒｅｄｅｆｉｎｅｅｄ Ｍａｓｔｅｒ／Ｓｌａｖｅ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔ）で定義されているフレーム構成を有している。
【００３３】
このフレーム６は、図２（ａ）に示すように、１９ビット（Ｂｉｔ）からなるＣＡＮヘッダーフィールド（ＣＡＮ ＨＥＡＤＥＲ ＦＩＥＬＤ）６１と、最大６４ビット（８バイト）からなるデータフィールド（ＤＡＴＡ ＦＩＥＬＤ）６２と、２５ビットからなるＣＡＮトレイラーフィールド（ＣＡＮＮ ＴＲＡＩＬＥＲ ＦＩＥＬＤ）６３とから構成されている。
【００３４】
１）ＣＡＮヘッダフィールド６１について
ＣＡＮヘッダーフィールド６１は、図２（ｂ）に示すように、１ビットからなるスタートビット（Ｓｔａｒｔ Ｂｉｔ）と、１１ビットからなるＣＡＮアイデンティファイアー（ＣＡＮ Ｉｄｅｎｔｉｆｉｉｅｒ）ビット６１２と、１ビットからなるＲＴＲビット６１３と、６ビットからなるコントロールビット６１４とから構成されている。
【００３５】
スタートビット（Ｓｔａｒｔ Ｂｉｔ）６１１は、フレームの開始を示す情報を有しており、ＣＡＮアイデンティファイアー（ＣＡＮ Ｉｄｅｎｔｉｆｉｅｒ）ビット６１２は、マスタ／スレーブ コネクション セットの定義、すなわち送受信先がマスタであるかスレーブであるかを示すノード役割情報，ノードアドレスを示すノードアドレス情報，および使用する通信方式を示す通信方式情報を有している。
【００３６】
ノードアドレス情報は、デバイスネット２ではＭＡＣ ＩＤとよばれ、６ビットで表わされており、そのため、使用できる数値は１０進数として０から６３である。
【００３７】
なお、デバイスネット２上では、各ノードは、異なるＭＡＣ ＩＤが割り当てられている。
【００３８】
通信方式情報には、高速なデータ通信が可能なビットストローブ（Ｂｉｔ−Ｓｔｒｏｂｅ）方式と、大量なデータの送信が可能なポール（Ｐｏｌｌ）方式とがある。
【００３９】
ビットストローブ方式は、マスタ局としての制御装置１０から送信されたコマンドフレームがすべてのスレーブ局としての制御機器２０に受信される通信方式であり、コマンドフレームを受信した制御機器２０は、このフレームのデータフィールド６２のうち、自己のＭＡＣ ＩＤに対応した１ビットに有する情報を、自己に対する出力データとして認識するようになっている。
【００４０】
例えば図３に示すように、０ビットから順に６３ビットにセットされた情報は、ＭＡＣ ＩＤが“０”を有する制御機器２０から順にＭＡＣ ＩＤが“６３”を有する制御機器２０に対する出力情報を示している。
【００４１】
ＲＴＲビット６１３はエラーを検出する情報を有しており、コントロールビット６１４はコントロール情報を有している。
【００４２】
ここで、上述したビットストローブとポール方式との通信方式について、更に詳細に図４に基づいて説明する。
【００４３】
ａ）ビットストローブ方式について
図４（ａ）の▲１▼の欄に示すように、マスタ局としての制御装置１０がスレーブ局として制御機器２０に対して送信するフレームの場合には、９ビットに“０”と１０ビットに“１”がセットされ、また、３ビットから８ビットにかけてマスタ局としての制御装置１０のＭＡＣ ＩＤがセットされ、更に０ビットから２ビットに“０，０，０”がセットされる。
【００４４】
ここで、例えば、制御装置１０のＭＡＣ ＩＤを１０進法で“６３”とした場合には、３ビットから８ビットには、“１，１，１，１，１，１”がセットされる。
【００４５】
図４（ａ）の（２）（・参考：図４（ａ）では「（２）」はマル２と表示されている）の欄に示すように、スレーブ局としての制御機器２０がマスタ局としての制御装置１０に対して送信するフレームの場合には、９ビットに“１”と１０ビットに“０”がセットされ、６ビットから９ビットにかけて“１，１，１，０”がセットされ、更に、０ビットから５ビットにかけて制御機器２０のＭＡＣ ＩＤがセットされる。
【００４６】
例えば、制御機器２０のＭＡＣ ＩＤを１０進法で“０”とした場合には、０ビットから５ビットには、“０，０，０，０，０，０”がセットされる。
【００４７】
ｂ）ポール方式について
図４（ｂ）の▲１▼の欄に示すように、マスタ局としての制御装置１０がスレーブ局として制御機器２０に対して送信するフレームの場合には、９ビットに“０”と１０ビットに“１”がセットされ、また、３ビットから８ビットにかけて送信先の制御機器２０のＭＡＣ ＩＤがセットされ、更に０ビットから２ビットに“１，０，１”がセットされる。
【００４８】
例えば、フレームを送信する制御機器２０のＭＡＣ ＩＤを１０進法で“６２”とした場合には、３ビットから８ビットにかけて“１，１，１，１，１，０”がセットされる。
【００４９】
図４（ｂ）の▲２▼の欄に示すように、スレーブ局としての制御機器２０がマスタ局としての制御装置１０に対して送信するフレームの場合には、９ビットに“１”と１０ビットに“０”がセットされ、６ビットから９ビットにかけて“１，１，１，１”がセットされ、更に、０ビットから５ビットにかけて制御機器２０のＭＡＣ ＩＤがセットされる。
【００５０】
例えば、フレームを送信する制御機器２０のＭＡＣ ＩＤを１０進法で“１”とした場合には、３ビットから８ビットにかけて“０，０，０，０，０，１”がセットされる。
【００５１】
２）データフィールド６２について
ところで、デバイスネット２では、一回に送信可能なデータのデータ量が最大８バイト（Ｂｙｔｅ）である。このため、それ以上のデータ量を有するデータを送信する場合には、分割送信しなければならない。
【００５２】
図５は分割送信する場合のデータフィールドの内容を説明する図である。
【００５３】
図５に示すように、分割送信する場合におけるデータフィールド６２は、バイトナンバー（Ｂｙｔｅ Ｎｕｍｂｅｒ）が“０”で示された１バイトの０ビットから５ビットにかけて、何フレーム目のデータであるかを識別するフラグメントカウント（Ｆｒａｇｍｅｎｔ Ｃｏｕｎｔ）情報を有しており、また、６ビットと７ビットとに送信したデータの属性を示すフラグメントタイプ（Ｆｒａｇｍｅｎｔ Ｔｙｐｅ）情報を有している。
【００５４】
また、このデータフィールド６２は、バイトナンバーが“１”から“７”で示された２バイトから８バイトにわたってＩ／Ｏメッセージを有している。
【００５５】
上述したフラグメントタイプについて、図６を参照して更に詳細に説明する。
【００５６】
図６に示すように、フラグメントタイプは、その値が“０”の場合には、ファーストフラグメント（Ｆｉｒｓｔ Ｆｒａｇｍｅｎｔ）、すなわちフレーム中の最初のデータであることを示し、値が“２”の場合には、ラストフラグメント（Ｌａｓｔ Ｆｒａｇｍｅｎｔ）、すなわちフレーム中の最後のデータであることを示し、値が“１”の場合には、ミドルフラグメント（Ｍｉｄｄｌｅ Ｆｒａｇｍｅｎｔ）、すなわちファーストフラグメントに該当するデータとラストフラグメントに該当するデータの間にあるデータを示している。
【００５７】
上述したフラグメントカウンタは、６ビットで表現されるので、最大３Ｆ（ヘキサデシマル表示）までセットすることができる。フレーム数が３Ｆ以上の場合には、再度０からセットされる。
【００５８】
なお、ファーストフラグメントの場合には、そのフラグメントカウンタが０または３Ｆでなければならない。デバイスネット２のＩ／Ｏ通信では、マスタ、スレーブ間で分割送信を使用するかどうかは実際のＩ／Ｏデータの交換を開始する前に初期設定により決定される。
【００５９】
そのため、１度分割送信ありで通信を開始すると、データ量が１フレームで終了するものであっても、分割送信の手順に従うことになる。この場合、ファーストフラグメントでありラストフラグメントということになる。つまり、ファーストフラグメントにおけるフラグメントカウンタが３Ｆを有するものは、最初で最後のフラグメントという特殊な意味を示す。
【００６０】
図７はフラグメントでない場合のデータフィールド６２の内容を説明する図である。
【００６１】
この場合には、データフィールド６２は、図に示すように、１バイト目にフラグメントタイプおよびフラグメントカウントを有しない。
【００６２】
次に、モニタ・ロギング装置を構築する各構成物の構成について説明する。なお、モニタ・ロギング装置はＷｉｎｄｏｗｓソフトウェアとして実装したものである。
【００６３】
ノード１に有する制御装置１０は、例えばプログラマブルロジックコントローラ（ＰＬＣ），ソフトＰＬＣが実装されているＰＣ（パーソナル コンピュータ）等からなり、ノード２，３，４に有する制御機器２０からＩ／Ｏデータを取得しており、この取得したＩ／Ｏデータに基づき演算処理を行い、その演算処理結果に基づき、ノード２，３，４の制御機器２０に対して所定の動作を実行させるコマンドを出力するようになっている。
【００６４】
制御機器２０は、スイッチ，リレー，温度センサ，インバータ、アクチュエータ等からなり、制御装置１０の制御に基づき、Ｉ／Ｏデータを制御装置１０に送信するとともに所定の動作を実行するようになっている。
【００６５】
モニタ・ロギング装置３０は、自身がノードとしてのアドレスを有していないものであって、自らネットワークコマンドを送信することなしにデバイスネット２を介してフレーム６を受信し（図１の▲１▼参照）、受信したフレーム６をフレーム情報に基づきフレーム中のＣＡＮヘッダ６１およびデータ・フィールド６２の詳細情報を解読するようになっている(図１の▲２▼参照)。
【００６６】
すなわち、モニタ・ロギング装置３０は、デバイスネット２を介して制御装置１０と制御機器２０間に送受信されているフレーム６を受動的に受信することを特徴とするものである。
【００６７】
さらに言換えると、モニタ・ロギング装置は、自らネットワークコマンドを送信することなく、制御装置１０と制御機器２０間の外的作用でデバイスネット２に通信されているフレーム６を受信するようになっている。
【００６８】
また、モニタ・ロギング装置３０は、フレーム情報に基づきフレームの内容を解読した結果（図１の▲３▼参照）、モニタリングまたはロギングに必要なフレームである場合には、ノード情報に基づきこのフレームを取得するようになっている。
【００６９】
前記フレーム情報は、デバイスネットプロトコル情報を示す情報であって、その情報にはマスタ・スレーブ間でやり取りするメッセージのフォーマットや意味を全て含んでいる。
【００７０】
前記ノード情報は、データ収集する対象のノード（スレーブ）が、マスタとのポール、ストローブの各Ｉ／Ｏ通信方式において通信を行なうＩ／Ｏデータのサイズ（ＩＮＰＵＴ，ＯＵＴＰＵＴ）の情報を含んでいる。
【００７１】
図８はモニタ・ロギング装置の概略構成を示すブロック図である。
【００７２】
このモニタ・ロギング装置３０は、アプリケーション（Ａｐｐｌｃａｔｉｏｎ）部３１０と、フレームを解読するフレーム解読手段としてのフレーム解読部（Ｃｏｒｅ Ｍｏｄｕｌｅ ＤＬＬ部）３２０と、フレームを受信する受信手段としてのＤｅｖｉｃｅＮｅｔ Ｉ／Ｆ部３３０とから構成されている。
【００７３】
アプリケーション部３１０は、後述するノード情報をソフトウエア上に有している。
【００７４】
フレーム解読部３２０は、アプリケーション（Ａｐｐｌｃａｔｉｏｎ）部３１０より、ノード情報を読み込むようになっており、このノード情報は、フレーム解読部３２０に記憶される。
【００７５】
先に述べたノード情報について更に詳細に説明すると、ノード情報は、図９に示すように、通信方式がポール方式によるものであるか、またはビットストローブ方式によるものであるかを示す情報と、各方式で通信Ｉ／Ｏデータのデータサイズを示す情報を有している。
【００７６】
なお、図中のＯＵＴＳｉｚｅ１、ＩＮＳｉｚｅ１は、ポール通信方式を使用する場合のデータサイズを示しており、ＯＵＴＳｉｚｅ２、ＩＮＳｉｚｅ２は、ビットストローブ通信方式のデータサイズを示している。
【００７７】
また、アプリケーション（Ａｐｐｌｃａｔｉｏｎ）部３１０は、後述するフレーム解読部３２０で形成されたモニタ・ロギングデータを一定間隔ごと、Ｉ／Ｏデータエリアから取得し、これをハードディスク等の記憶手段（図示せず）に格納するようになっている。
【００７８】
フレーム解読部３２０は、アプリケーション部３１０から受けたノード情報と、ソフトウェアに記述されているフレーム情報とに基づき、受信したフレーム６を解読し、この解読したフレーム６からＩ／Ｏデータを形成するようになっている。
【００７９】
先に述べたフレーム情報について、図１０を参照して説明する。
【００８０】
ここで、グループ ＩＤ（Ｇｒｏｕｐ ＩＤ）は、デバイスネット２で使用できる１１ビットのＣＡＮ ＩＤをグループ（Ｇｒｏｕｐ）１，グループ（Ｇｒｏｕｐ）２，グループ（Ｇｒｏｕｐ）３，グループ（Ｇｒｏｕｐ）４という用途別にグループ分けしたときのグループを識別する値（１〜４）である。
【００８１】
メッセージ ＩＤ（Ｍｅｓｓａｇｅ ＩＤ）は、あるエンドポイントにおいてメッセージグループ内の各メッセージを識別する値である。
【００８２】
Ａの欄に示したポールコマンド（Ｐｏｌｌ Ｃｏｍｍａｎｄ）は、グループ ＩＤとして“２”を、また、メッセージ ＩＤとして“５”を有しており、このコマンドがＯＵＴデータであることを示している。
【００８３】
また、Ｂの欄に示したビットストローブコマンド（Ｂｉｔ−Ｓｔｒｏｂｅ Ｃｏｍｍａｎｄ）は、グループ ＩＤとして“２”を、また、メッセージ ＩＤとして“０”を有しており、このコマンドが１点のみのＯＵＴデータであることを示している。
【００８４】
ＤｅｖｉｃｅＮｅｔ Ｉ／Ｆ部３３０は、デバイスネット２上に送信されているすべてのフレームを受信するようになっている。
【００８５】
ここで、上述したフレーム解読部３２０を更に詳細に説明する。
【００８６】
図１１はフレーム解読部の構成を示すブロック図である。
【００８７】
フレーム解読部３２０は、受信フィルタ手段３２０ａと、有効フレーム受信検知手段３２０ｂと、フレーム解析手段３２０ｃと、フラグバッファ（Ｆｒａｇｍｅｎｔ Ｂｕｆｆｅｒ）３２０ｄと、Ｉ／Ｏデータバッファ３２０ｅと、フラグメントカウンタ３２０ｆと、フレーム情報を有するフレーム情報憶部３２０ｇと、ノード情報記憶部３２０ｈとから構成されている。
【００８８】
受信フィルタ手段３２０ａは、デバイスネット Ｉ／Ｆ３３０を介して受信したフレーム６のＣＡＮヘッダーフールド６１に有するＣＡＮアイデンティファイアー６１２を参照し、受信すべきフレームのみを選択するようになっている（フィルタをかける）。
【００８９】
受信フィルタ手段３２０ａが選択受信するフレーム６は、図１２に示すようなものである。
【００９０】
▲１▼ＯＵＴデータのみの場合、すなわち対象となるＭＡＣ ＩＤを有する制御機器２０に対して送信されたフレームが、ポールコマンドフレーム、または、すべてのビットストローブコマンドフレームのもの
▲２▼ＩＮデータのみの場合、すなわち対象となるＭＡＣ ＩＤを有する制御機器２０から制御装置１０に対して送信されたフレームが、ポールレスポンフレーム、または、ビットストローブレスポンスフレームのもの
▲３▼ＯＵＴおよびＩＮデータ両方のもの、すなわち前述の▲１▼および▲２▼のフレームのもの
【００９１】
有効フレーム受信検知手段３２０ｂは、受信フィルタ手段３２０ａからフレーム６を受けると、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有しているか否かを判断し、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有していると判断した場合には、その旨をフレーム解析手段３２０ｃに通知するようになっている。
【００９２】
フレーム解析手段３２０ｃは、フレーム情報記憶部３２０ｇに有するフレーム情報に基づき、受信したフレーム６を解読するようになっている。
【００９３】
なお、その詳細な内容は、後述するこの実施形態に係るモニタ・ロギング装置の動作において説明されているので、その詳細説明を省略する。
【００９４】
フラグメントバッファ（Ｆｒａｇｍｅｎｔ Ｂｕｆｆｅｒ）３２０ｄは、受信したフレームがポール通信方式のもので、かつ、フラグメントを使用している場合には、そのフレーム６のデータを一時記憶するものである。
【００９５】
Ｉ／Ｏデータバッファ３２０ｅは、形成したＩ／Ｏデータを記憶するものである。
【００９６】
フラグメントカウンタ３２０ｆは、ポール通信方式のものであって、かつ、フラグメントがあるフレーム６のデータを受信するごとに、フレーム解析手段３２０ｃの指示のもとカウンタ値に１を加算し、送信されてきたデータがラストフラグメントの場合には、フレーム解析手段３２０ｃの指示のもとカウント値をクリアするようになっている。なお、これらの処理は、各ＭＡＣ ＩＤ毎に行なわれる。
【００９７】
フレーム情報記憶部３２０ｇはフレーム情報を有するものであり、ノード情報記憶部３２０ｈは、アプリケーション部３１０から取得したノード情報を記憶するものである。
【００９８】
続いて、この実施形態のモニタ・ロギング装置の動作を、図１３のフローチャートを参照して説明する。
【００９９】
フレーム解読部３２０は、デバイスネット Ｉ／Ｆ３３０で受信したフレーム６を受けると、受信フィルタ手段３２０ａが予め決定されているデバイスＩ／Ｏタイプ（図１０を参照）のフレーム６のみを選択的に受信し（フィルタをかけ）、選択的に受信したフレーム６を有効フレーム受信手段３２０ｂに出力する（ステップ１１０）。
【０１００】
有効フレーム受信検知手段３２０ｂは、受信フィルタ手段３２０ａからフレーム６を受けると、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有しているか否かを判断する（ステップ１２０）。
【０１０１】
有効フレーム受信検知手段３２０ｂは、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有していると判断した場合には（ステップ１２０；Ｙ）、その旨をフレーム解析手段３２０ｃに通知する。
【０１０２】
一方、有効フレーム受信検知手段３２０ｃは、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有していないと判断した場合には（ステップ１２０；Ｎ）、ステップ１１０に移行して上述したと同様な処理を続行する。
【０１０３】
フレーム解析手段３２０ｃは、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有している旨の通知を有効フレーム受信検知手段３２０ｂから受けると、フレーム６中のＣＡＮヘッダ６１を参照し、受信したフレーム６がポール通信方式によるメッセージ（Ｐｏｌｌ Ｍｅｓｓａｇｅ）であるか否かを判断する（ステップ１３０）。
【０１０４】
フレーム解析手段３２０ｃは、ポール通信方式によるＩ／Ｏデータ（メッセージ）でないと判断した場合、すなわちビットストローブ通信方式によるＩ／Ｏデータである場合には（ステップ１３０；Ｎ）、Ｉ／Ｏデータバッファ３２０ｅにＩ／Ｏデータをリフレッシュする（ステップ１４０）、その後、ステップ１１０に移行して上述したと同様な処理を続行する。
【０１０５】
一方、フレーム解析手段３２０ｃは、ポール通信方式によるＩ／Ｏデータであると判断した場合には（ステップ１３０；Ｙ）、ノード情報に基づきフラグメントカウントを有しているか否かを判断する（ステップ１５０）。
【０１０６】
フレーム解析手段３２０ｃは、受信したフレーム６中のＩ／Ｏデータがノード情報に基づき、フラグメントタイプおよびフラグメントカウントを有していないと判断した場合には（ステップ１５０；Ｎ）、後述するステップ２１０に移行する一方、データフィールド６２にフラグメントタイプおよびフラグメントカウントを有していると判断した場合には（ステップ１５０；Ｙ）、内部状態がファーストフラグメント待ちの状態であるか否かを判断する（ステップ１６０）。
【０１０７】
フレーム解析手段３２０ｃは、内部状態がファーストフラグメント待ちの状態でないと判断した場合には（ステップ１６０；Ｎ）、後述するステップ１７０に移行する一方、内部状態がファーストフラグメント待ちの状態であると判断した場合には（ステップ１６０；Ｙ）、受信したフレーム６中のデータフィールド６２中のフラグメントタイプがファーストフラグメントであるか否かを判断する（ステップ１８０）。
【０１０８】
フレーム解析手段３２０ｃは、受信したフレーム６中のデータフィールド６２中のフラグメントタイプがファーストフラグメントでないと判断した場合には（ステップ１８０；Ｎ）、後述するステップ２２０に移行する一方、受信したフレーム６中のデータフィールド６２中のフラグメントタイプがファーストフラグメントであると判断した場合には（ステップ１８０；Ｙ）、フラグメントカウントが“０Ｘ３Ｆ”であるか否かを判断する（ステップ１９０）。
【０１０９】
フレーム解析手段３２０ｃは、フラグメントカウントが“０Ｘ３Ｆ”でないと判断した場合には（ステップ１９０；Ｎ）、後述するステップ２００に移行する。一方、フレーム解析手段３２０ｃは、フラグメントカウントが“０Ｘ３Ｆ”であると判断した場合には（ステップ１９０；Ｙ）、フレーム６を該当するＭＡＣ ＩＤの箇所のＩ／Ｏデータバッファ３２０ｅに記憶させる（ステップ２１０）。
【０１１０】
その後、フレーム解析手段３２０ｃは、内部で保持しているフラグメント情報（フラグメントカウンタ、ファーストフラグメント待ち状態）を初期化し、一定時間間隔でＩ／Ｏデータバッファ３２０ｅに書き込まれたモニタ・ロギングデータを読み出し、これをハードディスク等の記憶手段に記憶させたのち（ステップ２２０）、ステップ１１０に移行し上述したと同様な処理を行う。
【０１１１】
ステップ１６０において、フレーム解析手段３２０ｃは、内部状態がファーストフラグメント待ちの状態でないと判断した場合には（ステップ１６０；Ｎ）、受信したフレーム６のデータフィールド６２中に有するフラグメントカウントが一致しているか否かを判断する（ステップ１７０）。
【０１１２】
フレーム解析手段３２０ｃは、受信したフレーム６のデータフィールド６２中に有するフラグメントカウントが一致していないと判断した場合には（ステップ１７０；Ｎ）、ステップ２２０に移行する一方、受信したフレーム６のデータフィールド６２中に有するフラグメントカウントが一致していると判断した場合には（ステップ１７０；Ｙ）、Ｉ／Ｏデータをフラグメントバッファ３２０ｄに書き込む（ステップ２００）。
【０１１３】
次に、フレーム解析手段３２０ｃは、受信したフレーム６のデータフィールド６２中に有するフラグメントカウントがラストフラグメントであるか否かを判断する（ステップ２３０）。
【０１１４】
フレーム解析手段３２０ｃは、フレーム６のデータフィールド６２中に有するフラグメントカウントがラストフラグメントであると判断した場合には（ステップ２３０；Ｙ）、ステップ２１０に移行する一方、フレーム６のデータフィールド６２中に有するフラグメントカウントがラストフラグメントでないと判断した場合には（ステップ２３０；Ｎ）、フレーム解読部３２０に有するフラグメントカウンタに１を加算して、新たなカウント値とし（ステップ２４０）、ステップ１１０に移行し、上述したと同様な処理を続行する。
【０１１５】
この実施形態のモニタ・ロギング装置では、自らフレーム（コマンド）を送信する必要がないから、ネットワークアドレスを不要とすることができる。
【０１１６】
従って、モニタ・ロギング装置３０がネットワークアドレスを有していないため、ノードアドレスの占有を免れることができ、その分稼動させる制御機器２０、例えばスイッチ，リレー等を増やすことができる。
【０１１７】
また、Ｉ／Ｏデータを取得する際に、Ｉ／Ｏデータを取得するためのコマンドを送信することなく、フレームを受信できるため、ネットワーク上のトラフィックを減少させるとともに無駄な処理を減少させ、制御システムの機能を高めることができるとともに、１つのノードに対してしか通信できないプロトコルを採用するシステムでも、モニタ・ロギングすることができる。
【０１１８】
なお、フレーム解析の実行タイミングは、フレーム受信ごとの場合であってもよいし、また、いったん受信フレームを記憶させておき、周期的にまとめて解析する場合であってもよい。
【０１１９】
また、この実施形態のモニタ・ロギン装置は、モニタ表示画面を含むものでもよいし、含まないものでもよい。含まない場合には、別途モニタ表示画面を外付け接続すればよい。
【０１２０】
【発明の効果】
本発明は前記のように構成されているので、次のような効果を有する。
【０１２１】
（１）請求項１記載の発明によれば、ネットワーク上で通信されているフレームを、自からネットワークにコマンドを送信することをせずに受信し、この受信した通信データを解読するようにしたことにより、本発明に係るモニタ・ロギング装置においては、ネットワークアドレスを不要とすることができる。
【０１２２】
また、データを取得する際に、データを取得するためのコマンドを送信することなく、フレームを受信できるため、ネットワーク上のトラフィックを減少させるとともに、無駄な処理を減少させ、システムの機能を高めることができる。
【０１２３】
更に１つのノードに対してしか通信できないプロトコルを採用するシステムでも、モニタ・ロギングすることができる。
【０１２４】
（２）請求項２記載の発明によれば、更にフレーム解読手段で受信したフレームのうち、モニタ・ロギングするフレームを解読するため、モニタ・ロギング用のデータを取得することができる。
【０１２５】
（３）請求項３記載の発明によれば、更にまた、受信フィルタ手段により受信手段で受信したフレームのうち所定のフレームのみを選択するので、モニタ・ロギングに不要なフレームを廃棄することができる。
【０１２６】
（４）請求項４記載の発明は、ネットワーク接続時にノードとしてのアドレスを持つことなしに、ネットワーク上で通信されているフレームを受信し、通信データを解読するようになっているので、ノードアドレスの占有を免れることができる。
【０１２７】
（５）請求項５記載の発明は、データ取得部が受信フレームを解析して、ネットワークに接続されているノードを特定することと、特定したノードが通信したデータを取得することを行なうようにしたことにより、必要とするノードに対するデータを取得することができる。
【０１２８】
（６）請求項６記載の発明は、解読部がフレーム情報に基づき受信したフレームの意味を解読するので、モニタ・ロギング用のデータを取得することができる。
【図面の簡単な説明】
【図１】本発明に係るモニタ・ロギングシステムの一実施形態の構成を示すブロック図。
【図２】図１中のデバイスネットを介して送受信されるフレームの構成を示すブロック図。
【図３】ビットストローブ通信方式におけるコマンドフレームの構成を示すブロック図。
【図４】図２中のＣＡＮアイデンティファイアーの構成を示すブロック図。
【図５】図２中のデータフィールドの構成を示すブロック図（フラグメント時）。
【図６】図５中フラグメントタイプとフラグメントカウントとの内容を説明する図。
【図７】図２中のデータフィールドの構成を示すブロック図。
【図８】図１中のモニタ・ロギング装置の概略構成を示すブロック図。
【図９】デバイスＩ／Ｏ割付を示すブロック図。
【図１０】図９中の有効フレームチェック手段により選択されるフレームの内容を示す図。
【図１１】図８中のフレーム解読部の構成を示すブロック図。
【図１２】Ｉ／Ｏデータとデバイスネットメッセージとの対応を示す図。
【図１３】図１中のモニタ・ロギング装置の処理動作を示すフローチャート。
【図１４】従来のモニタ・ロギング装置がコマンドを送信して制御システム内のＩ／Ｏデータを取得する内容を説明する図。
【図１５】従来のモニタ・ロギングシステムの構成を示す図。
【符号の説明】
１ 制御システム
２ デバイスネット
１０ 制御装置
２０ 制御機器
３０ モニタ・ロギング装置
３１０ アプリケーション部
３２０ フレーム解読部
３２０ａ 受信フィルタ手段
３２０ｂ 有効フレーム受信検知手段
３２０ｃ フレーム解析手段
３２０ｄ フラグメントバッファ
３２０ｅ Ｉ／Ｏデータバッファ
３２０ｆ フラグメントカウンタ
３２０ｇ フレーム情報記憶部
３２０ｈ ノード情報記憶部
３３０ デバイスネット Ｉ／Ｆ
【発明の属する技術分野】
本発明は、スイッチ，センサ等の制御機器をモニタするモニタ・ロギング装置に関するものである。
【０００２】
【従来の技術】
従来、制御システムにおいて用いられているモニタ・ロギング装置では、制御の状態をリアルタイムに画面上に表示したり（モニタリング）、制御システムの状態を一定周期で記録しておき（データロギング）、その後、制御状態の解析を行うようになっている。
【０００３】
ところで、近年、制御システムでは、例えば図１４に示すように、マスタ局として機能するプログラマブルコントローラ等の制御装置１０と、マスタ局としての制御装置１０に対してスレーブ局として機能する位置制御コントローラ等の制御機器２０と、モニタ・ロギング装置３０とがネットワーク４０に接続されて構成されている。
【０００４】
このシステムでは、ノード１に有する制御装置１０は、制御機器２０からＩ／Ｏデータを取得しており、この取得したＩ／Ｏデータに基づき、スレーブ局としての制御機器２０を制御するようになっている。
【０００５】
ノード５に有するモニタ・ロギング装置３０は、制御機器２０のＩ／Ｏデータを取得し、この制御データを用いて、制御の状態をリアルタイムに画面上に表示してモニタリングしたり、制御システムの状態を一定周期で記録しておき、後に、制御システムに何らかのトラブルが発生したとき、トラブル原因を解析するのに使用されている。
【０００６】
このような制御システムにおいては、データを送受信する方式として、コマンド・レスポンス方式が一般的に採用されている。
【０００７】
このコマンド・レスポンス方式は、図１５に示すように、制御装置１０が制御機器２０に対してＩ／Ｏデータを取得しようとするときには、制御用のコマンドフレームを制御機器２０に送信し、このコマンドフレームに対するレスポンスフレームを制御機器２０から受信した後、Ｉ／Ｏデータを取得するようになっている。
【０００８】
また、モニタ・ロギング装置３０が制御機器２０に対してモニタ・ロギング用の制御データを取得しようとするときには、モニタ・ロギング用のコマンドフレームを制御機器２０に送信し、このコマンドフレームに対するレスポンスフレームを制御機器２０から受信した後、モニタ・ロギング用の制御データを取得するようになっている。
【０００９】
なお、上述した制御システムは、データを送受信する方式として、コマンド・レスポンス方式が一般的に採用されていると述べたが、使用するネットワークのプロトコルによっては、あるノードが１つ以上のノードと通信できないような方式のものもある。
【００１０】
【発明が解決しようとする課題】
上述した従来の制御システムに使用されているモニタ・ロギング装置では、上述したようなコマンド・レスポンス方式が採用されているので、以下のような問題点があった。
【００１１】
（１）ネットワークトラフィックの増加
図１５に示すように、モニタ・ロギング装置がネットワーク４０上にモニタ・ロギング用のコマンドを送信し、このコマンドを受信したノードの制御機器２０がそれに対するレスポンスをネットワークに送信するので、この分ネットワーク４０上のトラフィックが増加し、制御システムの機能を低下させてしまうという問題点があった。
【００１２】
特に、制御装置１０がプログラマブルコントローラの場合には、プログラマブルコントローラが、所定のスキャンタイム内に各制御機器２０に対してＩ／Ｏデータを取得しなければシステムエラーとなるため、モニタ・ロギング装置３０からモニタ・ロギング用のコマンドおよびそれに対するレスポンスによるトラフィックの増加は、制御システムの機能を低下させる重大な要因となる。
【００１３】
（２）ノードに対する負荷の増加
従来のモニタ・ロギング装置では、各制御機器２０は、制御装置１０から送信された制御用のコマンドを受信し、このコマンドに対するレスポンスを制御装置１０に送信するとともに、モニタ・ロギング装置３０から受信したモニタリング用のコマンドを受信し、このコマンドに対するレスポンスをモニタ・ロギング装置３０に送信するので、処理の負荷が増加する。
【００１４】
このため、従来のシステムでは、各ノードに有する制御機器２０の処理内容が制限され、強いては、システム全体が制約されるという問題点があった。
【００１５】
（３）ネットワークリソース（ノードアドレス）の占有
一般に、ネットワーク上のあるノードに対してコマンドを送信する場合には、そのコマンドフレーム中に送信元を指定するノードアドレス（例えばＭＡＣ ＩＤ）を有する必要がある。
【００１６】
従って、従来の制御システムでは、モニタ・ロギング装置３０がネットワーク４０に有するノードアドレスの１つを占有してしまい、システム全体の構成を制限してしまうという問題点があった。
【００１７】
（４）ネットワークプロトコルによっては本方式の使用が困難
上述したように、使用するネットワークのプロトコルによって、あるノードが１つ以上のノードと通信できないような方式を有する制御システムでは、モニタ・ロギング装置３０を制御システムに付加することが不可能であるという問題点があった。
【００１８】
そこで、本発明は上述した問題点に鑑み、▲１▼ネットワークのトラフィックを増加させず、▲２▼各ノードに有する制御機器に対する負荷を抑え、▲３▼ノードアドレスを付加させず、▲４▼あるノードが１つ以上のノードと通信できないような方式を有するプロトコルを有する制御システムでも、モニタ・ロギングを行えるモニタ・ロギング装置を提供することを目的とする。
【００１９】
【課題を解決するための手段】
上述した目的を達成するために、本発明は、ネットワークに接続されたプログラマブルコントローラ側のマスタ局と制御機器側のスレーブ局との間で、１回の通信で相対的に高速なデータ通信が可能なビットストローブ通信方式と、１回に通信可能なデータ量が決まっていてそれ以上のデータ量を通信するには複数回にわたって通信することで相対的に大量なデータ通信が可能なポール通信方式とのいずれの方式においても通信されている通信フレームを取得でき、マスタ局とスレーブ局との間で通信されるＩ／Ｏデータをモニタ・ロギングするモニタ・ロギング装置であって、前記モニタ・ロギング装置は、前記ネットワーク上で通信されているマスタ局からスレーブ局への通信フレームおよびスレーブ局からマスタ局への通信フレームを、その通信がビットストローブ通信方式またはポール通信方式のいずれの場合であってもすべて受信する受信手段と、前記受信手段で受信した通信フレームを解読するフレーム解読手段と、前記フレーム解読手段で解読されたデータから形成したＩ／Ｏデータを記憶するＩ／Ｏデータバッファと、を備え、前記フレーム解読手段は、受信した通信フレームがビットストローブ通信方式によるものかポール通信方式によるものかを判断し、ビットストローブ通信方式によるものであると判断した場合には、通信フレームから解読して得たＩ／ＯデータをＩ／Ｏデータバッファに記憶し、ポール通信方式によるものであると判断した場合には、前記ネットワーク上でデータを分割して送信する際に使用されるフラグメントが前記受信した通信フレームに含まれているか否かを判断し、ここで、前記フラグメントを含まないと判断した場合には、通信フレームから解読して得たＩ／ＯデータをＩ／Ｏデータバッファに記憶し、いっぽう、前記フラグメントを含むと判断した場合には、分割送信に係る最初のデータであることを示すファーストフラグメントを含む通信フレームの受信から分割送信に係る最後のデータであることを示すラストフラグメントを含む通信フレームの受信までの間、その受信した各通信フレームから解読して得たＩ／Ｏデータをフラグメントバッファに積み上げていく形式で格納し、この格納した各Ｉ／ＯデータをＩ／Ｏデータバッファに記憶することを特徴とする。
【００２０】
また、（２）本発明は、ネットワークに接続された各ノード装置の間でビットストローブ通信方式またはポール通信方式のいずれかの方式により通信されている通信フレームを取得するモニタ・ロギング装置であって、前記モニタ・ロギング装置は、前記ネットワーク上で通信されている通信フレームをすべて受信する受信手段と、前記受信手段で受信した通信フレームを解読するフレーム解読手段と、前記フレーム解読手段で解読されたデータから形成したＩ／Ｏデータを記憶するＩ／Ｏデータバッファと、を備え、前記フレーム解読手段は、受信した通信フレームがビットストローブ通信方式によるものかポール通信方式によるものかを判断し、ビットストローブ通信方式によるものであると判断した場合には、通信フレームから解読して得たデータをＩ／Ｏデータバッファに記憶し、ポール通信方式によるものであると判断した場合には、データを分割して送信する際に使用されるフラグメントに基づいて、分割送信に係る最初のデータであることを示すファーストフラグメントを含む通信フレームの受信から分割送信に係る最後のデータであることを示すラストフラグメントを含む通信フレームの受信までの間、その受信した各通信フレームから解読して得たデータをフラグメントバッファに積み上げていく形式で格納し、この格納した各データをＩ／Ｏデータバッファに記憶することを特徴とする。
【００２１】
前記本発明において、前記フレーム解読手段は、ポール通信方式によるものであると判断した場合において、ファーストフラグメントが、ファーストフラグメントでありラストフラグメントである意味を示すものである場合は、分割送信であるがデータ量が１フレームで終了するものとして、通信フレームから解読して得たＩ／ＯデータをＩ／Ｏデータバッファに記憶するようにしてもよい。
【００２２】
前記本発明において、前記モニタ・ロギング装置は、ノード情報とフレーム情報とを有し、前記ノード情報は、ネットワークに接続された各ノード装置の間の通信方式がビットストローブ通信方式によるものかポール通信方式によるものかを示す情報と、各方式で通信されるＩ／Ｏデータのサイズを示す情報を含むものであり、前記フレーム情報は、ノード間で通信するメッセージのフォーマットなどのプロトコル情報を含むものであり、前記フレーム解読手段は、前記ノード情報と前記プロトコル情報とに基づいて、受信した通信フレームを解読するように構成してもよい。
【００２３】
前記（１）と（２）の本発明において、前記モニタ・ロギング装置は、ＣＡＮを利用したプロトコルであって、マスタ局とスレーブ局間でＩＮデータ、ＯＵＴデータを通信するものであるデバイスネットに接続され、前記受信手段で受信する通信フレームは、ビットストローブ通信方式によるものかポール通信方式によるものかを示す情報がセットされたヘッダと、ファーストフラグメントかラストフラグメントを示すデータおよびマスタ局とスレーブ局間で通信されるＩＮデータかＯＵＴデータであるＩ／Ｏデータがセットされたデータフィールドと、を含み、前記フレーム解読手段が通信フレームから解読して得たデータは、マスタ局とスレーブ局間で通信されるＩＮデータかＯＵＴデータであるＩ／Ｏデータであるものとしてよい。
【００２５】
本発明によれば、ネットワーク上で通信されているフレームを、自からネットワークにコマンドを送信することをせずに受信し、この受信した通信データを解読するようにしたことにより、ネットワークアドレスを不要とすることができる。
【００２６】
従って、モニタ・ロギング装置がネットワークアドレスを有していないため、ノードアドレスの占有を免れることができ、その分稼動させる制御機器を増やすことができる。
【００２７】
また、データを取得する際に、データを取得するためのコマンドを送信することなく、フレームを受信できるため、ネットワーク上のトラフィックを減少させるとともに無駄な処理を減少させ、制御システムの機能を高めることができ、更に使用するネットワークのプロトコルの制限に関らず、制御システムのモニタ・ロギングを行うことができる。
【００２８】
【発明の実施の形態】
以下、本発明に係るモニタ・ロギング装置の一実施形態を、図面を参照して詳細に説明する。
【００２９】
図１はモニタ・ロギング装置を有する制御システムの構成を示すブロック図である。
【００３０】
本発明に係る制御システムは、ノード１に有する制御装置１０と、ノード２，３，４に有する制御機器２０と、モニタ・ロギング装置３０とが、下位層（物理層、データリンク層）にＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）を利用しているネットワークプロトコルの１つであるデバイスネット（ＤｅｖｉｃｅＮｅｔ）２に接続されて構築されている。
【００３１】
ここで、制御システムを構築する各構成物の内容を説明する前に、デバイスネット２を介して送受信されるフレームについて、図２を参照して説明する。
【００３２】
デバイスネット２を介して送受信されるフレーム６は、ＣＡＮプロトコルで使用され、かつ、リモートＩ／Ｏシステムに対応したプリデファイン マスタ／スレーブ コネクション セット（Ｐｒｅｄｅｆｉｎｅｅｄ Ｍａｓｔｅｒ／Ｓｌａｖｅ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔ）で定義されているフレーム構成を有している。
【００３３】
このフレーム６は、図２（ａ）に示すように、１９ビット（Ｂｉｔ）からなるＣＡＮヘッダーフィールド（ＣＡＮ ＨＥＡＤＥＲ ＦＩＥＬＤ）６１と、最大６４ビット（８バイト）からなるデータフィールド（ＤＡＴＡ ＦＩＥＬＤ）６２と、２５ビットからなるＣＡＮトレイラーフィールド（ＣＡＮＮ ＴＲＡＩＬＥＲ ＦＩＥＬＤ）６３とから構成されている。
【００３４】
１）ＣＡＮヘッダフィールド６１について
ＣＡＮヘッダーフィールド６１は、図２（ｂ）に示すように、１ビットからなるスタートビット（Ｓｔａｒｔ Ｂｉｔ）と、１１ビットからなるＣＡＮアイデンティファイアー（ＣＡＮ Ｉｄｅｎｔｉｆｉｉｅｒ）ビット６１２と、１ビットからなるＲＴＲビット６１３と、６ビットからなるコントロールビット６１４とから構成されている。
【００３５】
スタートビット（Ｓｔａｒｔ Ｂｉｔ）６１１は、フレームの開始を示す情報を有しており、ＣＡＮアイデンティファイアー（ＣＡＮ Ｉｄｅｎｔｉｆｉｅｒ）ビット６１２は、マスタ／スレーブ コネクション セットの定義、すなわち送受信先がマスタであるかスレーブであるかを示すノード役割情報，ノードアドレスを示すノードアドレス情報，および使用する通信方式を示す通信方式情報を有している。
【００３６】
ノードアドレス情報は、デバイスネット２ではＭＡＣ ＩＤとよばれ、６ビットで表わされており、そのため、使用できる数値は１０進数として０から６３である。
【００３７】
なお、デバイスネット２上では、各ノードは、異なるＭＡＣ ＩＤが割り当てられている。
【００３８】
通信方式情報には、高速なデータ通信が可能なビットストローブ（Ｂｉｔ−Ｓｔｒｏｂｅ）方式と、大量なデータの送信が可能なポール（Ｐｏｌｌ）方式とがある。
【００３９】
ビットストローブ方式は、マスタ局としての制御装置１０から送信されたコマンドフレームがすべてのスレーブ局としての制御機器２０に受信される通信方式であり、コマンドフレームを受信した制御機器２０は、このフレームのデータフィールド６２のうち、自己のＭＡＣ ＩＤに対応した１ビットに有する情報を、自己に対する出力データとして認識するようになっている。
【００４０】
例えば図３に示すように、０ビットから順に６３ビットにセットされた情報は、ＭＡＣ ＩＤが“０”を有する制御機器２０から順にＭＡＣ ＩＤが“６３”を有する制御機器２０に対する出力情報を示している。
【００４１】
ＲＴＲビット６１３はエラーを検出する情報を有しており、コントロールビット６１４はコントロール情報を有している。
【００４２】
ここで、上述したビットストローブとポール方式との通信方式について、更に詳細に図４に基づいて説明する。
【００４３】
ａ）ビットストローブ方式について
図４（ａ）の▲１▼の欄に示すように、マスタ局としての制御装置１０がスレーブ局として制御機器２０に対して送信するフレームの場合には、９ビットに“０”と１０ビットに“１”がセットされ、また、３ビットから８ビットにかけてマスタ局としての制御装置１０のＭＡＣ ＩＤがセットされ、更に０ビットから２ビットに“０，０，０”がセットされる。
【００４４】
ここで、例えば、制御装置１０のＭＡＣ ＩＤを１０進法で“６３”とした場合には、３ビットから８ビットには、“１，１，１，１，１，１”がセットされる。
【００４５】
図４（ａ）の（２）（・参考：図４（ａ）では「（２）」はマル２と表示されている）の欄に示すように、スレーブ局としての制御機器２０がマスタ局としての制御装置１０に対して送信するフレームの場合には、９ビットに“１”と１０ビットに“０”がセットされ、６ビットから９ビットにかけて“１，１，１，０”がセットされ、更に、０ビットから５ビットにかけて制御機器２０のＭＡＣ ＩＤがセットされる。
【００４６】
例えば、制御機器２０のＭＡＣ ＩＤを１０進法で“０”とした場合には、０ビットから５ビットには、“０，０，０，０，０，０”がセットされる。
【００４７】
ｂ）ポール方式について
図４（ｂ）の▲１▼の欄に示すように、マスタ局としての制御装置１０がスレーブ局として制御機器２０に対して送信するフレームの場合には、９ビットに“０”と１０ビットに“１”がセットされ、また、３ビットから８ビットにかけて送信先の制御機器２０のＭＡＣ ＩＤがセットされ、更に０ビットから２ビットに“１，０，１”がセットされる。
【００４８】
例えば、フレームを送信する制御機器２０のＭＡＣ ＩＤを１０進法で“６２”とした場合には、３ビットから８ビットにかけて“１，１，１，１，１，０”がセットされる。
【００４９】
図４（ｂ）の▲２▼の欄に示すように、スレーブ局としての制御機器２０がマスタ局としての制御装置１０に対して送信するフレームの場合には、９ビットに“１”と１０ビットに“０”がセットされ、６ビットから９ビットにかけて“１，１，１，１”がセットされ、更に、０ビットから５ビットにかけて制御機器２０のＭＡＣ ＩＤがセットされる。
【００５０】
例えば、フレームを送信する制御機器２０のＭＡＣ ＩＤを１０進法で“１”とした場合には、３ビットから８ビットにかけて“０，０，０，０，０，１”がセットされる。
【００５１】
２）データフィールド６２について
ところで、デバイスネット２では、一回に送信可能なデータのデータ量が最大８バイト（Ｂｙｔｅ）である。このため、それ以上のデータ量を有するデータを送信する場合には、分割送信しなければならない。
【００５２】
図５は分割送信する場合のデータフィールドの内容を説明する図である。
【００５３】
図５に示すように、分割送信する場合におけるデータフィールド６２は、バイトナンバー（Ｂｙｔｅ Ｎｕｍｂｅｒ）が“０”で示された１バイトの０ビットから５ビットにかけて、何フレーム目のデータであるかを識別するフラグメントカウント（Ｆｒａｇｍｅｎｔ Ｃｏｕｎｔ）情報を有しており、また、６ビットと７ビットとに送信したデータの属性を示すフラグメントタイプ（Ｆｒａｇｍｅｎｔ Ｔｙｐｅ）情報を有している。
【００５４】
また、このデータフィールド６２は、バイトナンバーが“１”から“７”で示された２バイトから８バイトにわたってＩ／Ｏメッセージを有している。
【００５５】
上述したフラグメントタイプについて、図６を参照して更に詳細に説明する。
【００５６】
図６に示すように、フラグメントタイプは、その値が“０”の場合には、ファーストフラグメント（Ｆｉｒｓｔ Ｆｒａｇｍｅｎｔ）、すなわちフレーム中の最初のデータであることを示し、値が“２”の場合には、ラストフラグメント（Ｌａｓｔ Ｆｒａｇｍｅｎｔ）、すなわちフレーム中の最後のデータであることを示し、値が“１”の場合には、ミドルフラグメント（Ｍｉｄｄｌｅ Ｆｒａｇｍｅｎｔ）、すなわちファーストフラグメントに該当するデータとラストフラグメントに該当するデータの間にあるデータを示している。
【００５７】
上述したフラグメントカウンタは、６ビットで表現されるので、最大３Ｆ（ヘキサデシマル表示）までセットすることができる。フレーム数が３Ｆ以上の場合には、再度０からセットされる。
【００５８】
なお、ファーストフラグメントの場合には、そのフラグメントカウンタが０または３Ｆでなければならない。デバイスネット２のＩ／Ｏ通信では、マスタ、スレーブ間で分割送信を使用するかどうかは実際のＩ／Ｏデータの交換を開始する前に初期設定により決定される。
【００５９】
そのため、１度分割送信ありで通信を開始すると、データ量が１フレームで終了するものであっても、分割送信の手順に従うことになる。この場合、ファーストフラグメントでありラストフラグメントということになる。つまり、ファーストフラグメントにおけるフラグメントカウンタが３Ｆを有するものは、最初で最後のフラグメントという特殊な意味を示す。
【００６０】
図７はフラグメントでない場合のデータフィールド６２の内容を説明する図である。
【００６１】
この場合には、データフィールド６２は、図に示すように、１バイト目にフラグメントタイプおよびフラグメントカウントを有しない。
【００６２】
次に、モニタ・ロギング装置を構築する各構成物の構成について説明する。なお、モニタ・ロギング装置はＷｉｎｄｏｗｓソフトウェアとして実装したものである。
【００６３】
ノード１に有する制御装置１０は、例えばプログラマブルロジックコントローラ（ＰＬＣ），ソフトＰＬＣが実装されているＰＣ（パーソナル コンピュータ）等からなり、ノード２，３，４に有する制御機器２０からＩ／Ｏデータを取得しており、この取得したＩ／Ｏデータに基づき演算処理を行い、その演算処理結果に基づき、ノード２，３，４の制御機器２０に対して所定の動作を実行させるコマンドを出力するようになっている。
【００６４】
制御機器２０は、スイッチ，リレー，温度センサ，インバータ、アクチュエータ等からなり、制御装置１０の制御に基づき、Ｉ／Ｏデータを制御装置１０に送信するとともに所定の動作を実行するようになっている。
【００６５】
モニタ・ロギング装置３０は、自身がノードとしてのアドレスを有していないものであって、自らネットワークコマンドを送信することなしにデバイスネット２を介してフレーム６を受信し（図１の▲１▼参照）、受信したフレーム６をフレーム情報に基づきフレーム中のＣＡＮヘッダ６１およびデータ・フィールド６２の詳細情報を解読するようになっている(図１の▲２▼参照)。
【００６６】
すなわち、モニタ・ロギング装置３０は、デバイスネット２を介して制御装置１０と制御機器２０間に送受信されているフレーム６を受動的に受信することを特徴とするものである。
【００６７】
さらに言換えると、モニタ・ロギング装置は、自らネットワークコマンドを送信することなく、制御装置１０と制御機器２０間の外的作用でデバイスネット２に通信されているフレーム６を受信するようになっている。
【００６８】
また、モニタ・ロギング装置３０は、フレーム情報に基づきフレームの内容を解読した結果（図１の▲３▼参照）、モニタリングまたはロギングに必要なフレームである場合には、ノード情報に基づきこのフレームを取得するようになっている。
【００６９】
前記フレーム情報は、デバイスネットプロトコル情報を示す情報であって、その情報にはマスタ・スレーブ間でやり取りするメッセージのフォーマットや意味を全て含んでいる。
【００７０】
前記ノード情報は、データ収集する対象のノード（スレーブ）が、マスタとのポール、ストローブの各Ｉ／Ｏ通信方式において通信を行なうＩ／Ｏデータのサイズ（ＩＮＰＵＴ，ＯＵＴＰＵＴ）の情報を含んでいる。
【００７１】
図８はモニタ・ロギング装置の概略構成を示すブロック図である。
【００７２】
このモニタ・ロギング装置３０は、アプリケーション（Ａｐｐｌｃａｔｉｏｎ）部３１０と、フレームを解読するフレーム解読手段としてのフレーム解読部（Ｃｏｒｅ Ｍｏｄｕｌｅ ＤＬＬ部）３２０と、フレームを受信する受信手段としてのＤｅｖｉｃｅＮｅｔ Ｉ／Ｆ部３３０とから構成されている。
【００７３】
アプリケーション部３１０は、後述するノード情報をソフトウエア上に有している。
【００７４】
フレーム解読部３２０は、アプリケーション（Ａｐｐｌｃａｔｉｏｎ）部３１０より、ノード情報を読み込むようになっており、このノード情報は、フレーム解読部３２０に記憶される。
【００７５】
先に述べたノード情報について更に詳細に説明すると、ノード情報は、図９に示すように、通信方式がポール方式によるものであるか、またはビットストローブ方式によるものであるかを示す情報と、各方式で通信Ｉ／Ｏデータのデータサイズを示す情報を有している。
【００７６】
なお、図中のＯＵＴＳｉｚｅ１、ＩＮＳｉｚｅ１は、ポール通信方式を使用する場合のデータサイズを示しており、ＯＵＴＳｉｚｅ２、ＩＮＳｉｚｅ２は、ビットストローブ通信方式のデータサイズを示している。
【００７７】
また、アプリケーション（Ａｐｐｌｃａｔｉｏｎ）部３１０は、後述するフレーム解読部３２０で形成されたモニタ・ロギングデータを一定間隔ごと、Ｉ／Ｏデータエリアから取得し、これをハードディスク等の記憶手段（図示せず）に格納するようになっている。
【００７８】
フレーム解読部３２０は、アプリケーション部３１０から受けたノード情報と、ソフトウェアに記述されているフレーム情報とに基づき、受信したフレーム６を解読し、この解読したフレーム６からＩ／Ｏデータを形成するようになっている。
【００７９】
先に述べたフレーム情報について、図１０を参照して説明する。
【００８０】
ここで、グループ ＩＤ（Ｇｒｏｕｐ ＩＤ）は、デバイスネット２で使用できる１１ビットのＣＡＮ ＩＤをグループ（Ｇｒｏｕｐ）１，グループ（Ｇｒｏｕｐ）２，グループ（Ｇｒｏｕｐ）３，グループ（Ｇｒｏｕｐ）４という用途別にグループ分けしたときのグループを識別する値（１〜４）である。
【００８１】
メッセージ ＩＤ（Ｍｅｓｓａｇｅ ＩＤ）は、あるエンドポイントにおいてメッセージグループ内の各メッセージを識別する値である。
【００８２】
Ａの欄に示したポールコマンド（Ｐｏｌｌ Ｃｏｍｍａｎｄ）は、グループ ＩＤとして“２”を、また、メッセージ ＩＤとして“５”を有しており、このコマンドがＯＵＴデータであることを示している。
【００８３】
また、Ｂの欄に示したビットストローブコマンド（Ｂｉｔ−Ｓｔｒｏｂｅ Ｃｏｍｍａｎｄ）は、グループ ＩＤとして“２”を、また、メッセージ ＩＤとして“０”を有しており、このコマンドが１点のみのＯＵＴデータであることを示している。
【００８４】
ＤｅｖｉｃｅＮｅｔ Ｉ／Ｆ部３３０は、デバイスネット２上に送信されているすべてのフレームを受信するようになっている。
【００８５】
ここで、上述したフレーム解読部３２０を更に詳細に説明する。
【００８６】
図１１はフレーム解読部の構成を示すブロック図である。
【００８７】
フレーム解読部３２０は、受信フィルタ手段３２０ａと、有効フレーム受信検知手段３２０ｂと、フレーム解析手段３２０ｃと、フラグバッファ（Ｆｒａｇｍｅｎｔ Ｂｕｆｆｅｒ）３２０ｄと、Ｉ／Ｏデータバッファ３２０ｅと、フラグメントカウンタ３２０ｆと、フレーム情報を有するフレーム情報憶部３２０ｇと、ノード情報記憶部３２０ｈとから構成されている。
【００８８】
受信フィルタ手段３２０ａは、デバイスネット Ｉ／Ｆ３３０を介して受信したフレーム６のＣＡＮヘッダーフールド６１に有するＣＡＮアイデンティファイアー６１２を参照し、受信すべきフレームのみを選択するようになっている（フィルタをかける）。
【００８９】
受信フィルタ手段３２０ａが選択受信するフレーム６は、図１２に示すようなものである。
【００９０】
▲１▼ＯＵＴデータのみの場合、すなわち対象となるＭＡＣ ＩＤを有する制御機器２０に対して送信されたフレームが、ポールコマンドフレーム、または、すべてのビットストローブコマンドフレームのもの
▲２▼ＩＮデータのみの場合、すなわち対象となるＭＡＣ ＩＤを有する制御機器２０から制御装置１０に対して送信されたフレームが、ポールレスポンフレーム、または、ビットストローブレスポンスフレームのもの
▲３▼ＯＵＴおよびＩＮデータ両方のもの、すなわち前述の▲１▼および▲２▼のフレームのもの
【００９１】
有効フレーム受信検知手段３２０ｂは、受信フィルタ手段３２０ａからフレーム６を受けると、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有しているか否かを判断し、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有していると判断した場合には、その旨をフレーム解析手段３２０ｃに通知するようになっている。
【００９２】
フレーム解析手段３２０ｃは、フレーム情報記憶部３２０ｇに有するフレーム情報に基づき、受信したフレーム６を解読するようになっている。
【００９３】
なお、その詳細な内容は、後述するこの実施形態に係るモニタ・ロギング装置の動作において説明されているので、その詳細説明を省略する。
【００９４】
フラグメントバッファ（Ｆｒａｇｍｅｎｔ Ｂｕｆｆｅｒ）３２０ｄは、受信したフレームがポール通信方式のもので、かつ、フラグメントを使用している場合には、そのフレーム６のデータを一時記憶するものである。
【００９５】
Ｉ／Ｏデータバッファ３２０ｅは、形成したＩ／Ｏデータを記憶するものである。
【００９６】
フラグメントカウンタ３２０ｆは、ポール通信方式のものであって、かつ、フラグメントがあるフレーム６のデータを受信するごとに、フレーム解析手段３２０ｃの指示のもとカウンタ値に１を加算し、送信されてきたデータがラストフラグメントの場合には、フレーム解析手段３２０ｃの指示のもとカウント値をクリアするようになっている。なお、これらの処理は、各ＭＡＣ ＩＤ毎に行なわれる。
【００９７】
フレーム情報記憶部３２０ｇはフレーム情報を有するものであり、ノード情報記憶部３２０ｈは、アプリケーション部３１０から取得したノード情報を記憶するものである。
【００９８】
続いて、この実施形態のモニタ・ロギング装置の動作を、図１３のフローチャートを参照して説明する。
【００９９】
フレーム解読部３２０は、デバイスネット Ｉ／Ｆ３３０で受信したフレーム６を受けると、受信フィルタ手段３２０ａが予め決定されているデバイスＩ／Ｏタイプ（図１０を参照）のフレーム６のみを選択的に受信し（フィルタをかけ）、選択的に受信したフレーム６を有効フレーム受信手段３２０ｂに出力する（ステップ１１０）。
【０１００】
有効フレーム受信検知手段３２０ｂは、受信フィルタ手段３２０ａからフレーム６を受けると、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有しているか否かを判断する（ステップ１２０）。
【０１０１】
有効フレーム受信検知手段３２０ｂは、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有していると判断した場合には（ステップ１２０；Ｙ）、その旨をフレーム解析手段３２０ｃに通知する。
【０１０２】
一方、有効フレーム受信検知手段３２０ｃは、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有していないと判断した場合には（ステップ１２０；Ｎ）、ステップ１１０に移行して上述したと同様な処理を続行する。
【０１０３】
フレーム解析手段３２０ｃは、受けたフレーム６中のデータフィールド６２の長さが所定の長さを有している旨の通知を有効フレーム受信検知手段３２０ｂから受けると、フレーム６中のＣＡＮヘッダ６１を参照し、受信したフレーム６がポール通信方式によるメッセージ（Ｐｏｌｌ Ｍｅｓｓａｇｅ）であるか否かを判断する（ステップ１３０）。
【０１０４】
フレーム解析手段３２０ｃは、ポール通信方式によるＩ／Ｏデータ（メッセージ）でないと判断した場合、すなわちビットストローブ通信方式によるＩ／Ｏデータである場合には（ステップ１３０；Ｎ）、Ｉ／Ｏデータバッファ３２０ｅにＩ／Ｏデータをリフレッシュする（ステップ１４０）、その後、ステップ１１０に移行して上述したと同様な処理を続行する。
【０１０５】
一方、フレーム解析手段３２０ｃは、ポール通信方式によるＩ／Ｏデータであると判断した場合には（ステップ１３０；Ｙ）、ノード情報に基づきフラグメントカウントを有しているか否かを判断する（ステップ１５０）。
【０１０６】
フレーム解析手段３２０ｃは、受信したフレーム６中のＩ／Ｏデータがノード情報に基づき、フラグメントタイプおよびフラグメントカウントを有していないと判断した場合には（ステップ１５０；Ｎ）、後述するステップ２１０に移行する一方、データフィールド６２にフラグメントタイプおよびフラグメントカウントを有していると判断した場合には（ステップ１５０；Ｙ）、内部状態がファーストフラグメント待ちの状態であるか否かを判断する（ステップ１６０）。
【０１０７】
フレーム解析手段３２０ｃは、内部状態がファーストフラグメント待ちの状態でないと判断した場合には（ステップ１６０；Ｎ）、後述するステップ１７０に移行する一方、内部状態がファーストフラグメント待ちの状態であると判断した場合には（ステップ１６０；Ｙ）、受信したフレーム６中のデータフィールド６２中のフラグメントタイプがファーストフラグメントであるか否かを判断する（ステップ１８０）。
【０１０８】
フレーム解析手段３２０ｃは、受信したフレーム６中のデータフィールド６２中のフラグメントタイプがファーストフラグメントでないと判断した場合には（ステップ１８０；Ｎ）、後述するステップ２２０に移行する一方、受信したフレーム６中のデータフィールド６２中のフラグメントタイプがファーストフラグメントであると判断した場合には（ステップ１８０；Ｙ）、フラグメントカウントが“０Ｘ３Ｆ”であるか否かを判断する（ステップ１９０）。
【０１０９】
フレーム解析手段３２０ｃは、フラグメントカウントが“０Ｘ３Ｆ”でないと判断した場合には（ステップ１９０；Ｎ）、後述するステップ２００に移行する。一方、フレーム解析手段３２０ｃは、フラグメントカウントが“０Ｘ３Ｆ”であると判断した場合には（ステップ１９０；Ｙ）、フレーム６を該当するＭＡＣ ＩＤの箇所のＩ／Ｏデータバッファ３２０ｅに記憶させる（ステップ２１０）。
【０１１０】
その後、フレーム解析手段３２０ｃは、内部で保持しているフラグメント情報（フラグメントカウンタ、ファーストフラグメント待ち状態）を初期化し、一定時間間隔でＩ／Ｏデータバッファ３２０ｅに書き込まれたモニタ・ロギングデータを読み出し、これをハードディスク等の記憶手段に記憶させたのち（ステップ２２０）、ステップ１１０に移行し上述したと同様な処理を行う。
【０１１１】
ステップ１６０において、フレーム解析手段３２０ｃは、内部状態がファーストフラグメント待ちの状態でないと判断した場合には（ステップ１６０；Ｎ）、受信したフレーム６のデータフィールド６２中に有するフラグメントカウントが一致しているか否かを判断する（ステップ１７０）。
【０１１２】
フレーム解析手段３２０ｃは、受信したフレーム６のデータフィールド６２中に有するフラグメントカウントが一致していないと判断した場合には（ステップ１７０；Ｎ）、ステップ２２０に移行する一方、受信したフレーム６のデータフィールド６２中に有するフラグメントカウントが一致していると判断した場合には（ステップ１７０；Ｙ）、Ｉ／Ｏデータをフラグメントバッファ３２０ｄに書き込む（ステップ２００）。
【０１１３】
次に、フレーム解析手段３２０ｃは、受信したフレーム６のデータフィールド６２中に有するフラグメントカウントがラストフラグメントであるか否かを判断する（ステップ２３０）。
【０１１４】
フレーム解析手段３２０ｃは、フレーム６のデータフィールド６２中に有するフラグメントカウントがラストフラグメントであると判断した場合には（ステップ２３０；Ｙ）、ステップ２１０に移行する一方、フレーム６のデータフィールド６２中に有するフラグメントカウントがラストフラグメントでないと判断した場合には（ステップ２３０；Ｎ）、フレーム解読部３２０に有するフラグメントカウンタに１を加算して、新たなカウント値とし（ステップ２４０）、ステップ１１０に移行し、上述したと同様な処理を続行する。
【０１１５】
この実施形態のモニタ・ロギング装置では、自らフレーム（コマンド）を送信する必要がないから、ネットワークアドレスを不要とすることができる。
【０１１６】
従って、モニタ・ロギング装置３０がネットワークアドレスを有していないため、ノードアドレスの占有を免れることができ、その分稼動させる制御機器２０、例えばスイッチ，リレー等を増やすことができる。
【０１１７】
また、Ｉ／Ｏデータを取得する際に、Ｉ／Ｏデータを取得するためのコマンドを送信することなく、フレームを受信できるため、ネットワーク上のトラフィックを減少させるとともに無駄な処理を減少させ、制御システムの機能を高めることができるとともに、１つのノードに対してしか通信できないプロトコルを採用するシステムでも、モニタ・ロギングすることができる。
【０１１８】
なお、フレーム解析の実行タイミングは、フレーム受信ごとの場合であってもよいし、また、いったん受信フレームを記憶させておき、周期的にまとめて解析する場合であってもよい。
【０１１９】
また、この実施形態のモニタ・ロギン装置は、モニタ表示画面を含むものでもよいし、含まないものでもよい。含まない場合には、別途モニタ表示画面を外付け接続すればよい。
【０１２０】
【発明の効果】
本発明は前記のように構成されているので、次のような効果を有する。
【０１２１】
（１）請求項１記載の発明によれば、ネットワーク上で通信されているフレームを、自からネットワークにコマンドを送信することをせずに受信し、この受信した通信データを解読するようにしたことにより、本発明に係るモニタ・ロギング装置においては、ネットワークアドレスを不要とすることができる。
【０１２２】
また、データを取得する際に、データを取得するためのコマンドを送信することなく、フレームを受信できるため、ネットワーク上のトラフィックを減少させるとともに、無駄な処理を減少させ、システムの機能を高めることができる。
【０１２３】
更に１つのノードに対してしか通信できないプロトコルを採用するシステムでも、モニタ・ロギングすることができる。
【０１２４】
（２）請求項２記載の発明によれば、更にフレーム解読手段で受信したフレームのうち、モニタ・ロギングするフレームを解読するため、モニタ・ロギング用のデータを取得することができる。
【０１２５】
（３）請求項３記載の発明によれば、更にまた、受信フィルタ手段により受信手段で受信したフレームのうち所定のフレームのみを選択するので、モニタ・ロギングに不要なフレームを廃棄することができる。
【０１２６】
（４）請求項４記載の発明は、ネットワーク接続時にノードとしてのアドレスを持つことなしに、ネットワーク上で通信されているフレームを受信し、通信データを解読するようになっているので、ノードアドレスの占有を免れることができる。
【０１２７】
（５）請求項５記載の発明は、データ取得部が受信フレームを解析して、ネットワークに接続されているノードを特定することと、特定したノードが通信したデータを取得することを行なうようにしたことにより、必要とするノードに対するデータを取得することができる。
【０１２８】
（６）請求項６記載の発明は、解読部がフレーム情報に基づき受信したフレームの意味を解読するので、モニタ・ロギング用のデータを取得することができる。
【図面の簡単な説明】
【図１】本発明に係るモニタ・ロギングシステムの一実施形態の構成を示すブロック図。
【図２】図１中のデバイスネットを介して送受信されるフレームの構成を示すブロック図。
【図３】ビットストローブ通信方式におけるコマンドフレームの構成を示すブロック図。
【図４】図２中のＣＡＮアイデンティファイアーの構成を示すブロック図。
【図５】図２中のデータフィールドの構成を示すブロック図（フラグメント時）。
【図６】図５中フラグメントタイプとフラグメントカウントとの内容を説明する図。
【図７】図２中のデータフィールドの構成を示すブロック図。
【図８】図１中のモニタ・ロギング装置の概略構成を示すブロック図。
【図９】デバイスＩ／Ｏ割付を示すブロック図。
【図１０】図９中の有効フレームチェック手段により選択されるフレームの内容を示す図。
【図１１】図８中のフレーム解読部の構成を示すブロック図。
【図１２】Ｉ／Ｏデータとデバイスネットメッセージとの対応を示す図。
【図１３】図１中のモニタ・ロギング装置の処理動作を示すフローチャート。
【図１４】従来のモニタ・ロギング装置がコマンドを送信して制御システム内のＩ／Ｏデータを取得する内容を説明する図。
【図１５】従来のモニタ・ロギングシステムの構成を示す図。
【符号の説明】
１ 制御システム
２ デバイスネット
１０ 制御装置
２０ 制御機器
３０ モニタ・ロギング装置
３１０ アプリケーション部
３２０ フレーム解読部
３２０ａ 受信フィルタ手段
３２０ｂ 有効フレーム受信検知手段
３２０ｃ フレーム解析手段
３２０ｄ フラグメントバッファ
３２０ｅ Ｉ／Ｏデータバッファ
３２０ｆ フラグメントカウンタ
３２０ｇ フレーム情報記憶部
３２０ｈ ノード情報記憶部
３３０ デバイスネット Ｉ／Ｆ
Claims (4)
- ネットワークに接続されたプログラマブルコントローラ側のマスタ局と制御機器側のスレーブ局との間で、１回の通信で相対的に高速なデータ通信が可能なビットストローブ通信方式と、１回に通信可能なデータ量が決まっていてそれ以上のデータ量を通信するには複数回にわたって通信することで相対的に大量なデータ通信が可能なポール通信方式とのいずれの方式においても通信されている通信フレームを取得でき、マスタ局とスレーブ局との間で通信されるＩ／Ｏデータをモニタ・ロギングするモニタ・ロギング装置であって、
前記モニタ・ロギング装置は、
前記ネットワーク上で通信されているマスタ局からスレーブ局への通信フレームおよびスレーブ局からマスタ局への通信フレームを、その通信がビットストローブ通信方式またはポール通信方式のいずれの場合であってもすべて受信する受信手段と、
前記受信手段で受信した通信フレームを解読するフレーム解読手段と、
前記フレーム解読手段で解読されたデータから形成したＩ／Ｏデータを記憶するＩ／Ｏデータバッファと、を備え、
前記フレーム解読手段は、
受信した通信フレームがビットストローブ通信方式によるものかポール通信方式によるものかを判断し、
ビットストローブ通信方式によるものであると判断した場合には、通信フレームから解読して得たＩ／ＯデータをＩ／Ｏデータバッファに記憶し、
ポール通信方式によるものであると判断した場合には、前記ネットワーク上でデータを分割して送信する際に使用されるフラグメントが前記受信した通信フレームに含まれているか否かを判断し、
ここで、前記フラグメントを含まないと判断した場合には、通信フレームから解読して得たＩ／ＯデータをＩ／Ｏデータバッファに記憶し、いっぽう、前記フラグメントを含むと判断した場合には、分割送信に係る最初のデータであることを示すファーストフラグメントを含む通信フレームの受信から分割送信に係る最後のデータであることを示すラストフラグメントを含む通信フレームの受信までの間、その受信した各通信フレームから解読して得たＩ／Ｏデータをフラグメントバッファに積み上げていく形式で格納し、この格納した各Ｉ／ＯデータをＩ／Ｏデータバッファに記憶すること
を特徴とするモニタ・ロギング装置。 - 前記フレーム解読手段は、ポール通信方式によるものであると判断した場合において、ファーストフラグメントが、ファーストフラグメントでありラストフラグメントである意味を示すものである場合は、分割送信であるがデータ量が１フレームで終了するものとして、通信フレームから解読して得たＩ／ＯデータをＩ／Ｏデータバッファに記憶する
ことを特徴とする請求項１に記載のモニタ・ロギング装置。 - 前記モニタ・ロギング装置は、ノード情報とフレーム情報とを有し、
前記ノード情報は、ネットワークに接続された各ノード装置の間の通信方式がビットストローブ通信方式によるものかポール通信方式によるものかを示す情報と、各方式で通信されるＩ／Ｏデータのサイズを示す情報を含むものであり、
前記フレーム情報は、ノード間で通信するメッセージのフォーマットなどのプロトコル情報を含むものであり、
前記フレーム解読手段は、前記ノード情報と前記プロトコル情報とに基づいて、受信した通信フレームを解読する
ことを特徴とする請求項１に記載のモニタ・ロギング装置。 - 前記モニタ・ロギング装置は、ＣＡＮを利用したプロトコルであって、マスタ局とスレーブ局間でＩＮデータ、ＯＵＴデータを通信するものであるデバイスネットに接続され、
前記受信手段で受信する通信フレームは、ビットストローブ通信方式によるものかポール通信方式によるものかを示す情報がセットされたヘッダと、ファーストフラグメントかラストフラグメントを示すデータおよびマスタ局とスレーブ局間で通信されるＩＮデータかＯＵＴデータであるＩ／Ｏデータがセットされたデータフィールドと、を含み、
前記フレーム解読手段が通信フレームから解読して得たデータは、マスタ局とスレーブ局間で通信されるＩＮデータかＯＵＴデータであるＩ／Ｏデータである
ことを特徴とする請求項１に記載のモニタ・ロギング装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP01717899A JP3682838B2 (ja) | 1999-01-26 | 1999-01-26 | モニタ・ロギング装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP01717899A JP3682838B2 (ja) | 1999-01-26 | 1999-01-26 | モニタ・ロギング装置 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004260018A Division JP3712072B2 (ja) | 2004-09-07 | 2004-09-07 | モニタ・ロギング装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000216798A JP2000216798A (ja) | 2000-08-04 |
| JP3682838B2 true JP3682838B2 (ja) | 2005-08-17 |
Family
ID=11936708
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP01717899A Expired - Lifetime JP3682838B2 (ja) | 1999-01-26 | 1999-01-26 | モニタ・ロギング装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3682838B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006252486A (ja) * | 2005-03-14 | 2006-09-21 | Omron Corp | プログラマブル・コントローラ・システム |
| EP2228698B1 (en) * | 2005-03-14 | 2012-06-27 | Omron Corporation | Programmable controller system |
| WO2013121572A1 (ja) * | 2012-02-17 | 2013-08-22 | 株式会社日立製作所 | 分散システムにおける異種システムデータ提供方法 |
| JP6408277B2 (ja) * | 2014-07-25 | 2018-10-17 | 株式会社ベルチャイルド | データ収集装置及び産業用ネットワークシステム |
-
1999
- 1999-01-26 JP JP01717899A patent/JP3682838B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000216798A (ja) | 2000-08-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6810017B1 (en) | Graphical user interface system and method for organized network analysis | |
| JP3028783B2 (ja) | ネットワークの監視方法と装置 | |
| US6665275B1 (en) | Network device including automatic detection of duplex mismatch | |
| US20040010627A1 (en) | Ethernet interface device for reporting status via common industrial protocols | |
| JPH0761071B2 (ja) | モデム・ネツトワ−ク | |
| US6741566B1 (en) | Remote management ethernet network and device | |
| CN110300040A (zh) | 一种通信方法及相关设备 | |
| JP3682838B2 (ja) | モニタ・ロギング装置 | |
| CN112460747B (zh) | 分体式空调的通讯控制方法、装置、存储介质及下位机 | |
| US8396947B2 (en) | Active monitoring system for serial monitoring device and method thereof | |
| JP3712072B2 (ja) | モニタ・ロギング装置 | |
| JP2000261515A (ja) | ネットワークに接続可能な機器 | |
| JP2002064482A (ja) | 暗号処理装置 | |
| JPH07321783A (ja) | ネットワーク監視装置 | |
| JPH07297884A (ja) | 通信管理方法 | |
| JP3604008B2 (ja) | Ｌａｎ制御装置、ドライバ、スイッチングハブ、及びそれらを有するｌａｎ制御装置自動切り替えシステム | |
| US9743037B2 (en) | Method for transmitting device indicator data in network-based AV system | |
| JP2503861B2 (ja) | 監視制御方式 | |
| US9473597B2 (en) | Implementing multiple MAC protocols using a single wireless communication unit | |
| JPH10262073A (ja) | リング型ネットワークのノード並び順チェック方式 | |
| US20030093549A1 (en) | Data transfer device including communication circuit for controlling communication party | |
| JP2507540B2 (ja) | Ｌａｐｄ処理方法 | |
| KR20040095741A (ko) | 전문 처리 장치, 기기 제어 장치, 가전 기기, 전문 처리장치용 프로그램, 마이크로컴퓨터 시스템, 마이크로컴퓨터시스템용 프로그램 및 프로그램 제품 | |
| JPH06350615A (ja) | サイクリック伝送システム | |
| JPH08204777A (ja) | 無線装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040709 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040907 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041006 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041117 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20041215 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050214 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20050325 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050506 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050519 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080603 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090603 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090603 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100603 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100603 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110603 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110603 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120603 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130603 Year of fee payment: 8 |
|
| EXPY | Cancellation because of completion of term |