JPH08123747A - 施設管理システムにおける分散処理方式 - Google Patents

Abstract

(57)【要約】 【目的】本発明は複数のサーバと設備の状態を収集する
と共に制御を行う複数の監視装置がネットワークで接続
された施設管理システムの分散処理方式に関し，データ
生成の性能を向上しデータ生成のタイムラグを防ぎ，且
つ通信の負荷を最少限に抑え，サーバの過負荷に対応で
きる等を目的とする。 【構成】サーバとして管理機能に応じて一つのマスタサ
ーバと複数のスレーブサーバとを設定し，各サーバにデ
ータ参照・更新処理部を備える。マスタサーバは，要求
に応じてデータを更新すると，ネットワークを介して更
新データを各スレーブサーバに送信し，各スレーブサー
バのデータ参照・更新処理部は受け取った更新データに
より自サーバのデータベースを更新してマスタサーバに
通知し，各サーバは定刻起動処理部に予め設定された時
間になると起動されるデータ展開処理部により自データ
ベースを用いて行い，て管理対象施設のスケジュールを
作成するよう構成する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は施設管理システムにおけ
る分散処理方式に関する。近年，ビル，工場等の人が出
入りする各種施設における防災，空調，照明，電力等の
各面に関する管理を効率的に行うことが望まれている。
このようなシステムでは，コンピュータの高速化，低価
格化，ＬＡＮの普及に伴い，システムの分散化による信
頼性の向上が要求されている。このため，ＬＡＮ接続に
よる分散システムが構築されているが，装置いずれかに
障害の発生や緊急度の高い事象が発生すると他装置にで
きるだけ早く通知する必要がある。

【０００２】

【従来の技術】図３２は従来の施設管理システムの構成
例である。図３２において，９０は全ての施設からの全
てのデータが格納されるデータベースと処理装置を備
え，施設管理の全体施設管理の処理を行うと共に防災，
照明，空調等の各管理を実行する各サブシステムを制御
し，操作者による指示を入力すると共に指示された施設
の状態やデータ等を表示する表示装置を備えたマスタサ
ーバ，９１は複数個設けられ，それぞれマスタサーバ９
０と同様の構成を備えたスレーブサーバ，９２は各装置
間でデータを転送するためのＬＡＮ，９３−１〜９３−
ｎはゲートウェイ装置，９４−１〜９４−ｎは施設管理
の各機構（照明，空調，防災等）に対応して設けられ，
各機構の制御を行うサブシステム，９５はデータ収集を
行う収集制御装置，９６は収集制御装置９５と線路を介
して多数設けられたデータ収集端末（ＴＥで表示），９
７は各データ収集端末に多数接続されたセンサである。 (1) 従来例のデータ整合及び展開処理 上記の従来の施設管理システムでは，マスタサーバ９０
とスレーブサーバ９１は，同一のデータを保持し，デー
タの読み出しはマスタサーバ９０から行い，書き込みは
先ずマスタサーバ９０に行って，マスタサーバ９０から
の指示により各スレーブサーバ９１のデータを更新する
ことによりデータの整合をとり，マスタサーバ９０の機
能をスレーブサーバ９１でバックアップしている。この
方式は，不定期または散発的なデータ更新の場合は速度
が要求されないので十分にデータの補償（マスタサーバ
とスレーブサーバ間のデータの同一性）と性能を期待で
きる。

【０００３】また，施設管理システムでは，年間または
月間単位で建物等を使用するマスタースケジュールが作
成されると，マスタサーバ９０においてそのマスタスケ
ジュールに基づいて週間単位で各管理対象となる施設
（空調，照明，防災等）を使用する運用スケジュールが
展開され，更に運用スケジュールから日単位の時間の経
過に合わせた各機器（例えば，建物の場所毎の照明装置
や，フロア毎の空調装置）の制御データ（スイッチのオ
ン・オフ等）を含む機器スケジュールが展開され，展開
されたデータは逐次，各スレーブサーバ９１へ転送され
てそれぞれのデータベースへ格納されると共に各サブシ
ステム９４−１〜９４−ｎへ供給され，機器の監視（制
御を含む）が行われる。また，マスタサーバ９０は収集
制御装置９５からの収集データが集められ，各スレーブ
サーバ９１に供給され，それぞれのオペレータは，表示
装置に収集データや各スケジュールのデータを表示して
監視したり，異常の通知があると対応した指示を入力す
ることができる。

【０００４】(2) 従来例の負荷分散 次に従来の図３２の施設管理システムの負荷の分散につ
いて説明すると，従来は各ノード（マスタサーバ及びス
レーブサーバ）が管理する対象であるポイントを分散さ
せることにより実現していたが，様々な機能の分散は機
能単位（防災，照明等）でなくポイント（施設の場所）
の単位で負荷を分散させている。

【０００５】(3) 複数の監視装置にまたがる連動トリガ 上記従来例のサブシステム９４−１〜９４−ｎでは，そ
れぞれ異なる機能（防災，空調，照明等）の監視・制御
を行っているが，機能毎にサブシステムを設けると同じ
ポイントに対して複数の各機能に対応する機構と各サブ
システム間を接続する配線が必要であった。これを解消
するために各サブシステムに複数の機能を備え，監視
（制御）対象となるエリア毎にサブシステムを設けて，
各サブシステムはサーバ（マスタサーバやスレーブサー
バ）から制御を受ける方式が提案されている。

【０００６】そのような施設管理システムでは，ある機
能の監視項目の状態変化をトリガとして，他の機能を実
行する機構を連動させることがある。この機能を連動ト
リガと呼ぶ。例えば，照明のスイッチが切り替えられる
と，照明装置の近辺の空調装置の一つまたは複数を連動
して切り替える場合等がある。

【０００７】このように異なる機能にまたがった連動ト
リガを，高速に実行するには，複数の個別の機能（防
災，空調，照明等）毎に設けられた監視装置（サブシス
テム）を統合管理する装置を設ける必要がある。

【０００８】図３３に従来の連動トリガ行う場合の説明
図を示し，監視装置１０２，１０３はそれぞれ複数機能
（防災，空調，照明等）の監視（制御）を行い，各監視
装置は各監視対象の機器の状態や，測定器の値等のポイ
ントの状態を検出する多数のセンサや，各機器を制御す
る多数のスイッチ等と接続する配線と接続されている。
各監視装置は統合管理装置１００と接続され，全ての監
視装置の監視対象の設備状態は統合管理装置１００に集
められ，メモリ１０１に保持されて一定周期で更新され
る。連動トリガが成立する条件は予め各監視装置に入力
設定されている。例えば，監視装置１０２に属するセン
サ１がオンで，監視装置１０３に属するセンサ２がオン
の条件が成立したら，監視装置１０２のＳＷ１をオンに
切替えるという連動トリガを設定できる。この例の場
合，センサ１がオンへ状態変化（トリガ）すると，連動
条件を満たすか否かを監視装置１０２から統合管理装置
１００に通知され，統合管理装置１００自身が保持して
いる他の連動トリガ条件の設備（監視装置１０３のセン
サ２）の状態を調べて，連動条件が成立している場合に
連動設備（監視装置１０２のＳＷ１）への制御を指示す
ることになる。

【０００９】なお，上記図２１の構成例を採用しない
で，各監視装置だけで状態を保持し，連動トリガの条件
を満たすか否かを判定する場合は，一つの監視装置から
連動条件に関係する他の監視装置に問い合わせを行い，
そのために通信動作を行う必要がある。

【００１０】(4) 施設管理における建屋の火災復旧の判
定 従来の図３２に示す施設管理システムでは，複数の建屋
（建物の棟を表す）の火災復旧の判定は，サーバにおい
て実行されている。

【００１１】火災状態の判定データは，システム全体が
１０００グループ程度用意される場合がある。その場
合，各グループには，対応する建屋番号と，火災入力点
状態を数個（例えば５個）の機器，火災出力点（警報，
消化等を実行する機器）として多数の機器（例えば３０
個）が指定される。このようなシステムにおいて，火災
が発生した後，火災復旧の判定を行う場合，従来は次の
，の技術が用いられていた。

