JP2011035664A - コントローラ - Google Patents

Abstract

【課題】 イーサキャット（登録商標）のＦＡシステムにおいて、異常解析を簡単・確実に行えるようにすること
【解決手段】 コントローラ１０は、モニタシステムプログラムで動作するプロトコルモニタ機能を備え、リモート装置２３と通信するデータを常時モニタリングする。コントローラは、異常を検知する異常診断機能を備えるので、そこで異常が検出された際に、その直前にモニタしていたデータを保持する。プロトコルモニタ機能が組み込まれることで、異常発生後に新たにプロトコルモニタを外部装置としてネットワークに加入させる必要が無く、システムの稼働当初からモニタすることで、最初に発生した異常から、その原因となるデータを保持し、解析に利用できる。
【選択図】 図５

Description

本発明は、コントローラに関するもので、より具体的には、ＦＡシステムを構成するコントローラと、リモート装置等の装置・機器との間で送受するデータをモニタする技術に関する。

ＦＡ（Factory Automation）におけるネットワークシステムは、生産工場内に配備された産業ロボットその他の生産設備の入力機器及び出力機器の制御を司る１または複数のＰＬＣ（Programmable Logic Controller）と、そのＰＬＣにより動作が制御される機器とが、制御系のネットワークに接続される。それらＰＬＣと機器は、その制御系のネットワークを介してサイクリックに通信を行なうことで、ＩＮデータ及びＯＵＴデータ（以下Ｉ／Ｏデータという）の送受を行ない、生産設備を制御する。

図１は、係るネットワークシステムの一部を示している。この例では、通信プロトコルとして、イーサネット（登録商標）を用いているため、ＰＬＣ，モーションコントローラ等のコントローラ１と、リモート装置２とは、スイッチングハブ３を介してＩ／Ｏデータの送受を行う。コントローラ１は、制御を司るＣＰＵ１ａと、ＣＰＵ１ａが動作するためのプログラムを格納したメモリ１ｂと、ネットワークに接続するための接続インタフェース１ｃと、を備えている。メモリ１ｂに格納されるプログラムは、基本動作を行うためのシステムプログラムと、実際に制御を行うためのユーザ制御プログラム（ユーザプログラムと称されることもある）がある。また、メモリ１ｂには、プログラム以外にも、ＣＰＵ１ａが演算実行する際に使用するワークエリアが確保されたり、ＩＯデータ等を格納するメモリエリアが確保されたりしている。これらのメモリは、用途に応じて不揮発性メモリや揮発性メモリが用いられる。接続インタフェース１ｃは、図示するように、通信プロトコルに対応する通信ケーブル５の端子を装着するコネクタとなるＲＪ４５や、ＰＴ：パルストランス、ＰＨＹ：フィジカル・レイヤー、Ｍａｃ：メディア・アクセス・コントローラ等を備える。

リモート装置２は、ＲＪ４５等のネットワークへの接続コネクタ２ａを備える。その接続コネクタ２ａに、スイッチングハブ３に接続された通信ケーブル５の端子を装着することで、ネットワークに加入する。図１では、図示の便宜上、複数のリモート装置２は、スイッチングハブ３の一箇所に接続されたように描画しているが、スイッチングハブ３が備える複数のポートにそれぞれ接続される。リモート装置２は、それ単体で動作するものもあれば、モータ等の外部機器４をさらに接続するものもある。

ＦＡネットワークシステムで障害が発生した場合、ＩＯデータを検証してその原因等を解析することがある。この場合に、ネットワークにプロトコルモニタ６を接続し、ネットワーク上を伝送されるＩＯデータをプロトコルモニタ６にて取得するとともに、そのプロトコルモニタ６が、取得したＩＯデータに基づいて解析を行う。

