知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6037852
(24)【登録日】2016年11月11日
(45)【発行日】2016年12月7日
(54)【発明の名称】プラントの異常状態解決支援システム
(51)【国際特許分類】
G05B 23/02 20060101AFI20161128BHJP
【ＦＩ】
G05B23/02 X
【請求項の数】7
【全頁数】21
(21)【出願番号】特願2013-13931(P2013-13931)
(22)【出願日】2013年1月29日
(65)【公開番号】特開2014-146147(P2014-146147A)
(43)【公開日】2014年8月14日
【審査請求日】2015年8月6日
(73)【特許権者】
【識別番号】000006013
【氏名又は名称】三菱電機株式会社
(74)【代理人】
【識別番号】100073759
【弁理士】
【氏名又は名称】大岩 増雄
(74)【代理人】
【識別番号】100088199
【弁理士】
【氏名又は名称】竹中 岑生
(74)【代理人】
【識別番号】100094916
【弁理士】
【氏名又は名称】村上 啓吾
(74)【代理人】
【識別番号】100127672
【弁理士】
【氏名又は名称】吉澤 憲治
(72)【発明者】
【氏名】佐内 孝太郎
【審査官】
川東 孝至
(56)【参考文献】
【文献】
特開２００２−１８９５１３（ＪＰ，Ａ）
【文献】
特開２００２−０７３８５０（ＪＰ，Ａ）
【文献】
特開平１１−１５０７６９（ＪＰ，Ａ）
【文献】
特開２００２−２７８７９６（ＪＰ，Ａ）
【文献】
特開２００８−０２７２７２（ＪＰ，Ａ）
【文献】
特開２００１−２６５９２１（ＪＰ，Ａ）
【文献】
特開２００２−０２３８３６（ＪＰ，Ａ）
【文献】
特開２００５−３５１６８１（ＪＰ，Ａ）
【文献】
特開２００３−１８６５３２（ＪＰ，Ａ）
【文献】
特開２００３−１４１６６３（ＪＰ，Ａ）
【文献】
特開２０１２−１２８６７４（ＪＰ，Ａ）
【文献】
米国特許出願公開第２０１３／０２７１２８７（ＵＳ，Ａ１）
(58)【調査した分野】（Int.Cl.，ＤＢ名）
Ｇ０５Ｂ ２３／００−２３／０２
(57)【特許請求の範囲】
【請求項1】
プラントの運転状態が異常の際に、その異常内容の通知、異常に対する指示の状況、および処置の状況のメッセージを記憶するデータベースと、
前記メッセージの種別を入力し表示する複数の端末と、
メッセージ配信手段を備え、前記複数の端末のうち、一の端末に入力された前記メッセージを前記メッセージ配信手段により配信先ユーザの端末へ配信するとともに、前記メッセージの内容や前記配信の状況を前記データベースに入力するサーバー機と、
前記複数の端末と前記サーバー機との間で、前記メッセージの交換を行うネットワークと、を備え、
前記サーバー機は、前記プラントを構成する設備の中からプラントの運転状態の異常通知情報に含まれる設備を特定し、その異常を解決することにより前記プラントの運転状態の復旧に向けた複数の対応が全て完了するまで、前記データベースに記憶された前記メッセージの中から、前記異常内容に対応させて前記異常に対する指示のメッセージを選択し配信することを特徴とするプラントの異常状態解決支援システム。
前記メッセージの種別を入力し表示する複数の端末と、
メッセージ配信手段を備え、前記複数の端末のうち、一の端末に入力された前記メッセージを前記メッセージ配信手段により配信先ユーザの端末へ配信するとともに、前記メッセージの内容や前記配信の状況を前記データベースに入力するサーバー機と、
前記複数の端末と前記サーバー機との間で、前記メッセージの交換を行うネットワークと、を備え、
前記サーバー機は、前記プラントを構成する設備の中からプラントの運転状態の異常通知情報に含まれる設備を特定し、その異常を解決することにより前記プラントの運転状態の復旧に向けた複数の対応が全て完了するまで、前記データベースに記憶された前記メッセージの中から、前記異常内容に対応させて前記異常に対する指示のメッセージを選択し配信することを特徴とするプラントの異常状態解決支援システム。
【請求項2】
前記異常に対する指示には、プラント運転員の教育履歴あるいは保有資格を記載した資格データを、前記データベースに資格データベースとして記憶するとともに、前記資格データベースの更新に応じて管理者及び担当者のユーザＩＤを更新することを含むことを特徴とする請求項１に記載のプラントの異常状態解決支援システム。
【請求項3】
前記特定した設備の異常状態を解決する場合、その異常に対する処置の内容ごとにその解決の期限を設定することにより、当該期限を超過した項目に対して自動的なフォローを行うことを特徴とする請求項１に記載のプラントの異常状態解決支援システム。
【請求項4】
前記特定した異常通知情報に含まれる設備の処置状況に応じて、前記異常に対する指示を追加し、または既存の指示内容への実施順を編集可能としたことを特徴とする請求項１に記載のプラントの異常状態解決支援システム。
【請求項5】
前記メッセージの配信時に、ユーザＩＤあるいは画面ＩＤの中から特定のＩＤを指定することにより、前記異常に対する指示をする連絡先の追加、当該連絡先を含む前記異常に対する指示の連絡先に指名者を設定でき、かつ体制外のメンバーへも対応依頼可能とすることを特徴とする請求項１〜請求項４のいずれか１項に記載のプラントの異常状態解決支援システム。
【請求項6】
前記異常内容の通知は、音声入力手段と音声認識手段とを用いた入力であることを特徴とする請求項１に記載のプラントの異常状態解決支援システム。
【請求項7】
前記異常の発生の際の異音、前記異常を特定した設備の特定時の状態、または改修後の当該設備の状態を伝達する手段として、異常発生の際または改修後の前記設備の状態を示す音声や画像のデータをファイル形式で添付することを特徴とする請求項１に記載のプラントの異常状態解決支援システム。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、プラントの監視や運転操作を行う運転・監視システムにおいて、プラントの運転状態の異常への迅速な対応などの課題に対し、運転・監視システムの情報を元に、適切な関係者に自動通知するとともに、運転・監視システムの管理者と作業者間に効率的な情報伝達網を構築して、速やかに異常の原因を究明し処置する仕組みを提供するものである。
【背景技術】
【0002】
従来は、事故時の対応操作ガイダンスを表示する機能（例えば特開2003-186532号公報参照）、現場作業や保守履歴を電子化する仕組み（例えば特開2008-27272号公報参照）、現在の作業に類する過去の対応を紹介する仕組み（例えば特開2005-351681号公報参照）が開示されているが、未知の事故や故障等の課題が発生したケースに対して、「課題に関連する部門のメンバーに漏れなく自動通知し、関連部門の管理者層から指示を募り、実務者層から処置実行を促す」、或いは「管理者と担当者間の課題解決に向けた指示状況やその対応状況を見える化する（「見える化する」とは、未知の事故や故障等の解決すべき課題の内容と、その内容に対応させて課題に対処すべき対象者、あるいは課題を連絡すべき対象者を特定し、フロー図等により容易に把握できる形態で特定した対象者の端末に示すことを意味する。以下同様）、更には「課題解決に直結する処置が完了するまで、指示に対する現場対応が迅速に処置されるよう自動フォローする」といった処理手段は記載されていなかった。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2003-186532号公報
【特許文献2】特開2008-27272号公報
【特許文献3】特開2005-351681号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
発電所の運転システムの運転員は、発電所を構成する機器や発電技術に関する専門知識を持ち、複数の当直グループで交代しながら、発電プラントの２４時間稼働を支えている。発電プラントの運転中に発電システムや設備に異常が発生した場合、実際には、その運転状態の異常を発見した当直員が、中央制御室の当直長に電話等で報告し、当直長は現状把握や原因究明のための指示を検討することとなる。このような場合においては、従来は、異常発見の伝達方法は電話が主となるので、あらゆる報告・指揮が当直長に集中しやすく、上述の異常発見から現状把握、そして復旧処置に至るプロセスがスピーディに実行出来ない。また、当直長他の管理者が立案する“問題解決プロセス”は、管理者の判断に委ねられるのでフォーマットを定められず、その問題解決プロセスを共有したり、他の管理者がチェックしたり、複数の管理部門の管理者および作業者間で協力してフォローすることも困難であった。
【0005】
この発明は上記のような課題を解決するために、異常通知メッセージを異常設備に関連するメンバーに漏れなく自動通知することで最適な実務メンバーを募って決定するとともに、実務メンバー間の指示あるいは対応状況をフロー図形式などにより見える化することで、問題解決プロセスの第三者レビューの実施や、当直者間の業務引き継ぎの効率化や、複数の管理者と実務者による組織的な指示あるいはこの指示に対する対応業務の実行を支援する仕組みを提供することを目的とする。
【課題を解決するための手段】
【0006】
この発明に係るプラントの異常状態解決支援システムは、プラントの運転状態が異常の際に、その異常内容の通知、異常に対する指示の状況、および処置の状況のメッセージを記憶するデータベースと、
前記メッセージの種別を入力し表示する複数の端末と、
メッセージ配信手段を備え、前記複数の端末のうち、一の端末に入力された前記メッセージを前記メッセージ配信手段により配信先ユーザの端末へ配信するとともに、前記メッセージの内容や前記配信の状況を前記データベースに入力するサーバー機と、
前記複数の端末と前記サーバー機との間で、前記メッセージの交換を行うネットワークと、を備え、
前記サーバー機は、前記プラントを構成する設備の中からプラントの運転状態の異常通知情報に含まれる設備を特定し、その異常を解決することにより前記プラントの運転状態の復旧に向けた複数の対応が全て完了するまで、前記データベースに記憶された前記メッセージの中から、前記異常内容に対応させて前記異常に対する指示のメッセージを選択し配信するものである。
【発明の効果】
【0007】
従来、異常発生時の対応の作業フローが指示者の頭の中にあり、指示者と処置者間のやり取りは電話で行われており、全プロセスが非ドキュメント手段により実行されていた。この発明によれば、本システムが持つデータベースから入力された異常の内容あるいは対策、これらについての指示あるいは処置内容を呼び出す手段を備えるとともに、異常発生に対する対応状況のデータベース化によって、異常に対応する作業フローおよび対応状況の見える化を実現したので、第三者による作業フローの評価が可能となる。
また、情報の伝達先についても、入力されたメッセージの情報から、関係者を機械的に選定する手段を備えることで、指示者が認知していない有識者への通知や異常の内容に直接関わる運転員や保守員などの関係者への配信漏れを防止するとともに、当直の引き継ぎ時の情報伝達にかかる労力を軽減して半日程度で異常状態を解決できるシステムを提供できるという効果を奏する。
【図面の簡単な説明】
【0008】
【図1】この発明の実施の形態１を実現する機器や機能の構成図である。
【図2】この発明の実施の形態１における“ユーザＩＤ入力処理”のフロー図である。
【図3】この発明の実施の形態１における“画面ＩＤ取得処理”のフロー図である。
【図4】この発明の実施の形態１における“ユーザＩＤ登録処理”のフロー図である。
【図5】この発明の実施の形態１における“配信先判定処理”のフロー図である。
【図6】この発明の実施の形態１における“残件数算出処理”のフロー図である。
【図7】この発明の実施の形態１における“メッセージ配信手段”のフロー図である。
【図8】この発明の実施の形態１における“機器担当表のユーザＩＤ更新手段”のフロー図である。
【図9】この発明の実施の形態１における“ユーザＩＤ入力画面”の図である。
【図10】この発明の実施の形態１における“異常発生通知画面”の図である。
【図11】この発明の実施の形態１における“指示入力画面” の図である。
【図12】この発明の実施の形態１における“処置状況入力画面” の図である。
【図13】この発明の実施の形態１における“処置状況承認画面” の図である。
【図14】この発明の実施の形態１における“改修対応 承認画面” の図である。
【図15】この発明の実施の形態１における“処置状況確認画面” の図である。
【図16】この発明の実施の形態２を示す機器や機能の構成図である。
【図17】この発明の実施の形態２における“期限超過フォロー手段”のフロー図である。
【図18】この発明の実施の形態２における“希望処置日時 入力エリア”を示す図である。
【図19】この発明の実施の形態２における“処置状況フォロー画面”を示す図である。
【図20】この発明の実施の形態３を示す機器や機能の構成図である。
【図21】この発明の実施の形態３における“指示事項 条件入力画面”を示す図である。
【図22】この発明の実施の形態３における“指示順序制御手段”のフロー図である。
【図23】この発明の実施の形態４を示す機器や機能の構成図である。
【図24】この発明の実施の形態４における“配信先指定入力 エリア”を示す図である。
【図25】この発明の実施の形態４における“ログインユーザ格納処理”のフロー図である。
【図26】この発明の実施の形態４における“ログインユーザ格納処理”の別のフロー図である。
【図27】この発明の実施の形態４における“処置状況入力 入力画面例”を示す図である。
【図28】この発明の実施の形態５を示す機器や機能の構成図である。
【図29】この発明の実施の形態５における“音声入力 エリア”を示す図である。
【図30】この発明の実施の形態５における“音声認識入力処理”のフロー図である。
【図31】この発明の実施の形態６を示す機器や機能の構成図である。
【図32】この発明の実施の形態６における“ファイル添付 添付操作画面”を示す図である。
【図33】この発明の実施の形態６における“ファイル添付処理”のフロー図である。
【図34】この発明の実施の形態６における“ファイル表示処理”のフロー図である。
【図35】この発明の実施の形態６における“添付ファイル 呼び出し画面”を示す図である。
【図36】この発明の実施の形態１における“異常通知管理表”を示す図である。
【図37】この発明の実施の形態１における“指示票”を示す図である。
【図38】この発明の実施の形態１における“体制表”を示す図である。
【図39】この発明の実施の形態１における“機器担当表”を示す図である。
【図40】この発明の実施の形態１における“資格データベース表”を示す図である。
【図41】この発明の実施の形態２における“異常通知管理表(“処置期限“欄追加)”を示す図である。
【図42】この発明の実施の形態２における“指示票(“処置期限“欄追加)”を示す図である。
【図43】この発明の実施の形態３における“指示票における指示順序設定”を示す図である。
【図44】この発明の実施の形態４における“ログインユーザ データベース”を示す図である。
【図45】この発明の実施の形態５における“異常通知管理表(“添付ファイル“欄追加)”を示す図である。
【発明を実施するための形態】
【0009】
実施の形態１．以下、この発明の実施の形態１を図１に基づいて説明する。
端末２には、メッセージ入力手段１２によりメッセージの種別（プラント異常を発見した者は“異常通知“、管理者は”対応指示“、実務者は”処置内容“）が入力され、メッセージ表示手段１１によりメッセージの種別である異常通知、指示状況、あるいは対応状況が表示される。端末２から配信されたメッセージは、サーバー機１の異常通知管理表、指示票生成手段１４により異常通知、指示状況、あるいは対応状況に加工され、データベースとして記録される。また、端末２とサーバー機１は、ネットワーク３を介して、データの授受を行っている。
端末２に入力されたメッセージは、サーバー機１に送信され、サーバー機１では、画面ＩＤ取得処理１５および配信先決定手段９にてメッセージの種別に応じた配信先ユーザが自動選定され、メッセージ配信手段８により配信先ユーザの端末へメッセージが送信される。また、配信先決定手段９は、発電所内の組織体制を設定した体制表データベース４と、ユーザ毎の専門性や機器担当区分を定義した機器担当表データベース５を有し、これらから入力したデータが参照され、送信元端末のユーザＩＤやメッセージ内の機器名から配信先が自動的に決定される（図３８の「体制表データ概念図」及び図３９の「機器担当表概念図」参照）。
また、やり取りされるメッセージから“対応指示”と“処置内容”を記憶する指示票データベース７と、指示に対する処置状況は異常通知管理表データベース６として記録され、端末２のメッセージ表示手段１１を用いて確認できる。
端末２には、ユーザを識別するためにログイン管理を行うユーザＩＤ取得手段１０が搭載されており、ユーザが端末２にログインするとサーバー機１内のユーザＩＤ登録手段１３に登録される。
【0010】
次に動作について説明する。端末を立ち上げると、図２に示すユーザＩＤ取得処理に基づき、システム立ち上げ時に図９に示すユーザＩＤ入力画面が表示され、ユーザＩＤの入力が促される。ユーザＩＤ取得手段１０を用いてユーザＩＤが入力されログインが実行されると、ユーザＩＤがサーバー機へ送信される(図３)。サーバー機は、図４に示すユーザＩＤ登録処理にて、端末から受信したユーザＩＤと、ユーザＩＤから得られる所属を異常通知管理表データベース６、指示票データベース７に書き込む。登録されたユーザＩＤと所属は、メッセージ配信先を決定するときに参照される。
【0012】
異常発生通知画面に“異常通知“が入力されると、サーバー機１は”異常通知“を受け取る。その際、図５に示す配信先判定処理、及び図６に示す残件数算出処理を含む配信先決定手段９が動作し、異常通知が申請されたユーザＩＤと異常通知情報に含まれる機器名称から、体制表データベース４と機器担当表データベース５を用いて配信先を決定する。図５は、“申請者の上長にあたる管理者層“および”異常機器の管理者層“が配信先リストＡとして抽出される処理であり、図６は、“異常通知“に属する指示件数と完了件数の差を算出することで、指示内容に対して処置されていない残件をカウントする処理である。
【0013】
また、機器担当表データベース５は、ユーザ毎の教育履歴・保有資格をポイント換算した資格データベース５１から、ポイントが高いユーザ順にユーザＩＤを取得し、機器担当表データベース内のユーザ情報を生成する。資格データベース５１の更新に応じて管理者及び担当者のユーザＩＤを更新する。この場合において、機器担当表データベースのユーザＩＤの更新は、図８に示す「機器担当表のユーザＩＤ更新手段」のフローに従って更新される。
【0014】
表示画面が異常発生通知画面であるため、図５のフローに基づき、“申請者の上長にあたる管理者層“および”異常機器の管理者層“が配信先リストＡとして抽出される。また、図６のフローに基づき、指示内容に対して処置されていない残件がカウントされる。図７に示すメッセージ配信処理にて、図３６に示す異常通知管理表に事象ナンバー（以下「事象No」と略す）が採番され異常通知の内容が書き込まれる。さらに、メッセージ配信手段８により配信先リストＡに設定されたユーザにより、当該ユーザがログインしている端末２に自動配信される。（配信先に登録されているユーザが、メッセージ配信時にログインしていない場合、配信後にログインした際に再配信される。）
【0015】
次に、管理者層ユーザの端末に異常通知が配信された際、メッセージ入力手段１２から図１１の指示入力画面が呼び出され、異常の内容に応じて、“対応指示“の内容が入力される。“対応指示“が入力されると、端末２はサーバー機１に”対応指示“を送信し、図５に示す配信先判定処理、及び図６に示す残件数算出処理を含む配信先決定手段９により、”対応指示“申請者のＩＤや通知情報に含まれる機器名称から、体制表データベース４と機器担当表データベース５のデータが用いられて配信先が決定される。例えば、”Ａポンプ交換部品“に関するトラブルが発生した際、該当の知識を持つ管理者（８）、（２）の管理下の担当者に対して、配信先が決定される。
【0016】
上記入力された“対応指示“は、指示入力画面からのメッセージであるため、“指示者の部下にあたる実務者層“および”異常機器の担当者層“が配信先リストＢとして抽出され、メッセージ配信手段８（図１参照）の動作説明のフロー(図７参照)により、配信先リストＢに設定されたユーザがログインしている端末２に自動配信され、指示票に事象Noと枝番号が採番されて指示内容が追加され、図３７に示す指示票の状況が指示済みにされる。この際、指示内容が図３７に示す指示票に書き込まれるとともに、図３６に示す異常通知管理表と図３７に示す指示票の件数を更新する。（配信先に登録されているユーザが、メッセージ配信時にログインしていない場合、配信後にログインした際に再配信される。）
【0017】
さらに、実務者層ユーザの端末に異常通知が配信された際、メッセージ入力手段１２から図１２の処置状況入力画面が呼び出され、実務者層ユーザは指示の内容に応じた実務を行い、“処置内容“をメッセージ入力手段１２を用いて入力する。“処置内容“が入力されると、端末２はサーバー機１に”処置内容“を送信し、図５に示す配信先判定処理、及び図６に示す残件数算出処理を含む配信先決定手段９により、配信先を決定する。
【0018】
上記のメッセージは、回答入力画面からのメッセージであるため、指示者と回答者が所属するグループの管理者群を配信先リストＣとして抽出し、図７に示すメッセージ配信手段の処理フローに従って、配信先リストＣに設定されたユーザがログインしている端末２に自動配信し、図３７に示す指示票に処置内容を記入し、図３７に示す指示票のステータスを完了とする。この場合において、配信先に登録されているユーザが、メッセージ配信時にログインしていない場合には、配信後にログインした際に再配信される。
【0019】
実務者の端末から配信先リストＡとＣに含まれる管理者層ユーザの端末に“処置内容“が配信された際、メッセージ入力手段１２を用いて、図１３に示す処置状況承認画面が呼び出され、管理者層ユーザ端末で“対応指示“と”処置内容“が適合している、すなわち、対応指示にあった処置内容が行われていることを確認し、承認ＰＢ（「ＰＢ」はプッシュボタンの略称。以下同様）あるいは否認ＰＢが押される。この場合において、否認ＰＢが押されたときには、配信元の実務者に処置内容の再記入指示が通知される。一方、承認ＰＢが押されたときには、“処置内容”が、指示票データベース７に記録され、指示内容が完了ステータスに移行する。
【0020】
最後に、図６に示す処置残件算出処理にて、異常通知管理表データベース６の指示件数と回答件数が一致し、復旧に向けた複数の対応が全て完了している場合、プラント異常を最初に発見した者と最上位の管理者群の端末には、図１４に示す“改修対応 承認画面”が表示される。配信先の全てで承認ＰＢが押されたら、本“異常通知”に関わるメッセージが配信された全宛先（配信先リストＡ、Ｂ、Ｃ）及び申請者に、承認結果を配信する。処置内容に不足があれば、“改修対応 承認画面”の配信先の端末から “対応指示”の追加が実行される。
【0021】
また、“対応指示”の処置状況については、異常通知管理表データベース６に記録される。全体の状況は図１５に示す“処置状況確認画面”で確認できる。また、発生事象、指示事項、処置内容について、例えば発生事象別に表示することが可能である。
【0022】
実施の形態２．以下、この発明の実施の形態２を図１６に基づいて説明する。
実施の形態１では、異常発生から処置完了までのプロセスを、機械的に課題解決チームを構築したり、情報共有する機能を紹介したが、実施の形態２では、設定した期限までに回答を得るための自動フォロー機能を提供する。
そこで実施の形態２では、指示依頼や処置を自動フォローするために、異常発見者の設定日時を超過した項目について、実施を促すメッセージを送信する機能と端末に期限超過している指示事項を表示する機能を付加した。
【0023】
また、サーバー機に期限超過フォロー手段２１を追加し、“希望処置完了日時“の入力と処置期限超過通知手段は端末２のメッセージ入力手段１２とメッセージ表示手段１１に図１８及び図１９に示す画面に変更することで対応する。入力された“希望処置完了日時”は、図４１の異常通知管理表および図４２の指示票の“処置期限”の欄に保存される。図１７に期限超過フォロー手段２１のフローを示す。期限超過判断はサーバー機の現在時刻と図４２に示す指示票の“処置期限“の日時と比較することで実施する。期限超過の場合は図１５の処置状況確認画面にメッセージを表示するとともに期限超過している指示を表示文字等の一部の内容について色を変えて表示する色変え表示を行う。
【0024】
実施の形態３．以下、この発明の実施の形態３を、図２０に基づいて説明する。
実施の形態１では、異常発生に対して、管理部門の端末からの指示依頼を引き出し、その依頼の処置完了をもって事態の収束（ここでは、異常の原因あるいは異常設備が判明し、それにより異常事態が解決され正常運転に戻った状態をいう。以下同様）を図ることとしていたが、処置結果によっては、指示の追加や既存の指示内容の実施順序を変更される場合もあるので、その対応機能が必要となることが想定される。これについて以下説明する。
【0025】
本実施の形態３では、指示事項の実施順を編集する機能が付加されている。すなわち、サーバー機に指示順序制御手段２２を追加する。各指示に対する実行順序の入力手段は、端末２のメッセージ入力手段１２により、図２１に示す指示事項の条件入力画面を用いて条件設定する。具体的には、1001と1002の回答を受け、指示者がタスクの順番、あるいは論理構成(例えば1001と1002のand条件をとって1003とする場合には「設定」を「ＡＮＤ」とする)、などを入力して条件を設定する。
【0026】
図２２には、上記指示順序制御手段２２の処理フローを示す。指示票の開始条件に記載している指示が空白（この場合は指示未完了を示す）もしくは空白以外（この場合は指示完了を示す）かを判断し、条件となっている指示がすべて完了しているか（この場合は「ＡＮＤ」条件での完了を示す）もしくは条件となっている指示のいずれかが完了しているか（この場合は「ＯＲ」条件での完了を示す）によって条件が設定されている指示を送信する。図４３に開始条件を設定した場合の指示票を示す。
【0027】
実施の形態４．以下、この発明の実施の形態４を図２３に基づいて説明する。
実施の形態１では、異常発生、指示依頼、処置完了、異常収束の順に、これらのプロセスを、異常に関係するメンバーに情報共有する機能を説明したが、体制表に記載されていない組織や、個人を指定して対応を依頼することが出来なかった。
実施の形態４では、特定の個人を指名して依頼することを考慮し、連絡先（ログインユーザデータベース）に指名者を設定出来るとともに、体制外のメンバーへも対応依頼を実施する画面を付加した。
【0028】
この実施の形態では、サーバー機にログインユーザ格納処理２３とログインユーザデータベース２４を追加する。事象発生時にユーザを追加する場合は端末２のメッセージ入力手段１２の異常発生通知画面が、図２４に示す「配信先指定」エリアに追加される。「配信先指定」エリアに氏名(ユーザ名等)が入力されると、サーバー機は、図２３に示すログインユーザ格納処理２３により、氏名から体制表データベースを参照する。メンバーが体制表にあれば、所属・ユーザＩＤを得て、所属・ユーザＩＤ・氏名がログインユーザデータベースに登録され（図２５参照）、図４４のログインユーザデータベース内の指名フラグに１を立てる。体制表に氏名登録がないメンバーが入力された場合には、メーカの保守窓口担当者として追加登録し、指定フラグに１を立てる。また、指名されたユーザがログインし、本システムの入力画面が表示された際、入力画面内に“指名有”と表示される（図２５、図２６参照）。
【0029】
実施の形態５．以下、この発明の実施の形態５を図２８に基づいて説明する。
実施の形態１では、異常発生の通知は、ＰＣを用いてキーボードから文字入力されることを想定しているが、異常発見の際の現場状況によっては、手入力手段が使用不可のケースが想定される。そこで、実施の形態５では、事象発生通知を、音声認識手段と音声入力手段で実現する機能を付加した。
【0030】
サーバー機１に音声認識手段２５を追加する。事象発生時に端末２のメッセージ入力手段１２を図４５に示す異常発生通知画面に変更し、音声入力アイコン（図２９参照）を押すと、図３０の処理フローにしたがって音声が取得される。取得した音声は、サーバー機に送信され、音声認識処理にてテキスト変換され、異常通知表管理テーブルに入力される。表示中の画面の入力エリアには、異常通知表管理テーブルに保存されたテキスト情報が表示される。ここで、図２９は音声入力エリアを示す図、図３０は音声認識入力処理のフロー図である。
【0031】
実施の形態６．以下、この発明の実施の形態６を図３１に基づいて説明する。
実施の形態１では、異常発生通知は、事象欄に記載される文字情報だけであるが、異常によっては文字だけでは十分に表現出来ない場合がある。
実施の形態６では、異常発生時の異音や破損状態、あるいは、それらを処置した改修後の状態を効果的に伝達する手段として、音声や画像をファイル形式で添付する機能を付加した。
【0032】
そのため、この実施の形態においては、サーバー機に添付ファイル管理手段２６を追加する。図３２に示すように、異常発生通知画面に “ファイル添付”ＰＢを追加し、このＰＢを押すことで“添付ファイルリスト”を表示する。“添付ファイルリスト”には、タブレット端末で採取した写真や動画、音声データが表示され、“添付ファイルリスト”でファイルを選択して“添付”ＰＢを押すことで、選択されたファイルをサーバー機へアップロードする(図３３に示す「ファイル添付処理」の処理フロー参照)。添付ファイルは、サーバー内のメッセージ番号毎に設けられた“添付ファイル保存フォルダ”に保存される。また、メッセージ番号と添付ファイルとの関連付けは、図４５に示す異常通知管理表データベース６にて管理される。
【0033】
また、端末でも添付ファイルを見られるようにするため、図３５の” 添付ファイル 呼び出し画面”に示すように、各種入力画面に“添付ファイル表示”ＰＢを追加する。“添付ファイル表示”ＰＢを押すことで“添付ファイルリスト”が表示され、サーバー内にメッセージ毎に保存されているファイルが表示される。“添付ファイルリスト”でファイルを選択して“表示”ＰＢを押すことで、選択されたファイルがサーバー機からダウンロードされると、端末上で再生される(図３４に示す「ファイル表示処理」の処理フロー参照)。なお、以上の説明における「端末２」については、図面(図１他)中で個別にはＴ１、Ｔ２、・・・、Ｔｎと記して１台ずつ区別した。
なお、本発明は、その発明の範囲内において、各実施の形態を自由に組み合わせたり、各実施の形態を適宜、変形、省略することが可能である。
【符号の説明】
【0034】
１ サーバー機、２ 端末、３ ネットワーク、４ 体制表データベース、５ 機器担当表データベース、６ 異常通知管理表データベース、
７ 指示票データベース、８ メッセージ配信手段、９ 配信先決定手段、 １０ ユーザＩＤ取得手段、１１ メッセージ表示手段、
１２ メッセージ入力手段、１３ ユーザＩＤ登録手段、
１４ 異常通知管理表、指示票生成手段、１５ 画面ＩＤ取得処理、
２１ 期限超過フォロー手段、２２ 指示順序制御手段、
２３ ログインユーザ格納処理、２４ ログインユーザデータベース、
２５ 音声認識手段、２６ 添付ファイル管理手段、
５１ 資格データベース。