JP7262036B1 - ビル管理システム - Google Patents

Abstract

【課題】より効果的にビル管理を行うことができるビル管理システムを提供する。【解決手段】複数の管理項目（空調、照明、衛生、警報、エネルギーなど）のいずれかに分類される複数種類の設備機器（エアコン、照明機器、扉、無線式センサー装置等のセンサー類、スイッチ類、その他の電気機器類など）と、複数種類の検出項目（温度、湿度、照度、加速度、コンタクトなど）の検出が可能な無線式センサー装置と、昇順に上位層となる第１階層装置（マイクロ・エッジ・デバイス６０など）、第２階層装置（アプリケーション・エッジ・デバイス６２など）、第３階層装置（統合・エッジ・デバイス６４など）、第４階層装置（エンタープライズ・エッジ・サーバー６６など）のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備えた。【選択図】図１

Description

本発明は、例えば、情報通信網を介してビル管理を行うビル管理システムに関する。

例えば、後掲の特許文献１には、ネットワーク分散型のビル管理システムに係る発明が開示されている。特許文献１に開示された発明においては、段落００１７や図１に記載されているように、パソコン等の通信端末機（１）からインターネット等の既存のネットワーク（Ｌ１）やビルディングサーバ（２）を介して、ビル内設備機器が監視される。

特開２００３－１３４１２０号公報

ところで、ビルの改修の際には、既存の設備機器（センサー類やスイッチ類を含む）を新しいものに変更する作業が発生する。特許文献１に開示されたような従来のネットワークシステムや、従来のビル管理システムでは、共通の通信規格に対応するよう設計されている設備機器を管理することはできても、それ以上の多くの種類の設備機器に対応することまではできていなかった。例えば、特許文献１に開示された発明では、メーカー毎の設備制御機器の選定が必要である（段落０００９）。そして、近年におけるインテリジェントビルの管理や、多棟管理を想定した場合には、監視点数が膨大になるため、従来の技術によったのでは、総合的なビル管理には対応することができなかった。

本発明の目的とするところは、より効果的にビル管理を行うことができるビル管理システムを提供することにある。

上記目的を達成するために本発明に係るビル管理システムは、
複数の管理項目のいずれかに分類される複数種類の設備機器と、
複数種類の検出項目の検出が可能なセンサー装置と、
昇順に上位層となる第１階層装置、第２階層装置、第３階層装置、第４階層装置のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
少なくとも１つの前記管理項目を１つの項目系として複数の項目系を定めることが可能であり、
複数の前記項目系が、少なくとも、空調系、照明系、警報系、及び、エネルギー系を含む、ビル管理システムであって、
前記センサー装置が複数備えられ、
複数の前記センサー装置が、
少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力可能であり、
複数の前記項目系に跨るセンサー装置群を構成し、
前記第１階層装置で共通仕様の通信規格に基づき統一化された情報が前記第２階層装置へ送出され、
前記第２階層装置が、
所定のアプリケーションソフトを用いて前記第１階層装置からの前記情報をデータベース化することが可能である。

上記発明によれば、より効果的にビル管理を行うことができるビル管理システムを提供することができる。

本発明の一実施形態に係るビル管理システムを概略的に示す説明図である。 無線式センサー装置の構成を概略的に示すブロック図である。 データベースの作成手順を概略的に示すフローチャートである。 データベースの情報を概略的に示す説明図である。

＜実施形態に係るビル管理システムの概要＞
以下、本発明の実施形態に係るビル管理システムについて説明する。本実施形態のビル管理システムは、空調（エアコン）、照明、衛生、警報（セキュリティー）、エネルギー等といった各種の管理項目を、ビル内やビル外、及び、遠隔地から自在に、一元管理したり、分散制御したりすることを可能としている。

本実施形態のビル管理システムは、ビル内の各設備機器を含んでいる。設備機器には、例えば、エアコン、照明機器、扉等のように様々な設備機器が含まれている。また、設備機器には、部屋内の温度を検出する温度センサー、湿度を検出する湿度センサー、照明機器の照度を検出する照度センサー、扉の開閉を検出するコンタクトセンサーなど（センサー類）も含まれる。

また、設備機器には、エアコンの操作パネルやリモコン（リモートコントローラ）、照明の操作パネルやリモコン、壁に設置された各種のスイッチなど（スイッチ類）も含まれる。さらに、設備機器には、電力の使用状況の把握に係る変流器、電力量モニタ、サーキットプロテクタ、パワー・サプライ・ユニット、コンパクト・ゲートウェイなど（その他の電気機器類）も含めることが可能である。

これらは設備機器の一例であり、一般にビル管理に用いられるその他の機器も、本実施形態の設備機器に含めることが可能である。

本実施形態のビル管理システムでは、各設備機器により収集された情報に基づき、ビルの設備機器の監視を行うビル管理者や、各設備機器の一般利用者（フロアや区画を利用するテナントの社員など）が、自ら所有する情報携帯端末（スマートフォンやタブレットなど）から、設備機器を選択して指示（コマンド）を入力する、といったことを可能としている。

さらに、本実施形態のビル管理システムにおいては、ビル管理のためのソフトウェア（アプリケーションソフトを含む）の種類が、システムの統合により、最小限に止められている。また、本実施形態のビル管理システムにおいては、全体の監視を可能とする監視システムが標準装備されている。

当たり前のことのように思えるかもしれないが、従来のビル管理システムでは、メーカー（製造業者）やベンダー（販売業者）毎の各種情報の仕様（信号規格、通信規格、ＯＳ（オペレーティング・システム）、プログラミング言語など）の違いに関わらず、横断的に（横方向に跨って）情報を収集して、ビル管理者や、設備機器の一般利用者等に対し、統合されたサービスを提供することは難しかった。本実施形態のビル管理システムは、このことを可能とした。

より具体的には、本実施形態のビル管理システムは、「ビル内監視ルーム（中央監視ルーム）からの解放」を図っている。これは、従来、ビル内に設置されていた中央監視ルームを廃止したり、中央監視に係る人員を一人等のように最小限に止めたりすることが可能であることを意味している。

従来のビル管理システムにおいては、ビル内に中央監視ルームが不可欠であった。しかも、空調、照明、衛生、警報、エネルギー等といった各種の管理項目について設置された機器毎に、独立した管理が行われていた。前述したように、例えば前掲の特許文献１に開示された発明では、メーカー毎の設備制御機器の選定が必要である（段落０００９）。このため、機器類の制御が、システム構成上の縦方向に（縦断的に）は統合できたとしても、メーカーやベンダー毎の各種情報の仕様の違いに関わらず、水平方向に（横断的に）統合することはできず、分断されていた。

図１は、本実施形態のビル管理システム１０の構成を概略的に示している。図中には、設備機器に係る複数の系（項目系）の一例が示されている。図１に示されているのは、空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０である。

空調関連系１２は、エアコン（エアーコンディショナー、空気調和機）や、温度センサー、湿度センサー等といった空調に係る複数の設備機器の系（まとまり、グループ）を示している。

照明・コンセント系１４は、照明機器、照度センサー、商用電源への接続機器等に係る設備機器の系を示している。衛生・水回り系１６は、トイレ、洗面所、給湯等といった衛生や水回りに係る複数の設備機器の系を示している。

