JP2017227961A - コントローラおよび制御システム - Google Patents

Abstract

【課題】 制御システムにおいて、制御対象の制御のための演算に影響を与えることなく、異常の解析を十分に行えるようにする技術を提供する。【解決手段】 コントローラ１は、収集条件と状態情報との関連付けと、収集条件とが定義された状態情報定義ファイル１４２を予め取得する。データ収集機能部１３のテーブル管理機能部１３１は、制御対象系２Ａ〜２Ｃの状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３のうちの収集判断対象の状態情報Ａ１、Ｂ１およびＣ１と、状態情報定義ファイル１４２とに基づいて格納対象選定テーブル２２を作成する。データ収集機能部１３の格納機能部１３２は、格納対象選定テーブル２２に基づいて選ばれた状態情報Ａ１、Ａ２およびＡ３をタイムスタンプを付与して記憶部２０に格納する。【選択図】図１

Description

本発明は、制御対象に関する各種の状態を示す情報を異常の解析を行えるように記憶しておく機能を備えたコントローラおよび制御システムに関する。

制御システムの一例として、プラントの操業に用いられる制御システムが挙げられる。このような制御システムでは、機器の故障やプラントの操業に関わるシステム異常などのさまざまな異常が発生する虞がある。異常の規模や種類によっては、制御システムの停止に至ることもあり得る。異常が発生した場合や異常が発生しそうな場合には、制御システム管理者などは、その異常の発生要因の特定などの解析を行う。異常の解析に備え、制御システムには、制御対象に関する各種の状態を示す情報を記憶して蓄積する機能が備えられていることがある。制御システムによっては、制御対象の制御を行うコントローラにこの機能が備えられる。コントローラの具体例としては、ＤＣＳ（分散型制御システム或いは分散型制御装置）やプログラマブルロジックコントローラ（以下、ＰＬＣ）が挙げられる。一般的なＦＡシステムではコントローラとしてＰＬＣが用いられることが多いが、プラントの制御システムではＤＣＳが用いられることが多い。ＤＣＳはＰＬＣに比較して信頼性が高いからである。

図１３は、従来の制御システムの一例である制御システムＸ１００Ａの構成を示すブロック図である。図１３に示すように、この制御システムＸ１００Ａは、制御対象系Ｘ２Ａ、Ｘ２ＢおよびＸ２Ｃの制御を行うコントローラＸ１を有する。制御対象系Ｘ２Ａ、Ｘ２ＢおよびＸ２Ｃの各々は、コントローラＸ１の制御対象に関するひとまとまりのシステムである。制御対象に関する状態を示す情報、つまり、制御対象系の状態を示す情報のことを、以下、制御対象系の状態情報と呼ぶ。

コントローラＸ１は、記憶部Ｘ２０を備えている。記憶部Ｘ２０は、状態情報格納領域Ｘ２１Ａ、Ｘ２１ＢおよびＸ２１Ｃを有する。状態情報格納領域Ｘ２１Ａには、時間の経過に従って制御対象系Ｘ２Ａの状態情報Ａ１が順次に蓄積される。同様に、状態情報格納領域Ｘ２１Ｂには、時間の経過に従って制御対象系Ｘ２Ｂの状態情報Ｂ１が順次に蓄積され、状態情報格納領域Ｘ２１Ｃには、時間の経過に従って制御対象系Ｘ２Ｃの状態情報Ｃ１が順次に蓄積される。

特許文献１には、各入力装置から受信したデータをコントローラへ送信する転送装置を備えたデータ収集システムが開示されている。特許文献１のデータ収集システムによれば、コントローラ宛に送信するビット列を短時間に生成することができ、データ収集処理の性能を向上することができる。しかし、特許文献１の技術は、コントローラがデータ（すなわち状態情報）を短時間で取得する技術であり、取得した状態情報を記憶部に蓄積する技術ではない。

図１４は、図１３の制御システムＸ１００Ａの具体例を示す模式図である。図１４の例における制御対象系Ｘ２Ａは、水を蓄える水槽Ｘ２Ａ１と、水槽Ｘ２Ａ１への入水経路に設けられた入水弁Ｘ２Ａ２と、水槽Ｘ２Ａ１への入水流量を測定する流量計（マスフローメータ）Ｘ２Ａ４と、水槽Ｘ２Ａ１からの排水経路に設けられた排水弁Ｘ２Ａ３と、水槽Ｘ２Ａ１からの排水流量を測定する流量計（マスフローメータ）Ｘ２Ａ５と、水槽Ｘ２Ａ１内の水位を測定する水位計Ｘ２Ａ６とから構成される。この例におけるコントローラＸ１は、水位計Ｘ２Ａ６の測定結果である水位情報を取得し、水位情報で表される水位が目標値に近づくように、入水弁Ｘ２Ａ２の開度や開時間および排水弁Ｘ２Ａ３の開度や開時間を制御する。このように、コントローラＸ１の主な制御対象は水位であるが、その水位を制御するために直接に制御されるのが入水弁Ｘ２Ａ２や排水弁Ｘ２Ａ３である。このため、制御対象系Ｘ２Ａは、制御対象である水位に関するひとまとまりのシステムである。そして、コントローラＸ１は、水位情報で表される水位がアラーム水位Ｘ２Ａ９よりも高くなった場合、水位異常が発生したと判断する。

図１４の例において、水位計Ｘ２Ａ６の測定結果である水位情報は、制御対象系Ｘ２Ａの水槽Ｘ２Ａ１の水位の状態を表す状態情報である。図１４の例では、制御対象系Ｘ２Ａの状態情報である水位情報が状態情報格納領域Ｘ２１Ａに蓄積される。このため、図１４の例における制御システム管理者は、状態情報格納領域Ｘ２１Ａの水位情報の履歴を利用して制御対象系Ｘ２Ａにおける水位異常の解析を行うことができる。

図１４では、制御対象系Ｘ２ＢおよびＸ２Ｃの具体例の表記を省略した。例えば、制御対象系Ｘ２ＢおよびＸ２Ｃも制御対象系Ｘ２Ａと同様の構成であれば、制御システム管理者は、状態情報格納領域Ｘ２１Ｂに蓄積される水位情報および状態情報格納領域Ｘ２１Ｃに蓄積される水位情報を利用して制御対象系Ｘ２ＢおよびＸ２Ｃの水位異常の解析を行うことができる。なお、制御対象系Ｘ２ＢおよびＸ２Ｃの具体的な構成は、制御対象系Ｘ２Ａと異なる構成であっても良い。

