JP7226103B2 - 制御システム、サポート装置およびサポートプログラム - Google Patents

Description

本発明は、検知対象に発生し得る何らかの異常を検知可能な制御システム、その制御システムで用いられるサポート装置、およびサポート装置を実現するためのサポートプログラムに関する。

様々な生産現場において、機械や装置に対する予知保全により設備稼働率を向上させたいというニーズが存在する。予知保全とは、機械や装置に生じる何らかの異常を検知して、設備を停止しなければ状態になる前に、整備や交換などの保守作業を行うような保全形態を意味する。

予知保全を実現するために、機械や装置の状態値を収集するとともに、収集された状態値に基づいて、当該機械や装置に何らかの異常が生じているか否かを判断するような仕組みが必要となる。

例えば、特開２０１８－０９７６６２号公報（特許文献１）は、制御対象に生じている現象をより短い周期で監視できる技術を開示する。

特開２０１８－０９７６６２号公報

特開２０１８－０９７６６２号公報（特許文献１）に開示されるように、制御対象に生じている現象をより短い周期で監視するためには、比較的多くのリソースを必要とする。一方で、既存の制御装置では、異常検知に必要なリソースを十分に確保できない場合も生じ得る。

本発明の一つの目的は、必要な異常検知を必要な場所に配置することができる構成を実現することである。

本発明の一例に従えば、制御対象を制御するための制御システムが提供される。制御システムは、演算処理を実行可能な複数の処理リソースを含む。複数の処理リソースは、制御対象に含まれる任意の検知対象に対応する１または複数の状態値を収集する収集手段と、収集された１または複数の状態値から算出された特徴量に基づいて、検知対象に異常が発生している可能性を示す値を算出する異常検知手段とを含む。収集手段および異常検知手段の各々は、複数の処理リソースのうち、任意の処理リソースに配置可能である。

この構成によれば、処理リソースが不足していた場合であっても、必要な部分に異常検知を配置できる。

異常検知手段は、検知対象に異常が発生している可能性を示す値に基づいて、検知対象に異常が発生しているか否かを示す判定結果を生成してもよい。この構成によれば、判定結果を参照することで、検知対象に異常が発生している場合に必要な処理を実行できる。

収集手段および異常検知手段が異なる処理リソースに配置されている場合において、異常検知手段は、生成された判定結果を収集手段が配置された処理リソースへ送信してもよい。この構成によれば、複数の処理リソースが連係して異常検知処理を実現できる。

収集手段および異常検知手段が異なる処理リソースに配置されている場合において、収集手段は、収集された１または複数の状態値を異常検知手段が配置された処理リソースへ送信してもよい。この構成によれば、１または複数の状態値を収集する処理リソースにおいて、異常検知の結果を容易に得ることができる。

収集手段および異常検知手段が異なる処理リソースに配置されている場合において、異常検知手段は、算出された検知対象に異常が発生している可能性を示す値を収集手段が配置された処理リソースへ送信してもよい。この構成によれば、１または複数の状態値を収集する処理リソースにおいて、検知対象に異常が発生している可能性を示す値を容易に得ることができる。

収集手段および異常検知手段の配置先となる処理リソースの決定を支援するためのサポート装置をさらに含んでいてもよい。この構成によれば、サポート装置を用いることで、制御システムに対して異常検知処理を容易に実装できる。

サポート装置は、収集手段が収集すべき状態値の数、状態値の収集先、複数の処理リソースのスペック、内部バスの負荷率、および、ネットワークの負荷率の少なくとも一つに基づいて、収集手段および異常検知手段の配置先を決定してもよい。この構成によれば、１または複数のファクタに基づいて、異常検知処理を適切に実装できる。

サポート装置は、収集手段および異常検知手段が配置されるべき処理リソースに対して、必要なデータを送信してもよい。この構成によれば、制御システムにおいて異常検知処理を実装するために必要なデータを容易に配置できる。

本発明の別の例に従えば、制御対象を制御するための制御システムで用いられるサポート装置が提供される。制御システムは、演算処理を実行可能な複数の処理リソースを含む。複数の処理リソースは、制御対象に含まれる任意の検知対象に対応する１または複数の状態値を収集する収集手段と、収集された１または複数の状態値から算出された特徴量に基づいて、検知対象に異常が発生している可能性を示す値を算出する異常検知手段とを含む。サポート装置は、収集手段および異常検知手段の配置先となる処理リソースの決定を支援するためのユーザインターフェイスを提供する。

この構成によれば、制御システムに含まれる１または複数の処理リソースを用いて、異常検知処理を容易に実装できる。

本発明のさらに別の例に従えば、制御対象を制御するための制御システムで用いられるサポート装置を実現するためのサポートプログラムが提供される。制御システムは、演算処理を実行可能な複数の処理リソースを含む。複数の処理リソースは、制御対象に含まれる任意の検知対象に対応する１または複数の状態値を収集する収集手段と、収集された１または複数の状態値から算出された特徴量に基づいて、検知対象に異常が発生している可能性を示す値を算出する異常検知手段とを含む。サポートプログラムは、コンピュータに、収集手段および異常検知手段の配置先となる処理リソースの決定を支援するためのユーザインターフェイスを提供する機能を実現させる。

この構成によれば、制御システムに含まれる１または複数の処理リソースを用いて、異常検知処理を容易に実装できる。

本発明によれば、必要な異常検知を必要な場所に配置することができる。

本実施の形態に従う制御システムの要部を示す模式図である。 本実施の形態に従う制御システムの構成例を示す模式図である。 本実施の形態に従う制御装置を構成する制御ユニットのハードウェア構成例を示すブロック図である。 本実施の形態に従う制御装置を構成する補助処理ユニットのハードウェア構成例を示すブロック図である。 本実施の形態に従う制御システムに用いられるサポート装置のハードウェア構成例を示すブロック図である。 本実施の形態に従う制御システムにおける異常検知機能を実現するための構成例を示すブロック図である。 本実施の形態に従う制御装置における制御演算の実行周期を説明するためのタイムチャートである。 本実施の形態に従う制御システムにおける異常検知機能の実装例を示す模式図である。 本実施の形態に従う制御システムにおける異常検知機能の別の実装例を示す模式図である。 本実施の形態に従う制御システムにおける異常検知機能のさらに別の実装例を示す模式図である。 本実施の形態に従う制御システムにおけるシステム設計手順の一例を示すフローチャートである。 本実施の形態に従う制御システムにおける異常検知機能の実装例を決定する指針の一例を説明するための図である。 本実施の形態に従う制御システムのサポート装置が提供するユーザインターフェイス画面の一例を示す図である。 本実施の形態に従う制御システムのサポート装置が提供するユーザインターフェイス画面の一例を示す図である。

本発明の実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰り返さない。

＜Ａ．適用例＞
まず、本発明が適用される場面の一例について説明する。

