JP2014235674A - 保守管理システム及び保守管理システムの保守管理方法 - Google Patents

Abstract

【課題】作業者が現場知として持っている知識や技術を作業手順書に反映することが可能となり、作業の効率化や高品質化を図ることが出来、合わせて、作業時の不具合事象も警告できる保守管理システムを提供する。【解決手段】所定の機器の保守に関する第１の作業データを受け付けるモバイル端末１０と、前記作業データと、前記機器の前回の保守に関する第２の作業データとが格納されるデータベースサーバ５０と、前記データベースサーバ５０と接続され、前記第１の作業データと、前記第２の作業データから第１の故障間隔を算出するアプリケーションサーバ４０とを有する。【選択図】図１

Description

本発明は、保全作業における現場知の収集及び活用に関する。特に、発電所における保全作業員毎の知(知識・技術)を作業手順に反映する技術である。

現場知の管理については、特許文献１において、現場データの即時的な知識化を可能とするデータ構造方式として、現場のコトバを現場知識として情報化する方法が開示されている。また、作業手順については、特許文献２において、過去作業内容を作業記録として蓄積し、ある局面での作業選択のノウハウとして選択理由と内容をペアで記録することで、作業者に最適な作業手順を掲示する方法を開示している。

特開２０１０−１１８８５０号公報 特開平１１−２６５３６８号公報

しかし、特許文献２では、作業手順が明らかでかつ、その選択理由が明白な場合、比較及び教示を行うため、作業内容やその理由が個々人の知識・経験として暗黙知化している場合、ノウハウの蓄積や作業手順の効率化が行うことができないという課題がある。また、特許１においては、データ構造方式のため、作業内容の比較方法や、手順への反映については開示がない。

そこで、本発明では、前記の課題を解決するための手段として、所定の機器の保守に関する第１の作業データを受け付けるモバイル端末と、前記作業データと、前記機器の前回の保守に関する第２の作業データとが格納されるデータベースサーバと、前記データベースサーバと接続され、前記第１の作業データと、前記第２の作業データから第１の故障間隔を算出するアプリケーションサーバとを有する。

本発明によれば、作業者が現場知として持っている知識や技術を作業手順書に反映することが可能となり、作業の効率化や高品質化を図ることが出来る。合わせて、作業時の不具合事象も警告できることから、ヒューマンエラーが原因で大事故につながるようなことを低減でき、保全の高品質化により発電所の重要な目標である設備の稼働効率向上が可能となる。

上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

システムの全体構成図である。 作業記録の構造化である。 作業データ構造である。 作業詳細データ構造である。 作業実データ構造である。 機器データ構造である。 作業内容判定処理フロー図である。

図面を用いて説明する前に、一実施形態の概要を以下に説明する。
まず、一般的な保全作業フローを規定する。そこから個別機器や系統に対する作業手順が決定されるのだが、都度新規で作成するのではなく、構造化した手順を用意しておき、フロー毎にリンクさせ手順書として発行する。そこに、具体的なタスクチェックリストや基準となる数値といった予定が紐付き、結果を随時入力していく。

作業者はあらかじめモバイル端末を所持し、端末にはこれら横串の通された、作業予定保持されており、そこに随時結果を入力していき、作業記録としていく。また、機器にはセンサが取り付けられており、リアルタイムにセンサ値を作業記録と結び付けデータベースに登録している。大量のデータを作業記録と連動し収集、蓄積できる。この際、リアルタイムで比較も行うことで、あまりに作業時間が他作業と異なっていたり、数値が高すぎたりした場合には、何らかの不具合事象が発生していると警告を発することも可能となる。