図１５は、制御システムＸ１００ＡのコントローラＸ１が行う制御の流れを示すタイムチャートである。コントローラＸ１のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）（図示略）は、プログラム（図示略）を実行することにより、アプリケーション演算機能部とデータ収集機能部として動作する。アプリケーション演算機能部は、制御対象系Ｘ２Ａ〜Ｘ２Ｃの制御（図１４の例では、水槽Ｘ２Ａ１の水位制御）に関する各種の演算を行う。データ収集機能部は、制御対象系Ｘ２Ａ〜Ｘ２Ｃの状態情報Ａ１〜Ｃ１を記憶部Ｘ２０の状態情報格納領域Ｘ２１Ａ〜Ｘ２１Ｃへ格納する処理を行う。コントローラＸ１のＣＰＵは、アプリケーション演算機能部の処理とデータ収集機能部の処理とを所定の制御周期（例えば１０ｍｓ）で繰り返す。コントローラＸ１では、制御周期内におけるアプリケーション演算機能部が動作しない時間においてデータ収集機能部が動作して状態情報Ａ１〜Ｃ１の記憶部Ｘ２０への格納処理が行われる。

特開２００５−１７４１０５号公報

上述のように、制御システム管理者は、記憶部Ｘ２０に格納されている状態情報Ａ１〜Ｃ１の履歴を利用して制御対象系Ｘ２Ａ〜Ｘ２Ｃにおける異常の解析を行うことができる。しかし、複数の要因が連鎖的に関係して発生した異常などの複雑な異常の場合、状態情報Ａ１〜Ｃ１だけでは、異常の解析が困難である。

そこで、異常の解析を十分に行えるように、記憶しておく状態情報の種類を増やすことが考えられる。図１６は、制御システムＸ１００Ａに比べて記憶部Ｘ２０に格納する状態情報の種類を増やした制御システムＸ１００Ｂの構成を示すブロック図である。制御システムＸ１００Ｂでは、制御対象系Ｘ２Ａの状態情報Ａ１、Ａ２およびＡ３が状態情報格納領域Ｘ２１Ａに格納され、制御対象系Ｘ２Ｂの状態情報Ｂ１、Ｂ２およびＢ３が状態情報格納領域Ｘ２１Ｂに格納され、制御対象系Ｘ２Ｃの状態情報Ｃ１、Ｃ２およびＣ３が状態情報格納領域Ｘ２１Ｃに格納される。

図１７は、図１６の制御システムＸ１００Ｂの具体例を示す模式図である。図１７の例において、流量計Ｘ２Ａ４の検出結果である入水流量情報は、制御対象系Ｘ２Ａの水槽Ｘ２Ａ１に供給される水量の状態を表す状態情報であり、流量計Ｘ２Ａ５の検出結果である排水流量情報は、制御対象系Ｘ２Ａの水槽Ｘ２Ａ１から排出される水量の状態を表す状態情報である。図１７の例では、制御対象系Ｘ２Ａの状態情報である水位情報、入水流量情報および排水流量情報が状態情報格納領域Ｘ２１Ａに格納されて蓄積される。

図１７の例によれば、制御システム管理者は、水位情報の履歴に加え、入水流量情報の履歴および排水流量情報の履歴をも利用して制御対象系Ｘ２Ａにおける水位異常の解析を行うことができる。これにより、制御システム管理者は、排水流量に対して入水流量が多くなったことに起因して水位異常が発生したのか、入水流量に対して排水流量が少なくなったことに起因して水位異常が発生したのかを知ることができる。このように、記憶しておく状態情報の種類を増やすことで異常の解析を十分に行うことができる。

図１８は、制御システムＸ１００ＢのコントローラＸ１が行う制御の流れを示すタイムチャートである。図１８に示すように、この制御システムＸ１００Ｂにおけるデータ収集機能部は、制御周期毎に得られた状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３を状態情報格納領域Ｘ２１Ａ、Ｘ２１ＢおよびＸ２１Ｃに格納する。

制御システムＸ１００Ｂでは、格納する状態情報の種類が制御システムＸ１００Ａよりも多いため、制御周期の時間区間長に対するデータ収集機能部の動作時間の割合が制御システムＸ１００Ａに比べて多くなる。このため、制御システムＸ１００Ｂでは、制御周期の時間区間長に対してアプリケーション演算機能部の動作時間に当てることができる時間が制御システムＸ１００Ａに比べて少なくなる。これは、制御対象系の数や蓄積する状態情報の種類が増えるほど顕著になる。アプリケーション演算機能部の動作時間が少なくなると、アプリケーション演算機能部による所定の演算が時間内に完了しない可能性がある。このため、データ収集機能部の動作時間は、アプリケーション演算機能部による所定の演算の実行に影響が生じない時間範囲に制限される。

つまり、異常の解析を十分に行えるように、記憶しておく状態情報の種類を増やしたいが、状態情報を記憶する処理に当てることができる時間は限られるため、状態情報の種類を無制限に増やすことはできない、という問題がある。

アプリケーション演算機能部の動作時間を少なくせずにデータ収集機能部の動作時間を長くするには、制御周期を長くすることが考えられる。しかし、制御周期を長くすると制御の応答が遅くなるため、制御周期を長くすることは好ましくない。

本発明は以上に説明した課題に鑑みて為されたものであり、制御システムにおいて、制御対象の制御のための演算に影響を与えることなく、異常の解析を十分に行えるようにする技術を提供することを目的とする。

この発明によるコントローラは、アプリケーション演算機能部と、データ収集機能部とを有する。アプリケーション演算機能部は、制御対象に関するひとまとまりのシステムである制御対象系の状態を示す複数種の状態情報を所定の制御周期毎に１または複数の制御対象系について取得し、得られた状態情報のうちの少なくとも１つの状態情報に基づいて制御対象系の制御に関する各種の演算を行う。データ収集機能部は、制御周期内におけるアプリケーション演算機能部が動作しない時間において行われる処理であって、得られた状態情報のうちの記憶手段に格納する格納対象の状態情報の種類を、得られた状態情報のうちの少なくとも１つの状態情報に応じて変える処理を行う。