本実施の形態に従う異常検知処理を実行可能な制御システムの機能的な構成例について説明する。

図１は、本実施の形態に従う制御システム１の要部を示す模式図である。図１を参照して、制御対象を制御するための制御システム１は、一例として、演算処理を実行可能な複数の処理リソース３０－１～３０－６を有している。

本明細書において、「処理リソース」は、任意の演算処理を独立して実行できる主体を包含する用語である。例えば、ＰＬＣ（プログラマブルロジックコントローラ）などの制御装置単体が「処理リソース」であってもよいし、制御装置を構成する処理ユニット（後述の制御ユニット１００および補助処理ユニット２００など）の各々が「処理リソース」であってもよい。「処理リソース」は、典型的には、プログラムに規定された命令を展開するためのメモリと、メモリ上に展開された命令を順次実行するプロセッサとを含む。

制御システム１に含まれる複数の処理リソース３０－１～３０－６は、制御対象に含まれる任意の検知対象において生じ得る、何らかの異常を検知する機能を有している。

本明細書において、「異常検知」あるいは「異常検知機能」は、典型的には、検知対象において「通常とは異なる」あるいは「いつもとは違う」ことを検知することを包含する。複数の処理リソース３０－１～３０－６には、典型的には、制御周期毎に制御対象から収集される状態値に基づいて異常の有無を判断する機能が実装される。

具体的には、制御システム１には、制御対象に含まれる任意の検知対象に対応する１または複数の状態値を収集する状態値収集処理３２（後述する状態値収集１８０の処理を含む）、および、収集された１または複数の状態値から算出された特徴量に基づいて、検知対象に異常が発生している可能性を示す値（典型的には、後述する「スコア」）を算出する異常検知処理３４（後述するスコア算出１８２および判定１８４の処理を含む）とが実装される。

本明細書において、「状態値」は、任意の制御対象（含む：検知対象）にて観測できる値を包含する用語であり、例えば、任意のセンサにより測定できる物理値や、リレーやスイッチなどのＯＮ／ＯＦＦを示す状態値、ＰＬＣがサーボドライバに与える位置、速度、トルクなどの指令値、ＰＬＣが演算に用いる変数値などを含み得る。任意のセンサにより測定できる物理値やリレーやスイッチなどのＯＮ／ＯＦＦを示す状態値は、「生データ」とも言える。

図１（Ａ）には、状態値収集処理３２および異常検知処理３４が処理リソース３０－１に配置されている例を示す。図１（Ｂ）には、状態値収集処理３２が処理リソース３０－１に配置されており、異常検知処理３４が処理リソース３０－５に配置されている例を示す。図１（Ｂ）に示す例では、処理リソース３０－１の状態値収集処理３２により収集された状態値は、処理リソース３０－５へ送信される。

このように、本実施の形態においては、状態値収集処理３２および異常検知処理３４は、複数の処理リソース３０－１～３０－６のうち、任意の処理リソースに配置可能となっている。

このような構成を採用することで、本実施の形態に従う制御システム１においては、制御システム１に含まれる複数の処理リソースを利用して、必要な異常検知を必要な場所に配置できる。

＜Ｂ．制御システムの構成例＞
まず、本実施の形態に従う制御システム１の構成例について説明する。

（ｂ１：全体構成）
図２は、本実施の形態に従う制御システム１の構成例を示す模式図である。図２を参照して、制御システム１は、制御対象を制御するように構成されており、処理リソースとしての複数の制御装置１０－１，１０－２，１０－３（以下、「制御装置１０」とも総称する。）を含む。

制御装置１０は、演算処理を実行可能になっており、設備や機械を制御するための制御演算を周期的に実行する。制御装置１０は、制御対象である製造装置および生産ライン、ならびに、個々のセンシングデバイス（以下、「フィールド」とも総称する。）の状態値を入力値として収集するとともに、入力値に基づく制御演算により算出される指令値（以下、「出力値」とも称す。）を、制御対象である製造装置および生産ライン、ならびに、個々のアクチュエータへ出力する。

典型的には、制御装置１０とフィールドとの間で遣り取りされる入力値および出力値は、フィールドネットワーク４および６を介して伝送される。フィールドネットワーク４および６としては、データの到達時間が保証される、定周期通信を行うネットワークを採用することが好ましい。このような定周期通信を行うネットワークとしては、ＥｔｈｅｒＣＡＴ（登録商標）などが知られている。

図２に示す構成例においては、制御システム１は、制御装置１０－１とフィールドネットワーク４を介して接続されたリモートＩ／Ｏ装置１２と、制御装置１０－２とフィールドネットワーク６を介して接続されたリモートＩ／Ｏ装置１２とを含む。リモートＩ／Ｏ装置１２には、フィードとの間で信号を遣り取りするための１または複数のリレー１４などが接続されている。

制御装置１０－１，１０－２，１０－３は、制御ネットワーク８を介して互いにデータ通信可能に接続されている。制御装置１０－１，１０－２，１０－３の間では、任意のデータを遣り取り可能になっている。

制御装置１０の各々は、制御ユニット１００を含み、必要に応じて、補助処理ユニット２００を装着することもできる。以下、制御ユニット１００および補助処理ユニット２００に加えて、サポート装置３００のハードウェア構成例について説明する。

（ｂ２：制御ユニット１００のハードウェア構成例）
図３は、本実施の形態に従う制御装置１０を構成する制御ユニット１００のハードウェア構成例を示すブロック図である。図３を参照して、制御ユニット１００は、主たるコンポーネントとして、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphical Processing Unit）などのプロセッサ１０２と、チップセット１０４と、主記憶装置１０６と、二次記憶装置１０８と、ＵＳＢ（Universal Serial Bus）コントローラ１１２と、メモリカードインターフェイス１１４と、ネットワークコントローラ１１６，１１８と、内部バスコントローラ１２０とを含む。

プロセッサ１０２は、二次記憶装置１０８に格納された各種プログラムを読み出して、主記憶装置１０６に展開して実行することで、標準制御に係る制御演算、および、後述するような各種処理を実現する。チップセット１０４は、プロセッサ１０２と各コンポーネントとの間のデータの遣り取りを仲介することで、制御ユニット１００全体としての処理を実現する。

主記憶装置１０６は、ＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）などの揮発性記憶装置などで構成される。二次記憶装置１０８は、例えば、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などの不揮発性記憶装置などで構成される。

二次記憶装置１０８には、システムプログラムに加えて、システムプログラムが提供する実行環境上で動作する制御プログラムが格納される。

ＵＳＢコントローラ１１２は、ＵＳＢ接続を介して任意の情報処理装置との間のデータの遣り取りを担当する。

メモリカードインターフェイス１１４は、メモリカード１１５を着脱可能に構成されており、メモリカード１１５に対して制御プログラムや各種設定などのデータを書込み、あるいは、メモリカード１１５から制御プログラムや各種設定などのデータを読出すことが可能になっている。

