JP2007042147A - ビル群管理サ−ビス支援システム - Google Patents

Abstract

【課題】保守対象の設備機器の管理結果や利用者の意見をも反映させ、ビルを群として管理する場合のスケ−ルメリットを活用して、ライフサイクルコストを最小にする。
【解決手段】複数の保守対象からなるビル群に対して、保守対象毎に保守を実施する複数の保守事業者の作業を、設備を所有する設備所有者からの委託で、当該設備を設備管理者が計算機を利用して管理する。計算機には、入力されたビル設備の運行状況やサ−ビス特性を示す所定のパラメ−タ数の第一の状態デ−タを、デ−タが表現する当該運行状況の特性を保持しつつこのパラメ−タ数を削減した第二の状態デ−タに変換する変換手段と、第二の状態デ−タにおけるパラメ−タにより指示値が入力されたとき、指示値に最も近い第二の状態デ−タを持つ設備を特定し得る情報を出力する演算手段とを備えている。
【選択図】図１

Description

本発明は、ビル群管理サ−ビス支援システムに係り、特に、オフィスやマンションなどの複数のビルに対して設備や建物を統合的に管理するのに好適なビル群管理サ−ビス支援システムに関する。

複数のビルの管理情報を扱うものとしては、特開平５−２４４６６１号公報に記載されているビル群の施設管理システムのように、ビル群を複数の地区に分割し、各地区ブロックをセンタにネットワ−ク結合することにより、効率的な管理を可能にしたものが知られている。

一方、株式や債権などの金融商品の市場では、投資信託のように、証券会社などが複数の金融商品を、組み合わせをファンドして投資者に販売し、運用会社が予め定められた方針により運用し、個々の金融商品やファンドのパフォ−マンスは格付け会社が公表するといった事業が実施されている。これをシステム的にサポ−トするものとして、例えば特許文献１に記載されている総合ポ−トフォリオ計画システムにおいては、個々の投資者のライフプランやリスク受容レベルを反映させて、最適な金融商品の組み合わせを計画することができる。

特開平１１−１１０４４７号公報

従来では、ビル設備は機器種別毎に保守事業者が異なっており、数多くの保守事業者が存在する。そのため、ビル所有者にとって、多くの候補の中から最適な保守事業者を選出することは困難な作業であった。また設備所有者から設備全体の運用管理を受託して、必要な保守事業者を選定して管理する設備管理者も存在しているが、設備所有者から見ると保守事業者の選定がいかなる基準で実施されたか不透明であるという問題点があった。

設備の保守サ−ビスを管理するためには、前記総合ポ−トフォリオ計画システムのような金融の手法をそのまま利用することはできない。金融商品の場合には、その商品の価格だけで評価ができるのに対して、保守サ−ビスの評価は価格だけでは判断できず、評価が困難なためである。保守サ−ビスを評価するためには価格以外にも、保守された設備自体の状態を把握すること、または設備を利用したユ−ザの意見も把握することが重要となる。

また、従来では、ビル群のライフサイクルコストの最小化するためのサ−ビス支援システムが無いことが挙げられる。ビルは数十年の長期にわたり使用するので、保守費や修繕費などのライフサイクルコストは膨大であり、その削減が強く求められている。特に外壁の補修など大規模修繕では、高額な費用が発生するので、補修のためのサ−ビスの運用を高度化し、コストを押さえることが必要である。従来のビル群管理システムではビル群に対する情報管理の一元化が図られていたが、管理サ−ビスの運用最適化までは考慮されていなかった。

本発明の目的は、保守対象の設備機器の管理結果や利用者の意見をも反映させ、ビルを群として管理する場合のスケ−ルメリットを活用して、ライフサイクルコストを最小にするビル等の群管理サ−ビス支援装置を提供することにある。

本発明は、計算機を備えたビル群管理サ−ビス支援システムであって、前記計算機は、入力されたビル設備の運行状況やサ−ビス特性を示す所定のパラメ−タ数の第一の状態デ−タを該デ−タが表現する当該運行状況の特性を保持しつつ当該パラメ−タ数を削減した第二の状態デ−タに変換する変換手段と、当該第二の状態デ−タにおけるパラメ−タにより指示値が入力されたとき、当該指示値に最も近い当該第二の状態デ−タを持つ設備を特定し得る情報を出力する演算手段とを備えたことを特徴としている。

