JP2019144747A - 分析モデル構築支援装置および分析モデル構築支援方法 - Google Patents

Abstract

【課題】分析モデル開発者の負担を増大させることなく、モデル再利用の際に、各パラメータについてどのような手段で調整を行うかを提示する。【解決手段】分析モデルの構築作業を支援する分析モデル用支援装置であって、入力装置、出力装置、記憶装置、および処理部を備える。装置構成は単一の装置で構成しても良いし、クラウドで構成された分散的なシステムでも良い。記憶装置は、分析モデルの開発プログラムの操作履歴、および、分析モデルのバージョン管理プログラムの差分情報を記憶する。処理部は、履歴整形プログラム、作業分類プログラム、および分類結果提示プログラムを実行する。履歴整形プログラムは、操作履歴と差分情報を対応付ける。作業分類プログラムは、操作履歴に現れるデータ参照関係に基づいて、差分情報に現れる分析モデルのパラメータを分類して分類結果を得る。分類結果提示プログラムは、出力装置に分類結果に基づいた情報を出力する。【選択図】図１

Description

本発明は、データ分析やシミュレーションを行う分析モデルの構築作業手順支援システムに関する。

近年、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）技術、すなわち、各種設備や機器に設置されたセンサからの情報をネットワーク経由等で収集して機械の稼動状態をモニタリングし、運用や保守に活用するための技術が普及しつつある。当該分野では，センサデータを収集して異常診断を行うための分析手順をプログラムとして構築したり、対象の動作シミュレーションを行ったりするための物理モデルを構築する必要がある（以後、それらを総称して「分析モデル」と呼ぶ）。

それらの分析モデルでは，たとえ同じ種類の設備や機器であっても，ユーザの分析目的や，稼働状況や運用状況に応じてカスタマイズが必要である。カスタマイズは、具体的には、分析モデルが持つ多くのパラメータを調整することで行われる。ここで、パラメータとは、分析モデルを決定する各種数値や、構成に関する種別情報、例えば診断モデルのアルゴリズムとして候補中のどれを選ぶか、などの調整に関する選択枝を総称したものとする。

パラメータの調整の代表的な方法は、入力データによる機械学習である。例えば、特許文献１では、シミュレーションモデルで実プラントの動作予測を行うため、実プラントから受け取ったデータに基づいてシミュレーションモデルを随時修正する手法が提案されている。

しかしながら、分析モデルのパラメータには，センシングデータを用いた学習で決定できるもの以外にも，業務の状況を勘案して決定しなくてはいけないもの、顧客の目的に沿って決定しなくてはいけないものなどが存在する。

その中で、業務状況を勘案して決定されるパラメータは、業務記録データが存在する範囲で、それを参照して決定することが可能である。例えば、プラントにおいて、ある期間に運転中にテスト動作が行われているような場合、センサデータにノイズが乗ってしまうため、その間のデータは機械学習には活用すべきではない。このため、利用データの期間を指定するパラメータは、運転中保全があるかないかの情報を基に、その期間を除外する処理を構成することで決定することが可能である。

一方、何らかのデータに準拠できず、顧客の目的に沿って決定しなくてはいけないパラメータの決定経緯は、基本的には作業者の記録に頼るしかない。例えば、異常検出モデルにおいて、何割の誤報と検出漏れをそれぞれ許すかの目標値などがその例である。

設計の決定理由を手動で記録して再活用する試みとして、例えば、非特許文献１では、設計変更の議論の経緯を、問題、立場、意見、その他、などと区別したノード間を賛成、反対、一般化、特殊化、提案等の関係でネットワーク状に繋いで記録する書式が提案されている。

特開２００５−３３２３６０号公報

Ｊｅｆｆ Ｃｏｎｋｌｉｎ, Ｍｉｃｈａｅｌ Ｌ. Ｂｅｇｅｍａｎ, "ｇＩＢＩＳ： ａ ｈｙｐｅｒｔｅｘｔ ｔｏｏｌ ｆｏｒ ｅｘｐｌｏｒａｔｏｒｙ ｐｏｌｉｃｙ ｄｉｓｃｕｓｓｉｏｎ, " Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １９８８ ＡＣＭ ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ−ｓｕｐｐｏｒｔｅｄ ｃｏｏｐｅｒａｔｉｖｅ ｗｏｒｋ, Ｐａｇｅｓ １４０−１５２, １９８８.

上述したとおり、分析モデルのパラメータは、上記非特許文献１のように設計者が意図して決定の経緯が記録されれば、モデルの再利用の際にその記録を参照することで容易に設定可能となる。しかしながら、設計者にとって、検討の経緯を記録することの作業量が増えるため、計算機プログラムの開発に比べて少人数によって短期間で作成することが多い分析モデル開発では、検討経緯の記録が実現されている事例は多くない。

