JP2007048192A - 保守計画支援システム - Google Patents

Abstract

【課題】 突発的な障害が発生した場合の保守作業全体の効率を向上させることが可能な技術を提供する。
【解決手段】 突発案件を含む保守計画の作成を支援する保守計画支援システムにおいて、突発的な障害が発生した場合に、その突発案件または突発案件の次の案件として登録した登録済案件に対する評価を行う為の評価関数を用いて、次の案件の候補となる候補案件の評価値を処理装置により算出する評価関数計算部と、前記算出した評価値の良い候補案件を前記突発案件または登録済案件の次の案件として選択して記憶装置に登録する計画立案部とを備えるものである。
【選択図】図２

Description

本発明は設備・機器・コンピュータシステム等の保守及び修理等の作業において、効率的に作業計画を行う保守計画支援技術に関し、特に突発的な故障や障害が発生した場合の保守計画の作成を支援する保守計画支援技術に適用して有効な技術に関するものである。

設備・機器・コンピュータシステム等の継続的な性能維持の為には、定期的或いは稼動時間・ソフトバージョンアップ等に応じた、点検・部品交換・プログラムインストール等を行う事前計画的な保守作業と、突発的な故障や障害に対してその都度対応する修理作業とがある。従来、これら事前計画的な作業に対しては作業の組合せや作業順序を計画する支援システムがあるが、突発的障害の修理・復旧作業はその都度対応するため、事前計画的な作業と突発的作業の組合せは考慮されていなかった。このため俗人的な判断による組合せを行うこともあるが、全体的な観点からはあまり高効率とは言えなかった。

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

前記従来技術の保守計画支援システムでは、設備・機器・コンピュータシステム等の継続的な性能維持の為に必要な保守作業や修理作業を行う際に、事前計画的な作業と突発的作業の組合せは考慮されていなかった為、突発的作業を含む案件に対応する場合、全体的な観点からはあまり高効率とは言えないという問題があった。

本発明の目的は上記問題を解決し、突発的な障害が発生した場合の保守作業全体の効率を向上させることが可能な技術を提供することにある。

本発明は、保守計画の作成を支援する保守計画支援システムにおいて、突発的な障害が発生した場合にその突発案件や登録済案件に対する評価値の良い候補案件を前記突発案件と組み合わせて保守計画を作成するものである。

本発明の保守計画支援システムでは、突発的な障害が発生すると、その突発案件の保守設備から、次の案件の候補となる候補案件の保守設備までの移動距離、それらの保守設備の属するクラスタ（同一設備であるかや同一建物内にあるか等を示すもの）、それらの保守設備の保守に必要な工具の類似性、或いは、それらの保守設備の保守期限までの余裕期間を示す値をパラメータとする評価関数を用いて、前記突発案件に対する候補案件の評価値を算出し、その算出した評価値の良い案件を前記突発案件の次の案件として選択して登録する。そして、突発案件の次の案件として登録した登録済案件と、次の候補案件について同様にして評価値を算出し、その算出した評価値の良い案件を前記登録済案件の次の案件として選択して登録する。その後、前記突発案件と登録した案件の保守作業を行う為の保守計画データとして、ステータス、対応要員や開始予定時刻等の情報を記憶装置に格納して保守計画の策定を行う。

本発明によれば、突発的な障害が発生した場合の保守作業全体の効率を向上させることが可能である。

（実施形態１）
以下に突発案件を含む保守計画の作成を支援する実施形態１の保守計画支援システムについて説明する。

図１は本実施形態の保守計画支援システムのハードウェア構成を示す図である。図１に示す様に本実施形態の保守計画支援システムでは、ＣＰＵ１、メモリ１１、演算プログラム２、データベース３、入出力装置４、プリンタ５、通信装置６がバス１０により結ばれており、通信装置６はネットワークを通じて移動時間計算サービスのサイト７、顧客端末８、保守員端末９と結ばれている。

演算プログラム２としては、全体制御部２１、評価関数計算部２２、距離算出部２３、移動時間把握部２４、案件状況管理部２５、計画立案部２６、保守要員連絡部２７、顧客連絡部２８、及び障害受付部２９の各プログラムがある。また、データベース３としては、保守要員ＤＢ３１、保守案件ＤＢ３２、想定突発案件ＤＢ３３、案件対応状況ＤＢ３４を含んでいる。