また本発明は、計算機を備えたビル群管理サ−ビス支援システムであって、ビルの設備の利用者に対するアンケ−ト結果のデ−タを基に当該ビルの設備の評価状況を示す所定のパラメ−タ数の第一の状態デ−タを生成する手段と、当該第一の状態デ−タが表現する当該評価状況の特性を保持しつつ当該パラメ−タ数を削減した第二の状態デ−タに変換する手段と、当該第二の状態デ−タにおけるパラメ−タにより指示値が入力されると、当該第二の状態デ−タを持つ設備を特定し得る情報を演算し出力する手段とを備えたことを特徴としている。

好ましくは、第一の状態デ−タについて管理を約束する範囲として上限値と下限値を予め設定し、前記第一の状態デ−タの現在の値、当該下限値、及び当該上限値を出力することを特徴としている。

本発明のビル群管理サ−ビス支援システムによれば、保守対象の設備機器の管理結果や利用者の意見をも反映でき、ビルを群として管理する場合のスケ−ルメリットを活用して、ライフサイクルコストを最小にするビル等の群管理サ−ビスが行える極めて大きな効果がある。

本発明のビル群管理サ−ビス支援システムでは、複数の保守対象からなるビル群に対して、保守対象毎に保守を実施する複数の保守事業者の作業を、設備を所有する設備所有者からの委託で、当該設備を設備管理者が計算機を利用して管理している。

以下に図面を参照して、本発明の実施の一形態について、詳細に説明する。図１は、本発明による計算機システムを利用したビル群管理サ−ビス支援システムの全体構成を説明する図である。

１は計算機を用いたビルの管理者装置端末であり、作業群管理、工程群管理、診断群管理、配送群管理、営業群管理、調達群管理などのサブシステムから構成される。２はビルの所有者の端末、３はビルの利用者あるいは居住者の端末である。４は事業者Ａ、Ｂ、Ｃ、Ｄの端末で、保守の場合では警備、清掃、空調、昇降機などの保守事業者、修繕の場合ではとび、左官、塗装、電気、水道、ガスなどの工事事業者が相当する。さらに５は営業担当者の端末、６は診断担当者の端末、７は調達担当者の端末、８は配送担当者の端末である。これらの各端末も計算機により構成されており、管理者装置端末１と各端末は通信ネットワ−クを介して接続されている。

本システムでは、例えばビル１からビル６のようなビル群を扱う場合を対象に、管理サ−ビスを支援する。１１は作業群管理のサブシステムで、保守や修繕の事業者４のサ−ビス特性を評価し、ビル所有者が管理意図に従って、提示される保守プランの中から最適な事業者の組み合わせを選択できる。１２は工程群管理サブシステムで、本来はビル毎に異なるビルの修繕の時期を最適なタイミングで同期させ、同期化工程として出力する。

１３は診断群管理のサブシステムで、エレベ−タや空調などの設備の遠隔監視装置や、建築専門家による建物診断などを管理する。ここでも各ビルに対する診断の時期は共通化し、その診断情報は共同診断デ−タベ−スに格納する。１４は配送群管理サブシステムで、作業群管理によりサ−ビスする事業者の組み合わせは決定しているので、同じ保守プランであれば何れのビルでも事業者は同一であり、配送作業を共同化できる。保守や修繕の作業に使用する資材を、各事業者毎に各ビルに配送するのでなく、例えば共通の車両で配送する。このような配送を管理するのための情報が共同配送デ−タベ−スである。

１５は営業群管理サブシステムで、事業者が共通であることを利用して営業の窓口も一本化を図るものである。ビルの所有者や利用者からの問合せや引き合いは、電話やメ−ルなどの各種チャネルを通じて、一括してコ−ルセンタに寄せられ、その情報が共同営業デ−タベ−スに登録される。１６は調達群管理サブシステムで、ここでも同一の保守プランでは同一の仕様で作業するので、調達する資材も共通のものとなる。そこで全てのビルに対する資材は、ここでまとめて発注し調達する。この調達のための情報が、共同調達デ−タベ−スである。

