JP7473890B2

JP7473890B2 - 制御状態監視システムおよびプログラム

Info

Publication number: JP7473890B2
Application number: JP2019139766A
Authority: JP
Inventors: 鐵兵中野; 哲司小川; 哲則小林
Original assignee: Waseda University
Current assignee: Waseda University
Priority date: 2019-07-30
Filing date: 2019-07-30
Publication date: 2024-04-24
Anticipated expiration: 2039-07-30
Also published as: JP2021022290A

Description

本発明は、動作部およびこの動作部を制御する制御部を有する機器の動作制御の状態を監視する制御状態監視システムおよびプログラムに係り、例えば、交流電源を動力源として稼働する電気機器の動作制御の状態を監視する場合等に利用できる。

従来、動作制御が行われる機器では、様々な手法で動作制御の状態についての異常検知が行われている。例えば、学習段階で、基準とするデータ群（正常時動作データ）の正規分布を作成してこれを基準データとし、運用段階で取得したデータ（観測時動作データ）が基準データの正規分布から外れているか否かを確認する異常判定システムが知られている（特許文献１参照）。

この特許文献１に記載された異常判定システムでは、正規分布の端にデータ異常判定用の閾値を設定し、観測時動作データが正規分布中心（平均値、期待値）に対してその閾値よりも離れていることを確認する。この際、モータに入力するトルク、およびモータの出力速度の２種類の時系列データを取得し、これらの複数種類の動作データのそれぞれについてデータ異常を判定する。そして、観測した波形から変化を検出する手法として、統計学的手法であるホテリングのＴ二乗法に基づく機械学習を採用している。また、特許文献１には、トルクは、位置／速度制御の場合、モータ駆動機械側の反力の影響も反映されるため、継続して観測することで経年変化などの動作異常を捉えることが可能である旨の記載がある。さらに、特許文献１には、基準データは、全て正常であると確信できる正常時動作データに基づいて作成される旨の記載がある。

また、本発明では、オートエンコーダを利用することができるが、オートエンコーダを用いたシステムとしては、異常の原因を効果的に特定することができる異常診断装置が知られている（特許文献２参照）。

さらに、本発明で利用することができるベクトル化技術として、例えば、ｉ－ｖｅｃｔｏｒに関する技術が知られている（非特許文献１参照）。

特開２０１９－７９４５２号公報（段落［００４１］、［００４４］～［００４７］）特開２０１９－６１５６５号公報（請求項２、図７）

福地佑介、俵直弘、小川哲司、小林哲則、"ｉ－ｖｅｃｔｏｒに基づく発話類似度を用いた非負値行列分解と話者クラスタリングへの適用"、情報処理学会研究報告、２０１２年７月２０日、Ｖｏｌ．２０１２－ＳＬＰ－９２、Ｎｏ．８

機器の動作制御の状態についての異常検知を自動で行う場合、制御状態監視システムを構築し、維持管理するシステム管理者が必要となる。一般に、機器が開発され、その製品ライフサイクルを終えるまでの間に、例えば、メーカ、販売業者、保守・点検業者、エンドユーザ（機器を使用して事業を行う運用事業者や、家庭内で機器を使用する者等）、廃棄物処理業者のように、様々な立場の者が機器に関与することになる。制御状態監視システムについては、これらの機器に関与する者のうちのいずれかがシステム管理者になる場合と、専門業者がシステム管理者になる場合とがあるが、後者の場合でも、制御状態監視システムの構築に必要となる機器の状態データを収集するために、いずれかが協力者となる必要がある。異常検知を自動で行うには、事前に機械学習を行ってモデルを作成しておかなければならず、機械学習を行うには、学習用データとして、動作制御中の機器についての多くの状態データが必要だからである。

この際、新製品であれば、製品リリース前にメーカやその代行業者が機器の試験運転を行うことにより、正常な動作制御が行われている機器について多数の状態データを取得し、それを学習用データとして初期モデルを構築することになる。従って、メーカ自身がシステム管理者になる場合は、必要な状態データの取得に障害はなく、また、専門業者がシステム管理者になる場合でも、メーカから状態データの提供があれば、初期モデルを構築することができる。

一方、機械学習で得られたモデルは、初期モデルのまま使用され続ける場合もあるが、システムの性能向上を図るため、モデルの更新を行う場合も多く、モデルの更新を行うには、学習用データとして新たな状態データが必要となる。しかし、製品リリース前とは異なり、再学習のための状態データの取得が困難なケースもある。前述したように、機器が製造され、販売され、使用され、そして、廃棄されるまでの間に、機器は、様々な立場の者の管理下に置かれることになる。また、機器の種別毎に経年変化のスピードや程度に差はあるものの、いずれの機器についても、経年劣化は生じるといってよい。従って、機器を管理する者の立場や、経年劣化があることにより、再学習のための状態データの取得が困難になる事情が生じ得ることになる。例えば、エンドユーザ、販売業者、保守・点検業者が、機器の管理責任を負っている場合には、機器のメンテナンス、部品交換、全体的な入れ替えのタイミングの遅延等、様々な事情により状態データの提供を避けたいケースがある。また、メーカであれば、同業他社に詳しい製品データが流れることを警戒するケースがある。従って、このような事情から、モデルの更新を行うことができず、制御状態監視システムの性能向上を図ることが困難な場合がある。

このため、機器がどのような立場の者の管理下に置かれている状況下であっても、また、どのような経年劣化が生じる場合であっても、制御状態監視システムの性能向上を容易に図ることができれば便利であり、それを実現可能なシステム構成を有する制御状態監視システムの開発が望まれる。

なお、前述した特許文献１，２では、経年劣化への言及があり、また、異常の原因を効果的に特定する旨の記載があるが、上述したような学習用データの入手の困難性に対応可能な構成を備えているわけではない。

本発明の目的は、柔軟なモデルの更新や追加が可能であり、システムの性能向上を容易に図ることができる制御状態監視システムおよびプログラムを提供するところにある。

＜発明の基本構成＞

本発明は、動作部およびこの動作部を制御する制御部を有する機器の動作制御の状態を監視する制御状態監視システムであって、
制御部から送出されて動作部へ入力される制御信号、この制御信号以外で動作部へ入力される外部入力データ、動作部から制御部に向けて出力される制御用のフィードバック信号またはその他の内部観測データ、この内部観測データ以外の観測データを得るために設置された状態監視用センサから出力される外部観測データのうちの少なくとも１つの状態データから作成されたパターン認識用の入力データを用いて、制御実行中の動作部の実際の動作状態が、制御の目的動作を示す状態になっているか否かまたは制御の達成度を示すデータを出力するパターン認識処理を実行し、このパターン認識処理で得られる特徴データを抽出する処理を繰り返し実行する状態推定器と、
この状態推定器により抽出した特徴データを用いて、クラス識別処理、外れ値検知処理、新規性検知処理のうちの少なくとも１つの処理を実行し、動作制御の異常の有無または程度を示すスコアを出力する処理を実行する異常検知器と
を備えたことを特徴とするものである。

ここで、「機器」には、例えば、産業用機器、家庭用機器、車載機器、航空・宇宙機器、船舶機器、医療機器、プラント機器等、大小や用途を問わず、各種の機器が含まれる。また、電気機器に限らず、動作部を駆動する動力源は任意であり、例えば、蒸気膨張エネルギで駆動するエアコンプレッサ等でもよい。なお、電気機器に限らないというのは、動作部の動力として電気を使う機器に限らないという意味であるから、信号の送受信（ネットワーク上へのデータ送信を含む）で電気を使わないという意味ではない。

また、「…制御信号、…外部入力データ、…内部観測データ、…外部観測データのうちの少なくとも１つの状態データから作成されたパターン認識用の入力データ」の「作成」というのは、少なくとも１つの状態データを用いて、前段の状態推定器の処理（パターン認識器によるパターン認識処理）が可能となる入力データ、つまりパターン認識を行うのに十分な情報量の入力データを用意するという意味であり、具体的には、例えば、周波数分析等の前処理や、２以上の状態データを組み合わせることを指すが、必ずしも周波数分析等の前処理や、２以上の状態データを組み合わせることが必要になるという意味ではない。従って、使用するパターン認識器の構造、つまり実行されるパターン認識処理の内容に応じ、入力データを用意することになり、例えば、内部メモリを有する構造により時系列パターン認識処理を行う場合には、時系列の複数の入力データで必要な情報量が得られればよいので、ある１時点での入力データの情報量は少なくてもよい場合があるが、この点については、詳細は後述する。

さらに、「目的動作」とは、例えば、１００回転での運転、５０回転での運転等のように、主として定常状態を示す動作であるが、状態の特徴を捉えることができれば、例えば、９０回転から１００回転への移行制御中の運転等のように、過渡状態を示す動作を、目的動作としてもよい。

そして、「状態推定器」における「パターン認識処理」としては、例えば、ニューラル・ネットワークを採用することができ、特に、畳み込み・ニューラル・ネットワーク（ＣＮＮ）が好適であるが、その他に、例えば、隠れマルコフモデル（ＨＭＭ）、サポート・ベクター・マシン（ＳＶＭ）、ベイジアン・ネットワーク等を採用することができる。

＜発明の基本構成から得られる作用・効果＞

このような本発明の制御状態監視システムにおいては、前段の状態推定器で、機器から取得した状態データを用いてパターン認識処理を実行し、このパターン認識処理で得られる特徴データを抽出し、抽出した特徴データを用いて、後段の異常検知器で、クラス識別処理、外れ値検知処理、新規性検知処理のうちの少なくとも１つの処理を実行し、動作制御の異常の有無または程度を示すスコアを出力する。このため、前段の状態推定器を構成する状態推定モデルと、後段の異常検知器を構成する異常検知モデルとを独立して管理することが可能となる。

より具体的には、後段の異常検知モデルの更新を、前段の状態推定モデルの更新から切り離すことができるので、前段の状態推定モデルを更新しなくても、後段の異常検知モデルを更新することや、後段の異常検知モデルを追加することが可能となる。

すなわち、前段の状態推定モデルの更新では、学習用データとして状態データが必要となるが、後段の異常検知モデルの更新では、前段の状態推定モデルを用いたパターン認識処理で得られた特徴データがあれば、状態データが無くても、学習を行うことができる。このため、状態データの収集が困難な場合でも、異常検知モデルの更新を行い、システムの性能向上を図ることが可能となる。

前述したように、機器は、様々な立場の者の管理下に置かれる可能性があり、そこには様々な事情が存在する。状態データが、機器から直接に得られるデータ（センサデータ等）であるのに対し、特徴データは、それだけでは何を意味するのか判らないデータであるため、機器の管理者にとっては、状態データの提供が困難な場合であっても、特徴データの提供は可能な場合がある。従って、異常検知モデルの学習用データである特徴データの収集は、状態データの収集に比べて容易であり、これは、本発明が２段階の処理を行う構成を備えていることに基づくものである。

また、後段の異常検知モデルは、特徴データがあれば、状態データが無くても、学習を行うことができるので、前段の状態推定モデルをそのまま変えることなく、新たな異常検知モデルを追加することが可能となる。このため、前段の状態推定モデルが変わっていなくても、その状態推定モデルを用いたパターン認識処理で新たな状態を捉えた特徴データが得られれば、その特徴データを用いた学習を行うことにより新たな異常検知モデルを作成することができ、その異常検知モデルの追加により、新たな観点でのクラス識別処理、外れ値検知処理、または新規性検知処理を行うことが可能となり、異常検知の幅（異常検知処理で判定できる内容の幅）を広げることが可能となる。この際、状態データの収集が困難な場合でも、異常検知モデルの追加を行うことができるというのは、上述した異常検知モデルの更新の場合と同様である。

さらに、異常検知モデルの追加が可能なことからも明らかであるが、前段の状態推定モデルと、後段の異常検知モデルとは、１対１の対応関係である必要はなく、１対多でもよい。つまり、１つの状態推定モデルによるパターン認識処理で得られた特徴データは、複数の異常検知モデルによる処理で使用することができる。勿論、１対１の対応関係であってもよい。また、１対多の対応関係は、前段の状態推定モデルおよび後段の異常検知モデルの双方が初期モデルの時期に形成されていてもよく、後からの異常検知モデルの追加により、形成されてもよい。さらに、前段の状態推定モデルが複数用意されていてもよく、この場合、モデルの数だけ見れば、多対多になるが、ある１つの前段の状態推定モデルから見ると、後段の複数の異常検知モデルが対応していてもよいのに対し、ある１つの後段の異常検知モデルから見ると、その後段の異常検知モデルに対応する前段の状態推定モデルは１つである。これは、ある１つの後段の異常検知モデルを学習する際には、ある１つの前段の状態推定モデルによるパターン認識処理で得られた特徴データを用いた学習を行うので、学習に用いた特徴データを抽出した状態推定モデルが、後段の異常検知モデルに対応する前段の状態推定モデルとなり、運用時にも、対応する状態推定モデルで得られた特徴データを、対応する異常検知モデルに入力することになるからである。

なお、前段の状態推定モデルを更新した場合には、更新後の状態推定モデルによるパターン認識処理で得られる特徴データは、更新前とは異なるものとなるので、原則的には、対応する後段の異常検知モデルも更新する。後段の異常検知モデルは、更新前の状態推定モデルによるパターン認識処理で得られた特徴データで学習を行っているので、そのような後段の異常検知モデルに、更新後の状態推定モデルによるパターン認識処理で得られる特徴データを入力しても、適切な異常検知を行うことができないからである。

そして、本発明では、製品の製造・検査時の観測情報を用いて学習することで、個体差（同型の異なる機器同士の差）や設置環境の相違を吸収した頑健な状態推定モデルを構築することが可能である。加えて、前段の状態推定モデルを変えることなく、後段の異常検知モデルの更新や追加を行うことができるので、個体差や設置環境の影響が大きい機器の場合には、前段の状態推定器で、グルーバルな状態推定モデルを事前に用意しておき、その後、後段の異常検知器で、実働環境下での比較的少量の学習用の特徴データ（但し、比較的少量といっても、運用時に異常検知結果を１回出力するのに用いられる特徴データの個数よりは多い。）を用いたモデルの適応技術により、一部の機器の状況や設置環境に依存した異常検知モデルの構築を行うことができる。

すなわち、特定の状況下で得られた特徴データを用いた学習により、特定の状況下に置かれた機器にだけ適用可能な、または適用する意義のある異常検知モデルを構築し、運用時には、機器が当該特定の状況下にあることが既知であることを前提として、その異常検知モデルを用いるか、あるいは、機器が当該特定の状況下にあることを仮定した状態で、その異常検知モデルを用いて異常検知を行うことができる。後者の特定の状況下にあることを仮定した状態というのは、例えば「もし機器が、～という状況に置かれていた場合には、～である可能性が高い。」等のような条件付きの異常検知結果を出力する場合である。このような一部の機器の状況や設置環境に依存した異常検知モデルの構築は、前述したように、前段の状態推定モデルと、後段の異常検知モデルとが、１対多の対応関係を許容することから可能になる。

より具体的には、特定の状況には、様々な状況があり、例えば、標高を閾値として機器が高地または低地に設置されている場合を区別して学習すると、外気圧の高低に依存する異常検知モデルを構築することができる。また、機器が高緯度または低緯度の地方に設置されている場合を区別して学習すると、外気温の平均値の高低に依存する異常検知モデルを構築することができる。冬と夏といった季節の差でも同じである。さらに、雨の日、晴れの日の区別や、湿度の高低の差でもよい。その他に、海辺に設置されているか否かの区別で、塩害の影響を考慮した異常検知モデルを構築することができる。また、同型の機器でも、機器を使用するエンドユーザの業種の相違により、使用方法が異なる場合もあるので、エンドユーザの業種に依存する異常検知モデルを構築してもよい。自動車・電車・飛行機・船舶等の移動体に設置されて使用されるのか、固定した場所に設置されて使用されるかの区別により、振動の影響を考慮した異常検知モデルを構築してもよい。

さらに、機器で実際に発生する状態の頻度の高低とは無関係に、従って、たとえ発生頻度の低い状態であっても、その状態を示す学習用データである特徴データが得られれば、その状態を識別可能な異常検知モデルを構築することができる。そして、機器の設置環境の改善や、機器の改良（型番が変わる程の大きな改良ではなく、マイナーチェンジ）等により、そのような発生頻度の低い状態を識別可能な異常検知モデルが不要になった場合には、後から異常検知モデルを削除することもできる。削除しても前段の状態推定モデルに変化はなく、それに対応する後段の異常検知モデルの数が少なくなるだけであるから、システムは正常に機能することになる。このように異常検知モデルの削除を行うことができることも、前段の状態推定モデルと、後段の異常検知モデルとが、１対多の対応関係を許容することから可能になる。

また、本発明は、正常状態にある状態データや特徴データだけで学習を行うことができ、異常状態にある状態データや特徴データを学習用データに含める必要がなく、この点は、前述した特許文献１に記載された異常判定システムと同様である。但し、異常状態にある状態データや特徴データを用いて学習を行ってもよい。さらに、以上の説明では、主として本発明が２段階の処理を行う構成を備えていることから得られる作用・効果を述べたが、異常検知を機械学習で自動化したことによる作用・効果も、従来のシステムの場合と同様に得ることができ、これらにより前記目的が達成される。

＜状態推定器への入力データに、電源の電圧および／または電流の波形データ等を含める構成＞

また、前述した制御状態監視システムにおいて、
状態推定器に入力する入力データには、
外部入力データまたは外部観測データ若しくは内部観測データとしての電源の電圧および／または電流の波形データ若しくはこれらの波形データを周波数分析して得られた各周波数帯域の成分値が含まれることが望ましい。

ここで、「電源の電圧および／または電流の波形データ」には、交流電源の電圧および／または電流の波形データに限らず、直流電源の電圧および／または電流の波形データも含まれる。また、業務用電源（業務用機器や産業用機器に用いる電源）、家庭用電源（家電製品等の家庭用機器に用いる電源）の別は問わない。従って、交流電源の場合には、三相交流電源（Ｒ相、Ｓ相、Ｔ相）でもよく、単相交流電源でもよく、相の数は問わない。さらに、「電源の電圧および／または電流」というのは、電源によってもたらされた電圧や電流という意味であるから、それらの値を計測するのは、電源側に帰属する装置でもよく、機器側（負荷側）に帰属する装置でもよく、機器側におけるいずれの負荷部分でもよいので、「外部入力データまたは外部観測データ若しくは内部観測データとしての電源の…」としている。

このように状態推定器への入力データに、電源の電圧および／または電流の波形データ等を含める構成とした場合には、機器の負荷（交流の場合のインピーダンスや、直流の場合の抵抗）、負荷力率、ノイズとして発生するリップル電流（電流の中に含まれている脈動の成分）等の変化を捉え、異常検知を行うことが可能となる。機器の異常時には、その影響が負荷（インピーダンス、抵抗）、力率、リップル電流等の変化として観測可能であると考えられるので、その微小な変化を捉えるために、電源の電圧および／または電流の波形データ若しくはこれらの波形データを周波数分析して得られた各周波数帯域の成分値を特徴量として用いるものである。

＜ニューラル・ネットワークの中間層出力を抽出する構成＞

さらに、前述した制御状態監視システムにおいて、
状態推定器は、
ニューラル・ネットワークによるパターン認識処理を実行し、特徴データとして、少なくとも１つの目的動作に対応する少なくとも１組の出力ノードに至る中間層の出力データを抽出する処理を実行する構成としてもよい。

ここで、「ニューラル・ネットワーク」としては、例えば、畳み込み・ニューラル・ネットワーク（ＣＮＮ）等を好適に採用することができる。

また、「出力ノード」は、ニューラル・ネットワークの最終層である出力層を構成するノードである。そして、「少なくとも１つの目的動作に対応する少なくとも１組の出力ノードに至る中間層」における１番目の「少なくとも１つの」は、目的動作が１つしかない機器と、複数の目的動作を有する機器とがあることを考慮し、２番目の「少なくとも１組の」は、１つの目的動作について１組の出力ノードしか設けられない場合と、複数組の出力ノードが設けられる場合とがあることを考慮して記載されている。複数組の出力ノードの「組」というのは、２クラス識別であれば２つの出力ノードであり、Ｎクラス識別（Ｎは３以上）であればＮ個の出力ノードのことであり、１つのシングルタスクの各出力ノードは、ここでいう１組の出力ノードであり、マルチタスクにおける１つのタスク部分も、ここでいう１組の出力ノードであり、このような１組の出力ノードから見た場合、それらに至るネットワークは共有であるので、そのような単位を「組」としている。従って、「少なくとも１つの目的動作に対応する少なくとも１組の出力ノードに至る中間層」というのは、目的動作が１つしかない機器であり、かつ、対応する出力ノードが１組しか設けられていない場合は、その目的動作については、中間層の出力データを抽出することを意味する。一方、複数の目的動作を有する機器の場合は、全部の目的動作について、中間層の出力データを抽出してもよいが、一部の目的動作だけについて、中間層の出力データを抽出してもよく、例えば、目的動作Ｘ，Ｙについては、中間層の出力データを抽出し、目的動作Ｚについては、出力層（最終層）の出力データを抽出してもよい。また、任意の１つの目的動作について複数組の出力ノードが設けられている場合には、全部の組の出力ノードについて、それらの組の出力ノードに至る中間層を抽出してもよく、一部の組の出力ノードについてだけ、それらの組の出力ノードに至る中間層を抽出してもよい。

さらに、抽出する「中間層」は、１層に限らず、複数層としてもよい。すなわち、中間層を複数層抽出し、それらの複数層の中間層出力をまとめて特徴データとして後段の異常検知器に入力するようにしてもよい。なお、ここでいう複数層の中間層とは、同一の出力ノードに至るネットワークから抽出した複数層の中間層という意味であり、例えば、目的動作Ｘに対応する出力ノードに至るネットワークにおいて、出力層（最終層）から２つ前の中間層と、４つ前の中間層とを抽出し、両方とも特徴データとして使用するといった意味である。従って、例えば、目的動作Ｘに対応する出力ノードに至る中間層については、２つ前の中間層を抽出し、目的動作Ｙに対応する出力ノードに至る中間層については、４つ前の中間層を抽出するというような意味ではなく、このような抽出は、それぞれの目的動作から見れば、１層の中間層を抽出していることになる。

このようにニューラル・ネットワークの中間層出力を抽出する構成とした場合には、最終層（出力層）出力を抽出する場合に比べ、特徴データを用いた処理を行う後段の異常検知器に対し、その後段の処理に有効な情報を特徴データとして入力することが可能となる。すなわち、最終層（出力層）の出力データは、制御実行中の動作部の実際の動作状態が、制御の目的動作を示す状態になっているか否かまたは制御の達成度を示すだけのデータであり、情報量が少なく、後段の処理で利用可能な情報が欠落している場合があるので、ニューラル・ネットワークの入力層に入力される状態データ（非常に多くの情報量）から、最終層（出力層）の出力データ（かなり絞り込まれた情報量）に至るまでのネットワーク上に存在する中間的な情報量を抽出し、後段の処理で利用することが可能となる。また、最終層（出力層）の出力データは、情報量が少ないので、その判別結果が誤っていた場合には、後段の処理に与える影響が大きいが、中間層出力を後段の処理で利用すれば、影響を小さくすることが可能となる。

＜人為的に作り出された機器の故障の原因となり得る動作環境下での状態データを用いて作成された、動作環境の識別が可能な状態推定モデルを記憶する構成＞

また、前述した制御状態監視システムにおいて、
状態推定器を構成する状態推定モデル記憶手段は、
人為的に作り出された機器の故障の原因となり得る少なくとも１つの動作環境を含む複数の動作環境下での状態データの各集合およびこれらの各集合に付されるタグ情報を用意し、用意した状態データの各集合および各集合のタグ情報を用いて学習処理を実行することにより作成された動作環境の識別が可能な状態推定モデルを記憶する構成としてもよい。

ここで、「人為的に作り出された機器の故障の原因となり得る少なくとも１つの動作環境を含む複数の動作環境」の「含む」とは、複数の動作環境の中に、人為的に作り出された機器の故障の原因となり得る動作環境でない動作環境（例えば、オイルが汚れていない動作環境や、ボルトが１つも外れていない動作環境等）が存在することを示している。

また、「人為的に作り出された機器の故障の原因となり得る少なくとも１つの動作環境」であるから、人為的に作り出された機器の故障の原因となり得る動作環境は、１つでもよく、２以上でもよい。なお、人為的に作り出された機器の故障の原因となり得る動作環境がゼロの場合は、健全な動作環境下での状態データだけを用いて状態推定モデルを学習するということである。

このように人為的に作り出された機器の故障の原因となり得る動作環境下での状態データを用いて作成された、動作環境の識別が可能な状態推定モデルを記憶する構成とした場合には、初期モデル構築時における学習用データを得るために、通常その時点では自然に形成されることのない動作環境を積極的に作り出し、そのような積極的に作り出した動作環境下での状態データを学習用データとして用いて、通常は初期モデルとして構築することができないような状態推定モデルを作成することが可能となる。換言すれば、長期間の機器の使用によって偶発的に生じ得るような動作環境下での状態データを意図的に用意し、そのような特殊な環境の識別が可能な状態推定モデルを作成することが可能となる。

但し、上記の説明では、初期モデルの構築時において特殊な動作環境を人為的に作り出すことに言及しているが、状態推定モデルの更新時において、そのような特殊な動作環境を人為的に作り出してもよい。また、新製品である機器のリリース後、時間が経過すると、人為的に作り出していた特殊な動作環境が、実際に発生する場合があり、そのような実際に発生した動作環境（機器の故障の原因となり得る動作環境）下での状態データを収集することができ、かつ、その状態データにタグ情報（そういう動作環境下で収集した状態データであるというタグ情報）を付すことができる場合には、その状態データを用いて、状態推定モデルの更新のための学習を行ってもよい。

＜人為的に作り出された機器の故障の原因となり得る動作環境下での特徴データを用いて作成された、動作環境の識別が可能な異常検知モデルを記憶する構成＞

さらに、前述した制御状態監視システムにおいて、
異常検知器を構成する異常検知モデル記憶手段は、
人為的に作り出された機器の故障の原因となり得る少なくとも１つの動作環境を含む複数の動作環境下での特徴データの各集合およびこれらの各集合に付されるタグ情報を用意し、用意した特徴データの各集合および各集合のタグ情報を用いて学習処理を実行することにより作成された動作環境の識別が可能な異常検知モデルを記憶する構成としてもよい。

ここで、「人為的に作り出された機器の故障の原因となり得る少なくとも１つの動作環境を含む複数の動作環境」における「含む」や「少なくとも１つの」の意味は、前述した動作環境の識別が可能な状態推定モデルの場合と同様である。

このように人為的に作り出された機器の故障の原因となり得る動作環境下での特徴データを用いて作成された、動作環境の識別が可能な異常検知モデルを記憶する構成とした場合には、前述した動作環境の識別が可能な状態推定モデルの場合と同様な作用・効果が得られる。この際、前述した動作環境の識別が可能な状態推定モデルの場合における「状態データ」を「特徴データ」に置き換え、「状態推定モデル」を「異常検知モデル」に置き換えればよい。

また、前段の状態推定器に、動作環境の識別が可能な状態推定モデルが設けられ、かつ、後段の異常検知器にも、動作環境の識別が可能な異常検知モデルが設けられた構成としてもよい。

＜故障発生の予兆の有無を識別可能な状態推定モデルを記憶する構成＞

また、前述した制御状態監視システムにおいて、
状態推定器を構成する状態推定モデル記憶手段は、
累積稼働回数または累積稼働時間が予め定められた第１の範囲内で故障した機器および故障しなかった機器について、第１の範囲よりも累積稼働回数または累積稼働時間が少ない予め定められた第２の範囲内の状態データの各集合およびこれらの各集合に付されるタグ情報を用意し、用意した状態データの各集合および各集合のタグ情報を用いて学習処理を実行することにより作成された第１の範囲内での故障発生の予兆の有無を識別可能な状態推定モデルを記憶する構成としてもよい。

ここで、「累積稼働回数または累積稼働時間」は、機器の実稼働により機器にかかった累積的な負荷の指標値（指標情報）であるが、「～回、～年、～ヶ月、～日、～時間、～分、～秒」等といった単位の数量に限定されるものではなく、回数や時間に換算（疑似的な換算を含む）することができる数量や情報であれば、ここでいう「累積稼働回数または累積稼働時間」に含まれる。例えば、燃料の累積使用量は、「～リットル」等の単位であるが、対応関係を定めれば、回数や時間に換算できる数量である。また、残量（例えば、燃料の残量、印刷機であれば、トナーやインクの残量等）は、満タンの量から引けば、使用量となり、さらに、それまでに満タンにした回数を考慮すると、累積使用量が算出されるので、「累積稼働回数または累積稼働時間」に換算することができる。また、使用を重ねるに従って色の濃度が薄くなる場合の濃度（色の変化の程度）や、臭いが消えていく場合の臭い等のインジケータも、回数や時間に換算することができる指標情報である。

また、「第２の範囲」は、第１の範囲よりも前の時期であればよいので、第１の範囲と連続していてもよく、稼働開始直後を含んでいてもよい。

このように故障発生の予兆の有無を識別可能な状態推定モデルを記憶する構成とした場合には、実稼働で実際に故障が発生したときに、その故障発生時よりも前の時期に出現していた状態データの変化を学習しておくことができるので、運用時に、故障発生の予兆の有無を判定することが可能となる。

なお、実稼働で実際に故障が発生しないと必要な学習用データである状態データが得られないので、通常は、状態推定器に、最初からこのような故障発生の予兆の有無を識別可能な状態推定モデルを設けておくことは困難であるが、例えば、新製品をリリースしてから暫く時間が経過した後に、本発明の制御状態監視システムを構築する場合には、既に必要な学習用データが存在することもあるので、初期モデルとして、このような故障発生の予兆の有無を識別可能な状態推定モデルを設けることができる。また、新製品のリリース前に、長期間の試験運転期間を設け、その試験運転期間中に故障が発生すれば、新製品のリリース前に、必要な学習用データを得ることができるので、この場合も同様に、初期モデルとして、故障発生の予兆の有無を識別可能な状態推定モデルを設けることができる。

＜故障発生の予兆の有無を識別可能な異常検知モデルを記憶する構成＞

さらに、前述した制御状態監視システムにおいて、
異常検知器を構成する異常検知モデル記憶手段は、
累積稼働回数または累積稼働時間が予め定められた第１の範囲内で故障した機器および故障しなかった機器について、第１の範囲よりも累積稼働回数または累積稼働時間が少ない予め定められた第２の範囲内の特徴データの各集合およびこれらの各集合に付されるタグ情報を用意し、用意した特徴データの各集合および各集合のタグ情報を用いて学習処理を実行することにより作成された第１の範囲内での故障発生の予兆の有無を識別可能な異常検知モデルを記憶する構成としてもよい。

ここで、「累積稼働回数または累積稼働時間」、「第１の範囲」および「第２の範囲」の意味は、前述した故障発生の予兆の有無を識別可能な状態推定モデルの場合と同様である。