ネットワークコントローラ１１６は、制御ネットワーク８（図２参照）を介して他の制御装置１０との間のデータの遣り取りを仲介する。ネットワークコントローラ１１８は、フィールドネットワーク４，６を介して、リモートＩ／Ｏ装置１２（いずれも図２参照）などの任意のデバイスとの間のデータの遣り取りを仲介する。

内部バスコントローラ１２０は、内部バスを介して制御装置１０を構成する他のユニットとの間のデータの遣り取りを仲介する。内部バスには、メーカ固有の通信プロトコルを用いてもよいし、いずれかの産業用ネットワークのプロトコルと同一あるいは準拠した通信プロトコルを用いてもよい。

図３には、プロセッサ１０２がプログラムを実行することで必要な機能が提供される構成例を示したが、これらの提供される機能の一部または全部を、専用のハードウェア回路（例えば、ＡＳＩＣ（Application Specific Integrated Circuit）またはＦＰＧＡ（Field-Programmable Gate Array）など）を用いて実装してもよい。あるいは、制御ユニット１００の主要部を、汎用的なアーキテクチャに従うハードウェア（例えば、汎用パソコンをベースとした産業用パソコン）を用いて実現してもよい。この場合には、仮想化技術を用いて、用途の異なる複数のＯＳ（Operating System）を並列的に実行させるとともに、各ＯＳ上で必要なアプリケーションを実行させるようにしてもよい。

（ｂ３：補助処理ユニット２００のハードウェア構成例）
図４は、本実施の形態に従う制御装置１０を構成する補助処理ユニット２００のハードウェア構成例を示すブロック図である。図４を参照して、補助処理ユニット２００は、主たるコンポーネントとして、ＣＰＵやＧＰＵなどのプロセッサ２０２と、チップセット２０４と、主記憶装置２０６と、二次記憶装置２０８と、メモリカードインターフェイス２１４と、内部バスコントローラ２２０とを含む。

プロセッサ２０２は、二次記憶装置２０８に格納された各種プログラムを読み出して、主記憶装置２０６に展開して実行することで、制御演算に付随する任意の演算処理を実現する。チップセット２０４は、プロセッサ２０２と各コンポーネントとの間のデータの遣り取りを仲介することで、補助処理ユニット２００全体としての処理を実現する。

二次記憶装置２０８には、システムプログラムに加えて、システムプログラムが提供する実行環境上で動作するセーフティプログラムが格納される。

メモリカードインターフェイス２１４は、メモリカード２１５を着脱可能に構成されており、メモリカード２１５に対してセーフティプログラムや各種設定などのデータを書込み、あるいは、メモリカード２１５からセーフティプログラムや各種設定などのデータを読出すことが可能になっている。

内部バスコントローラ２２０は、内部バスを介した制御ユニット１００との間のデータの遣り取りを担当する。

図４には、プロセッサ２０２がプログラムを実行することで必要な機能が提供される構成例を示したが、これらの提供される機能の一部または全部を、専用のハードウェア回路（例えば、ＡＳＩＣまたはＦＰＧＡなど）を用いて実装してもよい。あるいは、補助処理ユニット２００の主要部を、汎用的なアーキテクチャに従うハードウェア（例えば、汎用パソコンをベースとした産業用パソコン）を用いて実現してもよい。この場合には、仮想化技術を用いて、用途の異なる複数のＯＳを並列的に実行させるとともに、各ＯＳ上で必要なアプリケーションを実行させるようにしてもよい。

（ｂ４：サポート装置３００のハードウェア構成例）
図５は、本実施の形態に従う制御システム１に用いられるサポート装置３００のハードウェア構成例を示すブロック図である。サポート装置３００は、一例として、汎用的なアーキテクチャに従うハードウェア（例えば、汎用パソコン）を用いてプログラムを実行することで実現される。

図５を参照して、サポート装置３００は、ＣＰＵやＭＰＵなどのプロセッサ３０２と、ドライブ３０４と、主記憶装置３０６と、二次記憶装置３０８と、ＵＳＢコントローラ３１２と、ローカルネットワークコントローラ３１４と、入力部３１６と、表示部３１８とを含む。これらのコンポーネントはバス３２０を介して接続される。

プロセッサ３０２は、二次記憶装置３０８に格納された各種プログラムを読み出して、主記憶装置３０６に展開して実行することで、後述するような各種処理を実現する。

二次記憶装置３０８は、例えば、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などで構成される。二次記憶装置３０８には、サポート装置３００を実現するためのサポートプログラム３４０が格納される。より具体的には、二次記憶装置３０８には、サポート装置３００において実行されるユーザプログラムの作成、作成したプログラムのデバッグ、システム構成の定義、各種パラメータの設定などを行うための開発ツール３５０と、設定ツール３６０とを含む各種プログラムが格納される。サポートプログラム３４０は、開発ツール３５０および設定ツール３６０を含む。二次記憶装置３０８には、ＯＳおよび他の必要なプログラムがさらに格納されてもよい。

ドライブ３０４は、記憶媒体３０５に対してデータを書込み、記憶媒体３０５から各種データ（ユーザプログラム、トレースデータまたは時系列データなど）を読み出すことが可能になっている。記憶媒体３０５は、例えばコンピュータ読取可能なプログラム（典型的には、サポートプログラム３４０）を非一過的に格納する記憶媒体３０５（例えば、ＤＶＤ（Digital Versatile Disc）などの光学記憶媒体）を含む。

サポート装置３００で実行される各種プログラム（典型的には、サポートプログラム３４０）は、コンピュータ読取可能な記憶媒体３０５を介してインストールされてもよいが、ネットワーク上のサーバ装置などからダウンロードする形でインストールするようにしてもよい。サポート装置３００が提供する機能は、ＯＳが提供するモジュールの一部を利用する形で実現される場合もある。

ＵＳＢコントローラ３１２は、ＵＳＢ接続を介して制御ユニット１００または補助処理ユニット２００との間のデータの遣り取りを仲介する。ローカルネットワークコントローラ３１４は、任意ネットワークを介した他の装置との間のデータの遣り取りを制御する。

入力部３１６は、キーボードやマウスなどで構成され、ユーザ操作を受け付ける。表示部３１８は、ディスプレイ、各種インジケータなどで構成され、プロセッサ３０２からの処理結果などを出力する。サポート装置３００には、プリンタが接続されてもよい。

図５には、プロセッサ３０２がプログラムを実行することで必要な機能が提供される構成例を示したが、これらの提供される機能の一部または全部を、専用のハードウェア回路（例えば、ＡＳＩＣまたはＦＰＧＡなど）を用いて実装してもよい。

＜Ｃ．異常検知機能＞
次に、本実施の形態に従う制御システム１に実装される異常検知機能について説明する。