このプロトコルモニタ６は、ＣＰＵ６ａと、メモリ６ｂと、ネットワークとの接続インタフェース６ｃを備えている。接続インタフェース６ｃは、コントローラ１のものと同様の構成をとることができる。メモリ６ｂには、プロトコルモニタ６を動作させるための基本機能となるシステムプログラムや、モニタ機能の制御条件や、取得したモニタデータを格納するバッファエリアなどを備えている。制御条件は、ユーザやネットワーク専門技術者により設定される。

モニタデータバッファは、バッファ容量まで受信したら自動停止したり、リングバッファとして古いデータから順に廃棄して制御条件までエンドレスに動作を継続したりすることができる。そして、モニタデータバッファのモニタデータは一般的には、ファイルとして保存される。

図２は、上記のネットワークシステムにおいて、コントローラ１と、リモート装置２の一例であるサーボドライバとの間で送受するＩＯデータをモニタする例を示している。図示するように、コントローラ１と、リモート装置（サーボドライバ）２と、プロトコルモニタ６は、スイッチングハブ３の所定のポートＰ１，Ｐ２，Ｐ３に接続される。コントローラ１と、リモート装置２との間で送受するデータをプロトコルモニタ６が取得するためには、スイッチングハブ３のあるポートをミラーポートという設定にした上で、そのポートにプロトコルモニタ６を接続する。ここでは、ポートＰ３が、係るミラーポートに設定したポートである。

このようにミラーポートに設定すると、あるポート（図中ではリモート装置（サーボドライバ）が接続されているポートＰ２）で送受信される通信フレームデータのすべてが、ミラーポート（ポートＰ３）に転送される。これにより、ミラーポートにプロトコルモニタ６を接続することで、ＩＯデータを含む全ての通信フレームデータをプロトコルモニタでキャプチャできる。

図３は、プロトコルモニタ６におけるドライバ部の送受信バッファ構造と、データの送受信・転送の相関を示す図である。一般的なイーサネット（登録商標）ドライバのソフトウェア構造として、全二重通信（受信処理と送信処理の同時実行）を実現するために受信用のバッファと送信用のバッファを確保する。それぞれのバッファは、複数のバッファ（図では０〜７の８個）配列と、格納最終ポインタと次回格納ポインタにより、一般的にリングバッファの構造を形成する。

受信動作を例にとって、リングバッファの機能を説明する。イーサネットコントローラは、スイッチングハブ３からミラーリングされて転送されてきた受信データをイーサネットドライバ部に渡す（受信要求）。イーサネットドライバ部は、イーサネットコントローラからの受信要求により、受信データを受信次回格納ポインタが設定された受信バッファ（図では“受信バッファ６”）に格納する。その後、受信次回格納ポインタは＋１され、次回の受信に備える。このポインタはデータ配列の末端まで到達すると受信バッファ０に戻される。

一方、上位モジュール（図ではＴＣＰ／ＩＰやフレームモニタ）は、受信格納最終ポインタで示される受信バッファ（図では“受信バッファ２”）に格納されている受信データを、任意のタイミングで読み出すとともに、その読み出した受信データがメモリ６ｃ内のモニタデータバッファに格納される。その後、受信格納最終ポインタは＋１され、次回の読み出しに備える。このポインタはデータ配列の末端まで到達すると受信バッファ０に戻される。このように、データ配列とポインタによる処理により、データ配列をリング構造に見せかけることで連続した受信処理を行う。これらの説明は、送信処理おいても同じである。

これにより、モニタデータバッファには、コントローラ１とリモート装置２との間で送受されるデータが蓄積されるので、プロトコルモニタ６に格納された解析機能を稼働させ、係るモニタデータバッファに格納されたデータを解析する。係るプロトコルモニタを用いた管理システムは、例えば特許文献１に開示されている。

特開２０００−２２４１８４号公報

従来のプロトコルモニタを用いた管理では、ＰＬＣやモーションコントローラ等のコントローラ以外に、プロトコルモニタ機能を具備した外部装置であるプロトコルモニタ６を準備し、そのプロトコルモニタ６をミラーポート機能付きのスイッチングハブ３のミラーポートに接続してネットワークに加入させる必要がある。