本コントローラでは、得られた状態情報のうちの格納対象の状態情報の種類が、得られた状態情報のうちの少なくとも１つの状態情報に応じて変わる。本コントローラによれば、格納対象の状態情報の種類が変わるため、必要な状態情報のみを記憶することができる。例えば、本コントローラによれば、得られた状態情報のうちの異常が発生しそうになった状態情報に関する状態情報のみを記憶し、その異常に関係のない状態情報を記憶しないようにすることができる。このため、本コントローラによれば、データ収集機能部の動作時間が長くなるのを抑えることができ、アプリケーション演算機能部による所定の演算の実行に影響が生じることはない。

より好ましい態様において、本コントローラのデータ収集機能部は、得られた状態情報のうちの少なくとも１つの状態情報を所定の収集条件を満たすか否かの収集判断対象の状態情報とし、収集判断対象の状態情報が収集条件を満たした場合、得られた状態情報のうちの収集条件に関連付けられた状態情報を格納対象の状態情報に選ぶ。

この態様における収集判断対象の状態情報の具体例は、異常の判断対象となる状態情報であり、所定の収集条件の具体例は、異常の有無の判断基準となる異常判断閾値に到達する途中において設定された収集閾値を超えたか否かである。この例によれば、所定の収集条件を満たした場合には、所定の収集条件を満たしていない場合に比べ、以後の制御周期において収集判断対象の状態情報が異常判断閾値に至って異常が発生する可能性が高い。本コントローラによれば、このような異常の発生の可能性が高い状態においてその異常に関連する各種の状態情報を記憶手段に格納するため、異常の解析を十分に行えるようになる。また、本コントローラによれば、所定の収集条件を満たさず、異常の発生の可能性が低い状態において、その異常に関連する状態情報を過度に格納することはない。この点からも、本コントローラによれば、データ収集機能部の動作時間が長くなるのを抑えることができ、アプリケーション演算機能部による所定の演算の実行に影響が生じることはない。

従って、この発明によれば、制御システムにおいて、制御対象の制御のための演算に影響を与えることなく、異常の解析を十分に行えるようになる。

この発明の実施形態によるコントローラ１を含む制御システム１００の構成を示すブロック図である。 状態情報定義ファイル１４２の構成例を示す図である。 格納対象選定テーブル２２の構成例を示す図である。 記憶部２０に格納される状態情報の一例を示す図である。 制御対象系２Ａ〜２Ｃの制御を開始する前の事前処理の流れを示すフローチャートである。 制御対象系２Ａ〜２Ｃの制御を開始した後の処理の流れを示すフローチャートである。 コントローラ１による制御の具体例を示すタイムチャートである。 時刻ｔ２２を含む制御周期における記憶部２０への格納状況を示すブロック図である。 変形例（１）における状態情報定義ファイルの構成例を示す図である。 図９の状態情報定義ファイルを用いた場合における制御の具体例を示すタイムチャートである。 変形例（２）における状態情報定義ファイルの構成例を示す図である。 変形例（３）における状態情報定義ファイルの構成例を示す図である。 従来の制御システムの一例である制御システムＸ１００Ａの構成を示すブロック図である。 図１３の制御システムＸ１００Ａの具体例を示す模式図である。 制御システムＸ１００ＡのコントローラＸ１が行う制御の流れを示すタイムチャートである。 制御システムＸ１００Ａに比べて記憶部Ｘ２０に格納する状態情報の種類を増やした制御システムＸ１００Ｂの構成を示すブロック図である。 図１６の制御システムＸ１００Ｂの具体例を示す模式図である。 制御システムＸ１００ＢのコントローラＸ１が行う制御の流れを示すタイムチャートである。

以下、図面を参照しつつ本発明の実施形態を説明する。
（実施形態）
図１は、この発明の一実施形態によるコントローラ１を含む制御システム１００の構成を示すブロック図である。制御システム１００は、制御対象系２Ａ、２Ｂおよび２Ｃの制御を行うコントローラ１を有する。

制御対象系２Ａ、２Ｂおよび２Ｃは、例えば、従来の制御システムＸ１００ＡおよびＸ１００Ｂにおける制御対象系Ｘ２Ａ、Ｘ２ＢおよびＸ２Ｃと同様のものである。制御対象系２Ａ、２Ｂおよび２Ｃの各々に含まれる各種の機器は、ネットワーク３を介してコントローラ１に接続される。コントローラ１は、ネットワーク３を介して、制御対象系２Ａから状態情報Ａ１、Ａ２およびＡ３を、制御対象系２Ｂから状態情報Ｂ１、Ｂ２およびＢ３を、制御対象系２Ｃから状態情報Ｃ１、Ｃ２およびＣ３を取得する。なお、制御対象系２Ａ、２Ｂおよび２Ｃは、制御対象系Ｘ２Ａ、Ｘ２ＢおよびＸ２Ｃとは異なるものであっても良い。また、制御対象系２Ａ、２Ｂおよび２Ｃは、各々が異なる種類のものであっても良い。

コントローラ１には、ネットワーク５を介して支援装置４が接続される。支援装置４は、コントローラ１による制御を支援する装置であり、例えば、パーソナルコンピュータである。

コントローラ１は、例えば、ＤＣＳ或いはＰＬＣである。コントローラ１は、制御部１０、記憶部２０および記憶部３０を有する。記憶部２０は、不揮発性の記憶装置の記憶領域のうち、コントローラ１のユーザに開放されているユーザ側の記憶領域である。制御部１０は、例えば、ＣＰＵである。制御部１０は、不揮発性記憶部（例えば記憶部２０）に格納されているプログラム（図示略）を実行することにより、コントローラ１の各部を制御する制御中枢である。記憶部３０は、メモリなどの揮発性の記憶装置の記憶領域のうち、コントローラ１のユーザに開放されていないシステム側の記憶領域である。

制御部１０は、プログラムを実行することにより、タスクスケジューリング機能部１１、アプリケーション演算機能部１２、データ収集機能部１３およびインターフェース機能部１４として動作する。なお、以後、インターフェースをＩＦと表記する。