【００１２】火災確認操作が必要な場合 建屋番号に対応したグループの１つでも入力条件（火災
の状態を表す入力条件）を満たしている時に火災確認操
作を行った場合は，その建屋は火災とみなされ，出力点
に指定された制御（例えば，スプリンクラーの駆動制
御）が行われると同時にシステムは火災状態となり，表
示画面に火災スポット（火災位置）の表示を行う。建屋
番号に対応した全てのグループが入力条件を満たしてい
ない時に火災復旧操作を行うと，その建屋は火災復旧と
みなされる。また，全ての建屋が火災復旧状態にならな
いとシステムは火災復旧状態にならない。

【００１３】火災確認操作が必要でない場合 建屋番号に対応したグループの１つでも入力条件を満た
している場合は，その建屋は火災と見なされ，出力点に
指定された制御が行われると同時にシステムは火災状態
となり，画面に火災スポットの表示を行う。建屋番号に
対応した全てのグループが入力条件を満たしていない場
合に火災復旧操作を行うと，その建屋は火災復旧とみな
される。また，全ての建屋が火災復旧状態にならないと
システムは火災復旧状態にならない。

【００１４】図３４は防災の処理速度を高速化するため
のシステム構成例を示し，上記の，の判定を高速に
行うために，統合管理装置１０４が設けられ，統合管理
装置１０４に備えられたメモリ１０５に防災関係の全グ
ループの機器状態が格納され，一元管理される。この構
成で，火災復旧を行う場合，統合管理装置１０４におい
て，メモリ１０５の全入力条件の状態を確認し，全ての
グループの状態が入力条件を満たしていない場合に火災
復旧と判定して表示装置１０６に表示し，満たしていな
いと火災状態であることを表示していた。

【００１５】(5) 収集データの画面表示 従来の施設管理システム（図３２参照）では，サーバ
（マスタサーバ９０，スレーブサーバ９１）の操作者が
画面表示開始時に収集制御装置９５，各サブシステム９
４に対して表示を行う機器の状態（センサの出力や機器
の制御状態等）を要求すると，その後は状態変化を検出
した機器のデータが収集制御装置やサブシステムを経由
してサーバに通知されて，表示中の機器に該当すると画
面の更新を行っていた。ところが，収集制御装置９５や
各サブシステム９４−１〜９４−ｎは，表示していない
機器のデータを含めた通知を行って，サーバが表示装置
の画面更新を行うのは全てのデータ（表示していないデ
ータを含む）の転送が完了した後である。

【００１６】

【発明が解決しようとする課題】上記(1) のデータ整合
及び展開処理に関し, 上記従来の施設管理システムで
は，データの更新が頻繁に発生した場合にはマスタサー
バ９０への書き込みの後に行われる各スレーブサーバ９
１への更新指示動作が追いつかなくなり，マスタサーバ
とスレーブサーバ間でデータが一致する保障ができなく
なる。また，上記したマスタスケジュールから運用スケ
ジュールへの展開及び運用スケジュールから機器スケジ
ュールへの展開処理等，大量のデータから大量のデータ
を生成する処理では逐次転送を行うとデータの生成処理
の性能が悪化する。更に，データ生成中にマスタサーバ
がダウンした場合，スレーブサーバは受信済のデータを
破棄し，データ生成処理を最初からやり直す必要があ
る。

【００１７】また，逐次転送ではなくデータ生成が終了
してからの一括転送では通信の負荷の他の監視処理等に
悪影響を及ぼし，データ生成処理中にマスタサーバがダ
ウンした場合，スレーブサーバはマスタサーバのダウン
を検出してからデータ生成の必要性を判断し，処理を開
始することになり，データが必要となる日替わり処理に
間に合わない場合がある。

【００１８】上記(2) の負荷分散に関し, 上記従来の負
荷分散の方式ではある機能が必要とするデータが各サー
バに分散するため, データの整合をとる必要がある場合
のデータの配信を全ノードに対して行う必要があり, 管
理の複雑化, 通信負荷の増大を招いている。一方，各機
能が必要とするデータを一元管理するマスタサーバを設
けると（図３２），そのノードに負荷が集中するという
問題があった。

【００１９】上記(3) の従来の複数の監視装置にまたが
る連動トリガの技術では，統合管理装置は全監視装置の
設備状態を監視できる規模の容量が必要であり，必然的
に施設管理システムのコストが高くなる。また，統合管
理装置に障害が発生した場合に複数の監視装置にまたが
る連動が行えない等の問題があった。

【００２０】上記(4) の施設管理における建屋の火災復
旧の判定には，統合管理装置（図３４の１０４）は，全
監視装置の設備状態を監視できる規模が必要であり，コ
ストが高くなり，統合管理装置に障害が発生すると，火
災制御全体が停止してしまうという問題があった。ま
た，統合管理装置を設けない場合は，他の監視装置が管
理する建屋に対応したグループの入力設備状態を問い合
わせ，全てのグループの状態が条件を満たすか判定する
ために，１建屋に複数の監視装置がまたがった火災制御
を行った場合，火災復旧装置の完了にかなりの時間がか
かった。

【００２１】上記(5) の従来の収集データの画面表示の
技術によれば，表示装置に表示している多くの機器の状
態変化が多発した場合にも，他の表示されていないデー
タを転送するのに時間がかかるため，画面更新が遅れる
という問題があった。

【００２２】本発明は上記(1) 〜(5) の各問題に対応す
る以下の各目的を持つ。本発明の第１の目的はデータ生
成の性能を向上しデータ生成のタイムラグを防ぎ，且つ
通信の負荷を最少限に抑えることができる施設管理シス
テムにおける分散処理方式を提供することである。

【００２３】本発明第２の目的はデータの配信等による
サーバ（マスタサーバ及びスレーブサーバ）の過負荷の
発生に対して正常に動作させることができる施設管理シ
ステムにおける分散処理方式を提供することである。

【００２４】本発明の第３の目的は統合管理装置を設け
ず緊急度の高い連動トリガの制御を高速に行うことがで
きる施設管理システムにおける分散処理方式を提供する
である。

【００２５】本発明の第４の目的は火災復旧の判定を統
合管理装置を設けることなく，複数の監視装置を備えた
構成により最少限の時間で行うことができる施設管理シ
ステムにおける分散処理方式を提供することを目的とす
る。

【００２６】本発明の第５の目的は表示装置に表示中の
機器の状態については状態変化が発生すると直ちに表示
できる施設管理システムにおける分散処理方式を提供す
ることを目的とする。

【００２７】

【課題を解決するための手段】図１は本発明の第１の原
理構成図，図２は本発明の第２の原理構成図，図３は本
発明の第３の原理構成図，図４は本発明の第４の原理構
成図である。

【００２８】図１は上記本発明の第１及び第２の目的を
実現する原理構成である。図１において，１は施設管理
のための表示装置やキーボードを含む入出力装置，処理
装置及びマスタデータベースを備えたマスタサーバ，１
１はマスタデータベース，１２はデータ参照・更新受付
処理部，１３はデータ参照・更新処理部，１４は通信処
理部，１５はデータ展開処理部，１６は予め設定された
周期で起動する定刻起動処理部，１７は自ノードの過負
荷を監視し，自ノードの持つ機能の負荷退避順位（過負
荷時に機能を他の何れのサーバに切り換えるかの順番付
け）を管理する負荷監視処理部である。

【００２９】２は図１には１つの装置しか示されていな
いが，実際には複数個設けられたスレーブサーバであ
り，それぞれマスタサーバ１と同様の機能及び構成を備
え，管理機能（例えば，照明管理）によってはマスタサ
ーバ（データ参照・更新処理部をそのサーバに備える）
として動作する。２１はスレーブデータベース，２２は
データ参照・更新処理部，２３は通信処理部，２４はデ
ータ展開処理部，２５は定刻起動処理部，２６は自ノー
ドの過負荷を監視して過負荷退避順位を管理する負荷監
視処理部，３はマスタサーバ，スレーブサーバ及び図示
されない施設管理用のデータ収集及び管理装置を相互に
接続して通信を行うＬＡＮ等のネットワークを表し，４
はネットワーク３を介して接続して複数の管理機能に対
応するデータ収集機能，制御機能を備えた複数の監視装
置，５は設備の状態を収集して監視装置に伝送し，監視
装置からの指示により設備の制御を行う収集装置，６は
多数の収集装置と監視装置を接続する線路である。