このプロトコルモニタ機能を使用するケースは、コントローラや、ネットワーク構成にトラブルが発生した場合に必要となるので、通常では、トラブルが発生してからこれらプロトコルモニタなどを準備し、ネットワークに加入させることになる。しかし、解析を行うためには、そのようにプロトコルモニタ６をネットワークに加入させた後で、上記のトラブルが再現しなくてはならないため、再現性が乏しいケースなど原因追求には相当の時間と労力を必要とする。

また、FAネットワークシステムに既設のスイッチングハブが、ミラーポート機能に対応していないものの場合、新たに係る機能を備えたスイッチングハブを用意し、交換する必要があり、費用が増すばかりでなく、係る交換作業も繁雑となる。

さらに、外部装置として用いたプロトコルモニタ６は、ネットワーク回線上に流れるデータをトレースし、メモリ６ｂに設定された制御条件と比較し、モニタ機能の制御（モニタの開始、停止）を行う。係る制御を正しく行うためには、登録する制御条件（特定のデータパターン等）を正しく行う必要があり、プロトコルモニタに精通した技術者にしか設定できない。さらには、プロトコルモニタで検出できるシステム上の異常は、通信フレーム上のデータパターンだけであり、その他の制御タイミングの不正や、複数のデータに依存した高度なアルゴリズムを必要とするものは検出できないという課題がある。

上記の課題を解決するために、本発明のコントローラは、（１）ＦＡ用のコントローラであって、接続されるネットワークの異常の有無を判断する異常診断機能と、前記ネットワークに接続される機器との間で通信するデータをモニタリングするプロトコルモニタ機能と、前記異常診断機能で異常が検出された際に、その前に前記プロトコルモニタ機能にてモニタリングした前記データを保持する機能を備えた。

コントローラは、ＰＬＣやモーションコントローラがある。これらのコントローラには、自己やネットワークに接続された機器やネットワークの異常（障害）を検出する機能を備えている。異常診断機能は、係る異常を検出する機能により実現することができる。異常診断機能は、コントローラ自体がその異常を検出するので、検出可能なものは各種のものに対応できる。つまり、従来の外部装置として用意されるプロトコルモニタは、取得したデータのパターンから異常を検出するため、検出可能な異常は限定されると共に、検出するにもタイムラグが生じる。これに対し、本発明では、検出可能な異常が多岐にわたると共に、瞬時に検出できる。よって、異常検出が遅れたタイムラグによりデータが消失するおそれが可及的に抑制できる。さらに、コントローラは、プロトコルモニタ機能を内蔵しておりこの機能を使用する場合に、外部装置や接続ケーブルさらにはミラーポート機能などを具備したスイッチングハブなどを準備する必要がない。また、常時モニタ動作を開始しておくと、モニタを行うためのトラブル再現実験を行う必要がない。よって、最初に発生した異常・障害に基づいて、迅速な対応ができる。本発明のプロトコルモニタ機能は、データを収集・保持する機能があればよく、そのデータに基づいて解析する機能まではなくて良い。もちろん解析する機能を備えるのは妨げない。モニタリング対象となる機器との間で通信するデータは、送信データと受信データのいずれも取り得るが、少なくとも、機器から受信した受信データとするのがよい。

（２） リングバッファを備え、前記機器と通信するデータは、そのリングバッファに一旦格納する通信方式を採り、前記リングバッファは、前記通信を行うに必要なバッファ量よりも大きいバッファ量が設定され、正常時はバッファ量の大きいリングバッファの設定で前記機器と通信を行い、そのリングバッファに保持されている前記データをモニタデータとして利用し、前記異常診断機能で異常を検出した場合には、前記リングバッファのうち、その異常を検出した後のデータが格納される一部の小さい領域を用いて通信を継続し、その通信を継続するために使用する領域以外に格納されたデータを保持するようにすると良い。