次に、以下では作業群管理サブシステム、及び工程群管理サブシステムの詳細について説明する。図２は、本発明の実施形態における作業群管理サブシステムの概略を説明する図である。

本発明では、設備の運行管理を実施する設備管理者の管理者装置１、設備を所有する設備所有者の所有者端末２、設備を利用する設備利用者の利用者端末３、及び設備管理者からの保守委託を受けて設備の維持を実施する保守事業者の事業者端末４とから構成される。本発明での処理とは、設備管理者が保守プランを提示して、設備所有者が保守プランを選択することである。

ここで、保守プランとは保守または修繕の事業者の組み合わせを示すものである。例えばビルの設備保守においては、警備が設備Ａ、清掃が設備Ｂ、空調が設備Ｃ、昇降機が設備Ｄなどというように対応する。ただし、実際には警備や清掃のような業務では、特定の設備機器の保守だけには限定されない場合もある。

そして、設備Ａに関しては保守事業者Ａ１、Ａ２及びＡ３が存在し、同様に設備Ｂには保守事業者Ｂ１、Ｂ２、及び３が、設備Ｃには保守事業者Ｃ１、Ｃ２及びＣ３が、及び設備Ｄには保守事業者Ｄ１、Ｄ２及びＤ３が存在するものとする。ここで各保守事業者のサ−ビスの特性を評価して、この例では３つの保守プランに分類している。

同図で、たとえばプラン１はコストを重視しＡ２−Ｂ１−Ｃ２−Ｄ１というコストの易い保守事業者を組み合わせたコスト重視型保守プランであり、プラン２は品質を重視してＡ１−Ｂ３−Ｃ１−Ｄ２という品質に定評の有る保守事業者を組み合わせた品質重視型保守プランであり、プラン３はコストと品質のバランスを考慮してＡ３−Ｂ２−Ｃ３−Ｄ３という保守事業者を組み合わせたバランス型保守プランである。この例では、設備所有者は保守プラン１を選択し、その結果として、その組み合わせにある保守事業者に保守が委託されている。

図３は、本発明によるシステムの手続きの概略を説明する図である。同図は関係者間の手続きの順序を時間経過と共に示すもので、図の下方に向かって時間は経過している。まず、管理者装置は端末事業者との間で、サ−ビス評価処理（７０１）を実施する。これは事業者端末の過去のサ−ビス内容を評価する手続きである。次に、管理者装置と所有者端末との間で、７０１の評価結果に基づいて保守プランの提案及び保守プラン選定処理（７０２）が行われる。管理者装置はコスト、工期、品質な、サ−ビス等種々の観点で作成されたすべての保守プランを所有者端末に提示し、その中から所有者端末が希望条件にあった保守プランの選択をする。そして７０２の選定結果に応じて、管理者装置と事業者端末との間で保守作業依頼処理（７０３）が実施され、実際の保守作業が開始する。

管理者装置と利用者端末の間で行われる利用者アンケ−ト処理（７０４）は、実施された保守サ−ビスの内容を評価するために行なうものである。サ−ビスの評価には他にも設備機器からの故障情報なども考慮され、その結果を元に事業者端末と管理者装置の間でサ−ビス再評価処理（７０５）が実施される。その後７０５の結果に基づき、管理者装置と所有者端末の間で保守結果報告処理（７０６）が実施される。そして、利用者端末と所有者端末の間で利用費支払処理（７０７）、所有者端末と管理者装置の間で管理費支払処理（７０８）、及び所有者端末と事業者端末の間で保守費支払処理（７０９）が行われ、一連の取引処理が終了する。

図４は、本発明によるシステムの構成を説明する図である。管理者装置（１０）は、一般にはパソコンなどであり、ディスプレイなどの表示及び出力部、キ−ボ−ドやマウスなどの入力部、及びネットワ−クを介して他の端末などからのアクセスが可能なサ−バから成る。所有者端末（２）、利用者端末（３）、事業者端末（４）も一般にはパソコンなどで、１０と同様な表示及び出力部、及び入力部とから成る。設備機器（５０）は保守作業の対象となる設備で、内部にはネットワ−ク接続部を有し、機器が自己診断した結果などの保守情報をネットワ−ク上に送出できる機能を持つものもある。また設備機器によっては、液晶ディスプレイなどの表示及び出力部、タッチパネルなどの入力部などを有するものもある。本発明ではすべての管理情報は１０のサ−バに記録され、その情報を参照しつつ、処理が進められる。