このように故障発生の予兆の有無を識別可能な異常検知モデルを記憶する構成とした場合には、実稼働で実際に故障が発生したときに、その故障発生時よりも前の時期に出現していた特徴データの変化を学習しておくことができるので、運用時に、故障発生の予兆の有無を判定することが可能となる。

また、前段の状態推定器に、故障発生の予兆の有無を識別可能な状態推定モデルが設けられ、かつ、後段の異常検知器にも、故障発生の予兆の有無を識別可能な異常検知モデルが設けられた構成としてもよい。

なお、実稼働で実際に故障が発生しないと必要な学習用データである特徴データが得られないので、前述した状態推定器の場合と同様に、通常は、異常検知器に、最初からこのような故障発生の予兆の有無を識別可能な異常検知モデルを設けておくことは困難であるが、後からこのような異常検知モデルを追加することは、容易に行うことができる。

＜累積稼働回数または累積稼働時間の識別が可能な状態推定モデルを記憶する構成＞

また、前述した制御状態監視システムにおいて、
状態推定器を構成する状態推定モデル記憶手段は、
機器の累積稼働回数または累積稼働時間とともに収集された状態データを用いて、累積稼働回数または累積稼働時間で区分けされた状態データの各集合およびこれらの各集合に付されるタグ情報を用意し、用意した状態データの各集合および各集合のタグ情報を用いて学習処理を実行することにより作成された累積稼働回数または累積稼働時間の識別が可能な状態推定モデルを記憶する構成としてもよい。

ここで、「累積稼働回数または累積稼働時間」の意味は、前述した故障発生の予兆の有無を識別可能な状態推定モデルや異常検知モデルの場合と同様である。

このように累積稼働回数または累積稼働時間の識別が可能な状態推定モデルを記憶する構成とした場合には、機器の経年劣化の状態を捉えつつ、異常検知を行うことが可能となる。

なお、実稼働を長期間継続して経年劣化の状態を実際に作らないと必要な学習用データである状態データが得られないので、通常は、状態推定器に、最初からこのような累積稼働回数または累積稼働時間の識別が可能な状態推定モデルを設けておくことは困難であるが、例えば、新製品をリリースしてから暫く時間が経過した後に、本発明の制御状態監視システムを構築する場合には、既に必要な学習用データが存在することもあるので、初期モデルとして、このような累積稼働回数または累積稼働時間の識別が可能な状態推定モデルを設けることができる。

＜累積稼働回数または累積稼働時間の識別が可能な異常検知モデルを記憶する構成＞

さらに、前述した制御状態監視システムにおいて、
異常検知器を構成する異常検知モデル記憶手段は、
機器の累積稼働回数または累積稼働時間とともに収集された特徴データを用いて、累積稼働回数または累積稼働時間で区分けされた特徴データの各集合およびこれらの各集合に付されるタグ情報を用意し、用意した特徴データの各集合および各集合のタグ情報を用いて学習処理を実行することにより作成された累積稼働回数または累積稼働時間の識別が可能な異常検知モデルを記憶する構成としてもよい。

ここで、「累積稼働回数または累積稼働時間」の意味は、前述した累積稼働回数または累積稼働時間の識別が可能な状態推定モデルの場合と同様である。

このように累積稼働回数または累積稼働時間の識別が可能な異常検知モデルを記憶する構成とした場合には、機器の経年劣化の状態を捉えつつ、異常検知を行うことが可能となる。

なお、実稼働を長期間継続して経年劣化の状態を実際に作らないと必要な学習用データである特徴データが得られないので、前述した状態推定器の場合と同様に、通常は、異常検知器に、最初からこのような累積稼働回数または累積稼働時間の識別が可能な異常検知モデルを設けておくことは困難であるが、後からこのような異常検知モデルを追加することは、容易に行うことができる。

＜配電盤または分電盤と一体化された構成＞

そして、前述した制御状態監視システムにおいて、
状態監視用センサ、状態推定器に入力するパターン認識用の入力データを作成するための状態データを取得する処理を実行する状態データ取得手段、および状態推定器、またはこれらに加えて異常検知器は、動作部への給電を行う配電盤または分電盤と一体化されていてもよい。

ここで、「配電盤」には、商用電源から給電を受ける配電盤だけではなく、発電機や無停電電源装置等の電源供給システムの一部として設置される配電盤、あるいは電源供給システム自体である配電盤が含まれる。

このように配電盤または分電盤と一体化された構成とした場合には、本発明の制御状態監視システムと、機器に対して給電を行う装置とが一体化されるので、本発明の制御状態監視システムが、機器に対する給電装置としても機能するようになる。

また、状態監視用センサ（電流検出器（ＣＴ：Current Transformer）や電圧センサ）を、配電盤または分電盤に設けることで、機器に対する外部観測データの取得が容易になる。

さらに、配電盤または分電盤は、機器への給電を行うために、機器と配線で接続されるので、逆に機器から目的動作を示す情報を取得するための配線も容易になる。

そして、本発明の制御状態監視システムによる監視対象となる機器には、大型で大きな電力を必要とする機器も多く、その場合には、機器と、配電盤または分電盤とが有線で接続されていることが多いので、それと合わせて状態データの取得を有線で行うことが可能となる。

また、異常検知器については配電盤または分電盤と一体化せずに、接続装置およびネットワークを介して、配電盤または分電盤と、異常検知器とを接続する構成とした場合や、接続装置およびネットワークを介して、配電盤または分電盤と、状態データや特徴データを収集するデータ収集装置とを接続する構成とした場合は、接続装置に対する給電を問題なく行うことが可能となる。すなわち、ＩｏＴ（インターネット・オヴ・スィングス）のエッジデバイス等では消費電力が問題となることが多いのに対し、配電盤または分電盤から接続装置への給電が可能となるので、そのような問題が解消される。

さらに、大型機器の場合、配電盤や分電盤に専用の分岐（ブレーカおよびその先に繋がる端子台）が用意され、そこから負荷（すなわち機器）に給電用の配線が接続される。このため、分岐に流れる電流／電圧を観測することでその機器に対する入力電流／電圧の変化を容易に観測可能となる。従って、その機器の目的動作を示す情報を取得または入力して目的動作を既知の状態にすれば、既知の目的動作での動作制御についての異常検知が可能になる。

＜プログラムの発明＞

また、本発明のプログラムは、以上に述べた制御状態監視システムとして、コンピュータを機能させるためのものである。

なお、上記のプログラムまたはその一部は、例えば、光磁気ディスク（ＭＯ）、コンパクトディスク（ＣＤ）、デジタル・バーサタイル・ディスク（ＤＶＤ）、フレキシブルディスク（ＦＤ）、磁気テープ、読出し専用メモリ（ＲＯＭ）、電気的消去および書換可能な読出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）、フラッシュディスク等の記録媒体に記録して保存や流通等させることが可能であるとともに、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等の有線ネットワーク、あるいは無線通信ネットワーク、さらにはこれらの組合せ等の伝送媒体を用いて伝送することが可能であり、また、搬送波に載せて搬送することも可能である。さらに、上記のプログラムは、他のプログラムの一部分であってもよく、あるいは別個のプログラムと共に記録媒体に記録されていてもよい。

以上に述べたように本発明によれば、前段の状態推定器で、機器から取得した状態データを用いてパターン認識処理を実行し、このパターン認識処理で得られる特徴データを抽出し、抽出した特徴データを用いて、後段の異常検知器で、クラス識別処理、外れ値検知処理、新規性検知処理のうちの少なくとも１つの処理を実行し、動作制御の異常の有無または程度を示すスコアを出力するので、前段の状態推定器を構成する状態推定モデルと、後段の異常検知器を構成する異常検知モデルとを独立して管理することができるため、柔軟なモデルの更新や追加が可能であり、システムの性能向上を容易に図ることができるという効果がある。

本発明の第１実施形態の制御状態監視システムの全体構成図。第１実施形態の交流回路の電圧・電流の説明図。第１実施形態における状態データおよび特徴データの送信や保存の形態を示す構成図。第１実施形態において、動作環境、累積稼働回数・時間を考慮することなく、目的動作のみを考慮して制御状態の監視を行う場合で、かつ、前段の状態推定を１つのパターン認識器で行う場合（ケースＣ１－１）の構成図。第１実施形態において、動作環境、累積稼働回数・時間を考慮することなく、目的動作のみを考慮して制御状態の監視を行う場合で、かつ、前段の状態推定を複数のパターン認識器で行う場合（ケースＣ１－２）の構成図。第１実施形態の異常検知器（タイプ１）の構成図。第１実施形態の異常検知器（タイプ２）の構成図。第１実施形態の異常検知器（タイプ４）の構成図。第１実施形態の異常検知器（タイプ５）の構成図。第１実施形態の異常検知器（タイプ６）の構成図。本発明の第２実施形態において、目的動作に加え、動作環境を考慮するが、累積稼働回数・時間は考慮することなく制御状態の監視を行う場合で、かつ、前段の状態推定を１つのパターン認識器で行う場合（ケースＣ２－１）の構成図。第２実施形態において、目的動作に加え、動作環境を考慮するが、累積稼働回数・時間は考慮することなく制御状態の監視を行う場合で、かつ、前段の状態推定を細分化した複数のパターン認識器で行う場合（ケースＣ２－２）の構成図。第２実施形態において、目的動作に加え、動作環境を考慮するが、累積稼働回数・時間は考慮することなく制御状態の監視を行う場合で、かつ、前段の状態推定を適度な数に分散した複数のパターン認識器で行う場合（ケースＣ２－３）の構成図。本発明の第３実施形態における故障発生時期である第１の範囲とその予兆を捉える期間である第２の範囲との関係を示す説明図。第３実施形態において、目的動作に加え、動作環境を考慮するとともに、故障発生予兆の有無の判定を伴う制御状態の監視を行う場合で、かつ、前段の状態推定を１つのパターン認識器で行う場合（ケースＣ３－１）の構成図。第３実施形態において、目的動作に加え、動作環境を考慮するとともに、故障発生予兆の有無の判定を伴う制御状態の監視を行う場合で、かつ、前段の状態推定を複数のパターン認識器で行う場合（ケースＣ３－２）の構成図。本発明の第４実施形態において、目的動作に加え、動作環境および累積稼働回数・時間を考慮して制御状態の監視を行う場合で、かつ、前段の状態推定を１つのパターン認識器で行う場合（ケースＣ４－１）の構成図。第４実施形態において、目的動作に加え、動作環境および累積稼働回数・時間を考慮して制御状態の監視を行う場合で、かつ、前段の状態推定を複数のパターン認識器で行う場合（ケースＣ４－２）の構成図。

以下に本発明の制御状態監視システムの各実施形態について図面を参照して説明する。各実施形態は、一部の構成が異なるのみであるため、共通部分や対応部分については、各実施形態で同じ符号を付すものとする。各実施形態は、説明の便宜上、簡易な構成から複雑な構成へと順番に説明を進めるために分けているに過ぎず、全体で１つの実施形態と捉えてもよいものである。従って、全ての実施形態で、制御状態監視システム１０、状態推定器５０、異常検知器６０等の共通符号を用いて説明を行う。

［第１実施形態］

図１には、第１実施形態の制御状態監視システム１０の全体構成が示されている。第１実施形態は、動作環境、累積稼働回数・時間を考慮することなく、目的動作のみを考慮して制御状態の監視を行う場合であり、本発明の基本構成を説明するための実施形態である。図２は、交流回路の電圧・電流の説明図である。図３には、状態データおよび特徴データの送信や保存の形態が示されている。また、図４には、前段の状態推定を１つのパターン認識器で行う場合（ケースＣ１－１）、図５には、前段の状態推定を複数のパターン認識器で行う場合（ケースＣ１－２）の構成がそれぞれ示されている。さらに、図６～図１０には、異常検知器６０の各タイプの構成が示されている。

＜制御状態監視システム１０の全体構成＞

図１において、制御状態監視システム１０は、機器２０の動作制御の状態を監視するシステムである。この制御状態監視システム１０による制御状態の監視には、機器２０に元々設置されている計測器の出力データや、機器２０に元々設置されている計測器ではなく制御状態の監視のために設置した計測器の出力データ等が用いられるので、制御状態の監視対象である機器２０の一部が、制御状態監視システム１０の構成要素にもなっている。

図１において、制御状態監視システム１０は、機器２０の一部（制御状態の監視に必要な状態データやその他の情報を取得する部分）と、機器２０から取得した状態データやその他の情報をネットワーク１上に送出する接続装置２６と、それぞれネットワーク１に接続された装置である異常検知処理装置３０、データ収集装置８０、学習装置９０とを備えて構成されている。また、ネットワーク１には、ユーザ（異常検知結果の利用者）が操作するユーザ端末１００と、本システムの管理者が操作する管理者端末１１０とが接続されている。

ここで、ネットワーク１は、主としてインターネットのような外部ネットワークであるが、これとイントラネットやＬＡＮ等の内部ネットワークとの組合せ等でもよく、有線であるか、無線であるか、有線・無線の混在型であるかは問わない。また、ネットワーク１は、例えば、社内、工場内、事業所内、グループ企業内、学内、所定の地域内等に限定されたイントラネットやＬＡＮ等の内部ネットワークであってもよい。

また、本実施形態では、機器２０から取得した状態データを用いて動作制御の状態監視（異常検知）に関する各種処理を行うためのシステム構成として、それぞれ別々のコンピュータからなる接続装置２６と、異常検知処理装置３０と、データ収集装置８０と、学習装置９０とをネットワーク１で接続した構成を採用しているが、このようなネットワーク接続によるシステム構成は一例に過ぎない。従って、制御状態監視システム１０は、必ずしもこのように複数台のコンピュータにより構成されている必要はなく、各装置２６，３０，８０，９０で実現される機能を１台のコンピュータにまとめた構成としてもよく、あるいは各機能を任意の台数のコンピュータに分散してもよい。

例えば、異常検知処理装置３０で実現される各機能（状態データ取得手段４０、状態推定器５０、異常検知器６０、出力手段７０の各機能）を、複数台のコンピュータに分散してもよく、あるいは、異常検知処理装置３０で実現される各機能の一部（例えば、状態データ取得手段４０の全部または一部の機能、またはそれに加えて状態推定器５０の全部または一部の機能）を、接続装置２６で実現してもよい。

後者の場合、接続装置２６は、各地に設置された機器２０に対応して設けられているので、状態データ取得手段４０の全部または一部の機能（例えば、周波数分析等の前処理の機能）や、状態推定器５０の全部または一部の機能が、各地のそれぞれで実現されることになる。なお、機器２０と接続装置２６とは、比較的近距離に設置されるので、原則として、同じ場所や同じエリア内に設置されるが、両者が１対１である必要はなく、複数の機器２０に対して１つの接続装置２６が設置されていてもよい。また、機器２０が例えばプラント機器のように大きな機器である場合には、１つの機器２０に対して複数の接続装置２６が設置されていてもよく、この場合、例えば、１つの機器２０について複数の場所で異なる種類の状態データを取得し、それぞれの状態データを、それぞれの場所に設置された接続装置２６へ送信するケース等がある。

そして、図１での図示は省略されているが、機器２０の周辺に、制御状態監視システム１０の一部として機能する配電盤や分電盤を設けてもよい。この場合には、配電盤や分電盤に接続装置２６の機能を設けることができ、また、機器２０に対して給電を行う電源２３、電源２３から機器２０への入力電流・電圧の値を外部観測データとして取得する状態監視用センサ２４、あるいは目的動作取得手段２５を、配電盤や分電盤に設けてもよい。さらに、このような配電盤や分電盤に、状態データ取得手段４０の全部または一部の機能、状態推定器５０の全部または一部の機能を設けてもよい。

また、状態推定器５０の機能が、接続装置２６で実現される場合は、状態推定器５０が各地に設置されることになるので、状態データがネットワーク１上を流れるのではなく、特徴データがネットワーク１上を流れることになる。なお、状態データや特徴データが動作制御の状態監視（異常検知）の処理を行うためにネットワーク１上を流れることと、状態データや特徴データがデータ収集装置８０に保存されて学習用データとして提供されるか否かとは、別のことである。従って、データがネットワーク１上を流れることをもって、そのデータについての学習用データとしての使用が承諾されているわけではない。

＜機器２０の構成＞

図１に示すように、機器２０は、動作部２１と、この動作部２０を制御する制御部２２とを備えて構成されている。動作部２１には、電源２３から駆動用の電力が供給されるようになっている。なお、図示は省略されているが、制御部２２にも電源２３からの電力供給がある。

制御部２２には、機器２０の利用者（以下、制御状態監視システム１０の利用者と区別する必要があるときには、一般ユーザまたはエンドユーザと称する。）から、動作部２０をどのように動作させるのかという目的動作についての指示が入力される。この指示の入力は、機器２０に設けられた制御盤のボタン操作による指示でもよく、パーソナルコンピュータ、またはスマートフォンやタブレット端末等のモバイル機器からの遠隔操作による指示でもよい。指示された目的動作を示す情報は、制御部２２に記憶される。

動作部２１および制御部２２の組合せは任意であり、制御部２２が予め定められた少なくとも１つの目的動作を動作部２１に実行させるための制御を行うようになっていれば、本発明を適用することができる。具体的には、例えば、動作部２１がフライホイールで、制御部２２がインバータの組合せである。また、機器２０がインバータエアコンの場合には、動作部２１がコンプレッサ（室外機に設置された圧縮機）のモータであり、制御部２２はインバータである。

また、機器２０には、状態監視用センサ２４が設置されている。この状態監視用センサ２４は、機器２０に元々設置されている制御用センサとは別に、制御状態監視システム１０による制御状態の監視（異常検知）を行うために設置されたものである。従って、この状態監視用センサ２４が無くても、機器２０の動作制御は何の不都合もなく行うことができるが、制御状態の監視（異常検知）のために取得する状態データの種類が減ることになるので、制御状態監視システム１０の性能向上のためには、状態監視用センサ２４を設置したほうがよい場合がある。一方、機器２０の種別によっては、状態監視用センサ２４を設置しなくても、十分に高精度な異常検知を行うことができる場合もある。

さらに、機器２０の周辺には、制御部２２から目的動作を示す情報（予め定められた複数の目的動作のうちの制御実行中の目的動作を示す情報）を取得し、取得した目的動作を示す情報を、有線または無線で接続装置２６へ送信する処理を実行する目的動作取得手段２５が設けられている。この目的動作取得手段２５は、例えばマイクロコントローラ（いわゆるマイコン）等により構成されるが、汎用のパーソナルコンピュータで構成してもよい。

＜状態データの取得、ネットワーク送信を行うための構成＞

制御部２２から動作部２１に入力される制御信号と、この制御信号以外で動作部２１へ入力される外部入力データ（例えば、電源２３から動作部２１へ供給される電圧・電流の波形データ等）と、動作部２１から制御部２２へ送信される内部観測データ（制御用センサの出力データであり、フィードバック制御を行う場合のフィードバック信号や、制御盤でのモニタリング用の計測データ等を含む。）と、外部観測データ（状態監視用センサ２４の出力データ）とは、図１中の点線で示すように、それぞれ状態データとして、接続装置２６へ有線または無線で送信されるようになっている。なお、図１では、これらの状態データは、接続装置２６へ直接に送信されるように記載されているが、目的動作取得手段２５の場合と同様に、取得した状態データを接続装置２６へ送信する状態データ送信手段（例えば、マイクロコントローラや、パーソナルコンピュータ等により構成される手段）を設置してもよく、各状態データおよび目的動作を示す情報を、まとめて接続装置２６へ送信する状態データ・目的動作送信手段（従って、目的動作取得手段２５を含む）を設置してもよく、これらの状態データ送信手段や状態データ・目的動作送信手段で、周波数分析等の前処理を行ってもよい。

上述したように、機器２０から取得する状態データには、（１）制御信号と、（２）外部入力データと、（３）内部観測データと、（４）外部観測データとがある。但し、制御状態の監視対象となる全ての機器２０について、これらの（１）～（４）の状態データの全てが必要になるという意味ではない。機器２０の種別に応じ、（１）～（４）の状態データの中から少なくとも１つの状態データを選択して使用（状態推定器５０によるパターン認識処理で使用するという意味）すればよい。

また、（１）～（４）の状態データの各々には、１種類または複数種類の状態データがある。従って、２以上の状態データを組み合わせて使用する場合には、例えば、（２）と（３）との組合せ、（２）と（３）と（４）との組合せのように、（１）～（４）のうちの異なる系統の状態データを組み合わせてもよく、あるいは、（１）同士、（２）同士、（３）同士、（４）同士の組合せのように、同じ系統に属する異なる種類の状態データの組合せとしてもよい。

（３）内部観測データと（４）外部観測データとの相違は、センサの設置位置が機器２０の筐体の内部と外部という意味ではなく、機器２０に元々設置されている制御用センサであるか、制御状態監視システム１０を構築するために追加で設置した状態監視用センサ２４であるかの相違である。

また、同じ物理量を示す計測値でも、複数の系統の状態データとして捉えられる場合がある。例えば、電源２３から動作部２１へ供給される電圧や電流の波形データは、（２）外部入力データ、（３）内部観測データ、（４）外部観測データとして計測される場合がある。この場合、上述したように（３）と（４）との相違は、センサの設置目的の相違であるが、（２）と、（３）や（４）との相違は、計測場所の相違または考え方の相違である。電源２３側に帰属する装置で計測されれば、（２）外部入力データであり、機器２０側に帰属する装置で計測されれば、（３）内部観測データまたは（４）外部観測データであると考えることができる。従って、配電盤や分電盤を、電源２３側の装置であると考えるか、機器２０側の装置であると考えるかによっても変わってくる。しかし、電圧や電流の波形データを、状態データとして取得することができればよいので、取得したデータが、（２）～（４）のうちのいずれの系統の状態データに該当するのかは問題にならない。なお、機器２０側（負荷側）で計測して（４）外部観測データとする場合には、機器２０側におけるいずれの負荷部分の電圧・電流を計測するのかにより、異なる種類の状態データが得られる。Ｒ相、Ｔ相の相違という意味ではなく、機器２０内の回路のいずれの個所の電圧・電流を計測するのかの相違という意味である。

さらに、（１）～（４）のうちの同じ系統の場合（例えば、ともに（４）の場合等）で、かつ、同じ現象を計測する場合でも、計測位置や計測方向が異なる場合や、センサ種別が異なる場合は、異なる種類の状態データになる場合がある。例えば、同じ現象について、異なるセンサ特性を有する２以上のセンサを用いて計測すれば、異なる種類の状態データになるので、それらを組み合わせて使用してもよい。

（３）内部観測データは、制御用センサの出力データであり、制御に関連する何らかの目的で、機器２０に元々設置されているセンサ出力をすべて含む。例えば、フィードバック制御を行う場合のフィードバック信号（動作部２１への入力である制御信号（入力信号）にフィードバック（帰還）する信号）、制御盤でのモニタリング用の計測データ（直接に制御信号に反映されるデータではなく、人間が制御中に参照するためのデータ）、バルブのＯＮ・ＯＦＦ状態を示す信号、制御盤のランプ点灯用の信号等を含む。従って、シーケンス制御を行っている機器２０からのセンサ出力も含む。また、ここでいうフィードバック信号は、フィードバック経路上の信号という意味であり、動作部２１から出力された直後の信号（フィードバック経路上の伝達関数よりも上流側の信号）と、制御信号にフィードバックされる直前の信号（フィードバック経路上の伝達関数よりも下流側の信号）との双方を含む。

（３）内部観測データは、機器２０に元々設置されているセンサ出力であるから、それを制御状態監視システム１０による異常検知に利用することができれば、安価かつ容易にシステムを構築することができる。一方、（３）内部観測データとして得られないデータを、状態データとして使用したい場合には、別途にセンサを設置する必要があるが、そのセンサ出力は、前述したように設置場所や考え方によっては、（２）外部入力データとなり、あるいは（４）外部観測データとなる。前述したように、（２）であるか、（４）であるかは重要ではなく、どのような状態データを、どのような種別または特性のセンサを設置して取得するのかが重要となる。

（２）外部入力データ、または（４）外部観測データには、例えば、電圧、電流、振動、熱、音（騒音）等の各種データが含まれる。そして、設置するセンサは、例えば、電流値の取得であれば、電流検出器（ＣＴ：Current Transformer）を用いることができ、その他、計測対象に応じて、加速度センサ、ギャップセンサ、熱センサ、マイクロフォン、光電センサ、磁気センサ、画像センサ等の各種のセンサを用いることができる。

より具体的には、例えば、（３）内部観測データとして得られない電圧値および電流値を、配電盤または分電盤から取得し、それらを状態データとして使用することができる。配電盤等から機器２０への出力であるが、機器２０にとっては入力電源であるため、配電盤等を電源２３側の装置であると考えれば、この状態データは、（２）外部入力データであると考えることができる。また、機器２０側のいずれかの負荷部分で計測すれば、（４）外部観測データであると考えることができる。

図２に示すように、電源２３が交流電源である場合には、電圧や電流の波形データは、正弦波に近いデータとなり、電圧と電流とで位相がずれている。これらの電圧および電流の波形データを、状態データとして用いれば、機器２０の負荷（ここでは交流波形の説明なのでインピーダンスを指し、直流の場合の抵抗に相当）、負荷力率、ノイズとして発生するリップル電流（電流の中に含まれている脈動の成分）等の微小な変化を捉えることができ、異常検知を行うことが可能であると考えられる。機器２０の異常時には、その影響が負荷（インピーダンスや、抵抗）、力率、リップル電流等の変化として観測可能であると考えられるからである。

このように電圧や電流の波形データを取得し、状態データとして用いて機器２０の負荷（交流の場合のインピーダンスや、直流の場合の抵抗）、負荷力率、ノイズとして発生するリップル電流（電流の中に含まれている脈動の成分）等の微小な変化を捉える処理は、電圧値および電流値が（３）内部観測データとして得られない場合に限らず、（３）内部観測データとして得られる場合に行っても同様な効果が得られる。従って、（３）内部観測データとしての電圧や電流の波形データを用いてもよい。

なお、電源２３が交流電源である場合の電圧および電流の各波形データは、そのまま状態データとして用いてもよく、これらの波形データを周波数分析（例えば、ＦＦＴ、ＭＦＣＣ等）して得られた各周波数帯域の成分値を状態データとして用いてもよい。また、三相交流の場合には、通常は三相全部を使用する必要はなく、二相の情報があれば、残りの一相の情報は完全に復元可能である。従って、三相のうち二相だけを使用すればよく、また、一相だけを使用してもよい。

具体的には、電源２３が三相交流電源である場合には、電圧および電流からの特徴量の取得方法として、例えば、次のような方法を採用することができる。下記の第１～第４の状態データは、全て高サンプリング周波数で計測された時系列データであり、時間軸に対して全ての観測が同期しているものとする。

第１の状態データは、Ｒ相の電圧波形から得られたＮ次元のベクトルデータである。
第２の状態データは、Ｒ相の電流波形から得られたＮ次元のベクトルデータである。
第３の状態データは、Ｔ相の電圧波形から得られたＮ次元のベクトルデータである。
第４の状態データは、Ｔ相の電流波形から得られたＮ次元のベクトルデータである。

これらのＮ次元のベクトルデータは、時系列データであり、観測された値そのものであるから、周波数分析（例えば、ＦＦＴ、ＭＦＣＣ等）して得られた各周波数帯域の成分値ではない。また、全ての観測が同期しているので、４つのＮ次元のベクトルデータにおける１番目の値（１番目の次元の値）のそれぞれは、同時刻の値であり、２番目の値のそれぞれも、同時刻の値であり、３番目以降の値も同様である。

そして、これらの波形データを画像画素（Ｒ，Ｇ，Ｂ）のように扱い、畳み込み・ニューラル・ネットワーク（ＣＮＮ）によるパターン認識処理を行う状態推定器５０に入力する。第１～第４の状態データは、いずれも図２のような波形を直接にイメージできる時系列データであり、（時刻ｔ１の値、時刻ｔ２の値、…、時刻ｔＮの値）というＮ次元のベクトルデータであるが、この時系列データを、順番に入力するのではなく、１時点の入力データとして、まとめて同時に状態推定器５０に入力することになる。

このような電圧・電流波形から得られた第１～第４の状態データのいずれかを用いることにより、機器２０側（負荷側）のインピーダンスや力率やリップル電流等の変化がモデル化されると考えられる。また、いずれか１つを用いてもよいが、よりインピーダンスや力率やリップル電流等のモデル化を可能にするために、第１と第２の状態データ（Ｒ相の電圧・電流波形）をまとめるか、または、第３と第４の状態データ（Ｔ相の電圧・電流波形）をまとめることにより、２×Ｎ次元のベクトルデータを、ＣＮＮによる状態推定器５０への入力データとしてもよく、この場合には、フィルタ数が２倍のＣＮＮが構築される。さらに、第１～第４の状態データの全てをまとめ、４×Ｎ次元のベクトルデータを、ＣＮＮによる状態推定器５０への入力データとしてもよい。また、電流値×電圧値から構成されるＮ次元の電力値ベクトルや、電圧値／電流値から構成されるＮ次元の抵抗値ベクトル等を、ＣＮＮによる状態推定器５０への入力データとしてもよい。

なお、上記のような電圧・電流波形による第１～第４の状態データを得る場合を含め、より一般に、波形データから、状態推定器５０への入力データを作成する方法には、大別すると、３通りの方法がある。

第１の方法では、高サンプリング周波数で取得した１次元のデータ（ある１時刻のデータ）を、１次元のデータとして、そのまま時系列で（順番に）入力する。従って、状態推定器５０への入力データの次元数は小さくなり、１次元の入力データでも状態推定を行うことが可能な場合がある。但し、この第１の方法では、状態推定器５０は、内部メモリ（前回または前回以前の内部的処理結果を記憶する内部メモリ）を有することにより、内部構造的に系列モデリングを実現しているパターン認識器である必要がある。すなわち、内部メモリによる時系列パターン認識処理を行う必要がある。例えば、リカレント・ニューラル・ネットワーク（ＲＮＮ）、またはＲＮＮの中のロング・ショート・ターム・メモリ（ＬＳＴＭ）、あるいは隠れマルコフモデル（ＨＭＭ）等による時系列パターン認識処理である。

第２の方法では、高サンプリング周波数で取得した１次元のデータの集合（複数の時刻のデータ）を、そのまま（つまり、周波数分析をせずに）、まとめて一気に高次元のデータとして入力する。前述した第１～第４の状態データ（電圧・電流波形から得られたＮ次元のベクトルデータ）を、ＣＮＮによる状態推定器５０へ入力する場合は、この第２の方法である。第２の方法では、状態推定器５０は、内部メモリによる時系列パターン認識処理を行う必要はなく、静的な（スタティックな）パターン認識処理でよいが、内部メモリによる時系列パターン認識処理を行ってもよい。