【００３０】図２は本発明の上記第３の目的を実現する
原理構成である。図２において，１はサーバであり，上
記図１のマスタサーバ１またはスレーブサーバ２の何れ
かを表す，３はＬＡＮ等のネットワーク，４はそれぞれ
施設の一定のエリア内の全ての管理機能（防災，空調，
照明，電力制御等）についてデータ収集と状態制御の行
う監視（制御）を行う監視装置であり，施設のエリアに
対応して複数個設けられている。５は各監視装置４と線
路６で接続されエリア内に設けられた機器の状態を表す
多数のデータを収集する収集装置，６は線路である。

【００３１】図３は本発明の上記第４の目的を実現する
原理構成，図４は本発明の上記第５の目的を実現する原
理構成であり，図３，図４の１，３〜６の各符号は上記
図２と同じ名称であり説明を省略する。なお，１ａは表
示装置，１ｂは入力装置である。

【００３２】本発明の第１の原理構成ではデータの参照
・更新はマスタサーバとスレーブサーバの両方で実行
し，データ展開処理はマスタサーバとスレーブサーバの
間で同じレベルのデータであることを確認して展開を行
い，通信が一定時間無いとヘルスチェックにより正常性
を確認するものである。また，処理や通信により負荷が
過大になると機能に対応して他のサーバをその機能に関
するマスタサーバとして切り換えるものである。

【００３３】

【作用】上記第１の目的を実現する図１の作用を説明す
ると，マスタデータベース１１の更新時は，データ参照
・更新受付処理部１２がデータ更新またはデータ参照を
受付けると，データ参照・更新処理部１３を起動し，マ
スタデータベース１１のデータ更新または参照を行うと
共にデータ更新についてはデータ参照・更新処理部１３
から通信処理部１４，ネットワーク３及び通信処理部２
３を介して更新データが送付（配信）され，スレーブデ
ータベース２１を更新し，スレーブデータベース２１の
更新終了時にデータ参照・更新処理部２２は通信処理部
２３，ネットワーク３，通信処理部１４を介してデータ
参照・更新処理部１３に正常応答を返し，データ参照・
更新処理部１３はデータベースの更新が正常終了したこ
とを認識すると，データ参照・更新受付処理部１３に正
常応答を返す。

【００３４】マスタサーバ１及びスレーブサーバ２の定
刻起動処理部１６，２５はそれぞれ予め設定された時間
になるとデータ展開処理部１５，２４を起動する。デー
タ展開処理部１５はデータ参照・更新処理部１３にデー
タ展開処理を開始することを通知しデータ展開処理を開
始する。通知を受けたデータ参照・更新処理部１３はデ
ータ展開処理部１５からデータ展開の終了の通知を受け
取るまで，新たなデータ更新処理を受付けない。

【００３５】スレーブサーバ２のデータ展開処理部２４
は通信処理部２３，１４を介してデータ展開処理部１５
にデータ展開を介した時のマスタデータベース１１のレ
ベル（更新世代）を問い合わせ，応答されたレベルとス
レーブデータベース２１のレベルが一致した場合，スレ
ーブサーバ２におけるデータ展開を開始する。レベルが
低いと一致するまで待ち合わせて，データ展開開始の同
期をとる。データ展開処理部２４はデータ展開終了時
に，通信処理部２３，１４を介してデータ展開終了を通
知し，データ展開処理部１５は自身のデータ展開とスレ
ーブサーバからの展開処理終了の通知でデータ展開を終
了する。データ展開には，例えば，カレンダのデータ
（施設を稼働する年間予定）等からマスタスケジュール
を展開し，マスタスケジュールから運用スケジュールの
展開，運用スケジュールから機器スケジュールへの展開
がある。

【００３６】通信処理部２３は一定時間にわたって通信
処理部１４と通信が行われないと，ヘルスチェックメッ
セージを通信処理部１４との間でやりとりしマスタサー
バ１の正常性を確認し，異常を検出した場合は，他のス
レーブサーバ２にサーバの切り換えを通知して，マスタ
サーバの機能をこのスレーブサーバ２で行う。サーバの
切り換え中に定刻起動処理部１６が起動した場合は，直
ちにデータ展開処理を開始する。この時，マスタデータ
ベース１１ののレベルを問い合わせて，マスタサーバの
ダウンを検出すると，サーバの切り換えを他のサーバに
通知し，マスタサーバとして動作を開始して展開処理を
行う。このヘルスメッセージの送信はマスタサーバ１の
通信処理部１４から他のスレーブサーバ２に対しても同
様に行われる。

【００３７】次に図１における上記第２の目的を実現す
る作用を説明すると，マスタサーバ１の負荷監視処理部
１７は自ノードの中央処理装置（ＣＰＵ）の使用率を監
視し，使用率が一定時間以上連続して１００％になると
過負荷と判断し，予め設定された負荷の退避順位に応じ
て該当するスレーブサーバを選び，このマスタサーバが
実行している機能を実行するデータ参照・更新処理部１
３に通知される。データ参照・更新処理部１３は通信処
理部１４，２３を介してスレーブデータベースのデータ
参照・更新処理部２２にマスタサーバ２が過負荷になっ
たことを通知する。データ参照・更新処理部２２は負荷
監視処理部２６に対しこのスレーブサーバ２が過負荷か
どうか確認し，過負荷でなければデータ参照・更新処理
部１３にネットワーク３を介してその旨を通知する。

【００３８】データ参照・更新処理部１３はこれに応じ
て，当該機能の新しいデータ変更要求を拒否し，既に受
付済の変更処理を終了すると該当機能のマスタデータベ
ース機能の引き継ぎをネットワーク３を介してスレーブ
サーバ２のデータ参照・更新処理部２２に依頼する。デ
ータ参照・更新処理部２２は他のノードに対し該当機能
のマスタデータベースが自装置になったことを通知し，
マスタデータベースとしての機能を開始する。機能毎の
マスタ・スレーブの配置，負荷退避の優先順位を最適に
設定することにより全体の通信の負荷を上げることな
く，負荷の分散を実現できる。

【００３９】次に上記第３の目的を達成する図２の原理
構成の作用を説明すると，システムの立ち上げ時にサー
バ１から監視装置４の通信処理部４０を介して連動処理
部４１に連動条件４１ａが設定される。この時，他の監
視装置主催の連動のポイント（他監視装置の管理下にあ
る設備）の状態が連動条件４１ａに含まれていると，該
当する他の監視装置４に対し通信処理部４０からネット
ワーク３を介してポイントのアドレスを指定してその状
態変化を通知するよう要求する。他の監視装置４の連動
処理部４１ではその要求を受け取るとそのポイントの状
態変化毎に要求元の監視装置に通知を行うよう設定され
る。

【００４０】一方，状態監視処理部４２は自監視装置４
の管理下にある収集装置５から送られた状態変化が発生
した設備状態を受け取ると，連動スキャニングメモリ４
４に書き込みを行う。この時，連動処理部４１を参照し
て，自装置が主催の連動（連動を開始するポイント（設
備）が自監視装置で管理していること）が存在すること
が分かると，そのポイントの状態変化を連動処理部４１
に通知し，また他装置主催から通知するよう要求された
ポイントであるか判定して該当すると通信処理部から要
求元の監視装置へ通知する。

【００４１】連動処理部４１は状態監視処理部４２から
の状態変化の通知を受けると連動条件４１ａを満たすか
の判定を行い，予め通知するよう要求を行った他の監視
装置からポイントの状態変化を通知されると，ポイント
の状態を連動スキャニングメモリ４３に書き込むと共
に，連動条件４１ａが成立したか判定する（連動スキャ
ニングメモリ４４の内容を参照）。連動条件４１ａが成
立すると，連動処理部４１は制御を行う設備が自監視装
置の管理下の場合は，状態監視処理部４２に制御要求を
行い，他の監視装置の管理下の場合は，該当する監視装
置の状態監視処理部４２にネットワーク３を経由して制
御要求を出力する。