図５、図６及び図７は、本発明による作業群管理サブシステムのシ−ケンス図である。また図８は管理者装置のサ−バ内におけるデ−タファイルの説明図である。次に、このシ−ケンス及びデ−タファイルの説明図を用いて処理の詳細を説明する。シ−ケンス１０１では事業者端末が管理者装置に保守実績デ−タを提出する。このデ−タは当該事業者が過去に実施したサ−ビス内容の実績を示すもので、その情報はシステムにより保守事業者の調査結果ファイル（５０４）のサ−ビス内容の項目として記録される。

シ−ケンス２０１は、管理者装置が保守事業者の初期評価をするシ−ケンスで、５０４の記録を参照して、保守事業者のサ−ビスの格付けを行なう。たとえばサ−ビスを幾つかのランクに分けて、分類した結果はシステムにより保守事業者の評価ファイル（５０５）のサ−ビス評価の項目として記録される。

シ−ケンス２０２では、管理者装置が、保守事業者の初期組み合わせを決定する。これは２０１の評価結果から各保守事業者のサ−ビスの特性を把握し、特性別にいくつかの保守プランを考え、その保守プランを構成するのに最適な保守事業者の初期の組み合わせを決定する。この決定結果は、システムにより保守事業者の組み合わせファイル（５０６）の保守プランの項目として記録される。このプランの例として、コストを重視したプラン、性能を重視したプラン、すべてに平均的なプランなどを管理者装置は用意する。

シ−ケンス２０３では、管理者装置が所有者端末に、保守プランを提示する。ここではシステムにより５０６の保守プランが示される。シ−ケンス３０１では、所有者端末が、保守プランの選択をする。この保守プランの選択は、設備所有者が個々の設備管理意図に応じて決めることができる。プランが選択されると、システムにより保守プラン契約者ファイル（５０７）に、選択した設備所有者名が記録される。

シ−ケンス２０４では、管理者装置が選択された保守プランに基づき、保守事業者を指定し、当該保守事業者に対して保守作業を依頼する。シ−ケンス１０２では、指定された事業者端末が設備の保守作業を指示する。シ−ケンス２０５では、管理者装置が、１０２で実施された保守作業結果の調査を行なう。この調査結果はシステムにより、保守事業者の調査結果ファイル５０４に対して、シ−ケンス１０１で記録された保守実績デ−タに追記した形で記録される。

シ−ケンス２０６では、管理者装置が、設備からの保守情報を取得する。先述のように設備機器５０は、保守情報を送出できるので、そのデ−タは１０のサ−バ内に自動記録される。そのデ−タとは、各設備の運行デ−タファイル（５００）のようなもので、故障時刻や故障内容といった項目で保守情報が記録される。シ−ケンス２０７では、管理者装置から利用者端末に、利用者アンケ−トが依頼される。これは設備を利用した際の満足度などを、アンケ−トにより計測するためである。

シ−ケンス４０１では、利用者端末から管理者装置に、利用者アンケ−トにつき回答する。この回答結果はシステムにより、利用者アンケ−トファイル（５０２）の評定値及びコメントの項目として記録される。ここで評定値とは、アンケ−トの質問に関して、大変そう思う：５点、ややそう思う：４点、普通：３点、あまりそう思わない：２点、全くそう思わない：１点などのように点数付けされた値である。またコメントとは自由な文章で記述されたテキストのデ−タである。

シ−ケンス２０８では、管理者装置が、保守サ−ビスを再評価する。ここでは設備の運行デ−タファイル５００の内容から、設備管理者は設備の運行状態を分析・評価し、そのランク付けされた結果はシステムにより運行デ−タ分析結果ファイル（５０１）の設備運行評価の項目に記録される。また利用者アンケ−トも設備管理者が分析し、同じくランク付けされた結果はシステムによりアンケ−ト分析結果ファイル（５０３）の利用者評価の項目として記録される。シ−ケンス２０９では、２０８により保守事業者の評価に変更があった場合のみシ−ケンス２１０に進むことを示している。変更がない場合にはシ−ケンス２１２に進む。