第３の方法では、周波数分析を行い、各周波数帯域の成分値を、まとめて一気に高次元のデータとして入力する。周波数分析としては、例えば、ＦＦＴ、ＭＦＣＣ等を採用することができ、本実施形態では、周波数分析は、前処理手段４１により実行する。この際、周波数分析の演算窓の時間長は、分析対象の波形の状態に応じて定めればよい。また、複数の演算窓の各々で周波数分析を行った結果を、例えば平均値や合計値等の算出による統合処理（帯域毎の演算でよいが、複数の帯域に跨った演算でもよい。）を行い、その統合処理の結果を、状態推定器５０への入力データとしてもよく、この統合処理も、本実施形態では、前処理手段４１により実行する。例えば、１つの演算窓での周波数分析の結果（各周波数帯域の成分値）として１０２４次元のベクトルデータが得られたとすれば、複数個（Ｌ個）の１０２４次元のベクトルデータ（Ｌ個の演算窓の各データ）から、統合処理で１つの１０２４次元のベクトルデータを作成し、それを入力データとする。さらに、複数の演算窓は、時間的にずれているが、統合処理の対象とする複数個（Ｌ個）の演算窓は、重なっていてもよく、重なりがなくてもよい。例えば、各演算窓での周波数分析の結果を示す多次元のベクトルデータが生成時刻順にＱ１，Ｑ２，Ｑ３，Ｑ４，…であり、Ｌ個＝１００個であるとすれば、（Ｑ１，Ｑ２，…，Ｑ１００）、（Ｑ２，Ｑ３，…，Ｑ１０１）のように、１つずつずらしながら統合処理の対象としてもよく、（Ｑ１，Ｑ２，…，Ｑ１００）、（Ｑ１０１，Ｑ１０２，…，Ｑ２００）のように、重なりなく統合処理の対象としてもよく、あるいは、（Ｑ１，Ｑ２，…，Ｑ１００）、（Ｑ１１，Ｑ１２，…，Ｑ１１０）のように、重なりはあるが、ずらし量が１つではなく、２以上になるように統合処理の対象を設定してもよい。また、各演算窓は、重なりなく連続していてもよく、前後の演算窓が部分的に重なっていてもよく、前後の演算窓が離れていてもよい（前後の演算窓の間に時間的な隙間があってもよい）。この第３の方法でも、状態推定器５０は、内部メモリによる時系列パターン認識処理を行う必要はなく、静的な（スタティックな）パターン認識処理でよいが、内部メモリによる時系列パターン認識処理を行ってもよい。

接続装置２６は、ネットワーク１へのデータ送出を行うエッジデバイスとしての機能（例えば、通信プロトコルの変換等の機能）を有する装置であり、コンピュータにより構成され、機器２０や状態監視用センサ２４や目的動作取得手段２５（あるいは、図示されない状態データ送信手段や状態データ・目的動作送信手段でもよい。）から出力される状態データおよび目的動作を示す情報を有線または無線で受信し、受信した状態データおよび目的動作を示す情報を、データ管理に必要となる情報とともに、ネットワーク１を介して異常検知処理装置３０（状態データ取得手段４０）へ送信する処理を実行するものである。

より詳細には、機器２０から接続装置２６を経由して状態データ取得手段４０へ送信するデータは、図３に示す通りである。すなわち、状態データ取得手段４０への送信データには、状態データについてのデータ識別情報（データＩＤ）と、機器識別情報（機器の製造番号等）と、機器タイプ識別情報（機器の型番等）と、目的動作を示す情報と、機器稼働開始年月日および／または累積稼働回数を示すカウント値と、状態データについてのデータ取得日時（年月日・時分秒）と、少なくとも１つの状態データとが含まれている。そして、状態データには、（１）制御信号と、（２）外部入力データ（電源の電圧および／または電流の波形データを含む）と、（３）内部観測データ（フィードバック信号を含む）と、（４）外部観測データとがある。なお、状態データおよび目的動作を示す情報を除くデータ（データ管理に必要となる情報）は、接続装置２６が付与してもよい。

＜異常検知処理装置３０の全体構成＞

異常検知処理装置３０は、１台または複数台のコンピュータ（サーバ）により構成され、状態データ取得手段４０と、状態推定器５０と、異常検知器６０と、出力手段７０とを含んで構成されている。状態データ取得手段４０は、前処理手段４１を備えている。また、状態推定器５０は、状態推定用のパターン認識アルゴリズムを実行する状態推定用パターン認識処理手段５１と、このパターン認識処理に用いる状態推定モデルを記憶する状態推定モデル記憶手段５２とを備えている。さらに、異常検知器６０は、クラス識別処理、外れ値検知処理、新規性検知処理のうちの少なくとも１つの処理を実行する異常検知処理手段６１と、この異常検知のための処理に用いる異常検知モデルを記憶する異常検知モデル記憶手段６２とを備えている。

ここで、状態データ取得手段４０、前処理手段４１、状態推定用パターン認識処理手段５１、異常検知処理手段６１、および出力手段７０は、異常検知処理装置３０を構成するコンピュータ本体の内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラムにより実現される。また、状態推定モデル記憶手段５２、異常検知モデル記憶手段６２としては、例えば、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）等を採用することができる。

状態データ取得手段４０は、接続装置２６からネットワーク１を介して送信されてくる状態データおよび目的動作を示す情報（付加されたデータ管理に必要となる情報を含む。図３参照）を受信（取得）する処理を実行するものである。接続装置２６からの状態データ等の送信は、接続装置２６側で管理されるタイミングで行われてもよく、状態データ取得手段４０からの取得要求に基づき行われてもよい。

また、前処理手段４１は、取得した状態データについて、必要な場合に、例えば、高速フーリエ変換（ＦＦＴ）やメル周波数ケプストラム係数（ＭＦＣＣ）等の周波数分析、画像データについての背景除去、正規化、エッジ画像作成等の各種の前処理を実行するものである。さらに、前処理手段４１で行う前処理には、分離して送信されてきた複数種類の状態データまたはそれらについて前処理（周波数分析等）を行った後の状態データを結合して状態推定器５０への入力データを作成する処理も含まれる。

なお、本実施形態では、状態データ取得手段４０は、接続装置２６からネットワーク１を介して送信されてくる状態データおよび目的動作を示す情報を受信する構成とされているが、機器２０や状態監視用センサ２４や目的動作取得手段２５から出力される状態データおよび目的動作を示す情報を直接に取得する構成としてもよい。接続装置２６に状態データ取得手段４０を設ける構成とする場合もあり、また、ネットワーク構成にせずに、機器２０の設置場所付近で異常検知処理を行う構成とする場合もあるからである。

＜状態推定器５０の構成＞

状態推定器５０は、状態データ取得手段４０により取得した状態データから作成されたパターン認識用の入力データを用いて、制御実行中の動作部２１の実際の動作状態が、制御の目的動作を示す状態になっているか否かまたは制御の達成度を示すデータを出力するパターン認識処理を実行し、このパターン認識処理で得られる特徴データを抽出する処理を繰り返し実行するものである。

目的動作は、少なくとも１つは必要であり、また、各目的動作は、予め定められた動作でなければならない。目的動作での稼働時における機器２０の動作制御の状態について、学習を行って状態推定モデル記憶手段５２に記憶させる状態推定モデルを作成するからである。つまり、目的動作が予め定められていないと、状態推定モデルを構築できない。

本発明で動作制御の状態を監視する際には、目的動作は既知の状態となっている。目的動作は、機器２０の利用者（一般ユーザ）による指示としてボタン操作や遠隔操作等で制御部２２に与えられ、制御部２２には、目的動作を示す情報が記憶されている。従って、目的動作取得手段２５により、制御部２２から目的動作を示す情報を取得し、取得した目的動作を示す情報を、異常検知処理装置３０へ送信することにより、状態推定器５０、異常検知器６０、および出力手段７０では、目的動作が既知の状態となる。

また、機器２０の利用者（一般ユーザ）は、機器２０に対し、目的動作について指示を出しているので、目的動作を自分で知っている。従って、機器２０の利用者は、ユーザ端末１００を操作し、ネットワーク１を介して異常検知処理装置３０に対して目的動作を示す情報を送信することができ、これにより、状態推定器５０、異常検知器６０、および出力手段７０では、目的動作が既知の状態となる。なお、機器２０の利用者（一般ユーザ）が、異常検知処理装置３０の周辺にいる場合には、ネットワーク経由ではなく、異常検知処理装置３０に対してボタン操作等で直接に目的動作を示す情報を与えることができる。

さらに、制御状態監視システム１０の利用者は、機器２０を利用する一般ユーザ（機器２０を使用して事業を行う運用事業者や、家庭内で機器２０を使用する者等のエンドユーザ）だけではない。例えば、メーカ、販売業者、保守・点検業者、廃棄物処理業者等の作業員が、例えば、新製品リリース前の点検、個々の製品の出荷前の点検、製品販売前の点検、製品販売後の定期点検、一般ユーザの依頼に基づく任意の時期の点検、廃棄製品を利用したデータ収集等のような様々な目的で、制御状態監視システム１０を利用する。従って、これらの作業者が、点検等の目的で機器２０を稼働させる際には、制御部２２に対して目的動作を指示し、目的動作取得手段２５により、制御部２２から目的動作を示す情報が取得され、異常検知処理装置３０へ送信される。また、これらの作業者が、ユーザ端末１００を操作し、ネットワーク１を介して異常検知処理装置３０に対して目的動作を示す情報を送信する場合もあり、これらの作業者が、異常検知処理装置３０の周辺にいるときには、ネットワーク経由ではなく、異常検知処理装置３０に対してボタン操作等で直接に目的動作を示す情報を与える場合もある。

なお、本発明は、目的動作が１つしかない機器２０にも適用することができ、この場合には、その唯一の目的動作での稼働時の状態を学習してモデルを構築し、運用時にそのモデルを用いて動作制御の状態を監視することになる。従って、目的動作取得手段２５の設置は省略してもよく、また、ユーザ端末１００等から異常検知処理装置３０に対して目的動作を示す情報を与える必要もない。

機器２０に、複数の目的動作がある場合とは、具体的には、例えば、動作部２１が、フライホイール、ベルトコンベアのベルトを回動させるプーリ、エアコンのコンプレッサのモータであれば、目的動作Ｘ＝１００回転での定常運転、目的動作Ｙ＝７０回転での定常運転、目的動作Ｚ＝３０回転での定常運転等である。また、状態データにより学習可能な特徴を捉えることができる場合には、目的動作は、定常状態だけではなく、過渡状態でもよく、例えば、９０回転から１００回転へ移行する運転等であってもよい。

さらに、目的動作は、複数のパラメータを備えていてもよく（目的動作で制御するパラメータが複数あってもよく）、例えば、回転数（ｒｐｍ）およびファンのＯＮ／ＯＦＦという複数（２つ）のパラメータを組み合わせた複合的な目的動作としてもよい。具体的には、例えば、目的動作Ｘ＝「１００回転、かつ、ファンＯＮでの定常運転（ファンをＯＮにした状態での１００回転での定常運転）」、目的動作Ｙ＝「１００回転、かつ、ファンＯＦＦでの定常運転」、目的動作Ｚ＝「５０回転、かつ、ファンＯＦＦでの定常運転」等である。この場合は、目的動作を構成するいずれのパラメータも、既知の情報であり、上記の例であれば、回転数が１００回転であるか、５０回転であるかは既知であり、かつ、ファンがＯＮであるか、ＯＦＦであるかも既知である。

また、機器２０の利用者（一般ユーザ）による指示が、直接に目的動作になるのではなく、制御部２２に対する目的動作の間接的な指示になる場合もある。例えば、エアコンの場合、一般ユーザは、「２６度の冷房」のような設定をするが、制御部２２は、このような一般ユーザの指示そのものを目的動作とするのではなく、２６度の冷房という指示を受けた後に、その設定温度（２６度）と現在の室内温度との関係でエアコンのパワーを決定するコンプレッサ（室外機に設置された圧縮機）のモータの回転数を設定し、それを目的動作とする。従って、インバータエアコンの場合、一般ユーザの指示による「２６度の冷房」という設定ではなく、インバータによるコンプレッサのモータの回転数制御の目的動作（モータの回転数）が、本発明における目的動作に該当する。

状態推定器５０を構成するパターン認識器の数は、１つでもよく、複数でもよい。パターン認識器は、アルゴリズム（状態推定用パターン認識処理手段５１を実現する状態推定用のパターン認識アルゴリズム）と、モデル（状態推定モデル記憶手段５２に記憶されている状態推定モデル）との組合せであるから、パターン認識器の数を複数にする場合は、アルゴリズムが同じで、異なる状態推定モデル（パラメータ）を用意するか、または、複数種類のアルゴリズムを用意してもよく、いずれの場合でも、後段の異常検知器６０を構成する異常検知モデルは、それぞれのパターン認識器に対応させて用意する。後段の異常検知器６０を構成する異常検知モデルを学習により構築するには、対応する前段のパターン認識器から抽出した特徴データを用いることになり、かつ、運用時にも、同じ対応関係で、前段のパターン認識器から抽出した特徴データを、後段の異常検知器６０に入力することになるからである。

具体的には、本実施形態の状態推定器５０は、一例として、畳み込み・ニューラル・ネットワーク（ＣＮＮ）によるパターン認識処理を実行する構成とする。但し、隠れマルコフモデル（ＨＭＭ）等を採用してもよく、あるいは、ＣＮＮによるパターン認識器と、ＨＭＭによるパターン認識器との双方を混在させてもよい。状態推定器５０への入力データは、例えば、１０２４次元等であり、抽出する特徴データは、例えば、２５６次元等である。

図４および図５に示すように、ＣＮＮは、入力層、複数の中間層、出力層（最終層）を備え、状態推定器５０は、ＣＮＮの中間層（例えば、最終層から２つ前の中間層等）から出力される特徴量を、後段の異常検知器６０に入力するための特徴データとして抽出する処理を実行する。目的動作の数は任意であるが、ここでは、説明の便宜上、３つの目的動作Ｘ，Ｙ，Ｚがあるものとする。例えば、目的動作Ｘ＝１００回転での定常運転、目的動作Ｙ＝７０回転での定常運転、目的動作Ｚ＝３０回転での定常運転等である。実際には、機器２０の種別にもよるが、１００以上の目的動作がある場合もある。

図４では、状態推定器５０は、ＣＮＮによる１つのパターン認識器により、複数の目的動作Ｘ，Ｙ，Ｚでの稼働時の各々の識別結果を出力する。すなわち、目的動作Ｘでの稼働時には、制御実行中の動作部２１の実際の動作状態が、目的動作Ｘを示す状態（正常な状態）になっているか否かまたは制御の達成度を示すデータを出力する。換言すれば、ＣＮＮの出力層（最終層）には、目的動作Ｘに対応する２つの出力ノード（２ユニット）があり、目的動作Ｘでの正常な動作制御の状態であることの確からしさを示す尤度と、それ以外の状態であることの確からしさを示す尤度とが出力される。目的動作Ｙ，Ｚについても同様である。但し、特徴データとして中間層出力を抽出するので、これらの尤度は、後段の異常検知器６０では使用されない。

また、図４に示す状態推定器５０は、マルチタスクＣＮＮの構成とされ、入力層から、特徴データを抽出する中間層に至るまでのネットワーク部分は、３つの目的動作Ｘ，Ｙ，Ｚで共通化され、その部分（ＣＮＮ中間層の共有部）のパラメータはシェアされている。一方、特徴データを抽出する中間層よりも出力層（最終層）寄りの部分は、第１のタスク用（目的動作Ｘ用）のＣＮＮ出力層に至る部分（非共有部）と、第２のタスク用（目的動作Ｙ用）のＣＮＮ出力層に至る部分（非共有部）と、第３のタスク用（目的動作Ｚ用）のＣＮＮ出力層に至る部分（非共有部）とに分かれている。

第１のタスク（目的動作Ｘ）の学習を行う際には、目的動作Ｘでの正常な運転が行われている際の多数の状態データおよび目的動作Ｘであるというタグ情報と、それ以外の運転が行われている際の多数の状態データおよび目的動作Ｘではないというタグ情報とを用いて、ＣＮＮ中間層の共有部および３つの非共有部のうちの第１のタスク用（目的動作Ｘ用）の非共有部で学習を行う。それ以外の運転が行われている際の状態データとしては、目的動作Ｙ，Ｚでの運転、または目的動作Ｘ，Ｙ，Ｚのいずれでもない過渡状態の運転が行われている際の状態データ、あるいは類似タイプの機器の運転時の状態データやその加工データ等を用いることができる。

同様に、第２のタスク（目的動作Ｙ）の学習を行う際には、目的動作Ｙでの正常な運転が行われている際の多数の状態データおよび目的動作Ｙであるというタグ情報と、それ以外の運転が行われている際の多数の状態データおよび目的動作Ｙではないというタグ情報とを用いて、ＣＮＮ中間層の共有部および３つの非共有部のうちの第２のタスク用（目的動作Ｙ用）の非共有部で学習を行う。それ以外の運転が行われている際の状態データとしては、目的動作Ｘ，Ｚでの運転、または目的動作Ｘ，Ｙ，Ｚのいずれでもない過渡状態の運転が行われている際の状態データ、あるいは類似タイプの機器の運転時の状態データやその加工データ等を用いることができる。

また、第３のタスク（目的動作Ｚ）の学習を行う際には、目的動作Ｚでの正常な運転が行われている際の多数の状態データおよび目的動作Ｚであるというタグ情報と、それ以外の運転が行われている際の多数の状態データおよび目的動作Ｚではないというタグ情報とを用いて、ＣＮＮ中間層の共有部および３つの非共有部のうちの第３のタスク用（目的動作Ｚ用）の非共有部で学習を行う。それ以外の運転が行われている際の状態データとしては、目的動作Ｘ，Ｙでの運転、または目的動作Ｘ，Ｙ，Ｚのいずれでもない過渡状態の運転が行われている際の状態データ、あるいは類似タイプの機器の運転時の状態データやその加工データ等を用いることができる。

なお、図４では、ＣＮＮ中間層の共有部の最後の層の出力を、特徴データとして抽出しているが、ＣＮＮ中間層の共有部における最後の層以外の層の出力を、特徴データとして抽出してもよい。但し、後段の異常検知器６０の学習時に使用する特徴データと、運用時時に使用する特徴データとは、同じ層から抽出した特徴データとする必要がある。

また、図４中の２点鎖線で示すように、非共有部の層の出力を、特徴データとして抽出してもよい。この場合も、後段の異常検知器６０の学習時に使用する特徴データと、運用時時に使用する特徴データとは、同じ層から抽出した特徴データとする必要がある。この際、運用時には、目的動作Ｘ，Ｙ，Ｚのうちのいずれでの制御中なのかが既知であるため、３つの非共有部のうちのいずれの非共有部の層の出力を、特徴データとして抽出するのかを判断することができる。

さらに、図４の例のように、目的動作Ｘ＝１００回転での定常運転、目的動作Ｙ＝７０回転での定常運転、目的動作Ｚ＝３０回転での定常運転とする場合、これらの目的動作Ｘ，Ｙ，Ｚは、同時には発生しないので、状態推定器５０は、マルチタスクではなく、１つのシングルタスクで構成することもできる。一方、前述したように、目的動作で制御するパラメータが複数あり、複数のパラメータの組み合わせで複合的な目的動作が定められている場合があるが、このような場合には、マルチタスクとすれば、同時に発生する状態に対応する出力ラベルを別のタスクに配置することができるので、目的動作を構成するパラメータ単位でのクラス識別を行う状態推定器５０を構築することも可能である。例えば、目的動作Ｘ＝「１００回転、かつ、ファンＯＮでの定常運転」、目的動作Ｙ＝「１００回転、かつ、ファンＯＦＦでの定常運転」、目的動作Ｚ＝「５０回転、かつ、ファンＯＦＦでの定常運転」等である場合に、状態推定器５０を構成するマルチタスクＣＮＮに、１００回転での正常な運転であるか、それ以外であるかの識別用の第１のタスクと、５０回転での正常な運転であるか、それ以外であるかの識別用の第２のタスクと、ファンのＯＮ／ＯＦＦの識別用の第３のタスクとを設けること等が可能である。このような目的動作を構成するパラメータ単位でのクラス識別を行うタスクを設ける場合については、後述する［変形の形態］で詳細を説明する。

一方、図５では、状態推定器５０は、複数の目的動作Ｘ，Ｙ，Ｚのそれぞれについて、別々のパターン認識器（いずれもＣＮＮ）による処理を実行し、複数の目的動作Ｘ，Ｙ，Ｚの各々の識別結果を出力する。すなわち、状態推定器５０は、第１（目的動作Ｘ用）のパターン認識器５０Ｘと、第２（目的動作Ｙ用）のパターン認識器５０Ｙと、第３（目的動作Ｚ用）のパターン認識器５０Ｚとを備えて構成されている。

第１（目的動作Ｘ用）のパターン認識器５０Ｘの出力層（最終層）には、目的動作Ｘに対応する２つの出力ノード（２ユニット）があり、目的動作Ｘでの正常な動作制御の状態であることの確からしさを示す尤度と、それ以外の状態であることの確からしさを示す尤度とが出力される。目的動作Ｙ，Ｚについても同様である。但し、特徴データとして中間層出力を抽出するので、これらの尤度は、後段の異常検知器６０では使用されない。

これらの３つのパターン認識器５０Ｘ，５０Ｙ，５０Ｚは、独立しているので、運用時には、第１（目的動作Ｘ用）のパターン認識器５０Ｘには、目的動作Ｘでの稼働時の状態データしか入力されない。パターン認識器５０Ｙ，５０Ｚも同様である。運用時には、目的動作Ｘ，Ｙ，Ｚのうちのいずれでの制御中なのかが既知であるため、そのような入力が可能となる。

第１（目的動作Ｘ用）のパターン認識器５０Ｘの学習を行う際には、目的動作Ｘでの正常な運転が行われている際の多数の状態データおよび目的動作Ｘであるというタグ情報と、それ以外の運転が行われている際の多数の状態データおよび目的動作Ｘではないというタグ情報とを用いる。それ以外の運転が行われている際の状態データとしては、目的動作Ｙ，Ｚでの運転、または目的動作Ｘ，Ｙ，Ｚのいずれでもない過渡状態の運転が行われている際の状態データ、あるいは類似タイプの機器の運転時の状態データやその加工データ等を用いることができる。従って、図４に示したマルチタスクＣＮＮの第１のタスク（目的動作Ｘ用）の学習と同様である。そして、第２（目的動作Ｙ用）のパターン認識器５０Ｙの学習、および第３（目的動作Ｚ用）のパターン認識器５０Ｚの学習も、それぞれ図４に示したマルチタスクＣＮＮの第２のタスク（目的動作Ｙ用）の学習、および第３のタスク（目的動作Ｚ用）の学習と同様にして行われる。

なお、本発明は、目的動作が１つしかない場合にも適用することができるが、その場合は、状態推定器５０が、第１（目的動作Ｘ用）のパターン認識器５０Ｘだけで構成されていると考えればよい。この場合、目的動作Ｙ，Ｚはないので、その他の具体的な識別要素がない場合（動作環境も１つしかなく、累積稼働回数・時間の区分けも１つしかなく、故障発生の有無の別もない場合）であれば、状態推定器５０の学習を行う際には、目的動作ではない過渡状態の運転が行われている際の状態データ、あるいは類似タイプの機器の運転時の状態データやその加工データ等を用いることができる。

また、第１（目的動作Ｘ用）のパターン認識器５０Ｘから抽出された特徴データは、後段の異常検知器６０において、対応するモデルである第１（目的動作Ｘ用）の異常検知モデル６２Ｘによる処理に使用される。パターン認識器５０Ｙ，５０Ｚの場合も同様であり、パターン認識器５０Ｙ，５０Ｚから抽出された特徴データは、それぞれ異常検知モデル６２Ｙ，６２Ｚによる処理に使用される。

さらに、図５では、状態推定器５０は、３つのパターン認識器５０Ｘ，５０Ｙ，５０Ｚのいずれについても、中間層の出力を、特徴データとして抽出する構成とされていたが、必ずしも全てについて中間層出力を抽出する必要はなく、一部について、出力層（最終層）出力を抽出する構成としてもよい。また、３つのパターン認識器５０Ｘ，５０Ｙ，５０Ｚは、別々のパターン認識器であるので、特徴データを抽出する中間層に至るネットワーク部分のパラメータは、それぞれ異なっており、それぞれのパターン認識器５０Ｘ，５０Ｙ，５０Ｚを構成する中間層の数も異なっていてもよい。さらには、特徴データを抽出する中間層の位置（何番目の層の出力を抽出するのか）も、それぞれのパターン認識器５０Ｘ，５０Ｙ，５０Ｚで異なっていてもよい。

＜異常検知器６０の構成＞

異常検知器６０は、状態推定器５０により抽出した特徴データを用いて、クラス識別処理、外れ値検知処理（アウトライヤ・ディテクション）、新規性検知処理（ノベルティ・ディテクション）のうちの少なくとも１つの処理を実行し、動作制御の異常の有無または程度を示すスコアを出力する処理を実行するものである。なお、クラス識別処理、外れ値検知処理、新規性検知処理のいずれも、パターン認識処理の範疇に含まれる。

ここで、異常検知器６０に入力されるのは特徴データであるから、外れ値検知処理は、大部分の特徴データから乖離した特徴データを検知する処理であり、新規性検知処理は、システムが認識していない特徴データ、すなわち学習していない特徴データを検知する処理である。一般的には、外れ値検知処理では、異常データの存在が前提となり、既知の異常データを用いた学習が行われることも多いが、本発明では、本第１実施形態のように、正常データ（正常な動作制御が行われている機器２０から取得した状態データを前段の状態推定器５０に入力し、そこから抽出した特徴データ）だけを用いて後段の異常検知器６０の学習を行うことが可能であり、その場合には、既知の異常データはなく、異常データの分布は未知である。また、一般的には、新規性検知処理では、検知された新規なデータは、異常データとはみなされず、正常データである場合もあるが、本発明では、本第１実施形態のように正常データだけを用いて後段の異常検知器６０の学習を行うことが可能であり、その場合には、検知された新規なデータを異常データとみなすことがある。従って、本発明では、前段の状態推定器５０や後段の異常検知器６０の学習形態（モデルの構築形態）にもよるが、外れ値検知処理と、新規性検知処理とは、同じ意味の処理となる場合があり、本第１実施形態では、同じ意味の処理となる。

図４および図５に示すように、異常検知器６０を構成する異常検知モデル記憶手段６２には、第１（目的動作Ｘ用）の異常検知モデル６２Ｘと、第２（目的動作Ｙ用）の異常検知モデル６２Ｙと、第３（目的動作Ｚ用）の異常検知モデル６２Ｚとが記憶されている。運用時において、これらの３つの異常検知モデル６２Ｘ，６２Ｙ，６２Ｚによる処理を行う際には、図４では、前段の状態推定器５０を構成する１つのパターン認識器から抽出された特徴データを用いるのに対し、図５では、複数（３つ）のパターン認識器５０Ｘ，５０Ｙ，５０Ｚのうちの対応するパターン認識器から抽出された特徴データを用いる。

また、異常検知器６０は、動作制御の異常の有無または程度を示すスコアを出力する構成とされているが、算出したスコアを、出力手段７０に送ってもよく、あるいは、算出したスコアと、予め定められている閾値との比較判定を行うことにより、動作制御の異常の有無（または正常であるか否か）の判定結果を出し、その判定結果を出力手段７０に送ってもよい。

さらに、異常検知器６０は、類似度を示すスコアや、乖離度を示すスコアを算出する場合があるが、出力手段７０にスコアを送る際には、類似度から乖離度へ、または乖離度から類似度への変換処理を行ってから、出力手段７０にスコアを送るようにしてもよい。類似度と乖離度とは、数値の大小関係が逆であるので、変換処理は、この関係を逆転させる処理となるが、このような変換処理は、関数で行ってもよく、テーブルで行ってもよい。

具体的には、異常検知器６０による処理として、以下のような様々なタイプの処理を採用することができる。

＜異常検知器６０の構成／オートエンコーダを用いるタイプ１の場合：図６＞

タイプ１の処理は、図６に示すように、前段の状態推定器５０から抽出した特徴データについて、オートエンコーダを用いて、元に戻ったか否かを判定する処理である。オートエンコーダは、ニューラル・ネットワークにおいて、入力層と出力層に同じデータを用いて教師あり学習を行って構築された判定器である。オートエンコーダの各層の次元数は、例えば、２５６次元→１２８次元→６４次元→３２次元→６４次元→１２８次元→２５６次元のようになり、次元圧縮が行われるが、層数や各層の次元数は、機器２０の種別や特徴データの大きさや状態に応じて定めればよい。

より具体的には、前段の状態推定器５０で繰り返し抽出した抽出時刻の異なる複数の時系列の特徴データ（状態推定器５０における連続する複数回のパターン認識処理で得られた複数時刻の特徴データ）を、その発生順に、Ｆ１，Ｆ２，Ｆ３，Ｆ４，Ｆ５，…であるとする。後段の異常検知器６０は、運用時に、このような時系列の特徴データＦ１，Ｆ２，…の中から、直近の一定期間である切出区間Ｃに含まれる複数（Ｋ個）の特徴データを切り出して異常検知器６０に入力する。但し、タイプ１の場合、複数（Ｋ個）の特徴データを、まとめて同時にオートエンコーダに入力するのではなく、１つずつ特徴データを入力する。また、複数（Ｋ個）の特徴データを１つずつオートエンコーダに入力する際に、複数（Ｋ個）の特徴データの中での入力の順序は問わず、時系列は考慮しなくてよい。なお、Ｋ＝１個としてもよいが、異常検知の精度向上の観点からは、複数の特徴データを用いることが好ましい。

また、運用時における切出区間Ｃによる切出処理は、時系列の特徴データがＦ１，Ｆ２，Ｆ３，Ｆ４，…（Ｋ個＝例えば１００個）であるとすれば、（Ｆ１，Ｆ２，…，Ｆ１００）、（Ｆ２，Ｆ３，…，Ｆ１０１）のように、１つずつずらしながら切り出してもよく、（Ｆ１，Ｆ２，…，Ｆ１００）、（Ｆ１０１，Ｆ１０２，…，Ｆ２００）のように、重なりなく切り出してもよく、あるいは、（Ｆ１，Ｆ２，…，Ｆ１００）、（Ｆ１１，Ｆ１２，…，Ｆ１１０）のように、重なりはあるが、ずらし量が１つではなく、２以上である切り出しを行ってもよい。

学習時には、目的動作Ｘでの正常な稼働時における多数（運用時におけるＫ個よりも多い数）の学習用の特徴データを用いて、目的動作Ｘ用のオートエンコーダのパラメータを決定し、これを第１の異常検知モデル６２Ｘとする。この学習では、オートエンコーダ（ニューラル・ネットワーク）の入力層および出力層に同じ特徴データを入力することにより、入力層に入力した特徴データが、出力層で元に戻るようになるパラメータを決定する。