そのため、なるべく自動で分析モデルパラメータ決定の経緯を記録できることが望ましい。その第一ステップとして、分析モデルが持つパラメータ中で、どれがデータによる学習で決定されたのか、どれが作業者の手動によって調整されたのかが自動で分類され、再利用の際にその情報が活用できることが望ましい。

本発明の一側面は、分析モデルの構築作業を支援する分析モデル用支援装置であって、入力装置、出力装置、記憶装置、および処理部を備える。装置構成は、単一の装置で構成しても良いし、クラウドで構成された分散的なシステムでも良い。記憶装置は、分析モデルの開発プログラムの操作履歴、および、分析モデルのバージョン管理プログラムの差分情報を記憶する。処理部は、履歴整形プログラム、作業分類プログラム、および分類結果提示プログラムを実行する。履歴整形プログラムは、操作履歴と差分情報を対応付ける。作業分類プログラムは、操作履歴に現れるデータ参照関係に基づいて、差分情報に現れる分析モデルのパラメータを分類して分類結果を得る。分類結果提示プログラムは、出力装置に分類結果に基づいた情報を出力する。

本発明の他の一側面は、入力装置、出力装置、記憶装置、および処理部を備える情報処理装置を用い、分析モデルのモデル開発プログラムの操作ログ、および、分析モデルのバージョン間のモデル差分データに基づいて、分析モデルのパラメータを分類する分析モデル構築支援方法である。操作ログは複数の行を含み、操作ログの複数の行のそれぞれは項目として、分析モデルに対する操作内容の項目、および操作で参照したデータである参照データの項目を含む。モデル差分データは複数の行を含み、モデル差分データの複数の行のそれぞれは項目として、分析モデルの差分情報の項目を含む。この方法では、操作ログの行とモデル差分データの行を、操作ログの項目の内容とモデル差分データの項目の内容の組み合わせパターンを予め設定した関連ルールに基づいて対応付けする、対応付けステップを実行する。また、モデル差分データの所定の行の差分情報の項目の内容であるパラメータを、対応する操作ログの行の参照データの項目の内容に基づいて分類する、分類ステップを実行する。

分析モデル開発者の負担を増大させることなく，モデル再利用の際に、各パラメータについてどのような手段で調整を行うべきかがわかる。この結果、作業量削減や、非熟練者であってもモデルの調整が容易にできるなどの効果が得られる。

実施例１の装置構成例を示すブロック図である。 モデル開発プログラムの操作ログである操作ログの概念例を示すテーブルである。 バージョン管理プログラムが出力したモデル差分データの概念例を示すテーブルである。 関連ルールリストの概念例を示すテーブルである。 実施例１における記録動作の全体手順を示すフローチャートである。 差分データと操作ログ対応付けの手順を示すフローチャートである。 差分データと操作ログ対応付けの手順で関連付けられた合成データの概念図を示すテーブルである。 差分データと操作ログ対応付け結果を用いた、一つのパラメータ差分イベントについてのパラメータ分類の手順を示すフローチャートである。 モデル再利用の際に記録された分類データを提示して支援する手順を示すフローチャートである。 実施例１におけるＧＵＩ例を示すイメージ図である。 実施例２の装置構成例を示すブロック図である。 作業者データの概念例を示すテーブルである。 実施例２における記録動作の全体手順を示すフローチャートである。 実施例２におけるＧＵＩ例を示すイメージ図である。

以下図面に沿って、本発明の一実施の形態を詳述する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。

本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数、順序、もしくはその内容を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。

図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。

図１に本実施例の装置構成例を示す。本構成例は、サーバ計算機にて処理フロー設計を行うと同時に、分析モデルが持つパラメータ修正作業の分類支援を行う場合の構成例である。分析モデル構築用サーバ（１０１）は、処理部（１０２）、記憶装置（１０３）、通信Ｉ／Ｆ（１０４）で構成され、ネットワーク（１０５）を介して作業端末（１０６）にてユーザが操作を行う。分析モデル構築用サーバの処理部には、モデル開発プログラム（１０７）、バージョン管理プログラム（１０８）、履歴整形プログラム（１０９）、作業分類プログラム（１１０）、分類結果提示プログラム（１１１）などのプログラムが動作可能となっている。

モデル開発プログラム（１０７）は、それを用いてユーザが分析モデルの処理内容を設計するためのプログラムであり、例えば、ＧＵＩによってモデルの処理の流れを表示しながらユーザがそれを変更することで設計を行うものである。具定例としては、分析フロー記述プラットフォームであるKNIME（商標）など、既存のプログラムが利用可能である。

バージョン管理プログラム（１０８）は、モデル開発プログラム上で設計された結果が記述されたモデル設計データ（後述）がどのように変化してきたか、差分を記録するプログラムである。公知のプログラム開発用のバージョン管理プログラムが利用可能である。