バッファ量の大きいリングバッファを用いたとしても、正常時の通信は、リングバッファを何ら問題なく使用して通信できる。バッファ量が大きいため、リングバッファには比較的多くの過去のデータが格納されているので、係る過去のデータをも似たデータとして使用することができる。よって、従来のように、特別にモニタデータバッファを用意し、そこに転送する処理を行う必要もなくなる。そして、異常が発生した場合には、その発生時よりも前に発生したデータは、保持されるので、その後にその保持されたデータに基づいて解析を行うことができる。また、小さい領域がリングバッファとして機能するので、異常発生後も通信を継続することができる。

（３）コントローラは、イーサネット（登録商標）或いはイーサキャット（登録商標）に対応するものとすることができる。本発明では、外部装置としてプロトコルモニタを用いないので、スイッチングハブは、必須の構成でなくなる。そのため、イーサキャット（登録商標）にも好ましく適用できる。すなわち、イーサキャット（登録商標）は、高速通信に対応するものであり、イーサネット（登録商標）のようにスイッチングハブを実装すると、希望する通信速度が得られず、イーサキャット（登録商標）のメリットが半減する。本発明を用いることで、イーサキャット（登録商標）のＦＡシステムにおいて、高速通信を維持することができる。

（４）前記の（２）の発明を前提とし、前記リングバッファは、イーサネットドライバ部内に設定されるものとすることができる。バッファ量を大きく設定したリングバッファを従来のモニタデータバッファとして利用できるので、モニタデータバッファへの転送・キャプチャ処理が不要となる。リングバッファを用いた通信処理は、必要以上のバッファ量が確保されれば、その大小に関係無く行える。よって、モニタデータバッファへの転送処理が不要となる分、さらに高速に対応することができ、イーサキャット（登録商標）により適したものとなる。もちろん、イーサキャット（登録商標）に対応できるので、イーサネット（登録商標）に対応する通信プロトコルのネットワークシステムにも適用できる。

本発明は、プロトコルモニタ機能がコントローラ内に組み込まれるので、コントローラで異常（障害）を検出したならば、瞬時にそれ以前にモニタして取得していたデータ（モニタデータ）を保持することができる。また、検出可能な異常（障害）も多岐にわたることができ、各種の異常の原因の解析のためのモニタリングを行うことができる。

バッファ量の大きいリングバッファを用いて通信をするようにした場合には、過去のデータがリングバッファに格納された状態が一般のリングバッファを用いた通信方式を採る装置に比べて長く続くため、係るリングバッファをモニタデータの格納領域として利用できる。その結果、従来のように、モニタデータバッファ等に別途転送してコピーする処理が不要となり、構成が簡略化すると共に、処理が簡便となって高速対応が可能となる。さらに、異常が発生した場合には、通信に使用するリングバッファの領域を狭くすることで、過去のデータが通信に伴う上書きにより消失することもなく、保持される。よって、その後に係る保持されたデータを解析装置等で解析し、異常原因等を特定するのに利用できる。

従来例を示す図である。 従来例を示す図である。 従来例を示す図である。 本発明に係るコントローラが組み込まれるＦＡネットワークシステムの一例を示す図である。 本発明に係るコントローラが組み込まれるＦＡネットワークシステムの他の例を示す図である。 異常検知機能を説明する図である。 正常時のリングバッファを用いた通信方式を説明する図である。 異常発生時のリングバッファを用いた通信方式を説明する図である。 作用を説明するフローチャートである。

図４は、本発明に係るプログラマブルコントローラやモーションコントローラ等のＦＡ用のコントローラ１０を含むＦＡネットワークシステムの一例を示している。本実施形態では、通信プロトコルとして、イーサネット（登録商標）を用いている。そのため、コントローラ１０は、スイッチングハブ２１を介してリモート装置（スレーブ）２３とＩＮデータ／ＯＵＴデータ等のＩＯデータの送受を行う。リモート装置２３は、サーボモータ２４ａの動作を制御するサーボドライバや、通常のモータ２４ｂの動作を制御するインバータや、Ｉ／Ｏターミナルやバルブなどがある。リモート装置２３は、ＲＪ４５等の当該プロトコル対応の通信ケーブル２２の端子を装着するコネクタ２３ａを備えており、その通信ケーブル２２経由でスイッチングハブ２１の所定のポートに接続される。