図６は、本実施の形態に従う制御システム１における異常検知機能を実現するための構成例を示すブロック図である。図６を参照して、制御装置１０は、異常検知機能として、変数管理部１６０と、特徴抽出部１４０と、機械学習処理部１４４と、結果判定部１４６とを含む。

変数管理部１６０は、制御対象に現れる状態値（入力値）を予め定められた制御周期毎に収集して、内部状態値であるデバイス変数１６２の値を更新する。なお、本発明は「変数」を用いて値を参照する形態に限られることなく、各値を格納するメモリの物理アドレスなどを直接指定して参照する形態などにも適用可能である。

特徴抽出部１４０は、検知対象に対応する１または複数の状態値（入力値）から１または複数の特徴量１５０を算出する。より具体的には、特徴抽出部１４０は、予め設定された設定情報１５８に従って、指定された１または複数のデバイス変数１６２（状態値）が示す値（あるいは、単位区間における値の時間的変化）に基づいて、予め定められた算出手順に従って１または複数の特徴量１５０（例えば、所定時間に亘る平均値、最大値、最小値など）を周期的またはイベント毎に算出する。特徴抽出部１４０が特徴量１５０を算出するために用いる単位区間を「フレーム」と称することもある。単位区間（フレーム）は、検知対象の動作などに応じて任意に設定される。

機械学習処理部１４４は、学習モデル１５２を参照して、特徴抽出部１４０により算出される１または複数の特徴量１５０に基づいて、検知対象に何らかの異常が発生している可能性を示す値であるスコア１５４を算出する。

一例として、機械学習処理部１４４は、異常検知のアルゴリズムとして、超空間上における値群に対する入力値の外れ度合いに基づいて、当該入力値に対応するスコアを算出する方法を採用してもよい。外れ度合いに基づく異常検知の手法としては、各点から値群までの最短距離に基づいて異常を検知する手法（ｋ近傍法）、値群を含むクラスタを含めて距離を評価する局所外れ値因子（ＬｏＦ：local outlier factor）法、パス長さから算出されるスコアを用いるｉＦｏｒｅｓｔ（isolation forest）法などが知られている。

学習モデル１５２が正常時の特徴量から構成される場合には、学習モデル１５２からの外れ度合い（すなわち、スコア）が大きいほど、検知対象に何らかの異常が発生している可能性が高いと判断できる。一方、学習モデル１５２が異常時の特徴量から構成される場合には、学習モデル１５２からの外れ度合い（すなわち、スコア）が小さいほど、検知対象に何らかの異常が発生している可能性が高いと判断できる。学習モデル１５２は、公知のデータマイニングの手法により決定することができる。

結果判定部１４６は、機械学習処理部１４４により算出されるスコア１５４に基づいて、検知対象に何らかの異常が発生しているか否かを示す判定結果１７０を生成する。判定条件１５６は、サポート装置３００により予め設定されてもよい。典型的には、判定条件１５６は、スコア１５４に対して設定される、検知対象に何らかの異常が発生している可能性が高いことを示すしきい範囲などを含む。判定結果１７０は、検知対象に何らの異常も発生していない状態である「ＯＫ」、および、検知対象に何らかの異常が発生している状態である「ＮＧ」のいずれかであってもよい。

以上のような構成を採用することで、制御対象に含まれる任意の検知対象について、発生し得る何らかの異常の発生を検知できる。なお、特徴抽出部１４０、機械学習処理部１４４および結果判定部１４６をライブラリ化してもよい。この場合には、設定情報１５８、学習モデル１５２および判定条件１５６をライブラリに設定することで、専門知識の乏しいユーザであっても、異常検知機能を容易に利用できる。

＜Ｄ．処理リソースの確保および課題＞
次に、制御装置１０（制御ユニット１００）における制御演算の周期実行について説明する。図７は、本実施の形態に従う制御装置１０における制御演算の実行周期を説明するためのタイムチャートである。図７（Ａ）には、処理リソースに余裕のある制御装置１０において、異常検知処理を実行する例を示す。図７（Ａ）に示すように、制御装置１０においては、予め定められた制御周期毎に制御タスク５０（制御演算）が実行される。制御周期の長さに対して、制御タスク５０の実行に要する時間が十分に短ければ、異常検知タスク５２（異常検知処理）をさらに実行するようにしたとしても、その合計時間は制御周期の長さ以下になり得る。図７（Ａ）に示す実行状態においては、制御タスク５０および異常検知タスク５２の両方を制御周期毎に実行することができる。

これに対して、図７（Ｂ）には、処理リソースに余裕のない制御装置１０において、異常検知処理を実行する例を示す。図７（Ｂ）に示すように、制御周期の長さに対して、制御タスク５０の実行に要する時間が相対的に長ければ、異常検知タスク５２（異常検知処理）をさらに実行すると、その合計時間は制御周期の長さを超え得る。図７（Ｂ）に示す実行状態においては、制御タスク５０および異常検知タスク５２の両方を制御周期毎に実行することができない。

このように、予防保全などの目的で異常検知機能を導入しようとした場合において、異常検知の実行に要する処理リソースは相対的に大きいので、制御演算の定周期実行を確保できない可能性がある。特に、高い応答性などが要求される制御対象においては、異常検知機能の導入が難しい場合がある。

＜Ｅ．分散配置＞
上述したように、十分な処理リソースを確保できない環境においては、異常検知機能の導入が難しいことがある。本実施の形態に従う制御システム１は、このような課題に対する解決手段を提供できる。

図８は、本実施の形態に従う制御システム１における異常検知機能の実装例を示す模式図である。図８には、制御装置１０－１および１０－２に異常検知機能が実装される例を示す。

より具体的には、制御装置１０－１および１０－２の各々では、状態値収集１８０、スコア算出１８２および判定１８４の処理が実行される。状態値収集１８０は、特徴抽出部１４０（図６参照）が検知対象に対応する１または複数の状態値（入力値）を収集する処理に相当する。スコア算出１８２は、特徴抽出部１４０および機械学習処理部１４４がスコア１５４を算出する処理（いずれも図６参照）に相当する。判定１８４は、結果判定部１４６が検知対象に何らかの異常が発生しているか否かを示す判定結果１７０を生成する処理（いずれも図６参照）に相当する。

状態値収集処理３２（図１参照）は、制御対象に含まれる任意の検知対象に対応する１または複数の状態値を収集するための状態値収集１８０の処理を含む。異常検知処理３４（図１参照）は、収集された１または複数の状態値から算出された特徴量に基づいて、検知対象に異常が発生している可能性を示す値（スコア）を算出するためのスコア算出１８２の処理と、検知対象に異常が発生している可能性を示す値（スコア）に基づいて、検知対象に異常が発生しているか否かを示す判定結果１７０を生成するための判定１８４の処理とを含む。