全体制御部２１は、保守計画支援処理を行う各部の動作を制御する処理部である。評価関数計算部２２は、突発的な障害が発生した場合に、その突発案件または突発案件の次の案件として登録した登録済案件に対する評価を行う為の評価関数を用いて、次の案件の候補となる候補案件の評価値をＣＰＵ１により算出する処理部である。

距離算出部２３は、保守設備や保守員の位置を示す座標データから保守設備間または保守設備と保守員との間の距離を算出する処理部である。移動時間把握部２４は、通信装置６によりネットワークを介して移動時間計算サービス企業のサイトへアクセスして、特定の座標間の移動時間推定値を前記サイトから受信する処理部である。

案件状況管理部２５は、保守作業の進行状況に伴って保守要員ＤＢ３１中の保守員の座標データや対応中案件情報等の情報を更新して案件状況を管理する処理部である。計画立案部２６は、前記算出した評価値の良い候補案件を前記突発案件または登録済案件の次の案件として選択して記憶装置に登録する処理部である。

保守要員連絡部２７は、通信装置６によりネットワークを介して保守員の携帯する保守員端末９へ突発案件を含む保守作業の実行指示や帰社指示を送信する処理部である。顧客連絡部２８は、通信装置６によりネットワークを介して顧客端末８へ突発案件の作業予定を示す情報等の送信する処理部である。障害受付部２９は、通信装置６によりネットワークを介して顧客端末から突発的な障害が発生したことを示す通知を受信する処理部である。

保守計画支援システムを、全体制御部２１、評価関数計算部２２、距離算出部２３、移動時間把握部２４、案件状況管理部２５、計画立案部２６、保守要員連絡部２７、顧客連絡部２８及び障害受付部２９として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。

図２は本実施形態の保守計画支援システムの機能構成を示す図である。図２に示す様に本実施形態の保守計画支援システムは、演算・制御４０、ＤＢ６０、及び移動時間計算７１、保守員端末７２、顧客端末７３から成り、演算・制御４０は全体制御４１、評価関数計算４２、距離算出４３、移動時間把握５２、保守要員連絡５３、顧客連絡５４、障害受付５５、案件状況管理４５、保守計画立案４６、入出力４７、及び通信５１の各機能より構成される。また、ＤＢ６０は、保守要員ＤＢ６１、保守案件ＤＢ６２、突発案件ＤＢ６３、案件対応状況ＤＢ６４により構成される。

図３は本実施形態の保守計画支援処理全体の処理手順を示すフローチャートである。図１のハードウェア構成と関連付けて図３の流れを説明する。

まずステップ７１で全体制御部２１は、障害受付部２９により顧客端末８からネットワークを通して突発的な障害が発生したことを示す通知を受信しているかどうかを調べ、前記通知を受信している場合には、その受信した通知データから突発案件の内容を示すデータを読み出して受け付ける障害受付を行う。

ステップ７２で障害受付部２９は、前記読み出した案件内容と突発案件ＤＢ６３中の案件内容と比較して該当する想定案件を検索し、その検索された想定案件の緊急度を示すデータを突発案件ＤＢ６３から読み出して前記受け付けた突発案件の緊急度を設定する緊急度設定を行う。本実施形態の例では、緊急度はＡ、Ｂ、Ｃの３段階であるものとし、Ａは営業時間に関係なく直ちに対応する案件、Ｂは営業時間内でなるべく早く対応する案件、Ｃは緊急を要さずある期間内に対応すれば良い案件であるものとする。

次にステップ７３では、突発案件の前記設定した緊急度がどの段階のものであるかを判定する緊急度判定を行い、前記設定した緊急度がＣの案件である場合にはステップ８３へ進み、当該突発案件を計画案件と同等に扱って計画案件への登録を行った後、ステップ８４で顧客連絡部２８は、その旨、ネットワークを通じて顧客端末８への通知を行う。

ステップ７３の緊急度判定で、緊急度ＡまたはＢと判定された場合にはステップ７４へ進み、保守要員ＤＢ６１を参照しながら対応保守員の選択・登録を行う。この保守員の選択・登録については図５を用いて後で説明する。

次にステップ７５では、突発案件ＤＢ６３の必要対応時間（図１１の１７６）と、ステップ７４の対応保守要員選定・登録の中で得られた移動時間を元に、障害対応終了時刻予測を行う。