【００４２】次に上記本発明の第４の目的を達成する図
３において，各監視装置４はそれぞれが管理する建屋の
火災の状態を表す各ポイントのデータを収集装置５から
取り出して格納している。なお，監視装置は一つの建屋
を監視するために設けられる場合もあるが，ここでは一
つの建屋を複数の監視装置によりエリア毎に監視してい
るものとする。

【００４３】サーバ１の操作者が建屋を指定して火災復
旧の確認の操作を入力装置１ｂから行うと，その建屋を
管理する一つの監視装置４の通信処理部４０を介して火
災復旧処理部４６は，同じ建屋を管理する他の監視装置
（複数個の場合を含む）に対し建屋火災状態を通知する
よう指示する要求を通信処理部４０，ネットワーク３を
介して送出する。他の監視装置はこれに応じて，その監
視装置が保持する建屋火災状態通知を，通知要求を発生
した監視装置４へ送出する。

【００４４】他の監視装置から建屋火災状態通知を受け
取った監視装置（要求を発生した監視装置）は，各監視
装置から受け取った建屋火災状態通知及び自監視装置の
管理下の収集装置５により得られた建屋火災状態をそれ
ぞれ監視装置別にメモリ４７に格納する。格納された各
監視装置の建屋火災状態を用いて火災復旧状態か火災状
態かを判定して，判定結果は通信処理部４０，ネットワ
ーク３を介してサーバ１へ通知され表示装置１ａに表示
される。

【００４５】次に上記本発明の第５の目的を達成する図
４において，サーバ１の操作者が入力装置１ｂにより表
示装置１ａで表示したい機器（ポイント）を指定する
と，指定された各機器のアドレスはその機器を管理する
監視装置４に通知される。各監視装置４の状態監視処理
部４２は機器状態を格納するメモリ４８の中の機器の状
態を格納するエリアの一部に設けられた表示中フラグを
オンに設定（設定されないものはオフで非表示を表す）
する。

【００４６】また，監視装置４は線路６を介して各収集
装置５の配下に属する表示中の機器のアドレスを通知す
ると，該当する収集装置５の状態監視制御部５０でこれ
を受け取ると，状態監視制御部５０が使用するメモリ５
１の該当する機器に対応する位置に表示中フラグが設定
される。

【００４７】この後，収集装置５の状態監視制御部５０
は表示フラグがオンになっている機器については通常よ
り早い周期で状態検出を行い，その状態変化だけを監視
装置４に通知する。監視装置４は各収集装置５から送ら
れた表示中フラグがオンである機器の状態変化情報だけ
をサーバ１へ通知して，サーバ１の表示装置１ａに表示
する。表示装置１ａで表示の消去が行われると，表示中
解除指令を監視装置４へ通知する。これにより，メモリ
４８の表示フラグがオンになっているものをオフにし，
各収集装置５にも表示中解除指令を通知する。各収集装
置５ではメモリ５１にオンになっている表示中フラグを
オフにする。表示中フラグがオフになっている機器の状
態変化は，監視装置４が通常（低速）の一定周期で表示
中フラグがオンになっている機器の状態変化の情報と共
にサーバ１へ通知する。

【００４８】

【実施例】図５は本発明が実施される施設管理システム
の構成図，図６はサーバのハードウェア構成，図７は監
視装置のハードウェア構成，図８は収集装置のハードウ
ェア構成である。

【００４９】図５において，１，３〜６は上記図１〜図
４の同じ符号で表す各部に対応し，１はサーバ，３は各
装置間でデータを転送するためのＬＡＮ回線，４は建屋
の一定のエリア内の各機能（防災，空調，照明等）の監
視・制御を行う監視装置，５は監視装置に接続され周囲
の一定範囲に設置されたセンサの状態を収集したり，機
器の制御を行う収集装置，６は複数の収集装置５と監視
装置４を接続する線路である。

【００５０】複数設けられたサーバ１は，ハードウェア
構成としては同じであり，その中の一つを全ての管理機
能（防災，空調，照明等）のマスタサーバとして設定
し，他のサーバ１をスレーブサーバとすることができる
が，管理機能毎にマスタサーバとなるサーバ１を設定す
ることもできる。

【００５１】図６にサーバ１のハードウェア構成を示
す，図６において，１ａは管理対象となる施設各部の制
御状態やセンサからの状態データを表示するＣＲＴ装
置，１ｂは操作者が設備の監視及び制御のための各種の
指示やデータを入力するキーボード，１ｃはマンマシン
インタフェースを備える共にサーバが備える各種の処理
を実行するＣＰＵ及びメモリ（機器の現在状態やセンサ
の検出信号の現在状態を保持）を含むマザーボード，１
ｄは管理対象の施設の構成，時系列のロギング等及びデ
ータ展開により作成された各種のスケジュール（マスタ
スケジュール，運用スケジュール，機器スケジュール
等）で構成するデータベースが格納されるハードディス
クユニット，１ｅはＬＡＮ回線（図５の３）を介する他
のサーバ１や，複数の監視装置４との通信処理を行うＬ
ＡＮ通信ユニットである。

【００５２】図７は監視装置４のハードウェア構成であ
り，４ａは監視装置を構成する各ユニット間のデータ転
送を行うチャネルバス，４ｂはバス４ａの使用権の調停
を行うバスコントロールユニット，４ｃはスキャニング
メモリ（上記図２の４４）として使用されたり作業領域
として使用され全てのプロセッサユニットにより参照さ
れる共通メモリユニット，４ｄは監視装置が備える監視
・制御機能を実行し，連動処理機能（図２の４１に対
応），連動スキャニングメモリ（図２の４３）及び火災
復旧処理機能（図３の４６に対応）を備えるアプリケー
ションプロセッサユニットである。

【００５３】４ｅは状態監視制御機能（図２，図３の４
２に対応）を備え，表示中フラグを配置（図４の４８）
し，ＬＡＮ通信機能（図２〜図４の通信処理部４０に対
応）によるＬＡＮ通信ユニットを制御する処理を行うＬ
ＡＮ制御・状態監視プロセッサユニット，４ｆはＬＡＮ
回線（図５の３）を介したサーバや他の監視装置との通
信を実行するＬＡＮ通信ユニット，４ｇは半導体ディス
クユニット４ｈを制御するディスク制御プロセッサユニ
ット，４ｈは各ユニットの初期データ等を保存する半導
体ディスクユニット，４ｉは収集装置接続プロセッサユ
ニット，４ｊは複数の収集装置５と接続する線路６を介
してＨＤＬＣ（High-level Data Link Control procedu
re: ハイレベル・データリンク手順) のＮＲＭ（Normal
Response Mode: 正規応答モード) でデータを伝送する
ＨＤＬＣ通信ユニットである。

【００５４】図８は収集装置５のハードウェア構成図で
ある。図中，５ａは収集装置が備える設備状態（機器の
動作状態やセンサの検出状態）の収集（監視）や機器の
制御含む状態制御機能（図４の５０に対応）の処理を行
い，表示中フラグが配置されるプロセッサユニット，５
ｂは上記図７の４ｊと同様のＨＤＬＣ通信ユニット，５
ｃはこの収集装置５が監視対象とする各現場設備５ｄの
一定個数毎に設けられ各現場設備への制御信号の出力，
現場設備からの信号を入力するＩ／Ｏユニット，５ｄは
建屋内の各管理設備に対応して設けられた各現場設備
（センサ，制御機器）である。

【００５５】上記図５〜図８に示す構成を備えた施設管
理システムにおいて，上記図１乃至図４に示す原理構成
に示す各処理を実現するための各部の処理フローを以下
に説明する。