図８に示す実装例においては、制御装置１０－１および１０－２の各々において、互いに独立して異常検知機能が実行される。制御装置１０－１および１０－２は、算出される判定結果およびスコアを他の制御装置１０へ出力することも可能である。

図９は、本実施の形態に従う制御システム１における異常検知機能の別の実装例を示す模式図である。図９には、制御装置１０－２および１０－３が連係することで、異常検知機能が実装される例を示す。

より具体的には、制御装置１０－２では、状態値収集１８０の処理が実行され、検知対象に対応する１または複数の状態値が収集される。この収集された状態値（生データ）は、制御装置１０－３へ送信される。制御装置１０－３では、制御装置１０－２からの状態値に基づいて、スコア算出１８２および判定１８４の処理が実行される。これらの処理の結果算出された判定結果およびスコアは、制御装置１０－３から制御装置１０－２へ戻される。制御装置１０－２は、制御装置１０－３からの判定結果およびスコアに基づいて、検知対象に何らかの異常が発生していることを検知でき、この検知結果に応じて、必要な処理を実行できる。

図９に示すように、状態値収集処理３２（状態値収集１８０）ならびに異常検知処理３４（スコア算出１８２および判定１８４）が異なる処理リソース（制御装置１０－２）に配置されている場合には、状態値収集処理３２（状態値収集１８０）は、収集された１または複数の状態値を異常検知処理３４（スコア算出１８２および判定１８４）が配置された処理リソース（制御装置１０－３）へ送信するようにしてもよい。

また、状態値収集処理３２（状態値収集１８０）ならびに異常検知処理３４（スコア算出１８２および判定１８４）が異なる処理リソース（制御装置１０－２）に配置されている場合には、異常検知処理３４（スコア算出１８２および判定１８４）は、生成された判定結果１７０を状態値収集処理３２（状態値収集１８０）が配置された処理リソース（制御装置１０－３）へ送信するようにしてもよい。このとき、異常検知処理３４（スコア算出１８２および判定１８４）は、算出された検知対象に異常が発生している可能性を示す値（スコア１５４）を状態値収集処理３２（状態値収集１８０）が配置された処理リソース（制御装置１０－３）へ送信するようにしてもよい。

図９に示す構成例においては、制御装置１０－２では、状態値収集１８０の処理のみが実行されることになるので、上述の図７（Ｂ）に示すような処理リソースに余裕のない状況であっても、異常検知機能を実装できる。

図９に示すように、複数の制御装置１０を連係して異常検知機能を実装可能にすることで、例えば、異常検知を提供するライブラリを有していない制御装置１０であっても、異常検知機能を容易に利用することができるようになる。また、検知対象に対応する１または複数の状態値を収集して他の制御装置１０へ送信さえすればよいので、制御装置１０で実行されるユーザプログラムなどの変更を最小限に抑えることができる。

なお、図９には、２つの制御装置１０が連係して異常検知機能を実現する構成例を示すが、これに限らず、３つ以上の制御装置１０が連係して異常検知機能を実現するようにしてもよい。

図８および図９においては、複数の制御装置１０が連係して異常検知機能を実現する構成例を示したが、単一の制御装置１０が互いに独立した複数の処理リソースを有している場合もある。このような場合には、複数の処理リソースが連係して異常検知機能を実現してもよい。

図１０は、本実施の形態に従う制御システム１における異常検知機能のさらに別の実装例を示す模式図である。図１０（Ａ）および（Ｂ）には、制御ユニット１００と、補助処理ユニット２００と、１または複数のＩ／Ｏユニット２５０とからなる制御装置１０を示す。制御ユニット１００および補助処理ユニット２００は、いずれもプロセッサを有しており、異常検知機能を実現するための処理を実行可能になっている。

制御ユニット１００およびＩ／Ｏユニット２５０との間は、内部バス１２２を介して接続されており、制御ユニット１００は、Ｉ／Ｏユニット２５０により収集された任意の状態値（入力値）を収集可能になっている。

図１０（Ａ）には、制御装置１０の制御ユニット１００に異常検知機能が実装される例を示す。より具体的には、制御ユニット１００では、状態値収集１８０、スコア算出１８２および判定１８４の処理が実行される。

これに対して、図１０（Ｂ）には、制御装置１０の制御ユニット１００および補助処理ユニット２００が連係することで、異常検知機能が実装される例を示す。より具体的には、制御ユニット１００では、状態値収集１８０の処理が実行され、検知対象に対応する１または複数の状態値が収集される。この収集された状態値（生データ）は、補助処理ユニット２００へ送信される。補助処理ユニット２００では、制御ユニット１００からの状態値に基づいて、スコア算出１８２および判定１８４の処理が実行される。これらの処理の結果算出された判定結果およびスコアは、補助処理ユニット２００から制御ユニット１００へ戻される。制御ユニット１００は、補助処理ユニット２００からの判定結果およびスコアに基づいて、検知対象に何らかの異常が発生していることを検知でき、この検知結果に応じて、必要な処理を実行できる。

図８～図１０に示すように、本実施の形態に従う制御システム１においては、単一の処理リソースを用いて異常検知機能を実現することができるとともに、複数の処理リソースを用いて異常検知機能を実現することもできる。すなわち、状態値収集１８０、スコア算出１８２および判定１８４の各々は、複数の処理リソースのうち、任意の処理リソースに配置可能になっている。

このようなフレキシブルな実装形態を採用することで、制御対象を制御するための既存の仕組み（ユーザプログラムを含む）を大きく変更することなく、必要な制御装置１０に対して、必要な異常検知機能を提供することができる。このような実装形態を採用することで、既存のユーザプログラムの実行への影響を局限化できる。

また、異常検知機能を実装するために、特別なシステム設計などを行うことなく、余裕度合いなどに応じて、任意の処理リソースに必要な機能を割り当てるだけで、異常検知機能を実現できる。

＜Ｆ．システム設計手順＞
次に、上述したような異常検知機能を配置する際のシステム設計手順について説明する。

図１１は、本実施の形態に従う制御システム１におけるシステム設計手順の一例を示すフローチャートである。図１１に示す処理は、基本的には、サポート装置３００において実行される。すなわち、サポート装置３００は、状態値収集処理３２（状態値収集１８０）ならびに異常検知処理３４（スコア算出１８２および判定１８４）の配置先となる処理リソースの決定を支援する。

図１１を参照して、ユーザは、予め定められた設計仕様に従って、任意の制御装置１０において実行される、制御対象を制御するためのユーザプログラムを作成する（ステップＳ１）。ユーザプログラムの作成が完了すると、ユーザは、当該制御装置１０に対して必要な異常検知機能を設定する（ステップＳ２）。続いて、ユーザがシミュレーションの実行を指示すると、サポート装置３００は、制御装置１０の機種情報、作成されたユーザプログラムの内容、および設定された異常検知機能などの情報に基づいて、シミュレーションを実行し、制御タスク５０および異常検知タスク５２の実行に必要な時間を算出する（ステップＳ３）。この算出された時間は、ユーザへ提示される。