コントローラ１０は、制御を司るＣＰＵ１１と、ＣＰＵ１１が動作するためのプログラム等を格納したメモリ１２と、ネットワークに接続するための接続インタフェース１３と、を備えている。これらのハードウェア構成は、従来のものと同様である。また、接続インタフェース１３は、図示するように、通信プロトコルに対応する通信ケーブル２２の端子を装着するコネクタとなるＲＪ４５や、ＰＴ：パルストランス、ＰＨＹ：フィジカル・レイヤー、Ｍａｃ：メディア・アクセス・コントローラ等を備える。これらも、従来と同様のもので実現できる。

ここで本発明では、コントローラ１０にプロトコルモニタにおけるデータの収集機能を実装するようにした。係る収集機能（プロトコルモニタ機能）は、アプリケーションプログラムにより実現できる。つまり、プロトコルモニタ機能を実現するための基本的なハードウェア構成は、ＰＬＣ等のコントローラのハードウェアと共用することができ、ハードウェアとしては一体化される。そして、メモリ１２には、コントローラの基本動作を行うためのシステムプログラムと、実際に制御を行うためのユーザ制御プログラム（ユーザプログラムと称されることもある）に加え、モニタシステムプログラムを格納している。このモニタシステムプログラムは、プロトコルモニタ機能を実現するためのプログラムである。ＣＰＵ１１が、メモリ１２に格納された各プログラムを実行することで、ＦＡシステムの制御を行う本来のコントローラとして機能させたり、プロトコルモニタとして機能させたりする。これらの機能は、一方のみ稼働させたり、両方を並列的に稼働させたりできる。

さらに、メモリ１２は、解析するためのＩＯデータを格納するためのモニタデータバッファも備えている。このモニタデータバッファは、バッファ容量まで受信したら自動停止することや、通常リングバッファとして古いデータから順に廃棄して制御条件までエンドレスに動作を継続することができる。

また、図示省略するが、メモリ１２は、プログラム以外にも、ＣＰＵ１１が演算実行する際に使用するワークエリア等も確保されたり、ＩＯデータ等を格納するＩＯメモリエリアが確保されたりしている。これらのメモリは、用途に応じて不揮発性メモリや揮発性メモリが用いられる。

また、コントローラ１０は、プロトコルモニタ機能を内蔵するようにしたので、従来のようにスイッチングハブのミラーポート機能を利用しないですむ。その結果、スイッチングハブ２１は、ミラーポート機能が実装されていないものを用いることもできるし、図５に示すように、スイッチングハブが存在しないネットワークシステムにも利用できる。図５は、イーサキャット（登録商標）について適用した例である。イーサキャット（登録商標）は、イーサネット（登録商標）に準拠してＦＡ用に対応するものであって、より高速通信が可能とした通信プロトコルであり、リモート装置２３を渡り配線で接続する構成を採る。

本実施形態において、プロトコルモニタにおけるモニタリングを停止し、それまでのデータを保持するには、ＦＡネットワークシステムに接続された各装置・機器を制御するコントローラ１０そのものが異常検知し、コントローラ１０が直接、内蔵するプロトコルモニタを停止するようにした。こうすることでシステム上の異常検知は、通信フレーム上のデータパターンだけではなく、制御タイミングの不正や、複数のデータに依存した高度なアルゴリズムによる検出にも対応でき、特殊な設定スキルがなくとも、プロトコルモニタの停止を容易に行うことができる。また、プロトコルモニタ機能の停止／開始の動作の制御を、コントローラ自身が行えるため、トラブル発生の瞬間（直前）に通信していたデータをモニタデータとして残すことができる。

