JP6591937B2 - 運用保守知識情報の策定支援システムおよび策定支援方法 - Google Patents

Description

本発明は、運用保守知識情報の策定支援システムおよび策定支援方法に関する。

従来、例えば、発電プラントや製鉄プラント、化学プラントなどの各種プラントでは、特定の管理会社（事業者）が運用保守を長年にわたって担当し、納入した機器等の品質向上や改良、運用保守技術の改善に努めている。プラントを長年にわたって運用してきた管理会社は、経験に基づく固有の知識や運用手法を蓄積している。

ところで近年では、複数のベンダから購入する製品を適宜組み合わせることで、プラントの建設コストや運用コストの低減を狙う傾向がある。ベンダも製品も限定せずに、その時々で、顧客の希望に添ったベンダや製品が選択される。かつては、高い信頼性と豊富な実績を持つベンダの提供する製品（特に例えば、特定プラント向けの特注品、専用品）がプラントには多く使用されてきた。しかし近年では、多様なベンダから購入する安価な汎用品を組み合わせて安価なプラントを構築することが、顧客から望まれている。

新規なプラントが既存プラントと同様の製品から構成されており、既存プラントの運用保守の管理会社と同一の管理会社により運用される場合は、既存プラントで培われた運用保守技術のノウハウを新規プラントにほぼそのまま適用できる。

しかし、使用実績に乏しい他社製品や汎用品を組み合わせて安価な新規プラントを作る場合や、新規参入の管理会社が新規プラントを運用する場合は、既存プラントの持つ運用保守技術のノウハウを新規プラントへ適用するのは難しい。

運用保守技術のノウハウの多くは形式知になっておらず、半ば暗黙知となっているためである。既存プラントでの運用保守技術のノウハウを新規プラントへ活かすことができない場合、新規プラントを安定して運用したり保守したりすることが難しくなる。しかし、既存プラントに蓄積された運用保守技術のノウハウを抽出して形式知化するのは難しく、コストの予想すら困難である。

ここで、従来技術としての特許文献１は、プラント設備の運転時間などの稼働状況と、プラント設備に設けられた複数センサの出力信号とを用いて異常を検知する。特許文献１では、作業履歴や交換部品情報などの過去の対策事例から、検知した異常と対策とを紐付けし、診断精度の向上を図る。

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

特許文献１の従来技術によれば、作業員の経験や勘に基づく保守業務を自動化することができ、暗黙知化されている運用保守技術のノウハウを形式知化できる。しかし、特許文献１は、監視対象と操作対象が明確であることを前提としており、監視対象が所定の条件を満たした場合に操作対象へ所定の指令を与えるという技術である。したがって、監視対象や操作対象が異なるプラントには適用することができない。そもそも何を監視すべきなのか、そして？、何をどのように操作すべきかが不明だからである。

この問題の解決は、パートナー企業が複数となり、数多くのメーカが提供するハードウェアやソフトウェアを組合せてシステムを構築する場合、ますます困難となる。

本発明は、上述の課題に鑑みてなされたもので、その目的は、既存システムから運用保守に関する知識情報を効率的に抽出できるようにした運用保守知識情報の策定支援システムを提供することにある。

上記課題を解決すべく、本発明に従う運用保守知識情報の策定支援システムは、既存システムから抽出する情報を用いて、運用保守に関する知識情報の策定を支援する運用保守知識情報の策定支援システムであって、既存システムに関する所定の情報を取得する情報取得部と、取得された所定の情報を解析することで、運用保守の論理判断に関するキー要素となるキー要素情報を抽出するキー要素抽出部と、抽出されたキー要素情報をシミュレーション解析することで、運用保守に関する知識情報である運用保守知識情報を抽出し、保存する運用保守知識情報抽出部と、を備える。

本発明によれば、既存システムから運用保守の論理判断に関するキー要素情報を抽出してシミュレーション解析することで、運用保守知識情報を抽出することができる。

本実施形態の全体概要を示す説明図である。 プラント運用ナレッジ策定支援装置の構成図である。 クライアント端末および運用保守端末の構成図である。 システムログデータ（入力データ）の例である。 システムログデータ（出力データ）の例である。 作業ログデータの例である。 外部データの例である。 キー要素データの例である。 ナレッジデータの例である。 ナレッジ策定支援処理のフローチャートである。 第２実施例に係り、ログデータの例である。 キー要素データの例である。 第３実施例に係り、ナレッジ成立条件を探索する処理を示すフローチャートである。 第４実施例に係り、画面操作ログを収集する処理のフローチャート。 第５実施例に係り、既存プラントから抽出したナレッジを新規プラントへ適用する場合の説明図。 第６実施例に係り、既存プラントから抽出したナレッジを顧客ポリシ毎に分類する様子を示す説明図。

本実施形態に係る運用保守知識情報の策定支援システムは、プラント等のシステムの運用保守に関わる、監視記録および制御記録を解析する機能と、制御をするための論理判断や行動ごとに解析結果を分類する機能と、分類結果から監視や制御に係わる頻度を変更する機能と、解析結果と同様の条件と変更した頻度とに基づいてプラント運用保守のシミュレーションする機能とを有し、シミュレーション結果から論理判断や行動に必要な監視や制御に係わる頻度の条件を決定する。

本実施形態では、プラントの運用保守に係わる、監視データ（センサデータ）、論理判断および指令データの３種類の動作記録から、監視データおよび指令データをビッグデータ解析技術を用いて分析する。これにより、本実施形態では、論理判断に紐づく機械的な特徴量、具体的には特定の監視データおよび指令データ、を抽出できる。本実施形態では、これらの監視データと指令データおよび論理判断（異常予兆の検知等）を運用保守のナレッジとして保存する。既存のプラントから抽出したナレッジを新規プラントへ適用することで、新規プラントの運用保守の利便性や信頼性を低コストに高めることができる。

キー要素データからナレッジを抽出する技術として、例えば適応共鳴理論（Adaptive Resonance Theory：ART）を用いることができる。

本実施形態では、論理判断ごとに抽出した特徴量の頻度を変化させることで、論理判断の可否をシミュレータで確認し、特徴量の仕様を決定する。例えば、シミュレーション解析により、或るセンサの信号が所定範囲内の値を指し示す回数が所定回数になったときに異常予兆を検知できるといったことが判明する。本実施形態では、センサ信号の値および回数のような、論理判断が発動するための特徴量の仕様を決定することができる。

本実施形態によれば、既存プラントに暗黙知として埋もれている運用保守ナレッジ（ノウハウ）を自動的に抽出して形式知とすることができる。そして、本実施形態によれば、形式知とした運用保守ナレッジをパッケージ化して新規プラントの運用保守へ適用することもできる。

図１は、本実施形態の概要を示す。図１は、本発明の理解および実施に必要な程度で実施形態の概要を示しており、本発明の範囲は図１に示す構成に限定されない。

運用保守知識情報の策定支援システム１は、コンピュータ装置から構成されており、クライアント端末２および運用保守システム３に接続されている。策定支援システム１は、マイクロプロセッサが所定のコンピュータプログラムを実行することで、策定支援システムとして求められる各機能を実現する。図１には、策定支援システム１が実現する機能Ｆ１０〜Ｆ１６のうち主な機能Ｆ１０，Ｆ１２，Ｆ１４等を示す。

クライアント端末２は、システム管理者等のユーザが使用するコンピュータ端末であり、策定支援システム１にログデータ等の各種データ情報を入力したり、策定支援システム１からの情報を表示したりする。