履歴整形プログラム（１０９）は、モデル開発のログとバージョン管理の差分情報を用いてパラメータの修正と参照データを関連付けて抽出する処理を行う。その手順の詳細は処理フローの図面を用いて後述する。

作業分類プログラム（１１０）は、参照データの種類から、パラメータ修正作業がどの作業パターンに分類されるかラベル付けを行う。

分類結果提示プログラム（１１１）は、作業分類の結果をユーザに提示することで、モデル設計の支援を行う。

記憶装置には、モデル設計データ（１１２）、センサデータ（１１３）、業務データ（１１４）、操作ログ（１１５）、モデル差分データ（１１６）、関連ルールリスト（１１７）、作業分類データ（１１８）の各データが格納される。

モデル設計データ（１１２）は、モデル開発プログラム上で設計された分析モデルの構造を記述するデータで、プログラム記述に相当する。例えば、データの読み込みをどこから行って、どのような処理を行って、どのような出力を行うか、分析のプロセスが記述されている。

センサデータ（１１３）は、分析モデルが入力データとして読み込んで、一部のパラメータの学習や動作検証に用いる。すなわち、分析モデルが分析する対象のデータである。このセンサデータは、装置から収集されて、一旦本サーバに格納されているとする。その他の構成として、センサ値を監視するシステムとネットワーク接続して参照可能とするような構成としてもよい。

業務データ（１１４）は、センサデータ以外の運用データであり、例えばある期間に対象となる設備が保守をしていた、何らかの事情で出力などの調整をしていた等、運用上の情報が記述されたものである。センサデータと同じく、運用に関わる操作などを関連するシステムから収集したものである。なお、本実施例では、業務データ（１１４）もオフラインで収集したものとするが、当該システムとネットワーク接続して常に参照するような構成としてもよい。

操作ログ（１１５）は、モデル開発プログラム（１０７）が出力した操作ログであり、設計者がどのような操作を行ったかが記録されている。その内容は後述する。

モデル差分データ（１１６）は、バージョン管理プログラム（１０８）が出力したデータであり、モデル設計データの差分を時系列的に記録したものである。その内容は後述する。

モデル差分データ（１１６）は、以下で単に差分データ（１１６）と呼ぶことがある。関連ルールリスト（１１７）は、差分データ（１１６）と操作ログ（１１５）の対応付けにおいて、それぞれどのようなキーフレーズがあれば、分析モデル中のどのモジュールを操作していたかの関係をリストアップしたものである。

作業分類データ（１１８）は、後述する本実施例の手順で抽出された作業の分類結果である。その内容は後述する。

なお、本実施例では、装置構成として、分析モデル構築用サーバ（１０１）に置かれたプログラムとデータをネットワーク経由で作業端末（１０６）から操作する構成としたが、上記各種データ取得さえ可能であれば、ネットワーク経由でなく、単体の計算機上で同様のプログラム及びデータを用いる装置構成しても構わない。また、分析モデル構築用サーバ（１０１）や作業端末（１０６）は、単体のコンピュータで構成してもよいし、あるいは、入力装置、出力装置、処理装置、記憶装置等の任意の部分が、ネットワークで接続された他のコンピュータで構成されてもよい。本実施例中、プログラムで構成した機能と同等の機能は、FPGA（Field Programmable Gate Array）、ASIC（Application Specific Integrated Circuit）などのハードウエアでも実現できる。

図２に、上述した、モデル開発プログラム（１０７）の操作ログである操作ログ（１１５）の概念例を示す。各行がそれぞれ作業のログであり、時刻（２０１）、作業者ＩＤ（２０２）、どの分析モデルを操作したか示す操作対象（２０３）、どのような操作を行ったかを示す操作内容（２０４）、参照したデータ名を示す参照データ（２０５）が記録されている。

例えば、ログの２行目では、日時2017/09/28の10:36:21にＩＤU1357の作業者が、Pred_Test.xmlという分析モデルを対象に、データ期間モジュール（モジュールは分析モデルの部分ルーチンを指す）を編集し、その際、“Operation_data_1”を参照したことが記録されている。

また、ログの３行目では、日時2017/09/28の11:12:32にＩＤU4321の作業者が、Pred_Test.xmlという分析モデルを対象に、学習モジュールを編集し、その際、“因数データ”を参照したことが記録されている。

ここで、参照データの中には、前段のモジュールから順に引数として渡されるものがある。処理の主対象となるセンサデータ（１１３）などはその例である。その場合には、処理の上流に遡ってデータ入力モジュール中から名称を得るような操作ログ整形処理を行って名称を決定するか、あるいは、引数として渡されたデータであることだけ分かれば十分な場合には、“引数データ”とだけ抽出しておく。図２の３行目の例は後者である。

また、この操作ログの記録タイミングは、モデル開発プログラムの仕様に依存するが、本実施例では全ての変更操作ごとに記録が行われるものとする。この仕様は、モデルの開発プログラムの設定次第で実行可能である。