作業完了後に、異なった作業者の作業を比較することで、効率のよい作業を行なっている作業員を判定する。そもそも、保全作業には大きく２つの形態がある。予防保全か事後保全である。予防保全とは、機器が故障する前に予め故障を防ぐために保全作業を実施する。運転データを監視し閾値を下回った場合作業を行う予知保全と、予め決められた間隔で定期的に作業を行う定期保全がある。事後保全とは、故障が発生してから修理や入替を行う。これら作業の優劣の判定は次の保全作業までの間隔、故障間隔（ＴＢＦ：Time Between Failure）の比較により実施する。予防保全においては厳密に言えば故障する前に作業を行うのでＴＢＦとは言えないが、本発明の一実施態様においては、次の保全作業までの時間全てをＴＢＦとして定義する。予防保全においても、事後保全においても次の作業までの間隔（ＴＢＦ）が長ければ稼働率が高く保全作業の効果が高いといえる。効果が高かった作業が特定できれば、作業記録を構造的に保持・記録していることから、作業内容や作業時間から、他の作業員とはどの作業において差が出ているのかが測定できる。作業にかかった時間（ＴＴＲ：Time to Repair）は、作業結果を入力するたびに時間も管理しているので、手順ごとに作業時間を自動で取得することができる。ここまでシステムで判定することで、その情報を基に手順書に記載すべきかどうかを判別する。判別及び手順書の書き換えは人手によるが、文書を構造化し、フローと結びつけているため、横展開についてはシステムにて容易に可能である。

以下、図面を用いて本発明に関する実施の形態を説明する。
図１に本発明を構成する全体構成図を示す。
機器システム１００は、ネットワークＡ８０を介して、ＡＰサーバ４０と、ＤＢサーバ５０とに接続され、モバイル端末１０、機器２０とセンサ３０を有している。モバイル端末は、携帯電話やスマートフォンやタブレット端末の携帯できるものであればなんでもよい。保全作業員は、機器システム１００のモバイル端末１０を保全現場に携行して保全作業を行う。モバイル端末１０は作業結果の入力のみならず、作業手順や内容の表示、作業に伴う運転データの表示・収集・保持なども行う。

モバイル端末１０は、ネットワークＡ８０を通してＡＰサーバ４０に接続されており、上記各種情報をリアルタイムにダウンロードして表示することやモバイル端末１０から入力を行い、モバイル情報処理部４１に送信することができる。モバイル情報処理部４１は送信された情報をＤＢサーバ５０に記録する。

機器２０は、保全作業の対象設備になる。この機器２０にはセンサ３０が接続されている。一般的に、発電所の各機器にはセンサが設置されており、現場もしくは遠隔地よりその設備の稼働状況を把握できるようになっている。また、センサがついていない機器や部位も当然ながら存在するのでその場合、センサを新たに設置する必要がある。センサ３０はネットワークＡ８０を通してＡＰサーバ４０に接続されており、センサ３０にて機器２０より取得した実データ（センシングデータ）は、プラントの運転データとしてＡＰサーバ４０経由で、ＤＢサーバ５０に保持・記録処理される。実データ（センシングデータ）には振動・熱・音・流量・圧力・配管肉厚・蒸気量・電流・電圧などがあり、これらは対象設備の適切な箇所にセンサを設置、接続される。

ＡＰサーバ４０は、一時的にデータが格納されるメモリ４６と、ＣＰＵ４５を有する。ＣＰＵ４５は、メモリに格納されあるプログラムを読み出し、モバイルデータ処理部４１、機器データ処理部４２、作業判定処理部４３と更新情報処理部４４として、プログラムを実行する。

作業判定処理部４３は、ＤＢサーバ５０のデータを用いて判断し、必要な情報は、ネットワークＢ９０を通して接続されている端末１１０に送信される。

端末１１０は、表示部６０と入力部７０を有する。ＡＰサーバ４０からネットワークＢ９０を介して、送信される情報を、端末１１０は、表示部６０に当該情報を表示する。管理者や監督者らは、表示部６０にて提示された情報をもとに、入力部７０より手順書の更新を行う。端末１１０は、手順書の更新データをＡＰサーバ４０に送信する。その後、更新情報処理部４４は、ＤＢサーバ５０へと、更新データを格納する。なお、詳細なフローは、追って、説明する。

ＤＢサーバ５０は、送信受信されるデータを処理するＣＰＵ５１、データを一時的に格納されるメモリ５２と、データが格納されるＤＢ５３とを有する。