運用保守システム３は、ナレッジ抽出対象の既存システム４の運用保守を行うための装置であり、コンピュータ端末である。運用保守システム３は、後述の実施例では、運用保守端末３と呼ばれる。運用保守システム３が既存システム４から取得した監視データ（入力データ、センサデータ、取得データとも呼ぶ）や、運用保守システム３から既存システム４へ与えた指令データ（出力データ、制御データとも呼ぶ）は、運用保守システム３からクライアント端末２へ送られる。場合によっては、運用保守システム３から策定支援システム１へ直接データを送信してもよい。

既存システム４は、例えば、発電プラント、製鉄プラント、化学プラント、上下水道プラント等の各種プラントとして構成される。既存システム４は、少なくとも一つの、センサ４１および機器４２を有する。

センサ４１には、例えば、温度センサ、圧力センサ、流量センサ、液面センサ、振動検知センサ、回転センサ、音響センサ、炎検知センサ、画像センサ、色彩センサ、磁気センサ、電流計、電圧計、手動式スイッチ、光電スイッチ、機械式リミットスイッチ、キーボードスイッチ、タッチパネル等がある。機器４２には、例えば、モータ、タービン、シリンダ、ソレノイド、バルブ、ポンプ、ヒータ、ボイラ、ファン等がある。

運用保守システム３は、予め設定されている論理判断（異常診断とその対応など）に基づいて、既存システム４の運用保守を行う。さらに、作業員等のユーザは、所定のセンサ４１の信号の挙動から異常の予兆を検知すると、運用保守システム３から所定の機器４２へ指示を与える。これにより、検知した異常予兆に速やかに対応し、異常発生を未然に防止する。ユーザによる既存システム４への操作は、作業記録として運用保守システム３に保存され、クライアント端末２へも送られる。センサ４１から運用保守システム３へ入力されるデータと、運用保守システム３から機器４２に与えるデータも、クライアント端末２へ送られる。

運用保守ナレッジ策定支援システム１は、「運用保守知識情報」としての運用保守ナレッジ（以下、ナレッジまたはナレッジデータとも呼ぶ）を、既存システム４の運用保守に関するデータを解析することで抽出する。抽出した運用保守ナレッジは、新規システム６の運用保守を担当する運用保守システム５へ実装することができる。

策定支援システム１は、例えば、データ取得部Ｆ１０、キー要素抽出部Ｆ１２、ナレッジ抽出部Ｆ１４といった処理機能と、記録データＴ１０−Ｔ１３、キー要素データＴ１３、ナレッジデータＴ１４とを保持する。策定支援システム１の詳細な構成は、図２等で後述する。

データ取得部Ｆ１０は、「情報取得部」に該当する。データ取得部Ｆ１０は、クライアント端末２および／または運用保守システム３から、「所定の情報」としてのログデータＴ１０−Ｔ１２を取得し、保存する。データ取得部Ｆ１０は、種々のデータフォーマットを持つデータを予め設定された統一データフォーマットに変換し、保存する。データ取得部Ｆ１０は、定期的にまたは不定期に、ログデータを取得できる。例えば、データ取得部Ｆ１０は、事前に決められた時刻、システム管理者等から指示されたとき、運用保守システム３で何らかの保守作業を行ったとき、既存システム４の構成が変化したとき、のいずれか一つまたは複数のタイミングで、ログデータを取得して保存することができる。

キー要素抽出部Ｆ１２は、ログデータを解析することで、運用保守の論理判断に関するキー要素となるデータ（キー要素データ）Ｔ１３を抽出し、保存する。ここで運用保守の論理判断とは、例えば、異常の予兆検知、故障予知などのように、運用保守上のロジックである。論理判断には、予兆検知のような純粋な判断だけでなく、例えば「設定値変更」「システム停止」「経路切り替え」などの行動も含めることができる。
「キー要素情報」としてのキー要素データＴ１３は、ログデータＴ１０−Ｔ１２をビッグデータ解析することで抽出されるデータであって、運用保守の論理判断に関係が深いと思われるデータである。

ナレッジ抽出部Ｆ１４は、キー要素データＴ１３をシミュレーション解析することで、「運用保守知識情報」としてのナレッジデータを得る。ナレッジ抽出部Ｆ１４は、キー要素データＴ１３と論理判断とに関係があるか判断し、関係のあるキー要素データと論理判断とを対応付けてナレッジデータＴ１４を生成し、保存する。

さらに、ナレッジ抽出部Ｆ１４は、発生条件変更部Ｆ１４１により、キー要素データのうち入力データの発生条件を変更する。これにより、ナレッジ抽出部Ｆ１４は、どのような発生条件であれば、そのキー要素データに対応する論理判断が実行されるかを確認し、その発生条件をナレッジデータに加える。

このようにして生成されるナレッジデータＴ１４は、既存システム４の長年にわたる運用保守作業で培われた暗黙知を自動的に検出して形式知化したものである。作業者の経験や勘として隠されてきた運用保守ノウハウの少なくとも一部は、策定支援システム１により可視化され、新規システム６の運用保守に活かされる。

図２〜図１０を用いて第１実施例を説明する。図２は、本実施例に係る策定支援システム１を含む全体システムの構成例である。

全体システムは、例えば、プラント運用保守ナレッジ策定支援システム（以下、ナレッジ策定支援システム）１と、複数のクライアント端末２と、複数御運用保守端末３とを備えており、これらコンピュータシステム１〜３は通信ネットワークＣＮ１を介して接続されている。

プラント運用保守を行う運用保守端末３は、通信ネットワークＣＮ２を介して、複数のセンサ４１および機器４２に接続されている。これらセンサ４１および機器４２は、図１中の既存システム（既存プラント）４に含まれる。詳しくは、運用保守端末３は、図外のプラント保守運用システムに接続されており、プラント保守運用システムに対して指示や設定値を入力するコンピュータ端末である。以下、説明の便宜上、プラント保守運用システムと運用保守端末３とを特に区別せずに使用する場合がある。

ナレッジ策定支援システム１は、例えば、ＣＰＵ１１、メモリ１２、通信部１３、および記憶装置１４を備える。ナレッジ策定支援システム１が有する各種プログラムは、記憶装置１４に記憶されている。ＣＰＵ１１は、それらコンピュータプログラムを必要に応じてメモリ１２を介して読み込み、実行する。これにより、各機能Ｆ１０〜Ｆ１６が実現される。

通信部１３は、通信ネットワークＣＮ１に接続して通信するための機能である。ナレッジ策定支援システム１は、通信部１３および通信ネットワークＣＮ１を介して、クライアント端末２および運用保守端末３と通信する。

記憶装置１４は、例えば、ハードディスクやフラッシュメモリ等から構成されており、各機能Ｆ１０〜Ｆ１６を実現するためのコンピュータプログラムと、データＴ１０〜Ｔ１４とを記憶している。

記憶装置１４に格納されるコンピュータプログラムとしては、例えば、データ取得部Ｆ１０、ビッグデータ解析部Ｆ１１、キー要素抽出部Ｆ１２、シミュレーション解析部Ｆ１３、ナレッジ抽出部Ｆ１４、画面制御部Ｆ１５、および通信制御部Ｆ１６がある。

データ取得部Ｆ１０は、クライアント端末２が有するログＴ２０から、様々なデータフォーマットのログを取得し、取得したデータのフォーマットをナレッジ策定支援システム１が処理可能な統一的なフォーマットに変換する機能である。通常、各クライアント端末２は、それぞれ独自の機器やシステムを有しており、データフォーマットが同一であることは少ない。データフォーマットの異なる複数のデータを取り扱うために、データ取得部Ｆ１０が必要となる。なお、データフォーマットを標準化する機能は、市販ソフトウェアで実現可能なため、本実施例ではこれ以上言及しない。