シ−ケンス２１０では、管理者装置が、保守事業者の評価値を変更する。変更された評価値は、システムにより保守事業者の評価ファイル５０５の内容の書き換えが行なわれる。シ−ケンス２１１では、管理者装置が、保守プランにおける保守事業者の組み合わせを変更する。変更された組み合わせは、システムにより保守事業者の組み合わせファイル５０６の内容の書き換えが行なわれる。シ−ケンス２１２では、管理者装置が所有者端末に対して実施した保守作業とその評価についての報告を行なう。シ−ケンス４０２では、利用者端末が所有者端末に対して、設備の利用費を支払う処理をする。

シ−ケンス３０２では、所有者端末が管理者装置に対して、設備の管理費を支払う処理をする。シ−ケンス３０３では、所有者端末が事業者端末に対して、設備の保守費を支払う処理をする。以上により設備管理の１サイクルは終了し、次のサイクルとして、シ−ケンス２０３に再び進むこととなる。

図９は入出力の画面例で、所有者端末の一画面を示す。この画面はシ−ケンス３０１での状態である。保守サ−ビス組み合わせ表示部（６０２）は、保守事業者組み合わせファイル５０６の内容から、保守事業者の組み合わせを表示する。総合評価表示部（６０３）は、５０６及び保守事業者の評価ファイル５０５の内容から、保守プランの総合評価を判定して表示する。保守プラン選択部（６０１）は、設備所有者がプランを選択するもので、ここではコスト重視プランが選択されている。さらに利用者評価表示部（６０４）は、そのプランに関する付加情報として、アンケ−ト分析結果ファイル５０３の内容から、利用者の評価結果を表示する。また設備運行評価表示部（６０５）は、運行デ−タ分析結果ファイル５０１の内容から、設備の運行結果を評価したものとして表示がされる。

以上の実施例においては、設備管理者が保守事業者のサ−ビスを評価したうえで作業を依頼していたが、独立した第三者である評価事業者が保守サ−ビスの評価を専門に実施することも可能である。本実施例によれば、作業の依頼と評価の担当を分離されるので、不正な評価を防止することが可能で、設備管理の取引の透明性を更に高めることができる。

以上の実施例においては、保守事業者は単一のサ−ビス特性を備えていたが、保守事業者は複数の異なるサ−ビス特性を提供することも可能である。本実施例によれば、同一の保守事業者が設備所有者や設備利用者のニ−ズに応じたサ−ビスを提供できるので、設備所有者の選択の幅が広がる、あるいは保守事業者の参入の機会が増えるといった効果がある。

以上の実施例においては、保守事業者は単一の設備のみ保守しているが、保守作業員の多能工化を進めることなどにより、同一の保守事業者が複数の設備を保守することも可能である。本実施例によれば、同一時期に複数の設備の保守が可能となるので、保守費のコストダウンが可能となる効果がある。

以上の実施例と異なり、保守や修繕の事業者のサ−ビスの特性を評価することは、統計学の手法を用いることでも可能である。本実施例においては、設備の運行結果や利用者のアンケ−ト結果に統計の主成分分析手法を適用して、サ−ビスの評価及び選択の手段を提供する方法を説明する。

図１０は設備運行デ−タで、図示したのはエレベ−タの遠隔監視装置が管理している情報の一例である。この例では、ＴＡやＴＢなどは管理している個々のエレベ−タを指し、それぞれについて走行時間や走行距離など２６の項目について計測し、その値を管理している。例えばＸ１Ａはエレベ−タＴＡの走行時間であり、Ｘ２Ｂはエレベ−タＴＢの走行距離である。これらの情報は管理者装置のサ−バ内の運行デ−タ分析結果ファイル５０１の一部の情報として、遠隔監視装置から記録される。

また、図１１は利用者アンケ−トの一例である。これは待ち時間や乗車時間など、２１の項目についてエレベ−タの利用者にサ−ビス評価をしてもらうために用いるものである。評定値は１から５までの範囲であり、この評定値は利用者アンケ−トファイル５０２の内容として記録する。

図１２は以上述べた全てのアンケ−ト結果を集計した例であり、ＰＡやＰＢなどはアンケ−トに回答した個々の評価者を示し、例えばＹ１Ａは評価者ＰＡが評価した待ち時間の評定値、Ｙ２Ｂは評価者ＰＢが評価した乗車時間の評定値で、ここではすべての評定値は１から５の値である。