次にステップ７６では、ステップ７５で得られた終了予測時刻が通常営業時間内であるかどうかを判定する通常営業時間内判定を行い、その終了予測時刻が通常営業時間外である場合、すなわち通常営業時間内に作業が終了しないと判断された場合にはステップ８５へ進み、この突発案件の緊急度を判定する緊急度判定を行う。ここでその突発案件の緊急度がＡである場合、当該突発案件は、通常の営業時間をオーバーしても当日作業を実行する必要のある緊急案件であるため、ステップ８０の当日実行計画策定に進む。またステップ８５の緊急度判定でその突発案件の緊急度がＡ以外、すなわちＢである場合には、ステップ８６で計画立案部２６により当該突発案件を次の営業日案件に登録する処理を行い、ステップ８７で顧客連絡部２８は、その旨ネットワークを通じて顧客端末８への通知を行う。

ステップ７６の通常営業時間内判定で、前記終了予測時刻が通常営業時間内であると判定された場合にはステップ７７へ進み、次の案件の選択・登録を行う。すなわち、突発案件への対応が通常営業時間内に終了すると予想される場合には、保守案件の中から本日実行できる案件を選んで突発案件と組合せて実行する計画を立てることになる。ステップ７７では移動時間等の評価関数を用いて案件の選択を行うが、その詳細は図６及び図７を用いて後で説明する。ステップ７７で次の案件の選択・登録がなされるとステップ７８へ進み、選択時に計算された案件までの移動予測時間と、保守案件ＤＢ６２にある標準作業時間（図９の１５４）とから保守終了時刻を予測する。

次にステップ７９では、ステップ７８で得られた終了予測時刻が通常営業時間内であるかどうかを判定する通常営業時間内判定を行い、その終了予測時刻が通常営業時間内である場合にはステップ７７に戻る。このループを繰り返すことによって、通常営業時間内に収まる保守作業を順次追加していく。

ステップ７９の通常営業時間内判定で終了予測時刻が通常営業時間外と判定された場合にはステップ８０へ進み、計画立案部２６では、突発案件とそれまでにステップ７７で登録された通常営業時間内の案件で当日実行計画策定を行い、それらの案件のステータス、対応要員及び開始予定時刻等の保守計画データを記憶装置内の案件対応状況ＤＢ３４に格納する。ステップ８０の当日実行計画策定が終了すると、顧客連絡部２８は、この計画に関係する顧客端末へ通知すると共に、保守要員連絡部２７は、対応保守員の保守員端末９へ実行指示を行う。

なお、当日実行計画策定では、最終案件が緊急度Ａの場合には、通常営業時間を超えてもその案件を計画に含み、最終案件が緊急度Ａ以外の場合には、これまでに選択された案件の内、通常営業時間内に終了する案件を選択順に並べれば良い。

図５は本実施形態の図３におけるステップ９４の保守員の選択・登録の処理手順を示すフローチャートである。まず最初にステップ１１１で距離算出部２３は、障害装置の位置取得を行う。これは、顧客端末８から送られてきた障害通知に含まれる障害装置の設備コードを元に、対象設備ＤＢ（図８）の設備コード１４１から設備の場所１４４を参照することで行うことができる。この設備の場所は、大まかにはエリア区分１４５により、詳しくは緯度１４６及び経度１４７で知ることができる。

次にステップ１１２で距離算出部２３は、その突発案件の案件タイプに対応可能な保守員の内で障害装置の近くに居る保守員をリストアップする。保守員の位置が障害装置の近くであるかどうかの判定は、障害装置の緯度１４６及び経度１４７と、保守員ＤＢ（図１０）の各要員の現在場所１６３の緯度１６５及び経度１６６から直線距離を計算することにより行う。このリストアップでは直線距離の短い保守員を例えば５人抽出する。

前述の例では、緯度及び経度から直線距離を計算するものとしたが、設備のエリア１４５と保守員の居るエリア１６４が一致する保守員を抽出するものとしても良い。この場合には直線距離を計算する必要が無いので素早く抽出できるが、一致するエリアに保守員が居ない場合には、エリアを拡大する等の措置が必要となる。

次にステップ１１３では、対応可能保守員毎の障害対応への移動開始可能時刻の推定を行う。この実施形態では、保守要員ＤＢの例（図１０）の対応終了予定時刻１６８より推定することができる。