ＩＦ機能部１４は、ネットワーク５を介して支援装置４と通信する。ＩＦ機能部１４は、制御システム管理者などが支援装置４を用いて作成した状態情報定義ファイル１４２を支援装置４から取得する。得られた状態情報定義ファイル１４２は、記憶部２０に格納される。

図２は、状態情報定義ファイル１４２の構成例を示す図である。状態情報定義ファイル１４２は、所定の収集条件が定義されたファイルである。また、状態情報定義ファイル１４２には、所定の収集条件を満たすか否かの判断の対象となる状態情報（以下、収集判断対象の状態情報という）の種類が定義されている。また、状態情報定義ファイル１４２には、制御対象系２Ａ〜２Ｃから得られる状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３の種類と、所定の収集条件との関連付けが定義されている。図２の例では、関連付けられたグループが１行で表されている。例えば、１行目の収集判断対象の状態情報Ａ１が「２０００よりも大」の収集条件には、収集判断対象の状態情報Ａ１と、状態情報Ａ２と、状態情報Ａ３とが関連付けられている、という具合である。

図１において、タスクスケジューリング機能部１１は、アプリケーション演算機能部１２が動作しない時間においてデータ収集機能部１３を動作させるように、アプリケーション演算機能部１２およびデータ収集機能部１３の実行順番を制御する。

アプリケーション演算機能部１２は、制御対象系２Ａ〜２Ｃの制御に関する各種の演算を実行する機能部である。また、アプリケーション演算機能部１２は、制御対象系２Ａから状態情報Ａ１、Ａ２およびＡ３を取得し、制御対象系２Ｂから状態情報Ｂ１、Ｂ２およびＢ３を取得し、制御対象系２Ｃから状態情報Ｃ１、Ｃ２およびＣ３を取得する機能を含む。得られた状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３は、記憶部３０に一時的に格納され、状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３が得られるごとに更新される。記憶部３０の状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３のうちの少なくとも１つの状態情報は、アプリケーション演算機能部１２による演算に利用される。

データ収集機能部１３は、制御対象系２Ａ〜２Ｃから得られた状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３のうちの記憶部２０に格納する格納対象の状態情報の種類を、収集判断対象の状態情報に応じて選ぶ機能部である。データ収集機能部１３は、テーブル管理機能部１３１と格納機能部１３２とを含む。

テーブル管理機能部１３１は、制御対象系２Ａ〜２Ｃから得られた状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３のうちの状態情報定義ファイル１４２によって定義された収集判断対象の状態情報が収集条件を満たすか否かの判断を行い、その収集判断結果と状態情報定義ファイル１４２とに基づいて格納対象選定テーブル２２を作成して更新するソフトウェアモジュールである。

図３は、格納対象選定テーブル２２の構成例を示す図である。格納対象選定テーブル２２は、格納対象の状態情報であるか否かの判断基準となるフラグを状態情報毎に関連付けたテーブルである。格納対象選定テーブル２２のフラグの値は、収集判断結果と状態情報定義ファイル１４２にて収集条件に関連付けられた状態情報とに基づいて決められる。図３の例において、フラグの値が「真（ＴＲＵＥ）」である状態情報は、格納対象に選定された状態情報であり、フラグの値が「偽（ＦＡＬＳＥ）」である状態情報は、格納対象に選定されない状態情報である。格納対象選定テーブル２２の更新の際には、このフラグの値が更新される。

格納機能部１３２は、テーブル管理機能部１３１によって作成された格納対象選定テーブル２２のフラグに基づいて格納対象の状態情報を選び、選ばれた状態情報の値を記憶部２０に格納するソフトウェアモジュールである。図４は、記憶部２０に格納される状態情報の一例を示す図である。図４に示すように、記憶部２０に格納される状態情報（図４では状態情報Ａ１、Ａ２およびＡ３）には、記憶部２０への格納時刻を示すタイムスタンプが付与される。

すなわち、データ収集機能部１３は、制御対象系２Ａ〜２Ｃから得られた状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３のうちの状態情報定義ファイル１４２によって定義された収集判断対象の状態情報が収集条件を満たした場合、その収集条件に関連付けられた状態情報を格納対象の状態情報として選び記憶部２０に格納する。
以上が、コントローラ１を含む制御システム１００の構成である。

次に、コントローラ１の動作を説明する。
図５は、制御対象系２Ａ〜２Ｃの制御を開始する前の事前処理の流れを示すフローチャートである。制御システム管理者などは、支援装置４を用いて状態情報定義ファイル１４２を予め作成しておく。コントローラ１の電源が投入されると、コントローラ１の制御部１０は、ＩＦ機能部１４として動作し、支援装置４からネットワーク５を介して状態情報定義ファイル１４２を取得する（ステップＳＡ１００）。ＩＦ機能部１４は、取得した状態情報定義ファイル１４２を記憶部２０に格納して終了する。なお、ＩＦ機能部１４は、制御システム管理者などによる状態情報定義ファイル１４２の取得を指示する操作に応じて状態情報定義ファイル１４２を支援装置４から取得しても良い。

図６は、制御対象系２Ａ〜２Ｃの制御を開始した後の処理の流れを示すフローチャートである。制御システム管理者などによる制御開始を指示する操作に応じて、コントローラ１の制御部１０は、まず、状態情報定義ファイル１４２をワークエリアに読み出す（ステップＳＢ１００）。

次に、制御部１０は、タスクスケジューリング機能部１１として動作を開始する。タスクスケジューリング機能部１１は、まず、制御終了指示を取得したか否かを判断する（ＳＢ１１０）。制御終了指示を取得した場合（ＳＢ１１０：Ｙｅｓ）、タスクスケジューリング機能部１１は、制御対象系２Ａ〜２Ｃの制御を終了する。一方、制御終了指示を取得しなかった場合（ステップＳＢ１１０：Ｎｏ）、タスクスケジューリング機能部１１は、制御周期の開始タイミングとなったか否かを判断する（ステップＳＢ１２０）。この制御周期の開始タイミングの判断は、内部クロックなどを用いて行われる。制御周期の開始タイミングではない場合（ステップＳＢ１２０：Ｎｏ）、タスクスケジューリング機能部１１は、制御周期の開始タイミングになるまでステップＳＢ１１０およびＳＢ１２０の処理を繰り返して待機する。