図１３は、公知の主成分分析手法の簡単な説明図である。例えば図１０の設備運行デ−タは２３の評価項目があるので、この原デ−タは２３の次元を持つ。このデ−タに対して主成分分析を適用すると、例えば第一主成分Ｕ１、第二主成分Ｕ２及び第三主成分Ｕ３のような３つの主成分を抽出できる。この例では、本来は２３次元の変数を３次元で表現できることを意味している。もとの変数の２３次元の空間軸の中で類似したものを統合して３次元に圧縮しているので、もとの変数のデ−タが有する特性も保存される。そして、各主成分ともとの変数との相関係数から判断して、例えばＵ１には高速性、Ｕ２は安定性、Ｕ３は操作性のように設備管理者が命名する。本実施例においては、こうして抽出された主成分を、サ−ビス選択のユ−ザ−インタ−フェ−スとして利用する。

図１４は、端末での主成分操作の画面例である。この例では、昇降機に対する保守サ−ビス特性を、利用者評価の結果としてＶ１及びＶ２という２つのパラメ−タで、設備運行評価の結果としてＵ１、Ｕ２及びＵ３という３つのパラメ−タで表現している。合計で５つのパラメ−タでサ−ビスを評価した結果がウインドウ６０２の内容で、Ｄ１社、Ｄ２社及びＤ３社という３つの事業者のサ−ビスの評価結果が図示されている。これに対して設備所有者が、設備の運用意図に応じてシステムに値を入力するのが利用者評価の入力ウインドウ６０４及び設備運行評価のウインドウ６０５である。

図示した例ではスライダ−を使ってパラメ−タの値を入力している。例えば設備所有者が応答性や高速性を重視するのであれば、スライダ−で大きな値を設定すれば良い。スライダ−で値が設定されると、ウインドウ６０２のサ−ビス特性の評価結果と比較され、最も差の少ないものがおすすめの保守プランとして表示される。本実施例によれば、主成分分析の結果を用いているので、サ−ビスの特性を少ない数のパラメ−タにより表示でき、また設備所有者の意図もスライダ−操作などで入力できるので、操作性の良いユ−ザ−インタ−フェ−スを提供できる効果がある。

上記実施例においては、運用意図の入力やサ−ビス選択の画面は、所有者端末２における操作のために利用していたが、この情報を利用者端末３に表示させることも可能である。例えば賃貸マンションの場合では、マンションオ−ナの運用意図がマンション居住者の住宅内の端末に表示されることとなる。本実施例によれば、設備所有者の運用意図を設備利用者に広く周知できるという効果がある。

上記実施例と異なり、運用意図の入力やサ−ビス選択の画面は、設備機器５０に表示させることも可能である。例えばエレベ−タにはかご内に液晶ディスプレイを備えたものがあり、ここに同じく運用意図を表示することができるので、上記と同様に設備所有者の運用意図を設備利用者に広く周知できるという効果がある。

また、主成分分析は、複数種類の保守サ−ビスを評価することにも応用できる。例えば警備、清掃、空調、昇降機といった異なるサ−ビスを評価するためには、設備運行デ−タや利用者アンケ−トの項目を共通に評価できる内容とすれば良い。例えば図１５の設備運行デ−タでは、稼働時間や故障時間といった各保守サ−ビスに共通的な内容としている。図１６の利用者アンケ−トにおいても、騒音や振動といった共通の内容を評価項目としている。同様に図１７は利用者評価デ−タで、図１６を集計した結果である。この場合の画面例は図１８のようなものとなる。図１４の場合と同様にして、ユ−ザがスライダ−で評価値を指定すると、それとの差が最も小さい保守事業者が算出される。この例では、警備、清掃、空調及び昇降機のそれぞれについて、おすすめとなる事業者が表示される。