次にステップ１１４で移動時間把握部２４は、抽出した対応可能保守員毎に障害装置への移動時間の推定を行う。この実施形態では、この推定をネットワークを介して移動時間計算サービス企業（図１の７）に委託している。移動時間計算サービス企業では、カーナビゲーションにおける到着時間予測計算プログラム或いは鉄道等の到着時刻計算プログラム等を使用して移動時間を推定することができ、その結果をネットワークを通じて本システムで受信する。

次にステップ１１５では、対応可能者毎に障害装置への到着時刻の推定を行う。この推定は、上記移動開始可能時刻の推定値に、移動時間推定値を加えることで行うことができる。ステップ１１６で計画立案部２６は、以上の推定の結果、最早到着者を対応保守員として選択してその要員Ｎｏ．を案件対応状況ＤＢ３４の対応要員に登録する。

図６は本実施形態の図３におけるステップ７７の「次の案件の選択・登録」の第１の処理手順を示す図である。まず最初にステップ１２１では、現時点で実行可能な計画保守案件のリストアップを行う。リストアップの方法は、図１３を参照しながら後で説明する。

次にステップ１２２で距離算出部２３は、１つ前の案件の場所からの直線距離の計算を行う。この直線距離の計算は、１つ前の案件の緯度・経度と、次の案件の緯度・経度から行うことができる。次にステップ１２３では、直線距離の短い案件を候補案件としてリストアップする。例えば直線距離の短いものから５件を抽出する。続いてステップ１２４で移動時間把握部２４は、ここで抽出した各候補保守案件の場所への移動時間を推定する。この例ではこの推定は図１に示す移動時間計算サービスのサイト７を利用している。ステップ１２５で計画立案部２６は、この移動時間推定の結果を元に、最早到着保守案件を次の保守案件として案件対応状況ＤＢ３４に登録する。

図７は本実施形態の図３におけるステップ７７の「次の案件の選択・登録」の第２の処理手順を示す図である。図７に示す様にステップ１３１の現時点で実行可能な計画保守案件のリストアップからステップ１３３の直線距離の短い案件を候補案件としてリストアップするまでは、前述の第１の処理手順と同じである。この第２の処理手順のステップ１３４で評価関数計算部２２は、評価関数を用いて候補案件の評価を行い、ステップ１３５では、評価結果の最適な案件を次の候補案件として選択して案件対応状況ＤＢ３４に登録する。

評価関数には例えば下記の様なパラメータを使用する。
次の案件までの距離：ｚ（単位ｋｍ）
設備の属するクラスタ：ｙ（同一設備：ｙ＝０、同一ビル内の同一企業：ｙ＝１、同一ビル内の別企業：ｙ＝２、その他：ｙ＝４）
使用工具変数：ｘ（標準工具のみ：ｘ＝０、登録済案件と同一工具グループ：ｘ＝０、新たな準標準工具グループ：ｘ＝１、新たな特殊工具グループ：ｘ＝３）
余裕日数変数：ｗ（図１３の当日１９４から保守期限２０９までの余裕日数２０８）
ここで、ｙは直前に選択された案件の設備と次の案件の設備が同一設備であるかや同一ビル内にあるか等を示しており、対象設備ＤＢ３５の設備コード１４１、顧客コード１４２及び建物コード１４３を比較してｙの設定を行うものとする。またｘについては、その案件で用いられる工具が、標準工具に属するものであるか、登録済案件で用いられる工具と同一の工具分類１５５であるか、準標準工具や特殊工具に属するものであるかに応じて設定する。なお、ある工具が、標準工具、準標準工具または特殊工具のどれに該当するかについては別途定義されているものとする。

評価関数ｅ＝ｆ（ｚ、ｙ、ｘ、ｗ、）は、例えば以下の数１の様な式である。
［数１］
ｅ＝５ｚ＋３ｙ＋３ｘ＋ｗ

ここでは説明を簡単にする為に単純な１次式で示したが、実績データ等を元にもう少し複雑な式としても良い。またパラメータを上記に固定する必要はなく、図６で説明した移動時間を評価関数のパラメータに含める様にしても良い。

ステップ１３５では、上記評価関数で評価値ｅの値が最小となる案件、一般的には評価結果の最適な案件を次の保守案件として選択して登録する。