【００５６】図９はデータ参照・更新受付の処理フロー
であり，この処理は上記図１の１２に対応し，図６のサ
ーバ１のマザーボード１ｃにおいて実行される。マンマ
シンインタフェースからイベント通知を待ち合わせる
（図９のＳ１）。これはキーボード（図６の１ｂ）から
操作者によるデータ参照または更新を指示する入力の発
生を待機する状態で，指示が発生するとデータベースの
更新の通知か（または参照の通知）判別し（同Ｓ２），
更新の場合はデータ参照・更新処理（後述する図１０に
示す）に対し更新依頼イベントを発行し，更新完了イベ
ントを待ち合わせて，更新完了イベントを受け取るとマ
ンマシンインタフェースに更新状況を通知する（図９の
Ｓ３〜Ｓ５）。

【００５７】データ参照の場合は，Ｓ６に移行して，デ
ータ参照・更新処理に対し参照依頼イベントを発行し，
続いてデータ参照・更新処理からの読込通知イベントを
待ち合わせて，その通知を受け取るとマンマシンインタ
フェースに読込状況を通知する（図９のＳ６〜Ｓ８）。
図１０，図１１はデータ参照・更新の処理フロー（その
１），（その２）であり，上記図１の１３，２２の機能
に対応し，図６のサーバ１のマザーボード１ｃにおいて
実行される。但し，この例はマスタサーバ側で実行され
る場合のフローである。

【００５８】この処理は，データ参照・更新受付処理
（上記図９），データ展開処理（後述する図１３，図１
４），通信処理（後述する図１５）等からの要求イベン
ト通知を待って（図１０のＳ１），通知が発生するとそ
の通知はデータベースの参照を要求するのか判別し（同
Ｓ２），参照の場合は現在データ展開処理を行っていて
排他中（データ展開中は参照・更新を不可とする）の状
態であるか判断し（同Ｓ３），データ展開処理を行って
いる場合要求元へ展開中を通知し（同Ｓ４），データ展
開を行っていないと要求されたデータベースのレコード
を読み込み（同Ｓ５），要求元へ読み込んだデータを通
知する（同Ｓ６）。

【００５９】要求イベント通知が参照でない場合，デー
タベースの更新の通知か判別し（同Ｓ７），更新の通知
の場合は上記Ｓ３と同様にデータ展開処理を行って排他
中か判断し（同Ｓ８），該当すると要求元へ通知し（同
Ｓ９），該当しないとデータベースのレコードとレベル
を更新し（同Ｓ１０），通信処理にスレーブ装置（スレ
ーブサーバ）のデータ更新依頼通知イベント（データベ
ースのレベルを含む）を発行して（同Ｓ１１），スレー
ブサーバからの応答を待ち合わせて（同Ｓ１２），応答
があると要求元へ応答内容（更新完了）を通知する（同
Ｓ１３）。

【００６０】要求イベントが更新でない場合，図１１に
移行して，データ展開排他解除依頼か判別し（図１１の
Ｓ１４），これに該当するとデータ展開排他中状態を解
除し（図１１のＳ１６），要求元へ応答内容（解除完
了）を通知し（同Ｓ１７），該当しないと依頼内容異常
を通知する（Ｓ１５）。

【００６１】図１２は定刻起動の処理フローである。こ
の処理は，図１の１６，２５（定刻起動処理部）に対応
し，マスタサーバ及びスレーブサーバで実行される。定
刻起動処理は，予め起動時刻が設定されているものと
し，６０秒間隔の起床を待ち合わせて，現在時刻が起動
時刻と一致するか判定し，一致するとデータ展開処理
（後述する図１３，図１４参照）を起動する。

【００６２】図１３，図１４はデータ展開の処理フロー
（その１），（その２）であり，図１の１５，２５の機
能に相当する。要求イベント通知を待機して（図１３の
Ｓ１），受け取るとデータ展開依頼か判別し（同Ｓ
２），データ依頼である場合には自装置がマスタである
か判別し（同Ｓ３），マスタの場合はデータ参照・更新
処理に対しデータ展開開始を通知し（同Ｓ４），データ
参照・更新処理から応答イベントを待ち（同Ｓ５），応
答を受け取るとマスタデータベースのデータ展開を行う
（同Ｓ６）。この展開でマスタスケジュール，運用スケ
ジュール，機器スケジュールが展開されるとマスタデー
タベースのレベルを更新し（同Ｓ７）。スレーブデータ
ベースの展開を待ち合わせる（同Ｓ８）。全スレーブか
ら展開の通知（更新レベルを含む）を受け取ったか判断
し（同Ｓ９），全スレーブの展開が完了するとレベルが
異なるスレーブがあるか判別し（図１４のＳ１８），あ
る場合はレベルの異なるスレーブに展開データの配信を
し（同Ｓ１９），依頼元へデータ展開完了を通知する
（同Ｓ２０）。

【００６３】上記のＳ２の処理でデータ展開依頼でない
ことが分かると，要求イベントがレベルの問い合わせで
あるか判断し（図１４のＳ２７），該当すると依頼元へ
データベースのレベルを通知する（同Ｓ２８）。レベル
の問い合わせでない場合，次にマスタ切換えの要求イベ
ントか判別し（同Ｓ２９），該当するとマスタデータベ
ース装置番号を変更する（同Ｓ３０）。

【００６４】また，上記の処理Ｓ３において，自装置が
マスタではなくスレーブであると判断された場合，通信
処理（後述する図１６参照）にマスタデータベースのレ
ベル問い合わせを依頼し（同Ｓ１０），Ｓ１１〜Ｓ１
５，Ｓ２１〜Ｓ２３の処理が行われる。すなわち，マス
タが正常であれば，レベルが一致し且つリトライオーバ
（再試行の回数が一定数以上）でないと，データ参照・
更新処理にデータ展開開始を通知し，応答イベントを待
ち合わせる。応答を受けると自装置（スレーブサーバ）
のデータ展開を行って，そのレベルを更新し，マスタデ
ータベースへ展開完了を通知する。レベルが一致しない
か，リトライオーバの場合は，１０秒間待ち合わせて，
通信処理に対する依頼（Ｓ１０）に戻る。

【００６５】また，Ｓ１１において，マスタが障害中の
場合は，Ｓ１６，Ｓ１７及びＳ２４〜Ｓ２６が実行され
る。すなわち，自装置をマスタとして切換え，全装置に
通知して，データ参照・更新処理に対しデータ展開を通
知する。この通知に対し応答イベントが返ると，自装置
データベースのデータ展開を行って，自装置のデータベ
ースのレベルを更新する。

【００６６】この処理により，マスタサーバとスレーブ
サーバで，それぞれがデータ展開処理を実行しても，何
れのデータベースも同じレベルのデータが展開されるた
め，どのスレーブサーバもマスタサーバと同じ内容のデ
ータベースを備えることが保証される。

【００６７】次に図１５乃至部図１８は通信の処理フロ
ーであり，図１の１４，図２乃至図４の４０の機能に相
当する。図１５は他装置送信，図１６は受信，図１７は
ヘルスメッセージ送信，図１８はヘルスメッセージ受信
の各処理のフローである。

【００６８】他装置への送信処理は，図１５に示すよう
に送信依頼を受けると，指定装置にデータを送信し，相
手装置が異常か判定して，異常であれば相手装置異常中
として相手装置の状態データを設定し，異常でなければ
異常中の状態を復旧して正常に設定する。

【００６９】受信処理は，図１６に示すように他装置か
ら受信があると，他装置から指定された内部の宛て先
（例えば，データ参照・更新処理やデータ展開処理，デ
ータベース等）に通知を行う。

【００７０】ヘルスメッセージの送信処理は，図１７に
示され，一定時間通信（送信，受信）が行われないと，
６０秒間隔の起床を待ち合わせ，自装置がマスタ装置
（マスタサーバ）か否か判定し，マスタ装置の場合，全
スレーブ装置（スレーブサーバ）にヘルスメッセージを
送信し，全スレーブ装置からの応答メッセージを待ち，
応答の無いスレーブ装置を異常とみなす。全スレーブ装
置からの応答があると，６０秒間隔の起床の待機に移行
する。自装置がスレーブサーバの場合，マスタ装置にヘ
ルスメッセージを送信し，マスタ装置からの応答メッセ
ージを待ち，応答がないとマスタ異常とする（この場
合，マスタ切換えが実行される）。