ビッグデータ解析部Ｆ１１は、例えばシステムログデータＴ１０、作業ログデータＴ１１、外部データＴ１２の３種類のログから、関連しそうな項目をピックアップする機能である。本機能はいわゆるデータマイニング手法を用いて実現可能であり、市販ソフトウェアでも実現可能なため、具体的な説明は省略する。

キー要素抽出部Ｆ１２は、ビッグデータ解析部Ｆ１１によりピックアップされた関連項目の候補の中からキーとなる要素を選択し、キー要素データＴ１３に保存する。ピックアップ結果については、図８にて後述する。ビッグデータ解析部Ｆ１１は、通常、関連項目を関係性の大小に従って複数提示する。例えば、上位３位までの関連項目をキー要素として機械的に選択してもよいし、あるいは、ピックアップ結果を画面表示し、表示させた結果からユーザが手動でキー要素を選択してもよい。

シミュレーション解析部Ｆ１３は、キー要素データＴ１３に格納された各種入力データの中から、プラント運用保守システムがどのように動作するかを確認する機能である。シミュレーション解析機能Ｆ１３には、例えば、プラント運用保守システムに実装されている訓練シミュレータを用いることができる。オペレータが実機器で訓練するために開発された訓練シミュレータでは、実際のプラントで使用するデータと前提条件とを入力源として、実際の運用保守の動作と同様の結果を出力させることができる。

ナレッジ抽出部Ｆ１４は、シミュレーション解析部Ｆ１３での結果から、キー要素の入力データおよび出力データの組合せが、例えば異常検知や異常予兆の検知などの、高度な自動的論理判断機能を動作させることができるか確認する。高度かつ自動的な論理判断機能が動作する場合、ナレッジ抽出部Ｆ１４は、キー要素データＴ１３の入力データおよび出力データを、ナレッジデータＴ１４として保存する。

画面制御部Ｆ１５は、ナレッジ策定支援システム１がユーザへ提供する画面を作成し、クライアント端末２に表示させる。画面制御部Ｆ１５は、例えば、システムログデータＴ１０、作業ログデータＴ１１、外部データＴ１２、キー要素データＴ１３、の内容の一部または全部を画面に表示させることができる。さらに、画面制御部Ｆ１５は、ビッグデータ解析部Ｆ１１の解析結果や、シミュレーション解析部Ｆ１３の解析結果を画面に表示させることができる。画面制御部Ｆ１５は、クライアント端末２のクライアント実行部Ｆ２０と連携することで、作成した画面をクライアント端末２上で表示する。画面制御部Ｆ１５は、その表示画面に対する操作を検出して保存することもできる。

通信制御部Ｆ１６は、通信部１３を制御して、クライアント端末２および運用保守端末３と通信する機能である。ナレッジ策定支援システム１と各端末２，３とのデータ送受信には、ログデータの送受信だけでなく、例えばリモートデスクトップ等の画面表示に使用するデータの送受信も含まれる。さらに、通信制御部Ｆ１６は、例えばクライアント端末２の数が増えた場合等に、特定のクライアント端末２とのデータ送受信を優先的に処理することもできる。

図３を用いて、クライアント端末２および運用保守端末３の構成例を説明する。先にクライアント端末２の構成を説明する。クライアント端末２は、例えば、ＣＰＵ２１、メモリ２２、通信部２３、記憶部２４、およびユーザインターフェース部（図中、ＵＩ部）２５を備える。

ＣＰＵ２１は、記憶部２４に記憶されたコンピュータプログラムをメモリ２２を介して読み込んで実行することで、クライアント端末２に求められる各機能Ｆ２０〜Ｆ２２を実現する。クライアント端末２は、通信部２３を介して通信ネットワークＣＮ１に接続し、ナレッジ策定支援装置１と通信する。

記憶部２４には、クライアント実行部Ｆ２０、画面制御部Ｆ２１、通信制御部Ｆ２２を実現するためのコンピュータプログラムと、ログデータＴ２０とナレッジデータＴ２１とが記憶されている。

クライアント実行部Ｆ２０は、サーバとしてのナレッジ策定支援システム１にクライアントとして接続し、情報を交換するための機能である。クライアント実行部Ｆ２０は、専用プログラムでもよいし、ウェブブラウザでもよい。

画面制御部Ｆ２１は、ナレッジ策定支援装置１の各機能の実行結果や、クライアント端末２の保有するログデータＴ２０およびナレッジデータＴ２１をユーザインターフェース部２５に表示する機能である。

ユーザインターフェース部２５は、情報入力部と情報出力部を備える。情報入力部は、ユーザがクライアント端末２へ指示等を入力するための機能であり、例えばキーボード、ポインティングデバイス、タッチパネル、音声指示装置等のうち少なくともいずれか一つを備える。情報出力部は、クライアント端末２からユーザへ情報を出力するための機能であり、例えばディスプレイ、音声合成装置、プリンタ等のうち少なくともいずれか一つを備える。

運用保守端末３は、ＣＰＵ３１、メモリ３２、通信部３３、記憶部３４、およびユーザインターフェース部３５を備える。

ＣＰＵ３１は、記憶部３４に記憶されたコンピュータプログラムをメモリ３２を介して読み込んで実行することで、運用保守端末３に求められる各機能Ｆ３０〜Ｆ３２を実現する。運用保守端末３は、通信部３３を介して通信ネットワークＣＮ１に接続し、ナレッジ策定支援装置１と通信する。

記憶部３４には、運用保守部Ｆ３０、画面制御部Ｆ３１、通信制御部Ｆ３２を実現するためのコンピュータプログラムと、ログデータＴ３０とナレッジデータＴ３１とが記憶されている。

運用保守端末３は、通信部３３を介して通信ネットワークＣＮ１に接続し、ナレッジ策定支援装置１と通信する。さらに、運用保守端末３は、通信ネットワークＣＮ２を介して、複数のセンサ４１と複数の機器４２と通信することもできる。運用保守端末３は、通信部３３を介して通信ネットワークＣＮ２に接続してもよいし、図示せぬ別の通信部を介して通信ネットワークＣＮ２に接続してもよい。

運用保守部Ｆ３０は、ナレッジデータＴ３１に基づいて、プラント４の運用保守を行うための機能である。運用保守部Ｆ３０は、センサ４１から取得する監視データとナレッジデータＴ３１に格納されているデータとに基づいて、異常検知や異常予知の検知等の高度かつ自動的な論理判断を実行する。運用保守部Ｆ３０は、高度な論理判断の結果に応じて、ナレッジデータＴ３１内の指令データを選択し、その指令データにより機器４２に指示する。このように、運用保守端末３は、運用保守の実績から得られるナレッジデータＴ３１とプラントの状態とに基づいて、リアルタイムでプラント４を運用保守する。

画面制御部Ｆ３１は、運用保守部Ｆ３０の実行結果や、運用保守端末３が有するプラント運用保守に関わるログデータＴ３０や、取得したナレッジデータＴ３１をユーザインターフェース部３５に表示する機能である。

図４は、プラント４から収集されるログデータのうち、入力データに関するシステムログデータＴ１０Ａの例を示す。入力データのシステムログデータは、図２に示すシステムログデータＴ１０に含まれる。