図８は本実施形態の対象設備ＤＢ３５の例を示す図である。図８に示す様に本実施形態の対象設備ＤＢ３５には、設備コード１４１、顧客コード１４２、建物コード１４３、及び場所１４４としてエリア１４５、緯度１４６、経度１４７等を記録している。設備コード、顧客コード、建物コードについては、評価関数のパラメータ値を求めるときに使用し、エリア、緯度、経度については、案件間距離や案件のエリアの近さを判定するときに使用する。

図９は本実施形態の保守案件ＤＢ３２の例を示す図である。図９に示す様に保守案件ＤＢ３２とは、どの設備に対して何時保守作業を行う必要があるかを一覧にした物である。

このＤＢには案件Ｎｏ．１５１、設備コード１５２、案件タイプ１５３、標準作業時間１５４、工具分類１５５、及び保守可能期間１５６として、開始時期１５７、終了時期１５８等を記録している。案件タイプとは、定期点検であるとか、消耗品交換であるとか、プログラムバージョンアップという様な、案件の分類を表している。案件タイプ、工具分類については、評価関数のパラメータ値を求める時に使用し、標準作業時間については、作業終了時刻を予測するときに使用する。また保守可能期間については、案件候補を抽出する場合に使用する。

図１０は本実施形態の保守要員ＤＢ３１の例を示す図である。このＤＢには要員Ｎｏ．１６１、対応可能案件タイプ１６２、現在場所１６３としてエリア１６４、緯度１６５、経度１６６、更に、対応中案件１６７、対応終了予定時刻１６８等を記録している。対応可能案件タイプは図９の保守案件ＤＢ３２の例の案件タイプ１５３に対応しており、その要員が案件に対応できるかどうかの判定に使用する。現在場所については、突発案件等に要員を引当てる場合の距離の算出に使用し、また、対応終了時刻については、次の案件への到着時刻を推定する場合に移動時間と合わせて使用する。

図１１は本実施形態の想定突発案件ＤＢ３３の例を示す図である。想定突発案件とは、定期的ではなく不定期或いは突発的に発生することが予想される障害等を言う。このＤＢでは想定案件Ｎｏ．１７１、設備コード１７２、案件内容１７３、対応方法１７４、緊急度１７５、必要対応時間１７６等が記録されている。突発案件が発生した場合でも、この想定突発案件ＤＢ３３に登録されている内容の案件であれば、直ちに対応計画を立てることができる。このＤＢの緊急度については、対応計画時の緊急度判定（ステップ７３、ステップ８５）等で使用する。

図１２は本実施形態の案件対応状況ＤＢ３４の例を示す図である。案件対応状況とは、現在対応中または対応予定が組まれている案件の進捗状況のことである。この例では、案件Ｎｏ．１８１、ステータス１８２、対応要員１８３、開始予定時刻１８４、開始時刻１８５、終了予定時刻１８６、終了時刻１８７等が記録されている。このＤＢの終了予定時刻を元に次の案件の開始時刻が推定される。また開始時刻、終了時刻が予定より遅れた場合には、それ以降の予定の修正を行う。

図１３は本実施形態の実施可能案件抽出の例を示す図である。図１３では、図６或いは図７の現時点で実行可能な計画保守案件のリストアップを行う時の、実施可能案件の抽出を表しており、案件Ｎｏ．１９１、エリア１９２、案件タイプ１９３、時間（日付）１９５及びステータス１９６が表示されている。

各案件には図９で示した保守可能期間１５６が有り、それをこの図ではグラフ状に実施可能範囲２０１〜２０６で示している。これに対し、保守等を実施する当日１９４を縦に太線表示すると、当日実施することができる案件（実施可能範囲２０１〜２０４の案件）が判り、割当候補案件を抽出することができる。

以上の様に本実施形態１によれば、保守作業と突発障害への対応とを組合せて作業計画を作成するため、設備の性能維持に必要な作業全体の総合効率向上が図れる。

また、保守作業と突発障害への対応を組合せながらも当日の営業時間を考慮した計画を立てることにより、作業員の効率的割当が行え、また作業員への精神的負担を軽減することができる。また距離及び移動時間を考慮した計画を立てることにより全体作業時間の把握精度が向上すると共に移動時間の少ない案件の組合せが計画できる。また、保守設備の同一性、保守設備の所属する企業の同一性、保守設備のある建物の同一性、保守に必要な工具の類似性、を考慮した計画を立てることにより作業効率の高い案件組合せ計画を立てることができる。また、保守期限までの余裕期間を考慮した計画を立てることにより、余裕期間の少ない案件を優先して計画することができ、余裕期間のある案件が後に残るため当日以降の計画の自由度が向上する等の効果がある。