図３に、上述したバージョン管理プログラム（１０８）が出力したモデル差分データ（１１６）の概念例を示す。各行がそれぞれ、モデルに差分が生じた差分イベントを示すモデル差分データである。時刻（３０１）、作業者ＩＤ（３０２）、対象ファイル（３０３）、および、差分情報（３０４）が記録されている。

例えば、２行目では、日時2017/09/28 10:37:25に、分析モデルの前回との差分を算出した結果、作業者IDU1357により、Pred_Test.xmlという分析モデルについて、データ期間パラメータ”begin_0”と保存タイムスタンプが変更されたことが記録されている。このように、パラメータに変更がある差分イベントについては、特に「パラメータ差分イベント」と称することにする。

なお、このモデル差分データの記録タイミングは、作業者自らが手動で明示的に操作を行ったタイミングで記録することが基本である。ただし、記録の漏れを無くすために、たとえば、分析モデル上の特定の動作（例えば、分析モデルのテスト実行）を行った際に、バージョン管理プログラムを動作させるようなサブルーチンが呼ばれるように、分析モデル自身に記述しておくことで、特定動作に連動して自身の差分が記録されるようにすることが可能である。本実施例ではそのような設定により、差分情報がテスト動作の都度記録されるものとする。

図４に、関連ルールリスト（１１７）の概念例を示す。このリストは、上述したように、操作ログ（１１５）側、差分データ（１１６）側、それぞれのキーワードやキーフレーズの組み合わせに対して、モジュール（分析モデルの部分ルーチン）を操作したかについてのリストであり、処理プログラムやバージョン管理プログラムに依存してユーザ（管理者）が作成する。関連ルールリストを用いて、操作ログと差分データを所定のモジュールに対応付けることができる。

関連ルールリスト（１１７）には、操作対象のモジュール（４０１）、操作ログキーフレーズ（４０２）、差分データキーフレーズ（４０３）、参照データ記述（４０４）、パラメータ記述（４０５）、サーチ幅（４０６）の各データが記録されている。

例えば、１行目を例にとると、“データ期間”についてのモジュールを操作した履歴として、操作ログ側が“データ期間設定”、差分データ側が“Data Period”というキーフレーズが現れるとすると、そのキーフレーズを表にしておく。また、その際参照されるデータ名が“Read Data From”というキーフレーズと共に現れること、また、修正されるデータの期間についてのパラメータは、開始期間は”begin_0”、終了期間は“end_0”というキーフレーズと共に現れることを示している。また、最終列の“サーチ幅”は、パラメータ差分が発生する前後どの範囲を関連付けるかを規定するものである。１行目の例では、差分発生から10分前までの操作ログを関連付けること、また、未来方向は関連付けないことを規定している。

なお、２行目の参照データ記述（操作ログ）中の記述が”（引数データ）”となっているが、これは上述のように、引数として渡されたデータであることを示す。

関連ルールリスト（１１７）は、一般に操作者や管理者が経験則に基づいて作成し、予め記憶装置に格納しておく。あるいは、機械学習によって自動生成してもよい。なお図４のデータ構成は一例であり、項目の数は追加あるいは削減してもよい。また、各項目の内用もキーフレーズ、データ種類、数値範囲などから適宜選択してよい。サーチ幅（４０６）については、本例では行ごとに条件を設定しているが、全ての行に共通で固定値に設定してもよいし、時間的に直近のものを選択するルールとしてもよい。

次に、本実施例における全体の動作を説明する。本実施例の動作は、モデルパラメータを自動分類して記録する記録動作と、モデル再利用の際に記録された分類データを提示する手順の２つから構成される。ぞれぞれはユーザの利用タイミングに応じて独立に実行可能である。以下、それら２つの手順を順に説明する。

図５に、本実施例における、記録動作の全体手順を示す。最初にＳ５０１で操作ログ（１１５）を、また、Ｓ５０２でモデル差分データ（１１６）をそれぞれ読み込む。次に、それらのデータを用いて、差分・操作ログ対応付けを行う（Ｓ５０３）。その処理の詳細は後述する。

次に、この対応付けで抽出された各パラメータ差分イベントについて（Ｓ５０４）、パラメータ分類を行う（Ｓ５０５）。全てのパラメータ差分イベントが終了したら（Ｓ５０６）、一般に複数回のパラメータ分類が行われていることになるので、各パラメータについて、時間的に最新の分類を採用する（Ｓ５０７）。なお、本実施例では最新の分類を採用することとしたが、再利用の際の利便性に応じて、最も多く生起した分類を採用するなどとしてもよい。