制御周期の開始タイミングとなった場合（ステップＳＢ１２０：Ｙｅｓ）、タスクスケジューリング機能部１１は、アプリケーション演算機能部１２を起動し、制御部１０は、アプリケーション演算機能部１２として動作を開始する。アプリケーション演算機能部１２は、まず、その制御周期の開始タイミングにおける制御対象系２Ａ〜２Ｃの各状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３を取得して記憶部３０に格納する。アプリケーション演算機能部１２は、状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３の少なくとも１つを用いた所定の演算を実行する（ステップＳＢ１３０）。アプリケーション演算機能部１２は、その所定の演算を終わるまで行う（ステップＳＢ１４０：Ｎｏ）。

所定の演算が終了すると（ステップＳＢ１４０：Ｙｅｓ）、アプリケーション演算機能部１２は、その旨をタスクスケジューリング機能部１１に通知する。その旨の通知を受けたタスクスケジューリング機能部１１は、データ収集機能部１３を起動する（ステップＳＢ１５０）。そして、制御部１０は、データ収集機能部１３として動作を開始する。

データ収集機能部１３のテーブル管理機能部１３１は、状態情報定義ファイル１４２を参照して収集判断対象の状態情報の種類を認識する。そして、テーブル管理機能部１３１は、記憶部３０に格納されている状態情報のうちの収集判断対象の状態情報をワークエリアに読み出す（ステップＳＢ１６０）。本実施形態の例では、状態情報Ａ１、Ｂ１およびＣ１が収集判断対象の状態情報として読み出される。

次に、テーブル管理機能部１３１は、読み出した収集判断対象の状態情報と状態情報定義ファイル１４２の収集条件とを比較し、収集判断対象の状態情報が収集条件を満たすか否かを収集条件毎に判断する（ステップＳＢ１７０）。より具体的には、テーブル管理機能部１３１は、読み出した収集判断対象の状態情報Ａ１が状態情報定義ファイル１４２の１行目の収集条件を満たすか否かを判断し、読み出した収集判断対象の状態情報Ｂ１が状態情報定義ファイル１４２の２行目の収集条件を満たすか否かを判断し、読み出した収集判断対象の状態情報Ｃ１が状態情報定義ファイル１４２の３行目の収集条件を満たすか否かを判断する。

次に、テーブル管理機能部１３１は、ステップＳＢ１７０の収集判断結果と状態情報定義ファイル１４２とに基づいて格納対象選定テーブル２２を作成して更新する（ステップＳＢ１８０）。より詳細には、テーブル管理機能部１３１は、ステップＳＢ１７０において収集判断対象の状態情報が収集条件を満たした場合、状態情報定義ファイル１４２において当該収集条件に関連付けられたすべての状態情報についてのフラグを「真（ＴＲＵＥ）」にする。例えば、読み出した収集判断対象の状態情報Ａ１が状態情報定義ファイル１４２の１行目の収集条件を満たした場合、その１行目の収集条件に関連付けられた状態情報Ａ１、Ａ２およびＡ３についての格納対象選定テーブル２２のフラグの値が各々「真（ＴＲＵＥ）」となる。

一方、ステップＳＢ１７０において収集判断対象の状態情報が収集条件を満たしていない場合、テーブル管理機能部１３１は、状態情報定義ファイル１４２において当該収集条件に関連付けられたすべての状態情報についてのフラグを「偽（ＦＡＬＳＥ）」にする。例えば、読み出した収集判断対象の状態情報Ｂ１が状態情報定義ファイル１４２の２行目の収集条件を満たしていない場合、その２行目の収集条件に関連付けられた状態情報Ｂ１、Ｂ２およびＢ３についての格納対象選定テーブル２２のフラグの値が各々「偽（ＦＡＬＳＥ）」となる。

テーブル管理機能部１３１は、このようにして状態情報毎にフラグの値を決めた格納対象選定テーブル２２を作成する。そして、テーブル管理機能部１３１は、作成した格納対象選定テーブル２２を記憶部２０に格納して更新する。

次に、データ収集機能部１１の格納機能部１３２は、テーブル管理機能部１３１によって作成された最新の格納対象選定テーブル２２のフラグに従って格納対象の状態情報の種類を選び、選んだ格納対象の状態情報の値を記憶部３０から読み出す（ステップＳＢ１９０）。例えば、格納対象選定テーブル２２において、状態情報Ａ１、Ａ２およびＡ３のフラグが「真（ＴＵＲＥ）」であり、状態情報Ｂ１、Ｂ２、Ｂ３、Ｃ１、Ｃ２およびＣ３のフラグが「偽（ＦＡＬＳＥ）」である場合、状態情報Ａ１、Ａ２およびＡ３が記憶部３０から読み出され、状態情報Ｂ１、Ｂ２、Ｂ３、Ｃ１、Ｃ２およびＣ３は読み出されない。

次に、格納機能部１３２は、ステップＳＢ１９０で記憶部３０から読み出した状態情報にタイムスタンプを関連付けて、当該読み出した状態情報とタイムスタンプとを記憶部２０に格納する（ステップＳＢ２００）。

格納対象の状態情報を格納した（ステップＳＢ２００）後、格納機能部１３２は、格納完了の旨をタスクスケジューリング機能部１１に通知する。その通知を受けたタスクスケジューリング機能部１１は、ステップＳＢ１１０の処理に戻る。そして、タスクスケジューリング機能部１１は、制御終了指示を取得しなかった場合（ステップＳＢ１１０：Ｎｏ）、次の制御周期の開始タイミングとなったか否かを判断する（ステップＳＢ１２０）。以上の処理を繰り返すことで、データ収集機能部１３は、制御周期毎に、所定の収集条件を満たした場合にその収集条件に関連付けられた状態情報のみを記憶部２０に格納する。