入力データは、プラント４の状態を取得するデータであり、例えばセンサデータ、監視データ、取得データと呼ぶこともできる。センサ４１の検出したデータは、プラント４側からナレッジ策定支援システム１へ入力されるため、入力データ（監視データ、センサデータ）と本実施例では呼ぶ。

データ取得部Ｆ１０は、様々なデータフォーマットの入力データを、統一フォーマットのデータに変換することで、入力データのシステムログデータＴ１０Ａを生成する。

システムログデータ（入力データ）Ｔ１０Ａは、例えば、日時を表す日時Ｃ１００Ａと、センサ４１の取得した取得値Ｃ１０１Ａと、センサ４１が設置されている機器を表す機器名Ｃ１０２Ａと、センサ名称を表すセンサ名Ｃ１０３Ａとを含む。

取得値Ｃ１０１Ａは、測定値Ｃ１０１Ａ１と、補正値Ｃ１０１Ａ２を有する。補正値Ｃ１０１Ａ２は、測定値Ｃ１０１Ａ１を統一フォーマットへ変換した場合の値である。測定値Ｃ１０１Ａ１がセンサ４１の出力するそのままの値だとすれば、補正値Ｃ１０１Ａ２はナレッジ策定支援システム１があらゆるデータを統一的に算出するために、単位や精度を統一した値であると言える。

図５は、システムログデータＴ１０のうち、出力データに関するシステムログデータＴ１０Ｂの例を示す。出力データは、プラント４に含まれる機器４２に向けて出力されるデータであり、指令データあるいは制御データと呼ぶこともできる。出力データのシステムログデータＴ１０Ｂは、アクチュエータ指令データと呼ぶこともできる。アクチュエータとは機器４２であり、プラント４に含まれる能動的な機械的要素である。

システムログデータ（出力データ）Ｔ１０Ｂは、例えば、日時を表す日時Ｃ１００Ｂと、アクチュエータに指定した指定値Ｃ１０１Ｂと、アクチュエータが設置されている機器を表す機器名Ｃ１０２Ｂと、アクチュエータ名称を表すアクチュエータ名Ｃ１０３Ｂとを含む。

指令値Ｃ１０１Ｂは、指定値Ｃ１０１Ｂ１と補正値Ｃ１０１Ｂ２を有する。補正値Ｃ１０１Ｂ２は、指定値Ｃ１０１Ｂ１をフォーマット変換した場合の値である。指定値Ｃ１０１Ｂ１がそのままの値だとすれば、補正値Ｃ１０１Ｂ２はナレッジ策定支援システム１があらゆるデータを統一的に算出するために、単位や様式を統一した値である。統一されたフォーマットの下では、例えば「スイッチを入れる」は「１」と、「スイッチを切る」は「０」と、示される。実際の指令値は、機器４２の仕様により異なる。機器４２の仕様に従う実際の指令値は、指定値Ｃ１０１Ｂ１に格納される。

図６は、作業ログデータＴ１１の例を示す。作業ログデータＴ１１は、プラント４の運用保守に関する作業記録のデータである。データ取得部Ｆ１０は、様々なデータフォーマットを統一フォーマットに変換することで、作業ログデータＴ１１を作成する。

作業ログデータＴ１１は、例えば、日時を表す日時Ｃ１１０と、どのような処理作業を行ったかを示す識別子である作業ＩＤ Ｃ１１１と、その作業内容を示す作業名称Ｃ１１２と、どの機器４２に対して処理を行ったかを示す機器名Ｃ１１３とを含む。

図７は、外部データＴ１２の例を示す。外部データＴ１２は、ナレッジ策定支援システム１の外部にある気象予報システム等の外部システムから取得するデータである。データ取得部Ｆ１０は、様々なデータフォーマットを統一フォーマットに変換することで、外部データＴ１２を作成する。

外部データＴ１２は、例えば、日時を表す日時Ｃ１２０と、外部データ種別を示す識別子である外部データＩＤ Ｃ１２１と、その内容を示すデータ名称Ｃ１２２と、その値である値Ｃ１２３とを含む。

外部データとしては、例えば、気象データ、プラントの稼働日や保守点検日等を示す操業履歴データ、生産予測システムの出力する予測値等がある。

図８は、キー要素データＴ１３の例を示す。キー要素データＴ１３は、キー要素抽出部Ｆ１２が作成する。

キー要素データＴ１３は、例えば、キー要素の識別子を表すアクションＩＤ Ｃ１３０と、運用や保守に関わる論理判断の元となる取得データＣ１３１と、論理判断の結果、機器４２へ指令した内容を示す指令データＣ１３２とを含む。

取得データＣ１３１は、どの機器４２からデータを取得したのかを示す機器名Ｃ１３１１と、どのセンサ４１からデータを取得したかを示すセンサ名Ｃ１３１２を含む。図８では、１つのアクションＩＤ Ｃ１３０に対して、１種類の取得データＣ１３１のみを対応付けているが、１つのアクションＩＤ Ｃ１３０に対して複数の取得データＣ１３１を対応付けて保存することもできる。

指令データＣ１３２は、どの機器４２へ指令したかを示す機器名Ｃ１３２１と、機器４２のどの要素へ制御指令を出したを示す制御対象Ｃ１３２２を含む。制御対象Ｃ１３２２は、制御対象の要素名、あるいはアクチュエータ名と呼ぶこともできる。図８では、１つのアクションＩＤ Ｃ１３０に対して１種類の指令データＣ１３２のみを対応付けているが、１つのアクションＩＤ Ｃ１３０に対して複数の指令データＣ１３２を対応付けてもよい。

図８において、アクションＩＤ Ｃ１３０が”００１”であるレコードは、ビッグデータ解析部Ｆ１１がマイニング処理によって関連があると判断した例である。この場合、機器名Ｃ１３１１およびセンサ名Ｃ１３１２には、いずれも「なし」が格納される。

図８において、アクションＩＤ Ｃ１３０が”００９”であるレコードは、ビッグデータ解析部Ｆ１１がマイニング処理によって関連があると判断した他の例である。この例では、取得データＣ１３１のセンサ名Ｃ１３１２が「振動検知センサ」であるものに対し、指令データＣ１３２は「外部連携」となっている。つまり、この例では、機器４２対して直接指示するのではなく、外部システムに対して指令する。例えば、タービンの振動に異常の予兆が認められる場合、タービンの回転数を低下させるのではなく、外部のメンテナンス管理システム（不図示）に対して、例えば、機器４２の交換を要求したり、メンテナンススケジュールの調整を要求したりする。

なお、実際の運用においては、指令前と指令後に、機器４２の動作を確認するため、取得データＣ１３１が「なし」の場合はほとんどあり得ないが、ここでは、説明を単純化するため省略している。

図９は、ナレッジデータＴ１４の例を示す。ナレッジデータＴ１４は、ナレッジ抽出部Ｆ１４により生成される。

ナレッジデータＴ１４は、例えば、ナレッジＩＤ Ｃ１４０と、論理判断Ｃ１４１と、関連キー要素ＩＤ Ｃ１４２と、取得データＣ１４３と、指令データＣ１４４とを含んでいる。

ナレッジＩＤ Ｃ１４０は、プラント４の運用保守に関するナレッジを特定する識別子である。論理判断Ｃ１４１は、ナレッジの内容となる判断である。論理判断としては、例えば、異常の検知、異常予兆の検知等がある。関連キー要素ＩＤ Ｃ１４２は、ナレッジＩＤ Ｃ１４０で特定されるナレッジに関連するキー要素を特定する識別子である。