状態・警報系１８は、ドアの開閉、地震、権限のない者の侵入等に対処に係る複数の設備機器の系を示している。エネルギー系２０は、使用電力量（電力消費量）や、太陽光発電量、燃料使用量等の把握に係るセンサー類やスイッチ類等の複数の設備機器の系を示している。

ここで、項目系の分類は、上述の例に限られるものではない。例えば、「空調・照明・コンセント系」のように、複数の系を統合してもよい。また、「照明系」、「コンセント系」、「衛生系」、「水回り系」のように、それぞれを独立させてもよい。さらに、「空調１」、「空調２」、「照明１」、「照明２」のように分割してもよい。

上述したような各種の項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）では、様々なメーカーやベンダーの設備機器が用いられるのが一般的である。このため、従来は、各項目系において、メーカーやベンダー毎に、情報通信の抱え込みが生じており、ビルの改修工事や新築工事の際には、メーカーやベンダーの指定の工事業者に工事を発注する必要があった。

また、メーカーやベンダー毎には共通の信号規格や通信規格が使用されていることが多い。このため、メーカーやベンダー毎に、共通の信号規格、通信規格、ＯＳ、プログラミング言語などを用いて管理システムを構築することは可能である。また、マルチプロトコル通信規格に対応するよう予め定められた設備機器を用いた場合には、それらの設備機器のみを統合的に取り扱うことは可能である。しかし、これらの場合は、メーカーやベンダーに対応したサーバーを設置して、管理システムを構築する必要がある。

例えば、１つの項目系（例えば空調関連系１２など）において、複数のメーカーやベンダーの設備機器が採用されている場合には、１つの項目系につき複数のサーバーを設置して、複数の管理システムを構築する必要があった。

また、例えば、各項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）毎に、メーカーやベンダーが統一されているような場合は、項目系毎にサーバーを設置して、管理システムを構築する必要があった。

このように、メーカーやベンダー毎の統合（システム構成上の縦方向の統合）は比較的容易にできるが、各項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）を横断した統合（システム構成上の横方向の統合）は容易ではなかった。そして、従来のビル管理システムにおいては、ＩＴ（情報技術）とＯＴ（運用技術）が分離されていた。

図１に示す本実施形態のビル管理システム１０は、各種の管理項目に係る設備機器の項目を統合し、且つ、適正なクラウド化を行うことで、中央監視ルームを廃止可能としている。本実施形態のビル管理システム１０は、各種の管理項目を、ビル管理者のスマートフォンやタブレット等の携帯情報端末２２から、多数のアプリケーションソフトをインストールすることなく、遠隔で監視できるようにしている。この結果、中央監視ルームに人を縛り付ける必要がなくなり、管理に要する人員の人数や人件費の削減が可能となった。

また、本実施形態のビル管理システム１０は、テナントの社員などの一般利用者も、所定の管理項目を、スマートフォンやタブレット等の携帯情報端末２４から、多数のアプリケーションソフトをインストールすることなく、遠隔で操作できるようにしている。

＜階層構造＞
図１に示すように、本実施形態に係るビル管理システム１０は、大きく分けて、レベル０～レベル４の５つの階層構造を有している。レベル０はセンサーの階層であり、レベル１はセンサー・コントローラー（マイクロ・エッジ・デバイス）の階層である。レベル２はアプリケーション・エッジ・デバイスの階層であり、レベル３は統合コントローラー（統合・エッジ・デバイス）の階層である。レベル４は、エンタープライズ・エッジ・サーバーの階層である。以下に各階層について説明する。

＜レベル０：センサー＞
ビル管理システム１０の最も下位レベルの階層はセンサーである。従来、例えば、温度や湿度等といった各種のアナログ情報をデジタル情報に変換するために、シーケンサーを設け、各種の情報に対する閾値を設定して管理する必要があった。

センサーから送出されるデータは、閾値、電流値、レンジ変換等といったいろいろな要素が加わり、一つの塊として形成されている。つまり、シーケンサーの中でデータが処理され、設計者や作業者により閾値が設定され、出力されたデータの一部がビル管理に使用されるだけであった。

従来型のビル管理システムの特徴といってもよいが、従来のビル管理システムは、機器間を物理的に接続して、特定のシリアルバス（RS485）で繋いでいるだけであった。通信は、シリアルバス（RS485）のインターフェースを使って行われており、信号処理は、ＣＰＵを持たない通信用チップを使用して行われていた。このため、従来のビル管理システムには、限られた機能しか備えられておらず、インテリジェンスに欠けていた。

本実施形態に係るビル管理システム１０では、レベル０のセンサーとして、図２に示すような、無線式のインテリジェントセンサー装置（以下では「無線式センサー装置」と称する）３０が用いられている。無線式センサー装置３０は、複数種類（例えば、温度、湿度、照度、加速度、コンタクトの５種類）の検出項目（物理量）の検出が可能である。

無線式センサー装置３０は、複数の項目系（例えば、空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）において使用されている。さらに、無線式センサー装置３０には、複数の機種があり、それぞれの通信規格で無線通信を行う。このため、無線式センサー装置３０には、異なる通信規格で無線通信を行うものが含まれる。さらに、無線式センサー装置３０については、マルチプロトコル対応の設計がされているか否かは問題とならない。

無線式センサー装置３０は、例えば、ビルの壁面、天井、及び、ドア等に設置され、検出した情報をレベル１のセンサー・コントローラー（後述する）に無線送信する。無線式センサー装置３０としては、複数のメーカーやベンダーから提供されている各種のものを混合して採用することが可能である。

無線式センサー装置３０は、図２に示すように、内部に、温度センサー部３２、湿度センサー部３４、照度センサー部３６、加速度センサー部３８、及び、コンタクトセンサー部４０を備えている。さらに、無線式センサー装置３０は、ＣＰＵ４２、記憶部４４、情報形式変換部４６、情報入力部４８、無線通信部５０、及び、発電部５２等を備えている。

温度センサー部３２は、温度センサーを備えており、例えば、室内の空気等の温度を検出可能である。湿度センサー部３４は、湿度センサーを備えており、例えば、室内の空気等の湿度を検出可能である。照度センサー部３６は、照度センサーを備えており、例えば、室内等の明るさを検出可能である。

加速度センサー部３８は、加速度センサーを備えており、例えば、壁に伝わる衝撃等を検出可能である。コンタクトセンサー部４０は、コンタクトセンサー（マグネットコンタクトセンサー）を備えており、例えば、ドアの開閉等を検出可能である。

無線式センサー装置３０に備えられる温度センサー、湿度センサー、照度センサー、加速度センサー、及び、コンタクトセンサーとしては、一般的な各種のセンサーを採用することが可能である。

無線式センサー装置３０においては、エネルギー・ハーベスティング技術を利用して発電し、無線送信する通信規格（EnOcean）が採用されている。無線式センサー装置３０においては、発電部５２の発電（ここでは光発電）により、ＣＰＵ４２やセンサー部３２、３４、３６、３８、４０の正常な動作に必要な電力が供給される。

無線式センサー装置３０は、どの検出項目の検出機能を使用するかを選択することが可能である。また、無線式センサー装置３０は、すべての検出機能を同時に使用することも可能である。