図６に、上述した差分・操作ログ対応付けＳ５０３の手順を示す。まず、上述した関連ルールリスト（１１７）を読み込む（Ｓ６０１）。差分データ（１１６）中の差分イベントごとに（Ｓ６０２）、パラメータ差分があるか判断する（Ｓ６０３）。パラメータ差分があれば、図４で例示したサーチ幅の範囲で、操作ログ（１１５）側に関連ログがあるか関連ルールリスト（１１７）を用いて判定する（Ｓ６０４）。関連あれば（Ｓ６０５）、対応候補として決定する（Ｓ６０６）。サーチ幅の範囲のすべてのログについて処理し（Ｓ６０７）、これを全ての差分イベントについて行う（Ｓ６０８）。

図７に、履歴整形プログラム（１０９）が行なう、上述した操作ログ（１１５）と差分データ（１１６）の対応付けＳ５０３において、関連付けられた合成データ（７００）の概念図を示す。各セット＃（７０１）が対応付けられたセットを示す。由来（７０３）の列にしめすように、”ログ”の行が操作ログ由来、“差分”の行が差分データ由来のデータである。時刻（７０２）には、操作ログと差分データの時刻（２０１）（３０１）が格納される。この対応付けによって、操作内容（７０６）、参照データ（７０７）、差分パラメータ（７０８）が対応付く。なお、図７の例では、セット＃001と010の差分イベントは差分パラメータがないので、対応付けＳ５０３の結果の対応候補には含まれない。セット＃002〜004の差分イベントは、差分パラメータがあるのでパラメータ差分イベントである。

また、作業者ＩＤ（７０４）は、操作ログ（１１５）の作業者ＩＤ（２０２）と差分データ（１１６）の作業者ＩＤ（３０２）である。対象（７０５）は、操作ログ（１１５）の操作対象（２０３）と差分データ（１１６）の対象ファイル（３０３）である。これらは、サーチ幅（４０６）を適切に選ぶと、一致させることができる。

なお、本例では操作ログ側と差分データ側が１件ずつ対応しているように記述しているが、差分ログの間隔によっては、複数の操作をまとめて差分が取られることも起こりうる。その場合、どのパラメータ変更がどの操作によるのかわかりづらくなるため、望ましくない。そのため、差分データ作成はなるべく高頻度に実行することが望ましい。上述したテスト実行のたびに自動作成する手順はその一例である。

図８に、作業分類プログラム（１１０）が行なう、上述した差分データと操作ログ対応付け結果を用いて一つのパラメータ差分イベントについてのパラメータ分類（Ｓ５０５）の手順を示す。ここでパラメータ分類とは、そのパラメータが、どのような作業で決定もしくは変更されたかという観点での分類である。

まず、各パラメータ差分イベントについて、対応付けられた参照データの有無を判定する（Ｓ８０１）。参照データがなければ、外部の何らかの情報で得られたと判断して“その他決定”のフラグを付与する（Ｓ８０２）。参照データがあれば、それが引数データであれば（Ｓ８０３）データ学習フラグを付与する（Ｓ８０４）。フラグはパラメータ自体に付与しても良いし、パラメータに対応する操作内容あるいはモジュールに付与することで、間接的にパラメータに付与しても良い。

ここで、引数データを参照していても、対象モジュールによっては、手動でパラメータを変更している場合が考えられる。たとえば、センサデータ（１１３）を読み込んでデータを選択するモジュールに関して、グラフで描画してその結果を元にユーザが手動で選択するデータを変えた場合などである。本実施例では、これもデータから決定できた場合（外部要因をヒアリングする必要がない）として、データ学習フラグを付与することとする。別の実施形態として、人的判断が介入した場合はデータ学習と区別する方針であれば、機械学習モジュールをリストアップしておいて、それが用いられたか否か（操作ログ中に記録される）で人的判断のフラグを与える手順を追加しても良い。

次に、業務データ（１１４）を参照したかどうかをみて（Ｓ８０５）、参照していれば、業務データ参照フラグを付与する（Ｓ８０６）。また、その際の参照業務情報についての内容（データ名）を記録する（Ｓ８０７）。

ここで、業務データ（１１４）とはセンサデータ（１１３）及びそれが加工された引数データではない全てのデータとする。すなわち、データ参照している場合は、必ず引数データか業務データを参照していることになる。また、この図が示すとおり、データ学習フラグと業務データ決定フラグは排他的ではないため、パラメータ差分イベントについて、(1)その他決定、(2)データ学習あり、業務データ参照なし、(3)データ学習なし、業務データ参照あり、(4)データ学習あり、業務データ参照あり、の４通りに場合分けされることになる。

以上のように、分析モデルが持つパラメータの決定経緯を自動分類することにより、モデル再利用の際にその情報を活用可能とすることができる。従って、分析モデルが持つパラメータ中で，センサデータ参照だけで決まらず、顧客業務状況や顧客目的に応じて変更する必要のあるパラメータがある場合でも、それらを区別して管理することができる。

図９に、本実施例におけるもう一つの手順である、モデル再利用の際に記録された分類データを提示して開発支援する手順を示す。