上記の実施例においては、設備の運用意図を入力すると、それに適切な保守事業者が表示されるが、図２３のように保守のサ−ビスレベルを表示することも可能である。ここでのサ−ビスレベルとは保守事業者が満足する必要のある契約上の条件である。例えば図１４の例では、設備運行評価６０５でのサ−ビス特性の指定値に対して、Ｄ１社のサ−ビスが最も近いとしている。そこでＤ１社が保守したエレベ−タについて、図１０のような設備運行デ−タを調べると、同図の例では２３個のパラメ−タの値を求めることができる。ここで求めたパラメ−タ値に対して、下限値と上限値を設定して、所定のパラメ−タ値が一定の範囲内にあることをサ−ビスレベルとして保守事業者が保証する。ここでは図１０のデ−タからドア開閉加速度と着床誤差と速度変動をサ−ビスレベルのパラメ−タとして選んでいる。この３つのパラメ−タにつき、現在の運行における値を現状値として示し、これが下限値と上限値の間にあれば、保守事業者が約束したサ−ビスレベルが満足されているものとする。この画面は設備所有者、保守事業者、設備利用者または設備機器に表示する。

本実施例によれば、保守のサ−ビスレベルが開示され、かつ現状の状態が約束の範囲内にあることを誰もが確認できるので、保守の費用負担に対する理解が得やすくなるという効果がある。

以降では、工程群管理のサブシステムについて説明する。図１９はビルの修繕モデルの説明図である。同図のグラフはビルの新築時からの経過年数と、ビル評価額との関係を示している。ビルは新築時には一定のビル評価額が与えられるが、建物や設備は劣化するので、修繕しない場合には点線で示すように評価額は減少する。この評価額の減少を回復するための手段が修繕で、外壁の補修や屋上の防水などといった大掛かりなものは大規模修繕と呼ばれる。修繕にも耐用年数はあるので、大規模修繕も１０年や２０年に一回というサイクルで繰返し実施する。ビルのライフサイクルを管理する上では、この修繕を適切に施すことにより、ビルの寿命を長く、かつビルの評価額を高い水準に維持することが重要となる。

図２０は修繕モデルをベ−スに、修繕時期を調整するためのモデルである。ビルを群管理する上では、修繕の時期を一致させたほうがコストダウンの効果が大きい。そのために着工時期の調整を、このモデルで行なう。いま、あるビルを診断した結果として、そのビルの評価額は１年あたりＤｅ（Ｄｅは正数）だけ下落しており、Ｍ年後には修繕が必要で、その修繕コストはＲＰ、その修繕の耐用年数はＣＹ年であるとする見積りが得られたものとする。ただし、ここでは修繕コストは評価額の回復に１００％反映されるとしている。

まず今回の修繕について、前倒しする場合にはビルの劣化が進んでいないので、修繕コストはＲＰよりも小さな値となる。一方、後倒しする場合には、劣化の進行によりＲＰよりも大きくなる。今回の修繕だけを考えると、できるだけ前倒しすることが良いこととなるが、ライフサイクルコストを検討するために次回の修繕も考慮すると結果が異なってくる。今回の修繕を前倒しすると、耐用年数は変わらないので次回の修繕までの期間が短縮されたことになり、不利益となる。そこで今回と次回の両者の修繕コストを最小化するように、着工時期を算出する。すると、あるビルについてｔ年後に着工するとして、今回修繕のコストＣ０は、
Ｃ０＝ＲＰ−Ｄｅ＊（Ｍ−ｔ） 数１
であり、次回修繕の短縮または延長によるコストＣ１は、
Ｃ１＝ＲＰ／ＣＹ＊（Ｍ−ｔ） 数２
で評価する。両者を合計した修繕コストＣは、
Ｃ＝Ｃ０＋Ｃ１＝ＲＰ−（Ｄｅ−（ＲＰ／ＣＹ））＊（Ｍ−ｔ） 数３
となる。

図２１は工程群管理サブシステムの画面例であり、３つのビルの大規模修繕の時期を同期化させたものである。この例では、各ビルは同じ仕様であるが新築時期が異なっている。したがって本来の修繕サイクルは点線で示す時期であるが、同期化するためにビル１では後倒しに、ビル２は診断通りに、ビル３は前倒しにして着工することを示している。この同期化のための入力パラメ−タは、各ビルについてのＤｅ、ＲＰ、ＣＹ及びＭであり、診断により得られたこれら値を入力・表示するウインドウもある。ここで最適な着工時期を決定するためには、各ビル毎の修繕コストＣを加算した値が最小になるように、着工時期ｔの値を定めれば良い。なお、ここでの同期化とは修繕工事の着工年を決める程度であり、各ビルの修繕工事を全く同一日に開始するわけではない。工事の作業人員など、資源には限りがあるので、詳細は工程計画により決定するが、何日間かずれるようにして、順次工事が開始することとなる。