この際、第１の異常検知モデル６２Ｘの学習に用いる特徴データは、前段の状態推定器５０に、目的動作Ｘで正常に稼働している際の状態データを入力し、その状態推定器５０から抽出した特徴データである。状態推定器５０が複数のパターン認識器で構成されている場合には、対応するパターン認識器から抽出した特徴データでなければならない。従って、図４では、状態推定器５０は、１つのパターン認識器（マルチタスクＣＮＮ）で構成されているので、目的動作Ｘで正常に稼働している際の状態データを、その唯一のパターン認識器に入力し、そこから抽出した特徴データを学習用データとして用いればよいが、図４中の２点鎖線で示すように、特徴データを非共有部から抽出する場合には、第１のタスク用（目的動作Ｘ用）の非共有部から抽出した特徴データでなければならない。また、図５では、状態推定器５０は、複数（３つ）のパターン認識器５０Ｘ，５０Ｙ，５０Ｚで構成されているので、目的動作Ｘで正常に稼働している際の状態データを、第１（目的動作Ｘ用）のパターン認識器５０Ｘに入力し、そこから抽出した特徴データを学習用データとして用いなければならない。

また、第２の異常検知モデル６２Ｙの学習、第３の異常検知モデル６２Ｚの学習に用いる特徴データも同様であり、目的動作Ｙ，Ｚで正常に稼働している際の状態データを、前段の状態推定器５０における対応するパターン認識器に入力し、そこから抽出した特徴データを学習用データとして用いる。

そして、学習を行って決定したＸ用、Ｙ用、Ｚ用のオートエンコーダのパラメータを、第１の異常検知モデル６２Ｘ、第２の異常検知モデル６２Ｙ、第３の異常検知モデル６２Ｚとして、異常検知器６０を構成する異常検知モデル記憶手段６２に記憶させておく。

前述したように、運用時には、複数個（Ｋ個）の特徴データを、Ｘ用、Ｙ用、Ｚ用のオートエンコーダに入力するので、目的動作Ｘ，Ｙ，Ｚのいずれの場合でも、オートエンコーダへの入力ベクトル（入力した特徴ベクトル）と、オートエンコーダからの出力ベクトルとを用いて算出された複数個（Ｋ個）のサブスコアが得られる。

このサブスコアの算出では、例えば、入力ベクトルと出力ベクトルとの対応する次元の数値を用いて、２乗平均誤差を算出することができる。すなわち、入力ベクトル＝（Ｕ（１），Ｕ（２），…，Ｕ（Ｍ））、出力ベクトル＝（Ｖ（１），Ｖ（２），…，Ｖ（Ｍ））とすると、これらの２つのＭ次元ベクトルの２乗平均誤差は、｛（Ｕ（１）－Ｖ（１））^２＋（Ｕ（２）－Ｖ（２））^２＋…＋（Ｕ（Ｍ）－Ｖ（Ｍ））^２｝／Ｍとなる。この２乗平均誤差の算出は、前述した特許文献２に記載された算出方法と同じである。また、サブスコアの算出方法は、これに限定されるものではなく、例えば、入力ベクトルと出力ベクトルとのコサイン類似度等としてもよく、要するに、入力ベクトルと出力ベクトルとの類似度または乖離度を示すことができればよい。

そして、運用時には、複数個（Ｋ個）のサブスコアを用いて、例えば平均値や合計値等の算出によりスコアを算出し、算出したスコアを、出力手段７０に送るか、または、算出したスコアと閾値との比較判定を行い、動作制御の異常の有無（正常であるか否か）の判定結果を、出力手段７０に送る。

また、サブスコアの段階で閾値との比較を行うことにより、動作制御の異常の有無（または正常であるか否か）についてのＫ個の判定結果を出し、それらのＫ個の判定結果を用いて、正常または異常の確率を求め、その確率を出力手段７０に送ってもよく、あるいは、Ｋ個の判定結果のうちの幾つが正常または異常であるかの閾値を設定しておき、その閾値との比較を行うことにより、動作制御の異常の有無（または正常であるか否か）についての最終的な判定結果を出し、出力手段７０に送ってもよい。

＜異常検知器６０の構成／切出区間Ｃの特徴データの集合を分布として捉えて分布間の類似度（乖離度）を求めるタイプ２の場合：図７＞

タイプ２の処理は、図７に示すように、予め用意されて異常検知モデル記憶手段６２に記憶されている正常な動作制御を行っている際の特徴データの分布と、運用時に抽出した複数（Ｋ個）の特徴データの分布との類似度（乖離度）を算出する処理である。

タイプ２では、学習時および運用時の双方で、特徴データの集合を分布として捉える。但し、分布の標本数は、学習時と運用時とで異なり、運用時は、時間軸上で移動する切出区間Ｃ内のＫ個の特徴データであるから、学習時に対し、相対的に少ない標本数である。

より具体的には、学習時にも運用時にも、Ｍ次元ベクトルである特徴データの集合を分布として捉え、それぞれの分布の代表値（代表ベクトル）を求める。すなわち、学習時には、目的動作Ｘ用、目的動作Ｙ用、目的動作Ｚ用の特徴データ（正常な状態で稼働している際の特徴データ）の各分布があるので、それらの各分布についての代表値を、別々に求める。そして、運用時には、切出区間Ｃ内のＫ個の特徴データ（Ｍ次元ベクトル）による分布があるので、その分布についての代表値を求める。この代表値（代表ベクトル）の次元数は、特徴データの次元数（Ｍ次元）と一致していてもよく、一致していなくてもよい。

分布の代表値（代表ベクトル）としては、様々なものを選択することができ、１つの代表値ではなく、複数の代表値の組合せとしてもよく、例えば、平均値、最頻値、中央値（メジアン）、標準偏差、分散の各ベクトル等を選択することができる。図７には、一例として、分布として正規分布を仮定し、平均ベクトルμおよび標準偏差ベクトルσの組合せが示され、いずれも次元数は、特徴データと同じであり、Ｍ次元ベクトルである。目的動作Ｘについては、（μＸ，σＸ）が求められ、目的動作Ｙについては、（μＹ，σＹ）が求められ、目的動作Ｚについては、（μＺ，σＺ）が求められる。そして、学習時に求められた各目的動作Ｘ，Ｙ，Ｚ用の分布の代表値（代表ベクトル）は、異常検知モデル記憶手段６２に記憶される。また、運用時も同様に、運用時の分布についての（μ，σ）が求められるが、目的動作Ｘ，Ｙ，Ｚのいずれであるかが既知であるため、既知である目的動作についての（μ，σ）、すなわち、（μＸ，σＸ）、（μＹ，σＹ）、（μＺ，σＺ）のいずれかが求められることになる。

なお、ここでは、分布の代表値は、代表ベクトルとしているが、スカラ値でもよく、あるいは、行列やテンソル量でもよい。

以上のように、運用時において、切出区間Ｃ内のＫ個の特徴データによる分布の代表値（代表ベクトル）が得られるとともに、事前の学習により各目的動作Ｘ，Ｙ，Ｚ用の特徴データの分布の代表値（代表ベクトル）が予め求められて異常検知モデル記憶手段６２に記憶されている状況下では、代表値（代表ベクトル）間の類似度を算出することができる。

すなわち、運用時には、目的動作Ｘ，Ｙ，Ｚのいずれであるかが既知であるため、既知である目的動作について求めた分布の代表値（代表ベクトル）（従って、（μＸ，σＸ）、（μＹ，σＹ）、（μＺ，σＺ）のいずれかとなる。）と、異常検知モデル記憶手段６２に記憶されている対応する目的動作（運用時における既知の目的動作と同じ目的動作）についての分布の代表値（代表ベクトル）との類似度（ＬＸ，ＬＹ，ＬＺのいずれか）を算出することができる。この際、類似度としては、例えば、正規分布を仮定し分布の代表値として平均ベクトルμおよび標準偏差ベクトルσが求められている場合は、ＫＬダイバージェンス（ＫＬ距離）を用いることができる。また、例えば、ユークリッド距離やコサイン類似度等を用いてもよい。

そして、運用時において、算出した類似度（ＬＸ，ＬＹ，ＬＺのいずれか）がスコアとなるので、これを出力手段７０へ送るか、または、算出したスコアと閾値との比較判定を行い、その判定結果を、出力手段７０に送る。

＜異常検知器６０の構成／分布に対する尤度を算出するタイプ３の場合＞

タイプ３の処理は、抽出した特徴データについて、事前の学習で予め用意されて異常検知モデル記憶手段６２に記憶されている正常な動作制御を行っている際の特徴データの分布に対する尤度を算出する処理である。

より具体的には、学習時には、目的動作Ｘでの正常な動作制御を行っている際の多数の特徴データの分布を、第１の異常検知モデル６２Ｘとして異常検知モデル記憶手段６２に記憶させておく。同様に、目的動作Ｙ，Ｚでの正常な動作制御を行っている際の多数の特徴データの分布を、第２の異常検知モデル６２Ｙ、第３の異常検知モデル６２Ｚとして異常検知モデル記憶手段６２に記憶させておく。さらに、分布に対する尤度についての閾値をパーセンタイル（百分位数）等で設定しておく。この閾値は、目的動作Ｘ，Ｙ，Ｚ毎に異なっていてもよく、同じでもよい。分布を構成する多数の特徴データが正常な状態を示すデータである場合には、分布に対する尤度が高い（大きい）と正常であり、低い（小さい）と異常であることになる。

運用時には、目的動作Ｘ，Ｙ，Ｚのいずれであるかが既知であるため、既知である目的動作での稼働時の特徴データが得られるが、正常・異常の別は不明である。そして、得られた１つの特徴データについて、異常検知モデル記憶手段６２に記憶されている対応する目的動作（運用時における既知の目的動作と同じ目的動作）についての分布に対する尤度を求め、求めた尤度と、閾値との比較判定を行うことにより、動作制御の異常の有無（または正常であるか否か）についての判定結果を出し、その判定結果を出力手段７０に送る。

また、運用時には、複数（Ｋ個）の特徴データについて、上述した分布に対する尤度をそれぞれ求め、これらをサブスコアとし、複数（Ｋ個）のサブスコアを用いて、例えば平均値や合計値等の算出によりスコアを算出し、算出したスコアを、出力手段７０に送るか、または、算出したスコアと閾値との比較判定を行い、動作制御の異常の有無（正常であるか否か）の判定結果を、出力手段７０に送ってもよい。

さらに、運用時には、複数（Ｋ個）の特徴データについて、上述した分布に対する尤度をそれぞれ求め、それぞれの尤度と閾値との比較判定を行うことにより、動作制御の異常の有無（または正常であるか否か）についてのＫ個の判定結果を出し、それらのＫ個の判定結果を用いて、正常または異常の確率を求め、その確率を出力手段７０に送ってもよく、あるいは、Ｋ個の判定結果のうちの幾つが正常または異常であるかの閾値を設定しておき、その閾値との比較判定を行うことにより、動作制御の異常の有無（または正常であるか否か）についての最終的な判定結果を出し、出力手段７０に送ってもよい。

＜異常検知器６０の構成／切出区間Ｃの特徴データの集合をベクトル化してベクトル間の類似度を求めるタイプ４の場合：図８＞

タイプ４の処理は、事前の学習で予め用意されて異常検知モデル記憶手段６２に記憶されている正常な動作制御を行っている際の混合ガウスモデルを構成するガウス分布の平均ベクトルを連結して形成した高次元のスーパーベクトルまたはこれを低次元化したｉベクタと、抽出した複数（Ｋ個）の特徴データを用いて算出したスーパーベクトルまたはｉベクタとの類似度（乖離度）を算出する処理である。

より具体的には、学習時に、各目的動作Ｘ，Ｙ，Ｚでの正常な動作制御を行っている際の多数の特徴データを用いて、最尤学習により、各目的動作Ｘ，Ｙ，Ｚの混合ガウスモデル（ＧＭＭ）、および全体のＧＭＭを構築する。全体のＧＭＭは、各目的動作Ｘ，Ｙ，Ｚでの正常な動作制御を行っている際の全ての特徴データ（目的動作Ｘでの正常な動作制御を行っている際の全ての特徴データ＋目的動作Ｙでの正常な動作制御を行っている際の全ての特徴データ＋目的動作Ｚでの正常な動作制御を行っている際の全ての特徴データ）を使った学習で得られるモデルであり、ユニバーサル・バックグランド・モデル（ＵＢＭ）である。各目的動作Ｘ，Ｙ，ＺのＧＭＭは、全体的・平均的な内容を示すＵＢＭに対し、各目的動作Ｘ，Ｙ，Ｚでの正常な動作制御を行っている際の特徴データの集合から得られる部分的な情報（例えば、目的動作Ｘだけの情報）を適応させたモデルである。

続いて、各目的動作Ｘ，Ｙ，ＺのＧＭＭ、および全体のＧＭＭのそれぞれについて、スーパーベクトル（ＳＶ）を作成する。このＳＶは、ＧＭＭを構成するガウス分布の平均ベクトルμを全て連結して形成した高次元ベクトルである。これにより、目的動作ＸのＧＭＭのＳＶ、目的動作ＹのＧＭＭのＳＶ、目的動作ＺのＧＭＭのＳＶ、および、全体のＧＭＭのＳＶが作成される。

それから、これらのＳＶを用いて、次の式に基づき、確率的因子分析を行うことにより、射影行列、および各目的動作Ｘ，Ｙ，Ｚのｉベクタを算出する。ｉベクタは、ＳＶよりも次元数の小さい低次元ベクトルであるが、このｉベクタの次元数は、本システムを構築するシステム管理者が、適切な次元を選択して決める。なお、ｉベクタに関する技術自体は公知技術である（非特許文献１参照）。

各目的動作Ｘ，Ｙ，ＺのＧＭＭのＳＶ＝全体のＧＭＭのＳＶ＋射影行列×各目的動作Ｘ，Ｙ，Ｚのｉベクタ

これにより、目的動作Ｘのｉベクタ、目的動作Ｙのｉベクタ、目的動作Ｚのｉベクタ、および、１つの射影行列が得られる。その後、各目的動作Ｘ，Ｙ，Ｚのｉベクタ、射影行列、および、全体のＧＭＭのＳＶを、異常検知モデル記憶手段６２に記憶させる。射影行列および全体のＧＭＭのＳＶを記憶させるのは、運用時のｉベクタを上記の式で算出する際に、これらを固定値として用いるからである。各目的動作Ｘ，Ｙ，Ｚのｉベクタが、Ｘ，Ｙ，Ｚ用の異常検知モデル６２Ｘ，６２Ｙ，６２Ｚに相当する。

なお、ｉベクタを算出せずに、学習時の処理をＳＶの算出までの処理とし、ＳＶを類似度の判定に用いてもよい。ＳＶを類似度の判定に用いる場合には、各目的動作Ｘ，Ｙ，ＺのＳＶを、異常検知モデル記憶手段６２に記憶させる必要があるが、運用時にｉベクタの算出は行わないので、全体のＧＭＭのＳＶを記憶させる必要はない。

運用時には、切出区間Ｃ内のＫ個の特徴データを用いて、運用時のＧＭＭを生成し、更に、この運用時のＧＭＭのＳＶを生成する。それから、生成した運用時のＳＶを、射影行列および全体のＧＭＭのＳＶの部分が固定値とされている状態（これらは、パラメータとして、異常検知モデル記憶手段６２から読み込まれる。）の前述した式に入力し、運用時のｉベクタを算出する（実際の計算はＥＭアルゴリズム等により行う）。

以上のように、運用時において、切出区間Ｃ内のＫ個の特徴データによる運用時のｉベクタが得られるとともに、事前の学習で各目的動作Ｘ，Ｙ，Ｚのｉベクタが予め求められて異常検知モデル記憶手段６２に記憶されている状況下では、ｉベクタ間の類似度を算出することができる。この際、類似度としては、例えば、コサイン類似度等を用いることができる。

この際、前者の運用時のｉベクタは、運用時には、目的動作Ｘ，Ｙ，Ｚのいずれであるかが既知であるため、既知である目的動作のｉベクタであるが、正常・異常の別は不明である。また、後者の異常検知モデル記憶手段６２には各目的動作Ｘ，Ｙ，Ｚのｉベクタが記憶されているが、運用時には、各目的動作Ｘ，Ｙ，Ｚのｉベクタのうちの対応する目的動作（運用時における既知の目的動作と同じ目的動作）のｉベクタだけが、運用時のｉベクタとの類似度の算出に用いられる。従って、運用時には、図８中の類似度ＲＸ，ＲＹ，ＲＺの全てが算出されるのではなく、いずれかが算出される。

そして、運用時において、算出した類似度（ＲＸ，ＲＹ，ＲＺのいずれか）がスコアとなるので、これを出力手段７０へ送るか、または、算出したスコアと閾値との比較判定を行い、その判定結果を、出力手段７０に送る。

＜異常検知器６０の構成／内部メモリを有するパターン認識器による時系列パターン認識処理を行うタイプ５の場合：図９＞

タイプ５の処理では、内部メモリを有するパターン認識器により、各目的動作Ｘ，Ｙ，Ｚでの動作制御が正常な状態であるか否かを識別する時系列パターン認識処理を行う。この時系列パターン認識処理を行うパターン認識器としては、例えば、リカレント・ニューラル・ネットワーク（ＲＮＮ）、隠れマルコフモデル（ＨＭＭ）等を採用することができる。ＲＮＮは、ある層の出力が、次回のその層に入力されて次回の処理に反映されるという構造を有するので、前回の処理結果を反映した出力を行うことができ、前回の処理結果は、更にその前の処理結果を反映していることから、前回以前の処理結果を反映する時系列パターン認識処理を実現している。

より具体的には、学習時には、目的動作Ｘでの正常な運転が行われている際の多数の特徴データおよびそれ以外の運転が行われている際の多数の特徴データを用いて、目的動作Ｘでの動作制御が正常な状態で行われているか否かを識別可能な目的動作Ｘ用の時系列パターン認識器のパラメータを決定し、第１（目的動作Ｘ用）の異常検知モデル６２Ｘとして異常検知モデル記憶手段６２に記憶させておく。それ以外の運転が行われている際の特徴データとしては、目的動作Ｙ，Ｚでの運転、または目的動作Ｘ，Ｙ，Ｚのいずれでもない過渡状態の運転が行われている際の特徴データ、あるいは類似タイプの機器の運転時の状態データやその加工データを前段の状態推定器５０に入力して得られた特徴データ等を用いることができる。

また、目的動作Ｙ，Ｚについても同様な学習を行い、目的動作Ｙ，Ｚ用の時系列パターン認識器のパラメータを決定し、第２（目的動作Ｙ用）の異常検知モデル６２Ｙ、第３（目的動作Ｚ用）の異常検知モデル６２Ｚとして異常検知モデル記憶手段６２に記憶させておく。

運用時には、前段の状態推定器５０を構成するパターン認識器のうちの対応するパターン認識器から抽出した特徴データを、時系列で（順番に）異常検知器６０に入力する。この際、運用時には、目的動作Ｘ，Ｙ，Ｚのいずれであるかが既知であるため、異常検知器６０を構成する複数（３つ）の異常検知モデル６２Ｘ，６２Ｙ，６２Ｚのうち、既知である目的動作用の異常検知モデルによる処理を行う。

例えば、目的動作Ｘでの制御中の場合には、目的動作Ｘでの運転中の状態データ（但し、正常・異常の別は不明）を、前段の状態推定器５０を構成するパターン認識器のうちの対応するパターン認識器（図４では、１つのマルチタスクＣＮＮであり、図５では、第１（目的動作Ｘ用）のパターン認識器５０Ｘである。）に入力し、そこから抽出した特徴データを、第１（目的動作Ｘ用）の異常検知モデル６２Ｘに入力する。

そして、運用時において、複数（３つ）の異常検知モデル６２Ｘ，６２Ｙ，６２Ｚのうちのいずれかの出力がスコアとなるので、これを出力手段７０へ送るか、または、算出したスコアと閾値との比較判定を行い、その判定結果を、出力手段７０に送る。

なお、異常検知器６０として、例えばＲＮＮを採用した場合には、ＲＮＮの内部構造により前回以前の処理結果を反映する構成とすることができるが、前段の状態推定器５０で繰り返し抽出した抽出時刻の異なる複数の時系列の特徴データ（状態推定器５０における連続する複数回のパターン認識処理で得られた複数時刻の特徴データ）を、まとめて後段の異常検知器６０に同時に入力してもよい。

＜異常検知器６０の構成／切出区間Ｃの特徴データの集合を１つずつ、内部メモリを有していない静的なパターン認識器に入力するタイプ６の場合：図１０＞

タイプ６の処理では、切出区間Ｃの特徴データの集合を１つずつ、内部メモリを有していない静的な（スタティックな）パターン認識器に入力することにより、各目的動作Ｘ，Ｙ，Ｚでの動作制御が正常な状態であるか否かを識別する静的なパターン認識処理を行う。静的なパターン認識処理を行うパターン認識器としては、例えば、単純なニューラル・ネットワーク（内部メモリを持たないＮＮ）、サポート・ベクター・マシン（ＳＶＭ）等を採用することができる。

前述したタイプ５で述べた、内部メモリを有するパターン認識器（例えば、ＲＮＮやＨＭＭ等）による時系列パターン認識処理は、内部メモリ（前回または前回以前の内部的処理結果を記憶する内部メモリ）を有することにより、内部構造的に系列モデリングを実現しているパターン認識器による処理であり、このようなパターン認識器では、内部メモリの情報が反映されるので、同じ入力が与えられたとしても、前後の入力が異なっている場合には常に同じ出力になるとは限らない。一方、タイプ６の処理は、内部メモリによる系列モデリングを行わない静的なパターン認識器による処理であり、このようなパターン認識器では、同じ入力に対し、前後の入力とは非依存で常に同じ出力結果が得られる。

より具体的には、学習時には、前述したタイプ５の場合と同様な学習処理を行うことにより、目的動作Ｘ，Ｙ，Ｚでの動作制御がそれぞれ正常な状態で行われているか否かを識別可能な目的動作Ｘ，Ｙ，Ｚ用の静的なパターン認識器のパラメータを決定し、第１（目的動作Ｘ用）の異常検知モデル６２Ｘ、第２（目的動作Ｙ用）の異常検知モデル６２Ｙ、第３（目的動作Ｚ用）の異常検知モデル６２Ｚとして異常検知モデル記憶手段６２に記憶させておく。

運用時には、前段の状態推定器５０を構成するパターン認識器のうちの対応するパターン認識器から抽出した複数（Ｋ個）の時系列の特徴データを、１つずつ異常検知器６０に入力する。但し、入力の際には、複数個（Ｋ個）の中での入力の順序は問わず、時系列は考慮しなくてよい。この際、運用時には、目的動作Ｘ，Ｙ，Ｚのいずれであるかが既知であるため、異常検知器６０を構成する複数（３つ）の異常検知モデル６２Ｘ，６２Ｙ，６２Ｚのうち、既知である目的動作用の異常検知モデルによる処理を行う。これにより、複数個（Ｋ個）のサブスコアが得られる。

例えば、目的動作Ｘでの制御中の場合には、目的動作Ｘでの運転中の状態データ（但し、正常・異常の別は不明）を、前段の状態推定器５０を構成するパターン認識器のうちの対応するパターン認識器（図４では、１つのマルチタスクＣＮＮであり、図５では、第１（目的動作Ｘ用）のパターン認識器５０Ｘである。）に入力し、そこから抽出した複数（Ｋ個）の特徴データを、１つずつ第１（目的動作Ｘ用）の異常検知モデル６２Ｘに入力する。これにより、第１（目的動作Ｘ用）の異常検知モデル６２Ｘによる処理で、複数個（Ｋ個）のサブスコアが得られる。

＜出力手段７０の構成＞

出力手段７０は、異常検知器６０から出力された異常の有無の判定結果またはスコア（異常の程度を示すスコア）を用いて、異常検知結果を出力する処理を実行するものである。具体的には、出力手段７０は、異常検知結果の出力用データを、ネットワーク１を介してユーザ端末１００（またはユーザが管理する連携システムでもよい。）へ送信する処理、あるいは、必要に応じて管理者端末１１０へ送信する処理を実行する。また、出力手段７０は、本システムのユーザ（一般ユーザ、メンテンナンス業者・販売業者・メーカ等の作業員）または本システムの管理者が、異常検知処理装置３０（出力手段７０が設けられた装置）の設置場所の周辺にいる場合等には、異常検知結果を、異常検知処理装置３０に接続された表示装置（不図示）に画面表示するか、印刷装置（不図示）で印刷するか、スピーカ（不図示）で音声出力するか、または異常検知結果に応じた報知音若しくは報知光をブザーやランプ等の報知用機器（不図示）で出力する処理を実行してもよい。

ユーザ端末１００等への異常検知結果の出力用データの送信処理を行う場合には、送信する異常検知結果の出力用データは、主として画面表示用のデータとなるが、音声出力用のデータを加えてもよく、また、音声出力用のデータだけとしてもよい。また、送信タイミングは、出力手段７０側のタイミングでもよく、あるいは、ユーザ端末１００等からの要求に応じて送信してもよい。

具体的には、例えば、電子メール等により異常検知結果の出力用データを自動送信してもよく、電子メールの自動送信や自動架電等により異常検知処理装置３０へのアクセスを促し（例えば、アクセス先のＵＲＬを通知する等）、ユーザ端末１００等からの出力要求（主として画面表示要求）を受けてから、異常検知結果の出力用データを送信してもよい。なお、ユーザ端末１００等からの出力要求を受けてから送信する場合には、既に作成されている異常検知結果の出力用データ（出力用データ記憶手段（不図示）に記憶されている出力用データ）を送信してもよく、あるいは、出力要求を受けてから、スコア記憶手段（不図示）に記憶されている異常検知器６０の出力スコアや出力判定結果を用いて異常検知結果の出力用データを作成し、送信してもよい。

また、出力手段７０は、前段の状態推定器５０に入力された状態データ（付加されたデータ管理に必要となる情報を含む。状態データは、前処理を行う前後いずれのものでもよい。図３参照）、および、後段の異常検知器６０に入力された特徴データ（付加されたデータ管理に必要となる情報を含む。図３参照）を、ネットワーク１を介してデータ収集装置８０へ送信する処理も実行する。但し、メーカや一般ユーザ等の関係者の事情により、データ収集装置８０へのデータ送信が制限されているデータについては、送信は行われない。

本第１実施形態では、目的動作のみを考慮して異常検知を行う場合を説明しているので、出力手段７０による出力形式は、比較的簡易である。具体的には、例えば、目的動作Ｘ，Ｙ，Ｚのいずれかでの制御中に、動作制御が異常であるか否か（または正常である否か）を示す出力（画面表示等）を行うか、あるいは、異常である可能性が高い、異常である可能性がある、異常を疑ったほうがよい、詳細点検が必要である等のような異常の程度を示す出力（画面表示等）を行う。

＜データ収集装置８０の構成＞

データ収集装置８０は、１台または複数台のコンピュータ（サーバ）により構成され、データベースマネジメントシステム（ＤＢＭＳ）の機能を有するデータ収集手段８１と、データベース８２とを備えて構成されている。データベース８２は、状態推定器５０に入力された状態データ等を記憶する状態推定器学習用データ記憶手段８３と、異常検知器６０に入力された特徴データ等を記憶する異常検知器学習用データ記憶手段８４とを含んでいる。

ここで、データ収集手段８１は、データ収集装置８０を構成するコンピュータ本体の内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラムにより実現される。また、データベース８２は、例えば、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）等により実現される。

状態推定器学習用データ記憶手段８３には、図３に示すように、異常検知処理装置３０の出力手段７０によりネットワーク１を介して送信されてくる状態データ等、およびユーザ端末１００や管理者端末１１０からネットワーク１を介して送信されてくる状態データに付されるタグ情報（目的動作を示す情報以外のタグ情報）が記憶される。なお、タグ情報の一部（目的動作を示す情報を含む）は、異常検知に関する判定処理時における既知の情報として、出力手段７０からネットワーク１を介して送信されてくる。そして、状態データおよびそのタグ情報は、学習装置９０の状態推定器用学習手段９１による学習処理に利用される。

具体的には、状態推定器学習用データ記憶手段８３には、図３に示すように、例えば、状態データについてのデータ識別情報（データＩＤ）と、機器識別情報（機器の製造番号等）と、機器タイプ識別情報（機器の型番等）と、目的動作を示す情報と、機器稼働開始年月日および／または累積稼働回数を示すカウント値と、状態データについてのデータ取得日時（年月日・時分秒）と、少なくとも１つの状態データと、目的動作を示す情報以外のタグ情報とが記憶されている。そして、状態データには、（１）制御信号と、（２）外部入力データ（電源の電圧および／または電流の波形データを含む）と、（３）内部観測データ（フィードバック信号を含む）と、（４）外部観測データとがある。保存する状態データは、前処理を行う前後いずれのものでもよい。また、目的動作を示す情報以外のタグ情報は、動作制御が正常であったか否かの人による判定情報、動作環境等であり、ユーザ端末１００や管理者端末１１０から送信されてきた事後的に付与されたタグ情報でもよく、出力手段７０から送信されてきた異常検知に関する判定処理時における既知の情報としてのタグ情報でもよい。

また、異常検知器学習用データ記憶手段８４には、図３に示すように、異常検知処理装置３０の出力手段７０によりネットワーク１を介して送信されてくる特徴データ等、およびユーザ端末１００や管理者端末１１０からネットワーク１を介して送信されてくる特徴データに付されるタグ情報（目的動作を示す情報以外のタグ情報）が記憶される。なお、タグ情報の一部（目的動作を示す情報を含む）は、異常検知に関する判定処理時における既知の情報として、出力手段７０からネットワーク１を介して送信されてくる。そして、特徴データおよびそのタグ情報は、学習装置９０の異常検知器用学習手段９２による学習処理に利用される。

具体的には、異常検知器学習用データ記憶手段８４には、図３に示すように、例えば、特徴データについてのデータ識別情報（データＩＤ）と、機器識別情報（機器の製造番号等）と、機器タイプ識別情報（機器の型番等）と、目的動作を示す情報と、機器稼働開始年月日および／または累積稼働回数を示すカウント値と、特徴データについてのデータ取得日時（年月日・時分秒）（状態データについてのデータ取得日時で代用してもよい。）と、特徴データの取得元の状態推定器識別情報（状態推定器５０およびそれを構成するパターン認識器のバージョン番号等）と、特徴データと、目的動作を示す情報以外のタグ情報とが記憶されている。目的動作を示す情報以外のタグ情報は、動作制御が正常であったか否かの人による判定情報、動作環境等であり、ユーザ端末１００や管理者端末１１０から送信されてきた事後的に付与されたタグ情報でもよく、出力手段７０から送信されてきた異常検知に関する判定処理時における既知の情報としてのタグ情報でもよい。

なお、学習用データとなる状態データや特徴データの収集は、ネットワーク１を介したデータ収集装置８０での収集に限らず、例えば、メンテナンス業者・販売業者・メーカ等の作業員が、ＵＳＢメモリやＤＶＤ等の記録媒体を使い、機器２０の点検等の作業現場から持ち帰って収集してもよい。

＜学習装置９０の構成＞

学習装置９０は、１台または複数台のコンピュータ（サーバ）により構成され、状態推定器用学習手段９１と、異常検知器用学習手段９２とを備えて構成されている。ここで、各学習手段９１，９２は、学習装置９０を構成するコンピュータ本体の内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラムにより実現される。