まず、ユーザによって、再活用されるモデルが指定入力される（Ｓ９０１）。次に、そのモデルに対応する、以前の開発の際に上述した手順によって分類されたパラメータ分類データが読み込まれる（Ｓ９０２）。モデル中の各パラメータについて（Ｓ９０３）、その他決定パラメータであれば（Ｓ９０４）、対応する確認項目を提示（Ｓ９０５）する。ここで、その他決定パラメータに対応した確認項目とは、当該パラメータ項目が外部から決定される必要があると推測されること、及び、あらかじめ準備しておいた、当該パラメータの値を確認するための想定質問文などである。

一方、パラメータがデータ学習パラメータであれば（Ｓ９０６）、学習関連情報を提示（Ｓ９０７）、業務データ参照パラメータであれば（Ｓ９０８）、利用した業務情報を提示する（Ｓ９０９）。ここで、学習関連情報とは、決定されたパラメータの項目名、学習プログラム（あれば）の名前、利用データの名前（処理モデル上で追跡されていれば）等である。また、利用した業務情報とは、参照している業務データ（１１４）の名称等の情報である。

図１０に、ユーザに表示されるＧＵＩ例を示す。本図は一つの分析モデル「発電プラント○○装置の異常診断」の処理内容を示す。矢印で接続された各四角（１００１〜１００８）が処理モジュールであり、矢印の順に引数データが渡され、処理が行われる。また、図中吹き出しで表示された情報（１００９〜１０１１）がパラメータ分類と付加情報の例である。

情報（１００９）ではデータ選択モジュールに関して、パラメータ（セット）名がデータ参照期間であり、種別は業務データ参照パラメータ、参照情報は正常期間データであることが示されている。なお、本例のようにパラメータセット単位での説明ではなく、開始期間、終了期間等、個別パラメータごとに細かく表示してもよい。同様に情報（１０１０）では、異常診断学習モジュールに関して、判定クラスタパラメータ（セット）の情報が提示されている。また、情報（１０１１）では異常判定モジュールに関して、異常判定閾値の情報が提示されている。このパラメータは、上述したその他決定パラメータであるため、「値について確認が必要です」というコメントが生成される。

情報（１０１１）が表示される状況は、モデル差分データ（１１６）の所定の行の差分情報の項目（３０４）に変更されたパラメータがあり、かつ、それに対応付けされた操作ログ（１１５）の行の参照データの項目（２０５）に参照データがない場合である。この場合、パラメータ分類（Ｓ５０５）で、変更されたパラメータ「異常判定閾値」に対応付けて「その他決定」フラグが付与されている。よって、パラメータ「異常判定閾値」に対応付けられた異常判定モジュール（１００７）に対応して情報（１０１１）の表示がされる。これにより、操作者は自らがパラメータ設定作業をする必要があることを認識できる。

なお、図１０では、過去に修正のあった複数のパラメータ（セット）について一斉に提示する例を示した。その他の実施形態として、過去記録時のパラメータ修正の順序を記録しておき、かつ、現在のパラメータ修正の状況も、過去記録と同様に作業途上で抽出逐次し、それらの実現順序を比較することで、あるパラメータが決定されたら、まだ決定されていない、次のパラメータの情報を順に提示するという形態を行ってもよい。このように、順序を踏まえた提示によって、多くのパラメータをどの順序で決定するべきかのガイドを行うことが可能となる。

また、本実施例ではモジュールのフロー図上に重ねて情報提示する形態を示したが、必要な情報が提示されていれば、描画デザインはこの図面に限定されるものでなく、表形式やユーザ操作で階層的に表示される形式など、様々なＧＵＩで行ってよい。また、表示内容も、パラメータセットで一まとめでなく、一つ一つのパラメータごとに詳細に表示することも可能である。

本実施例では，実施例１の機能に加えて、ユーザの分析モデルの編集目的を含めて分類提示する実施例を示す。

図１１は本実施例における装置構成を示したものである。分析モデル構築用サーバ（１１００）は実施例１（図１）の構成に加えて、作業者データ（１１０１）を準備する。また、作業分類プログラム（１１０２）は、後述するように作業者データを参照して作業目的等を追加する処理が加えられる。また、それに伴って、分類結果提示プログラム（１１０３）も、作業目的等を追加表示する。

図１２に作業者データ（１１０１）の概念例を示す。作業者データでは、各行それぞれが作業者（操作者）についての情報であり、作業者ＩＤ（１２０１）、作業者の役割（１２０２）、分析モデルの操作目的（１２０３）、作業者のスキル（１２０４）などが記録されている。作業者データは、例えば作業者の監督権限を持つユーザ（管理者）が作成して、記録しておく。

作業者データ（１１０１）と、操作ログ（１１５）あるいは差分データ（１１６）は、作業者ＩＤで対応付けができる。従って、対象となるモジュールと作業者の対応付けも可能となる。