使用する検出機能の設定は、選択された検出機能を識別する情報（検出機能識別情報）を記憶部４４に記憶させて行われる。上記検出機能識別情報の記憶は、無線通信が可能な外部通信機器を利用して行うことが可能である。

上述の外部通信機器としては、例えば、スマートフォンやタブレット端末等の携帯情報端末（携帯情報端末２２、２４など）を例示できる。この場合、携帯情報端末に、所定のアプリケーションソフトをインストールし、このアプリケーションソフトを操作することにより行うことが可能である。所定のアプリケーションソフトには、ビル管理者が使用する管理者用機器管理アプリや、一般利用者用機器管理アプリなどがある。

無線式センサー装置３０においては、ＣＰＵ４２の情報処理により、使用されるセンサー部（センサー部３２、３４、３６、３８、４０のうちの少なくとも一部）の信号が、工業単位の情報に変換され、デジタルデータが生成される。無線式センサー装置３０においては、生成されたデジタルデータを利用して無線パケットが作成され、無線パケットが、後述するレベル１のセンサー・コントローラー（マイクロ・エッジ・デバイス）に送られる。

温度センサー部３２、湿度センサー部３４、照度センサー部３６などのように、連続量を検出するセンサー部については、情報の送信は、所定時間（例えば数十秒～３分など）毎に行われる。また、加速度センサー部３８やコンタクトセンサー部４０の信号に係る情報の送信は、所定の閾値に達するほどの大きさの加速度やコンタクト（接触圧力など）が検出された場合に行われる。

温度センサー部３２、湿度センサー部３４、照度センサー部３６など情報送信間隔を大きくするほど、情報送信量を減らすことができる。上記の所定時間内に、温度センサー部３２、湿度センサー部３４、照度センサー部３６に係る情報を送信してもよく、上記の所定時間毎に、温度センサー部３２、湿度センサー部３４、照度センサー部３６係る情報を順に送信してもよい。

従来のビル管理システムにおいて、情報通信の無線化は、頻繁なバッテリー（電池）交換が必要になることや、無線信号が途切れること等の問題により、敬遠されることが多かった。本実施形態のビル管理システム１０は、このような無線化におけるバッテリーの課題を、エネルギー・ハーベスティング技術により解決している。

なお、エネルギー・ハーベスティング技術に用いられる発電部５２は、光発電を行うものに限らず、例えば、熱電発電、電磁波発電、振動力発電等であってもよい。

熱電発電においては、例えば、ゼーベック効果（温度差が電圧に変換される現象）を利用した熱電変換素子（熱と電力を変換する素子）が用いられ、物体の温度差が電圧に変換される。例えば、空調装置や、ビル内の配管等から発生する熱が、電気エネルギーに変換される。

電磁波発電においては、例えば、ビル内の無線ＬＡＮなどが発する電波のエネルギーをレクテナ（rectifying antenna）により直流電流に変換して発電が行われる。

振動力発電においては、振動によって発生する圧力が、圧電素子などを介して電力に変換される。例えば、ビルのフロア内に圧力センサーが設置され、人が通路を歩く際に発生する圧力や、振動による圧力が、電気エネルギーに変換される。

なお、本実施形態のビル管理システム１０では、照明をオン／オフするためのスイッチとして、無線式スイッチ（図示略）が使用されている。無線式スイッチは、スイッチ機構部や無線通信部を内蔵しており、エネルギー・ハーベスティング技術を利用して、スイッチ機構部の状態を示す情報を、無線により外部に送信する。

無線式スイッチを管理者や一般利用者が手指で操作することにより、オン／オフの情報（オン／オフ情報）が、誘起電力を利用して無線送信される。無線式スイッチは、ビス止めや、マグネットシートの貼付等の方法により、壁面への設置が可能である。

無線式スイッチを使用することにより、配線を要することなく、照明のオン／オフが可能である。配線不要であることから、スイッチ類の置き場所に制約がなく、スイッチの配置の自由度が高い。加えて、バッテリーが不要であり、このことによっても、多くの手間を要していた電池交換作業が不要になる。

以上のように、必要なセンサー類やスイッチ類に対して、可能な限り多くの無線式センサー装置３０や無線式スイッチを用いることで、配線を引き回して、システムの末端を構成するセンサー類やスイッチ類をシーケンサーに接続する作業が不要になる。このため、センサー類やスイッチ類の設置工事を容易に行うことが可能となる。

センサー類やスイッチ類は、前述の項目系１２、１４、１６、１８、２０の中に多数含まれている。また、１つのビルに使用されるセンサー類やスイッチ類は、フロア内の部屋数等によっても異なるが、ビルのインテリジェント化が進むほど多くなる。

このため、部屋数の多いビルや、高度にインテリジェント化されたビルの改築工事や新築工事の際に、センサー類やスイッチ類の配線作業に要する工数（人員数×時間）は相当な値となる。したがって、無線式センサー装置３０や無線式スイッチを用いることで、配線作業の多くを不要にすることができ、工数を大幅に削減することが可能となる。

従来、配線作業に要する作業内容や工数は、作業現場任せになりがちであり、工期の見積りや、人件費の見積りを不正確にする大きな要因であった。例えば、センサー装置とシーケンサーの間の配線や、シーケンサーと上記の機器の配線等をどのように行うかは、作業現場の判断により行われることが多かった。また、設置されるセンサー装置の数は、ビルの形態や規模によって、数百～数十万といった数に達する。さらに、ビルの改修コストや新築コストの多くの部分は、人件費に依って占められている。したがって、配線に要する工数を削減することは、コスト削減に大きく寄与する。

なお、本実施形態に係るビル管理システム１０では、すべてのセンサーやスイッチ類が無線式であることに限られるものではなく、一部のセンサーやスイッチは有線で信号をシーケンサー等に送出するものであってもよい。また、前述したその他電気機器類には、無線通信するものや有線通信するものが含まれていてもよい。

＜レベル１：センサー・コントローラー（マイクロ・エッジ・デバイス）＞
各無線式センサー装置３０から送信されたデジタルデータは、レベル１のセンサー・コントローラー（マイクロ・エッジ・デバイス６０）により受信される。センサー・コントローラーは、マイクロ・エッジ・デバイス６０により構成される。

本実施形態のビル管理システム１０では、管理対象のビルの規模や棟数等の条件に応じて、複数個のマイクロ・エッジ・デバイス６０が用いられる。図１には、一例として３つのマイクロ・エッジ・デバイス６０が示されている。１つのマイクロ・エッジ・デバイス６０には、例えば、１００個以上（最大２００個程度）の各無線式センサー装置３０の対応付けや、図示は省略するが、有線式のセンサー類やスイッチ類に接続されたシーケンサー類の対応付けが可能である。そして、１つのマイクロ・エッジ・デバイス６０では、１００～２００点程度の監視点数についてのデータ処理が可能である。

従来、例えば、ビルの窓に設置されたブラインドの制御に関して、ブラインド専用のコントローラー（専用コントローラ）が用いられていた。専用コントローラーでは、ブラインド制御プログラムが実行されて、ブラインドの制御に係る処理が行われていた。つまり、ブラインドと専用コントローラーにより構成される制御系において、制御対象（ここではブラインド）の制御が完結していた。