以上説明した様に本実施形態の保守計画支援システムによれば、突発的な障害が発生した場合にその突発案件や登録済案件に対する評価値の良い候補案件を前記突発案件と組み合わせて保守計画を作成するので、突発的な障害が発生した場合の保守作業全体の効率を向上させることが可能である。

（実施形態２）
以下に次の案件のみをその都度、実行指示し、その案件が終了した後に次の案件の選択・登録を行う実施形態２の保守計画支援システムについて説明する。

図４は本実施形態の保守計画支援処理全体の処理手順を示すフローチャートである。実施形態２のハードウェア構成は、図１に示すものであり、実施形態１と同じである。図４のフローチャートが実施形態１のフローチャート図３と異なる部分である。

図４において全体制御部２１は、ステップ９１で顧客端末８から障害受付を行うと、次にステップ９２で緊急度設定を行う。次にステップ９３で緊急度判定を行い、緊急度がＣすなわち緊急に対応する必要がない場合には、ステップ１０４で計画案件として登録し、ステップ１０５で顧客連絡部２８は、その旨顧客端末に通知する。

ステップ９３の緊急度判定で緊急度がＡまたはＢの場合にはステップ９４で保守員の選択・登録を行い、ステップ９５で障害対応終了時刻の予測を行う。ステップ９６では、この予測時刻について通常営業時間内判定を行い、通常営業時間内でない場合にはステップ１０６で再び緊急度判定を行う。緊急度がＢの場合にはステップ１０７で次の営業日案件に登録し、ステップ１０８で顧客連絡部２８は、その旨顧客端末へ通知する。

ここまでは実施形態１と同じである。次に、ステップ９６の通常営業時間内判定で時間内であった場合と、ステップ１０６の緊急度判定でＡと判定された場合には、ステップ９７で顧客連絡部２８は、顧客端末へ通知して、ステップ９８で保守要員連絡部２７は、対応保守員端末へ実行指示を出す。その後、対応保守員による作業が終了すると、ステップ９９では、保守員端末９からの終了報告受付を行う。終了報告を受け付けるとステップ１００で次の案件の選択・登録を行う。次の案件の選択・登録の詳細は図６または図７に示すものであり、実施形態１の場合と同じである。

その後、ステップ１０１でその案件の保守終了時刻の予測を行い、ステップ１０２で通常営業時間内の判定を行う。ステップ１０２の通常営業時間内の判定で通常営業時間外となった場合、ステップ１０３で保守要員連絡部２７は、対応保守員端末へ帰社指示を行い対応保守員は当日の作業を終了する。

ステップ１０２の通常営業時間内の判定で通常営業時間内と判定された場合には、ステップ９７の顧客端末への通知に戻り、ステップ９７で顧客連絡部２８は、登録された案件をその顧客端末へ通知し、このループを繰り返す。以上により、突発的障害と計画可能保守案件とを組合わせて当日の対応案件を効率良く実施することができる。

実施形態１では各案件の終了時刻を予め予測してステップ８０の当日実行計画策定を行った後、ステップ８２でまとめて保守員への実行指示を行ったのに対し、実施形態２では次の案件のみをその都度、ステップ９８で実行指示し、その案件が終了した後にステップ１００の次の案件の選択・登録を行う点が異なっている。実施形態１ではまとめて計画を立てるため、顧客に事前に連絡できるという効果があり、実施形態２では、実際に作業が終了した後に次の計画を立てる為に、時刻の予測が比較的正確になるという効果がある。