図７は、コントローラ１による制御の具体例を示すタイムチャートである。
制御周期の開始時刻ｔ１１において、アプリケーション演算機能部１２は、この時点における状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３を取得して記憶部３０に格納した。このときの状態情報Ａ１の値は１０００であり、状態情報Ｂ１の値は１０００であり、状態情報Ｃ１の値は１０００であったとする。時刻ｔ１２において、所定の演算が終了したため、データ収集機能部１３は動作を開始した。データ収集機能部１３のテーブル管理機能部１３１は、収集判断対象の状態情報Ａ１、Ｂ１およびＣ１を記憶部３０から読み出して状態情報定義ファイル１４２の収集条件と比較した。その結果、この時点では、状態情報Ａ１、Ｂ１およびＣ１のすべてにおいて収集条件を満たさなかった。このため、テーブル管理機能部１３１は、状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３についてのフラグをすべて「偽（ＦＡＬＳＥ）」とした格納対象選定テーブル２２を作成して更新した。この時点では、すべての状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３についてのフラグが「偽（ＦＡＬＳＥ）」であるため、格納機能部１３２は、記憶部２０に何も格納しない。

制御周期の開始時刻ｔ２１において、アプリケーション演算機能部１２は、この時点における状態情報Ａ１〜Ａ３、Ｂ１〜Ｂ３およびＣ１〜Ｃ３を取得して記憶部３０に格納した。このときの状態情報Ａ１の値は２５００であり、状態情報Ｂ１の値は１０００であり、状態情報Ｃ１の値は１０００であったとする。時刻ｔ２２において、所定の演算が終了したため、データ収集機能部１３は動作を開始した。データ収集機能部１３のテーブル管理機能部１３１は、収集判断対象の状態情報Ａ１、Ｂ１およびＣ１を記憶部３０から読み出して状態情報定義ファイル１４２の収集条件と比較した。その結果、この時点では、状態情報Ａ１は収集条件を満たし、状態情報Ｂ１およびＣ１は収集条件を満たさなかった。このため、テーブル管理機能部１３１は、満たされた収集条件に関連付けられた状態情報Ａ１、Ａ２およびＡ３についてのフラグを「真（ＴＲＵＥ）」とし、それ以外の状態情報Ｂ１〜Ｂ３およびＣ１〜Ｃ３についてのフラグを「偽（ＦＡＬＳＥ）」とした格納対象選定テーブル２２を作成して更新した。この時点では、状態情報Ａ１、Ａ２およびＡ３のフラグが「真（ＴＲＵＥ）」であるため、格納機能部１３２は、格納対象の状態情報として状態情報Ａ１、Ａ２およびＡ３を選び、状態情報Ａ１、Ａ２およびＡ３の値を記憶部３０から読み出す。そして、この時点における格納機能部１３２は、状態情報Ａ１、Ａ２およびＡ３をタイムスタンプとともに記憶部２０に格納する。

図８は、時刻ｔ２２を含む制御周期における記憶部２０への格納状況を示すブロック図である。図８に示すように、この制御周期の時点では、記憶部２０における制御対象系２Ａの状態情報格納領域２１Ａには状態情報Ａ１、Ａ２およびＡ３が格納されるが、制御対象系２Ｂの状態情報格納領域２１Ｂおよび制御対象系２Ｃの状態情報格納領域２１Ｃには何も格納されない。

図７において、制御周期の開始時刻ｔ３１では、状態情報Ａ１の値は３０００であり、状態情報Ｂ１の値は１０００であり、状態情報Ｃ１の値は１０００であったとする。この時点では、時刻ｔ２１から始まる直前の制御周期の場合と同様に、状態情報Ａ１、Ａ２およびＡ３についてのフラグが「真（ＴＲＵＥ）」であるため、格納機能部１３２は、状態情報Ａ１、Ａ２およびＡ３の値を記憶部３０から読み出し、タイムスタンプとともに記憶部２０に格納する。

ここで、例えば、収集判断対象の状態情報Ａ１の値（例えば水位情報の示す水位）が異常の有無の判断基準となる異常判断閾値ＴｈＥ（例えば３０００）を超えた場合、コントローラ１は異常（例えば水位異常）である旨の判断を行うものとする。状態情報Ａ１の値が異常判断閾値ＴｈＥよりも遥かに小さい値（例えば１０００）である場合、以後の制御周期において状態情報Ａ１の値が異常判断閾値ＴｈＥを超える可能性は低い。しかし、状態情報Ａ１の値が異常判断閾値ＴｈＥよりも小さい値であるが異常判断閾値ＴｈＥに近い値（例えば２５００）である場合、以後の制御周期において状態情報Ａ１の値が異常判断閾値ＴｈＥを超える可能性が高くなる。このため、異常の解析の際には、将来において異常判断条件を満たす可能性の高い異常判断閾値ＴｈＥに近い値が重要となる。

この点を考慮し、制御システム１００では、異常の判断対象となる状態情報を収集判断対象の状態情報とし、収集条件における判断基準となる収集閾値Ｔｈ１を異常の判断基準となる異常判断閾値ＴｈＥに到達する途中の値に設定するのが好ましい。図７の例では、異常判断閾値ＴｈＥである３０００に到達する途中の値である２０００を収集閾値Ｔｈ１としている。コントローラ１では、状態情報Ａ１が異常判断閾値ＴｈＥに近づいて収集閾値Ｔｈ１（２０００）を超えた場合に収集条件を満たしたとして、状態情報Ａ１、Ａ２およびＡ３を記憶部２０に格納するのである。状態情報Ａ１が収集閾値Ｔｈ１を超えた場合には、その後、状態情報Ａ１が異常判断閾値ＴｈＥにさらに近づいて異常判断閾値ＴｈＥを超える可能性が高いからである。制御対象系２Ａが例えば水位制御系である場合、状態情報Ａ１を水位情報とし、状態情報Ａ２を入水流量情報とし、状態情報Ａ３を排水流量情報とすれば、制御対象系２Ａの水位異常の解析を十分に行えるようになる。

以上のように、本実施形態のコントローラ１のデータ収集機能部１３は、収集判断対象の状態情報が所定の収集条件を満たした場合、その収集条件に関連付けられた状態情報を記憶部２０に格納し、その収集条件に関連付けられていない状態情報については記憶部２０に格納しない。コントローラ１によれば、異常の解析に必要な状態情報を収集条件に予め関連付けておくことで、異常の解析に十分な種類の状態情報を記憶部２０に蓄積することができる。また、コントローラ１によれば、異常の解析に必要な状態情報ではない状態情報（換言すると予想される異常に関連しない状態情報）の記憶部２０への格納処理を行わないため、データ収集機能部１３の動作時間が長くなるのを抑えることができ、アプリケーション演算機能部による所定の演算の実行に影響が生じることはない。