従来より、ビル管理システムにおいては、空調、照明、衛生、セキュリティー、エネルギー等に係る多くの管理項目について監視制御が行われている。これらの管理項目に係る制御（監視制御）においては、前述したように、使用される機器や、機器の製造業者、機種等の違いに応じて、様々な信号規格、通信規格、ＯＳ、プログラム言語等を用いた制御が行われるのが一般的であった。

そして、ビル管理の技術分野において、ＩＴ（情報技術）やＯＴ（運用技術）に関する様々な規格が存在し、これらの規格の内容が異なるため、１つのコントローラーに、既存の各種のセンサー類や、ビルの建設業者が選定したセンサー類等の多種類のセンサー類を通信可能に接続することはできなかった。

これに対し、本実施形態のビル管理システム１０では、すべての情報の出発点となるアナログデータ（無線式センサー装置３０より収集したデータ）が、レベル０の無線式センサー装置３０自身によりデジタル化される。１つのマイクロ・エッジ・デバイス６０に対し、多数の無線式センサー装置３０のデジタル情報が、マイクロ・エッジ・デバイス６０に集約される。

無線式センサー装置３０には、同じデジタル無線通信規格による情報通信を行うものや、互いに異なるデジタル無線通信規格による情報通信を行うものが含まれる。マイクロ・エッジ・デバイス６０は、多数（例えば１５０以上）の数の通信規格（通信プロトコル）を取り扱うことが可能なように構成されている。

マイクロ・エッジ・デバイス６０では、多数の無線式センサー装置３０の情報を、無線式センサー装置３０に採用されている通信規格毎に、共通仕様の通信規格（ここではＩＰ（インターネット・プロトコル））に変換して取り扱うことが可能である。つまり、マイクロ・エッジ・デバイス６０においては、異なる通信規格の信号が入力されて、統一された共通仕様の信号が出力される。マイクロ・エッジ・デバイス６０は、対応付けられた設備機器にＩＰアドレスを割り振り、ＩＰアドレスを用いて識別する。

マイクロ・エッジ・デバイス６０は、個々に、異なる通信規格の信号を集約して共通仕様の信号が出力されるゲートウェイとして機能する。マイクロ・エッジ・デバイス６０を、管理対象のビルの規模や棟数等に応じて多数備えることにより、複数のゲートウェイにより構成されるゲートウェイ群を大規模に形成することが可能である。なお、各項目系１２、１４、１６、１８、２０と、マイクロ・エッジ・デバイス６０との間に、他のゲートウェイ（細分化されたゲートウェイ）が存在する場合もある。ここでいうゲートウェイ群には、マイクロ・エッジ・デバイス６０とは別の機器として存在するゲートウェイも含まれる。マイクロ・エッジ・デバイス６０とゲートウェイとの関係（位置づけ）は、マイクロ・エッジ・デバイスが上位であり、ゲートウェイが下位である。

マイクロ・エッジ・デバイス６０では、無線式センサー装置３０からの情報が吸い上げられ、必要な情報の整理が行われて、上層のアプリケーション・エッジ・デバイス６２（レベル２）に送信される。マイクロ・エッジ・デバイス６０の階層（レベル１）では、例えば、多数のマイクロ・エッジ・デバイス６０によりマイクロ・エッジ・デバイス群６０Ａが構成される。マイクロ・エッジ・デバイス群６０Ａは、概念上、前述のゲートウェイ群に含まれものとすることができる。

マイクロ・エッジ・デバイス群６０Ａは、ゲートウェイの機能を発揮してデータの変換（コンバート）を行い、統一化された仕様の情報（パターン化された形式の情報）を上層の、対応付けられたアプリケーション・エッジ・デバイス６２に送信する。

このように、無線式センサー装置３０やシーケンサー類によりデジタル化されたアナログデータは、マイクロ・エッジ・デバイス６０で前段階処理され、統一化された仕様の情報となって上位層に送出される。マイクロ・エッジ・デバイス６０では、末端の無線式センサー装置３０でデジタル化された情報が、レベル２でのデータベース化のために前段階処理される。

マイクロ・エッジ・デバイス６０としては、図示は省略するが、例えば、ＣＰＵ、記憶部、無線通信部等を備え、マルチプロトコルのデジタル情報を、時分割等の処理や、情報変換の処理により、共通の通信規格に変換するものを採用できる。

＜レベル２：アプリケーション・エッジ・デバイス＞
マイクロ・エッジ・デバイス６０の上層（レベル２）にあるのがアプリケーション・エッジ・デバイス６２である。アプリケーション・エッジ・デバイス６２は、ビルの空調、電気、衛生、中央監視等といった管理項目（アプリケーション）毎にデータを集める役割を担う。

前述したように、マイクロ・エッジ・デバイス６０（レベル１）において、センサー（レベル０）のデータが集約され、センサー（レベル０）でデジタル化されたデータが、マイクロ・エッジ・デバイス６０（レベル１）からアプリケーション・エッジ・デバイス６２（レベル２）に送出される。

管理対象のビルの規模にもよるが、例えば、１００個程度のマイクロ・エッジ・デバイス６０に対して、１つのアプリケーション・エッジ・デバイス６２が設置される。所謂中小ビルのレベルであれば、１台のアプリケーション・エッジ・デバイス６２により、ビル全体の管理が可能である。この場合、後述のレベル３及びレベル４は省略することが可能である。

アプリケーション・エッジ・デバイス６２には、中央監視機能が備えられている。中央監視機能は、エネルギー・マネジメント・システム（ＥＭＳ）の監視や制御のための処理を行い、得られた情報を外部機器に提供できるようにした機能である。中央監視機能部により、各無線式センサー装置３０で収集された情報に基づき、電力量等の情報がリアルタイムに処理され、統計的に視覚化されて、表示可能な情報として出力される。つまり、エネルギー・マネジメント・システム（ＥＭＳ）の監視・制御システムが、アプリケーション・エッジ・デバイス６２の中に組み込まれている。

アプリケーション・エッジ・デバイス６２では、図３に示すように、マイクロ・エッジ・デバイス６０から送られた情報が、データベース作成用のソフトウェアに読み込まれ（Ｓ(ステップ)１１）、自動的にデータベースが作成される（Ｓ１２）。さらに、個別の認識データの設定（パラメータ設定など）には、プロダクティビティ・ツールが用いられている。

プロダクティビティ・ツールは、本実施形態のビル管理システム１０で使用されるアプリケーションソフトの１つとして開発されたものである。プロダクティビティ・ツールについては後述する。データベース作成用のソフトウェアとしては、一般的な種々のものを採用できる。

作成されたデータベースには、図４に示すように、収集されたデータの各種の属性（プロパティを含む）が記録されている。記録される属性としては、ＩＰアドレス、ビル名、フロア、エリア、管理項目、情報種別、情報取得日、情報取得時刻などの情報が含まれる。また、センサー類の情報である場合には、各センサーの検出値などの情報（検出値情報）や、オン／オフの情報なども含まれる。

従来、インテリジェントセンサーや、マイクロ・エッジ・デバイス６０への設定データの登録は、一つずつ手作業で打ち込む必要があった。このような作業は、打ち込み作業そのものが多くの手間を要するほか、データの特性や仕組み等を理解していなければ行うことができなかった。本実施形態のビル管理システム１０によれば、自動的にデータベースが作成されるので、手作業や、仕組み等の理解を要することなく、データ登録を行うことが可能である。