次に、図２２のフロ−チャ−トにより、工程群管理サブシステムの処理を説明する。ステップ８０１は各ビルにつき繰返し処理することを意味している。ステップ８０２は遠隔診断装置による設備の診断処理で、振動や制御値のばらつきなどから、空調や昇降機などの設備の劣化具合を判断する。ステップ８０３は建築専門家による建物診断の処理で、外壁や鉄筋の劣化具合などを判断する。以上２つの診断結果から、劣化度ＤｅＣステップ８０４）、診断での修繕コストＲＰ％ステップ８０５）、耐用年数ＣＹ（ステップ８０６）、修繕時期Ｍ（ステップ８０７）の値を入力する。ステップ８０８は各着工候補年につき繰返し処理することを意味している。ステップ８０９は着工を変更した場合の修繕コストＣを計算する。可能な全ての場合を計算して、ステップ８１０ではＣが最小値となるように修繕着工年ｔを決定する。そしてステップ８１１にて、同期化した工程を端末の画面に表示する。

本発明の実施の一形態のビル群管理サ−ビス支援システムの全体構成を説明する図である。 システムの概略を説明する図である。 手続きの概略を説明する図である。 システムの構成を説明する図である。 システムのシ−ケンス図である。 システムのシ−ケンス図である。 システムのシ−ケンス図である。 デ−タファイルを説明する図である。 端末画面の一例を説明する図である。 入力デ−タを説明する図である。 入力デ−タを説明する図である。 入力デ−タを説明する図である。 デ−タの分析方法を説明する図である。 端末画面の一例を説明する図である。 入力デ−タを説明する図である。 入力デ−タを説明する図である。 入力デ−タを説明する図である。 端末画面の一例を説明する図である。 システムの計算モデルを説明する図である。 システムの計算モデルを説明する図である。 端末画面の一例を説明する図である。 システムのフロ−チャ−トである。 端末画面の一例を説明する図である。

符号の説明

１…管理者装置、２…所有者端末、３…利用者端末、４…事業者端末、５…営業者端末、６…診断者端末、７…調達者端末、８…配送者端末、５０…設備機器、６０１…保守プラン選択部、６０２…保守サービス組み合わせ表示部、６０３…総合評価表示部、６０４…利用者評価表示部、６０５…設備運行評価表示部。

Claims (3)

1. 計算機を備えたビル群管理サ−ビス支援システムであって、前記計算機は、入力されたビル設備の運行状況やサ−ビス特性を示す所定のパラメ−タ数の第一の状態デ−タを該デ−タが表現する当該運行状況の特性を保持しつつ当該パラメ−タ数を削減した第二の状態デ−タに変換する変換手段と、当該第二の状態デ−タにおけるパラメ−タにより指示値が入力されたとき、当該指示値に最も近い当該第二の状態デ−タを持つ設備を特定し得る情報を出力する演算手段とを備えたことを特徴とするビル群管理サ−ビス支援システム。
2. 計算機を備えたビル群管理サ−ビス支援システムであって、ビルの設備の利用者に対するアンケ−ト結果のデ−タを基に当該ビルの設備の評価状況を示す所定のパラメ−タ数の第一の状態デ−タを生成する手段と、当該第一の状態デ−タが表現する当該評価状況の特性を保持しつつ当該パラメ−タ数を削減した第二の状態デ−タに変換する手段と、当該第二の状態デ−タにおけるパラメ−タにより指示値が入力されると、当該第二の状態デ−タを持つ設備を特定し得る情報を演算し出力する手段とを備えたことを特徴とするビル群管理サ−ビス支援システム。
3. 前記第一の状態デ−タについて管理を約束する範囲として上限値と下限値を予め設定し、前記第一の状態デ−タの現在の値、当該下限値、及び当該上限値を出力することを特徴とする請求項１または２記載のビル群管理サ−ビス支援システム。

Images