実施形態１の保守計画支援システムのハードウェア構成を示す図である。 実施形態１の保守計画支援システムの機能構成を示す図である。 実施形態１の保守計画支援処理全体の処理手順を示すフローチャートである。 実施形態２の保守計画支援処理全体の処理手順を示すフローチャートである。 実施形態１の図３におけるステップ９４の保守員の選択・登録の処理手順を示すフローチャートである。 実施形態１の図３におけるステップ７７の「次の案件の選択・登録」の第１の処理手順を示す図である。 実施形態１の図３におけるステップ７７の「次の案件の選択・登録」の第２の処理手順を示す図である。 実施形態１の対象設備ＤＢ３５の例を示す図である。 実施形態１の保守案件ＤＢ３２の例を示す図である。 実施形態１の保守要員ＤＢ３１の例を示す図である。 実施形態１の想定突発案件ＤＢ３３の例を示す図である。 実施形態１の案件対応状況ＤＢ３４の例を示す図である。 実施形態１の実施可能案件抽出の例を示す図である。

符号の説明

１…ＣＰＵ、２…演算プログラム、３…データベース、４…入出力装置、５…プリンタ、６…通信装置、７…移動時間計算サービスのサイト、８…顧客端末、９…保守員端末、１０…バス、１１…メモリ、３１…保守要員ＤＢ、３２…保守案件ＤＢ、３３…想定突発案件ＤＢ、３４…案件対応状況ＤＢ、３５…対象設備ＤＢ、２１…全体制御部、２２…評価関数計算部、２３…距離算出部、２４…移動時間把握部、２５…案件状況管理部、２６…計画立案部、２７…保守要員連絡部、２８…顧客連絡部、２９…障害受付部、４０…演算・制御、４１…全体制御、４２…評価関数計算、４３…距離算出、４５…案件状況管理、４６…保守計画立案、４７…入出力、５１…通信、５２…移動時間把握、５３…保守要員連絡、５４…顧客連絡、５５…障害受付、６０…ＤＢ、６１…保守要員ＤＢ、６２…保守案件ＤＢ、６３…突発案件ＤＢ、６４…案件対応状況ＤＢ、７１…移動時間計算、７２…保守員端末、７３…顧客端末、１４１…設備コード、１４２…顧客コード、１４３…建物コード、１４４…場所、１４５…エリア、１４６…緯度、１４７…経度、１５１…案件Ｎｏ．、１５２…設備コード、１５３…案件タイプ、１５４…標準作業時間、１５５…工具分類、１５６…保守可能期間、１５７…開始時期、１５８…終了時期、１６１…要員Ｎｏ．、１６２…対応可能案件タイプ、１６３…現在場所、１６４…エリア、１６５…緯度、１６６…経度、１６７…対応中案件、１６８…対応終了予定時刻、１７１…想定案件Ｎｏ．、１７２…設備コード、１７３…案件内容、１７４…対応方法、１７５…緊急度、１７６…必要対応時間、１８１…案件Ｎｏ．、１８２…ステータス、１８３…対応要員、１８４…開始予定時刻、１８５…開始時刻、１８６…終了予定時刻、１８７…終了時刻、１９１…案件Ｎｏ．、１９２…エリア、１９３…案件タイプ、１９４…当日、１９５…時間（日付）、１９６…ステータス、２０１〜２０６…実施可能範囲、２０８…余裕日数、２０９…保守期限。

Claims (5)

1. 突発案件を含む保守計画の作成を支援する保守計画支援システムにおいて、
   突発的な障害が発生した場合に、その突発案件または突発案件の次の案件として登録した登録済案件に対するパラメータの値を含む評価関数を用いて、次の案件の候補となる候補案件の評価値を処理装置により算出する評価関数計算部と、前記算出した評価値の良い候補案件を前記突発案件または登録済案件の次の案件として選択して記憶装置に登録する計画立案部とを備えることを特徴とする保守計画支援システム。
2. 前記計画立案部は、前記選択した案件の保守終了時刻の予測値が営業終了時間内である場合に当該案件の保守計画データを記憶装置に格納するものであることを特徴とする請求項１に記載された保守計画支援システム。
3. 前記評価関数計算部は、評価関数のパラメータとして保守設備への移動距離を用いるものであることを特徴とする請求項１または請求項２のいずれかに記載された保守計画支援システム。
4. 前記評価関数計算部は、評価関数のパラメータとして、保守設備の属するクラスタ、保守に必要な工具の類似性、或いは、保守期限までの余裕期間を用いるものであることを特徴とする請求項１乃至請求項３のいずれか１項に記載された保守計画支援システム。
5. 保守対象となる設備の座標データを対象設備ＤＢに保持し、保守案件間の移動距離を前記座標データを基に算出することを特徴とする請求項３に記載された保守計画支援システム。
   

Images