状態推定器用学習手段９１は、データ収集装置８０の状態推定器学習用データ記憶手段８３に記憶された状態データおよびそのタグ情報を用いて、状態推定器５０用の学習処理を実行することにより、新たに状態推定モデル（ＣＮＮのパラメータ等）を作成し、作成したモデルで、状態推定モデル記憶手段５２に記憶された状態推定モデルを更新する処理を実行するものである。

異常検知器用学習手段９２は、データ収集装置８０の異常検知器学習用データ記憶手段８４に記憶された特徴データおよびそのタグ情報を用いて、異常検知器６０用の学習処理を実行することにより、新たに異常検知モデルを作成し、作成したモデルで、異常検知モデル記憶手段６２に記憶された異常検知モデルを更新する処理を実行するものである。

＜ユーザ端末１００、管理者端末１１０の構成＞

ユーザ端末１００、管理者端末１１０は、コンピュータにより構成され、例えばマウスやキーボード等の入力手段と、例えば液晶ディスプレイ等の表示手段とを備えている。これらの端末１００，１１０は、例えば、スマートフォンやタブレット端末等の携帯機器であってもよい。

＜異常検知処理の全体的な流れ＞

このような第１実施形態においては、以下のようにして制御状態監視システム１０により、機器２０の動作制御についての異常検知処理が行われる。

先ず、図１において、事前の学習により状態推定モデル（ＣＮＮのパラメータ等）を作成して状態推定器５０の状態推定モデル記憶手段５２に記憶させるとともに、異常検知モデル（分布、ＮＮのパラメータ等）を作成して異常検知器６０の異常検知モデル記憶手段６２に記憶させる。

この際、状態推定モデルは、目的動作Ｘ，Ｙ，Ｚでの正常な運転を行っている際の多数の状態データを用いて学習する。異常検知モデルは、学習で得られた状態推定モデルによる状態推定器５０に、目的動作Ｘ，Ｙ，Ｚでの正常な運転を行っている際の多数の状態データを入力し、その状態推定器５０から抽出した特徴データを用いて学習する。従って、異常検知モデルの学習に用いた特徴データが、状態推定器５０を構成するいずれのパターン認識器から抽出された特徴データであるのかが重要であり、その対応関係は、運用時にも維持される。

例えば、図４の場合には、状態推定器５０は、１つのマルチタスクＣＮＮにより構成されているので、複数（３つ）の異常検知モデル６２Ｘ，６２Ｙ，６２Ｚのいずれについても、１つのマルチタスクＣＮＮから抽出した特徴データを用いて学習を行う。一方、図５の場合には、状態推定器５０は、複数（３つ）のパターン認識器５０Ｘ，５０Ｙ，５０Ｚにより構成されているので、第１（目的動作Ｘ用）の異常検知モデル６２Ｘは、第１（目的動作Ｘ用）のパターン認識器５０Ｘから抽出した特徴データを用いて学習を行い、同様に、第２（目的動作Ｙ用）の異常検知モデル６２Ｙは、第２（目的動作Ｙ用）のパターン認識器５０Ｙから抽出した特徴データを用いて学習を行い、第３（目的動作Ｚ用）の異常検知モデル６２Ｚは、第３（目的動作Ｚ用）のパターン認識器５０Ｚから抽出した特徴データを用いて学習を行う。

続いて、運用時には、機器２０の利用者が、目的動作の指示を機器２０の制御部２２に与える。例えば、目的動作Ｘが指示で与えられた場合には、制御部２２により動作部２１に対し、目的動作Ｘでの動作制御が開始される。

目的動作Ｘでの動作制御中には、目的動作取得手段２５により制御部２２から目的動作を示す情報（目的動作Ｘ）が取得され、各状態データおよび目的動作を示す情報（目的動作Ｘ）が接続装置２６に送信され、さらにネットワーク１を介して異常検知処理装置３０へ送信される。

異常検知処理装置３０では、状態データ取得手段４０により、各状態データおよび目的動作を示す情報（例えば、目的動作Ｘ）を受信し、必要な場合には、前処理手段４１により周波数分析等の前処理を行い、前処理を行った状態データを、状態推定器５０に入力する。従って、この時点で、目的動作は、既知の情報（例えば、目的動作Ｘ）である。なお、目的動作は、機器２０の利用者が自分でわかっているので、ユーザ端末１００からネットワーク１を介して異常検知処理装置３０の状態データ取得手段４０に送信してもよい。

目的動作Ｘでの動作制御中において、状態データを状態推定器５０に入力する際には、図４の場合は、状態推定器５０を構成するマルチタスクＣＮＮに入力する。一方、図５の場合は、目的動作Ｘが既知であるため、第１（目的動作Ｘ用）のパターン認識器５０Ｘに入力する。

それから、状態推定器５０を構成するパターン認識器の中間層出力を、特徴データとして抽出する。図５の場合は、第１（目的動作Ｘ用）のパターン認識器５０Ｘの中間層出力を、特徴データとして抽出する。

続いて、状態推定器５０から抽出した特徴データを、異常検知器６０に入力する。この際、目的動作（例えば、目的動作Ｘ）が既知であるため、第１（目的動作Ｘ用）の異常検知モデル６２Ｘによる処理器に入力する。

さらに、異常検知器６０から異常検知に関する判定結果またはスコアが出力され、その判定結果またはスコアが、出力手段７０に送られる。そして、出力手段７０により、ユーザ端末１００や管理者端末１１０で、異常検知結果の出力（画面表示等）が行われる。また、出力手段７０により、状態データや特徴データが、それらのタグ情報である目的動作を示す情報（例えば、目的動作Ｘ）とともに、データ収集装置８０に送信される。

その後、ユーザ（一般ユーザ、メンテナンス業者・販売業者・メーカ等の作業員）は、ユーザ端末１００を操作し、データ収集装置８０に記憶されている状態データや特徴データに対し、可能な範囲でタグ情報を付す。タグ情報としては、動作制御が正常であったという情報や、後述する第２実施形態における動作環境等である。また、ユーザは、出力手段７０による異常検知結果の出力の際に、既知の情報（その時点で判明している情報）や動作制御が正常であるという情報（正常だと確信が持てる場合）を、出力手段７０に入力してもよく、そこで入力された既知の情報や動作制御が正常であるという情報は、出力手段７０により、タグ情報としてデータ収集装置８０に送信され、記憶される。なお、タグ情報の付与は、本システムの管理者が、管理者端末１１０を操作して行ってもよい。

それから、データ収集装置８０に、状態データや特徴データ、およびそれらのタグ情報が、ある程度、溜まった段階で、学習装置９０による学習処理を行い、状態推定モデル記憶手段５２に記憶されている状態推定モデルの更新や、異常検知モデル記憶手段６２に記憶されている異常検知モデルの更新を行う。

＜第１実施形態の効果＞

このような第１実施形態によれば、次のような効果がある。すなわち、本実施形態の制御状態監視システム１０では、前段の状態推定器５０および後段の異常検知器６０の２段階の構成で異常検知を行うので、前段の状態推定器５０を構成する状態推定モデルと、後段の異常検知器６０を構成する異常検知モデルとを独立して管理することができる。

従って、後段の異常検知モデルの更新を、前段の状態推定モデルの更新から切り離すことができるので、前段の状態推定モデルを更新しなくても、後段の異常検知モデルを更新することや、後段の異常検知モデルを追加することができる。前段の状態推定モデルの更新では、学習用データとして状態データが必要となるが、後段の異常検知モデルの更新では、前段の状態推定モデルを用いたパターン認識処理で得られた特徴データがあれば、状態データが無くても、学習を行うことができるからである。このため、状態データの収集が困難な場合でも、異常検知モデルの更新を行い、システムの性能向上を図ることができる。

状態データの収集が困難な場合が生じるのは、機器２０が、様々な立場の者（メーカ、販売業者、一般ユーザ等）の管理下に置かれることがあり、そこには様々な事情が存在するからである。しかし、状態データが、機器２０から直接に得られるデータ（センサデータ等）であるのに対し、特徴データは、それだけでは何を意味するのか判らないデータであるため、機器２０の管理者にとっては、状態データの提供が困難な場合であっても、特徴データの提供は可能な場合がある。従って、異常検知モデルの学習用データである特徴データの収集は、状態データの収集に比べて容易に行うことができる。

また、後段の異常検知モデルは、特徴データがあれば、状態データが無くても、学習を行うことができるので、前段の状態推定モデルをそのまま変えることなく、新たな異常検知モデルを追加することができる。このため、前段の状態推定モデルが変わっていなくても、その状態推定モデルを用いたパターン認識処理で新たな状態を捉えた特徴データが得られれば、その特徴データを用いた学習を行うことにより新たな異常検知モデルを作成することができ、その異常検知モデルの追加により、新たな観点でのクラス識別処理、外れ値検知処理、または新規性検知処理を行うことができる。従って、異常検知の幅（異常検知処理で判定できる内容の幅）を広げることができる。この際、状態データの収集が困難な場合でも、異常検知モデルの追加を行うことができるというのは、上述した異常検知モデルの更新の場合と同様である。

このような異常検知モデルの追加は、特に、後述する第３、第４実施形態において顕著な効果を発揮するが、本第１実施形態では、それを実現可能にする基礎構成を説明している。なお、新たな目的動作用の異常検知モデルの追加が可能な場合もある。例えば、目的動作Ｘ，Ｙ，Ｚが既にある状態で、新たな目的動作Ｗが機器２０に設定されたときに、前段の状態推定モデルをそのまま変えることなく、目的動作Ｗ用の後段の異常検知モデルを追加可能な場合（目的動作Ｗでの正常な稼働状態の特徴を効果的に捉えることができる場合）もある。

さらに、異常検知モデルの追加が可能なことからも明らかであるが、前段の状態推定モデルと、後段の異常検知モデルとは、１対１の対応関係である必要はなく、１対多でもよい。つまり、１つの状態推定モデルによるパターン認識処理で得られた特徴データは、複数の異常検知モデルによる処理で使用することができる。例えば、図５は、１対１の対応関係であるが、図４は、１対多の対応関係である。また、１対多の対応関係は、前段の状態推定モデルおよび後段の異常検知モデルの双方が初期モデルの時期に形成されていてもよく、後からの異常検知モデルの追加により、形成されてもよい。例えば、図４の場合に、新たな目的動作Ｗ用の異常検知モデルの追加が可能な場合もある。

また、前段の状態推定モデルが複数用意されていてもよく、この場合、モデルの数だけ見れば、多対多になるが、ある１つの前段の状態推定モデルから見ると、後段の複数の異常検知モデルが対応していてもよいのに対し、ある１つの後段の異常検知モデルから見ると、その後段の異常検知モデルに対応する前段の状態推定モデルは１つである。例えば、図５は、モデルの数だけ見れば、多対多（３対３）になるが、１対１の対応関係が複数（３つ）ある状態である。図４および図５を組み合わせた構成としてもよく、この場合は、１対多の対応関係と、１対１の対応関係とが混在することになる。

このような対応関係が構築されるのは、ある１つの後段の異常検知モデルを学習する際には、ある１つの前段の状態推定モデルによるパターン認識処理で得られた特徴データを用いた学習を行うので、学習に用いた特徴データを抽出した状態推定モデルが、後段の異常検知モデルに対応する前段の状態推定モデルとなり、運用時にも、対応する状態推定モデルで得られた特徴データを、対応する異常検知モデルに入力することになるからである。

そして、制御状態監視システム１０では、製品の製造・検査時の観測情報を用いて学習することで、個体差（同型の異なる機器同士の差）や設置環境の相違を吸収した頑健な状態推定モデルを構築することができる。加えて、前段の状態推定モデルを変えることなく、後段の異常検知モデルの更新や追加を行うことができるので、個体差や設置環境の影響が大きい機器２０の場合には、前段の状態推定器で、グルーバルな状態推定モデルを事前に用意しておき、その後、後段の異常検知器で、実働環境下での比較的少量の学習用の特徴データ（但し、比較的少量といっても、運用時に異常検知結果を１回出力するのに用いられる特徴データの個数よりは多い。）を用いたモデルの適応技術により、一部の機器２０の状況や設置環境に依存した異常検知モデルの構築を行うことができる。

すなわち、特定の状況下で得られた特徴データを用いた学習により、特定の状況下に置かれた機器２０にだけ適用可能な、または適用する意義のある異常検知モデルを構築し、運用時には、機器２０が当該特定の状況下にあることが既知であることを前提として、その異常検知モデルを用いるか、あるいは、機器２０が当該特定の状況下にあることを仮定した状態で、その異常検知モデルを用いて異常検知を行うことができる。後者の特定の状況下にあることを仮定した状態というのは、例えば「もし機器２０が、～という状況に置かれていた場合には、～である可能性が高い。」等のような条件付きの異常検知結果を出力する場合である。このような一部の機器２０の状況や設置環境に依存した異常検知モデルの構築は、前述したように、前段の状態推定モデルと、後段の異常検知モデルとが、１対多の対応関係を許容することから可能になる。

より具体的には、特定の状況には、様々な状況があり、後述する第２実施形態の動作環境、第３実施形態の故障発生予兆の有無、第４実施形態の累積稼働回数・時間も含まれるが、その他の例を挙げれば、例えば、標高を閾値として機器２０が高地または低地に設置されている場合を区別して学習すると、外気圧の高低に依存する異常検知モデルを構築することができる。つまり、同じ目的動作Ｘ用の異常検知モデルであっても、高地用の異常検知モデルと、低地用の異常検知モデルとを構築することができる。機器２０の種別によっては、動作制御の状態が外気圧の高低に影響される場合もあり得るからである。

同様に、機器２０が高緯度または低緯度の地方に設置されている場合を区別して学習すると、外気温の平均値の高低に依存する異常検知モデルを構築することができる。冬と夏といった季節の差でも同じである。さらに、雨の日、晴れの日の区別や、湿度の高低の差でもよい。

また、海辺に設置されているか否かの区別で、塩害の影響を考慮した異常検知モデルを構築することができる。

さらに、同型の機器２０でも、機器２０を使用するエンドユーザの業種の相違により、使用方法が異なる場合もあるので、エンドユーザの業種に依存する異常検知モデルを構築してもよい。

また、機器２０が、自動車・電車・飛行機・船舶等の移動体に設置されて使用されるのか、固定した場所に設置されて使用されるかの区別により、振動の影響を考慮した異常検知モデルを構築してもよい。

さらに、機器２０で実際に発生する状態の頻度の高低とは無関係に、従って、たとえ発生頻度の低い状態であっても、その状態を示す学習用データである特徴データが得られれば、その状態を識別可能な異常検知モデルを構築することができる。

そして、機器２０の設置環境の改善や、機器２０の改良（型番が変わる程の大きな改良ではなく、マイナーチェンジ）等により、そのような発生頻度の低い状態を識別可能な異常検知モデルが不要になった場合には、後から異常検知モデルを削除することもできる。削除しても前段の状態推定モデルに変化はなく、それに対応する後段の異常検知モデルの数が少なくなるだけであるから、システムは正常に機能することになる。このように異常検知モデルの削除を行うことができることも、前段の状態推定モデルと、後段の異常検知モデルとが、１対多の対応関係を許容することから可能になる。

また、制御状態監視システム１０では、正常状態にある状態データや特徴データだけで学習を行うことができる。このため、異常状態にある状態データや特徴データを学習用データに含める必要がない。この点は、前述した特許文献１に記載された異常判定システムと同様である。但し、異常状態にある状態データや特徴データを用いて学習を行ってもよい。

さらに、制御状態監視システム１０では、状態推定器５０への入力データに、電源２３の電圧および／または電流の波形データ（周波数分析を行う場合を含む）を含めることができるので、機器２０の負荷（交流の場合のインピーダンスや、直流の場合の抵抗）、負荷力率、ノイズとして発生するリップル電流（電流の中に含まれている脈動の成分）等の変化を捉え、異常検知を行うことができる。

また、制御状態監視システム１０では、ニューラル・ネットワークの中間層出力を抽出する構成とされているので、最終層（出力層）出力を抽出する場合に比べ、特徴データを用いた処理を行う後段の異常検知器６０に対し、その後段の処理に有効な情報を特徴データとして入力することができる。すなわち、最終層（出力層）の出力データは、制御実行中の動作部２１の実際の動作状態が、制御の目的動作を示す状態になっているか否かまたは制御の達成度を示すだけのデータであり、情報量が少なく、後段の処理で利用可能な情報が欠落している場合があるので、ニューラル・ネットワークの入力層に入力される状態データ（非常に多くの情報量）から、最終層（出力層）の出力データ（かなり絞り込まれた情報量）に至るまでのネットワーク上に存在する中間的な情報量を抽出し、後段の処理で利用することができる。また、最終層（出力層）の出力データは、情報量が少ないので、その判別結果が誤っていた場合には、後段の処理に与える影響が大きいが、中間層出力を後段の処理で利用すれば、影響を小さくすることができる。

［第２実施形態］

第２実施形態の制御状態監視システム１０では、目的動作に加え、動作環境を考慮して機器２０の動作制御の状態監視を行う。図１１には、前段の状態推定を１つのパターン認識器で行う場合（ケースＣ２－１）が示され、図１２には、前段の状態推定を細分化した複数のパターン認識器で行う場合（ケースＣ２－２）が示され、図１３には、前段の状態推定を適度な数に分散した複数のパターン認識器で行う場合（ケースＣ２－３）が示されている。

＜動作環境の詳細＞

機器２０の動作環境には、通常の健全な動作環境（好ましい動作環境）と、人為的に作り出された動作環境とがある。人為的に作り出された動作環境は、好ましくない動作環境であり、そのまま放置すると機器２０の故障に繋がる可能性や、機器２０の寿命を縮める可能性のある動作環境等である。

好ましくない動作環境は、機器２０の長期間稼働により生じるような動作環境であるから、少なくとも初期モデルの構築時には、そのような動作環境下での状態データや特徴データが自然に得られていることは殆どなく、特に、新製品の初期モデルの構築時には、入手し得ないデータである。既存の製品について、制御状態監視システム１０を後発的に開発する場合には、入手できる可能性はゼロではないが、システム開発前にモデルの構築を前提としてタグ付けされた学習用データが収集されることはないので、入手できるのは、極めて稀なケースである。つまり、システム開発前は、そもそもデータを収集する動機付けがなく、さらには収集できたとしても、事後的にタグ情報を付すのは困難である。そこで、本第２実施形態では、そのような好ましくない動作環境を人為的に作り出し、モデルを構築する。人為的に作り出す作業は、例えば、メーカ、販売業者、保守・点検業者、廃棄物処理業者等の作業員が、システム開発（モデル構築）の協力者として行ってもよく、本システムの管理者が行ってもよい。

具体的には、動作環境としては、通常の健全な動作環境も含めて挙げると、次のようなものがある。例えば、動作環境Ａ１＝機器２０に含まれるオイルが汚れていない（健全な動作環境）、動作環境Ａ２＝オイルが汚れている等がある。動作環境Ａ２は、事前に用意しておいた劣化したオイルを人為的に充填すればよい。また、オイルの濁度を、３段階以上にして、動作環境Ａ１，Ａ２，Ａ３，…としてもよい。

また、機器２０の内部ガス濃度についての動作環境がある。例えば、動作環境Ｂ１＝特定の気体が充填されている（健全な動作環境）、動作環境Ｂ２＝特定の気体が充填されていない等がある。動作環境Ｂ２は、特定の気体を人為的に抜いて、別の気体（空気等）を充填したり、真空に近い状態を作ればよい。また、真空の状態が健全な動作環境であれば、気体（空気等）を充填すればよい。内部ガス濃度を、３段階以上にして、動作環境Ｂ１，Ｂ２，Ｂ３，…としてもよい。

さらに、機器２０のボルトやネジの外れの有無についての動作環境がある。例えば、動作環境Ｃ１＝ボルトやネジが外れていない（健全な動作環境）、動作環境Ｃ２＝ボルトやネジが少なくとも１本は外れている等がある。動作環境Ｃ２は、ボルトやネジを人為的に取り外せばよい。動作環境Ｃ１＝ボルトやネジが外れていない（健全な動作環境）、動作環境Ｃ２＝１～２本外れている、動作環境Ｃ３＝３本以上外れている等のように、３段階以上にしてもよい。

また、機器２０の一部に亀裂が入っているか否かの動作環境がある。例えば、動作環境Ｄ１＝機器２０のどこにも亀裂は入っていない（健全な動作環境）、動作環境Ｄ２＝機器２０の一部に亀裂が入っている等がある。動作環境Ｄ２は、亀裂の入った部品と人為的に交換すればよい。亀裂の個所の数に応じ、３段階以上の動作環境Ｄ１，Ｄ２，Ｄ３，…としてもよい。

さらに、機器２０に汚れが付いていて動作が悪くなっているか否かの動作環境がある。例えば、動作環境Ｅ１＝機器２０に汚れは付いていない（健全な動作環境）、動作環境Ｅ２＝機器２０に汚れが付いていて動作が悪くなっている等がある。動作環境Ｅ２は、特定の場所に汚れた油を塗布する等により実現すればよい。汚れの付着個所の数の多少、付着範囲の広狭、付着量の多少により、３段階以上の動作環境Ｅ１，Ｅ２，Ｅ３，…としてもよい。

＜前段の状態推定を１つのパターン認識器で行う場合（ケースＣ２－１）：図１１＞

図１１において、状態推定器５０は、一例として、１つのマルチタスクＣＮＮにより構成されている。この例では、複数（第１～第１２）のタスクは、すべて２クラス分類としているが、３クラス以上の分類としてもよい。例えば、動作環境Ｂ１，Ｂ２，Ｂ３の識別タスクとする等である。

第１～第４のタスクは、いずれも目的動作Ｘ用のタスクであり、第１のタスクは、目的動作Ｘにおける動作環境Ａ１，Ａ２の識別タスクであり、第２のタスクは、目的動作Ｘにおける動作環境Ｂ１，Ｂ２の識別タスクであり、第３のタスクは、目的動作Ｘにおける動作環境Ｃ１，Ｃ２の識別タスクであり、第４のタスクは、目的動作Ｘにおける動作環境（Ａ２＋Ｂ２＋Ｃ２）とそれ以外との識別タスクである。

第４のタスクは、複数の動作環境Ａ２，Ｂ２，Ｃ２を組み合わせた動作環境であり、任意の組合せの動作環境とすることができ、各動作環境Ａ１，Ａ２，…、各動作環境Ｂ１，Ｂ２，…、各動作環境Ｃ１，Ｃ２，…、各動作環境Ｄ１，Ｄ２，…、各動作環境Ｅ１，Ｅ２，…等の総当たりの組合せの動作環境を用意してもよいが、システム構成の簡易化やモデル構築の容易性等から、実際の稼働において比較的高い頻度で発生しそうな組合せの動作環境を用意すればよい。

同様に、第５～第８のタスクは、いずれも目的動作Ｙ用のタスクであり、目的動作Ｘ用の第１～第４のタスクに対応している。また、第９～第１２のタスクは、いずれも目的動作Ｚ用のタスクであり、これらも目的動作Ｘ用の第１～第４のタスクに対応している。

また、第１～第１２のタスクに加え、前記第１実施形態の図４の第１～第３のタスク（目的動作Ｘ，Ｙ，Ｚ用のタスク）を用意してもよい。

異常検知器６０には、各目的動作Ｘ，Ｙ，Ｚと各動作環境Ａ１，Ａ２，Ｂ１，Ｂ２，Ｃ１，Ｃ２，（Ａ２＋Ｂ２＋Ｃ２）との全ての組合せに対応する異常検知モデルが用意されている。例えば、（Ｘ＋Ａ１）用の異常検知モデル、（Ｘ＋Ａ２）用の異常検知モデル、…、（Ｙ＋Ａ１）用の異常検知モデル、（Ｙ＋Ａ２）用の異常検知モデル、…等である。従って、図１１の例では、状態推定モデルと、異常検知モデルとは、１対多の対応関係となっている。

なお、例えば、（Ｘ＋Ａ１）については、Ａ１は、健全な動作環境であるから、（Ｘ＋Ａ１）のデータは、目的動作Ｘでの正常な動作制御が行われている際のデータであると言える。一方、（Ｘ＋Ａ２）については、Ａ２は、好ましくない動作環境であるから、（Ｘ＋Ａ２）のデータは、目的動作Ｘでの正常な動作制御が行われている際のデータであるとは言えないが、そのまま不都合なく運転を継続できる場合もあるので、異常時のデータであるとも言えず、放置すると将来的に故障の原因となり得る動作環境下で動作制御が行われている際のデータであると言える程度である。このように好ましくない動作環境下での運転を、異常と呼ぶか、正常と呼ぶか、異常ではないが正常とも言えないと捉えるかは、メーカやシステム管理者の基準に依るところとなる。

学習時には、これらのいずれの異常検知モデルについても、１つの状態推定モデルによる状態推定器５０（１つのマルチタスクＣＮＮ）から抽出された特徴データを用いて学習を行うことになる。

運用時には、全ての状態データが、１つのマルチタスクＣＮＮに入力されるが、そこから抽出された特徴データは、既知の情報である目的動作に対応する異常検知モデルのみに入力される。例えば、目的動作Ｘが既知であれば、（Ｘ＋Ａ１）用の異常検知モデル、（Ｘ＋Ａ２）用の異常検知モデル、…に入力されるが、（Ｙ＋Ａ１）用の異常検知モデル、（Ｙ＋Ａ２）用の異常検知モデル、…には入力されない。同様に、目的動作Ｙが既知であれば、（Ｙ＋Ａ１）用の異常検知モデル、（Ｙ＋Ａ２）用の異常検知モデル、…に入力されるが、（Ｘ＋Ａ１）用の異常検知モデル、（Ｘ＋Ａ２）用の異常検知モデル、…には入力されない。

また、図１１での記載は省略されているが、動作環境で既知のものがあれば、本システムのユーザ（機器２０を利用する一般ユーザ、あるいはメーカ・メンテナンス業者・販売業者等の作業員）が、異常検知処理装置３０に入力することができる。この入力情報（既知の動作環境）は、ユーザ端末１００を操作してネットワーク１を介して異常検知処理装置３０へ送信してもよく、ユーザが異常検知処理装置３０の設置個所の周辺にいれば、ボタン操作等により異常検知処理装置３０に入力してもよい。この入力が行われると、状態推定器５０や異常検知器６０による異常検知に関する判定処理で利用され、あるいは、出力手段７０による異常検知結果の出力処理に利用される。

例えば、ボルトやネジが外れているか否かは、一般ユーザでも把握することができ、オイルが汚れているか否かは、メーカ・メンテナンス業者・販売業者等の作業員が、点検等の際に確認することができ、あるいは知識のある一般ユーザであれば、普段でも（点検等の際でなくても）確認することができる。通常、ボルトやネジが外れていることを確認した場合には、ボルトやネジを締め、オイルが汚れていることを確認した場合には、オイルを交換して運転を再開することになるが、その前に、他に好ましくない動作環境があるか否かを本システムで確認するために、そのまま運転を継続し、本システムによる異常検知に関する判定処理を行う場合もある。このような場合には、ユーザによる既知の情報の入力に基づき、特徴データを入力する異常検知モデル（による処理器）を、より絞ることができる。例えば、オイルが汚れているか否かの既知の情報を入力すれば、目的動作Ｘが既知である場合には、（Ｘ＋Ａ１）用の異常検知モデル、および（Ｘ＋Ａ２）用の異常検知モデルによる処理器への特徴データの入力を省略することができる。また、オイルが汚れていなければ、動作環境Ａ１であり、Ａ２ではないので、（Ａ２＋Ｂ２＋Ｃ２）には該当しないことから、（Ａ２＋Ｂ２＋Ｃ２）用の異常検知モデルの使用も省略することができる。

出力手段７０には、異常検知器６０から複数のスコアまたは判定結果が送られ、それらを出力手段７０で統合して異常検知結果を出力するか、あるいは異常検知器６０で全部または一部を統合し、その統合結果を出力手段７０へ送信してもよい。

例えば、目的動作Ｘが既知である場合には、（Ｘ＋Ａ１）用の異常検知モデル、（Ｘ＋Ａ２）用の異常検知モデル、…による各処理器から、複数のスコアまたは判定結果が得られる。これをどのような形式でユーザ（一般ユーザ、あるいはメーカ・メンテナンス業者等の作業員）に対して出力するかは、メーカやシステム管理者等のポリシーに従うものとなる。

具体的には、例えば、（Ｘ＋Ａ１）用および／または（Ｘ＋Ａ２）用の異常検知モデルで、オイルが汚れていない（健全な動作環境）と判定され、かつ、（Ｘ＋Ｂ１）用および／または（Ｘ＋Ｂ２）用の異常検知モデルで、特定の気体が充填されている（健全な動作環境）と判定され、かつ、（Ｘ＋Ｃ１）用および／または（Ｘ＋Ｃ２）用の異常検知モデルで、ボルトやネジが外れていない（健全な動作環境）と判定され、さらに、（Ｘ＋Ａ２＋Ｂ２＋Ｃ２）用の異常検知モデルで、当該状態に該当しない（健全な動作環境）と判定された場合に、異常は確認できない（正常である）等の出力を行うことができる。その他の場合には、例えば、オイルが汚れている可能性がある、可能性が高い、オイルの交換時期です、オイルの交換を検討してください等の出力や、「～して下さい。このまま放置すると故障のおそれがあります。」等の出力を行うことができる。

また、矛盾するようなスコアや判定結果が得られた場合には、例えば、計測をやり直してください、制御状態を把握することができませんでした、～であるか否かが不明です等の出力を行ってもよい。例えば、（Ｘ＋Ａ１）用および（Ｘ＋Ａ２）用の各異常検知モデルから出力された尤度が、ともに大きい場合、オイルが汚れているのか否かの判定ができないので、上記のような出力を行ってもよい。

＜前段の状態推定を細分化した複数のパターン認識器で行う場合（ケースＣ２－２）：図１２＞

図１２において、状態推定器５０は、一例として、多数のパターン認識器（すべてシングルタスクＣＮＮ）により構成されている。この例では、各パターン認識器には、２クラス分類のものと、３クラス分類のものとがある。動作環境Ｂ１，Ｂ２，Ｂ３を識別可能なパターン認識器（シングルタスクＣＮＮ）が、３クラス分類となっている。なお、４以上のクラス分類のパターン認識器としてもよい。

異常検知器６０には、各目的動作Ｘ，Ｙ，Ｚと各動作環境Ａ１，Ａ２，Ｂ１，Ｂ２，Ｂ３，Ｃ１，Ｃ２，（Ａ２＋Ｂ２＋Ｃ２）との全ての組合せに対応する異常検知モデルが用意されている。例えば、（Ｘ＋Ａ１）用、（Ｘ＋Ａ２）用、（Ｘ＋Ｂ１）用、（Ｘ＋Ｂ２）用、（Ｘ＋Ｂ３）用、…、（Ｙ＋Ａ１）用、（Ｙ＋Ａ２）用、（Ｙ＋Ｂ１）用、（Ｙ＋Ｂ２）用、（Ｙ＋Ｂ３）用、…の異常検知モデル等である。