取得データＣ１４３は、ナレッジの前提となる入力データ（センサデータ）の種類を特定する。取得データＣ１４３は、センサの設置された機器を特定する機器名Ｃ１４３１と、センサを特定するセンサ名Ｃ１４３２を含む。

指令データＣ１４４は、ナレッジの適用結果としての指令データ（出力データ、制御データ）の宛先等を特定する。指令データＣ１４４は、指令を与える機器を特定する機器名Ｃ１４４１と、指令を与えて制御する対象を特定する制御対象Ｃ１４４２を含む。制御対象Ｃ１４４２は、機器が含む一つまたは複数の制御対象要素のうち、ナレッジの結果として制御対象となる要素名である。

図１０は、運用保守のナレッジの策定を支援する処理を示すフローチャートである。本処理は、ナレッジ策定支援システム１が実行する。ユーザは、適当なタイミングで、ナレッジ策定支援システム１に本処理を実行させることができる。

ナレッジ策定支援システム１は、大別して以下の２種類の処理を順に行う。１番目の処理は、キー要素となるデータを抽出する処理である（Ｓ１０〜Ｓ１５）。２番目の処理は、ナレッジデータを抽出して確定させる処理である（Ｓ１６〜Ｓ２０）。

キー要素抽出処理（Ｓ１０〜Ｓ１５）は、キー要素データを抽出するための各種データを取得して解析し、その解析結果を保存する。ナレッジ確定処理（Ｓ１６〜Ｓ２０）は、抽出したキー要素データを用いて高度な論理判断機能が自動的に動作するかを確認し、確認できたキー要素データ等を確定したナレッジデータとして保存する。キー要素データが高度な論理判断を自動的に実行させるか否かは、シミュレーション処理により確認することができる。

最初に、データ取得部Ｆ１０は、各クライアント端末２の保存するログデータＴ２０からナレッジデータの生成に必要なデータを取得し（Ｓ１０）、それら取得したデータのフォーマットを標準化する（Ｓ１１）。つまり、データ取得部Ｆ１０は、各クライアント端末２から収集したデータを、システムログデータ、作業記録、外部データに分類し、それら分類したデータのフォーマットを統一化して、システムログデータＴ１０、作業ログデータＴ１１、外部データＴ１２、へ格納する（Ｓ１１）。

ビッグデータ解析部Ｆ１１は、システムログデータＴ１０、作業ログデータＴ１１、外部データＴ１２からデータを読み出し、それら読み出したデータをデータマイニング処理することで解析する（Ｓ１２）。その解析結果は、クライアント端末２のユーザインターフェース部２５に表示される（Ｓ１３）。

解析結果を表示するステップＳ１３は、例えばキー要素抽出部Ｆ１２が実行する。キー要素抽出部Ｆ１２は、ビッグデータ解析部Ｆ１１の出力した解析結果を、画面制御部Ｆ１５を介してクライアント端末２のユーザインターフェース部２５へ表示する。ユーザは、ビッグデータ解析結果を確認することができる。なお、本ステップＳ１３は、省略しても良い。

キー要素抽出部Ｆ１２は、ビックデータ解析処理（Ｓ１２）で抽出されたデータに基づいてキー要素データとなりうる候補データを抽出し、その候補データをキー要素データＴ１３へ保存する（Ｓ１４）。

ビッグデータ解析処理の結果の中からキー要素データの候補を選択するに際して、ユーザの判断を加えることもできる。すなわち、ユーザは、ステップＳ１３で表示される画面から、キー要素データの候補となるデータを一つまたは複数選択してもよい。または、ビッグデータ解析処理の結果のうち上位の所定数のデータを、キー要素データの候補データとして自動的に選択してもよい。

キー要素抽出部Ｆ１２は、ビッグデータ解析処理の結果からキー要素データの候補となりえるデータを全て抽出したか判定する（Ｓ１５）。キー要素抽出部Ｆ１２は、全てのキー要素データの候補を抽出済みの場合（Ｓ１５：ＹＥＳ）次のステップＳ１６に進み、そうでない場合は（Ｓ１５：ＮＯ）ステップＳ１３へ戻り、他の解析結果を判定する。以上がキー要素抽出処理である。これに続いて、ナレッジ確定処理が実行される。

ナレッジ確定処理では、シミュレーション用の入力データを作成するステップ（Ｓ１６）、シミュレーション解析するステップ（Ｓ１７）、異常検知などの高度な自動的論理判断が実行されるか否かを判断するステップ（Ｓ１８）、キー要素データ（入力データと出力データの組）と論理判断とを対応付けてナレッジデータとして保存するステップ（Ｓ１９）、全てのキー要素データを解析したか判断するステップ（Ｓ２０）、を含む。

シミュレーション用の入力データを作成するステップ（Ｓ１６）では、キー要素データＴ１３に格納されたデータのうち、入力データ（センサデータ、監視データ、取得データ）をシミュレーション解析処理への入力データとして加工する。

シミュレーション解析するステップ（Ｓ１７）では、シミュレーション解析部Ｆ１３が、ステップＳ１６で作成された入力データと異常検知などの高度な自動的論理判断とをナレッジデータとしてプラント運用保守システムに組込んだ場合に、プラント運用保守システムがどのように動作するかを解析して、その結果を出力する。ステップＳ１６では、プラント運用保守用に予め設けられている訓練シミュレータを用いても良いし、あるいは、簡易モデルを用いるシミュレータを用いても良い。または、ユーザが、運用保守システムの動作を机上で検討してもよい。

異常検知などの高度な自動的論理判断が実行されるか判断するステップ（Ｓ１８）では、ナレッジ抽出部Ｆ１４が、シミュレーション解析部Ｆ１３での結果から、異常検知などの高度な自動的論理判断が実行されたか否かを確認する。

ナレッジ抽出部Ｆ１４が高度な自動的論理判断を実行できた場合（Ｓ１８：ＹＥＳ）、シミュレーション解析処理に使用されたキー要素データと論理判断とは、ナレッジデータＴ１４の一部として保存される（Ｓ１９）。

これに対し、ナレッジ抽出部Ｆ１４が高度な自動的論理判断を実行できなかった場合（Ｓ１８：ＮＯ）、全てのキー要素データについてシミュレーション解析を行ったかを判断する（Ｓ２０）。未だシミュレーション解析していないキー要素データがある場合（Ｓ２０：ＮＯ）、ステップＳ１６へ戻る。抽出されたキー要素データの全てについてシミュレーション解析を行った場合（Ｓ２０：ＹＥＳ）、本処理を終了する。

このように構成される本実施例によれば、既存のプラント４で使用されている暗黙知化されたナレッジデータを自動的に抽出することができる。

本実施例によれば、作業者の経験や勘として隠されてきた運用保守ノウハウの少なくとも一部を、ナレッジ策定支援システム１により可視化することができ、新規プラント６の運用保守に活かすことが可能となる。

したがって、本実施例を用いて形式知化したナレッジデータを、ソフトウェアとして新規プラントの運用保守システムに実装すれば、高度なプラント運用保守ノウハウを有さない新規事業者であっても、信頼性の高い運用保守を行うことができる。また、特性や実績等の不明な他社製品を組み合わせたプラントに、本実施例により形式知化したナレッジデータを適用することで、安定した高品質の運用保守を提供することができる。

なお、本実施例では、ナレッジの一例として、異常検知などの高度な自動判断機能を述べた。しかし、ナレッジは、異常検知や異常予兆の検知などに限らない。運用保守に関わるすべての機能、すなわち、特定のセンサ４１や特定の機器４２が係わる機械および人の判断に係わる一連の特定処理は、ナレッジである。