ユーザは、提示された実行に必要な時間を確認し、現在の設定を適用するか否かを指定する（ステップＳ４）。現在の設定を適用することが指定されると（ステップＳ４においてＹＥＳ）、サポート装置３００は、現在の設定に応じた設定データおよびユーザプログラムなどを対象の制御装置１０へ転送する（ステップＳ５）。そして、処理は終了する。

現在の設定を変更することが指定されると（ステップＳ４においてＮＯ）、サポート装置３００は、異常検知機能を分散配置するための候補案を作成してユーザへ提示する（ステップＳ６）。ユーザがいずれかの候補案を選択すると（ステップＳ７）、サポート装置３００は、選択された候補案に対応する設定データおよびユーザプログラムなどを対象となる１または複数の制御装置１０へ転送する（ステップＳ８）。そして、処理は終了する。

このように、本実施の形態に従う制御システム１においては、異常検知機能を実装するための設計を支援する機能を提供する。

制御タスク５０および異常検知タスク５２の実行に必要な時間が制御周期を超過する場合には、以下のようなファクタを考慮して、異常検知機能を担当する制御装置１０あるいは制御ユニット１００および補助処理ユニット２００などを決定する。

・異常検知に必要な状態値の数
・異常検知に必要な状態値の収集先（デバイス）
・制御装置１０（制御ユニット１００および補助処理ユニット２００）のスペック
・制御装置１０の内部バスの負荷率
・制御装置１０に接続されるフィールドネットワークの負荷率
・制御装置１０に接続される制御ネットワークの負荷率
このように、サポート装置３００は、収集すべき状態値の数、状態値の収集先、複数の処理リソースのスペック、内部バスの負荷率、および、ネットワークの負荷率の少なくとも一つに基づいて、状態値収集処理３２（状態値収集１８０）ならびに異常検知処理３４（スコア算出１８２および判定１８４）の配置先を決定する。

基本的には、異常検知機能を担当する処理リソースは、検知対象に対応する１または複数の状態値（入力値）の発生元により近い位置にあるものを優先的に採用することが好ましい。また、処理リソースが複数のコアを有している場合には、定周期処理を担当するコアを優先的に使用するようにしてもよい。これらを採用できない場合に限って、ネットワーク経由で処理リソースを利用するようにしてもよい。

例えば、検知対象に対応する１または複数の状態値（入力値）のうち、タスク周期が相対的に長い状態値についての処理は、他の制御装置１０に委譲するようにしてもよい。また、ユーザが予め設定してプライオリティに基づいて、プライオリティが低い状態値についての処理は、他の制御装置１０に委譲するようにしてもよい。

図１２は、本実施の形態に従う制御システム１における異常検知機能の実装例を決定する指針の一例を説明するための図である。図１２を参照して、指針としては、品質重視およびロバスト性重視の二つの考え方がある。品質重視は、速度および周期性を確保することを優先するものであり、ロバスト性重視は、安定性を優先するものである。

制御周期の観点で見ると、品質重視は、ロバスト性重視の場合に比較してより短い制御周期で実行される。また、データ量の観点で見ると、ロバスト性重視は、品質重視の場合に比較してより少ないデータ量が処理される。

サポート装置３００が提供するユーザインターフェイス画面などにおいて、ユーザは、品質重視およびロバスト性重視のいずれを希望するのかを先に選択するようにしてもよい。

例えば、品質重視が選択された場合には、内部バスを介して状態値を収集できる処理リソースが優先的に選択されることが好ましい。また、制御タスクを担当する処理リソースが異常検知タスクについても担当するように選択することが好ましい。制御タスクおよび異常検知タスクを同一の処理リソースで実行することで、同一制御周期内において必要な情報を確実に収集できる。

一方、ロバスト性重視が選択された場合には、異常検知タスクの実行周期は相対的に長くなる可能性があるが、対象のデータ量が多くても異常検知処理を確実に実行できる。ロバスト性重視が選択された場合には、制御ネットワークなどを介して接続された処理リソースを選択することもできる。但し、ネットワーク上に多くのデータが伝送されることになるので、ネットワーク負荷などについても事前の調査などが必要である。また、ネットワーク負荷が増大することに対して、ユーザに通知するとともに、ユーザからの明示的な許可を受けるように構成してもよい。

また、ロバスト性重視が選択された場合には、制御タスクを担当する処理リソース以外の処理リソースを用いてもよい。制御システム全体として、処理負荷が均等に分散されるように配置することが優先される。

以下に例示するように、サポート装置３００は、状態値収集処理３２（状態値収集１８０）ならびに異常検知処理３４（スコア算出１８２および判定１８４）の配置先となる処理リソースの決定を支援するためのユーザインターフェイスを提供する。

図１３は、本実施の形態に従う制御システム１のサポート装置３００が提供するユーザインターフェイス画面４００の一例を示す図である。

図１３を参照して、ユーザインターフェイス画面４００は、設定対象の制御システム１における処理リソースの状態を示すリソースモニタと、処理リソースの制御周期との情報を含む。より具体的には、設定対象の制御システム１のシステム構成４１０と、各制御装置１０に含まれる処理リソース毎の負荷率に相当する使用率４１２，４１４，４１６とが表示されている。使用率４１２，４１４，４１６については、シミュレーションにより計算された値であってもよいし、現実の制御システムと接続できる場合には、実測値であってもよい。

ここで、ユーザインターフェイス画面４００には、予めユーザが設定した異常検知機能を示すアイコン４１８も表示されている。図１３に示す例では、「ＰＬＣ２」の制御ユニットで実行されることが示されている。

異常検知機能を実行する処理リソースの設定に応じて、各タスクの実行時間が示される。具体的には、ユーザインターフェイス画面４００は、各制御装置の制御ユニット毎に実行されるタスクおよび各タスクの実行に要する時間を示す実行時間表示４２０を含む。実行時間表示４２０の表示内容は、シミュレーションにより計算された値であってもよいし、現実の制御システムと接続できる場合には、実測値であってもよい。

ユーザは、図１３に示されるユーザインターフェイス画面４００を参照しながら、異常検知機能を担当する処理リソースを適宜調整することができる。但し、専門知識が乏しいユーザであっても、異常検知機能を適切に実装できるように、サポート装置３００は、適切な「おすすめ」設定を提示することもできる。

図１４は、本実施の形態に従う制御システム１のサポート装置３００が提供するユーザインターフェイス画面４０２の一例を示す図である。