但し、図１２の例では、状態推定モデルと、異常検知モデルとは、１対１の対応関係になる場合と、１対１の対応関係にならない場合とがある。（Ｘ＋Ａ２＋Ｂ２＋Ｃ２）とそれ以外とを識別可能なパターン認識器の状態推定モデルに対応して、（Ｘ＋Ａ２＋Ｂ２＋Ｃ２）用の異常検知モデルが用意されているので、この場合は、１対１の対応関係である。つまり、状態推定モデルが２クラス分類のパターン認識器を構成しているが、対応する異常検知モデルの数は、２つではなく、１つであり、１対１の対応関係となっている。この対応関係は、前記第１実施形態の図５の場合と同様である。図５の場合も、目的動作Ｘでの正常な運転を行っている場合の異常検知モデルは用意しているが、それ以外の運転を行っている場合の異常検知モデルは用意していないので、１対１の対応関係となっている。

一方、例えば、（Ｘ＋Ａ１）と（Ｘ＋Ａ２）とを識別可能なパターン認識器の状態推定モデルに対応して、（Ｘ＋Ａ１）用および（Ｘ＋Ａ２）用の２つの異常検知モデルが用意されているので、この場合は、１対２の対応関係である。また、（Ｘ＋Ｂ１）と（Ｘ＋Ｂ２）と（Ｘ＋Ｂ３）とを識別可能なパターン認識器の状態推定モデルに対応して、（Ｘ＋Ｂ１）用、（Ｘ＋Ｂ２）用、（Ｘ＋Ｂ３）用の３つの異常検知モデルが用意されているので、この場合は、１対３の対応関係である。これらの場合、状態推定モデルがＮクラス分類のパターン認識器を構成していれば、対応する異常検知モデルの数は、クラス数と同じ数になり、１対Ｎの対応関係となる。４以上のクラス数でも同様である。仮に、図５の状態推定器５０を、目的動作Ｘ，Ｙ，Ｚを識別可能な１つのパターン認識器（１つのシングルタスクＣＮＮ）で構成すれば、３クラス分類のパターン認識器となり、対応する異常検知モデルの数は３つである（３つの異常検知モデル６２Ｘ，６２Ｙ，６２Ｚが用意されている。）から、クラス数と同じ数になり、１対３の対応関係となる。

図１２では、運用時には、前段の状態推定器５０側で、既知の状態に基づき、使用するパターン認識器の選択が行われる。例えば、目的動作Ｘが既知である場合には、状態データは、目的動作Ｘに関する識別を行うパターン認識器のみに入力される。従って、例えば、状態データは、（Ｘ＋Ａ１）と（Ｘ＋Ａ２）とを識別可能なパターン認識器には入力されるが、（Ｙ＋Ａ１）と（Ｙ＋Ａ２）とを識別可能なパターン認識器には入力されない。そして、後段の異常検知器６０側では、対応するパターン認識器から抽出された特徴データが、対応する異常検知モデルによる処理器にのみ入力される。

出力手段７０による出力は、図１１の場合と同様である。従って、例えば目的動作Ｘでの動作制御中には、その目的動作Ｘが既知であるので、目的動作Ｘに対応する各異常検知モデルによる処理器からのスコアや判定結果を用いた出力が行われる。

＜前段の状態推定を適度な数に分散した複数のパターン認識器で行う場合（ケースＣ２－３）：図１３＞

図１３において、状態推定器５０は、一例として、複数（適度に分散した数）のパターン認識器（すべてマルチタスクＣＮＮ）により構成されている。この例では、各パターン認識器は、目的動作Ｘ，Ｙ，Ｚ毎に用意されている。そして、例えば、目的動作Ｘ用のパターン認識器（マルチタスクＣＮＮ）は、複数（第１～第４）のタスクにより、動作環境を学習するようになっている。目的動作Ｙ，Ｚ用のパターン認識器（マルチタスクＣＮＮ）も同様である。なお、マルチタスクＣＮＮと、シングルタスクＣＮＮとを、併設してもよい。従って、図１３の例は、図１１の例と図１２の例とを折衷または混在させた場合である。

異常検知器６０には、各目的動作Ｘ，Ｙ，Ｚと各動作環境Ａ１，Ａ２，Ｂ１，Ｂ２，Ｃ１，Ｃ２，（Ａ２＋Ｂ２＋Ｃ２）との全ての組合せに対応する異常検知モデルが用意されている。例えば、（Ｘ＋Ａ１）用の異常検知モデル、（Ｘ＋Ａ２）用の異常検知モデル、…、（Ｙ＋Ａ１）用の異常検知モデル、（Ｙ＋Ａ２）用の異常検知モデル、…等である。そして、図１３の例では、目的動作Ｘ用のパターン認識器（マルチタスクＣＮＮ）の状態推定モデルと、異常検知モデルとは、１対多の対応関係となっている。目的動作Ｙ，Ｚについても同様である。

図１３では、運用時には、前段の状態推定器５０側で、既知の状態に基づき、使用するパターン認識器の選択が行われる。例えば、目的動作Ｘが既知である場合には、状態データは、目的動作Ｘ用のパターン認識器（マルチタスクＣＮＮ）のみに入力される。そして、後段の異常検知器６０側では、対応するパターン認識器から抽出された特徴データが、対応する異常検知モデルによる処理器にのみ入力される。

図１３の場合も、出力手段７０による出力は、図１１の場合と同様である。従って、例えば目的動作Ｘでの動作制御中には、その目的動作Ｘが既知であるので、目的動作Ｘに対応する各異常検知モデルによる処理器からのスコアや判定結果を用いた出力が行われる。

＜第２実施形態の効果＞

このような第２実施形態によれば、前記第１実施形態で得られる効果と同様な効果が得られることに加え、次のような効果を得ることができる。

すなわち、制御状態監視システム１０は、前段の状態推定器５０の状態推定モデル記憶手段５２に、人為的に作り出された機器２０の故障の原因となり得る動作環境下での状態データを用いて作成された、動作環境の識別が可能な状態推定モデルを記憶する構成とされている。また、後段の異常検知器６０の異常検知モデル記憶手段６２にも、人為的に作り出された機器の故障の原因となり得る動作環境下での特徴データを用いて作成された、動作環境の識別が可能な異常検知モデルを記憶する構成とされている。

このため、初期モデル構築時における学習用データを得るために、通常その時点では自然に形成されることのない動作環境を積極的に作り出し、そのような積極的に作り出した動作環境下での状態データや特徴データを学習用データとして用いて、通常は初期モデルとして構築することができないような状態推定モデルや異常検知モデルを作成することができる。換言すれば、長期間の機器２０の使用によって偶発的に生じ得るような動作環境下での状態データや特徴データを意図的に用意し、そのような特殊な環境の識別が可能な状態推定モデルや異常検知モデルを作成することができる。従って、異常検知の幅（異常検知処理で判定できる内容の幅）を広げることができる。

また、上記の説明では、初期モデルの構築時において特殊な動作環境（好ましくない動作環境）を人為的に作り出すことに言及しているが、状態推定モデルや異常検知モデルの更新時において、そのような特殊な動作環境を人為的に作り出してもよい。この際、一般ユーザが使用を開始している機器２０において、好ましくない動作環境を人為的に作り出すことは通常はできないが、例えば、廃棄物処理業者が廃棄対象の機器２０を回収した後に、その機器２０を用いて、好ましくない動作環境を人為的に作り出し、データ収集に協力する場合、あるいは、回収した機器２０をメーカやシステム管理者に引き渡し、メーカやシステム管理者が、引き取った機器２０を用いて、好ましくない動作環境を人為的に作り出し、データ収集を行う場合等がある。

また、上述したように、一般ユーザが使用を開始している機器２０において、好ましくない動作環境を人為的に作り出すことは通常はできないが、好ましくない動作環境の中にも、その程度があり、中間的な状態にある動作環境（健全な動作環境であるとはいえないが、すぐに故障に繋がるとも言えないような動作環境）を確認しながら、それを放置して運転を継続する場合があり、この場合には、得られる状態データや特徴データについてタグ情報を付することができることがある。一般には、機器２０の動作環境は、いつから変化したのか判りにくく、実稼働で収集した状態データや特徴データが、どのような動作環境下で収集されたデータであるかのタグ情報を付すことが困難なことが多く、その点で、動作環境に関する状態推定モデルや異常検知モデルの更新はしにくい。しかし、メンテナンス業者・メーカ・販売業者等の作業員による定期点検等の際に、例えば、前回の定期点検から今回の定期点検までの間に、動作環境（オイルの濁度、気体の充填量、目詰まりの度合い等）が変わっていなければ、収集した状態データや特徴データへのタグ付けを行うことができる。多少好ましくない動作環境であっても、交換基準等までは達していないという理由で、または、コスト面を考慮した一般ユーザの意思により、前回の定期点検等の際に、点検作業員が、その動作環境をそのまま放置した場合には、そういう状況下でのデータ収集およびタグ付けが可能なことがあるからである。また、点検作業中に収集した状態データや特徴データ（先ず、動作環境を確認し、確認した状態のままで点検稼働して得られた状態データや特徴データ）であれば、タグ付けを行うことができる。

また、新製品である機器のリリース後、時間が経過すると、人為的に作り出していた特殊な動作環境（好ましくない動作環境）が、実際に（自然に）発生する場合があり、そのような実際に発生した動作環境（機器２０の故障の原因となり得る動作環境）下での状態データや特徴データを収集することができ、かつ、それらの状態データや特徴データにタグ情報（そういう動作環境下で収集した状態データや特徴データであるというタグ情報）を付すことができる場合には、それらの状態データや特徴データを用いて、状態推定モデルや異常検知モデルの更新のための学習を行ってもよい。

さらに、前段の状態推定モデルを変えずに維持したまま、動作環境に関する異常検知モデルを後から追加することや、追加した異常検知モデルが不要になった場合にそれを削除すること（削除には、モデルのデータは残したまま、それを使用しないようにすることを含む。）や、初期モデルから用意されている動作環境に関する異常検知モデルを後から削除することもできる。そして、異常検知モデルの追加や削除が行われた場合には、出力手段７０によるユーザに対する出力形式を変更する必要が生じる場合もあるが、その場合には、追加や削除が行われた場合の予備の出力形式を、出力手段７０を実現するプログラムの中に予め記述しておくことが好ましい。なお、異常検知モデルの追加や削除を行うことになった段階で、それに対応する出力形式のプログラムを作成してもよい。

［第３実施形態］

第３実施形態の制御状態監視システム１０では、目的動作に加え、動作環境を考慮するとともに、故障発生予兆の有無の判定を伴う制御状態の監視を行う。図１４には、故障発生時期である第１の範囲と、その予兆を捉える期間である第２の範囲との関係が示されている。図１５には、前段の状態推定を１つのパターン認識器で行う場合（ケースＣ３－１）が示され、図１６には、前段の状態推定を複数のパターン認識器で行う場合（ケースＣ３－２）が示されている。

第３実施形態では、長期間の実稼働で故障が発生した機器２０から得られた状態データや特徴データを用いて、識別的に故障発生の予兆検知を行う。具体的には、累積稼働回数または累積稼働時間が予め定められた第１の範囲内（例えば、稼働開始後、６ヶ月経過時点から１年経過時点までの間、または、５，０００回から１０，０００回までの間）に故障した機器２０と故障しなかった機器２０を集め、それらの機器２０について、予め定められた第２の範囲内（例えば、稼働開始直後から３か月経過時点までの間、または、１００回から２，０００回までの間）の状態データや特徴データを収集し、それらの状態データや特徴データに出現する故障発生の予兆を捉えることにより、故障発生の予兆の有無の識別が可能な状態推定モデルや異常検知モデルを構築する。

例えば、第１の範囲を、稼働開始後６ヶ月経過時点から１年経過時点までの間に設定し、第２の範囲を、稼働開始直後から３か月経過時点までの間に設定した場合には、半年から１年以内の間に故障するような機器２０は、稼働開始直後からその兆候が出ている可能性が高いので、それの兆候を捉えることにより、故障発生の予兆検知を行うといった考え方等に基づき、設定を行っていることになる。

図１４において、第２の範囲は、第１の範囲よりも前の時期（ここでいう時期は、累積稼働回数または累積稼働時間で示される時期である。）であればよい。従って、第２の範囲は、第１の範囲と連続していてもよく、稼働開始直後を含んでいてもよい。図１４の例では、稼働開始直後を含んでいる。また、図１４の例では、第１の範囲に対し、１つの第２の範囲が設定されているが、複数の第２の範囲を設定してもよい。

＜前段の状態推定を１つのパターン認識器で行う場合（ケースＣ３－１）：図１５＞

図１５において、状態推定器５０は、一例として、１つのマルチタスクＣＮＮにより構成されている。図１５（Ａ）の例は、後から故障発生予兆の有無の判定用の異常検知モデルを追加する場合であり、図１５（Ｂ）の例は、故障発生予兆の有無の判定用の状態推定モデルおよび異常検知モデルが最初から用意されている場合である。

＜ケースＣ３－１：図１５（Ａ）＞

図１５（Ａ）において、状態推定器５０を構成するパターン認識器（１つのマルチタスクＣＮＮ）は、複数（第１～第３）のタスクで学習を行っている。いずれのタスクも２クラス分類としている。

第１のタスクは、目的動作Ｘと動作環境Ａ１とを組み合わせた（Ｘ＋Ａ１）と、目的動作Ｘと動作環境Ａ２とを組み合わせた（Ｘ＋Ａ２）との識別タスクであり、第２のタスクは、目的動作Ｙと動作環境Ａ１とを組み合わせた（Ｙ＋Ａ１）と、目的動作Ｙと動作環境Ａ２とを組み合わせた（Ｙ＋Ａ２）との識別タスクであり、第３のタスクは、目的動作Ｚと動作環境Ａ１とを組み合わせた（Ｚ＋Ａ１）と、目的動作Ｚと動作環境Ａ２とを組み合わせた（Ｚ＋Ａ２）との識別タスクである。従って、図１５（Ａ）の例では、状態推定器５０には、故障発生予兆の有無の判定用の状態推定モデルは用意されていない。

図１５（Ａ）において、異常検知器６０には、各目的動作Ｘ，Ｙ，Ｚと各動作環境Ａ１，Ａ２との全ての組合せに対応する異常検知モデルが用意されている。すなわち、（Ｘ＋Ａ１）用、（Ｘ＋Ａ２）用、（Ｙ＋Ａ１）用、（Ｙ＋Ａ２）用、（Ｚ＋Ａ１）用、（Ｚ＋Ａ２）用の各異常検知モデルが用意されている。

また、異常検知器６０には、図１５（Ａ）中の点線で示すように、後から追加された複数（６つ）の故障発生予兆の有無の判定用の異常検知モデルが用意されている。これらの故障発生予兆の有無の判定用の異常検知モデルには、目的動作Ｘと第１の範囲内で故障が発生したこと（Ｋ１）との組合せに対応する（Ｘ＋Ｋ１）用の異常検知モデルと、目的動作Ｘと第１の範囲内で故障が発生しなかったこと（Ｋ２）との組合せに対応する（Ｘ＋Ｋ２）用の異常検知モデルと、目的動作Ｙと第１の範囲内で故障が発生したこと（Ｋ１）との組合せに対応する（Ｙ＋Ｋ１）用の異常検知モデルと、目的動作Ｙと第１の範囲内で故障が発生しなかったこと（Ｋ２）との組合せに対応する（Ｙ＋Ｋ２）用の異常検知モデルと、目的動作Ｚと第１の範囲内で故障が発生したこと（Ｋ１）との組合せに対応する（Ｚ＋Ｋ１）用の異常検知モデルと、目的動作Ｚと第１の範囲内で故障が発生しなかったこと（Ｋ２）との組合せに対応する（Ｚ＋Ｋ２）用の異常検知モデルとがある。

図１５（Ａ）において、学習時には、（Ｘ＋Ｋ１）用の異常検知モデルは、第１の範囲内で故障が発生したＫ１の機器２０についての第２の範囲内で目的動作Ｘでの動作制御を行っていた際の特徴データを用いて学習する。（Ｘ＋Ｋ２）用の異常検知モデルは、第１の範囲内で故障が発生しなかったＫ２の機器２０についての第２の範囲内で目的動作Ｘでの動作制御を行っていた際の特徴データを用いて学習する。（Ｙ＋Ｋ１）用の異常検知モデルは、第１の範囲内で故障が発生したＫ１の機器２０についての第２の範囲内で目的動作Ｙでの動作制御を行っていた際の特徴データを用いて学習する。（Ｙ＋Ｋ２）用の異常検知モデルは、第１の範囲内で故障が発生しなかったＫ２の機器２０についての第２の範囲内で目的動作Ｙでの動作制御を行っていた際の特徴データを用いて学習する。（Ｚ＋Ｋ１）用の異常検知モデルは、第１の範囲内で故障が発生したＫ１の機器２０についての第２の範囲内で目的動作Ｚでの動作制御を行っていた際の特徴データを用いて学習する。（Ｚ＋Ｋ２）用の異常検知モデルは、第１の範囲内で故障が発生しなかったＫ２の機器２０についての第２の範囲内で目的動作Ｚでの動作制御を行っていた際の特徴データを用いて学習する。

これらの学習用の特徴データは、すべて状態推定器５０を構成する１つのパターン認識器（１つのマルチタスクＣＮＮ）から抽出された特徴データである。また、第２の範囲内で目的動作Ｘ，Ｙ，Ｚでの動作制御を行っていた際の特徴データが残っていない場合であっても、第２の範囲内で目的動作Ｘ，Ｙ，Ｚでの動作制御を行っていた際の状態データが残っていれば、それらの状態データを、状態推定器５０を構成する１つのパターン認識器（１つのマルチタスクＣＮＮ）入力することにより、特徴データを抽出できるので、それを学習用の特徴データとすればよい。パターン認識器（１つのマルチタスクＣＮＮ）は、第２の範囲の時期から現在（改めて特徴データを抽出する時点）まで変わっていないからである。

図１５（Ａ）において、運用時には、全ての状態データが、１つのマルチタスクＣＮＮに入力されるが、そこから抽出された特徴データは、既知の情報である目的動作に対応する異常検知モデルのみに入力される。例えば、目的動作Ｘが既知であれば、（Ｘ＋Ａ１）用、（Ｘ＋Ａ２）用、（Ｘ＋Ｋ１）用、（Ｘ＋Ｋ２）用の各異常検知モデルに入力されるが、（Ｙ＋Ａ１）用、（Ｙ＋Ａ２）用、（Ｙ＋Ｋ１）用、（Ｙ＋Ｋ２）用、（Ｚ＋Ａ１）用、（Ｚ＋Ａ２）用、（Ｚ＋Ｋ１）用、（Ｚ＋Ｋ２）用の各異常検知モデルには入力されない。同様に、目的動作Ｙが既知であれば、（Ｙ＋Ａ１）用、（Ｙ＋Ａ２）用、（Ｙ＋Ｋ１）用、（Ｙ＋Ｋ２）用の各異常検知モデルに入力されるが、その他の異常検知モデルには入力されない。また、目的動作Ｚが既知であれば、（Ｚ＋Ａ１）用、（Ｚ＋Ａ２）用、（Ｚ＋Ｋ１）用、（Ｚ＋Ｋ２）用の各異常検知モデルに入力されるが、その他の異常検知モデルには入力されない。

但し、上記の異常検知モデルのうち、複数（６つ）の故障発生予兆の有無の判定用の異常検知モデルが使用されるのは、制御状態監視システム１０による異常検知の対象とされている機器２０が、第２の範囲内の時期にあるときだけである。その機器２０にとっての第２の範囲内の時期に、故障発生予兆の有無の判定を行うことにより、その機器２０にとっての第１の範囲内の時期に故障が発生する可能性を判定するからである。なお、その機器２０にとっての第２の範囲に該当しない時期については、複数（６つ）の故障発生予兆の有無の判定用の異常検知モデル以外の異常検知モデルは使用される。つまり、動作環境に関する異常検知モデルは使用されるので、前記第２実施形態と同様な処理が行われる。

また、運用時において、制御状態監視システム１０による異常検知の対象とされている機器２０が、第２の範囲内の時期にあるか否かは、機器２０から状態データとともに送信されてくる機器稼働開始年月日および／または累積稼働回数を示すカウント値（図３参照）を用いて判定することができる。この際、累積稼働回数の場合には、カウント値を用いればよく、累積稼働時間の場合には、機器稼働開始年月日と現在時刻との差分になるが、現在時刻は、機器２０から状態データとともに送信されてくる当該状態データについてのデータ取得日時（図３参照）としてもよく、判定時の時刻としてもよい。

なお、学習時において、第２の範囲内のデータを学習用データとして収集する際も、上記と同様に判定することができ、この際、データ取得日時については、状態データの場合には、状態推定器学習用データ記憶手段８３に記憶されている当該状態データについてのデータ取得日時（図３参照）を用いればよく、特徴データの場合には、異常検知器学習用データ記憶手段８４に記憶されている当該特徴データについてのデータ取得日時（図３参照）を用いればよい。また、機器２０が第１の範囲内で故障したか否かは、故障が発生した機器２０の場合には、当該機器２０についてデータ収集装置８０で最後に収集されたデータ（図３参照）を参照するか、または、故障時における当該機器２０の管理者（通常は、一般ユーザ）の申告情報に基づけばよく、故障が発生しなかった機器２０の場合には、当該機器２０についてデータ収集装置８０に第１の範囲の最後の時期までデータが存在するか否かを参照するか、または、第１の範囲の最後の時期における当該機器２０の管理者（通常は、一般ユーザ）の申告情報に基づけばよい。

その後、出力手段７０により、第２の範囲内の時期にある場合には、故障発生予兆の有無の判定結果を伴う異常検知結果の出力が行われる。例えば、目的動作Ｘでの動作制御中であれば、（Ｘ＋Ｋ１）用および（Ｘ＋Ｋ２）用の各異常検知モデルからのスコアまたは判定結果が得られるので、これにより出力手段７０は、ユーザに対し、故障発生予兆の有無の判定結果の出力を行うことができる。例えば、（Ｘ＋Ｋ１）用の異常検知モデルから出力された尤度が大きく、（Ｘ＋Ｋ２）用の異常検知モデルから出力された尤度が小さければ、その機器２０にとっての第１の範囲内の時期に、故障が発生する可能性が高い等の出力を行うことができる。尤度の大小が逆であれば、故障が発生する可能性が低い等の出力を行うことができる。双方の尤度が大きい場合等のように、矛盾するスコアが出力された場合は、ユーザに対し、何も出力しないか、判定不能である旨の出力等を行えばよい。

また、運用時において、制御状態監視システム１０による異常検知の対象とされている機器２０についての累積稼働回数・時間が不明である場合には、「もし、現在が稼働開始後３ヶ月以内であれば、稼働開始後６ヶ月から１２ヶ月までの間に相当する時期に、故障する可能性がある」等といった条件付きの出力を行うこともできる。この条件付きの出力を行うには、累積稼働回数・時間が不明な場合でも、（Ｘ＋Ｋ１）用および（Ｘ＋Ｋ２）用の各異常検知モデルを使用してスコアを得ていることが前提である。

＜ケースＣ３－１：図１５（Ｂ）＞

図１５（Ｂ）において、状態推定器５０を構成するパターン認識器（１つのマルチタスクＣＮＮ）は、複数（第１～第６）のタスクで学習を行っている。いずれのタスクも２クラス分類としている。

第１のタスクは、目的動作Ｘと動作環境Ａ１とを組み合わせた（Ｘ＋Ａ１）と、目的動作Ｘと動作環境Ａ２とを組み合わせた（Ｘ＋Ａ２）との識別タスクであり、第２のタスクは、目的動作Ｘと第１の範囲内で故障が発生したこと（Ｋ１）とを組み合わせた（Ｘ＋Ｋ１）と、目的動作Ｘと第１の範囲内で故障が発生しなかったこと（Ｋ２）とを組み合わせた（Ｘ＋Ｋ２）との識別タスクである。また、第３のタスクは、目的動作Ｙと動作環境Ａ１とを組み合わせた（Ｙ＋Ａ１）と、目的動作Ｙと動作環境Ａ２とを組み合わせた（Ｙ＋Ａ２）との識別タスクであり、第４のタスクは、目的動作Ｙと第１の範囲内で故障が発生したこと（Ｋ１）とを組み合わせた（Ｙ＋Ｋ１）と、目的動作Ｙと第１の範囲内で故障が発生しなかったこと（Ｋ２）とを組み合わせた（Ｙ＋Ｋ２）との識別タスクである。さらに、第５のタスクは、目的動作Ｚと動作環境Ａ１とを組み合わせた（Ｚ＋Ａ１）と、目的動作Ｚと動作環境Ａ２とを組み合わせた（Ｚ＋Ａ２）との識別タスクであり、第６のタスクは、目的動作Ｚと第１の範囲内で故障が発生したこと（Ｋ１）とを組み合わせた（Ｚ＋Ｋ１）と、目的動作Ｚと第１の範囲内で故障が発生しなかったこと（Ｋ２）とを組み合わせた（Ｚ＋Ｋ２）との識別タスクである。従って、図１５（Ｂ）の例では、図１５（Ａ）の例とは異なり、状態推定器５０には、故障発生予兆の有無の判定用の状態推定モデルが用意されていることになる。より正確には、状態推定器５０は、１つのパターン認識器（１つのマルチタスクＣＮＮ）により構成されているので、故障発生予兆の有無の判定用のタスク部分を備えているということになる。

図１５（Ｂ）において、異常検知器６０には、各目的動作Ｘ，Ｙ，Ｚと各動作環境Ａ１，Ａ２との全ての組合せに対応する異常検知モデルが用意されている。すなわち、（Ｘ＋Ａ１）用、（Ｘ＋Ａ２）用、（Ｙ＋Ａ１）用、（Ｙ＋Ａ２）用、（Ｚ＋Ａ１）用、（Ｚ＋Ａ２）用の各異常検知モデルが用意されている。但し、（Ｚ＋Ａ１）用、（Ｚ＋Ａ２）用の図示は省略されている。この点は、図１５（Ａ）の場合と同様である。

また、異常検知器６０には、図１５（Ａ）の場合と同様に、複数（６つ）の故障発生予兆の有無の判定用の異常検知モデルが用意されている。すなわち、（Ｘ＋Ｋ１）用、（Ｘ＋Ｋ２）用、（Ｙ＋Ｋ１）用、（Ｙ＋Ｋ２）用、（Ｚ＋Ｋ１）用、（Ｚ＋Ｋ２）用の各異常検知モデルが用意されている。但し、（Ｚ＋Ｋ１）用、（Ｚ＋Ｋ２）用の図示は省略されている。これらの複数（６つ）の故障発生予兆の有無の判定用の異常検知モデルは、後から追加されたものではなく、最初から用意されている点を除き、図１５（Ａ）の場合と同様であり、同様な学習処理を行って作成されている。従って、学習用の特徴データは、すべて状態推定器５０を構成する１つのパターン認識器（１つのマルチタスクＣＮＮ）から抽出された特徴データである。

さらに、運用時における状態データや特徴データの流れ、および、出力手段７０による判定結果の出力も、図１５（Ａ）の場合と同様である。

＜前段の状態推定を複数のパターン認識器で行う場合（ケースＣ３－２）：図１６＞

図１６において、状態推定器５０は、一例として、複数のパターン認識器（いずれもシングルタスクＣＮＮ）により構成されている。図１６（Ａ）の例は、後から故障発生予兆の有無の判定用の異常検知モデルを追加する場合であり、図１６（Ｂ）の例は、故障発生予兆の有無の判定用の状態推定モデルおよび異常検知モデルが最初から用意されている場合である。

＜ケースＣ３－２：図１６（Ａ）＞

図１６（Ａ）において、状態推定器５０は、複数（３つ）のパターン認識器（ＣＮＮ）により構成されている。すなわち、目的動作Ｘと動作環境Ａ１とを組み合わせた（Ｘ＋Ａ１）と、目的動作Ｘと動作環境Ａ２とを組み合わせた（Ｘ＋Ａ２）との識別用のパターン認識器（ＣＮＮ）と、目的動作Ｙと動作環境Ａ１とを組み合わせた（Ｙ＋Ａ１）と、目的動作Ｙと動作環境Ａ２とを組み合わせた（Ｙ＋Ａ２）との識別用のパターン認識器（ＣＮＮ）と、目的動作Ｚと動作環境Ａ１とを組み合わせた（Ｚ＋Ａ１）と、目的動作Ｚと動作環境Ａ２とを組み合わせた（Ｚ＋Ａ２）との識別用のパターン認識器（ＣＮＮ）とにより構成されている。但し、（Ｚ＋Ａ１）と（Ｚ＋Ａ２）との識別用のパターン認識器（ＣＮＮ）の図示は省略されている。従って、図１６（Ａ）の例では、状態推定器５０には、故障発生予兆の有無の判定用の状態推定モデルは用意されていない。

図１６（Ａ）において、異常検知器６０には、各目的動作Ｘ，Ｙ，Ｚと各動作環境Ａ１，Ａ２との全ての組合せに対応する異常検知モデルが用意されている。すなわち、（Ｘ＋Ａ１）用、（Ｘ＋Ａ２）用、（Ｙ＋Ａ１）用、（Ｙ＋Ａ２）用、（Ｚ＋Ａ１）用、（Ｚ＋Ａ２）用の各異常検知モデルが用意されている。但し、（Ｚ＋Ａ１）用、（Ｚ＋Ａ２）用の図示は省略されている。

また、異常検知器６０には、図１６（Ａ）中の点線で示すように、後から追加された複数（６つ）の故障発生予兆の有無の判定用の異常検知モデルが用意されている。すなわち、（Ｘ＋Ｋ１）用、（Ｘ＋Ｋ２）用、（Ｙ＋Ｋ１）用、（Ｙ＋Ｋ２）用、（Ｚ＋Ｋ１）用、（Ｚ＋Ｋ２）用の各異常検知モデルが用意されている。但し、（Ｚ＋Ｋ１）用、（Ｚ＋Ｋ２）用の図示は省略されている。

図１６（Ａ）において、学習時には、（Ｘ＋Ｋ１）用の異常検知モデルは、第１の範囲内で故障が発生したＫ１の機器２０についての第２の範囲内で目的動作Ｘでの動作制御を行っていた際の特徴データを用いて学習する。（Ｘ＋Ｋ２）用の異常検知モデルは、第１の範囲内で故障が発生しなかったＫ２の機器２０についての第２の範囲内で目的動作Ｘでの動作制御を行っていた際の特徴データを用いて学習する。これらの学習用の特徴データは、状態推定器５０を構成する複数のパターン認識器（ＣＮＮ）のうちの対応するパターン認識器（（Ｘ＋Ａ１）と（Ｘ＋Ａ２）との識別用のパターン認識器）から抽出された特徴データである。