さらに、アプリケーション・エッジ・デバイス６２では、中央監視機能部を用いて、データベース化された情報に基づき、各設備機器から収集した温度や湿度、電力量といった情報をリアルタイムに、統計的に視覚化して表示するための情報を出力できる。出力された情報は、インターネット回線（公衆無線通信回線、及び、公衆有線通信回線）６８を介して、ビル管理者のＰＣ（パーソナルコンピュータ）に接続された表示装置や、携帯情報端末などに表示される。ビル管理者のＰＣや携帯情報端末にインストールされているブラウザを介して、中央監視用アプリケーションソフトへの接続が行われる。

前述のＥＭＳ（エネルギー・マネジメント・システム）は、情報の見える化を行っている。すなわち、センサーや照明、空調、衛生、エネルギーといった各機器から集められた情報は、それらが単に存在するだけでは価値を生まない。これらのデータ（情報）を、種類別に分類し、必要な部分、必要な時間だけを集計し、統計処理した上で、画面表示してこそ価値が生まれる。

本実施形態のビル管理システム１０におけるＥＭＳは、電気の使用量を様々なグラフで見ることができるよう構成されている。もちろん、使用している様々な設備機器毎の電気量も見ることが可能である。

一般に、ビルで消費するエネルギーの ６５％は、空調と照明である。点きっぱなしになっている空調と照明を、外部温度や日光などの周辺環境の状態や、人の在室・在籍の状況に応じてコントロールすることができれば、消費エネルギーを大きく節減することができる。

電力の使用量を解析するためには、機器の運転状況、温度、外気温等の複合要素の分析も必要である。本実施形態におけるビル管理システム１０では、エネルギー管理については、トレンドデータの表示が可能となっている。トレンドデータは、最速１秒単位で多くのテータを取り込むことが可能である、このため、エネルギー分析には最適である。

このようなＥＭＳを使用して、エネルギー種別毎の使用量、時系列のエネルギー解析が可能である。さらに、設備機器を選択して、設定や状況表示をリアルタイムに行うことが可能である。

前述のプロダクティビティ・ツールは、同一ネットワーク上に設置されたセンサー類やスイッチ類、及び、各設備機器等の情報を自動収集し、データベース化する（図４）。作成されたデータベースに対して、一つひとつの設定情報を効率的に登録することができる。

従来は、ビル内の照明器具や空調、衛生などの各機器やセンサーから情報を収集して、現在の使用状況を表示したり、制御したりするためには、すべての機器とその機能に対して、一つずつ設定作業を行う必要があった。

例えば、接点情報（監視点数）が数十万点もある巨大ビルに限らず、数百点であっても、その設定を一つずつ手で行わなければならず、非常に多くの時間を要していた。しかも、その情報が現在どうなっているのかといった事項を確認する状態管理にも多くの手間を要していた。

本実施形態のビル管理システム１０では、このような問題を解決するために、前述のプロダクティビティ・ツールが用いられている。プロダクティビティ・ツールを用いることにより、従来、設定するだけで何十日もかかっていた作業がわずかな時間で行えるようになる。しかも登録するデータは、遠隔地からのダウンロードにより設定可能である。プロダクティビティ・ツールにより、工事作業が大幅に簡便化されるとともに、工事費用も大きく削減されることとなる。

＜レベル３：統合コントローラー（統合・エッジ・デバイス）＞
ビル内には、空調、電気、衛生、中央監視といったアプリケーション別のシステム（アプリケーション別システム）が多く構築されている。本実施形態のビル管理システム１０における統合コントローラー（統合・エッジ・デバイス６４）は、これらのアプリケーション別システムを統合し、受信した情報を、インターネット回線（公衆無線通信回線、及び、公衆有線通信回線）６８を介して、さらに上位のシステムへと順次伝達する。情報の伝達には、ＬＡＮ（ローカル・エリア・ネットワーク、構内ネットワーク）も適宜利用される。

本実施形態のビル管理システム１０において、統合コントローラー（統合・エッジ・デバイス６４）のハードウェア及びソフトウェアは、１台が、床面積が１０万平米のビルを管理できる程度の処理能力を有するよう構築されている。１０万平米は１０ｈａであり、３１６ｍ×３１６ｍのフロア、又は、１フロアが５０ｍ×５０ｍの４０階建てビルに相当する。このように、１台の統合コントローラー（統合・エッジ・デバイス６４）により、相当程度の規模の管理が可能である。

＜レベル４：エンタープライズ・エッジ・サーバー＞
本実施形態のビル管理システム１０においては、マイクロ・エッジ・デバイス６０（レベル１）、アプリケーション・エッジ・デバイス６２（レベル２）、統合エッジ・デバイス６４（レベル３）の上層に、エンタープライズ・エッジ・サーバー６６（レベル４）の階層が構築されている。これらのデバイスやサーバーは、いずれも、コンピュータ機器を用いて構成されるが、これらの間の大きな違いは、コンピュータ機器としての性能（処理容量、処理速度など）と、メモリ領域の利用形態である。

従来は、監視点数の制約が大きかったが、本実施形態のビル管理システム１０におけるエンタープライズ・エッジ・サーバー６６は、管理対象のビルの規模や棟数が増えて、性能が足りない場合には、未使用のスロット使用し、ＣＰＵの数を増やすことにより対応できるようにしている。また、より処理能力の高いＣＰＵを搭載した基板（ボード）に交換することでも、性能を向上できる。

さらに、エンタープライズ・エッジ・サーバー６６としては、ＶＭ（Virtual Machine、仮想マシン）を構成することが可能なコンピュータ機器が用いられている。ＷＭを構成することにより、管理システムの多重化（ここでは二重化）が可能である。

ＶＭは、システムの他の部分から分離され、１台のハードウェア上で複数が共存するよう構築される。ＶＭにより、複数の異なるＯＳ（オペレーティング・システム）を１台のコンピュータ機器上で同時に実行できるようになる。

例えば、ビル管理のシステムを改修しようとした場合、改修後にも、Windows NT（登録商標）やXPなどといった、近年では新たに導入されることがない古いＯＳ（オペレーティング・システム）を使用し続けなければならないことがある。

従来のビル管理システムでは、監視サーバーがＯＳに依存しているため、上位層の機器を変更すると、上位層に合わせて下位層の機器をもすべて変えなければならない。このため、下位層の機器の少なくとも一部を維持したままシステムを新しくしようとしても、過去のシステムに引きずられ、古いＯＳを残しておく必要がある。

本実施形態のビル管理システム１０においては、エンタープライズ・エッジ・サーバー６６は、仮想サーバーを構成できる。このため、新たにエンタープライズ・エッジ・サーバー６６を導入した場合に、エンタープライズ・エッジ・サーバー６６において、多様なＯＳを並行して動作させることが可能である。そして、例えば、Linux（登録商標）とWindows NT（登録商標）を並行して動作させる、といったことが可能である。

したがって、ビル管理システムの改修の際に、下位層の機器を残し、上位層だけを新しいものに交換するといったことが可能となる。しかも、複数のＯＳに係るシステムをそれぞれ構築することが可能である。このような考え方そのものが、従来と違って、新しい取り組みを示すものである。そして、ＶＭに古いＯＳを残すことができるため、システム改修時のサーバー機器の置き換えが、従来に比べて非常に楽なものとなる。