【００７１】ヘルスメッセージの受信処理は，図１８に
示すように，他装置からのヘルスメッセージの受信を待
ち，受信すると依頼元にヘルスメッセージを折り返す動
作が行われる。

【００７２】次に図１９乃至図２１によりサーバにおけ
る負荷監視と過負荷時の処理を説明する。図１９，図２
０は過負荷時の処理フロー，図２１は負荷監視の処理フ
ローであり，これらは図１の１７，２６の機能に対応す
る。

【００７３】各サーバにおける負荷監視は，図２１に示
すように行われ，一秒間の起床を待ち合わせ，ＣＰＵ
（図６のマザーボード１ｃ内）のアイドル率が５０％以
上か判別し，５０％に達しない場合は何もしないが，５
０％以上の場合は過負荷の通知を行う。

【００７４】次に図１９，図２０に示す過負荷の処理フ
ロー（その１），（その２）において，要求イベントを
待ち合わせて（図１９のＳ１），イベントが入力される
と過負荷通知（上記図２１で発生）であるか判別し（同
Ｓ２），過負荷通知の場合は他装置（サーバ）に処理引
き継ぎが可能か問い合わせて応答を待ち合わせる（同Ｓ
３，Ｓ４）。他装置（サーバ）から応答を受け取ると，
応答内容が引き継ぎ可能か判定し（同Ｓ５），可能でな
い場合は他の装置に切換え（同Ｓ６），同様の問い合わ
せを行う。可能な場合は処理可能装置に引き継ぎを依頼
し（同Ｓ７），自装置をデータ変更拒否の状態にする
（同Ｓ８）。

【００７５】また要求イベントが過負荷通知でない場
合，Ｓ９〜Ｓ１２の処理が行われる。すなわち，他の装
置からの引き継ぎ可能の問い合わせか判定し，該当する
場合自装置の処理負荷が１０％以下か判定し，以下の場
合は依頼元に引き継ぎ可能を通知し，１０％を越えてい
る場合は引き継ぎ不可を依頼元へ通知する。

【００７６】また，要求イベントが上記過負荷通知，引
き継ぎ可能問い合わせの何れでもない場合，引き継ぎ依
頼であるか判定し（図２０のＳ１３），引き継ぎ依頼で
あれば（この場合既に上記した問い合わせに対し引き継
ぎ可能を通知してある），自装置をデータ変更可能とし
（同Ｓ１４），依頼元の処理を引き継ぎ，処理を実行す
る（同Ｓ１５）。

【００７７】次に図２２により状態監視の処理フローを
説明する。この処理は図２の４２（状態監視処理部）の
機能に対応し，図７の監視装置において実行される。要
求イベント通知を待ち合わせて（図２２のＳ１），ポイ
ント状態（監視対象のセンサ出力または設備の状態）通
知であるか判定し（同Ｓ２），ポイント状態通知の場合
はスキャニングメモリ（図２の４４）のポイント状態
（前回の状態）から変化があるか判定し（図２２のＳ
３），変化があるとスキャニングメモリに状態を反映し
（同Ｓ４），そのポイント状態の変化が連動トリガに関
して自装置主催の連動であるか判別する（同Ｓ５）。こ
の場合，連動処理部（図２の４１）の連動条件を参照し
て判別する。自装置の主催の連動である場合は，連動処
理（後述する図２３）に状態変化を通知し（同Ｓ６），
そうでない場合は，他装置の連動処理に状態変化を通知
する（同Ｓ７）。

【００７８】要求イベントがポイント状態通知でない場
合，制御要求（監視装置の配下の設備装置からの制御要
求）であるか判別し（同Ｓ８），該当すると他装置（他
の監視装置）配下の収集装置の制御であるか判別し（同
Ｓ９），他装置の場合は通信処理部を経由して他装置に
制御要求を行い（同Ｓ１０），自装置配下の場合は該当
する収集装置に制御要求を行う（同Ｓ１１）。

【００７９】図２３は連動機能の処理フローである。こ
の処理は図２の４１（連動処理部）の機能に対応し，図
７の監視装置において実行される。イベント通知を待ち
合わせ（図２３のＳ１），イベント通知を受け取ると他
装置からの連動ポイントの通知であるか判定し（同Ｓ
２），該当すると連動スキャニングメモリ（図２の４
３）に他装置の連動ポイントの状態を書き込む（同Ｓ
３）。続いて，連動条件の内，自装置内のポイントは上
記のスキャニングメモリを読み込み，条件の成立を確認
する（同Ｓ４）。これにより，自装置内の条件成立した
か判定し（同Ｓ５），成立した場合，他装置（監視装
置）内の条件が存在するか判定する（同Ｓ６）。存在す
る場合，連動条件のうち他装置内のポイントを連動スキ
ャニングメモリ（図２の４３）を読み込んで条件成立を
確認する（同Ｓ７）。これにより他装置の条件が成立す
るか判別し（同Ｓ８），成立すると状態監視処理（上記
図２２）に制御依頼を行う（図２３のＳ９）。

【００８０】図２４は連動制御を行う場合の各処理及び
メモリの相互の関係を示す図であり，図中，４０〜４４
は上記図２の同じ符号で表す各部に対応し，点線は他監
視装置からの入力設備状態通知やその書き込み操作を表
し，実線は自装置で検出した設備状態通知や制御要求，
及び連動処理部４１によるメモリ参照動作を表す。各動
作は上記図２２，図２３に示す処理フローに示されてお
り，説明を省略する。

【００８１】次に図２５は火災監視の処理フローであ
る。この処理は図３の４６（火災復旧処理部）が備える
複数の監視装置にまたがる火災復旧判定の機能を含み，
図７の監視装置において実行される。

【００８２】図２５において，要求イベント通知を待ち
（図２５のＳ１），要求イベントを受け取るとその要求
イベントがマンマシンインタフェースからの建屋を指定
した火災復旧操作（指定した建屋の火災が復旧したかを
確認する指示）であるか判定し（同Ｓ２），該当すると
関係する他の各監視装置に該当建屋の火災状態要求を発
行して通知を待ち合わせる（同Ｓ３，Ｓ４）。

【００８３】通知を受け取るとその内容が火災中通知か
判定し（同Ｓ５），火災中の通知の場合は建屋が火災中
状態とする（同Ｓ６）。この状態はサーバへ送られて表
示装置に表示される。通知の内容が火災中でない場合，
関係する全ての監視装置からの通知を受けたか判定し
（同Ｓ７），全て火災中でないと火災復旧状態とする
（同Ｓ８）。

【００８４】また，要求イベントがマンマシンインタフ
ェースからの火災復旧操作でなく，火災状態要求（他の
監視装置から上記Ｓ４で発生）である場合は，要求され
た建屋の火災状態を要求元に通知する（同Ｓ９，Ｓ１
０）。

【００８５】図２６は監視装置の火災復旧処理の動作説
明図である。図中，４０，４６，４７は上記図３の各部
に対応し，メモリ４７に各監視装置から通知された火災
状態が格納される。〜は動作の順番を表し，これら
の動作は図２６の火災復旧処理部４６において上記図２
５の処理フローにより実行され，図２５のＳ５，Ｓ８の
判定はメモリ４７に格納された火災状態を参照して行わ
れる。

【００８６】次に図２７乃至図３０は状態監視により収
集したデータの画面への高速反映を行うための各処理内
容を示し，図２７，図２８は表示のための状態監視の処
理フロー（その１），（その２）であり，図４の４２
（監視装置内の状態監視処理部）の機能に対応する。図
２９は収集装置における状態監視制御部（図４の５０）
の処理フローであり，図３０は収集装置における高速状
態通知の処理フローである。