図１３に本実施例における操作履歴の記録手順を示す。実施例１（図５）の手順に加えて、上述した作業者データ（１１０１）の読込（１３０１）、各パラメータ差分イベントについて、当該イベントの作業者の役割、操作目的等を付加するプロセス（１３０２）、また、関連して、最終的に各パラメータについて最新の分類フラグを選択するプロセスに付随して、対応する作業者の役割、操作目的等を選択するプロセスが追加されている（１３０３）。

プロセス（１３０２）では、例えば図７に示されるパラメータ差分イベントのデータに対して、該当する作業者ＩＤを持つ作業者データ（１１０１）の役割（１２０１）、操作目的（１２０３）、スキル（１２０４）を結合する。

図１４に本実施例におけるＧＵＩの例を示す。実施例１の表示内容に加えて、修正目的、及び担当者の役割についての情報が追加表示されている（１４０１〜１４０３の下線部）。なお、このＧＵＩはあくまで一例であり、目的別にリストアップするなどの表示方法を行うことも可能である。

以上の実施例では、モデル構築アプリの操作ログと、バージョン管理プログラムで記録した分析モデルの差分情報を用いて、それらの対応付け手段を提供する。また、参照データ分類手段を用いて，各パラメータについて修正の際にデータを参照したか否か，また，参照した場合、参照データの種別を分類する。以上の結果、各パラメータに対して、データ学習，業務データ参照，その他決定の３種類のフラグを自動付与する機能を提供する。また、分類結果をモデル再活用の際に，作業段階に応じた確認事項を生成提示する機能を提供することができた。

以上説明した実施例によれば、分析モデル開発者は作業記録をとることなく，モデルパラメータの種別が区分されることで，モデル再利用の際に、各パラメータについてどのような手段で調整を行うべきかがわかる。この結果、作業量削減や、非熟練者であってもモデルの調整が容易にできるなどの効果が得られる。

本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の実施例の構成の追加・削除・置換をすることが可能である。

モデル開発プログラム１０７、バージョン管理プログラム１０８、履歴整形プログラム１０９、作業分類プログラム１１０、分類結果提示プログラム１１１、モデル設計データ１１２、センサデータ１１３、業務データ１１４、操作ログ１１５、モデル差分データ１１６、関連ルールリスト１１７、作業分類データ１１８

Claims (15)

1. 分析モデルの構築作業を支援する分析モデル用支援装置であって、入力装置、出力装置、記憶装置、および処理部を備え、
   前記記憶装置は、
   前記分析モデルの開発プログラムの操作履歴、および、前記分析モデルのバージョン管理プログラムの差分情報を記憶し、
   前記処理部は、
   履歴整形プログラム、作業分類プログラム、および分類結果提示プログラムを実行し、
   前記履歴整形プログラムは、
   前記操作履歴と前記差分情報を対応付け、
   前記作業分類プログラムは、
   前記操作履歴に現れるデータ参照関係に基づいて、前記差分情報に現れる分析モデルのパラメータを分類して分類結果を得、
   前記分類結果提示プログラムは、
   前記出力装置に前記分類結果に基づいた情報を出力する、
   ことを特徴とする分析モデル構築支援装置。
2. 請求項１に記載の分析モデル構築支援装置において、
   前記記憶装置は、
   前記操作履歴の中の要素と前記差分情報の中の要素の組み合わせパターンを予め設定した、関連ルールを記憶し、
   前記履歴整形プログラムは、
   前記操作履歴と前記差分情報を、前記パターンによって対応付けることを特徴とする分析モデル構築支援装置。
3. 請求項２に記載の分析モデル構築支援装置において、
   前記操作履歴は、
   第１の時間情報を含み、
   前記差分情報は、
   第２の時間情報を含み、
   前記関連ルールは、
   前記要素としてキーフレーズを用いるとともに、前記第１の時間情報と前記第２の時間情報の満たすべき制約条件であるサーチ幅の情報を含み、
   前記履歴整形プログラムは、
   前記関連ルールを参照して、前記サーチ幅と前記キーフレーズを元に対応付けを行うことを特徴とする分析モデル構築支援装置。
4. 請求項２に記載の分析モデル構築支援装置において、
   前記関連ルールは、
   前記操作履歴と前記差分情報を、さらに分析モデルのモジュールと対応付け、
   前記作業分類プログラムは、
   前記差分情報においてパラメータ変更があったモジュールが、前記操作履歴において変更の際にデータを参照しているか否かで分類することを特徴とする分析モデル構築支援装置。
5. 請求項４に記載の分析モデル構築支援装置において、
   前記作業分類プログラムは、
   前記差分情報においてパラメータ変更があったモジュールが、前記操作履歴において変更の際にデータを参照していた場合、そのデータが分析モデルの処理対象として入力したデータか、それ以外の外部データかで分類することを特徴とする分析モデル構築支援装置。