エンタープライズ・エッジ・サーバー６６を用いるメリットは大きい。単に構成する機器のサイズが小さくなっただけではなく、所定期間（７年程度）毎に発生する改修作業をも容易にする。

従来では、大規模システムの改修には保有システムの退避・保存・リロード等を行うためには丸１日要していた。さらに、サーバー台数分の作業を行う必要があったため、改修作業全体として、何日もの日程を要していた。

本実施形態のビル管理システム１０では、エンタープライズ・エッジ・サーバー６６を用いることにより、このような問題が解決され、システムを停止させることなく、ホット・スワップ（電源を入れたまま）での機器改修（交換・増設等）が可能となった。ホット・スワップでの機器改修を行えるようにするためには、エンタープライズ・エッジ・サーバー６６を二重化構成として冗長化することが可能である。この場合、一方のエンタープライズ・エッジ・サーバー６６を稼働させながら、もう一方のエンタープライズ・エッジ・サーバー６６を改修する。

＜エッジ・デバイスの働き＞
＜＜分散システム＞＞
本実施形態に係るビル管理システム１０の一つの大きな特徴は、無線通信やインターネット通信を適切に組み合わせることにより、監視点数の増大を容易に行えるようにしていることである。従来のビル管理システムでは監視点数に制限があり、その制限は、数千から、多ければ数万程度である。ビルのインテリジェント化や、複数のビルの管理を行う多棟管理を進めようとすると、管理能力が容易に限界に達してしまう。従来のビル管理システムにより、管理点数の制限を超えるシステムを導入する場合は、特別にプログラムを組み、複数のサーバーをブリッジさせる必要があった。

本実施形態のビル管理システム１０では、エンタープライズ・エッジ・サーバー６６が仮想サーバーを構成するため、ＣＰＵの増加により処理能力を容易に増強することが可能である。これにより、無限のリソースといえるハードディスク（記憶手段）も利用して、巨大なビル管理システムを構築することが可能となる。

また、ビル管理システム１０の一つの大きな特徴は、分散システムである。例えば、一つのサーバーを二つに分散することができる。サーバーを分割するが、すべてのデータを一つに集めなくてもよく、分散しておいて、必要に応じて取ってくる（オンデマンドで集める）ことができるようにしている。つまり、すべてのサーバーを繋ぐ必要がない。

必要な時に、必要な操作を行うことにより、複数のサーバーから、必要なデータを集めることが可能である。本実施形態のビル管理システム１０では、例えば、「データＡとデータＢとデータＣだけが欲しい」旨のコマンドをＰＣや携帯情報端末に入力すると、必要なデータが出力される。本実施形態のビル管理システム１０は、あたかも１つのコンピュータが処理しているように動作する。

従来のビル管理システムは、ほとんどがクライアント・サーバー型であり、このような動作はできない。従来のビル管理システムは、分散型にはなることはできず、大きなシステムにならざるを得なかった。この限界を超える仕組みを構築したことが、本実施形態のビル管理システム１０の特徴の一つである。

＜＜エッジサーバーの活用＞＞
従来のビル管理システムは、一つのサーバーの中にデータを集約し、その中を統括して管理していた。このため、システム自体が大きくなっていた。しかし、本実施形態のビル管理システム１０は、エッジ・サーバーを使うことでシステムを分散化している。そして、分散化は行っているが、例えば「マイクロ・エッジ・デバイス６０の特定のデータを見たい」旨のコマンドを入力すると、オンデマンドでデータを見ることができる。

＜＜統一データ様式＞＞
本実施形態のビル管理システム１０における他の特徴の一つは、情報の管理がすべて、統一された様式で行われることである。前述のように、無線式センサー装置３０を用いることにより、統一された様式のデータが自動的に収集される。しかもその様式は、先に述べた４種類のエッジ・デバイス（マイクロ・エッジ・デバイス６０、アプリケーション・エッジ・デバイス６２、統合・エッジ・デバイス６４、及び、エンタープライズ・エッジ・サーバー６６）のすべてで共通化されている。

マイクロ・エッジ・デバイス６０（レベル１）で取り扱われるデータ様式の構造と、その上位にあるアプリケーション・エッジ・デバイス６２（レベル２）、統合エッジ・デバイス６４（レベル３）、及び、エンタープライズ・エッジ・サーバー６６（レベル４）の構造は同じである。このため、上位レベルのエッジ・デバイスにおいて、上位レベルのエッジ・デバイスのデータを引き継ぐことができる。

以上のようにして統一様式のデータが作成され、作成されたデータが、多様な管理項目（空調、電気、衛生、中央監視等といった種々のアプリケーション）において活用される。統一様式のデータを利用することにより、あたかも、共通な接続構造を有するブロック玩具を組み合わせて目的の造形を作り上げるように、全体的に統合されたビル管理システム１０を構築できるようになる。

＜クラウドの活用＞
＜＜遠隔監視＞＞
本実施形態のビル管理システム１０では、クラウドが活用されている。このため、ビル監視者や一般利用者が、それぞれ独自にサーバーや記憶装置を持たずに、公共通信網を利用して、ビル管理のサービスを受けることが可能である。このようにクラウドを使用する理由の一つは、遠隔監視を行うためである。

ただし、複数の下位機器からデジタル化されたデータをそのまま上位層に上げてしまうと、データを受け取る上位機器で、通信量が増大し、データ処理速度の低下を招きかねない。

発明者等の知見では、ビル管理のためにクラウドを使用する場合、センサー類やスイッチ類により現場（ビル管理システム１０の末端）から集められたデータのうち、クラウドに上げるべきデータは、実際のところ、全収集データの数％（例えば３％程度）で十分である。その数％は、例えば、ＥＭＳ（エネルギー・マネジメント・システム）、エネルギーのデータ、ＦＭＳ（施設管理システム）である。これらのデータを、例えば、３０分に一度や、１時間に一度程度の頻度で収集するだけでも、十分なビル管理を行うことは可能である。

ビル管理に必要なデータは、時々刻々とダイナミックに変化するようなものよりも、スタティックなデータ、つまり静的データである。静的データについては、一定の時間間隔で収集して累積するだけでも、ビル管理においては十分である。このため、後述するように、オンプレミスによるデータ収集と、クラウドによるデータ収集とを併用したビル管理が行われる。

＜＜オンプレ・クラウド＞＞
現在、クラウドサービスは、情報処理サービスの主流となっている。クラウドサービスについては、とにかく多くのデータを集めてビッグデータを集積すればよいと考えられがちであるが、ビル管理システムに応用した場合、実際に膨大なデータを集めても、有効なビル管理システムを構築することは難しかった。

有効なビル管理システムの構築が難しかった原因として、集積されたデータの情報をどのように取り扱えばよいかが分かり難く、せっかく集められたデータの９０％以上は使う必要さえない、といった場合もあった。

現場（ビル管理システム１０の末端）で収集されたデータの１００％すべてをクラウドに乗せても（アップロードしても）、そのうちの９０％以上のデータは、何らかのトラブルが発生したような場合以外は使われない。