【００８７】図２７，図２８に示す表示のための状態監
視の処理は，要求イベント通知を待ち合わせ（図２７の
Ｓ１），サーバの操作者により表示装置に状態表示を行
う設備（複数）が選択（画面切換え等により実行）され
ると，それらの設備の状態表示要求通知が発行され，監
視装置へ送られてくる。この状態表示要求通知を受け取
ると（同Ｓ２），要求された設備に対応して表示中フラ
グ（監視装置に設けられた各設備状態を表すデータの格
納部内の各データ毎に設定可能）を設定しカウンタを＋
１する（同Ｓ３）。続いて，収集装置の状態監視制御部
に表示中設備（監視装置から状態表示要求された設備）
を通知し（同Ｓ４），収集装置の状態監視制御部からの
状態通知を待ち（同Ｓ５），受け取ると要求元（サー
バ）へ設備状態を通知する（同Ｓ６）。

【００８８】要求イベントが状態表示要求通知でない場
合，次に状態表示消去通知か判定し（同Ｓ7 ），該当す
る場合表示中フラグのカウンタを−１し（同Ｓ８），次
いでカウンタが０か判定し（同Ｓ９），０であると収集
装置の状態監視制御部に消去設備を通知する（図２８の
Ｓ１０）。また，要求イベントが状態表示消去通知でな
い場合，状態変化通知であるか判別し（同Ｓ１１），該
当すると状態変化をマンマシーンインタフェースに通知
する（同Ｓ１２）。

【００８９】図２９は収集装置の状態監視制御部で実行
され，要求イベントを待機して，受け取ると状態表示要
求通知か判別し（図２９のＳ１，Ｓ２），状態表示要求
通知であると，収集装置内の設備対応にフラグを格納で
きるメモリの，指定された設備に対応する表示中フラグ
をオンにし（同Ｓ３），要求元（監視装置）へ設備状態
を通知する（同Ｓ４）。要求イベントが状態表示要求通
知でない場合，状態表示消去通知か判別し（同Ｓ５），
該当すると収集装置内の該当する表示中フラグをオフに
する（同Ｓ６）。該当しなければ，要求イベント通知の
待ち合わせに戻る。

【００９０】図３０は収集装置において実行される高速
状態通知の処理であり，最初に１秒間隔で周期起床を待
ち合わせた後（図３０のＳ１），表示中フラグがオンで
ある設備について状態変化が発生したか判定する（同Ｓ
２）。状態変化がないと次の設備について調べるが，状
態変化が発生すると監視装置の状態監視処理に状態変化
を通知する（同Ｓ３）。全ての設備についてＳ2 ，Ｓ３
の処理を実行して，終了すると（同Ｓ４），Ｓ１に戻
る。

【００９１】図３１はサーバ，監視装置，収集装置によ
る高速表示のための動作説明図であり，上記図２７〜図
３０に示す処理フローにより実行され，図中，１，４，
４０，４２，４８及び５，５０，５１は上記図４に示す
同一の各符号に対応し，〜に示すように表示中設備
の通知が行われると，監視装置４のメモリ内の表示中フ
ラグがオンに設定され，更に状態監視処理部から各収集
装置５に表示中設備の通知が送られて，収集装置のメモ
リ内の表示中フラグがオンに設定される。設定された表
示中フラグを見て対応する設備の状態変化については，
収集装置の状態監視制御部が高速に監視装置に通知し，
監視装置からサーバへ送られて表示が行われる。

【００９２】

【発明の効果】本発明の第１の構成によれば施設管理シ
ステムにおいてマスタサーバとスレーブサーバで常にデ
ータを整合して保持し，同時平行してデータの展開処理
を行うことにより通信の負荷を増加させることがない。
また，マスタサーバがダウンしても最小限のタイムラグ
で他のサーバにより機能のバックアップが可能となる。

【００９３】さらに，第１の構成によりサーバに過負荷
が発生してもダウンする前に検出して，他の負荷が軽い
サーバにより機能を引き継ぐことができるため，システ
ムの信頼性を向上することができ，機能に応じて異なる
サーバがマスタサーバとなることができる。

【００９４】本発明の第２の構成によれば，施設管理の
状態変化により連動機能を働かせる必要がある場合に，
連動条件の成立を高速に判定することができ，連動機能
を組み込んだ施設管理システムの構築を低コストで提供
することが可能となる。

【００９５】本発明の第３の構成によれは，複数の建屋
を複数の監視装置で監視する場合に，監視装置間で最小
の通信回数により，最小限の時間で火災復旧の確認を行
うことが可能となる。

【００９６】本発明の第４の構成によれば施設管理シス
テムの操作者（管理者）が表示装置に表示している設備
の状態については，全設備の状態変化のデータを収集す
るまで待つことなく，高速に収集されて通知されるので
状態変化後に直ちに表示することができる。

【図面の簡単な説明】

【図１】本発明の第１の原理構成図である。

【図２】本発明の第２の原理構成図である。

【図３】本発明の第３の原理構成図である。

【図４】本発明の第４の原理構成図である。

【図５】本発明が実施される施設管理システムの構成図
である。

【図６】サーバのハードウェア構成を示す図である。

【図７】監視装置のハードウェア構成を示す図である。

【図８】収集装置のハードウェア構成を示す図である。

【図９】データ参照・更新受付の処理フローを示す図で
ある。

【図１０】データ参照・更新の処理フロー（その１）を
示す図である。

【図１１】データ参照・更新の処理フロー（その２）を
示す図である。

【図１２】定刻起動の処理フローを示す図である。

【図１３】データ展開の処理フロー（その１）を示す図
である。

【図１４】データ展開の処理フロー（その２）を示す図
である。

【図１５】通信の処理フロー（他装置送信）を示す図で
ある。

【図１６】通信の処理フロー（受信）を示す図である。

【図１７】通信の処理フロー（ヘルスメッセージ送信）
を示す図である。

【図１８】通信の処理フロー（ヘルスメッセージ受信）
を示す図である。

【図１９】過負荷時の処理フロー（その１）を示す図で
ある。

【図２０】過負荷時の処理フロー（その２）を示す図で
ある。

【図２１】負荷監視の処理フローを示す図である。

【図２２】状態監視の処理フローを示す図である。

【図２３】連動機能の処理フローを示す図である。

【図２４】連動制御を行う場合の各処理及びメモリの相
互の関係を示す図である。

【図２５】火災監視の処理フローを示す図である。

【図２６】監視装置の火災復旧処理の動作説明図であ
る。

【図２７】表示のための状態監視の処理フロー（その
１）を示す図である。

【図２８】表示のための状態監視の処理フロー（その
２）を示す図である。

【図２９】収集装置における状態監視制御部の処理フロ
ーを示す図である。

【図３０】収集装置における高速状態通知の処理フロー
を示す図である。

【図３１】サーバ，監視装置，収集装置による高速表示
のための動作説明図である。

【図３２】従来の施設管理システムの構成例を示す図で
ある。

【図３３】従来の連動トリガ行う場合の説明図である。

【図３４】防災の処理速度を高速化するためのシステム
構成例を示す図である。

【符号の説明】

１ マスタサーバ １１ マスタデータベース １２ データ参照・更新受付処理部 １３ データ参照・更新処理部 １４ 通信処理部 １５ データ展開処理部 １６ 定刻起動処理部 １７ 負荷監視処理部 ２ スレーブサーバ ２１ スレーブデータベース ２２ データ参照・更新処理部 ２３ 通信処理部 ２４ データ展開処理部 ２５ 定刻起動処理部 ２６ 負荷監視処理部 ３ ＬＡＮ等のネットワーク ４ 監視装置 ５ 収集装置 ６ 線路

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成６年１０月３１日

【手続補正１】

【補正対象書類名】図面

【補正対象項目名】全図

【補正方法】変更

【補正内容】

【図１１】

【図１２】

【図１６】

【図１】

【図２】

【図５】

【図１５】

【図１８】

【図３】

【図４】

【図６】

【図１７】

【図７】

【図８】

【図２０】

【図２１】

【図９】

【図１０】

【図２８】

【図２９】

【図１３】

【図１４】

【図３０】

【図３３】

【図１９】

【図２２】

【図３４】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７】

【図３１】

【図３２】

Claims (12)