これに伴い、従来のプロトコルモニタ６のメモリ６ｂに格納されていたモニタ機能の制御条件については、コントローラのユーザ制御プログラム内に記述されメモリ１２に格納される。すなわち、図６に示すように、ユーザ制御プログラムの一つとして、図示のような異常検知用のファンクションブロックＦＢがある。このファンクションブロックＦＢは、異常を検出すると、エラー検知部のいずれかの接点がＯＮになり、出力であるストップフラグがＯＮになる。後述するように、このストップフラグがＯＮになった場合に、プロトコルモニタを停止することで、直前まで収集していたデータをそのままモニタデータとして残すことができる。また、エラー検知部の接点がＯＦＦになると、ストップフラグもＯＦＦになりモニタが再開できるようにすることもできる。このように、モニタの開始／停止の制御を、ラダープログラムにて記述できるので、ネットワークの専門技術者でなくともコントローラの制御プログラマの能力があれば、モニタ機能の制御が可能となる。

また、係るエラー検知部の接点がＯＮになるモニタ停止の判定ロジックは、通信タイムアウト，リンクダウン，制御データ異常，制御タイミング異常など何でもよい。さらに異常判定は、ユーザプログラムだけではなく、システムがある程度の異常（リンクダウン、ＦＣＳエラーなどの伝送エラー）を自動判定して停止してもよい。

本実施形態では、図７に示すように、送受信データを一時的に格納するリングバッファのバッファ量を通常のものよりも大きくした。すなわち、本実施形態においても、イーサネットドライバ部では、一般的な場合と同じくソフトウェア構造として、全二重通信（受信処理と送信処理の同時実行）を実現するために受信用のバッファと送信用のバッファを確保する。ただし、それぞれのバッファは、一般的な通信で必要とされるバッファ量よりも長大なバッファ量による（図では便宜上、０〜１５の１６個で表現する）配列と、格納最終ポインタと次回格納ポインタにより、一般的なリングバッファの構造を形成する。

このように、長大なバッファ量とすることで、それぞれのリングバッファに格納された送信データ、受信データをそのままフレームモニタのデータバッファとして使用することができる。実際には、数百から数千のバッファ量とした。

異常を生じていない通常時のリングバッファを用いた送受信は、データ配列が大きくなっただけで、一般的な場合と同等のポインタ処理により行うことができる。すなわち、イーサネットコントローラは、受信データをイーサネットドライバ部に渡す（受信要求）。イーサネットドライバ部は、イーサネットコントローラからの受信要求により、受信データを受信次回格納ポインタが設定された受信バッファ（図では“受信バッファ１２”）に格納する。その後、受信次回格納ポインタは＋１され、次回の受信に備える。このポインタはデータ配列の末端まで到達すると受信バッファ０に戻される。

一方、上位モジュール（図ではＴＣＰ／ＩＰやフレームモニタ）は、受信格納最終ポインタで示される受信バッファ（図では“受信バッファ９”）に格納されている受信データを任意のタイミングで読み出す。その後、受信格納最終ポインタは＋１され、次回の読み出しに備える。このポインタはデータ配列の末端まで到達すると受信バッファ０に戻される。このように、データ配列とポインタによる処理により、データ配列をリング構造に見せかけることで連続した受信処理を行う。そして、コントローラ１０の受信データの受信タイミングと、上位モジュールの読み出しタイミングは、不定であるため、読み出しが遅くれると、イーサネットコントローラから上位のＴＣＰ／ＩＰに引き渡す途中のデータが受信バッファにたまることになる。図７の例では、受信格納最終ポインタから受信次回可能ポインタまでの受信バッファ９〜１２に格納された受信データが、イーサネットコントローラから上位のＴＣＰ／ＩＰに引き渡す途中のデータとなる。それ以前のデータ（図では受信バッファ０〜８、１３〜１５）に格納された過去の受信データは、次に受信次回可能ポインタが設定され、その後受信データが格納されるまで残る。