図２は、ＤＢ５３に格納される作業記録の構造化データの例である。ただし、これらは実際のデータテーブルとは異なっている、論理的な構造イメージである。作業記録は大きく４つにわかれている。４つとは、ワークフロー２−１、手順書２−２、実データ２−３、実績２−４である。フローは作業のみならず、計画や承認も含めたプラント運営（業務）全体の流れを表している。手順書は、作業の方法（対象機器、対象箇所や機器の操作法）が書かれている。従来は１つの作業で１つの手順書が発行されていたが、本実施例においては、１つの動作（バルブをしめる、配管内の付着物を削る等）毎にパーツ化・構造化し、組み換えを容易としている。このフローと手順書が予定となる。実データ２−３と実績２−４は、それぞれ構造化された手順書２−２毎に記録されることとなる。作業員が、携帯しているモバイル端末１０に順次作業が終了次第、作業結果や実績を入力する。実データは、上記センシングデータと同じものであり、遠隔取得ではなく、作業員が作業を行う中で取得されるデータになる。実績２−４は、その作業を手順書通りに実行できたかどうかというチェックであり、各々作業者や時間とともに記録されている。これらをそれぞれフロー単位から、手順書単位に横串を通すように関連付けて記録・保持する。

図３は、ＤＢ５３に格納される作業データＤ５の一例である。作業データＤ５は、作業ＩＤ、作業コード、機器ＩＤ、開始時刻、終了時刻、ＴＢＦとＴＴＲが格納される。

図４は、ＤＢ５３に格納される作業詳細データＤ６の一例である。作業詳細データＤ６は、作業コード、フローＮｏ,手順Ｎｏ,作業員Ｎｏ、実データコード、作業実績、開始時刻と終了時刻が格納される。

図５は、ＤＢ５３に格納される作業実データＤ７の一例である。作業実データＤ７は、実データＩＤ、実データコード、運転データ、開始時刻と終了時刻が格納される。

図６は、ＤＢ５３に格納される機器データＤ８の一例である。機器データＤ８は、機器ＩＤと機器コードが格納される。

図７は、作業内容の優劣判定フローの一例である。新規作業データの入力がフローのトリガーとなる。なお、新規作業データ入力作業はモバイルデータ処理部４１が、優劣の判定については、作業判定処理部４３が行う。作業担当者がモバイル端末１０より新規作業データを入力すると、モバイル端末１０は、ＡＰサーバに新規作業データを送信する。モバイルデータ処理部４１は、新規作業データを受信すると、ＤＢ５３にデータを格納するために、ＤＢサーバ５０に新規作業データを送信する。また、モバイルデータ処理部４１は、作業データＤ５を読み出し、同機器に対する同作業を実施した直前作業を特定する（Ｓ４００）。モバイルデータ処理部４１は、機器ＩＤと作業コードが同じもので、ＴＢＦが入力されていない作業データを直前作業データとして抽出する。

次に、モバイルデータ処理部４１は、直前作業データに、ＴＢＦを計算し、作業データＤ５を更新する。（Ｓ４１０）。モバイルデータ処理部４１は、直前作業終了時刻と新規作業開始時刻から、その差を算出し、ＴＢＦとする。モバイルデータ処理部４１は、直前作業の作業データＤ５を更新する。

次に、作業判定処理部４３は、作業データＤ５の比較により作業の優劣を判定する（Ｓ４２０）。作業判定処理部４３は、Ｓ４００で、同機器に対する同作業が判明しているため、それらのＴＢＦと、直前作業のＴＢＦを比較し、直前作業のＴＢＦが長ければ直前作業の保全作業効果が高かったと判断する（Ｓ４３０）。その他、作業判定処理部４３は、同機器ではないが、同機器種別に対する同作業とも比較を行う。この際、作業判定処理部４３は、機器データＤ８より、機器ＩＤと機器コードを取得することにより、機器種別に対する同作業を比較する。ここから、同機器と同機器種別の他機器ＩＤがわかり、作業データＤ５にてその他機器ＩＤと同作業コードにて検索することで、他機器・同機器種別・同作業が判明する。作業判定処理部４３これらＴＢＦと、直前作業のＴＢＦを比べることで、より精度の高い判断を下すことが可能となる。

直前作業の効果が高かった、つまり優れていたと判断した場合後続処理のＳ４４０へと遷移する。ただし、効果が低く、優れていたと判断できない場合には処理終了となる。

次に、作業判定処理部４３は、作業時間（ＴＴＲ）を比較し、優と判断された直前作業が通常よりＴＴＲが長かったのか短かったのかを判定する（Ｓ４４０）。これにより、管理者に作業員の知について判断をするサポートを行うことができる。