【特許請求の範囲】
1. 【請求項１】 それぞれ入出力装置，データベース及び
   処理装置を備えた複数のサーバと，設備の状態を収集す
   ると共に制御を行う複数の監視装置がネットワークで接
   続された施設管理システムにおいて，前記サーバとして
   管理機能に応じて一つのマスタサーバと複数のスレーブ
   サーバとを設定し，各サーバにデータ参照・更新処理部
   を備え，マスタサーバのデータ参照・更新処理部は，要
   求に応じてデータを更新すると，ネットワークを介して
   更新データを各スレーブサーバに送信し，各スレーブサ
   ーバのデータ参照・更新処理部は受け取った更新データ
   により自サーバのデータベースを更新して前記マスタサ
   ーバに通知し，各サーバは管理対象施設のスケジュール
   を自サーバのデータベースのデータを用いて作成するデ
   ータ展開処理部と，予め設定された時間になると前記デ
   ータ展開処理部を起動する定刻起動処理部を備えること
   を特徴とする施設管理システムにおける分散処理方式。
2. 【請求項２】 請求項１において，前記マスタサーバの
   データ展開処理部は，起動すると前記データ参照・更新
   処理部に通知して参照・更新処理を禁止して，データ展
   開処理を実行してデータベースのレベルを更新し，前記
   スレーブサーバのデータ展開処理部は，起動するとマス
   タサーバにレベルを問い合わせて一致するとデータ参照
   ・更新処理部に通知して参照・更新処理を禁止して，デ
   ータ展開処理を実行してデータベースのレベルを更新し
   てマスタデータベースへレベルを通知することを特徴と
   する施設管理システムにおける分散処理方式。
3. 【請求項３】 請求項１において，前記ネットワークを
   介する通信を行う通信処理部を各サーバに備え，前記ス
   レーブサーバの通信処理部は，一定時間マスタサーバと
   通信が行われないことを検出すると，ヘルスチェックメ
   ッセージをマスタサーバと送受信し，マスタサーバの正
   常性を確認することを特徴とする施設管理システムにお
   ける分散処理方式。
4. 【請求項４】 請求項２において，前記スレーブサーバ
   によるマスタサーバの正常性の確認において，マスタサ
   ーバのダウンを検出すると，前記スレーブサーバは自サ
   ーバをマスタサーバとし，前記ダウンしたマスタサーバ
   をスレーブサーバとするよう設定し，他のスレーブサー
   バに対し前記切換えを通知することを特徴とする施設管
   理システムにおける分散処理方式。
5. 【請求項５】 それぞれ入出力装置，データベース及び
   処理装置を備えた複数のサーバと，設備の状態を収集す
   ると共に制御を行う複数の監視装置がネットワークで接
   続された施設管理システムにおいて，前記サーバとして
   管理機能に応じて一つのマスタサーバと複数のスレーブ
   サーバとを設定し，各サーバに負荷監視処理部を設け，
   前記負荷監視処理部は，自サーバ内の処理装置（ＣＰ
   Ｕ）の負荷を監視し，予め設定された率を越えたことを
   検出すると，他のサーバに対し処理引き継ぎを問い合わ
   せ，他のサーバから引き継ぎ可の応答を受け取ると前記
   サーバに対し自サーバの機能の処理依頼を通知すること
   を特徴とする施設管理システムにおける分散処理方式。
6. 【請求項６】 請求項５において，前記各サーバは，管
   理機能に応じて予め過負荷時に処理機能を代替するサー
   バの優先順位が設定され，過負荷状態になると前記優先
   順位に従って他のサーバに処理引き継ぎを問い合わせる
   ことを特徴とする施設管理システムにおける分散処理方
   式。
7. 【請求項７】 請求項５または６において，前記処理引
   き継ぎの問い合わせを受けた他のサーバは，自サーバの
   処理装置の負荷をチェックし，予め設定された一定の負
   荷率以下であるか否かにより処理引き継ぎ可か，処理引
   き継ぎ不可の応答を問い合わせ元に通知することを特徴
   とする施設管理システムにおける分散処理方式。
8. 【請求項８】 それぞれ入出力装置，データベース及び
   処理装置を備えた複数のサーバと，設備の状態を収集す
   ると共に制御を行う複数の監視装置がネットワークで接
   続された施設管理システムにおいて，各監視装置は監視
   対象の設備の状態を検出すると共に制御を行う複数の収
   集装置と接続され，各収集装置からの状態監視を行う状
   態監視処理部と，自監視装置管理下の設備状態と他監視
   装置の管理下の設備状態により自監視装置または他監視
   装置の設備を制御する処理を行う連動処理部とを備え，
   前記連動処理部は連動条件を保持し，連動条件内に他監
   視装置管理下の設備状態が含まれていると，他監視装置
   に前記設備を指定して状態変化を通知する要求を発生し
   て，他監視装置から前記指定された設備の状態変化の通
   知を受け取ることにより複数監視装置にまたがる連動条
   件の成立を判定することを特徴とする施設管理システム
   における分散処理方式。
9. 【請求項９】 請求項８において，前記監視装置に，前
   記他監視装置から通知された前記指定された設備の状態
   変化を表すデータを格納する連動スキャニングメモリ
   と，前記状態監視処理部が管理下の収集装置から得られ
   た各設備の状態を表すデータを格納するスキャニングメ
   モリとを備え，前記状態監視処理部は，設備状態の変化
   を検出すると前記連動処理部の連動条件に該当するかチ
   ェックし該当すると前記連動処理部に通知し，前記連動
   処理部は，連動スキャニングメモリへの状態変化の書き
   込み時と前記状態監視処理部からの通知により連動条件
   の成立を判定して，成立すると自監視装置または他監視
   装置の設備の制御要求を発生することを特徴とする施設
   管理システムにおける分散処理方式。
10. 【請求項１０】 それぞれ入出力装置，データベース及
    び処理装置を備えた複数のサーバと，設備の状態を収集
    すると共に制御を行う複数の監視装置がネットワークで
    接続された施設管理システムにおいて，前記監視装置
    は，サーバから発生する建屋の火災復旧確認の指示を受
    け取ると，建屋に関して火災復旧状態か否かの確認を行
    う火災復旧処理部を備え，前記火災復旧処理部は，前記
    指示を受け取ると建屋を管理する他の監視装置に対し該
    他の監視装置が収集した当該建屋の火災状態を通知する
    よう要求を発行し，前記他の監視装置から火災状態通知
    を受け取ると，該火災状態通知の内容及び自監視装置で
    収集した火災状態を識別して火災復旧状態か火災中状態
    かを判別することを特徴とする施設管理システムにおけ
    る分散処理方式。
11. 【請求項１１】 請求項１０において，前記火災復旧処
    理部に火災状態を記憶するメモリを備え，前記他の監視
    装置から通知された火災状態通知及び自監視装置で収集
    した火災状態を前記メモリに格納し，前記メモリに格納
    された各監視装置からの火災状態を判別して火災復旧状
    態か火災中状態かを判別することを特徴とする施設管理
    システムにおける分散処理方式。
12. 【請求項１２】 それぞれ入出力装置，データベース及
    び処理装置を備えた複数のサーバと，設備の状態を収集
    すると共に制御を行う複数の監視装置がネットワークで
    接続された施設管理システムにおいて，サーバにおいて
    表示装置で状態表示を行う設備が指定されるとサーバか
    ら監視装置に対し指定された設備の状態表示要求を送信
    し，前記監視装置の状態監視処理部は，表示中フラグを
    設定するメモリを備え，前記状態表示要求通知を受け取
    ると指定された設備に対応する表示中フラグをオンに設
    定すると共に，前記設備を管理下におく収集装置に対し
    状態表示要求通知を送信し，前記収集装置は，管理下の
    設備に対応する表示中フラグを設定するメモリを備え，
    前記監視装置からの状態表示要求通知を受け取ると，指
    定された設備に対応する表示中フラグをオンに設定し，
    状態監視制御の動作において前記表示中フラグがオンに
    設定された設備の状態変化については通常より高速の周
    期で前記監視装置に通知し，前記監視装置は通知された
    設備の状態変化を要求元のサーバへ送信することを特徴
    とする施設管理システムにおける分散処理方式。