このようにすると、上位のＴＣＰ／ＩＰに引き渡した後も、過去のデータが一定期間受信バッファに保持された状態となり、本実施形態では、長大なバッファ量のリングバッファとしたため、係る引き渡し後の過去のデータを、そのままフレームモニタのデータとして使用できる。なお、フレームモニタデータとして必要な受信時刻、送信時刻の情報は、受信バッファ、送信バッファのデータ構造の一部として確保し、イーサネットドライバの受信要因、送信要因で格納する。これらの説明は、送信処理においても同じである。

これにより、従来のように、モニタデータバッファへの格納（コピー）処理が不要となる。よって、本実施形態では、リングバッファのデータ配列が大きくなるものの、受信処理、送信処理への性能の影響は一般的な場合となんら変わることがないとともに、モニタデータバッファへのコピー処理が不要なために従来よりも高速に処理ができる。

一方、引き渡し後の過去のデータが格納されたバッファエリアは、上位のＴＣＰ／ＩＰの引き渡しや、新たな受信データの引き受けに伴うポインタの変更により、逐次変更される。そのため、何かしらの障害が発生した場合、そのままリングバッファ全体を使用して通信を継続すると、受信次回可能ポインタの移動により、過去のデータが新たに受信された受信データに書き換えられてしまい、障害を発生した原因を特定するためのデータが消失する可能性がある。送信処理についても同様である。

そこで、本実施形態では、図８に示すように、故障発生時には、リングバッファの配列を小さくし、その小さい配列内で受信データの受け取り、引き渡しをするようにした。これにより、それ以外のデータ領域に格納された過去のデータは、そのまま保持され、フレームモニタデータとして使用することができる。

具体的には、アプリケーションが何らかのエラーを検知したのち、フレームモニタ動作を停止すると、その時点でのポインタをキャプチャ停止ポインタとする。図８では、受信バッファ５と送信バッファ７に対してキャプチャ停止ポインタが設定されている。フレームモニタ停止後も通信状態を継続して動作させるために、キャプチャ停止ポインタから一般的な通信に必要なバッファ量を確保する（図では太枠で示された受信バッファ５〜１２、送信バッファ７〜１４）。一般的な通信は、このバッファの範囲を通信動作用のリングバッファとして使用する。キャプチャ先頭データポインタは、この一般通信で使用されるバッファの次に位置する。このポインタからリング構造を経てキャプチャ停止ポインタまで（図では受信バッファ１３〜４、送信バッファ１５〜６）をフレームモニタデータとして使用する。

図９は、本実施形態の機能を示すフローチャートである。コントローラ１０（ＣＰＵ１１）は、電源ＯＮにより、イーサネットドライバ部を初期化する（Ｓ１）。ここでは、イーサネットコントローラの初期化や、後述する送受信のためのリングバッファを準備する。

本実施形態では、プロトコルモニタ機能は、リングバッファの構造や制御アルゴリズムから、コントローラ本来のシステム性能への影響がないため、運転開始と共にモニタ（キャプチャ）を開始する（Ｓ２）。

キャプチャを開始したら、リングバッファの全ての領域（図６，図７では、受信バッファ０〜１５，送信バッファ０〜１５）を使用して通信を開始する（Ｓ３）。上述したように、コントローラが障害・異常を検出した場合には、ストップフラグがＯＮになるので、ストップフラグがＯＦＦ（Ｓ４でＮｏ）の状態が継続するかぎり、係る全ての領域を使用した最大リングバッファを用いて通信を行う。