図１４を参照して、ユーザインターフェイス画面４０２においては、図１３に示す状態に比較して、「おすすめ設定」が表示される。図１４に示すユーザインターフェイス画面４０２においては、異常検知機能を示すアイコン４１８が「ＰＬＣ３」に対応付けられており、これは、「ＰＬＣ３」の制御ユニット１００において異常検知の処理が実行されることが示されている。

この異常検知の処理を担当する処理リソースの変更に伴って、実行時間表示４２０についても表示内容が更新される。

ユーザインターフェイス画面４０２の下部には、「ＯＫ」のボタン４３０または「ＮＧ」のボタン４３２が表示されている。ユーザが「ＯＫ」のボタン４３０を選択すると、サポート装置３００は、ユーザインターフェイス画面４０２の表示内容を反映する。より具体的には、サポート装置３００は、反映された内容に従って、対象となる制御装置１０（制御ユニット１００および補助処理ユニット２００）に対して書込むべき実行ファイルや各種設定を生成し、順次書込みを行う。併せて、設定情報１５８、学習モデル１５２、判定条件１５６（いずれも図６参照）についても、サポート装置３００から対象の制御装置１０へ送信される。これらの送信されるデータの容量が大きい場合には、ネットワークの負荷率などを考慮して、最適な送信方法を決定するようにしてもよい。

このように、サポート装置３００は、状態値収集処理３２（状態値収集１８０）ならびに異常検知処理３４（スコア算出１８２および判定１８４）が配置されるべき処理リソースに対して、必要なデータを送信する。

このとき、制御ネットワークなどを介して他の制御装置１０などへ送信される変数は、自動的に公開変数に設定されてもよい。

上述したようなファクタを考慮して自動的に決定された設定内容をユーザに提示するとともに、ユーザが提示された設定内容をさらに変更するようなことも可能である。

なお、品質重視が選択されていれば、ある制御装置１０から他の制御装置１０へ状態値を送信するように設定した場合、送信元の制御装置１０に判定結果１７０およびスコア１５４が戻されることをデフォルトとするが好ましい。一方、ロバスト性重視が選択されていれば、上位側にある制御装置１０に判定結果１７０およびスコア１５４が送信されることをデフォルトとするが好ましい。但し、この設定についても、ユーザが任意に選択できるようにしてもよい。

なお、複数の判定結果１７０の組み合わせを用いて、制御対象に生じ得る異常を検知したいといったニーズも存在する。このような場合には、複数の異常検知タスクの周期などを互いに一致するように調整してもよい。

さらに、シミュレーションにより決定された設定に従って、現実の制御システム１に設定を行った上で、各処理リソースの状態を確認できるようにしてもよい。現実の制御システム１における各処理リソースの状態がシミュレーションにより算出された状態と異なっている場合には、再設定を行うようにしてもよい。

＜Ｇ．付記＞
上述したような本実施の形態は、以下のような技術思想を含む。
［構成１］
制御対象を制御するための制御システム（１）であって、
演算処理を実行可能な複数の処理リソース（１０；１００，２００）を備え、
前記複数の処理リソースは、
前記制御対象に含まれる任意の検知対象に対応する１または複数の状態値を収集する収集手段（３２；１８０）と、
前記収集された１または複数の状態値から算出された特徴量に基づいて、前記検知対象に異常が発生している可能性を示す値（１５４）を算出する異常検知手段（３４；１８４，１８６）とを備え、
前記収集手段および前記異常検知手段の各々は、前記複数の処理リソースのうち、任意の処理リソースに配置可能である、制御システム。
［構成２］
前記異常検知手段は、前記検知対象に異常が発生している可能性を示す値に基づいて、前記検知対象に異常が発生しているか否かを示す判定結果（１７０）を生成する、構成１に記載の制御システム。
［構成３］
前記収集手段および前記異常検知手段が異なる処理リソースに配置されている場合において、前記異常検知手段は、前記生成された判定結果を前記収集手段が配置された処理リソースへ送信する、構成２に記載の制御システム。
［構成４］
前記収集手段および前記異常検知手段が異なる処理リソースに配置されている場合において、前記収集手段は、前記収集された１または複数の状態値を前記異常検知手段が配置された処理リソースへ送信する、構成１～３のいずれか１項に記載の制御システム。
［構成５］
前記収集手段および前記異常検知手段が異なる処理リソースに配置されている場合において、前記異常検知手段は、前記算出された検知対象に異常が発生している可能性を示す値を前記収集手段が配置された処理リソースへ送信する、構成１～４のいずれか１項に記載の制御システム。
［構成６］
前記収集手段および前記異常検知手段の配置先となる処理リソースの決定を支援するためのサポート装置（３００）をさらに備える、構成１～５のいずれか１項に記載の制御システム。
［構成７］
前記サポート装置は、前記収集手段が収集すべき状態値の数、状態値の収集先、前記複数の処理リソースのスペック、内部バスの負荷率、および、ネットワークの負荷率の少なくとも一つに基づいて、前記収集手段および前記異常検知手段の配置先を決定する、構成６に記載の制御システム。
［構成８］
前記サポート装置は、前記収集手段および前記異常検知手段が配置されるべき処理リソースに対して、必要なデータを送信する、構成６または７に記載の制御システム。
［構成９］
制御対象を制御するための制御システム（１）で用いられるサポート装置（３００）であって、
前記制御システムは、演算処理を実行可能な複数の処理リソース（１０；１００，２００）を備えており、
前記複数の処理リソースは、
前記制御対象に含まれる任意の検知対象に対応する１または複数の状態値を収集する収集手段（３２；１８０）と、
前記収集された１または複数の状態値から算出された特徴量に基づいて、前記検知対象に異常が発生している可能性を示す値（１５４）を算出する異常検知手段（３４；１８４，１８６）とを備え、
前記サポート装置は、前記収集手段および前記異常検知手段の配置先となる処理リソースの決定を支援するためのユーザインターフェイス（４００，４０２）を提供する、サポート装置。
［構成１０］
制御対象を制御するための制御システム（１）で用いられるサポート装置（３００）を実現するためのサポートプログラム（３４０）であって、
前記制御システムは、演算処理を実行可能な複数の処理リソース（１０；１００，２００）を備えており、
前記複数の処理リソースは、
前記制御対象に含まれる任意の検知対象に対応する１または複数の状態値を収集する収集手段（３２；１８０）と、
前記収集された１または複数の状態値から算出された特徴量に基づいて、前記検知対象に異常が発生している可能性を示す値（１５４）を算出する異常検知手段（３４；１８４，１８６）とを備え、
前記サポートプログラムは、コンピュータに、前記収集手段および前記異常検知手段の配置先となる処理リソースの決定を支援するためのユーザインターフェイス（４００，４０２）を提供する機能を実現する、サポートプログラム。