クラウドに上げる（アップロードする）には、通信費が発生し、ＣＰＵ使用料も発生し、クラウドに上げるための情報を記憶しておく保存領域（「使用領域」ともいう）も必要になる。もし、すべての発生データを保存しておけるような保存領域を確保する場合には、保存領域の大きさは、ギガバイトやテラバイトといった単位の大きさでは済まず、ペタバイト以上に達すると予想される。そのうえ、クラウドの保存容量が巨大なり、クラウドの維持や管理に、当然、莫大な費用を要することとなる。

そこで、本実施形態のビル管理システム１０は、エッジ・デバイス（現場で前処理するシステム）を活用し、オンプレミスなデータ処理とクラウドサービスとを適切に使い分けることにより、有効なビル管理システムの構築を可能としている。

本実施形態のビル管理システム１０では、すべてのデータをクラウドに乗せる（アップロードする）のではなく、選択されたデータがクラウドに乗せられる。平常時は、スタティックなデータのみを選択的に上げ、所定の条件が成立した場合（例えば、警報（アラーム）が発せられた場合など）に限り、その他のデータ（例えば履歴データ）がオンプレミスのデータから利用される。

このようにすることで、例えば、警報が出た場合に、警報の原因となった事象が発生した時間帯のオンプレミスのデータを参照することで、原因を調査するための処理プログラムを実行する、といったことが可能となる。そして、通信量と保存領域の抑制、通信速度やレスポンス（応答）速度の向上が図られている。

＜＜技術の統合＞＞
本実施形態のビル管理システム１０では、収集したデータをクラウドで活用したり、オンプレミスで活用したりするために種々の機器類や、ツール（アプリケーションソフト）類が備えられている。これらの機器類やツール類は、個別に存在しているのではなく、互いに連携している。そして、これらの機器類やツール類は、システムのパフォーマンスを最大化するために不可欠のものとなっている。

＜中央監視機能＞
＜＜ＩＴとＯＴの融合による多彩な見える化を実現＞＞
ビル管理システムの大きな目的は、ビル内に設置された機器類の一元的な状態監視と制御である。従来は、このような全体的な管理が難しかった。しかし、本実施形態のビル管理システム１０は、様々な工夫を組み合わせて、全体的な管理を実現している。例えば、電力量については、所定期間（指定期間）における全体の合計や、機器毎の合計について、可視化（見える化）が行われている。そして、いつ、どこで、どの機器が、どのくらいの電力を使用しているか、といった事項が確認できるようになっている。

＜＜照明・温度・湿度等の見える化＞＞
本実施形態のビル管理システム１０において、照明については、照明の点灯状況のほか、オン／オフ、及び、調光制御の状況等を、特定の態様で画面表示することが可能である。また、室内環境については、室内のＣＯ２濃度、温度、湿度などを、特定の態様（ヒートマップなど）で画面表示することが可能である。

＜＜環境の見える化－トレンドグラフ＞＞
本実施形態のビル管理システム１０においては、温度、湿度、照度等を、トレンドグラフによっても画面表示することが可能である。

＜＜利用状況や連携アプリケーション＞＞
本実施形態のビル管理システム１０においては、スケジュール、操作履歴、帳票、地震警報システム、クラウドアプリケーションなども画面表示することが可能である。

＜遠隔監視機能＞
＜＜多棟管理を可能にするクラウド監視システム＞＞
本実施形態のビル管理システム１０においては、ビル内の空調、照明、衛生、警報、エネルギーに関する各種の機器類について、スマートフォンやタブレット等の携帯情報端末を介して、監視や制御を行うことができる。また、ビルから離れた遠隔地からも、携帯情報端末を介して、監視や制御を行うことができる。

携帯情報端末では、インストールされたブラウザを介して、ビル管理のためのアプリケーションソフトに接続し、アプリケーションソフトを利用することが可能である。携帯情報端末のブラウザを介して、操作し易く、レスポンス（応答性）の良い管理画面が提供される。

前述したように、クラウドに乗せるのはスタティックデータのみであり、利用頻度の少ないダイナミックデータはエッジ・デバイスに配置される。このため、クラウドの使用領域が小さく、費用低減や、レスポンス（応答性）の向上が実現される。

＜＜ＣＢＭの実現＞＞
複数のビルの管理を行う多棟管理においては、どのビルで障害（異常）が発生しているかを知ることが重要である。従来は、異常の発生を常時確認しているような常時監視が行われていた。これに対し、本実施形態のビル管理システム１０においては、定期的にデータを採取したうえで、異常が発生した場合にだけ対応が行われる「予防保全」（ＣＢＭ： Condition Based Maintenance）が実現されている。

定期的に採取されるデータに基づき、異常が発見された場合には、携帯情報端末に警報（アラーム）が通知される、といった対策が施されている。さらに、アラームが発生したビルを指定し、ドリルダウンすることで、遠隔地からでもより詳細な状況把握を行うことができる。ドリルダウンにおいては、アラームが発生したビルの属性に紐付けられたデータを選んで、予め定められた各種の分析が実行される。

＜手のひらで監視・制御が可能なスマートパーム（商標登録出願中）＞
本実施形態のビル管理システム１０では、最新のテクノロジーを駆使し、新しい時代にふさわしい、照明とエアコンを制御するインテリジェントなツールが実現されている。ビル管理者や一般利用者等にブラウザを介して提供されるスマートパーム（商標登録出願中）は、照明と空調の両方のリモコン（遠隔操作）を携帯情報端末上で実現して、オフィス内の照明やエアコンを制御・監視することを可能とする。スマートパーム（商標登録出願中）は、あたかも手のひらがスイッチになったような操作性を提供するツールである。
＜＜ネットワークをまたいだ遠隔監視が可能＞＞
本実施形態のビル管理システム１０においては、スマートフォンやタブレット等の携帯情報端末を利用することにより、場所や時間等の制約に縛られず、どこからでもビル管理システムを制御することが可能である。

＜＜照明・空調の制御＞＞
本実施形態のビル管理システム１０においては、携帯情報端末を使って、空調や照明等の制御を直接行うことができる。このため、例えば、オフィスの照明や空調（エアコン）の温度を変更するために、オフィス内の人員が壁のスイッチまで移動することが不要になる。

例えば、照明に関しては、フロア内の全灯について、一括してオン／オフしたり、グループ別にオン／オフしたりすることができるよう、システムが構築されている。また、輝度を上下させる調光についても、手元から操作することができるように、システムが構築されている。

また、ブラウザを介して提供されるスマートパーム（商標登録出願中）には、例えば、フロア単位、グループ単位、及び、照明単位で、電気使用量を表示する機能が備えられている。このため、携帯情報端末を介して、対象の範囲での電気使用量がどの程度であるのかを確認できる。

＜＜設定とＱＲコード（登録商標）の生成＞＞
本実施形態のビル管理システム１０においては、一度設定された照明や空調（エアコン）のグループを、携帯情報端末において変更することが可能となっている。このようにすることにより、例えば、空調の工事業者や、システムの工事業者に、ビル内のテナントが休業している週末を利用してグループ変更の作業を実施してもらう、といったことが不要になる。