図１１，図１２を用いて第２実施例を説明する。本実施例を含む以下の各実施例は、第１実施例の変形例に該当するため、第１実施例との相違を中心に説明する。本実施例では、ナレッジを拡張する場合を説明する。本実施例では、プラント４のログデータが論理判断やアクションを含んでいる。

図１１は、本実施例のシステムログデータＴ１０に含まれる論理判断・アクションテーブルＴ１０Ｃの例を示す。

論理判断・アクションテーブルＴ１０Ｃは、例えば、日時を表す日時Ｃ１００Ｃ、どのような処理を行ったかを示す実行名称Ｃ１０１Ｃ、その要因となった事象を示す要因名称Ｃ１０２Ｃ、処理の実行主体である主体者Ｃ１０３Ｃ、主体者Ｃ１０３Ｃがどの機器４２に対して処理を行ったかを示す対象機器Ｃ１０４Ｃを含んでいる。

主体Ｃ１０３Ｃは、「機械」の場合と「人」の場合との２種類がある。主体Ｃ１０３Ｃが「機械」である場合とは、予め決定された条件に基づいて自動的に処理する場合であり、処理に際して人の判断は含まれない。例えば、ある設定値を超えた場合は、自動的にスイッチを切るような処理である。

これに対し、主体Ｃ１０３Ｃが「人」である場合とは、人による判断を介して処理する場合である。例えば、必ず人の判断で処理することが義務付けられている処理や、突発的な故障や異常に対する処理である。

本実施例のビッグデータ解析部Ｆ１１は、システムログデータＴ１０、作業ログデータＴ１１、外部データＴ１２の３種類のログデータから、機械的な論理判断または人の判断を介したアクションに関連しそうな項目をピックアップする。本機能は、いわゆるデータマイニング手法を用いて実現可能であるため、これ以上の説明を省略する。

図１１は、本実施例のキー要素データＴ１３_１の例を示す。本実施例のキー要素データＴ１３_１は、図８で述べたキー要素データＴ１３に対して、図１０で述べた論理判断・アクションテーブルＴ１０Ｃの内容をさらに含んでいる。

すなわち、キー要素データＴ１３＿１は、キー要素の識別を表すアクションＩＤ Ｃ１３０と、どのような論理判断や行動を行ったかを示すアクションＣ１３３と、そのアクションに至るために取得した内容を示す取得データＣ１３１と、そのアクションを起こすために指令した内容を示す指令データＣ１３２とを含む。

取得データＣ１３１は、どの機器４２からデータを取得したのかを示す機器名Ｃ１３１１と、どのセンサ４１からデータを取得したかを示すセンサ名Ｃ１３１２とを含む。本実施例では、１つのアクションＣ１３３に対して１種類の取得データＣ１３１のみ対応付けているが、これに限らず、１つのアクションＣ１３３に対して複数の取得データＣ１３１を対応付けてもよい。

指令データＣ１３２は、どの機器４２へ指令したかを示す機器名Ｃ１３２１と、機器４２の持つどの制御対象へ制御指令を出したかを示す制御対象Ｃ１３２２とを含む。本実施例では、１つのアクションＣ１３３に対して１種類の指令データＣ１３２のみ対応付けているが、これに限らず、１つのアクションＣ１３３に対して複数の指令データＣ１３２を対応付けてもよい。

図１２のアクションＩＤ Ｃ１３０が”００１”のレコードに着目する。これはアクションＣ１３３が「運転開始」であり、機器４２の運転を開始する場合を示している。ここでは、運転開始時にセンサデータは必要ないとして説明するため、取得データＣ１３１には値がセットされていない。機器名Ｃ１３１１およびセンサ名Ｃ１３１２には、いずれも「なし」が記憶されている。

これに対し、機器４２の運転を開始するためには指令データＣ１３２が必要である。このため、指令データＣ１３２の機器名Ｃ１３２１および制御対象名Ｃ１３２２には、制御指令の対象を特定する値が設定されている。

なお、実際の運用においては、指令前および指令後のいずれも機器４２の動作を確認するため、取得データＣ１３１に「なし」が設定される場合はほぼあり得ないが、ここでは説明を単純化するため省略している。

キー要素データＴ１３＿１には、値の取得先と、値の設定方法とに応じて以下の５種類がある。以下の説明において、値が設定されていない場合とは、図１２において「なし」が設定されていることを意味する。

第１は、アクションＣ１３３に応じて、取得データＣ１３１に値が設定されておらず、指令データＣ１３２の機器名Ｃ１３２１および制御対象名Ｃ１３２２にはそれぞれ値が設定されている場合である。

第２は、取得データＣ１３１の機器名Ｃ１３１１およびセンサ名Ｃ１３１２に値がそれぞれ設定されており、指令データＣ１３２には値が設定されていない場合である。

第３は、取得データＣ１３１および指令データＣ１３２にそれぞれ値が設定されている場合である。

第４は、取得データＣ１３１の機器名Ｃ１３１１に「外部連携」が設定されている場合である。この場合は、外部システムからデータを取得することで、その外部システムと連携する。

第５は、指令データＣ１３２の機器名Ｃ１３２１に「外部連携」が設定されている場合である。この場合は、外部システムに対して指令を発することで、その外部システムと連携する。

図１２に示すキー要素データ１３＿１を用いて、第１実施例で説明したナレッジ策定支援処理（図１０）を実行すれば、異常検知などの高度な自動的論理判断に加え、一般的な論理判断も含むナレッジデータの策定を支援できる。

このように構成される本実施例も第１実施例で述べたと同様の作用効果を奏する。さらに本実施例によれば、一般的な論理判断と高度な自動的論理判断との両方を含む幅広いナレッジを既存プラントから取得できる。したがって、この幅広いナレッジを新規プラントの運用保守システムへ適用することで、ノウハウを持たない新規事業者の場合や不慣れなセンサや機器を寄せ集めて新規プラントを構築する場合でも、信頼性の高い運用保守を実現できる。

図１３を用いて第３実施例を説明する。本実施例では、異常検知などの高度で自動的な論理判断を得るために必要となる、キー要素データ（センサ４１から取得するデータと、機器４２へ指令するデータ）の取得する頻度を特定する。つまり本実施例では、運用保守ナレッジを実現するために、センサ４１および機器４２が備えるべき性能を調べる。

図１３は、ナレッジの成立条件を探索する処理のフローチャートである。本処理をナレッジ成立条件探索処理と称する。本処理は、ナレッジ抽出部Ｆ１４が実行する。

ナレッジ成立条件探索処理は、後述のように、キー要素データに係わる時間帯（開始時刻と終了時刻）の検出（Ｓ３０）と、指令データ または センサデータの頻度変更（Ｓ３１）と、シミュレーション用入力データの作成（Ｓ３２）と、シミュレーション解析（Ｓ３３）と、自動判断機能または自動判断に基づく制御が実行されたかの判断（Ｓ３４）と、キー要素データの条件（上限値／下限値など）を保存（Ｓ３５）、すべてのキー要素で解析を終えたかの判断（Ｓ３６）、で構成する。

ステップＳ３０では、キー要素データに係わる時間帯を設定する。時間帯は、例えば開始時刻と終了時刻で定義される。このステップＳ３０では、ナレッジデータＴ１４から、関連するキー要素データのＩＤ Ｃ１４２を調べ、そのＩＤ Ｃ１４２を用いてキー要素データＴ１３のＩＤ Ｃ１３０を検索する。