一方、ストップフラグがＯＮになると（Ｓ４でＹｅｓ）、キャプチャ停止ポインタを設定し、そこから所定エリアの最小リングバッファを用いて通信を継続する（Ｓ５）。そして、最小リングバッファに設定された領域以外のバッファに残されたデータ（モニタデータ）が、故障・異常発生した直前のデータであるので、そのモニタデータを所定の解析ツールにアップロードする。モニタデータのアップロードについては任意のものを用いることができ、例えば、ファイルシステム情報に変換しＦＴＰ機能などで上位コンピュータからアップロードすることができる。そして、上位コンピュータにおいて、アップロードしたモニタデータに基づいて、故障・異常の原因等を解析することになる。最小リングバッファを用いても、通信に支障がないバッファ量を設定することにより、ネットワークシステムは、リングバッファを用いた安定した通信を継続できる。

モニタデータがアップロードできたタイミングで、プログラミングツール装置などからモニタ機能の再起動命令を与えると、処理ステップＳ６の分岐判断はＹｅｓとなり、処理ステップＳ３に戻り、全てのリングバッファを使用して送受信する状態に復帰する。

本実施形態では、コントローラ自体にプロトコルモニタ機能を実装し、運転開始当初からモニタリングすることができるので、初めて障害・異常が生じた場合でも、その最初の状態からデータをモニタすることができる。よって、発生頻度が低い異常等であっても、確実にその時のデータを保持し、解析することができる。

モニタデータは通常ファイルとして取り扱われる。ネットワークモニタソフトとしては、さまざまな種類のものが存在し、各々、モニタデータファイルのデータフォーマットがある。本発明のモニタデータは特別にデータフォーマットには依存せず、必要であればデータフォーマット変換などを行うこともできる。そして、保存されたモニタデータを用いることで、データシーケンスなどの解析やネットワーク負荷を分析することができる。また、保存されたモニタデータにＣＲＣエラーなどの伝送エラーなどを付加することで、ネットワークへのノイズなどの電気的な外乱が発生したことの可能性を間接的に分析することができる。

さらにコントローラで送受信されるデータとして、リモート装置（サーボモータ、インバータモータ、Ｉ／Ｏ、バルブなど）との入出力データがすべて格納されているため、データの意味解析など、いわゆるデータマイニングとしての分析に使用することができる。また、コントローラで送受信されるデータを、リモート装置（サーボモータ、インバータモータ、Ｉ／Ｏ、バルブなど）が実際に駆動する機械的機構品を３Ｄ−ＣＡＤなどで動作解析を行うデータとして使用し、機械的設備のトラブル発生前の挙動を解析することに使用できる。

１０ コントローラ
１１ ＣＰＵ
１２ メモリ

Claims (4)

1. ＦＡ用のコントローラであって、
   接続されるネットワークの異常の有無を判断する異常診断機能と、
   前記ネットワークに接続される機器との間で通信するデータをモニタリングするプロトコルモニタ機能と、
   前記異常診断機能で異常が検出された際に、その前に前記プロトコルモニタ機能にてモニタリングした前記データを保持する機能を備えたことを特徴とするコントローラ。
2. リングバッファを備え、前記機器と通信するデータは、そのリングバッファに一旦格納する通信方式を採り、
   前記リングバッファは、前記通信を行うに必要なバッファ量よりも大きいバッファ量が設定され、正常時はバッファ量の大きいリングバッファの設定で前記機器と通信を行い、そのリングバッファに保持されている前記データをモニタデータとして利用し、前記異常診断機能で異常を検出した場合には、前記リングバッファのうち、その異常を検出した後のデータが格納される一部の小さい領域を用いて通信を継続し、その通信を継続するために使用する領域以外に格納されたデータを保持することを特徴とする請求項１に記載のコントローラ。
3. 前記コントローラは、イーサネット（登録商標）或いはイーサキャット（登録商標）に対応するものである請求項１または２に記載のコントローラ。
4. 前記コントローラは、イーサネット（登録商標）或いはイーサキャット（登録商標）に対応するものであり、
   前記リングバッファは、イーサネットドライバ部内に設定されることを特徴とする請求項２に記載のコントローラ。

Images