6. 請求項５に記載の分析モデル構築支援装置において、
   前記分類結果提示プログラムは、
   前記パラメータの分類結果に関する情報を、当該パラメータが現れる差分情報に対応する当該モジュールごとに提示することを特徴とする分析モデル構築支援装置。
7. 請求項６に記載の分析モデル構築支援装置において、
   前記分類結果提示プログラムは、
   モジュールごとの提示を行う際に、該当モジュールがデータを参照していないパラメータに対しては、外部情報で決定する必要があることを明示して提示することを特徴とする分析モデル構築支援装置。
8. 請求項６に記載の分析モデル構築支援装置において、
   前記分類結果提示プログラムは、
   モジュールごとの提示を行う際に、該当モジュールが参照したデータが前記外部データである場合は、用いたデータの名称を提示することを特徴とする分析モデル構築支援装置。
9. 請求項６に記載の分析モデル構築支援装置において、
   前記分類結果提示プログラムは、
   モジュールごとの提示を行う際に、前記開発プログラムの現在の作業内容と比較して現在の作業内容の次に行われる修正を、順に提示することを特徴とする分析モデル構築支援装置。
10. 請求項６に記載の分析モデル構築支援装置において、
    前記操作履歴および前記差分情報の少なくとも一つは、関連する作業者ＩＤを含み、
    前記記憶装置は、
    作業者ＩＤに対応させた作業者データを持ち、
    前記処理部は、
    作業分類プログラムを実行し、
    前記作業分類プログラムは、
    前記モジュールと前記作業者データを対応付けて、作業者データから前記差分情報に現れるパラメータの変更ごとに目的を推定し、
    前記分類結果提示プログラムは、
    モジュールごとの提示を行う際に、前記モジュールに対応付けた前記目的を提示することを特徴とする分析モデル構築支援装置。
11. 入力装置、出力装置、記憶装置、および処理部を備える情報処理装置を用い、分析モデルのモデル開発プログラムの操作ログ、および、前記分析モデルのバージョン間のモデル差分データに基づいて、前記分析モデルのパラメータを分類する分析モデル構築支援方法であって、
    前記操作ログは複数の行を含み、
    前記操作ログの複数の行のそれぞれは項目として、前記分析モデルに対する操作内容の項目、および操作で参照したデータである参照データの項目を含み、
    前記モデル差分データは複数の行を含み、
    前記モデル差分データの複数の行のそれぞれは項目として、前記分析モデルの差分情報の項目を含み、
    前記操作ログの行と前記モデル差分データの行を、前記操作ログの項目の内容と前記モデル差分データの項目の内容の組み合わせパターンを予め設定した関連ルールに基づいて対応付けする、対応付けステップと、
    前記モデル差分データの所定の行の差分情報の項目の内容であるパラメータを、対応する前記操作ログの行の参照データの項目の内容に基づいて分類する、分類ステップと、
    を実行することを特徴とする分析モデル構築支援方法。
12. 請求項１１記載の分析モデル構築支援方法において、
    前記操作ログの複数の行のそれぞれは、さらに第１の時間情報を含み、
    前記モデル差分データの複数の行のそれぞれは、さらに第２の時間情報を含み、
    前記関連ルールは、さらに、前記第１の時間情報と前記第２の時間情報の関連性を規定し、
    前記対応付けステップは、さらに、前記関連性を満たすことを条件に、操作ログの行とモデル差分データの行を対応付けする、
    分析モデル構築支援方法。
13. 請求項１１記載の分析モデル構築支援方法において、
    前記分類ステップは、
    前記参照データの項目の内容が、分析モデルが分析する対象の入力データあるいはそれが加工された引数データか、それ以外の業務データかに基づいて、前記パラメータの分類を行なう、
    分析モデル構築支援方法。
14. 請求項１１記載の分析モデル構築支援方法において、
    分類結果提示ステップをさらに備え、
    前記分類ステップは、
    モデル差分データの所定の行の差分情報の項目に変更されたパラメータがあり、かつ、それに対応付けされた操作ログの行の参照データの項目に参照データがない場合、当該変更されたパラメータに対応付けてフラグを付与し、
    前記分類結果提示ステップは、
    前記出力装置に、前記パラメータに対応付けて所定の出力を行なう、
    分析モデル構築支援方法。
15. 請求項１１記載の分析モデル構築支援方法において、
    分類結果提示ステップをさらに備え、
    前記対応付けステップは、
    前記操作ログの行と前記モデル差分データの行を、前記操作ログの項目の内容と前記モデル差分データの項目の内容の組み合わせパターンを予め設定した関連ルールに基づいて、分析モデルの所定のモジュールと対応付けし、
    前記分類結果提示ステップにおいて、
    前記出力装置に、前記所定のモジュールごとに、前記分類ステップによるパラメータの分類結果に基づいた情報を提示する、
    分析モデル構築支援方法。

Images