また、（Ｙ＋Ｋ１）用の異常検知モデルは、第１の範囲内で故障が発生したＫ１の機器２０についての第２の範囲内で目的動作Ｙでの動作制御を行っていた際の特徴データを用いて学習する。（Ｙ＋Ｋ２）用の異常検知モデルは、第１の範囲内で故障が発生しなかったＫ２の機器２０についての第２の範囲内で目的動作Ｙでの動作制御を行っていた際の特徴データを用いて学習する。これらの学習用の特徴データは、状態推定器５０を構成する複数のパターン認識器（ＣＮＮ）のうちの対応するパターン認識器（（Ｙ＋Ａ１）と（Ｙ＋Ａ２）との識別用のパターン認識器）から抽出された特徴データである。

図示は省略されているが、（Ｚ＋Ｋ１）用の異常検知モデル、（Ｚ＋Ｋ２）用の異常検知モデルの場合も同様である。

図１６（Ａ）において、運用時には、状態データは、既知の目的動作に対応するパターン認識器（ＣＮＮ）に入力される。例えば、目的動作Ｘが既知である場合には、（Ｘ＋Ａ１）と（Ｘ＋Ａ２）との識別用のパターン認識器に入力され、そこから抽出された特徴データは、対応する異常検知モデルのみに入力される。例えば、目的動作Ｘが既知であれば、（Ｘ＋Ａ１）用、（Ｘ＋Ａ２）用、（Ｘ＋Ｋ１）用、（Ｘ＋Ｋ２）用の各異常検知モデルに入力されるが、その他の異常検知モデルには入力されない。

図１６（Ａ）において、出力手段７０による判定結果の出力は、図１５（Ａ）の場合と同様である。

＜ケースＣ３－２：図１６（Ｂ）＞

図１６（Ｂ）において、状態推定器５０は、複数（６つ）のパターン認識器（ＣＮＮ）により構成されている。すなわち、状態推定器５０は、目的動作Ｘと動作環境Ａ１とを組み合わせた（Ｘ＋Ａ１）と、目的動作Ｘと動作環境Ａ２とを組み合わせた（Ｘ＋Ａ２）との識別用のパターン認識器（ＣＮＮ）を備えている。また、目的動作Ｙと動作環境Ａ１とを組み合わせた（Ｙ＋Ａ１）と、目的動作Ｙと動作環境Ａ２とを組み合わせた（Ｙ＋Ａ２）との識別用のパターン認識器（ＣＮＮ）を備えている。さらに、図示は省略されているが、目的動作Ｚと動作環境Ａ１とを組み合わせた（Ｚ＋Ａ１）と、目的動作Ｚと動作環境Ａ２とを組み合わせた（Ｚ＋Ａ２）との識別用のパターン認識器（ＣＮＮ）を備えている。

また、状態推定器５０は、目的動作Ｘと第１の範囲内で故障が発生したこと（Ｋ１）とを組み合わせた（Ｘ＋Ｋ１）と、目的動作Ｘと第１の範囲内で故障が発生しなかったこと（Ｋ２）とを組み合わせた（Ｘ＋Ｋ２）との識別用のパターン認識器（ＣＮＮ）を備えている。また、目的動作Ｙと第１の範囲内で故障が発生したこと（Ｋ１）とを組み合わせた（Ｙ＋Ｋ１）と、目的動作Ｙと第１の範囲内で故障が発生しなかったこと（Ｋ２）とを組み合わせた（Ｙ＋Ｋ２）との識別用のパターン認識器（ＣＮＮ）を備えている。さらに、図示は省略されているが、目的動作Ｚと第１の範囲内で故障が発生したこと（Ｋ１）とを組み合わせた（Ｚ＋Ｋ１）と、目的動作Ｚと第１の範囲内で故障が発生しなかったこと（Ｋ２）とを組み合わせた（Ｚ＋Ｋ２）との識別用のパターン認識器（ＣＮＮ）を備えている。従って、図１６（Ｂ）の例では、図１６（Ａ）の例とは異なり、状態推定器５０には、故障発生予兆の有無の判定用の状態推定モデルが用意されている。

図１６（Ｂ）において、異常検知器６０には、各目的動作Ｘ，Ｙ，Ｚと各動作環境Ａ１，Ａ２との全ての組合せに対応する異常検知モデルが用意されている。すなわち、（Ｘ＋Ａ１）用、（Ｘ＋Ａ２）用、（Ｙ＋Ａ１）用、（Ｙ＋Ａ２）用、（Ｚ＋Ａ１）用、（Ｚ＋Ａ２）用の各異常検知モデルが用意されている。但し、（Ｚ＋Ａ１）用、（Ｚ＋Ａ２）用の図示は省略されている。この点は、図１６（Ａ）の場合と同様である。

また、異常検知器６０には、図１６（Ａ）の場合と同様に、複数（６つ）の故障発生予兆の有無の判定用の異常検知モデルが用意されている。すなわち、（Ｘ＋Ｋ１）用、（Ｘ＋Ｋ２）用、（Ｙ＋Ｋ１）用、（Ｙ＋Ｋ２）用、（Ｚ＋Ｋ１）用、（Ｚ＋Ｋ２）用の各異常検知モデルが用意されている。但し、（Ｚ＋Ｋ１）用、（Ｚ＋Ｋ２）用の図示は省略されている。これらの複数（６つ）の故障発生予兆の有無の判定用の異常検知モデルは、後から追加されたものではなく、最初から用意されている点が、図１６（Ａ）の場合と異なっている。

図１６（Ｂ）において、学習時には、（Ｘ＋Ｋ１）用の異常検知モデルは、第１の範囲内で故障が発生したＫ１の機器２０についての第２の範囲内で目的動作Ｘでの動作制御を行っていた際の特徴データを用いて学習する。（Ｘ＋Ｋ２）用の異常検知モデルは、第１の範囲内で故障が発生しなかったＫ２の機器２０についての第２の範囲内で目的動作Ｘでの動作制御を行っていた際の特徴データを用いて学習する。これらの学習用の特徴データは、状態推定器５０を構成する複数のパターン認識器（ＣＮＮ）のうちの対応するパターン認識器（（Ｘ＋Ｋ１）と（Ｘ＋Ｋ２）との識別用のパターン認識器）から抽出された特徴データである。この点が、図１６（Ａ）の場合と異なっている。図１６（Ａ）の場合には、状態推定器５０に、故障発生予兆の有無の判定用の状態推定モデルが用意されていないので、（Ｘ＋Ａ１）と（Ｘ＋Ａ２）との識別用のパターン認識器から抽出された特徴データを用いて学習を行うからである。

また、（Ｙ＋Ｋ１）用の異常検知モデルは、第１の範囲内で故障が発生したＫ１の機器２０についての第２の範囲内で目的動作Ｙでの動作制御を行っていた際の特徴データを用いて学習する。（Ｙ＋Ｋ２）用の異常検知モデルは、第１の範囲内で故障が発生しなかったＫ２の機器２０についての第２の範囲内で目的動作Ｙでの動作制御を行っていた際の特徴データを用いて学習する。これらの学習用の特徴データは、状態推定器５０を構成する複数のパターン認識器（ＣＮＮ）のうちの対応するパターン認識器（（Ｙ＋Ｋ１）と（Ｙ＋Ｋ２）との識別用のパターン認識器）から抽出された特徴データである。この点が、図１６（Ａ）の場合と異なっている。図１６（Ａ）の場合には、状態推定器５０に、故障発生予兆の有無の判定用の状態推定モデルが用意されていないので、（Ｙ＋Ａ１）と（Ｙ＋Ａ２）との識別用のパターン認識器から抽出された特徴データを用いて学習を行うからである。

図１６（Ｂ）において、運用時には、状態データは、既知の目的動作に対応するパターン認識器（ＣＮＮ）に入力される。例えば、目的動作Ｘが既知である場合には、（Ｘ＋Ａ１）と（Ｘ＋Ａ２）との識別用のパターン認識器、および（Ｘ＋Ｋ１）と（Ｘ＋Ｋ２）との識別用のパターン認識器に入力される。それから、（Ｘ＋Ａ１）と（Ｘ＋Ａ２）との識別用のパターン認識器から抽出された特徴データは、対応する異常検知モデル（（Ｘ＋Ａ１）用および（Ｘ＋Ａ２）用の各異常検知モデル）のみに入力される。また、（Ｘ＋Ｋ１）と（Ｘ＋Ｋ２）との識別用のパターン認識器から抽出された特徴データは、対応する異常検知モデル（（Ｘ＋Ｋ１）用および（Ｘ＋Ｋ２）用の各異常検知モデル）のみに入力される。

図１６（Ｂ）において、出力手段７０による判定結果の出力は、図１６（Ａ）の場合と同様である。

＜第３実施形態の効果＞

このような第３実施形態によれば、前記第１、第２実施形態で得られる効果と同様な効果が得られることに加え、次のような効果を得ることができる。

すなわち、制御状態監視システム１０は、状態推定モデル記憶手段５２に、故障発生の予兆の有無を識別可能な状態推定モデルを記憶する構成とされ、また、異常検知モデル記憶手段６２に、故障発生の予兆の有無を識別可能な異常検知モデルを記憶する構成とされているので、実稼働で実際に故障が発生したときに、その故障発生時よりも前の時期に出現していた状態データや特徴データの変化を学習しておくことができる。このため、運用時に、故障発生の予兆の有無を判定することができる。

なお、実稼働で実際に故障が発生しないと必要な学習用データである状態データや特徴データが得られないので、通常は、状態推定器５０や異常検知器６０に、最初からこのような故障発生の予兆の有無を識別可能な状態推定モデルや異常検知モデルを設けておくことは困難であるが、例えば、新製品をリリースしてから暫く時間が経過した後に、制御状態監視システム１０を構築する場合には、既に必要な学習用データが存在することもあるので、初期モデルとして、このような故障発生の予兆の有無を識別可能な状態推定モデルや異常検知モデルを設けることができる。また、新製品のリリース前に、長期間の試験運転期間を設け、その試験運転期間中に故障が発生すれば、新製品のリリース前に、必要な学習用データを得ることができるので、この場合も同様に、初期モデルとして、故障発生の予兆の有無を識別可能な状態推定モデルや異常検知モデルを設けることができる。従って、図１５（Ｂ）や図１６（Ｂ）のように、故障発生予兆の有無の判定用の状態推定モデルおよび異常検知モデルを最初から用意しておくことができる。

また、上述したように、初期のモデル構築時に、実際に故障が発生した機器２０のデータを収集できるのは、限られたケースであるから、通常は、故障発生予兆の有無の判定用のモデルは、同型製品の運用開始後に構築されるモデルとなる。この際、制御状態監視システム１０は、前段の状態推定器５０と後段の異常検知器６０との２段構成になっているので、図１５（Ａ）や図１６（Ａ）の点線で示すように、状態推定モデルを変えることなく、後から異常検知モデルの追加を行うことができる。このため、故障発生予兆の有無の判定が可能なシステムを容易に構築することができる。

このように後から異常検知モデルの追加を行うことができると、機器２０を利用する一般ユーザには、次のようなメリットがある。例えば、製品寿命が長い機器２０であれば、一般ユーザ（例えば、後発的な事業参入者）がその製品を購入したときに、既に故障発生予兆の有無の判定用の異常検知モデルが構築され、本システムに追加されている状況になっている場合があるので、その場合には、その一般ユーザは、製品の購入直後から、追加した異常検知モデルを用いた故障発生予兆の有無の判定結果を得ることができる。

また、発売直後に、すなわち同時期に同タイプの製品を導入した一般ユーザが多数いる場合において、他の一般ユーザが使用している比較的多数の機器２０に故障が発生し、それらの故障が発生した機器２０のデータ収集が行われ、故障発生予兆の有無の判定用の異常検知モデルが構築され、その異常検知モデルが本システムに追加されたとすると、その時点から、故障発生予兆の有無の判定を伴う異常検知処理が行われるので、未だ故障が発生していない機器２０を使用している一般ユーザは、その利益を享受することができる。換言すれば、同時期に発売された全ての製品の故障発生タイミングが同じであるわけではないので、自分の機器２０よりも前に故障が発生した他人の機器２０のデータを用いて、同時期に導入した自分の機器２０に同様な故障が発生しないかを判定することができる。

但し、第１の範囲内で故障が発生した機器２０については、その故障が発生した時点でデータ収集が可能であるが、第１の範囲内で故障が発生しなかった機器２０というのは、厳密にいえば、第１の範囲の最後の時期が経過しなければ、その事実が確定しないので、データ収集できないことになる。従って、より早い時期に、故障発生予兆の有無の判定用の異常検知モデルの追加を行う場合には、第１の範囲内で故障が発生した機器２０のデータと、故障が発生しなかった機器２０のデータとの識別ではなく、例えば、第１の範囲内で故障が発生した機器２０のデータと、それ以外のデータ（どのようなデータでもよく、例えば、先行する類似タイプの旧製品で故障しなかった機器の該当期間のデータでもよい。）との識別用のモデルを構築し、それを早い段階で仮のモデルとして本システムに追加し、その後、第１の範囲の最後の時期が経過した時点で、より正確なモデルとして、第１の範囲内で故障が発生した機器２０のデータと、故障が発生しなかった機器２０（その事実が確定した機器２０）のデータとの識別用のモデルを構築し、それを正式なモデルとして本システムに追加するとともに、仮のモデルを削除すること等を行ってもよい。

［第４実施形態］

第４実施形態の制御状態監視システム１０では、目的動作に加え、動作環境および累積稼働回数・時間を考慮して制御状態の監視を行う。図１７には、前段の状態推定を１つのパターン認識器で行う場合（ケースＣ４－１）が示され、図１８には、前段の状態推定を複数のパターン認識器で行う場合（ケースＣ４－２）が示されている。

第４実施形態では、機器２０の累積稼働回数または累積稼働時間とともに収集された状態データや特徴データを用いて、累積稼働回数または累積稼働時間の区分け毎に学習を行うことにより、機器２０の経年変化を捉えることが可能な状態推定モデルや異常検知モデルを構築し、経年劣化を考慮した異常検知処理を行う。

ここで、累積稼働回数または累積稼働時間の区分けＴ０，Ｔ１，Ｔ２，…は、累積稼働時間の場合は、例えば、Ｔ０＝稼働開始前（製品出荷前の点検期間やデータ収集期間を含む）、Ｔ１＝稼働開始から１年以内、Ｔ２＝稼働開始後１～２年経過、Ｔ３＝稼働開始後２～５年経過、Ｔ４＝稼働開始後５年以上経過等である。また、累積稼働回数の場合は、例えば、Ｔ０＝稼働開始前、Ｔ１＝１，０００回以内、Ｔ２＝１，００１回～２，０００回、Ｔ３＝２，００１回～５，０００回、Ｔ４＝５，００１回以上等である。各区分けＴ０，Ｔ１，Ｔ２，…は、等間隔（等しい時間長や回数）である必要はなく、また、それぞれの時間長や回数も任意である。

また、累積稼働回数または累積稼働時間の判定方法は、前記第３実施形態の場合と同様であり、前記第３実施形態の説明で既に詳述しているため、ここでは詳しい説明を省略する。

なお、累積稼働時間を判定する場合に、途中で不使用期間があるケースでは、メーカやシステム管理者の定めたルールに従って、累積稼働時間への寄与を定めればよい。例えば、１年間使用し、その後２年間不使用で、さらに３年間使用したケースでは、不使用期間を含めないで１＋３＝４年間としてもよく、不使用期間を含めて１＋２＋３＝６年間としてもよく、係数を乗じた不使用期間を含めて１＋２×０．５＋３＝５年間等としてもよい。

＜前段の状態推定を１つのパターン認識器で行う場合（ケースＣ４－１）：図１７＞

図１７において、状態推定器５０は、一例として、１つのマルチタスクＣＮＮにより構成されている。図１７（Ａ）の例は、後から累積稼働回数・時間の識別用の異常検知モデルを追加する場合であり、図１７（Ｂ）の例は、累積稼働回数・時間の識別用の状態推定モデルおよび異常検知モデルが最初から用意されている場合である。

＜ケースＣ４－１：図１７（Ａ）＞

図１７（Ａ）において、状態推定器５０を構成するパターン認識器（１つのマルチタスクＣＮＮ）は、複数（第１～第３）のタスクで学習を行っている。いずれのタスクも２クラス分類としている。

第１のタスクは、目的動作Ｘと動作環境Ａ１と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｘ＋Ａ１＋Ｔ０）と、目的動作Ｘと動作環境Ａ２と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｘ＋Ａ２＋Ｔ０）との識別タスクである。なお、例えば、（Ｘ＋Ａ１＋Ｔ０）は、累積稼働回数・時間の区分けＴ０に含まれる時期に、動作環境Ａ１の下で、目的動作Ｘでの動作制御を行っている際のデータという意味である。第２のタスクは、目的動作Ｙと動作環境Ａ１と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｙ＋Ａ１＋Ｔ０）と、目的動作Ｙと動作環境Ａ２と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｙ＋Ａ２＋Ｔ０）との識別タスクである。第３のタスクは、目的動作Ｚと動作環境Ａ１と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｚ＋Ａ１＋Ｔ０）と、目的動作Ｚと動作環境Ａ２と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｚ＋Ａ２＋Ｔ０）との識別タスクである。従って、図１７（Ａ）の例では、状態推定器５０には、累積稼働回数・時間の識別用の状態推定モデルは用意されていない。

図１７（Ａ）において、異常検知器６０には、各目的動作Ｘ，Ｙ，Ｚと各動作環境Ａ１，Ａ２と累積稼働回数・時間の区分けＴ０との全ての組合せに対応する異常検知モデルが用意されている。すなわち、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｙ＋Ａ１＋Ｔ０）用、（Ｙ＋Ａ２＋Ｔ０）用、（Ｚ＋Ａ１＋Ｔ０）用、（Ｚ＋Ａ２＋Ｔ０）用の各異常検知モデルが用意されている。但し、（Ｚ＋Ａ１＋Ｔ０）用、（Ｚ＋Ａ２＋Ｔ０）用の図示は省略されている。

また、異常検知器６０には、図１７（Ａ）中の点線で示すように、後から追加された累積稼働回数・時間の識別用の異常検知モデルが用意されている。これらの累積稼働回数・時間の識別用の異常検知モデルには、目的動作Ｘと累積稼働回数・時間の区分けＴ１との組合せに対応する（Ｘ＋Ｔ１）用の異常検知モデルと、目的動作Ｘと累積稼働回数・時間の区分けＴ２との組合せに対応する（Ｘ＋Ｔ２）用の異常検知モデルと、目的動作Ｙと累積稼働回数・時間の区分けＴ１との組合せに対応する（Ｙ＋Ｔ１）用の異常検知モデルと、目的動作Ｙと累積稼働回数・時間の区分けＴ２との組合せに対応する（Ｙ＋Ｔ２）用の異常検知モデルと、目的動作Ｚと累積稼働回数・時間の区分けＴ１との組合せに対応する（Ｚ＋Ｔ１）用の異常検知モデルと、目的動作Ｚと累積稼働回数・時間の区分けＴ２との組合せに対応する（Ｚ＋Ｔ２）用の異常検知モデルとがある。但し、（Ｚ＋Ｔ１）用、（Ｚ＋Ｔ２）用の図示は省略されている。また、後から追加された異常検知モデルであるため、Ｔ０のモデルはない。Ｔ３以降がないのは、製品販売開始からの経過年数がそこまで達していないため、データ収集できないからである。さらに、動作環境Ａ１，Ａ２がないのは、実稼働開始後に得られた実際の経年変化データを学習用データとして、後から学習を行って追加用の異常検知モデルを構築するので、学習用データについて動作環境Ａ１，Ａ２に関するタグ情報がないからである。換言すれば、人為的に作り出した動作環境下で収集した学習用データではないからである。

図１７（Ａ）において、学習時には、（Ｘ＋Ｔ１）用の異常検知モデルは、累積稼働回数または累積稼働時間が区分けＴ１に属する時期に、目的動作Ｘでの動作制御を行っている際の特徴データを用いて学習する。（Ｘ＋Ｔ２）用の異常検知モデルは、累積稼働回数または累積稼働時間が区分けＴ２に属する時期に、目的動作Ｘでの動作制御を行っている際の特徴データを用いて学習する。（Ｙ＋Ｔ１）用の異常検知モデルは、累積稼働回数または累積稼働時間が区分けＴ１に属する時期に、目的動作Ｙでの動作制御を行っている際の特徴データを用いて学習する。（Ｙ＋Ｔ２）用の異常検知モデルは、累積稼働回数または累積稼働時間が区分けＴ２に属する時期に、目的動作Ｙでの動作制御を行っている際の特徴データを用いて学習する。（Ｚ＋Ｔ１）用および（Ｚ＋Ｔ２）用の各異常検知モデルについても同様である。

これらの学習用の特徴データは、すべて状態推定器５０を構成する１つのパターン認識器（１つのマルチタスクＣＮＮ）から抽出された特徴データである。また、特徴データが収集できない場合であっても、状態データが収集できれば、それらの状態データを、状態推定器５０を構成する１つのパターン認識器（１つのマルチタスクＣＮＮ）入力することにより、特徴データを抽出できるので、それを学習用の特徴データとすればよい。パターン認識器（１つのマルチタスクＣＮＮ）は、変わっていないからである。

図１７（Ａ）において、運用時には、全ての状態データが、１つのマルチタスクＣＮＮに入力されるが、そこから抽出された特徴データは、既知の情報である目的動作に対応する異常検知モデルのみに入力される。さらに、既知の情報である目的動作に対応する異常検知モデルの中でも、累積稼働回数または累積稼働時間に基づき、使用する異常検知モデルの選択が行われる。すなわち、制御状態監視システム１０による異常検知の対象となっている機器２０についての累積稼働回数・時間が、不明である場合（Ｔ未知）と、区分けＴ１に属する時期である場合（Ｔ１既知）と、区分けＴ２以降（Ｔ２，Ｔ３，Ｔ４，…）に属する時期である場合（Ｔ２以降既知）とで、使用する異常検知モデルが異なる。

例えば、目的動作Ｘが既知であれば、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ｔ１）用、（Ｘ＋Ｔ２）用の各異常検知モデルに入力されるが、その他の異常検知モデルには入力されない。同様に、目的動作Ｙが既知であれば、（Ｙ＋Ａ１＋Ｔ０）用、（Ｙ＋Ａ２＋Ｔ０）用、（Ｙ＋Ｔ１）用、（Ｙ＋Ｔ２）用の各異常検知モデルに入力されるが、その他の異常検知モデルには入力されない。また、目的動作Ｚが既知の場合も同様である。

さらに、例えば目的動作Ｘが既知である場合において、累積稼働回数・時間に基づく選択により、Ｔ未知の場合には、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ｔ１）用、（Ｘ＋Ｔ２）用の各異常検知モデルに入力される。つまり、目的動作Ｘに関する全ての異常検知モデルに入力される。

また、Ｔ１既知の場合には、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ｔ１）用の各異常検知モデルに入力されるが、（Ｘ＋Ｔ２）用の異常検知モデルには入力されない。Ｔ１が判明しているときに、Ｔ２の状態に近いか否かを判定する必要はないからである。

さらに、Ｔ２以降既知の場合には、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ｔ２）用の各異常検知モデルに入力されるが、（Ｘ＋Ｔ１）用の異常検知モデルには入力されない。Ｔ２以降（Ｔ２，Ｔ３，Ｔ４，…）が判明しているときに、Ｔ１の状態に近いか否かを判定する必要はないからである。なお、Ｔ３以降のモデルがないので、Ｔ３以降既知の場合には、最も状態が近いＴ２のモデルを使用することにしている。

その後、出力手段７０により、異常検知結果の出力が行われる。この際、Ｔ未知の場合と、Ｔ１既知の場合と、Ｔ２以降既知の場合とで、出力形式が異なる。例えば、目的動作Ｘでの動作制御中であれば、次のようになる。

Ｔ未知の場合には、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ｔ１）用、（Ｘ＋Ｔ２）用の各異常検知モデルからのスコアまたは判定結果が得られるので、先ず、（Ｘ＋Ａ１＋Ｔ０）、（Ｘ＋Ａ２＋Ｔ０）からのスコアまたは判定結果を用いて、動作環境Ａ１，Ａ２に関する異常検知結果の出力を行う。ここで、（Ｘ＋Ａ１＋Ｔ０）、（Ｘ＋Ａ２＋Ｔ０）から出力された尤度が、両方とも大きい等のように矛盾が生じた場合、あるいは、動作環境が悪いという判定結果になった場合には、それらの原因が経年劣化によるものかもしれないので、（Ｘ＋Ｔ１）、（Ｘ＋Ｔ２）からのスコアまたは判定結果を用いて、条件付きの出力を行う。例えば、（Ｘ＋Ｔ１）から出力された尤度が大きければ、「お使いの機器が、もし稼働開始後～年目から～年目の間（Ｔ１に属する時期）であれば、経年劣化はありますが、正常です」等の出力を行い、（Ｘ＋Ｔ２）から出力された尤度が大きければ、「お使いの機器が、もし稼働開始後～年以上経過（Ｔ２以降に属する時期）している場合には、経年劣化はありますが、正常です」等の出力を行うことができる。

Ｔ１既知の場合には、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ｔ１）用の各異常検知モデルからのスコアまたは判定結果が得られるので、先ず、（Ｘ＋Ａ１＋Ｔ０）、（Ｘ＋Ａ２＋Ｔ０）からのスコアまたは判定結果を用いて、動作環境Ａ１，Ａ２に関する異常検知結果の出力を行う。ここで、（Ｘ＋Ａ１＋Ｔ０）、（Ｘ＋Ａ２＋Ｔ０）から出力された尤度が、両方とも大きい等のように矛盾が生じた場合、あるいは、動作環境が悪いという判定結果になった場合には、それらの原因が経年劣化によるものかもしれないので、（Ｘ＋Ｔ１）からのスコアまたは判定結果を用いて、次のような出力を行うことができる。例えば、（Ｘ＋Ｔ１）から出力された尤度が大きければ、「お使いの機器は、動作環境が悪く、オイルを交換したほうがよいかもしれませんが、経年劣化の影響である可能性もあります。お早めに点検を依頼してください。」等の出力を行うことができる。Ｔ２以降既知の場合も同様である。

＜ケースＣ４－１：図１７（Ｂ）＞

図１７（Ｂ）において、状態推定器５０を構成するパターン認識器（１つのマルチタスクＣＮＮ）は、複数（第１～第９）のタスクで学習を行っている。いずれのタスクも２クラス分類としている。

第１のタスクは、目的動作Ｘと動作環境Ａ１と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｘ＋Ａ１＋Ｔ０）と、目的動作Ｘと動作環境Ａ２と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｘ＋Ａ２＋Ｔ０）との識別タスクである。第２のタスクは、目的動作Ｘと動作環境Ａ１と累積稼働回数・時間の区分けＴ１とを組み合わせた（Ｘ＋Ａ１＋Ｔ１）と、目的動作Ｘと動作環境Ａ２と累積稼働回数・時間の区分けＴ１とを組み合わせた（Ｘ＋Ａ２＋Ｔ１）との識別タスクである。第３のタスクは、目的動作Ｘと動作環境Ａ１と累積稼働回数・時間の区分けＴ２とを組み合わせた（Ｘ＋Ａ１＋Ｔ２）と、目的動作Ｘと動作環境Ａ２と累積稼働回数・時間の区分けＴ２とを組み合わせた（Ｘ＋Ａ２＋Ｔ２）との識別タスクである。

また、第４のタスクは、目的動作Ｙと動作環境Ａ１と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｙ＋Ａ１＋Ｔ０）と、目的動作Ｙと動作環境Ａ２と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｙ＋Ａ２＋Ｔ０）との識別タスクである。第５のタスクは、目的動作Ｙと動作環境Ａ１と累積稼働回数・時間の区分けＴ１とを組み合わせた（Ｙ＋Ａ１＋Ｔ１）と、目的動作Ｙと動作環境Ａ２と累積稼働回数・時間の区分けＴ１とを組み合わせた（Ｙ＋Ａ２＋Ｔ１）との識別タスクである。第６のタスクは、目的動作Ｙと動作環境Ａ１と累積稼働回数・時間の区分けＴ２とを組み合わせた（Ｙ＋Ａ１＋Ｔ２）と、目的動作Ｙと動作環境Ａ２と累積稼働回数・時間の区分けＴ２とを組み合わせた（Ｙ＋Ａ２＋Ｔ２）との識別タスクである。

さらに、第７のタスクは、目的動作Ｚと動作環境Ａ１と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｚ＋Ａ１＋Ｔ０）と、目的動作Ｚと動作環境Ａ２と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｚ＋Ａ２＋Ｔ０）との識別タスクである。第８のタスクは、目的動作Ｚと動作環境Ａ１と累積稼働回数・時間の区分けＴ１とを組み合わせた（Ｚ＋Ａ１＋Ｔ１）と、目的動作Ｚと動作環境Ａ２と累積稼働回数・時間の区分けＴ１とを組み合わせた（Ｚ＋Ａ２＋Ｔ１）との識別タスクである。第９のタスクは、目的動作Ｚと動作環境Ａ１と累積稼働回数・時間の区分けＴ２とを組み合わせた（Ｚ＋Ａ１＋Ｔ２）と、目的動作Ｚと動作環境Ａ２と累積稼働回数・時間の区分けＴ２とを組み合わせた（Ｚ＋Ａ２＋Ｔ２）との識別タスクである。

従って、図１７（Ｂ）の例では、図１７（Ａ）の例とは異なり、状態推定器５０には、累積稼働回数・時間の識別用の状態推定モデルが用意されていることになる。より正確には、状態推定器５０は、１つのパターン認識器（１つのマルチタスクＣＮＮ）により構成されているので、累積稼働回数・時間の識別用のタスク部分を備えているということになる。

図１７（Ｂ）において、異常検知器６０には、各目的動作Ｘ，Ｙ，Ｚと各動作環境Ａ１，Ａ２と累積稼働回数・時間の区分けＴ０，Ｔ１，Ｔ２の全ての組合せに対応する異常検知モデルが用意されている。すなわち、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ａ１＋Ｔ１）用、（Ｘ＋Ａ２＋Ｔ１）用、（Ｘ＋Ａ１＋Ｔ２）用、（Ｘ＋Ａ２＋Ｔ２）用、（Ｙ＋Ａ１＋Ｔ０）用、（Ｙ＋Ａ２＋Ｔ０）用、（Ｙ＋Ａ１＋Ｔ１）用、（Ｙ＋Ａ２＋Ｔ１）用、（Ｙ＋Ａ１＋Ｔ２）用、（Ｙ＋Ａ２＋Ｔ２）用、（Ｚ＋Ａ１＋Ｔ０）用、（Ｚ＋Ａ２＋Ｔ０）用、（Ｚ＋Ａ１＋Ｔ１）用、（Ｚ＋Ａ２＋Ｔ１）用、（Ｚ＋Ａ１＋Ｔ２）用、（Ｚ＋Ａ２＋Ｔ２）用の各異常検知モデルが用意されている。但し、（Ｚ＋Ａ１＋Ｔ０）用、（Ｚ＋Ａ２＋Ｔ０）用、（Ｚ＋Ａ１＋Ｔ１）用、（Ｚ＋Ａ２＋Ｔ１）用、（Ｚ＋Ａ１＋Ｔ２）用、（Ｚ＋Ａ２＋Ｔ２）用の図示は省略されている。