このような作業を行う際には、照明や空調（エアコン）を制御するために、例えば、設定管理用の一般利用者のグループにおいて、予め定められたグループ管理者にＱＲコード（登録商標）が配布される。ＱＲコード（登録商標）は、グループ管理者から、他のグループ員に配布される。グループは、設定が許容されるよう予め定め指定された範囲の一般利用者（ビル管理者や、その他の管理者が含まれていてもよい）により構成される。設定が許容される照明の範囲は、後述する照明のデザインツールを用いて行われる。

配布されたＱＲコード（登録商標）は、グループ員のＰＣに接続された表示装置や携帯情報端末等に表示される。ＱＲコード（登録商標）は、グループ員の他の携帯情報端末のカメラで読み取られ、ＵＲＬ等が表示される。ＵＲＬ等は、対応するアプリケーション・エッジ・デバイス６２に係る設定変更サイトにリンクしている。

グループ員が、ＵＲＬ等を選択すると、対応するアプリケーション・エッジ・デバイス６２に係る設定変更サイトが、グループ員の携帯情報端末に表示される。グループ員は、設定変更サイトにおいて、設定を変更したい設備機器の設定を操作する。

このようにすることで、一般利用者は、設定変更用のアプリケーションソフトをインストールすることなく、ブラウザを介して、照明やエアコンのグループ変更を行うことができる。

＜＜複数のプロジェクトを設定可能＞＞
携帯情報端末を介して設定された内容は、プロジェクトとして保存することが可能である。プロジェクトは、複数保存することが可能である。これにより、例えば、時間帯毎に設定を変えたり、平日と週末で、照明や空調のグループを変えたりすることが可能となる。このようにすることで、グループの変更のために、壁に新たにスイッチや操作盤を取り付ける必要がない。また、スイッチや操作盤に配線を繋げて壁内や床下等に引き回す工事を行う必要もない。さらに、工事業者に作業を依頼することなく、利用者が自社内で設定変更することが可能である。

＜＜照明のデザインツール＞＞
照明器具を設置するにあたっては、フロア内にどれくらいの機器を設置すればよいのか、設置した照明と電源をオン・オフするスイッチとの間のグループ化（グルーピング）をどのように行えばよいのか、といった事項が重要な焦点となる。過度に細かく設計してしまうと、制御が複雑になり、多くの制御用の機械が必要となる。逆に、過度に粗く設計してしまうと、例えば、人がいないところも照明が点灯するなどといった無駄が発生する。

このため、本実施形態のビル管理システム１０では、アプリケーションソフトの１つとして、照明のデザインツールを開発している。照明のデザインツールは、例えば、ビル監視者が、アプリケーション・エッジ・デバイス６２（レベル２）に接続し、表示された照明のデザインツールのサイト内において、設計のための操作を行う。

＜実施形態から抽出可能な発明＞
これまでに説明したような実施形態から、以下のような発明を抽出することが可能である。
（１）複数の管理項目（空調、照明、衛生、警報、エネルギーなど）のいずれかに分類される複数種類の設備機器（エアコン、照明機器、扉、無線式センサー装置３０等のセンサー類、スイッチ類、その他の電気機器類など）と、
複数種類の検出項目（温度、湿度、照度、加速度、コンタクトなど）の検出が可能なセンサー装置（無線式センサー装置３０など）と、
昇順に上位層となる第１階層装置（マイクロ・エッジ・デバイス６０など）、第２階層装置（アプリケーション・エッジ・デバイス６２など）、第３階層装置（統合・エッジ・デバイス６４など）、第４階層装置（エンタープライズ・エッジ・サーバー６６など）のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
少なくとも１つの前記管理項目を１つの項目系として複数の項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）を定めることが可能であり、
複数の前記項目系が、少なくとも、空調系、照明系、及び、警報系、及び、エネルギー系を含む、ビル管理システムであって、
前記センサー装置が複数備えられ、
複数の前記センサー装置が、
少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力し、
複数の前記項目系に跨るセンサー装置群を構成する、ビル管理システム。
（２）前記第１階層装置が、
複数の前記無線通信規格のデジタル情報を変換処理可能（ＩＰへの変換など）であり、
前記センサー装置群からのデジタル情報を、前記センサー装置で採用されている前記無線通信規格から共通の通信規格である共通通信規格（ＩＰなど）のデジタル情報に変換して、無線通信により送出し、
前記第２階層装置が、
前記第１階層装置からの前記共通通信規格のデジタル情報を受信し、
複数の前記センサー装置から収集したデジタル情報に基づき、複数の前記センサー装置から収集した情報をデータベース化する、上記（１）に記載のビル管理システム。
（３）前記第２階層装置は、前記第３階層装置が備えられていない場合には、
ユーザーの端末装置（携帯情報端末２２、２４など）から、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択し、
前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（２）に記載のビル管理システム。
（４）前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置は、前記第４階層装置が備えられていない場合には、
ユーザーの端末装置（携帯情報端末２２、２４など）から、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記第２階層装置に対し、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択して送出するよう要求し、
前記第２階層装置から前記共通通信規格により、前記公衆無線通信回線を介して送出された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（２）に記載のビル管理システム。
（５）前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置が複数備えられている場合には前記第４階層装置が備えられ、
前記第４階層装置は、
ユーザーの端末装置（携帯情報端末２２、２４など）から、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記第３階層装置を介して、前記第２階層装置に、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択して送信するよう要求し、
前記第３階層装置は、
前記第２階層装置から、前記共通通信規格により、前記公衆無線通信回線を介して送出された前記処理前情報を、前記第４階層装置に中継し、
前記第４階層装置は、
前記第３階層装置により中継された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（２）に記載のビル管理システム。
（６）上記（１）～（５）のビル管理システムで行われるビル管理方法。
（７）上記（１）～（５）の「ビル管理システム」を「ビル管理装置」に置き換えた発明。

＜その他＞
当業者は、本発明の精神及び範囲から外れることなく、様々な変更、置換、及び修正をこれに加えることが可能であることを理解されたい。

１０ ：ビル管理システム
１２ ：空調関連系
１４ ：コンセント系
１６ ：水回り系
１８ ：警報系
２０ ：エネルギー系
２２、２４ ：携帯情報端末
３０ ：無線式センサー装置
６０ ：マイクロ・エッジ・デバイス
６０Ａ ：デバイス群
６２ ：アプリケーション・エッジ・デバイス
６４ ：統合・エッジ・デバイス
６６ ：エンタープライズ・エッジ・サーバー

Claims (1)

1. 複数の管理項目のいずれかに分類される複数種類の設備機器と、
   複数種類の検出項目の検出が可能なセンサー装置と、
   昇順に上位層となる第１階層装置、第２階層装置、第３階層装置、第４階層装置のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
   少なくとも１つの前記管理項目を１つの項目系として複数の項目系を定めることが可能であり、
   複数の前記項目系が、少なくとも、空調系、照明系、警報系、及び、エネルギー系を含む、ビル管理システムであって、
   前記センサー装置が複数備えられ、
   複数の前記センサー装置が、
   少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力可能であり、
   複数の前記項目系に跨るセンサー装置群を構成し、
   前記第１階層装置で共通仕様の通信規格に基づき統一化された情報が前記第２階層装置へ送出され、
   前記第２階層装置が、
   所定のアプリケーションソフトを用いて前記第１階層装置からの前記情報をデータベース化することが可能な、ビル管理システム。

Images