＜Ｈ．利点＞
本実施の形態に従う制御システム１においては、各処理リソースの余裕度合い（ネットワークの負荷率なども含む）に応じて、適切な処理リソースに異常検知機能を実装できる。そのため、制御対象を制御するためのユーザプログラムの実行を妨げることなく、必要な異常検知機能を必要な位置に実装できる。また、余裕のある処理リソースが異常検知機能を実装できるので、タスク実行が制御周期を超過するような事態を回避できる。すなわち、異常検知機能を適切な位置に実装することで、各処理リソースにおけるタスク実行の定周期性を可能な限り維持できる。

本実施の形態に従う制御システム１においては、異常検知機能を適切な位置に実装できるので、特定の制御装置１０（制御ユニット１００および補助処理ユニット２００）のスペックを高くする必要がなく、初期設定時における処理リソースの設定制約を下げることができる。また、既存の制御システム１に対して異常検知機能を実装する場合であっても、余裕のある処理リソースを用いることができるので、新たに処理リソースを導入したり、より高いスペックの処理リソースに交換したりする必要がない。その結果、ユーザによる設計の自由度を高めることができる。

本実施の形態に従う制御システム１においては、サポート装置３００が異常検知機能の実装に適した設定を自動的に提案するので、専門知識の乏しいユーザであっても、任意の異常検知機能を実装できる。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１ 制御システム、２ ＰＬＣ、４，６ フィールドネットワーク、８ 制御ネットワーク、１０ 制御装置、１２ リモートＩ／Ｏ装置、１４ リレー、３０ 処理リソース、３２ 状態値収集処理、３４ 異常検知処理、５０ 制御タスク、５２ 異常検知タスク、１００ 制御ユニット、１０２，２０２，３０２ プロセッサ、１０４，２０４ チップセット、１０６，２０６，３０６ 主記憶装置、１０８，２０８，３０８ 二次記憶装置、１１２，３１２ ＵＳＢコントローラ、１１４，２１４ メモリカードインターフェイス、１１５，２１５ メモリカード、１１６，１１８ ネットワークコントローラ、１２０，２２０ 内部バスコントローラ、１２２ 内部バス、１４０ 特徴抽出部、１４４ 機械学習処理部、１４６ 結果判定部、１５０ 特徴量、１５２ 学習モデル、１５４ スコア、１５６ 判定条件、１５８ 設定情報、１６０ 変数管理部、１６２ デバイス変数、１７０ 判定結果、１８０ 状態値収集、１８２ スコア算出、１８４ 判定、２００ 補助処理ユニット、２５０ Ｉ／Ｏユニット、３００ サポート装置、３０４ ドライブ、３０５ 記憶媒体、３１４ ローカルネットワークコントローラ、３１６ 入力部、３１８ 表示部、３２０ バス、３４０ サポートプログラム、３５０ 開発ツール、３６０ 設定ツール、４００，４０２ ユーザインターフェイス画面、４１０ システム構成、４１２，４１４，４１６ 使用率、４１８ アイコン、４２０ 実行時間表示、４３０，４３２ ボタン。

Claims (10)

1. 制御対象を制御するための制御システムであって、
   演算処理を実行可能な複数の処理リソースを備え、
   前記複数の処理リソースは、
   前記制御対象に含まれる任意の検知対象に対応する１または複数の状態値を収集する収集手段と、
   前記収集された１または複数の状態値から算出された特徴量に基づいて、前記検知対象に異常が発生している可能性を示す値を算出する異常検知手段とを備え、
   前記収集手段および前記異常検知手段は、同一の処理リソースおよび異なる処理リソースのいずれにも配置可能である、制御システム。
2. 前記異常検知手段は、前記検知対象に異常が発生している可能性を示す値に基づいて、前記検知対象に異常が発生しているか否かを示す判定結果を生成する、請求項１に記載の制御システム。
3. 前記収集手段および前記異常検知手段が異なる処理リソースに配置されている場合において、前記異常検知手段は、前記生成された判定結果を前記収集手段が配置された処理リソースへ送信する、請求項２に記載の制御システム。
4. 前記収集手段および前記異常検知手段が異なる処理リソースに配置されている場合において、前記収集手段は、前記収集された１または複数の状態値を前記異常検知手段が配置された処理リソースへ送信する、請求項１～３のいずれか１項に記載の制御システム。
5. 前記収集手段および前記異常検知手段が異なる処理リソースに配置されている場合において、前記異常検知手段は、前記算出された検知対象に異常が発生している可能性を示す値を前記収集手段が配置された処理リソースへ送信する、請求項１～４のいずれか１項に記載の制御システム。
6. 前記収集手段および前記異常検知手段の配置先となる処理リソースの決定を支援するためのサポート装置をさらに備える、請求項１～５のいずれか１項に記載の制御システム。
7. 前記サポート装置は、前記収集手段が収集すべき状態値の数、状態値の収集先、前記複数の処理リソースのスペック、内部バスの負荷率、および、ネットワークの負荷率の少なくとも一つに基づいて、前記収集手段および前記異常検知手段の配置先を決定する、請求項６に記載の制御システム。
8. 前記サポート装置は、前記収集手段および前記異常検知手段が配置されるべき処理リソースに対して、必要なデータを送信する、請求項６または７に記載の制御システム。
9. 制御対象を制御するための制御システムで用いられるサポート装置であって、
   前記制御システムは、演算処理を実行可能な複数の処理リソースを備えており、
   前記複数の処理リソースは、
   前記制御対象に含まれる任意の検知対象に対応する１または複数の状態値を収集する収集手段と、
   前記収集された１または複数の状態値から算出された特徴量に基づいて、前記検知対象に異常が発生している可能性を示す値を算出する異常検知手段とを備え、
   前記サポート装置は、前記収集手段および前記異常検知手段の配置先となる処理リソースの決定を支援するためのユーザインターフェイスを提供し、
   前記ユーザインターフェイスを介したユーザ指示に従って、前記収集手段および前記異常検知手段は、同一の処理リソースおよび異なる処理リソースのいずれにも配置可能である、サポート装置。
10. 制御対象を制御するための制御システムで用いられるサポート装置を実現するためのサポートプログラムであって、
    前記制御システムは、演算処理を実行可能な複数の処理リソースを備えており、
    前記複数の処理リソースは、
    前記制御対象に含まれる任意の検知対象に対応する１または複数の状態値を収集する収集手段と、
    前記収集された１または複数の状態値から算出された特徴量に基づいて、前記検知対象に異常が発生している可能性を示す値を算出する異常検知手段とを備え、
    前記サポートプログラムは、コンピュータに、前記収集手段および前記異常検知手段の配置先となる処理リソースの決定を支援するためのユーザインターフェイスを提供する機能を実現させ、
    前記ユーザインターフェイスを介したユーザ指示に従って、前記収集手段および前記異常検知手段は、同一の処理リソースおよび異なる処理リソースのいずれにも配置可能である、サポートプログラム。

Images