ステップＳ３０では、ナレッジに関連する取得データＣ１３１（センサデータ）および指令データＣ１３２について、システムログデータＴ１０Ａ，Ｔ１０Ｂを検索することで、取得データＣ１３１および指令データＣ１３２に対応する開始時刻と終了時刻とをそれぞれ決定する。つまり、ステップＳ３０では、ナレッジを抽出する基となったデータ（取得データと指令データ）について、それらデータの検出された時間帯を特定する。

ステップＳ３１では、指令データ（出力データ）または取得データ（入力データ）の取得頻度を変更する。ステップＳ３１では、ステップＳ３０で設定した時間帯において、指令データと取得データの発生頻度（検出頻度）を算出し、最新の頻度よりも所定値だけ低下させた頻度を設定する（取得頻度＝最新の取得頻度−所定値）。

ステップＳ３２では、シミュレーション処理に使用する入力データを作成する。ステップＳ３２は、ステップＳ３０で設定したキー要素データの時間帯と、ステップＳ３１で設定した取得頻度とに基づいて、ログデータＴ１０Ａ，Ｔ１０Ｂから、関連するデータ（指令データＣ１０１Ｂと取得データＣ１０１Ａ）を取得する。そして、ステップＳ３２では、それらデータの頻度をステップＳ３１で設定した頻度に調整する。

ステップＳ３３では、シミュレーション解析部Ｆ１３が、シミュレーション用入力データ作成（Ｓ３２）で作成した各種入力データからプラント運用保守システムがどのように動作するかを解析し、その結果を出力する。このシミュレータは、プラント運用保守用の訓練シミュレータを用いても良いし、簡易モデルを活用したシミュレータを用いても良いし、机上検討でも良い。

ステップＳ３４では、データの取得頻度を低下させた場合でも、自動判断機能もしくは自動判断に基づく制御が実行されたかを判断する。ステップＳ３４では、シミュレーション解析部Ｆ１３での解析結果から、自動判断機能もしくは自動判断に基づく制御が実行されたかを確認する。それらが実行された場合（Ｓ３４：ＹＥＳ）、ステップＳ３１へ戻り、頻度をさらに低下させて再解析する（Ｓ３２，Ｓ３３）。それらが実行されない場合（Ｓ１８：ＮＯ）、処理を進める。

ステップＳ３５では、ナレッジの再現する条件（取得頻度の上限値や下限値）をキー要素データに対応付けて、ナレッジデータＴ１４へ保存する。

ステップＳ３６では、全てのナレッジデータについて、その再現条件（自動判断機能もしくは自動判断に基づく制御が実行される条件）を解析したか判定する。未解析のナレッジがある場合（Ｓ３６：ＮＯ）、ステップＳ３０へ戻る。全てのナレッジについて解析済の場合（Ｓ３６：ＹＥＳ）、本処理を終了する。

このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに本実施例によれば、ナレッジに必要となる、センサからデータを取得する頻度や機器（アクチュエータ）への指令頻度を決定できる。本実施例によれば、新プラント６でナレッジを活かすために必要な、センサ４１および機器４２の仕様を決定することができるため、第１実施例に比べて無駄の少ない運用保守を実現できる。本実施例は第１実施例、第２実施例のいずれとも結合させることができる。

図１４を用いて第４実施例を説明する。本実施例では、ナレッジ策定支援システム１がクライアント端末２に提供する画面に対するユーザの操作履歴を自動的に抽出し、その操作履歴を作業ログデータＴ１１の少なくとも一部として使用する。

図１４は、クライアント端末２に表示される画面に対するユーザの操作履歴を抽出して保存する処理のフローチャートである。本処理は、例えば、ナレッジ策定支援システム１がクライアント端末２や運用保守端末３と協力して実行する。以下では、運用保守端末３の表示画面に対する操作をナレッジ策定支援システム１が取得して、画面操作ログとして保存する例を説明する。

運用保守端末３のユーザインターフェース部３５は、運用保守に関する画面を表示する（Ｓ４０）。ユーザは、その画面に表示されたボタンをクリック等して操作する。画面に対するユーザ操作は、運用保守端末３のユーザインターフェース３５により検出され、通信部２３を介してナレッジ策定支援システム１に送られる（Ｓ４１）。

ナレッジ策定支援システム１の画面制御部Ｆ１５は、運用保守端末３から画面操作データを受信すると（Ｓ５０）、その画面操作データを解析する（Ｓ５１）。データ取得部Ｆ１０は、画面制御部Ｆ１５での解析結果を画面操作ログとして、画面操作ログデータＴ１５へ記憶する（Ｓ５２）。

画面操作ログデータＴ１５は、例えば、操作ＩＤ、操作日時、操作種別、操作内容を対応付けて管理する。ユーザのＩＤをさらに対応付けて管理してもよい。画面操作ログデータＴ１５を参照することで、ユーザがどの画面要素（ボタン、入力欄など）に対して、どのような操作をしたのかを確認することができる。

ナレッジ抽出部Ｆ１４は、作業ログデータＴ１１の少なくとも一部として、画面操作ログデータＴ１５を使用する。これにより、ナレッジ抽出部Ｆ１４は、ナレッジを構成しうるキー要素データを抽出する。

このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに本実施例では、ユーザの画面操作を自動的に取得して解析し、作業ログデータＴ１１の一部である画面操作ログデータＴ１５を作成する。したがって、ユーザが手動で作業記録をつける必要がなく、使い勝手が向上する。本実施例は、第１〜第３実施例のいずれとも結合させることができる。

図１５を用いて第５実施例を説明する。本実施例では、既存プラントから抽出したナレッジを新規プラントの運用保守へ適用するに際して、プラントのシステム構成の観点と、プラントを運営する顧客のポリシとを考慮する。

図１５は本実施例の全体概要を示す。既存プラントＰ１〜Ｐ３からは、それぞれ複数のナレッジが抽出される。プラントＰ１からはナレッジＮ１０〜Ｎ１ｎが、プラントＰ２からはナレッジＮ２０〜Ｎ２ｎが、プラントＰ３からはナレッジＮ３０〜Ｎ３ｎが、それぞれ取得されたとする。

各既存プラントＰ１〜Ｐ３から抽出されたナレッジをそのまま全て新規プラントＰ４へ適用できるとは限らない。新規プラントＰ４と既存プラントＰ１〜Ｐ３とはシステム構成が相違し、さらにプラントを運営する顧客のポリシも異なる場合がある。そこで、本実施例では、既存プラントの構成と新規プラントの構成とを比較することで、既存プラントから抽出したナレッジを新規プラントへ適用可能であるかを判定する。

さらに、本実施例では、システム構成上は適合すると判定されたナレッジについて、新規プラントを運営する顧客のポリシに合致するか判定する。図１５の場合、システム構成上の適合可能性と顧客ポリシの両方を満たすナレッジＮ１ｎ，Ｎ２１，Ｎ３０，Ｎ３２のみが新規プラントＰ４に適用される。

このように構成される本実施例によれば、複数の既存プラントＰ１〜Ｐ３から抽出したナレッジから、新規プラントＰ４へ適用可能なナレッジを選び出して、新規プラントＰ４へ適用することができる。本実施例は、第１〜第４実施例のいずれとも結合させることができる。