従って、異常検知器６０には、累積稼働回数・時間の識別用の異常検知モデルが用意されている。これらの異常検知モデルのうち、Ｔ０だけではなく、Ｔ１，Ｔ２のモデルも、後から追加されたものではなく、最初から用意されているので、この点が、図１７（Ａ）の例とは異なっている。

また、図１７（Ａ）における後から追加した累積稼働回数・時間の識別用の異常検知モデルとは異なり、図１７（Ｂ）の例では、Ｔ０だけではなく、Ｔ１，Ｔ２のモデルも、動作環境Ａ１，Ａ２との組合せのモデルとなっている。これは、初期モデルを用意するので、好ましくない動作環境を人為的に作り出すことができるからである。例えば、経年劣化した機器２０を廃棄物処理業者、メーカ、販売業者等が回収し、回収した機器２０において、好ましくない動作環境下でのデータ収集を行うことができる。

図１７（Ｂ）において、学習用の特徴データは、すべて状態推定器５０を構成する１つのパターン認識器（１つのマルチタスクＣＮＮ）から抽出された特徴データである。この点は、図１７（Ａ）の場合と同様である。

図１７（Ｂ）において、運用時には、全ての状態データが、１つのマルチタスクＣＮＮに入力されるが、そこから抽出された特徴データは、既知の情報である目的動作に対応する異常検知モデルのみに入力される。さらに、既知の情報である目的動作に対応する異常検知モデルの中でも、累積稼働回数または累積稼働時間に基づき、使用する異常検知モデルの選択が行われる。すなわち、制御状態監視システム１０による異常検知の対象となっている機器２０についての累積稼働回数・時間が、不明である場合（Ｔ未知）と、区分けＴ１に属する時期である場合（Ｔ１既知）と、区分けＴ２以降（Ｔ２，Ｔ３，Ｔ４，…）に属する時期である場合（Ｔ２以降既知）とで、使用する異常検知モデルが異なる。この点は、図１７（Ａ）の場合と同様である。

例えば、目的動作Ｘが既知であれば、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ａ１＋Ｔ１）用、（Ｘ＋Ａ２＋Ｔ１）用、（Ｘ＋Ａ１＋Ｔ２）用、（Ｘ＋Ａ２＋Ｔ２）用の各異常検知モデルに入力されるが、その他の異常検知モデルには入力されない。同様に、目的動作Ｙが既知であれば、（Ｙ＋Ａ１＋Ｔ０）用、（Ｙ＋Ａ２＋Ｔ０）用、（Ｙ＋Ａ１＋Ｔ１）用、（Ｙ＋Ａ２＋Ｔ１）用、（Ｙ＋Ａ１＋Ｔ２）用、（Ｙ＋Ａ２＋Ｔ２）用の各異常検知モデルに入力されるが、その他の異常検知モデルには入力されない。また、目的動作Ｚが既知の場合も同様である。

さらに、例えば目的動作Ｘが既知である場合において、累積稼働回数・時間に基づく選択により、Ｔ未知の場合には、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ａ１＋Ｔ１）用、（Ｘ＋Ａ２＋Ｔ１）用、（Ｘ＋Ａ１＋Ｔ２）用、（Ｘ＋Ａ２＋Ｔ２）用の各異常検知モデルに入力される。つまり、目的動作Ｘに関する全ての異常検知モデルに入力される。

また、Ｔ１既知の場合には、（Ｘ＋Ａ１＋Ｔ１）用、（Ｘ＋Ａ２＋Ｔ１）用の各異常検知モデルに入力されるが、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ａ１＋Ｔ２）用、（Ｘ＋Ａ２＋Ｔ２）用の異常検知モデルには入力されない。Ｔ１が判明しているときに、Ｔ０，Ｔ２の状態に近いか否かを判定する必要はないからである。なお、前述した図１７（Ａ）の場合に、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用の異常検知モデルにも入力していたのは、（Ｘ＋Ｔ１）用の異常検知モデルに、動作環境Ａ１，Ａ２が含まれていなかったからである。

さらに、Ｔ２以降既知の場合には、（Ｘ＋Ａ１＋Ｔ２）用、（Ｘ＋Ａ２＋Ｔ２）用の各異常検知モデルに入力されるが、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ａ１＋Ｔ１）用、（Ｘ＋Ａ２＋Ｔ１）用の異常検知モデルには入力されない。Ｔ２以降（Ｔ２，Ｔ３，Ｔ４，…）が判明しているときに、Ｔ０，Ｔ１の状態に近いか否かを判定する必要はないからである。なお、Ｔ３以降のモデルがないので、Ｔ３以降既知の場合には、最も状態が近いＴ２のモデルを使用することにしている。

Ｔ未知の場合には、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ａ１＋Ｔ１）用、（Ｘ＋Ａ２＋Ｔ１）用、（Ｘ＋Ａ１＋Ｔ２）用、（Ｘ＋Ａ２＋Ｔ２）用の各異常検知モデルからのスコアまたは判定結果が得られるので、Ｔ０，Ｔ１，Ｔ２の各々について動作環境Ａ１，Ａ２に関する異常検知結果の条件付きの出力を行う。例えば、「お使いの機器が、もし初めての使用でしたら（Ｔ０相当）、オイルが～ですので～してください。もし稼働開始後～年目から～年目の間（Ｔ１に属する時期）でしたら、オイルが～ですので～してください。もし稼働開始後～年以上経過（Ｔ２以降に属する時期）していましたら、オイルが～ですので～してください。」等の出力を行うことができる。

また、Ｔ１既知、Ｔ２以降既知の場合には、使用する異常検知モデルが絞られているので、動作環境Ａ１，Ａ２に関する異常検知結果について、条件付きではなく、通常の出力を行う。

＜前段の状態推定を複数のパターン認識器で行う場合（ケースＣ４－２）：図１８＞

図１８において、状態推定器５０は、一例として、複数のパターン認識器（いずれもシングルタスクＣＮＮ）により構成されている。図１８（Ａ）の例は、後から累積稼働回数・時間の識別用の異常検知モデルを追加する場合であり、図１８（Ｂ）の例は、累積稼働回数・時間の識別用の状態推定モデルおよび異常検知モデルが最初から用意されている場合である。

＜ケースＣ４－２：図１８（Ａ）＞

図１８（Ａ）において、状態推定器５０は、複数（３つ）のパターン認識器（ＣＮＮ）により構成されている。すなわち、目的動作Ｘと動作環境Ａ１と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｘ＋Ａ１＋Ｔ０）と、目的動作Ｘと動作環境Ａ２と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｘ＋Ａ２＋Ｔ０）との識別用のパターン認識器（ＣＮＮ）と、目的動作Ｙと動作環境Ａ１と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｙ＋Ａ１＋Ｔ０）と、目的動作Ｙと動作環境Ａ２と累積稼働回数・時間の区分けＴ０を組み合わせた（Ｙ＋Ａ２＋Ｔ０）との識別用のパターン認識器（ＣＮＮ）と、目的動作Ｚと動作環境Ａ１と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｚ＋Ａ１＋Ｔ０）と、目的動作Ｚと動作環境Ａ２と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｚ＋Ａ２＋Ｔ０）との識別用のパターン認識器（ＣＮＮ）とにより構成されている。但し、（Ｚ＋Ａ１＋Ｔ０）と（Ｚ＋Ａ２＋Ｔ０）との識別用のパターン認識器（ＣＮＮ）の図示は省略されている。従って、図１８（Ａ）の例では、状態推定器５０には、累積稼働回数・時間の識別用の状態推定モデルは用意されていない。

図１８（Ａ）において、異常検知器６０には、各目的動作Ｘ，Ｙ，Ｚと各動作環境Ａ１，Ａ２と累積稼働回数・時間の区分けＴ０との全ての組合せに対応する異常検知モデルが用意されている。すなわち、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｙ＋Ａ１＋Ｔ０）用、（Ｙ＋Ａ２＋Ｔ０）用、（Ｚ＋Ａ１＋Ｔ０）用、（Ｚ＋Ａ２＋Ｔ０）用の各異常検知モデルが用意されている。但し、（Ｚ＋Ａ１＋Ｔ０）用、（Ｚ＋Ａ２＋Ｔ０）用の図示は省略されている。

また、異常検知器６０には、図１８（Ａ）中の点線で示すように、後から追加された複数（６つ）の累積稼働回数・時間の識別用の異常検知モデルが用意されている。すなわち、（Ｘ＋Ｔ１）用、（Ｘ＋Ｔ２）用、（Ｙ＋Ｔ１）用、（Ｙ＋Ｔ２）用、（Ｚ＋Ｔ１）用、（Ｚ＋Ｔ２）用の各異常検知モデルが用意されている。但し、（Ｚ＋Ｔ１）用、（Ｚ＋Ｔ２）用の図示は省略されている。

図１８（Ａ）において、学習時には、（Ｘ＋Ｔ１）用、（Ｘ＋Ｔ２）用の異常検知モデルは、状態推定器５０を構成する複数のパターン認識器（ＣＮＮ）のうちの対応するパターン認識器（（Ｘ＋Ａ１＋Ｔ０）と（Ｘ＋Ａ２＋Ｔ０）との識別用のパターン認識器）から抽出された特徴データを用いて学習を行う。

また、（Ｙ＋Ｔ１）用、（Ｙ＋Ｔ２）用の異常検知モデルは、状態推定器５０を構成する複数のパターン認識器（ＣＮＮ）のうちの対応するパターン認識器（（Ｙ＋Ａ１＋Ｔ０）と（Ｙ＋Ａ２＋Ｔ０）との識別用のパターン認識器）から抽出された特徴データを用いて学習を行う。

図示は省略されているが、（Ｚ＋Ｔ１）用の異常検知モデル、（Ｚ＋Ｔ２）用の異常検知モデルの場合も同様である。

図１８（Ａ）において、運用時には、状態データは、既知の目的動作に対応するパターン認識器（ＣＮＮ）に入力される。例えば、目的動作Ｘが既知である場合には、（Ｘ＋Ａ１＋Ｔ０）と（Ｘ＋Ａ２＋Ｔ０）との識別用のパターン認識器に入力され、そこから抽出された特徴データは、対応する異常検知モデルのみに入力される。さらに、既知の情報である目的動作に対応する異常検知モデルの中でも、累積稼働回数または累積稼働時間に基づき、使用する異常検知モデルの選択が行われる。すなわち、制御状態監視システム１０による異常検知の対象となっている機器２０についての累積稼働回数・時間が、不明である場合（Ｔ未知）と、区分けＴ１に属する時期である場合（Ｔ１既知）と、区分けＴ２以降（Ｔ２，Ｔ３，Ｔ４，…）に属する時期である場合（Ｔ２以降既知）とで、使用する異常検知モデルが異なる。この点は、図１７（Ａ）の場合と同様である。

その後、出力手段７０により、異常検知結果の出力が行われる。この際、Ｔ未知の場合と、Ｔ１既知の場合と、Ｔ２以降既知の場合とで、出力形式が異なる。この点も、図１７（Ａ）の場合と同様である。

＜ケースＣ４－２：図１８（Ｂ）＞

図１８（Ｂ）において、状態推定器５０は、複数（９つ）のパターン認識器（ＣＮＮ）により構成されている。すなわち、状態推定器５０は、目的動作Ｘと動作環境Ａ１と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｘ＋Ａ１＋Ｔ０）と、目的動作Ｘと動作環境Ａ２と累積稼働回数・時間の区分けＴ０とを組み合わせた（Ｘ＋Ａ２＋Ｔ０）との識別用のパターン認識器（ＣＮＮ）を備えている。また、目的動作Ｘと動作環境Ａ１と累積稼働回数・時間の区分けＴ１とを組み合わせた（Ｘ＋Ａ１＋Ｔ１）と、目的動作Ｘと動作環境Ａ２と累積稼働回数・時間の区分けＴ１とを組み合わせた（Ｘ＋Ａ２＋Ｔ１）との識別用のパターン認識器（ＣＮＮ）を備えている。さらに、目的動作Ｘと動作環境Ａ１と累積稼働回数・時間の区分けＴ２とを組み合わせた（Ｘ＋Ａ１＋Ｔ２）と、目的動作Ｘと動作環境Ａ２と累積稼働回数・時間の区分けＴ２とを組み合わせた（Ｘ＋Ａ２＋Ｔ２）との識別用のパターン認識器（ＣＮＮ）を備えている。また、図示は省略されているが、目的動作Ｙ，Ｚの各々についても、動作環境Ａ１，Ａ２と累積稼働回数・時間Ｔ０，Ｔ１，Ｔ２との組合せの識別用のパターン認識器（ＣＮＮ）を備えている。従って、図１８（Ｂ）の例では、図１８（Ａ）の例とは異なり、状態推定器５０には、累積稼働回数・時間の識別用の状態推定モデルが用意されている。

図１８（Ｂ）において、異常検知器６０には、各目的動作Ｘ，Ｙ，Ｚと各動作環境Ａ１，Ａ２と累積稼働回数・時間の区分けＴ０，Ｔ１，Ｔ２との全ての組合せに対応する異常検知モデルが用意されている。すなわち、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ａ１＋Ｔ１）用、（Ｘ＋Ａ２＋Ｔ１）用、（Ｘ＋Ａ１＋Ｔ２）用、（Ｘ＋Ａ２＋Ｔ２）用の各異常検知モデルが用意されている。また、図示は省略されているが、（Ｙ＋Ａ１＋Ｔ０）用、（Ｙ＋Ａ２＋Ｔ０）用、（Ｙ＋Ａ１＋Ｔ１）用、（Ｙ＋Ａ２＋Ｔ１）用、（Ｙ＋Ａ１＋Ｔ２）用、（Ｙ＋Ａ２＋Ｔ２）用、（Ｚ＋Ａ１＋Ｔ０）用、（Ｚ＋Ａ２＋Ｔ０）用、（Ｚ＋Ａ１＋Ｔ１）用、（Ｚ＋Ａ２＋Ｔ１）用、（Ｚ＋Ａ１＋Ｔ２）用、（Ｚ＋Ａ２＋Ｔ２）用の各異常検知モデルが用意されている。この点は、図１７（Ｂ）の場合と同様である。

従って、異常検知器６０には、累積稼働回数・時間の識別用の異常検知モデルが用意されている。これらの異常検知モデルのうち、Ｔ０だけではなく、Ｔ１，Ｔ２のモデルも、後から追加されたものではなく、最初から用意されているので、この点が、図１８（Ａ）の例とは異なっている。

また、図１８（Ａ）における後から追加した累積稼働回数・時間の識別用の異常検知モデルとは異なり、図１８（Ｂ）の例では、Ｔ０だけではなく、Ｔ１，Ｔ２のモデルも、動作環境Ａ１，Ａ２との組合せのモデルとなっている。これは、初期モデルを用意するので、好ましくない動作環境を人為的に作り出すことができるからである。例えば、経年劣化した機器２０を廃棄物処理業者、メーカ、販売業者等が回収し、回収した機器２０において、好ましくない動作環境下でのデータ収集を行うことができる。この点は、図１７（Ｂ）の場合と同様である。

図１８（Ｂ）において、学習時には、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用の異常検知モデルは、状態推定器５０を構成する複数のパターン認識器（ＣＮＮ）のうちの対応するパターン認識器（（Ｘ＋Ａ１＋Ｔ０）と（Ｘ＋Ａ２＋Ｔ０）との識別用のパターン認識器）から抽出された特徴データを用いて学習を行う。また、（Ｘ＋Ａ１＋Ｔ１）用、（Ｘ＋Ａ２＋Ｔ１）用の異常検知モデルは、状態推定器５０を構成する複数のパターン認識器（ＣＮＮ）のうちの対応するパターン認識器（（Ｘ＋Ａ１＋Ｔ１）と（Ｘ＋Ａ２＋Ｔ１）との識別用のパターン認識器）から抽出された特徴データを用いて学習を行う。さらに、（Ｘ＋Ａ１＋Ｔ２）用、（Ｘ＋Ａ２＋Ｔ２）用の異常検知モデルは、状態推定器５０を構成する複数のパターン認識器（ＣＮＮ）のうちの対応するパターン認識器（（Ｘ＋Ａ１＋Ｔ２）と（Ｘ＋Ａ２＋Ｔ２）との識別用のパターン認識器）から抽出された特徴データを用いて学習を行う。図示は省略されているが、目的動作Ｙ，Ｚに関する異常検知モデルの学習も同様である。

図１８（Ｂ）において、運用時には、状態データは、既知の目的動作に対応するパターン認識器（ＣＮＮ）に入力される。例えば、目的動作Ｘが既知である場合には、（Ｘ＋Ａ１＋Ｔ０）と（Ｘ＋Ａ２＋Ｔ０）との識別用のパターン認識器か、（Ｘ＋Ａ１＋Ｔ１）と（Ｘ＋Ａ２＋Ｔ１）との識別用のパターン認識器か、（Ｘ＋Ａ１＋Ｔ２）と（Ｘ＋Ａ２＋Ｔ２）との識別用のパターン認識器に入力され、そこから抽出された特徴データは、対応する異常検知モデルのみに入力される。この際、既知の情報である目的動作に対応するパターン認識器（ＣＮＮ）の中において、累積稼働回数または累積稼働時間に基づき、使用するパターン認識器（ＣＮＮ）の選択（状態推定モデルの選択）が行われる。すなわち、制御状態監視システム１０による異常検知の対象となっている機器２０についての累積稼働回数・時間が、不明である場合（Ｔ未知）と、区分けＴ１に属する時期である場合（Ｔ１既知）と、区分けＴ２以降（Ｔ２，Ｔ３，Ｔ４，…）に属する時期である場合（Ｔ２以降既知）とで、使用するパターン認識器（ＣＮＮ）、つまり使用する状態推定モデルが異なる。

例えば目的動作Ｘが既知である場合において、累積稼働回数・時間に基づく選択により、Ｔ未知の場合には、状態データは、（Ｘ＋Ａ１＋Ｔ０）と（Ｘ＋Ａ２＋Ｔ０）との識別用のパターン認識器と、（Ｘ＋Ａ１＋Ｔ１）と（Ｘ＋Ａ２＋Ｔ１）との識別用のパターン認識器と、（Ｘ＋Ａ１＋Ｔ２）と（Ｘ＋Ａ２＋Ｔ２）との識別用のパターン認識器との全部に入力される。そして、これらのパターン認識器に入力され、そこから抽出された特徴データは、それぞれのパターン認識器に対応する異常検知モデルのみに入力される。

また、Ｔ１既知の場合には、（Ｘ＋Ａ１＋Ｔ１）と（Ｘ＋Ａ２＋Ｔ１）との識別用のパターン認識器のみに入力され、そこから抽出された特徴データは、そのパターン認識器に対応する異常検知モデルのみに入力される。

さらに、Ｔ２以降既知の場合には、（Ｘ＋Ａ１＋Ｔ２）と（Ｘ＋Ａ２＋Ｔ２）との識別用のパターン認識器のみに入力され、そこから抽出された特徴データは、そのパターン認識器に対応する異常検知モデルのみに入力される。

その後、出力手段７０により、異常検知結果の出力が行われる。この際、Ｔ未知の場合と、Ｔ１既知の場合と、Ｔ２以降既知の場合とで、出力形式が異なる。それぞれの場合の出力形式は、図１７（Ｂ）の場合と同様である。例えば、目的動作Ｘでの動作制御中であれば、次のようになる。

Ｔ未知の場合には、（Ｘ＋Ａ１＋Ｔ０）用、（Ｘ＋Ａ２＋Ｔ０）用、（Ｘ＋Ａ１＋Ｔ１）用、（Ｘ＋Ａ２＋Ｔ１）用、（Ｘ＋Ａ１＋Ｔ２）用、（Ｘ＋Ａ２＋Ｔ２）用の各異常検知モデルからのスコアまたは判定結果が得られるので、図１７（Ｂ）の場合と同様に、Ｔ０，Ｔ１，Ｔ２の各々について動作環境Ａ１，Ａ２に関する異常検知結果の条件付きの出力を行う。

また、Ｔ１既知、Ｔ２以降既知の場合には、図１７（Ｂ）の場合と同様に、使用する異常検知モデルが絞られているので、動作環境Ａ１，Ａ２に関する異常検知結果について、条件付きではなく、通常の出力を行う。

＜第４実施形態の効果＞

このような第４実施形態によれば、前記第１、第２実施形態で得られる効果と同様な効果が得られることに加え、次のような効果を得ることができる。

すなわち、制御状態監視システム１０は、状態推定モデル記憶手段５２に、累積稼働回数・時間を識別可能な状態推定モデルを記憶する構成とされ、また、異常検知モデル記憶手段６２に、累積稼働回数・時間を識別可能な異常検知モデルを記憶する構成とされているので、機器２０の経年劣化の状態を捉えつつ、異常検知を行うことができる。

また、実稼働を長期間継続することにより経年劣化の状態を実際に作らないと必要な学習用データが得られないので、通常は、機器２０の販売が開始されてから、ある程度の期間が経過した時点で、必要な学習用データが得られることになる。この際、制御状態監視システム１０は、前段の状態推定器５０と後段の異常検知器６０との２段構成になっているので、状態推定モデルを変えることなく、後から異常検知モデルを追加することができる。従って、販売開始後、時間が経過し、必要な学習用データである特徴データが得られれば、累積稼働回数・時間を識別可能な異常検知モデルを構築することができ、その異常検知モデルを後からでも容易に本システムに追加することができる。従って、制御状態監視システム１０の性能向上を容易に図ることができる。また、機器２０の管理者の事情や都合により、状態データを収集することができなくても、後から得られた特徴データだけで累積稼働回数・時間を識別可能な異常検知モデルを構築し、追加することができる。

［変形の形態］

なお、本発明は前記実施形態に限定されるものではなく、本発明の目的を達成できる範囲内での変形等は本発明に含まれるものである。

例えば、前記実施形態では、制御状態監視システム１０は、ネットワーク１を用いて構成されていたが、本発明の制御状態監視システムは、スタンドアロンの構成としてもよく、また、スタンドアロンの構成とする場合には、機器２０と一体化してもよい。さらに、前記第１実施形態の説明でも詳述したが、状態データ取得手段４０および状態推定器５０を接続装置２６に設けてもよく、その場合には、特徴データがネットワーク１上を流れることになり、また、状態データ取得手段４０および状態推定器５０を機器２０と一体化してもよく、その場合には、特徴データが接続装置２６を経由してネットワーク１を介して異常検知器６０に送信される。そして、スタンドアロンの構成とする場合には、例えば、機器２０の周辺に設けられた配電盤や分電盤に、制御状態監視システム１０の全ての機能を集中させてもよい。

また、本発明の制御状態監視システムを、スタンドアロンの構成とする場合には、状態推定モデルや異常検知モデルの更新に用いる学習用の状態データや特徴データの収集は、ネットワーク経由ではなく、保守・点検業者やメーカ等の作業員、あるいは一般ユーザが、例えばＵＳＢメモリやＤＶＤ等の記録媒体で行ってもよい。

さらに、前記第３実施形態では、故障発生予兆の有無を判定し、前記第４実施形態では、累積稼働回数・時間を考慮した異常検知を行う構成とされていたが、前記第３、第４実施形態を同時に適用してもよい。すなわち、累積稼働回数・時間を考慮しつつ、故障発生予兆の有無の判定を伴う異常検知を行ってもよい。

そして、前記各実施形態で示された具体例では、目的動作Ｘ，Ｙ，Ｚは、１つのパラメータで定められた目的動作であったが、複数のパラメータの組み合わせによる複合的な目的動作とすることもできる。そして、この場合、後段の異常検知器６０が、目的動作の単位で出力を行う構成であるのに対し、マルチタスクのニューラル・ネットワーク（例えば、マルチタスクＣＮＮ）で構成した前段の状態推定器５０は、目的動作を構成する各パラメータ単位でのクラス識別結果を出力する構成としてもよい。

すなわち、パラメータα＝α１，α２，α３，…、パラメータβ＝β１，β２，β３，…、パラメータγ＝γ１，γ２，γ３，…、パラメータδ＝δ１，δ２，δ３，…等を組み合わせて、例えば、目的動作Ｘ＝「α１かつβ１かつγ１かつδ１」、目的動作Ｙ＝「α１かつβ２かつγ１かつδ１」、目的動作Ｚ＝「α２かつβ１かつγ１かつδ１」等のような複合的な目的動作を定めることができる。各パラメータα，β，γ，δ等は、すべて既知の情報であるから、それらを組み合わせた目的動作Ｘ，Ｙ，Ｚ等も既知の情報となる。具体的には、例えば、パラメータα（回転数）＝α１（１００回転），α２（５０回転）等であり、パラメータβ（ファン）＝β１（ＯＮ），β２（ＯＦＦ）等である。

この場合に、後段の異常検知器６０は、前記各実施形態のように、目的動作Ｘ，Ｙ，Ｚに対応する異常検知モデルを構築し、目的動作Ｘ，Ｙ，Ｚに対応する判定結果を出力するようにする。一方、前段の状態推定器５０は、パラメータ単位での識別を行うタスク部分を備えたマルチタスクＮＮ（例えばマルチタスクＣＮＮ）により構成することができる。この際、パラメータ単位での識別を行うタスク部分は、１つのパラメータだけに対応するタスク部分としてもよく、複数のパラメータの組合せに対応するタスク部分としてもよい。具体的には、１つのパラメータだけに対応するタスク部分としては、例えば、α１（１００回転）であるかそれ以外であるかの識別を行うタスク部分、α２（５０回転）であるかそれ以外であるかの識別を行うタスク部分、β１（ファンＯＮ）とβ２（ファンＯＦＦ）との識別を行うタスク部分等である。また、複数のパラメータの組合せに対応するタスク部分としては、例えば、「α１かつβ１」であるかそれ以外であるかの識別を行うタスク部分、「α１かつβ１かつγ１」であるかそれ以外であるかの識別を行うタスク部分等であるが、通常は、目的動作Ｘ，Ｙ，Ｚを構成するパラメータ数未満のパラメータ数の組合せとする。目的動作Ｘ，Ｙ，Ｚを構成するパラメータ数と同数の組合せとしてしまうと、結局、目的動作Ｘ，Ｙ，Ｚ自体であるか否かの識別を行うことになり、パラメータ単位での識別を行うタスク部分とは言えないからである。

前段の状態推定器５０と後段の異常検知器６０との関係について、より具体的に述べると、次のようになる。例えば、目的動作Ｘ＝「１００回転、かつ、ファンＯＮでの定常運転」であり、目的動作Ｙ＝「１００回転、かつ、ファンＯＦＦでの定常運転」であり、目的動作Ｚ＝「５０回転、かつ、ファンＯＦＦでの定常運転」であるとする。マルチタスクＣＮＮによる状態推定器５０において、１００回転での正常な運転であるか、それ以外であるかの識別用の第１のタスクと、５０回転での正常な運転であるか、それ以外であるかの識別用の第２のタスクと、ファンのＯＮ／ＯＦＦの識別用の第３のタスクとで学習行えば、その学習結果として、このマルチタスクＣＮＮの共有部についてのパラメータの値は、上記の目的動作Ｘ，Ｙ，Ｚでの各運転が正常であるか否かの判定を行うための特徴データとして、適切な特徴データを抽出することができる状態となる。従って、このような学習で得られたマルチタスクＣＮＮによる状態推定器５０に、目的動作Ｘ（１００回転、かつ、ファンＯＮでの定常運転）が正常であるときの状態データを入力し、そこから抽出される特徴データを、目的動作Ｘ用の異常検知器６０の学習用データとして用いることができる。目的動作Ｙ，Ｚについても同様である。

以上のように、状態推定器５０を、目的動作を構成するパラメータ単位での識別を行うタスク部分を備えたマルチタスクのニューラル・ネットワークによるパターン認識処理を行う構成とした場合も、本発明の状態推定器における「制御実行中の動作部の実際の動作状態が、制御の目的動作を示す状態になっているか否かまたは制御の達成度を示すデータを出力するパターン認識処理」に該当する。複数のタスク部分からの出力結果を統合すると、該当する状態になるからである。

以上のように、本発明の状態監視システムおよびプログラムは、例えば、交流電源を動力源として稼働する電気機器の動作制御の状態を監視する場合等に用いるのに適している。

１０制御状態監視システム
２０機器
２１動作部
２２制御部
２３電源
２４状態監視用センサ
５０状態推定器
５２状態推定モデル記憶手段
６０異常検知器
６２異常検知モデル記憶手段

Claims

動作部およびこの動作部を制御する制御部を有する機器の動作制御の状態を、制御の目的動作が既知の状況下で監視する制御状態監視システムであって、
前記制御部から送出されて前記動作部へ入力される制御信号、この制御信号以外で前記動作部へ入力される外部入力データ、前記動作部から前記制御部に向けて出力される制御用のフィードバック信号またはその他の内部観測データ、この内部観測データ以外の観測データを得るために設置された状態監視用センサから出力される外部観測データのうちの少なくとも１つの状態データから作成されたパターン認識用の入力データを用いて、制御実行中の前記動作部の実際の動作状態が、前記制御の目的動作を示す状態になっているか否かまたは制御の達成度を示すデータを出力するパターン認識処理を実行し、このパターン認識処理で得られる特徴データを抽出する処理を繰り返し実行する状態推定器と、
この状態推定器により抽出した前記特徴データを用いて、クラス識別処理、外れ値検知処理、新規性検知処理のうちの少なくとも１つの処理を実行し、動作制御の異常の有無または程度を示すスコアを出力する処理を実行する異常検知器とを備え、
前記状態推定器は、
ニューラル・ネットワークによるパターン認識処理を実行し、前記特徴データとして、少なくとも１つの目的動作に対応する少なくとも１組の出力ノードに至る中間層の出力データを抽出する処理を実行する構成とされている
ことを特徴とする制御状態監視システム。
前記状態推定器を構成する状態推定モデル記憶手段は、
人為的に作り出された前記機器の故障の原因となり得る少なくとも１つの動作環境を含む複数の動作環境下での状態データの各集合およびこれらの各集合に付されるタグ情報を用意し、用意した状態データの各集合および各集合のタグ情報を用いて学習処理を実行することにより作成された動作環境の識別が可能な状態推定モデルを記憶する構成とされている
ことを特徴とする請求項１に記載の制御状態監視システム。
前記異常検知器を構成する異常検知モデル記憶手段は、
人為的に作り出された前記機器の故障の原因となり得る少なくとも１つの動作環境を含む複数の動作環境下での特徴データの各集合およびこれらの各集合に付されるタグ情報を用意し、用意した特徴データの各集合および各集合のタグ情報を用いて学習処理を実行することにより作成された動作環境の識別が可能な異常検知モデルを記憶する構成とされている
ことを特徴とする請求項１または２に記載の制御状態監視システム。
請求項１～３のいずれかに記載の制御状態監視システムとして、コンピュータを機能させるためのプログラム。