また、コントローラ１において、収集判断対象の状態情報の具体例は、異常の判断対象となる状態情報であり、所定の収集条件の具体例は、異常の有無の判断基準となる異常判断閾値ＴｈＥに到達する途中において設定された収集閾値Ｔｈ１を超えたか否かである。この例によれば、所定の収集条件を満たした場合には、所定の収集条件を満たしていない場合に比べ、以後の制御周期において収集判断対象の状態情報が異常判断閾値ＴｈＥに至って異常が発生する可能性が高い。コントローラ１によれば、このような異常の発生の可能性が高い状態においてその異常に関連する各種の状態情報を記憶部２０に格納するため、異常の解析を十分に行えるようになる。また、コントローラ１によれば、所定の収集条件を満たさず、異常の発生の可能性が低い状態において、その異常に関連する状態情報を過度に格納することはない。この点からも、コントローラ１によれば、データ収集機能部１３の動作時間が長くなるのを抑えることができ、アプリケーション演算機能部による所定の演算の実行に影響が生じることはない。

従って、本実施形態のコントローラ１によれば、制御対象の制御のための演算に影響を与えることなく、異常の解析を十分に行えるようになる。

（変形）
以上本発明の一実施形態について説明したが、この実施形態に以下の変形を加えても勿論良い。

（１）実施形態の状態情報定義ファイル１４２には、１つの収集判断対象の状態情報について１つの収集条件が定義されていた。しかし、状態情報定義ファイルにおいて、１つの収集判断対象の状態情報について複数の収集条件が定義されていても良い。図９は、この態様の状態情報定義ファイルの構成例を示す図である。図９の状態情報定義ファイルでは、収集判断対象の状態情報Ａ１が「２０００以下」の収集条件には、状態情報が何も関連付けられておらず、収集判断対象の状態情報Ａ１が「２０００よりも大であり２５００以下」の収集条件には、状態情報Ａ１およびＡ２が関連付けられており、収集判断対象の状態情報Ａ１が「２５００よりも大」の収集条件には、状態情報Ａ１、Ａ２およびＡ３が関連付けられている。

図１０は、図９の状態情報定義ファイルを用いた場合における制御の具体例を示すタイムチャートである。制御開始時刻ｔ１１の制御周期において状態情報Ａ１が２０００以下であったとする。この時点では、図９の状態情報定義ファイルに基づいて記憶部２０には何も格納されない。次の制御開始時刻ｔ２１の制御周期において、状態情報Ａ１が２０００よりも大であり、かつ、２５００以下に変化したとする。この時点では、図９の状態情報定義ファイルに基づいて記憶部２０には状態情報Ａ１およびＡ２が格納される。すなわち、コントローラ１は、状態情報Ａ１の変化に応じて、記憶部２０に何も格納されない収集状態Ｑ１から記憶部２０に状態情報Ａ１およびＡ２を格納する収集状態Ｑ２に状態遷移した。次の制御開始時刻ｔ３１の制御周期において、状態情報Ａ１が２５００よりも大に変化したとする。この時点では、図９の状態情報定義ファイルに基づいて記憶部２０には状態情報Ａ１、Ａ２およびＡ３が格納される。すなわち、コントローラ１は、状態情報Ａ１の変化に応じて、記憶部２０に状態情報Ａ１およびＡ２を格納する収集状態Ｑ２から記憶部２０に状態情報Ａ１、Ａ２およびＡ３を格納する収集状態Ｑ３に状態遷移した。

以上を踏まえると、コントローラ１のデータ収集機能部１３は、制御対象系から得られた複数種の状態情報のうちの記憶部２０に格納する格納対象の状態情報の種類を、収集判断対象の状態情報に応じて変える処理を行うのである。

（２）実施形態の状態情報定義ファイル１４２では、収集条件に対して関連付けられた状態情報を１行に表していた。しかし、状態情報定義ファイルは、図１１に示すように、収集判断対象の状態情報と収集条件とを制御対象系から得られる状態情報毎に表したものであっても良い。このように表したものであっても、収集条件と、制御対象系から得られる複数種の状態情報との関連付けが定義されていることに変わりはないからである。

（３）図１２に示すように、状態情報定義ファイルにおいて、収集条件に関連付けられた状態情報に優先順位が定義されていても良い。この態様のデータ収集機能部は、収集条件を満たすことで選ばれた格納対象の状態情報の数（換言すると、フラグが「真（ＴＵＲＥ）」である状態情報の数）が、制御周期とアプリケーション演算機能部１２の動作時間とに基づいて決められる上限を超えた場合、その上限を超えない数の格納対象の状態情報を、状態情報定義ファイルにおける優先順位に従って選ぶ。格納対象の状態情報の上限は、予め定義されていても良いし、アプリケーション演算機能部１２における演算内容によって逐次算出されても良い。この態様によれば、格納対象に選ばれた状態情報がその上限を超えてしまっても、優先順位を設けなかった場合に比べ、アプリケーション演算機能部１２による所定の演算の実行に影響を生じさせることはなく、重要な状態情報を優先的に格納するため、異常の解析を十分に行えるようになる。

（４）実施形態の状態情報定義ファイル１４２において、収集条件に対応する収集判断対象の状態情報の数は１つであった。しかし、例えば、状態情報Ａ１と状態情報Ａ２との乗算結果を収集判断対象の状態情報にする、という具合に、状態情報定義ファイルにおいて、収集条件に対応する収集判断対象の状態情報の数は、１つ以上であれば良く複数であっても良い。

（５）状態情報定義ファイルにおける各種定義は、実施形態や各変形例の具体例に限らない。

（６）実施形態のコントローラ１は、３個の制御対象系２Ａ〜２Ｃの制御を行うものであった。しかし、コントローラ１によって制御される制御対象系は３個に限らない。また、コントローラ１によって制御される制御対象系が複数ある場合、その複数の制御対象系の各々が同じ種類の制御対象系であっても良いし、各々が異なる種類の制御対象系であっても良いし、複数のうちの一部が同じ種類の制御対象系であっても良い。