図１６を用いて、第６実施例を説明する。本実施例では、既存プラントＰ５〜Ｐ７から抽出されたナレッジを、予め用意されているポリシごとに分類して保存する。図１６に示す例では、プラントＰ５からはナレッジＮ５０〜Ｎ５ｎが、プラントＰ６からはナレッジＮ６０〜Ｎ６ｎが、プラントＰ７からはナレッジＮ７０〜Ｎ７ｎが、それぞれ取得されたとする。これらナレッジのうち、ナレッジＮ５１，Ｎ５２，Ｎ６０，Ｎ６２，Ｎ７０，Ｎ７２は、「安全優先」というポリシに分類されている。他のナレッジＮ５３，Ｎ５ｎ，Ｎ６３，Ｎ７１，Ｎ７３，Ｎ７ｎは、「コスト優先」というポリシに分類されている。

このように構成される本実施例によれば、既存プラントから抽出したナレッジをポリシごとに分類して保存するため、新規プラントを運営する顧客の希望に応じたナレッジを選び出して新規プラントへ適用することもできる。本実施例は、第１〜第４実施例のいずれにも結合させることができる。

なお、本発明は、上述した実施形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。上述の実施形態において、添付図面に図示した構成例に限定されない。本発明の目的を達成する範囲内で、実施形態の構成や処理方法は適宜変更することが可能である。

また、本発明の各構成要素は、任意に取捨選択することができ、取捨選択した構成を具備する発明も本発明に含まれる。さらに特許請求の範囲に記載された構成は、特許請求の範囲で明示している組合せ以外にも組み合わせることができる。

１：運用保守ナレッジ策定支援システム、２：クライアント端末、３，５：運用保守システム（運用保守端末）、４：既存システム（既存プラント）、６：新規システム（新規プラント）、４１：センサ、４２：機器、Ｔ１０：システムログデータ、Ｔ１１：作業ログデータ、Ｔ１２：外部データ、Ｔ１３：キー要素データ、Ｔ１４：ナレッジデータ、Ｆ１０：データ取得部、Ｆ１１：ビッグデータ解析部、Ｆ１２：キー要素抽出部、Ｆ１３：シミュレーション解析部、Ｆ１４：ナレッジ抽出部、Ｆ１５：画面制御部、Ｆ１６：通信制御部

Claims (10)

1. 既存システムから抽出する情報を用いて、運用保守に関する知識情報の策定を支援する運用保守知識情報の策定支援システムであって、
   前記既存システムに関する所定の情報を取得する情報取得部と、
   前記取得された所定の情報を解析することで、運用保守の論理判断に関するキー要素となるキー要素情報を抽出するキー要素抽出部と、
   前記抽出されたキー要素情報をシミュレーション解析することで、運用保守に関する知識情報である運用保守知識情報を抽出し、保存する運用保守知識情報抽出部と、
   を備え、
   前記情報取得部は、前記既存システムを構成する機器へ入力される入力情報と前記機器への出力を指令する出力情報と運用保守に関する作業記録情報とを、前記所定の情報として取得し、
   前記キー要素抽出部は、前記入力情報および前記出力情報のうち前記論理判断に対応する情報を前記キー要素情報として抽出し、
   前記運用保守知識情報抽出部は、前記キー要素情報と前記論理判断との間に関係性が存在するかを前記シミュレーション解析により確認し、前記キー要素情報と前記論理判断とに関係性が存在することを確認できた場合に、前記キー要素情報と前記論理判断とを前記運用保守知識情報として抽出する、
   運用保守知識情報の策定支援システム。
2. 前記運用保守知識情報抽出部は、前記キー要素情報に含まれる入力情報の発生条件を変えながら前記シミュレーション解析することで、前記キー要素情報に含まれる出力情報が出現するかを判定し、前記出力情報が出現するために必要な前記入力情報の発生条件を、前記運用保守知識情報の一部として抽出し、前記キー要素情報および前記論理判断に対応づけて保存する、
   請求項１に記載の運用保守知識情報の策定支援システム。
3. 前記運用保守知識情報抽出部の抽出した前記運用保守知識情報を新規システムへ適用するために出力する、
   請求項２に記載の運用保守知識情報の策定支援システム。
4. 前記論理判断は、障害発生の予兆に関する判断を含む、
   請求項３に記載の運用保守知識情報の策定支援システム。
5. 前記既存システムと前記新規システムとのシステム構成の異同に基づいて、前記運用保守知識情報を前記新規システムへ適用可能であるか判定し、適用可能と判定した運用保守知識情報のみを前記新規システムへ適用する、
   請求項４に記載の運用保守知識情報の策定支援システム。
6. 前記新規システムへ適用可能であると判定された運用保守知識情報のうち、前記新規システムについて対応付けられたポリシに適合する運用保守知識情報のみを前記新規システムへ適用する、
   請求項５に記載の運用保守知識情報の策定支援システム。
7. 前記運用保守知識情報を、予め設定された複数のポリシに分類する、
   請求項４に記載の運用保守知識情報の策定支援システム。
8. 前記所定の情報には、前記既存システムを運用保守する画面に対する操作の履歴である画面操作履歴情報が含まれる、
   請求項１〜７のいずれか一項に記載の運用保守知識情報の策定支援システム。
9. 既存システムから抽出する情報を用いて、運用保守に関する知識情報の策定をコンピュータにより支援する運用保守知識情報の策定支援方法であって、
   前記既存システムに関する所定の情報を取得し、
   前記取得された所定の情報を解析することで、運用保守の論理判断に関するキー要素となるキー要素情報を抽出し、
   前記抽出されたキー要素情報をシミュレーション解析することで、運用保守に関する知識情報である運用保守知識情報を抽出して保存し、
   前記所定の情報には、前記既存システムを構成する機器へ入力される入力情報と前記機器への出力を指令する出力情報と運用保守に関する作業記録情報とが含まれており、
   前記入力情報および前記出力情報のうち前記論理判断に対応する情報が前記キー要素情報として抽出され、
   前記キー要素情報と前記論理判断との間に関係性が存在するかを前記シミュレーション解析により確認し、前記キー要素情報と前記論理判断とに関係性が存在することを確認できた場合に、前記キー要素情報と前記論理判断とを前記運用保守知識情報として抽出し、保存する、
   運用保守知識情報の策定支援方法。
10. コンピュータを、既存システムから抽出する情報を用いて、運用保守に関する知識情報の策定を支援する運用保守知識情報の策定支援システムとして機能させるためのコンピュータプログラムであって、
    前記コンピュータ上に、
    前記既存システムを構成する機器へ入力される入力情報と前記機器への出力を指令する出力情報と運用保守に関する作業記録情報とを、所定の情報として取得する情報取得部と、
    前記取得された所定の情報を解析することで、前記入力情報および前記出力情報のうち運用保守の論理判断に関するキー要素となるキー要素情報を抽出するキー要素抽出部と、
    前記キー要素情報と前記論理判断との間に関係性が存在するかをシミュレーション解析により確認し、前記キー要素情報と前記論理判断とに関係性が存在することを確認できた場合に、前記キー要素情報と前記論理判断とを前記運用保守知識情報として抽出し、保存する運用保守知識情報抽出部であって、さらに、前記キー要素情報に含まれる入力情報の発生条件を変えながら前記シミュレーション解析することで、前記キー要素情報に含まれる出力情報が出現するかを判定し、前記出力情報が出現するために必要な前記入力情報の発生条件を、前記運用保守知識情報の一部として抽出し、前記キー要素情報および前記論理判断に対応づけて保存する運用保守知識情報抽出部と、
    をそれぞれ実現させるコンピュータプログラム。

Images