さらに、作業判定処理部４３は、直前作業の具体的にどの作業部分に違いが見られたのかを判定する（Ｓ４５０）。具体的に、作業判定処理部４３は、作業詳細データＤ６と作業実データＤ７を組み合わせることで、保全作業全体における具体的なフロー（手順）毎の作業員及び作業時間を算出する。Ｓ４４０において、直前作業の作業時間が長かった（短かった）場合には、個々のフローの作業時間が長かった（短かった）個別作業の影響が高かったと判断する。これで、保全作業の質を高めた影響の強いであろうフローが特定でき、作業員や実作業時の運転データも算出することができる。

より良い作業方法を具体的に特定し、手順書に反映するかどうかの判断を行い、実際に手順書を修正する。端末１１０は、修正手順書をＤＢサーバ５０に送信し、ＤＢサーバは、修正手順書をＤＢ５３に格納する。

本実施例によれば、ＤＢ５３に基づいて、良い作業方法が含まれるフローやその作業員、作業データをシステムで判定し提示していることから、該当作業員へのヒアリングや検討は容易になっている。また、作業詳細データＤ６のようにフローと手順、運転データに横串を通し保持・記録しているため、作業手順の横展開は非常に容易である。手順Ｎｏをもとに元手順を修正することで、その手順を含む全保全作業に対して修正版への更新が可能となる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、実施例の構成の一部について、他の構成の追加・削除・置換することが可能である。

また、機器システム１００、ＡＰサーバ４０、ＤＢサーバと端末１０は、一部または全部の機能を一つのサーバ等にまとめることができる。例えば、ＡＰサーバ４０、ＤＢサーバと端末１０の機能、手段を単一のサーバとして実現することができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての校正が相互に接続されていると考えてもよい。

１０ モバイル端末
２０ 機器
３０ センサ
４０ ＡＰサーバ
４１ モバイルデータ処理部
４２ 機器データ処理部
４３ 作業判定処理部
４４ 更新情報処理部
５０ ＤＢサーバ
６０ 表示部
７０ 入力部
８０ ネットワークＡ
９０ ネットワークＢ
２−１ ワークフロー
２−２ 手順書
２−３ 実データ
２−４ 実績
Ｄ５ 作業データ
Ｄ６ 作業詳細データ
Ｄ７ 作業実データ
Ｄ８ 機器データ

Claims (6)

1. 所定の機器の保守に関する第１の作業データを受け付けるモバイル端末と、
   前記作業データと、前記機器の前回の保守に関する第２の作業データとが格納されるデータベースサーバと、
   前記データベースサーバと接続され、前記第１の作業データと、前記第２の作業データから第１の故障間隔を算出し、前記第１の故障間隔と、前記第２の作業データに基づく第２の故障間隔と、を比較するサーバと、
   前記サーバと、前記データベースサーバに接続され、前記第１の故障間隔と前記第２の故障間隔とを表示する端末と、
   を有する保守管理システム。
2. 前記サーバは、前記機器と同種の機器に関する作業データから第３の故障間隔を算出し、前記第３の故障間隔と、前記第１の故障間隔と、を比較し、前記第３の故障間隔を前記端末に表示する
   請求項１に記載の保守管理システム。
3. 前記データベースサーバは、前記第１の作業データの手順となる手順書を格納し、
   前記端末は、前記手順書を更新した内容を前記データベースサーバに格納する請求項２に記載の保守管理システム。
4. モバイル端末により、所定の機器の保守に関する第１の作業データを受け付け、
   データベースサーバにより、前記作業データと、前記機器の前回の保守に関する第２の作業データとが格納され、
   前記第１の作業データと、前記第２の作業データから第１の故障間隔を算出し、前記第１の故障間隔と、前回第２の作業データに基づく第２の故障間隔と、を比較し、
   前記第１の故障間隔と前記第２の故障間隔とを端末に表示する
   保守管理システムの保守管理方法。
5. 前記サーバは、前記機器と同種の機器に関する作業データから第３の故障間隔を算出し、第３の故障間隔と、前記第１の故障間隔と、を比較し、前記第３の故障間隔を前記端末に表示する
   請求項４に記載の保守管理システムの保守管理方法。
6. 前記データベースサーバは、前記第１の作業データの手順となる手順書を格納し、
   前記端末は、前記手順書を更新した内容を前記データベースサーバに格納する請求項５に記載の保守管理システムの保守管理方法。

Images