（７）実施形態のコントローラ１は、制御対象系２Ａから３種類の状態情報Ａ１〜Ａ３を取得し、制御対象系２Ｂから３種類の状態情報Ｂ１〜Ｂ３を取得し、制御対象系２Ｃから３種類の状態情報Ｃ１〜Ｃ３を取得していた。しかし、制御対象系２Ａ〜２Ｃの各々から取得する状態情報の数は３種類に限らない。また、複数の制御対象系の各々から取得する状態情報の数は、複数の制御対象系で同じであっても良いし、複数の制御対象系毎に異なっていても良いし、複数のうちの一部の制御対象系で同じであっても良い。

（８）実施形態のコントローラ１のデータ収集機能部１３は、格納対象選定テーブル２２の作成と格納対象選定テーブル２２に基づいた状態情報の記憶部２０への格納とを同一の制御周期内で行っていた。しかし、データ収集機能部１３は、格納対象選定テーブル２２を作成した次の制御周期において、直前の制御周期で作成された格納対象選定テーブル２２に基づいた状態情報の格納を行っても良い。

（９）実施形態のコントローラ１では、制御周期内において、アプリケーション演算機能部１２の動作後にデータ収集機能部１３の動作が行われていた。しかし、データ収集機能部１３は、アプリケーション演算機能部１２が動作しない時間において行われれば良く、制御周期内において、アプリケーション演算機能部１２の動作の前に行われても良い。この態様のデータ収集機能部１３は、直前の制御周期のアプリケーション演算機能部１２によって取得された状態情報を用いて現在の制御周期における格納処理を行えば良い。

（１０）実施形態のコントローラ１の記憶部２０は、不揮発性の記憶装置であった。しかし、記憶部２０は、揮発性の記憶装置であっても良い。制御システム１００において異常が発生したとしても、記憶部２０への電力供給が途絶えなければ、記憶部２０に格納されている状態情報が引き続き保持され、その状態情報の履歴を利用して異常の解析を行うことができるからである。ただし、記憶部２０が揮発性の記憶装置である場合、不揮発性の記憶装置の場合に比べ、記憶部２０から状態情報が消去されるリスクが高くなる。また、記憶部２０を揮発性の記憶装置とする場合、記憶装置２０と記憶装置３０とを一体の記憶装置で構成しても良い。記憶装置２０に対応する記憶領域と記憶装置３０に対応する記憶領域とを区別することで、記憶装置２０に対応する記憶領域に格納された状態情報の履歴を保持することができるからである。

（１１）実施形態の制御システム１００では、状態情報が格納される記憶部２０をコントローラが備えていた。しかし、制御システムにおいて、状態情報が格納される記憶手段をコントローラ１とは別個に備えても良い。状態情報が格納される記憶手段とコントローラ１とが制御システム１００内で接続されれば、当該記憶手段は、コントローラ１によって選ばれた状態情報をコントローラ１から受信して格納することができるからである。

１００…制御システム、１…コントローラ、２Ａ，２Ｂ，２Ｃ…制御対象系、３，５…ネットワーク、４…支援装置、１０…制御部、１１…タスクスケジューリング機能部、１２…アプリケーション演算機能部、１３…データ収集機能部、１３１…テーブル管理機能部、１３２…格納機能部、１４…インターフェース機能部、１４２…状態情報定義ファイル、２０、３０…記憶部、２２…格納対象選定テーブル、Ａ１，Ａ２，Ａ３，Ｂ１，Ｂ２，Ｂ３，Ｃ１，Ｃ２，Ｃ３…状態情報。

Claims (6)

1. 制御対象に関するひとまとまりのシステムである制御対象系の状態を示す複数種の状態情報を所定の制御周期毎に１または複数の前記制御対象系について取得し、得られた状態情報のうちの少なくとも１つの状態情報に基づいて前記制御対象系の制御に関する各種の演算を行うアプリケーション演算機能部と、
   前記制御周期内における前記アプリケーション演算機能部が動作しない時間において行われる処理であって、前記得られた状態情報のうちの記憶手段に格納する格納対象の状態情報の種類を、前記得られた状態情報のうちの少なくとも１つの状態情報に応じて変える処理を行うデータ収集機能部と、
   を有することを特徴とするコントローラ。
2. 前記データ収集機能部は、
   前記得られた状態情報のうちの少なくとも１つの状態情報を所定の収集条件を満たすか否かの収集判断対象の状態情報とし、
   前記収集判断対象の状態情報が前記収集条件を満たした場合、
   前記得られた状態情報のうちの前記収集条件に関連付けられた状態情報を前記格納対象の状態情報に選ぶ
   ことを特徴とする請求項１に記載のコントローラ。
3. 前記収集条件には、前記収集判断対象の状態情報以外の状態情報が少なくとも１種類関連付けられていることを特徴とする請求項２に記載のコントローラ。
4. 前記収集条件に関連付けられた状態情報には優先順位が決められており、
   前記データ収集機能部は、
   前記収集条件を満たすことで選ばれた前記格納対象の状態情報の数が、前記制御周期と前記アプリケーション演算機能部の動作時間とに基づいて決められる上限を超えた場合、前記上限を超えない数の前記格納対象の状態情報を前記優先順位に従って選ぶ
   ことを特徴とする請求項２または３に記載のコントローラ。
5. 前記データ収集機能部は、
   前記収集条件と、前記収集条件と前記複数種の状態情報との関連付けとが定義された定義ファイルに基づいて前記収集判断対象の状態情報が前記収集条件を満たすか否かの判断を行い、
   前記収集条件を満たすか否かの判断結果と、前記定義ファイルとに基づいて更新されるテーブルに従って前記格納対象の状態情報を選ぶ
   ことを特徴とする２〜４のいずれか１の請求項に記載のコントローラ。
6. 制御対象に関するひとまとまりのシステムである制御対象系の状態を示す複数種の状態情報を所定の制御周期毎に１または複数の前記制御対象系について取得し、得られた状態情報のうちの少なくとも１つの状態情報に基づいて前記制御対象系の制御に関する各種の演算を行うアプリケーション演算手段と、
   前記制御周期内における前記アプリケーション演算手段が動作しない時間において行われる処理であって、前記得られた状態情報のうちの記憶手段に格納する格納対象の状態情報の種類を、前記得られた状態情報のうちの少なくとも１つの状態情報に応じて変える処理を行うデータ収集手段と、
   を有することを特徴とする制御システム。

Images