知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024130827
(43)【公開日】2024-09-30
(54)【発明の名称】ビル管理システム
(51)【国際特許分類】
H02J 13/00 20060101AFI20240920BHJP
【ＦＩ】
H02J13/00 301A
H02J13/00 A
【審査請求】未請求
【請求項の数】8
【出願形態】ＯＬ
(21)【出願番号】P 2023040741
(22)【出願日】2023-03-15
(71)【出願人】
【識別番号】309000967
【氏名又は名称】株式会社 ネットワーク・コーポレーション
(74)【代理人】
【識別番号】100097559
【弁理士】
【氏名又は名称】水野 浩司
(74)【代理人】
【識別番号】100196829
【弁理士】
【氏名又は名称】中澤 言一
(74)【代理人】
【識別番号】100173680
【弁理士】
【氏名又は名称】納口 慶太
(72)【発明者】
【氏名】馬越 伸太郎
【テーマコード（参考）】
5G064
【Ｆターム（参考）】
5G064AA01
5G064AC06
5G064AC09
5G064BA02
5G064CB08
5G064CB12
(57)【要約】
【課題】より効果的にビル管理を行うことができるビル管理システムを提供する。
【解決手段】複数の管理項目（空調、照明、衛生、警報、エネルギーなど）のいずれかに分類される複数種類の設備機器（エアコン、照明機器、扉、無線式センサー装置等のセンサー類、スイッチ類、その他の電気機器類など）と、複数種類の検出項目（温度、湿度、照度、加速度、コンタクトなど）の検出が可能な無線式センサー装置と、昇順に上位層となる第１階層装置（マイクロ・エッジ・デバイス６０など）、第２階層装置（アプリケーション・エッジ・デバイス６２など）、第３階層装置（統合・エッジ・デバイス６４など）、第４階層装置（エンタープライズ・エッジ・サーバー６６など）のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備えた。
【選択図】図１
【解決手段】複数の管理項目（空調、照明、衛生、警報、エネルギーなど）のいずれかに分類される複数種類の設備機器（エアコン、照明機器、扉、無線式センサー装置等のセンサー類、スイッチ類、その他の電気機器類など）と、複数種類の検出項目（温度、湿度、照度、加速度、コンタクトなど）の検出が可能な無線式センサー装置と、昇順に上位層となる第１階層装置（マイクロ・エッジ・デバイス６０など）、第２階層装置（アプリケーション・エッジ・デバイス６２など）、第３階層装置（統合・エッジ・デバイス６４など）、第４階層装置（エンタープライズ・エッジ・サーバー６６など）のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備えた。
【選択図】図１
【特許請求の範囲】
【請求項1】
複数の管理項目のいずれかに分類される複数種類の設備機器と、
複数種類の検出項目の検出が可能なセンサー装置と、
昇順に上位層となる第１階層装置、第２階層装置、第３階層装置、第４階層装置のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
少なくとも１つの前記管理項目を１つの項目系として複数の項目系を定めることが可能であり、
複数の前記項目系が、少なくとも、空調系、照明系、警報系、及び、エネルギー系を含む、ビル管理システムであって、
前記センサー装置が複数備えられ、
複数の前記センサー装置が、
少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力可能であり、
複数の前記項目系に跨るセンサー装置群を構成し、
前記第１階層装置で共通仕様の通信規格に基づき統一化された情報のうち、予め指定された情報のみが、クラウドを介して前記第２階層装置へ送出される、ビル管理システム。
複数種類の検出項目の検出が可能なセンサー装置と、
昇順に上位層となる第１階層装置、第２階層装置、第３階層装置、第４階層装置のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
少なくとも１つの前記管理項目を１つの項目系として複数の項目系を定めることが可能であり、
複数の前記項目系が、少なくとも、空調系、照明系、警報系、及び、エネルギー系を含む、ビル管理システムであって、
前記センサー装置が複数備えられ、
複数の前記センサー装置が、
少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力可能であり、
複数の前記項目系に跨るセンサー装置群を構成し、
前記第１階層装置で共通仕様の通信規格に基づき統一化された情報のうち、予め指定された情報のみが、クラウドを介して前記第２階層装置へ送出される、ビル管理システム。
【請求項2】
前記指定された情報はアラームの情報を含む、請求項１に記載のビル管理システム。
【請求項3】
前記第１階層装置が、前記設備機器に対しＩＰアドレスの割り振りを行う、請求項１に記載のビル管理システム。
【請求項4】
グローバルＤＮＳにより多地点を特定する、請求項１に記載のビル管理システム。
【請求項5】
前記第２階層装置が、
前記第１階層装置からの前記共通通信規格のデジタル情報を受信し、
複数の前記センサー装置から収集したデジタル情報に基づき、複数の前記センサー装置から収集した情報をデータベース化する、請求項１～４に記載のビル管理システム。
前記第１階層装置からの前記共通通信規格のデジタル情報を受信し、
複数の前記センサー装置から収集したデジタル情報に基づき、複数の前記センサー装置から収集した情報をデータベース化する、請求項１～４に記載のビル管理システム。
【請求項6】
前記第２階層装置は、前記第３階層装置が備えられていない場合には、
ユーザーの端末装置から、少なくとも、公衆無線通信回線を介して、特定の前記管理項目に係る要求があると、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報を選択し、
前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、請求項５に記載のビル管理システム。
ユーザーの端末装置から、少なくとも、公衆無線通信回線を介して、特定の前記管理項目に係る要求があると、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報を選択し、
前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、請求項５に記載のビル管理システム。
【請求項7】
前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置は、前記第４階層装置が備えられていない場合には、
ユーザーの端末装置から、少なくとも、公衆無線通信回線を介して、特定の前記管理項目に係る要求があると、前記第２階層装置に対し、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報を選択して送出するよう要求し、
前記第２階層装置から前記共通通信規格により、前記公衆無線通信回線を介して送出された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報を、 前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、請求項５に記載のビル管理システム。
前記第３階層装置は、前記第４階層装置が備えられていない場合には、
ユーザーの端末装置から、少なくとも、公衆無線通信回線を介して、特定の前記管理項目に係る要求があると、前記第２階層装置に対し、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報を選択して送出するよう要求し、
前記第２階層装置から前記共通通信規格により、前記公衆無線通信回線を介して送出された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報を、 前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、請求項５に記載のビル管理システム。
【請求項8】
前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置が複数備えられている場合には前記第４階層装置が備えられ、
前記第４階層装置は、
ユーザーの端末装置から、少なくとも、公衆無線通信回線を介して、特定の前記管理項目に係る要求があると、前記第３階層装置を介して、前記第２階層装置に、前記ユーザーへの応答に必要な処理前情報を選択して送信するよう要求し、
前記第３階層装置は、
前記第２階層装置から、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して送出された前記処理前情報を、前記第４階層装置に中継し、
前記第４階層装置は、
前記第３階層装置により中継された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報を、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、請求項５に記載のビル管理システム。
前記第３階層装置が複数備えられている場合には前記第４階層装置が備えられ、
前記第４階層装置は、
ユーザーの端末装置から、少なくとも、公衆無線通信回線を介して、特定の前記管理項目に係る要求があると、前記第３階層装置を介して、前記第２階層装置に、前記ユーザーへの応答に必要な処理前情報を選択して送信するよう要求し、
前記第３階層装置は、
前記第２階層装置から、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して送出された前記処理前情報を、前記第４階層装置に中継し、
前記第４階層装置は、
前記第３階層装置により中継された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報を、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、請求項５に記載のビル管理システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、例えば、情報通信網を介してビル管理を行うビル管理システムに関する。
【背景技術】
【0002】
例えば、後掲の特許文献１には、ネットワーク分散型のビル管理システムに係る発明が開示されている。特許文献１に開示された発明においては、段落００１７や図１に記載されているように、パソコン等の通信端末機（１）からインターネット等の既存のネットワーク（Ｌ１）やビルディングサーバ（２）を介して、ビル内設備機器が監視される。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２００３－１３４１２０号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ところで、ビルの改修の際には、既存の設備機器（センサー類やスイッチ類を含む）を新しいものに変更する作業が発生する。特許文献１に開示されたような従来のネットワークシステムや、従来のビル管理システムでは、共通の通信規格に対応するよう設計されている設備機器を管理することはできても、それ以上の多くの種類の設備機器に対応することまではできていなかった。例えば、特許文献１に開示された発明では、メーカー毎の設備制御機器の選定が必要である（段落０００９）。そして、近年におけるインテリジェントビルの管理や、多棟管理を想定した場合には、監視点数が膨大になるため、従来の技術によったのでは、総合的なビル管理には対応することができなかった。
【0005】
本発明の目的とするところは、より効果的にビル管理を行うことができるビル管理システムを提供することにある。
【課題を解決するための手段】
【0006】
上記目的を達成するために本発明に係るビル管理システムは、
複数の管理項目のいずれかに分類される複数種類の設備機器と、
複数種類の検出項目の検出が可能なセンサー装置と、
昇順に上位層となる第１階層装置、第２階層装置、第３階層装置、第４階層装置のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
少なくとも１つの前記管理項目を１つの項目系として複数の項目系を定めることが可能であり、
複数の前記項目系が、少なくとも、空調系、照明系、警報系、及び、エネルギー系を含む、ビル管理システムであって、
前記センサー装置が複数備えられ、
複数の前記センサー装置が、
少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力可能であり、
複数の前記項目系に跨るセンサー装置群を構成し、
前記第１階層装置で共通仕様の通信規格に基づき統一化された情報のうち、予め指定された情報のみが、クラウドを介して前記第２階層装置へ送出される。
複数の管理項目のいずれかに分類される複数種類の設備機器と、
複数種類の検出項目の検出が可能なセンサー装置と、
昇順に上位層となる第１階層装置、第２階層装置、第３階層装置、第４階層装置のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
少なくとも１つの前記管理項目を１つの項目系として複数の項目系を定めることが可能であり、
複数の前記項目系が、少なくとも、空調系、照明系、警報系、及び、エネルギー系を含む、ビル管理システムであって、
前記センサー装置が複数備えられ、
複数の前記センサー装置が、
少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力可能であり、
複数の前記項目系に跨るセンサー装置群を構成し、
前記第１階層装置で共通仕様の通信規格に基づき統一化された情報のうち、予め指定された情報のみが、クラウドを介して前記第２階層装置へ送出される。
【発明の効果】
【0007】
上記発明によれば、より効果的にビル管理を行うことができるビル管理システムを提供することができる。
【図面の簡単な説明】
【0008】
【図1】本発明の一実施形態に係るビル管理システムを概略的に示す説明図である。
【図2】無線式センサー装置の構成を概略的に示すブロック図である。
【図3】データベースの作成手順を概略的に示すフローチャートである。
【図4】データベースの情報を概略的に示す説明図である。
【図5】通信障害発生時の状況の一例を概略的に示す説明図である。
【発明を実施するための形態】
【0009】
＜実施形態に係るビル管理システムの概要＞
以下、本発明の実施形態に係るビル管理システムについて説明する。本実施形態のビル管理システムは、空調（エアコン）、照明、衛生、警報（セキュリティー、アラーム）、エネルギー等といった各種の管理項目を、ビル内やビル外、及び、遠隔地から自在に、一元管理したり、分散制御したりすることを可能としている。
以下、本発明の実施形態に係るビル管理システムについて説明する。本実施形態のビル管理システムは、空調（エアコン）、照明、衛生、警報（セキュリティー、アラーム）、エネルギー等といった各種の管理項目を、ビル内やビル外、及び、遠隔地から自在に、一元管理したり、分散制御したりすることを可能としている。
【0010】
本実施形態のビル管理システムは、ビル内の各設備機器を含んでいる。設備機器には、例えば、エアコン、照明機器、扉等のように様々な設備機器が含まれている。また、設備機器には、部屋内の温度を検出する温度センサー、湿度を検出する湿度センサー、照明機器の照度を検出する照度センサー、扉の開閉を検出するコンタクトセンサーなど（センサー類）も含まれる。
【0011】
また、設備機器には、エアコンの操作パネルやリモコン（リモートコントローラ）、照明の操作パネルやリモコン、壁に設置された各種のスイッチなど（スイッチ類）も含まれる。さらに、設備機器には、電力の使用状況の把握に係る変流器、電力量モニタ、サーキットプロテクタ、パワー・サプライ・ユニット、コンパクト・ゲートウェイなど（その他の電気機器類）も含めることが可能である。
【0012】
これらは設備機器の一例であり、一般にビル管理に用いられるその他の機器も、本実施形態の設備機器に含めることが可能である。
【0013】
本実施形態のビル管理システムでは、各設備機器により収集された情報に基づき、ビルの設備機器の監視を行うビル管理者や、各設備機器の一般利用者（フロアや区画を利用するテナントの社員など）が、自ら所有する情報携帯端末（スマートフォンやタブレットなど）から、設備機器を選択して指示（コマンド）を入力する、といったことを可能としている。
【0014】
さらに、本実施形態のビル管理システムにおいては、ビル管理のためのソフトウェア（アプリケーションソフトを含む）の種類が、システムの統合により、最小限に止められている。また、本実施形態のビル管理システムにおいては、全体の監視を可能とする監視システムが標準装備されている。
【0015】
当たり前のことのように思えるかもしれないが、従来のビル管理システムでは、メーカー（製造業者）やベンダー（販売業者）毎の各種情報の仕様（信号規格、通信規格、ＯＳ（オペレーティング・システム）、プログラミング言語など）の違いに関わらず、横断的に（横方向に跨って）情報を収集して、ビル管理者や、設備機器の一般利用者等に対し、統合されたサービスを提供することは難しかった。本実施形態のビル管理システムは、このことを可能とした。
【0016】
より具体的には、本実施形態のビル管理システムは、「ビル内監視ルーム（中央監視ルーム）からの解放」を図っている。これは、従来、ビル内に設置されていた中央監視ルームを廃止したり、中央監視に係る人員を一人等のように最小限に止めたりすることが可能であることを意味している。
【0017】
従来のビル管理システムにおいては、ビル内に中央監視ルームが不可欠であった。しかも、空調、照明、衛生、警報、エネルギー等といった各種の管理項目について設置された機器毎に、独立した管理が行われていた。前述したように、例えば前掲の特許文献１に開示された発明では、メーカー毎の設備制御機器の選定が必要である（段落０００９）。このため、機器類の制御が、システム構成上の縦方向に（縦断的に）は統合できたとしても、メーカーやベンダー毎の各種情報の仕様の違いに関わらず、水平方向に（横断的に）統合することはできず、分断されていた。
【0018】
図１は、本実施形態のビル管理システム１０の構成を概略的に示している。図中には、設備機器に係る複数の系（項目系）の一例が示されている。図１に示されているのは、空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０である。
【0019】
空調関連系１２は、エアコン（エアーコンディショナー、空気調和機）や、温度センサー、湿度センサー等といった空調に係る複数の設備機器の系（まとまり、グループ）を示している。
【0020】
照明・コンセント系１４は、照明機器、照度センサー、商用電源への接続機器等に係る設備機器の系を示している。衛生・水回り系１６は、トイレ、洗面所、給湯等といった衛生や水回りに係る複数の設備機器の系を示している。
【0021】
状態・警報系１８は、ドアの開閉、地震、権限のない者の侵入等に対処に係る複数の設備機器の系を示している。エネルギー系２０は、使用電力量（電力消費量）や、太陽光発電量、燃料使用量等の把握に係るセンサー類やスイッチ類等の複数の設備機器の系を示している。
【0022】
ここで、項目系の分類は、上述の例に限られるものではない。例えば、「空調・照明・コンセント系」のように、複数の系を統合してもよい。また、「照明系」、「コンセント系」、「衛生系」、「水回り系」のように、それぞれを独立させてもよい。さらに、「空調１」、「空調２」、「照明１」、「照明２」のように分割してもよい。
【0023】
上述したような各種の項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）では、様々なメーカーやベンダーの設備機器が用いられるのが一般的である。このため、従来は、各項目系において、メーカーやベンダー毎に、情報通信の抱え込みが生じており、ビルの改修工事や新築工事の際には、メーカーやベンダーの指定の工事業者に工事を発注する必要があった。
【0024】
また、メーカーやベンダー毎には共通の信号規格や通信規格が使用されていることが多い。このため、メーカーやベンダー毎に、共通の信号規格、通信規格、ＯＳ、プログラミング言語などを用いて管理システムを構築することは可能である。また、マルチプロトコル通信規格に対応するよう予め定められた設備機器を用いた場合には、それらの設備機器のみを統合的に取り扱うことは可能である。しかし、これらの場合は、メーカーやベンダーに対応したサーバーを設置して、管理システムを構築する必要がある。
【0025】
例えば、１つの項目系（例えば空調関連系１２など）において、複数のメーカーやベンダーの設備機器が採用されている場合には、１つの項目系につき複数のサーバーを設置して、複数の管理システムを構築する必要があった。
【0026】
また、例えば、各項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）毎に、メーカーやベンダーが統一されているような場合は、項目系毎にサーバーを設置して、管理システムを構築する必要があった。
【0027】
このように、メーカーやベンダー毎の統合（システム構成上の縦方向の統合）は比較的容易にできるが、各項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）を横断した統合（システム構成上の横方向の統合）は容易ではなかった。そして、従来のビル管理システムにおいては、ＩＴ（情報技術）とＯＴ（運用技術）が分離されていた。
【0028】
図１に示す本実施形態のビル管理システム１０は、各種の管理項目に係る設備機器の項目を統合し、且つ、適正なクラウド化を行うことで、中央監視ルームを廃止可能としている。本実施形態のビル管理システム１０は、各種の管理項目を、ビル管理者のスマートフォンやタブレット等の携帯情報端末２２から、多数のアプリケーションソフトをインストールすることなく、遠隔で監視できるようにしている。この結果、中央監視ルームに人を縛り付ける必要がなくなり、管理に要する人員の人数や人件費の削減が可能となった。
【0029】
また、本実施形態のビル管理システム１０は、テナントの社員などの一般利用者も、所定の管理項目を、スマートフォンやタブレット等の携帯情報端末２４から、多数のアプリケーションソフトをインストールすることなく、遠隔で操作できるようにしている。
【0030】
＜階層構造＞
図１に示すように、本実施形態に係るビル管理システム１０は、大きく分けて、レベル０～レベル４の５つの階層構造を有している。レベル０はセンサーの階層であり、レベル１はセンサー・コントローラー（マイクロ・エッジ・デバイス）の階層である。レベル２はアプリケーション・エッジ・デバイスの階層であり、レベル３は統合コントローラー（統合・エッジ・デバイス）の階層である。レベル４は、エンタープライズ・エッジ・サーバーの階層である。以下に各階層について説明する。
図１に示すように、本実施形態に係るビル管理システム１０は、大きく分けて、レベル０～レベル４の５つの階層構造を有している。レベル０はセンサーの階層であり、レベル１はセンサー・コントローラー（マイクロ・エッジ・デバイス）の階層である。レベル２はアプリケーション・エッジ・デバイスの階層であり、レベル３は統合コントローラー（統合・エッジ・デバイス）の階層である。レベル４は、エンタープライズ・エッジ・サーバーの階層である。以下に各階層について説明する。
【0031】
＜レベル０：センサー＞
ビル管理システム１０の最も下位レベルの階層はセンサーである。従来、例えば、温度や湿度等といった各種のアナログ情報をデジタル情報に変換するために、シーケンサーを設け、各種の情報に対する閾値を設定して管理する必要があった。
ビル管理システム１０の最も下位レベルの階層はセンサーである。従来、例えば、温度や湿度等といった各種のアナログ情報をデジタル情報に変換するために、シーケンサーを設け、各種の情報に対する閾値を設定して管理する必要があった。
【0032】
センサーから送出されるデータは、閾値、電流値、レンジ変換等といったいろいろな要素が加わり、一つの塊として形成されている。つまり、シーケンサーの中でデータが処理され、設計者や作業者により閾値が設定され、出力されたデータの一部がビル管理に使用されるだけであった。
【0033】
従来型のビル管理システムの特徴といってもよいが、従来のビル管理システムは、機器間を物理的に接続して、特定のシリアルバス（RS485）で繋いでいるだけであった。通信は、シリアルバス（RS485）のインターフェースを使って行われており、信号処理は、ＣＰＵを持たない通信用チップを使用して行われていた。このため、従来のビル管理システムには、限られた機能しか備えられておらず、インテリジェンスに欠けていた。
【0034】
本実施形態に係るビル管理システム１０では、レベル０のセンサーとして、図２に示すような、無線式のインテリジェントセンサー装置（以下では「無線式センサー装置」と称する）３０が用いられている。無線式センサー装置３０は、複数種類（例えば、温度、湿度、照度、加速度、コンタクトの５種類）の検出項目（物理量）の検出が可能である。
【0035】
無線式センサー装置３０は、複数の項目系（例えば、空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）において使用されている。さらに、無線式センサー装置３０には、複数の機種があり、それぞれの通信規格で無線通信を行う。このため、無線式センサー装置３０には、異なる通信規格で無線通信を行うものが含まれる。さらに、無線式センサー装置３０については、マルチプロトコル対応の設計がされているか否かは問題とならない。
【0036】
無線式センサー装置３０は、例えば、ビルの壁面、天井、及び、ドア等に設置され、検出した情報をレベル１のセンサー・コントローラー（後述する）に無線送信する。無線式センサー装置３０としては、複数のメーカーやベンダーから提供されている各種のものを混合して採用することが可能である。
【0037】
無線式センサー装置３０は、図２に示すように、内部に、温度センサー部３２、湿度センサー部３４、照度センサー部３６、加速度センサー部３８、及び、コンタクトセンサー部４０を備えている。さらに、無線式センサー装置３０は、ＣＰＵ４２、記憶部４４、情報形式変換部４６、情報入力部４８、無線通信部５０、及び、発電部５２等を備えている。
【0038】
温度センサー部３２は、温度センサーを備えており、例えば、室内の空気等の温度を検出可能である。湿度センサー部３４は、湿度センサーを備えており、例えば、室内の空気等の湿度を検出可能である。照度センサー部３６は、照度センサーを備えており、例えば、室内等の明るさを検出可能である。
【0039】
加速度センサー部３８は、加速度センサーを備えており、例えば、壁に伝わる衝撃等を検出可能である。コンタクトセンサー部４０は、コンタクトセンサー（マグネットコンタクトセンサー）を備えており、例えば、ドアの開閉等を検出可能である。
【0040】
無線式センサー装置３０に備えられる温度センサー、湿度センサー、照度センサー、加速度センサー、及び、コンタクトセンサーとしては、一般的な各種のセンサーを採用することが可能である。
【0041】
無線式センサー装置３０においては、エネルギー・ハーベスティング技術を利用して発電し、無線送信する通信規格（EnOcean）が採用されている。無線式センサー装置３０においては、発電部５２の発電（ここでは光発電）により、ＣＰＵ４２やセンサー部３２、３４、３６、３８、４０の正常な動作に必要な電力が供給される。
【0042】
無線式センサー装置３０は、どの検出項目の検出機能を使用するかを選択することが可能である。また、無線式センサー装置３０は、すべての検出機能を同時に使用することも可能である。
【0043】
使用する検出機能の設定は、選択された検出機能を識別する情報（検出機能識別情報）を記憶部４４に記憶させて行われる。上記検出機能識別情報の記憶は、無線通信が可能な外部通信機器を利用して行うことが可能である。
【0044】
上述の外部通信機器としては、例えば、スマートフォンやタブレット端末等の携帯情報端末（携帯情報端末２２、２４など）を例示できる。この場合、携帯情報端末に、所定のアプリケーションソフトをインストールし、このアプリケーションソフトを操作することにより行うことが可能である。所定のアプリケーションソフトには、ビル管理者が使用する管理者用機器管理アプリや、一般利用者用機器管理アプリなどがある。
【0045】
無線式センサー装置３０においては、ＣＰＵ４２の情報処理により、使用されるセンサー部（センサー部３２、３４、３６、３８、４０のうちの少なくとも一部）の信号が、工業単位の情報に変換され、デジタルデータが生成される。無線式センサー装置３０においては、生成されたデジタルデータを利用して無線パケットが作成され、無線パケットが、後述するレベル１のセンサー・コントローラー（マイクロ・エッジ・デバイス）に送られる。
【0046】
温度センサー部３２、湿度センサー部３４、照度センサー部３６などのように、連続量を検出するセンサー部については、情報の送信は、所定時間（例えば数十秒～３分など）毎に行われる。また、加速度センサー部３８やコンタクトセンサー部４０の信号に係る情報の送信は、所定の閾値に達するほどの大きさの加速度やコンタクト（接触圧力など）が検出された場合に行われる。
【0047】
温度センサー部３２、湿度センサー部３４、照度センサー部３６など情報送信間隔を大きくするほど、情報送信量を減らすことができる。上記の所定時間内に、温度センサー部３２、湿度センサー部３４、照度センサー部３６に係る情報を送信してもよく、上記の所定時間毎に、温度センサー部３２、湿度センサー部３４、照度センサー部３６係る情報を順に送信してもよい。
【0048】
従来のビル管理システムにおいて、情報通信の無線化は、頻繁なバッテリー（電池）交換が必要になることや、無線信号が途切れること等の問題により、敬遠されることが多かった。本実施形態のビル管理システム１０は、このような無線化におけるバッテリーの課題を、エネルギー・ハーベスティング技術により解決している。
【0049】
なお、エネルギー・ハーベスティング技術に用いられる発電部５２は、光発電を行うものに限らず、例えば、熱電発電、電磁波発電、振動力発電等であってもよい。
【0050】
熱電発電においては、例えば、ゼーベック効果（温度差が電圧に変換される現象）を利用した熱電変換素子（熱と電力を変換する素子）が用いられ、物体の温度差が電圧に変換される。例えば、空調装置や、ビル内の配管等から発生する熱が、電気エネルギーに変換される。
【0051】
電磁波発電においては、例えば、ビル内の無線ＬＡＮなどが発する電波のエネルギーをレクテナ（rectifying antenna）により直流電流に変換して発電が行われる。
【0052】
振動力発電においては、振動によって発生する圧力が、圧電素子などを介して電力に変換される。例えば、ビルのフロア内に圧力センサーが設置され、人が通路を歩く際に発生する圧力や、振動による圧力が、電気エネルギーに変換される。
【0053】
なお、本実施形態のビル管理システム１０では、照明をオン／オフするためのスイッチとして、無線式スイッチ（図示略）が使用されている。無線式スイッチは、スイッチ機構部や無線通信部を内蔵しており、エネルギー・ハーベスティング技術を利用して、スイッチ機構部の状態を示す情報を、無線により外部に送信する。
【0054】
無線式スイッチを管理者や一般利用者が手指で操作することにより、オン／オフの情報（オン／オフ情報）が、誘起電力を利用して無線送信される。無線式スイッチは、ビス止めや、マグネットシートの貼付等の方法により、壁面への設置が可能である。
【0055】
無線式スイッチを使用することにより、配線を要することなく、照明のオン／オフが可能である。配線不要であることから、スイッチ類の置き場所に制約がなく、スイッチの配置の自由度が高い。加えて、バッテリーが不要であり、このことによっても、多くの手間を要していた電池交換作業が不要になる。
【0056】
以上のように、必要なセンサー類やスイッチ類に対して、可能な限り多くの無線式センサー装置３０や無線式スイッチを用いることで、配線を引き回して、システムの末端を構成するセンサー類やスイッチ類をシーケンサーに接続する作業が不要になる。このため、センサー類やスイッチ類の設置工事を容易に行うことが可能となる。
【0057】
センサー類やスイッチ類は、前述の項目系１２、１４、１６、１８、２０の中に多数含まれている。また、１つのビルに使用されるセンサー類やスイッチ類は、フロア内の部屋数等によっても異なるが、ビルのインテリジェント化が進むほど多くなる。
【0058】
このため、部屋数の多いビルや、高度にインテリジェント化されたビルの改築工事や新築工事の際に、センサー類やスイッチ類の配線作業に要する工数（人員数×時間）は相当な値となる。したがって、無線式センサー装置３０や無線式スイッチを用いることで、配線作業の多くを不要にすることができ、工数を大幅に削減することが可能となる。
【0059】
従来、配線作業に要する作業内容や工数は、作業現場任せになりがちであり、工期の見積りや、人件費の見積りを不正確にする大きな要因であった。例えば、センサー装置とシーケンサーの間の配線や、シーケンサーと上記の機器の配線等をどのように行うかは、作業現場の判断により行われることが多かった。また、設置されるセンサー装置の数は、ビルの形態や規模によって、数百～数十万といった数に達する。さらに、ビルの改修コストや新築コストの多くの部分は、人件費に依って占められている。したがって、配線に要する工数を削減することは、コスト削減に大きく寄与する。
【0060】
なお、本実施形態に係るビル管理システム１０では、すべてのセンサーやスイッチ類が無線式であることに限られるものではなく、一部のセンサーやスイッチは有線で信号をシーケンサー等に送出するものであってもよい。また、前述したその他電気機器類には、無線通信するものや有線通信するものが含まれていてもよい。
【0061】
＜レベル１：センサー・コントローラー（マイクロ・エッジ・デバイス）＞
各無線式センサー装置３０から送信されたデジタルデータは、レベル１のセンサー・コントローラー（マイクロ・エッジ・デバイス６０）により受信される。センサー・コントローラーは、マイクロ・エッジ・デバイス６０により構成される。
各無線式センサー装置３０から送信されたデジタルデータは、レベル１のセンサー・コントローラー（マイクロ・エッジ・デバイス６０）により受信される。センサー・コントローラーは、マイクロ・エッジ・デバイス６０により構成される。
【0062】
本実施形態のビル管理システム１０では、管理対象のビルの規模や棟数等の条件に応じて、複数個のマイクロ・エッジ・デバイス６０が用いられる。図１には、一例として３つのマイクロ・エッジ・デバイス６０が示されている。１つのマイクロ・エッジ・デバイス６０には、例えば、１００個以上（最大２００個程度）の各無線式センサー装置３０の対応付けや、図示は省略するが、有線式のセンサー類やスイッチ類に接続されたシーケンサー類の対応付けが可能である。そして、１つのマイクロ・エッジ・デバイス６０では、１００～２００点程度の監視点数についてのデータ処理が可能である。
【0063】
従来、例えば、ビルの窓に設置されたブラインドの制御に関して、ブラインド専用のコントローラー（専用コントローラ）が用いられていた。専用コントローラーでは、ブラインド制御プログラムが実行されて、ブラインドの制御に係る処理が行われていた。つまり、ブラインドと専用コントローラーにより構成される制御系において、制御対象（ここではブラインド）の制御が完結していた。
【0064】
従来より、ビル管理システムにおいては、空調、照明、衛生、セキュリティー、エネルギー等に係る多くの管理項目について監視制御が行われている。これらの管理項目に係る制御（監視制御）においては、前述したように、使用される機器や、機器の製造業者、機種等の違いに応じて、様々な信号規格、通信規格、ＯＳ、プログラム言語等を用いた制御が行われるのが一般的であった。
【0065】
そして、ビル管理の技術分野において、ＩＴ（情報技術）やＯＴ（運用技術）に関する様々な規格が存在し、これらの規格の内容が異なるため、１つのコントローラーに、既存の各種のセンサー類や、ビルの建設業者が選定したセンサー類等の多種類のセンサー類を通信可能に接続することはできなかった。
【0066】
これに対し、本実施形態のビル管理システム１０では、すべての情報の出発点となるアナログデータ（無線式センサー装置３０より収集したデータ）が、レベル０の無線式センサー装置３０自身によりデジタル化される。１つのマイクロ・エッジ・デバイス６０に対し、多数の無線式センサー装置３０のデジタル情報が、マイクロ・エッジ・デバイス６０に集約される。
【0067】
無線式センサー装置３０には、同じデジタル無線通信規格による情報通信を行うものや、互いに異なるデジタル無線通信規格による情報通信を行うものが含まれる。マイクロ・エッジ・デバイス６０は、多数（例えば１５０以上）の数の通信規格（通信プロトコル）を取り扱うことが可能なように構成されている。
【0068】
マイクロ・エッジ・デバイス６０では、多数の無線式センサー装置３０の情報を、無線式センサー装置３０に採用されている通信規格毎に、共通仕様の通信規格（ここではＩＰ（インターネット・プロトコル））に変換して取り扱うことが可能である。つまり、マイクロ・エッジ・デバイス６０においては、異なる通信規格の信号が入力されて、統一された共通仕様の信号が出力される。マイクロ・エッジ・デバイス６０は、対応付けられた設備機器にＩＰアドレスを割り振り、ＩＰアドレスを用いて識別する。
【0069】
マイクロ・エッジ・デバイス６０は、個々に、異なる通信規格の信号を集約して共通仕様の信号が出力されるゲートウェイとして機能する。マイクロ・エッジ・デバイス６０を、管理対象のビルの規模や棟数等に応じて多数備えることにより、複数のゲートウェイにより構成されるゲートウェイ群を大規模に形成することが可能である。なお、各項目系１２、１４、１６、１８、２０と、マイクロ・エッジ・デバイス６０との間に、他のゲートウェイ（細分化されたゲートウェイ）が存在する場合もある。ここでいうゲートウェイ群には、マイクロ・エッジ・デバイス６０とは別の機器として存在するゲートウェイも含まれる。マイクロ・エッジ・デバイス６０とゲートウェイとの関係（位置づけ）は、マイクロ・エッジ・デバイスが上位であり、ゲートウェイが下位である。
【0070】
マイクロ・エッジ・デバイス６０では、無線式センサー装置３０からの情報が吸い上げられ、必要な情報の整理が行われて、上層のアプリケーション・エッジ・デバイス６２（レベル２）に送信される。マイクロ・エッジ・デバイス６０の階層（レベル１）では、例えば、多数のマイクロ・エッジ・デバイス６０によりマイクロ・エッジ・デバイス群６０Ａが構成される。マイクロ・エッジ・デバイス群６０Ａは、概念上、前述のゲートウェイ群に含まれものとすることができる。
【0071】
マイクロ・エッジ・デバイス群６０Ａは、ゲートウェイの機能を発揮してデータの変換（コンバート）を行い、統一化された仕様の情報（パターン化された形式の情報）を上層の、対応付けられたアプリケーション・エッジ・デバイス６２に送信する。
【0072】
このように、無線式センサー装置３０やシーケンサー類によりデジタル化されたアナログデータは、マイクロ・エッジ・デバイス６０で前段階処理され、統一化された仕様の情報となって上位層に送出される。マイクロ・エッジ・デバイス６０では、末端の無線式センサー装置３０でデジタル化された情報が、レベル２でのデータベース化のために前段階処理される。
【0073】
マイクロ・エッジ・デバイス６０としては、図示は省略するが、例えば、ＣＰＵ、記憶部、無線通信部等を備え、マルチプロトコルのデジタル情報を、時分割等の処理や、情報変換の処理により、共通の通信規格に変換するものを採用できる。
【0074】
＜レベル２：アプリケーション・エッジ・デバイス＞
マイクロ・エッジ・デバイス６０の上層（レベル２）にあるのがアプリケーション・エッジ・デバイス６２である。アプリケーション・エッジ・デバイス６２は、ビルの空調、電気、衛生、中央監視等といった管理項目（アプリケーション）毎にデータを集める役割を担う。
マイクロ・エッジ・デバイス６０の上層（レベル２）にあるのがアプリケーション・エッジ・デバイス６２である。アプリケーション・エッジ・デバイス６２は、ビルの空調、電気、衛生、中央監視等といった管理項目（アプリケーション）毎にデータを集める役割を担う。
【0075】
前述したように、マイクロ・エッジ・デバイス６０（レベル１）において、センサー（レベル０）のデータが集約され、センサー（レベル０）でデジタル化されたデータが、マイクロ・エッジ・デバイス６０（レベル１）からアプリケーション・エッジ・デバイス６２（レベル２）に送出される。
【0076】
管理対象のビルの規模にもよるが、例えば、１００個程度のマイクロ・エッジ・デバイス６０に対して、１つのアプリケーション・エッジ・デバイス６２が設置される。所謂中小ビルのレベルであれば、１台のアプリケーション・エッジ・デバイス６２により、ビル全体の管理が可能である。この場合、後述のレベル３及びレベル４は省略することが可能である。
【0077】
アプリケーション・エッジ・デバイス６２には、中央監視機能が備えられている。中央監視機能は、エネルギー・マネジメント・システム（ＥＭＳ）の監視や制御のための処理を行い、得られた情報を外部機器に提供できるようにした機能である。中央監視機能部により、各無線式センサー装置３０で収集された情報に基づき、電力量等の情報がリアルタイムに処理され、統計的に視覚化されて、表示可能な情報として出力される。つまり、エネルギー・マネジメント・システム（ＥＭＳ）の監視・制御システムが、アプリケーション・エッジ・デバイス６２の中に組み込まれている。
【0078】
アプリケーション・エッジ・デバイス６２では、図３に示すように、マイクロ・エッジ・デバイス６０から送られた情報が、データベース作成用のソフトウェアに読み込まれ（Ｓ(ステップ)１１）、自動的にデータベースが作成される（Ｓ１２）。さらに、個別の認識データの設定（パラメータ設定など）には、プロダクティビティ・ツールが用いられている。
【0079】
プロダクティビティ・ツールは、本実施形態のビル管理システム１０で使用されるアプリケーションソフトの１つとして開発されたものである。プロダクティビティ・ツールについては後述する。データベース作成用のソフトウェアとしては、一般的な種々のものを採用できる。
【0080】
作成されたデータベースには、図４に示すように、収集されたデータの各種の属性（プロパティを含む）が記録されている。記録される属性としては、ＩＰアドレス、ビル名、フロア、エリア、管理項目、情報種別、情報取得日、情報取得時刻などの情報が含まれる。また、センサー類の情報である場合には、各センサーの検出値などの情報（検出値情報）や、オン／オフの情報なども含まれる。
【0081】
従来、インテリジェントセンサーや、マイクロ・エッジ・デバイス６０への設定データの登録は、一つずつ手作業で打ち込む必要があった。このような作業は、打ち込み作業そのものが多くの手間を要するほか、データの特性や仕組み等を理解していなければ行うことができなかった。本実施形態のビル管理システム１０によれば、自動的にデータベースが作成されるので、手作業や、仕組み等の理解を要することなく、データ登録を行うことが可能である。
【0082】
さらに、アプリケーション・エッジ・デバイス６２では、中央監視機能部を用いて、データベース化された情報に基づき、各設備機器から収集した温度や湿度、電力量といった情報をリアルタイムに、統計的に視覚化して表示するための情報を出力できる。出力された情報は、インターネット回線（公衆無線通信回線、及び、公衆有線通信回線）６８を介して、ビル管理者のＰＣ（パーソナルコンピュータ）に接続された表示装置や、携帯情報端末などに表示される。ビル管理者のＰＣや携帯情報端末にインストールされているブラウザを介して、中央監視用アプリケーションソフトへの接続が行われる。
【0083】
前述のＥＭＳ（エネルギー・マネジメント・システム）は、情報の見える化を行っている。すなわち、センサーや照明、空調、衛生、エネルギーといった各機器から集められた情報は、それらが単に存在するだけでは価値を生まない。これらのデータ（情報）を、種類別に分類し、必要な部分、必要な時間だけを集計し、統計処理した上で、画面表示してこそ価値が生まれる。
【0084】
本実施形態のビル管理システム１０におけるＥＭＳは、電気の使用量を様々なグラフで見ることができるよう構成されている。もちろん、使用している様々な設備機器毎の電気量も見ることが可能である。
【0085】
一般に、ビルで消費するエネルギーの６５％は、空調と照明である。点きっぱなしになっている空調と照明を、外部温度や日光などの周辺環境の状態や、人の在室・在籍の状況に応じてコントロールすることができれば、消費エネルギーを大きく節減することができる。
【0086】
電力の使用量を解析するためには、機器の運転状況、温度、外気温等の複合要素の分析も必要である。本実施形態におけるビル管理システム１０では、エネルギー管理については、トレンドデータの表示が可能となっている。トレンドデータは、最速１秒単位で多くのテータを取り込むことが可能である、このため、エネルギー分析には最適である。
【0087】
このようなＥＭＳを使用して、エネルギー種別毎の使用量、時系列のエネルギー解析が可能である。さらに、設備機器を選択して、設定や状況表示をリアルタイムに行うことが可能である。
【0088】
前述のプロダクティビティ・ツールは、同一ネットワーク上に設置されたセンサー類やスイッチ類、及び、各設備機器等の情報を自動収集し、データベース化する（図４）。作成されたデータベースに対して、一つひとつの設定情報を効率的に登録することができる。
【0089】
従来は、ビル内の照明器具や空調、衛生などの各機器やセンサーから情報を収集して、現在の使用状況を表示したり、制御したりするためには、すべての機器とその機能に対して、一つずつ設定作業を行う必要があった。
【0090】
例えば、接点情報（監視点数）が数十万点もある巨大ビルに限らず、数百点であっても、その設定を一つずつ手で行わなければならず、非常に多くの時間を要していた。しかも、その情報が現在どうなっているのかといった事項を確認する状態管理にも多くの手間を要していた。
【0091】
本実施形態のビル管理システム１０では、このような問題を解決するために、前述のプロダクティビティ・ツールが用いられている。プロダクティビティ・ツールを用いることにより、従来、設定するだけで何十日もかかっていた作業がわずかな時間で行えるようになる。しかも登録するデータは、遠隔地からのダウンロードにより設定可能である。プロダクティビティ・ツールにより、工事作業が大幅に簡便化されるとともに、工事費用も大きく削減されることとなる。
【0092】
＜レベル３：統合コントローラー（統合・エッジ・デバイス）＞
ビル内には、空調、電気、衛生、中央監視といったアプリケーション別のシステム（アプリケーション別システム）が多く構築されている。本実施形態のビル管理システム１０における統合コントローラー（統合・エッジ・デバイス６４）は、これらのアプリケーション別システムを統合し、受信した情報を、インターネット回線（公衆無線通信回線、及び、公衆有線通信回線）６８を介して、さらに上位のシステムへと順次伝達する。情報の伝達には、ＬＡＮ（ローカル・エリア・ネットワーク、構内ネットワーク）も適宜利用される。
ビル内には、空調、電気、衛生、中央監視といったアプリケーション別のシステム（アプリケーション別システム）が多く構築されている。本実施形態のビル管理システム１０における統合コントローラー（統合・エッジ・デバイス６４）は、これらのアプリケーション別システムを統合し、受信した情報を、インターネット回線（公衆無線通信回線、及び、公衆有線通信回線）６８を介して、さらに上位のシステムへと順次伝達する。情報の伝達には、ＬＡＮ（ローカル・エリア・ネットワーク、構内ネットワーク）も適宜利用される。
【0093】
本実施形態のビル管理システム１０において、統合コントローラー（統合・エッジ・デバイス６４）のハードウェア及びソフトウェアは、１台が、床面積が１０万平米のビルを管理できる程度の処理能力を有するよう構築されている。１０万平米は１０ｈａであり、３１６ｍ×３１６ｍのフロア、又は、１フロアが５０ｍ×５０ｍの４０階建てビルに相当する。このように、１台の統合コントローラー（統合・エッジ・デバイス６４）により、相当程度の規模の管理が可能である。
【0094】
＜レベル４：エンタープライズ・エッジ・サーバー＞
本実施形態のビル管理システム１０においては、マイクロ・エッジ・デバイス６０（レベル１）、アプリケーション・エッジ・デバイス６２（レベル２）、統合エッジ・デバイス６４（レベル３）の上層に、エンタープライズ・エッジ・サーバー６６（レベル４）の階層が構築されている。これらのデバイスやサーバーは、いずれも、コンピュータ機器を用いて構成されるが、これらの間の大きな違いは、コンピュータ機器としての性能（処理容量、処理速度など）と、メモリ領域の利用形態である。
本実施形態のビル管理システム１０においては、マイクロ・エッジ・デバイス６０（レベル１）、アプリケーション・エッジ・デバイス６２（レベル２）、統合エッジ・デバイス６４（レベル３）の上層に、エンタープライズ・エッジ・サーバー６６（レベル４）の階層が構築されている。これらのデバイスやサーバーは、いずれも、コンピュータ機器を用いて構成されるが、これらの間の大きな違いは、コンピュータ機器としての性能（処理容量、処理速度など）と、メモリ領域の利用形態である。
【0095】
従来は、監視点数の制約が大きかったが、本実施形態のビル管理システム１０におけるエンタープライズ・エッジ・サーバー６６は、管理対象のビルの規模や棟数が増えて、性能が足りない場合には、未使用のスロット使用し、ＣＰＵの数を増やすことにより対応できるようにしている。また、より処理能力の高いＣＰＵを搭載した基板（ボード）に交換することでも、性能を向上できる。
【0096】
さらに、エンタープライズ・エッジ・サーバー６６としては、ＶＭ（Virtual Machine、仮想マシン）を構成することが可能なコンピュータ機器が用いられている。ＶＭを構成することにより、管理システムの多重化（ここでは二重化）が可能である。
【0097】
ＶＭは、システムの他の部分から分離され、１台のハードウェア上で複数が共存するよう構築される。ＶＭにより、複数の異なるＯＳ（オペレーティング・システム）を１台のコンピュータ機器上で同時に実行できるようになる。
【0098】
例えば、ビル管理のシステムを改修しようとした場合、改修後にも、Windows NT（登録商標）やXPなどといった、近年では新たに導入されることがない古いＯＳ（オペレーティング・システム）を使用し続けなければならないことがある。
【0099】
従来のビル管理システムでは、監視サーバーがＯＳに依存しているため、上位層の機器を変更すると、上位層に合わせて下位層の機器をもすべて変えなければならない。このため、下位層の機器の少なくとも一部を維持したままシステムを新しくしようとしても、過去のシステムに引きずられ、古いＯＳを残しておく必要がある。
【0100】
本実施形態のビル管理システム１０においては、エンタープライズ・エッジ・サーバー６６は、仮想サーバーを構成できる。このため、新たにエンタープライズ・エッジ・サーバー６６を導入した場合に、エンタープライズ・エッジ・サーバー６６において、多様なＯＳを並行して動作させることが可能である。そして、例えば、Linux（登録商標）とWindows NT（登録商標）を並行して動作させる、といったことが可能である。
【0101】
したがって、ビル管理システムの改修の際に、下位層の機器を残し、上位層だけを新しいものに交換するといったことが可能となる。しかも、複数のＯＳに係るシステムをそれぞれ構築することが可能である。このような考え方そのものが、従来と違って、新しい取り組みを示すものである。そして、ＶＭに古いＯＳを残すことができるため、システム改修時のサーバー機器の置き換えが、従来に比べて非常に楽なものとなる。
【0102】
エンタープライズ・エッジ・サーバー６６を用いるメリットは大きい。単に構成する機器のサイズが小さくなっただけではなく、所定期間（７年程度）毎に発生する改修作業をも容易にする。
【0103】
従来では、大規模システムの改修には保有システムの退避・保存・リロード等を行うためには丸１日要していた。さらに、サーバー台数分の作業を行う必要があったため、改修作業全体として、何日もの日程を要していた。
【0104】
本実施形態のビル管理システム１０では、エンタープライズ・エッジ・サーバー６６を用いることにより、このような問題が解決され、システムを停止させることなく、ホット・スワップ（電源を入れたまま）での機器改修（交換・増設等）が可能となった。ホット・スワップでの機器改修を行えるようにするためには、エンタープライズ・エッジ・サーバー６６を二重化構成として冗長化することが可能である。この場合、一方のエンタープライズ・エッジ・サーバー６６を稼働させながら、もう一方のエンタープライズ・エッジ・サーバー６６を改修する。
【0105】
＜エッジ・デバイスの働き＞
＜＜分散システム＞＞
本実施形態に係るビル管理システム１０の一つの大きな特徴は、無線通信やインターネット通信を適切に組み合わせることにより、監視点数の増大を容易に行えるようにしていることである。従来のビル管理システムでは監視点数に制限があり、その制限は、数千から、多ければ数万程度である。ビルのインテリジェント化や、複数のビルの管理を行う多棟管理を進めようとすると、管理能力が容易に限界に達してしまう。従来のビル管理システムにより、管理点数の制限を超えるシステムを導入する場合は、特別にプログラムを組み、複数のサーバーをブリッジさせる必要があった。
＜＜分散システム＞＞
本実施形態に係るビル管理システム１０の一つの大きな特徴は、無線通信やインターネット通信を適切に組み合わせることにより、監視点数の増大を容易に行えるようにしていることである。従来のビル管理システムでは監視点数に制限があり、その制限は、数千から、多ければ数万程度である。ビルのインテリジェント化や、複数のビルの管理を行う多棟管理を進めようとすると、管理能力が容易に限界に達してしまう。従来のビル管理システムにより、管理点数の制限を超えるシステムを導入する場合は、特別にプログラムを組み、複数のサーバーをブリッジさせる必要があった。
【0106】
本実施形態のビル管理システム１０では、エンタープライズ・エッジ・サーバー６６が仮想サーバーを構成するため、ＣＰＵの増加により処理能力を容易に増強することが可能である。これにより、無限のリソースといえるハードディスク（記憶手段）も利用して、巨大なビル管理システムを構築することが可能となる。
【0107】
また、ビル管理システム１０の一つの大きな特徴は、分散システムである。例えば、一つのサーバーを二つに分散することができる。サーバーを分割するが、すべてのデータを一つに集めなくてもよく、分散しておいて、必要に応じて取ってくる（オンデマンドで集める）ことができるようにしている。つまり、すべてのサーバーを繋ぐ必要がない。
【0108】
必要な時に、必要な操作を行うことにより、複数のサーバーから、必要なデータを集めることが可能である。本実施形態のビル管理システム１０では、例えば、「データＡとデータＢとデータＣだけが欲しい」旨のコマンドをＰＣや携帯情報端末に入力すると、必要なデータが出力される。本実施形態のビル管理システム１０は、あたかも１つのコンピュータが処理しているように動作する。
【0109】
従来のビル管理システムは、ほとんどがクライアント・サーバー型であり、このような動作はできない。従来のビル管理システムは、分散型にはなることはできず、大きなシステムにならざるを得なかった。この限界を超える仕組みを構築したことが、本実施形態のビル管理システム１０の特徴の一つである。
【0110】
＜＜エッジ・サーバーの活用＞＞
従来のビル管理システムは、一つのサーバーの中にデータを集約し、その中を統括して管理していた。このため、システム自体が大きくなっていた。しかし、本実施形態のビル管理システム１０は、エッジ・サーバーを使うことでシステムを分散化している。そして、分散化は行っているが、例えば「マイクロ・エッジ・デバイス６０の特定のデータを見たい」旨のコマンドを入力すると、オンデマンドでデータを見ることができる。
従来のビル管理システムは、一つのサーバーの中にデータを集約し、その中を統括して管理していた。このため、システム自体が大きくなっていた。しかし、本実施形態のビル管理システム１０は、エッジ・サーバーを使うことでシステムを分散化している。そして、分散化は行っているが、例えば「マイクロ・エッジ・デバイス６０の特定のデータを見たい」旨のコマンドを入力すると、オンデマンドでデータを見ることができる。
【0111】
＜＜統一データ様式＞＞
本実施形態のビル管理システム１０における他の特徴の一つは、情報の管理がすべて、統一された様式で行われることである。前述のように、無線式センサー装置３０を用いることにより、統一された様式のデータが自動的に収集される。しかもその様式は、先に述べた４種類のエッジ・デバイス（マイクロ・エッジ・デバイス６０、アプリケーション・エッジ・デバイス６２、統合・エッジ・デバイス６４、及び、エンタープライズ・エッジ・サーバー６６）のすべてで共通化されている。
本実施形態のビル管理システム１０における他の特徴の一つは、情報の管理がすべて、統一された様式で行われることである。前述のように、無線式センサー装置３０を用いることにより、統一された様式のデータが自動的に収集される。しかもその様式は、先に述べた４種類のエッジ・デバイス（マイクロ・エッジ・デバイス６０、アプリケーション・エッジ・デバイス６２、統合・エッジ・デバイス６４、及び、エンタープライズ・エッジ・サーバー６６）のすべてで共通化されている。
【0112】
マイクロ・エッジ・デバイス６０（レベル１）で取り扱われるデータ様式の構造と、その上位にあるアプリケーション・エッジ・デバイス６２（レベル２）、統合エッジ・デバイス６４（レベル３）、及び、エンタープライズ・エッジ・サーバー６６（レベル４）の構造は同じである。このため、上位レベルのエッジ・デバイスにおいて、上位レベルのエッジ・デバイスのデータを引き継ぐことができる。
【0113】
以上のようにして統一様式のデータが作成され、作成されたデータが、多様な管理項目（空調、電気、衛生、中央監視等といった種々のアプリケーション）において活用される。統一様式のデータを利用することにより、あたかも、共通な接続構造を有するブロック玩具を組み合わせて目的の造形を作り上げるように、全体的に統合されたビル管理システム１０を構築できるようになる。
【0114】
＜クラウドの活用＞
＜＜遠隔監視＞＞
本実施形態のビル管理システム１０では、クラウドが活用されている。このため、ビル監視者や一般利用者が、それぞれ独自にサーバーや記憶装置を持たずに、公共通信網を利用して、ビル管理のサービスを受けることが可能である。このようにクラウドを使用する理由の一つは、遠隔監視を行うためである。
＜＜遠隔監視＞＞
本実施形態のビル管理システム１０では、クラウドが活用されている。このため、ビル監視者や一般利用者が、それぞれ独自にサーバーや記憶装置を持たずに、公共通信網を利用して、ビル管理のサービスを受けることが可能である。このようにクラウドを使用する理由の一つは、遠隔監視を行うためである。
【0115】
ただし、複数の下位機器からデジタル化されたデータをそのまま上位層に上げてしまうと、データを受け取る上位機器で、通信量が増大し、データ処理速度の低下を招きかねない。
【0116】
発明者等の知見では、ビル管理のためにクラウドを使用する場合、センサー類やスイッチ類により現場（ビル管理システム１０の末端）から集められたデータのうち、クラウドに上げるべきデータは、実際のところ、全収集データの数％（例えば３％程度）で十分である。その数％は、例えば、ＥＭＳ（エネルギー・マネジメント・システム）、エネルギーのデータ、ＦＭＳ（施設管理システム）である。これらのデータを、例えば、３０分に一度や、１時間に一度程度の頻度で収集するだけでも、十分なビル管理を行うことは可能である。
【0117】
ビル管理に必要なデータは、時々刻々とダイナミックに変化するようなものよりも、スタティックなデータ、つまり静的データである。静的データについては、一定の時間間隔で収集して累積するだけでも、ビル管理においては十分である。このため、後述するように、オンプレミスによるデータ収集と、クラウドによるデータ収集とを併用したビル管理が行われる。何をクラウドに上げれば、全体のパフォーマンスが最大化するかを考慮し、何をスタティックデータとしてクラウドに上げ、何をダイナミックデータとしてアプリケーション・エッジ・デバイスに残しておくかが選定される。
【0118】
＜＜オンプレ・クラウド＞＞
現在、クラウドサービスは、情報処理サービスの主流となっている。クラウドサービスについては、とにかく多くのデータを集めてビッグデータを集積すればよいと考えられがちであるが、ビル管理システムに応用した場合、実際に膨大なデータを集めても、有効なビル管理システムを構築することは難しかった。
現在、クラウドサービスは、情報処理サービスの主流となっている。クラウドサービスについては、とにかく多くのデータを集めてビッグデータを集積すればよいと考えられがちであるが、ビル管理システムに応用した場合、実際に膨大なデータを集めても、有効なビル管理システムを構築することは難しかった。
【0119】
有効なビル管理システムの構築が難しかった原因として、集積されたデータの情報をどのように取り扱えばよいかが分かり難く、せっかく集められたデータの９０％以上は使う必要さえない、といった場合もあった。
【0120】
現場（ビル管理システム１０の末端）で収集されたデータの１００％すべてをクラウドに乗せても（アップロードしても）、そのうちの９０％以上のデータは、何らかのトラブルが発生したような場合以外は使われない。
【0121】
クラウドに上げる（アップロードする）には、通信費が発生し、ＣＰＵ使用料も発生し、クラウドに上げるための情報を記憶しておく保存領域（「使用領域」ともいう）も必要になる。もし、すべての発生データを保存しておけるような保存領域を確保する場合には、保存領域の大きさは、ギガバイトやテラバイトといった単位の大きさでは済まず、ペタバイト以上に達すると予想される。そのうえ、クラウドの保存容量が巨大なり、クラウドの維持や管理に、当然、莫大な費用を要することとなる。
【0122】
そこで、本実施形態のビル管理システム１０は、エッジ・デバイス（現場で前処理するシステム）を活用し、オンプレミスなデータ処理とクラウドサービスとを適切に使い分けることにより、有効なビル管理システムの構築を可能としている。
【0123】
本実施形態のビル管理システム１０では、すべてのデータをクラウドに乗せる（アップロードする）のではなく、選択されたデータがクラウドに乗せられる。平常時は、スタティックなデータのみを選択的に上げ、所定の条件が成立した場合（例えば、警報（アラーム）が発せられた場合など）に限り、その他のデータ（例えば履歴データ）がオンプレミスのデータから利用される。
【0124】
このようにすることで、例えば、警報が出た場合に、警報の原因となった事象が発生した時間帯のオンプレミスのデータを参照することで、原因を調査するための処理プログラムを実行する、といったことが可能となる。そして、通信量と保存領域の抑制、通信速度やレスポンス（応答）速度の向上が図られている。
【0125】
＜＜技術の統合＞＞
本実施形態のビル管理システム１０では、収集したデータをクラウドで活用したり、オンプレミスで活用したりするために種々の機器類や、ツール（アプリケーションソフト）類が備えられている。これらの機器類やツール類は、個別に存在しているのではなく、互いに連携している。そして、これらの機器類やツール類は、システムのパフォーマンスを最大化するために不可欠のものとなっている。
本実施形態のビル管理システム１０では、収集したデータをクラウドで活用したり、オンプレミスで活用したりするために種々の機器類や、ツール（アプリケーションソフト）類が備えられている。これらの機器類やツール類は、個別に存在しているのではなく、互いに連携している。そして、これらの機器類やツール類は、システムのパフォーマンスを最大化するために不可欠のものとなっている。
【0126】
＜中央監視機能＞
＜＜ＩＴとＯＴの融合による多彩な見える化を実現＞＞
ビル管理システムの大きな目的は、ビル内に設置された機器類の一元的な状態監視と制御である。従来は、このような全体的な管理が難しかった。しかし、本実施形態のビル管理システム１０は、様々な工夫を組み合わせて、全体的な管理を実現している。例えば、電力量については、所定期間（指定期間）における全体の合計や、機器毎の合計について、可視化（見える化）が行われている。そして、いつ、どこで、どの機器が、どのくらいの電力を使用しているか、といった事項が確認できるようになっている。
＜＜ＩＴとＯＴの融合による多彩な見える化を実現＞＞
ビル管理システムの大きな目的は、ビル内に設置された機器類の一元的な状態監視と制御である。従来は、このような全体的な管理が難しかった。しかし、本実施形態のビル管理システム１０は、様々な工夫を組み合わせて、全体的な管理を実現している。例えば、電力量については、所定期間（指定期間）における全体の合計や、機器毎の合計について、可視化（見える化）が行われている。そして、いつ、どこで、どの機器が、どのくらいの電力を使用しているか、といった事項が確認できるようになっている。
【0127】
＜＜照明・温度・湿度等の見える化＞＞
本実施形態のビル管理システム１０において、照明については、照明の点灯状況のほか、オン／オフ、及び、調光制御の状況等を、特定の態様で画面表示することが可能である。また、室内環境については、室内のＣＯ２濃度、温度、湿度などを、特定の態様（ヒートマップなど）で画面表示することが可能である。
本実施形態のビル管理システム１０において、照明については、照明の点灯状況のほか、オン／オフ、及び、調光制御の状況等を、特定の態様で画面表示することが可能である。また、室内環境については、室内のＣＯ２濃度、温度、湿度などを、特定の態様（ヒートマップなど）で画面表示することが可能である。
【0128】
＜＜環境の見える化－トレンドグラフ＞＞
本実施形態のビル管理システム１０においては、温度、湿度、照度等を、トレンドグラフによっても画面表示することが可能である。
本実施形態のビル管理システム１０においては、温度、湿度、照度等を、トレンドグラフによっても画面表示することが可能である。
【0129】
＜＜利用状況や連携アプリケーション＞＞
本実施形態のビル管理システム１０においては、スケジュール、操作履歴、帳票、地震警報システム、クラウドアプリケーションなども画面表示することが可能である。
本実施形態のビル管理システム１０においては、スケジュール、操作履歴、帳票、地震警報システム、クラウドアプリケーションなども画面表示することが可能である。
【0130】
＜遠隔監視機能＞
＜＜多棟管理を可能にするクラウド監視システム＞＞
本実施形態のビル管理システム１０においては、ビル内の空調、照明、衛生、警報、エネルギーに関する各種の機器類について、スマートフォンやタブレット等の携帯情報端末を介して、監視や制御を行うことができる。また、ビルから離れた遠隔地からも、携帯情報端末を介して、監視や制御を行うことができる。
＜＜多棟管理を可能にするクラウド監視システム＞＞
本実施形態のビル管理システム１０においては、ビル内の空調、照明、衛生、警報、エネルギーに関する各種の機器類について、スマートフォンやタブレット等の携帯情報端末を介して、監視や制御を行うことができる。また、ビルから離れた遠隔地からも、携帯情報端末を介して、監視や制御を行うことができる。
【0131】
携帯情報端末では、インストールされたブラウザを介して、ビル管理のためのアプリケーションソフトに接続し、アプリケーションソフトを利用することが可能である。携帯情報端末のブラウザを介して、操作し易く、レスポンス（応答性）の良い管理画面が提供される。
【0132】
前述したように、クラウドに乗せるのはスタティックデータのみであり、利用頻度の少ないダイナミックデータはエッジ・デバイスに配置される。このため、クラウドの使用領域が小さく、費用低減や、レスポンス（応答性）の向上が実現される。データ処理量そのものを削減することで、処理に要する時間を削減できる。集計しやすい形（少ない量）でのデータの保管を行う保管形式を採用できる。これらによってもレスポンス（応答性）の向上が実現される。
【0133】
＜＜ＣＢＭの実現＞＞
複数のビルの管理を行う多棟管理においては、どのビルで障害（異常）が発生しているかを知ることが重要である。従来は、異常の発生を常時確認しているような常時監視が行われていた。これに対し、本実施形態のビル管理システム１０においては、定期的にデータを採取したうえで、異常が発生した場合にだけ対応が行われる「予防保全」（ＣＢＭ： Condition Based Maintenance）が実現されている。
複数のビルの管理を行う多棟管理においては、どのビルで障害（異常）が発生しているかを知ることが重要である。従来は、異常の発生を常時確認しているような常時監視が行われていた。これに対し、本実施形態のビル管理システム１０においては、定期的にデータを採取したうえで、異常が発生した場合にだけ対応が行われる「予防保全」（ＣＢＭ： Condition Based Maintenance）が実現されている。
【0134】
定期的に採取されるデータに基づき、異常が発見された場合には、携帯情報端末に警報（アラーム）が通知される、といった対策が施されている。さらに、アラームが発生したビルを指定し、ドリルダウンすることで、遠隔地からでもより詳細な状況把握を行うことができる。ドリルダウンにおいては、アラームが発生したビルの属性に紐付けられたデータを選んで、予め定められた各種の分析が実行される。
【0135】
＜手のひらで監視・制御が可能なスマートパーム（商標登録出願中）＞
本実施形態のビル管理システム１０では、最新のテクノロジーを駆使し、新しい時代にふさわしい、照明とエアコンを制御するインテリジェントなツールが実現されている。ビル管理者や一般利用者等にブラウザを介して提供されるスマートパーム（商標登録出願中）は、照明と空調の両方のリモコン（遠隔操作）を携帯情報端末上で実現して、オフィス内の照明やエアコンを制御・監視することを可能とする。スマートパーム（商標登録出願中）は、あたかも手のひらがスイッチになったような操作性を提供するツールである。
＜＜ネットワークをまたいだ遠隔監視が可能＞＞
本実施形態のビル管理システム１０においては、スマートフォンやタブレット等の携帯情報端末を利用することにより、場所や時間等の制約に縛られず、どこからでもビル管理システムを制御することが可能である。
本実施形態のビル管理システム１０では、最新のテクノロジーを駆使し、新しい時代にふさわしい、照明とエアコンを制御するインテリジェントなツールが実現されている。ビル管理者や一般利用者等にブラウザを介して提供されるスマートパーム（商標登録出願中）は、照明と空調の両方のリモコン（遠隔操作）を携帯情報端末上で実現して、オフィス内の照明やエアコンを制御・監視することを可能とする。スマートパーム（商標登録出願中）は、あたかも手のひらがスイッチになったような操作性を提供するツールである。
＜＜ネットワークをまたいだ遠隔監視が可能＞＞
本実施形態のビル管理システム１０においては、スマートフォンやタブレット等の携帯情報端末を利用することにより、場所や時間等の制約に縛られず、どこからでもビル管理システムを制御することが可能である。
【0136】
＜＜照明・空調の制御＞＞
本実施形態のビル管理システム１０においては、携帯情報端末を使って、空調や照明等の制御を直接行うことができる。このため、例えば、オフィスの照明や空調（エアコン）の温度を変更するために、オフィス内の人員が壁のスイッチまで移動することが不要になる。
本実施形態のビル管理システム１０においては、携帯情報端末を使って、空調や照明等の制御を直接行うことができる。このため、例えば、オフィスの照明や空調（エアコン）の温度を変更するために、オフィス内の人員が壁のスイッチまで移動することが不要になる。
【0137】
例えば、照明に関しては、フロア内の全灯について、一括してオン／オフしたり、グループ別にオン／オフしたりすることができるよう、システムが構築されている。また、輝度を上下させる調光についても、手元から操作することができるように、システムが構築されている。
【0138】
また、ブラウザを介して提供されるスマートパーム（商標登録出願中）には、例えば、フロア単位、グループ単位、及び、照明単位で、電気使用量を表示する機能が備えられている。このため、携帯情報端末を介して、対象の範囲での電気使用量がどの程度であるのかを確認できる。
【0139】
＜＜設定とＱＲコード（登録商標）の生成＞＞
本実施形態のビル管理システム１０においては、一度設定された照明や空調（エアコン）のグループを、携帯情報端末において変更することが可能となっている。このようにすることにより、例えば、空調の工事業者や、システムの工事業者に、ビル内のテナントが休業している週末を利用してグループ変更の作業を実施してもらう、といったことが不要になる。
本実施形態のビル管理システム１０においては、一度設定された照明や空調（エアコン）のグループを、携帯情報端末において変更することが可能となっている。このようにすることにより、例えば、空調の工事業者や、システムの工事業者に、ビル内のテナントが休業している週末を利用してグループ変更の作業を実施してもらう、といったことが不要になる。
【0140】
このような作業を行う際には、照明や空調（エアコン）を制御するために、例えば、設定管理用の一般利用者のグループにおいて、予め定められたグループ管理者にＱＲコード（登録商標）が配布される。ＱＲコード（登録商標）は、グループ管理者から、他のグループ員に配布される。グループは、設定が許容されるよう予め定め指定された範囲の一般利用者（ビル管理者や、その他の管理者が含まれていてもよい）により構成される。設定が許容される照明の範囲は、後述する照明のデザインツールを用いて行われる。
【0141】
配布されたＱＲコード（登録商標）は、グループ員のＰＣに接続された表示装置や携帯情報端末等に表示される。ＱＲコード（登録商標）は、グループ員の他の携帯情報端末のカメラで読み取られ、ＵＲＬ等が表示される。ＵＲＬ等は、対応するアプリケーション・エッジ・デバイス６２に係る設定変更サイトにリンクしている。
【0142】
グループ員が、ＵＲＬ等を選択すると、対応するアプリケーション・エッジ・デバイス６２に係る設定変更サイトが、グループ員の携帯情報端末に表示される。グループ員は、設定変更サイトにおいて、設定を変更したい設備機器の設定を操作する。
【0143】
このようにすることで、一般利用者は、設定変更用のアプリケーションソフトをインストールすることなく、ブラウザを介して、照明やエアコンのグループ変更を行うことができる。
【0144】
＜＜複数のプロジェクトを設定可能＞＞
携帯情報端末を介して設定された内容は、プロジェクトとして保存することが可能である。プロジェクトは、複数保存することが可能である。これにより、例えば、時間帯毎に設定を変えたり、平日と週末で、照明や空調のグループを変えたりすることが可能となる。このようにすることで、グループの変更のために、壁に新たにスイッチや操作盤を取り付ける必要がない。また、スイッチや操作盤に配線を繋げて壁内や床下等に引き回す工事を行う必要もない。さらに、工事業者に作業を依頼することなく、利用者が自社内で設定変更することが可能である。
携帯情報端末を介して設定された内容は、プロジェクトとして保存することが可能である。プロジェクトは、複数保存することが可能である。これにより、例えば、時間帯毎に設定を変えたり、平日と週末で、照明や空調のグループを変えたりすることが可能となる。このようにすることで、グループの変更のために、壁に新たにスイッチや操作盤を取り付ける必要がない。また、スイッチや操作盤に配線を繋げて壁内や床下等に引き回す工事を行う必要もない。さらに、工事業者に作業を依頼することなく、利用者が自社内で設定変更することが可能である。
【0145】
＜＜照明のデザインツール＞＞
照明器具を設置するにあたっては、フロア内にどれくらいの機器を設置すればよいのか、設置した照明と電源をオン・オフするスイッチとの間のグループ化（グルーピング）をどのように行えばよいのか、といった事項が重要な焦点となる。過度に細かく設計してしまうと、制御が複雑になり、多くの制御用の機械が必要となる。逆に、過度に粗く設計してしまうと、例えば、人がいないところも照明が点灯するなどといった無駄が発生する。
照明器具を設置するにあたっては、フロア内にどれくらいの機器を設置すればよいのか、設置した照明と電源をオン・オフするスイッチとの間のグループ化（グルーピング）をどのように行えばよいのか、といった事項が重要な焦点となる。過度に細かく設計してしまうと、制御が複雑になり、多くの制御用の機械が必要となる。逆に、過度に粗く設計してしまうと、例えば、人がいないところも照明が点灯するなどといった無駄が発生する。
【0146】
このため、本実施形態のビル管理システム１０では、アプリケーションソフトの１つとして、照明のデザインツールを開発している。照明のデザインツールは、例えば、ビル監視者が、アプリケーション・エッジ・デバイス６２（レベル２）に接続し、表示された照明のデザインツールのサイト内において、設計のための操作を行う。
【0147】
＜クラウドを利用した点についての詳細＞
これまで、本実施形態に係るビル管理システム１０の全体像について説明した。以下では、前述したようにクラウドを利用している点に焦点をあて、クラウドを利用するに至った背景や、クラウドを利用した場合の利点等について説明する。なお、クラウドを利用すること特徴を明確にするため、以下に、これまでの説明と重複する内容についても説明する。
これまで、本実施形態に係るビル管理システム１０の全体像について説明した。以下では、前述したようにクラウドを利用している点に焦点をあて、クラウドを利用するに至った背景や、クラウドを利用した場合の利点等について説明する。なお、クラウドを利用すること特徴を明確にするため、以下に、これまでの説明と重複する内容についても説明する。
【0148】
＜＜1 課題＞＞
＜＜＜1.1.1 実施形態に係るビル管理システムの目的＞＞＞
ビル管理システムは従来、ビル内に閉じた形で、運営されていた。
ビル管理システムを監視する人は、監視ルームに設置されたパソコン上の監視画面を見て、異常が発生していないかを常時監視する必要があった。
しかも、照明機器は照明用のビル管理システム、空調機器は空調用のビル管理システム、衛生機器は衛生用のビル管理システム、警報機器は警報用のビル管理システム、エネルギー機器はエネルギー用のビル管理システムのように、ビル管理システムそのものが分断されていた。
前述の実施形態に係るビル管理システム１０は、監視ルームから人を開放し、機器別に分断されていたビル管理システムを統合し、インターネット回線が利用できれば、ビル外のどこからでもビル内機器を監視することができることを目的の一つとしている。
＜＜＜1.1.1 実施形態に係るビル管理システムの目的＞＞＞
ビル管理システムは従来、ビル内に閉じた形で、運営されていた。
ビル管理システムを監視する人は、監視ルームに設置されたパソコン上の監視画面を見て、異常が発生していないかを常時監視する必要があった。
しかも、照明機器は照明用のビル管理システム、空調機器は空調用のビル管理システム、衛生機器は衛生用のビル管理システム、警報機器は警報用のビル管理システム、エネルギー機器はエネルギー用のビル管理システムのように、ビル管理システムそのものが分断されていた。
前述の実施形態に係るビル管理システム１０は、監視ルームから人を開放し、機器別に分断されていたビル管理システムを統合し、インターネット回線が利用できれば、ビル外のどこからでもビル内機器を監視することができることを目的の一つとしている。
【0149】
＜＜＜1.1.2 クラウド監視できるための前提条件＞＞＞
当然であるが、１つには、ビル内において、照明、空調、衛生、警報、エネルギー機器の監視ができる必要がある。この実現方法については、前述している。
他にも、クラウド上に保存されているデータを、遠隔地から利用できるしくみが必要である。
当然であるが、１つには、ビル内において、照明、空調、衛生、警報、エネルギー機器の監視ができる必要がある。この実現方法については、前述している。
他にも、クラウド上に保存されているデータを、遠隔地から利用できるしくみが必要である。
【0150】
＜＜＜1.1.3 クラウド利用ビル管理システムが困難な理由＞＞＞
なおここで、出願人が開発したクラウド利用ビル管理システムを、これまで実現できていなかった原因について考察する。
なおここで、出願人が開発したクラウド利用ビル管理システムを、これまで実現できていなかった原因について考察する。
【0151】
＜＜＜1.1.4 ビッグデータを集めることにしか意識がない＞＞＞
現在のＩＴ業界では、クラウド利用が当たり前のようになるほど、クラウドが普及しているといってもよい。
その議論の延長には、ビッグデータの利用というものが存在する。
ビッグデータは、日々現場で発生している様々なデータをそのままクラウドに乗せたものを意味する。
極端な言い方をすれば、ビッグデータを集めることで、何か付加価値を生み出すことができるのではないかと考える思考方法である。
現在のＩＴ業界では、クラウド利用が当たり前のようになるほど、クラウドが普及しているといってもよい。
その議論の延長には、ビッグデータの利用というものが存在する。
ビッグデータは、日々現場で発生している様々なデータをそのままクラウドに乗せたものを意味する。
極端な言い方をすれば、ビッグデータを集めることで、何か付加価値を生み出すことができるのではないかと考える思考方法である。
【0152】
＜＜＜1.1.5 集計のしかたがわからない＞＞＞
ではビッグデータを集めて、ビル管理システムが適切に運用できているのかというと、現実はそうなっていない。数多くのデータをクラウドに乗せても、そのデータを活用できているとは言い難い。
その理由の一つには、クラウドに全データを集めればなんとかなると思っていたが、集めた後の処理がわからないということが挙げられる。
膨大な量のデータということもあるが、それ以前に、集められているデータをどう活用して、どう生かせばよいのかの知見が十分にないことが原因と考えられる。
これがＩＴとＯＴの分断と呼ばれるものである。
ではビッグデータを集めて、ビル管理システムが適切に運用できているのかというと、現実はそうなっていない。数多くのデータをクラウドに乗せても、そのデータを活用できているとは言い難い。
その理由の一つには、クラウドに全データを集めればなんとかなると思っていたが、集めた後の処理がわからないということが挙げられる。
膨大な量のデータということもあるが、それ以前に、集められているデータをどう活用して、どう生かせばよいのかの知見が十分にないことが原因と考えられる。
これがＩＴとＯＴの分断と呼ばれるものである。
【0153】
＜＜2 実現するための手段＞＞
＜＜＜2.1.1 概要＞＞＞
発明者等は、これまで数多くのプロジェクトに関わることで、ビル管理システムに求められる要件と、顧客が何を望んでいるのかという点を理解するに至った。
両者に求められるシステムを構築してきたことによって、無駄のない、最適なビル管理システムのあるべき姿が見えてきた。
このあるべきビル管理システムとは、簡単に言うと、「照明、空調、衛生、警報、エネルギー、施設管理等の全システムを、場所に依存することなく管理できること」に尽きる。
発明者等は、このあるべきビル管理システムを構築するにあたり、様々な制約が生じていることも理解した。その上で、解決すべき点に対して一つずつ対処した。
それは、以下に集約される。
（ａ）多地点にある監視対象のビル内システムを遠隔から監視できること。
（ｂ）専用の機器を使わないとビル管理ができない等の機器の制約がないこと。
（ｃ）監視対象の機器（照明、空調、衛生、警報、エネルギー、施設管理等）に制約がないこと。
（ｄ）表示のレスポンスが早いこと。
（ｅ）セキュリティが強固なこと。
（ｆ）ビル～クラウド間、クラウド～ビル管理システム間の通信障害が発生しても、大きな影響がないこと。
発明者等は、これらの制約を解決するために、各種の工夫を凝らして問題を解決してきた。
その内容について、以下に述べる。
＜＜＜2.1.1 概要＞＞＞
発明者等は、これまで数多くのプロジェクトに関わることで、ビル管理システムに求められる要件と、顧客が何を望んでいるのかという点を理解するに至った。
両者に求められるシステムを構築してきたことによって、無駄のない、最適なビル管理システムのあるべき姿が見えてきた。
このあるべきビル管理システムとは、簡単に言うと、「照明、空調、衛生、警報、エネルギー、施設管理等の全システムを、場所に依存することなく管理できること」に尽きる。
発明者等は、このあるべきビル管理システムを構築するにあたり、様々な制約が生じていることも理解した。その上で、解決すべき点に対して一つずつ対処した。
それは、以下に集約される。
（ａ）多地点にある監視対象のビル内システムを遠隔から監視できること。
（ｂ）専用の機器を使わないとビル管理ができない等の機器の制約がないこと。
（ｃ）監視対象の機器（照明、空調、衛生、警報、エネルギー、施設管理等）に制約がないこと。
（ｄ）表示のレスポンスが早いこと。
（ｅ）セキュリティが強固なこと。
（ｆ）ビル～クラウド間、クラウド～ビル管理システム間の通信障害が発生しても、大きな影響がないこと。
発明者等は、これらの制約を解決するために、各種の工夫を凝らして問題を解決してきた。
その内容について、以下に述べる。
【0154】
＜＜＜2.1.2 集約・分散処理＞＞＞
本実施形態に係るビル管理システムの特徴の１つは、多地点から監視することができること（多地点を監視できること）である。そして、異なる複数拠点を遠隔から見ることができる。また、遠隔から見る場所の制限を受けない。本実施形態の多地点のシステム（たくさんのビル）を遠隔から監視できるようにするためには、１つには、地点の特定が必要である。これはグローバル DNS（Domain Name System）によって特定するようにした。これにより、マイクロ・エッジ・デバイス６０において、対応付けられた設備機器にＩＰアドレスを割り振り、ＩＰアドレスを用いて識別できるようにした。
もう一つは、複数拠点におけるデータを統合して表示するシステムが必要である。
発明者等は、複数拠点における情報を統合して、一つのデータのように見せる仕組みを構築した。これがクラウドを使うことのメリットである。
サーバーが分散されていても、一つのサーバーのように見えるようにすることで、地点が分かれていても一つのサーバーの稼働として扱うことができる（Web サーバー方式）。
本実施形態に係るビル管理システムの特徴の１つは、多地点から監視することができること（多地点を監視できること）である。そして、異なる複数拠点を遠隔から見ることができる。また、遠隔から見る場所の制限を受けない。本実施形態の多地点のシステム（たくさんのビル）を遠隔から監視できるようにするためには、１つには、地点の特定が必要である。これはグローバル DNS（Domain Name System）によって特定するようにした。これにより、マイクロ・エッジ・デバイス６０において、対応付けられた設備機器にＩＰアドレスを割り振り、ＩＰアドレスを用いて識別できるようにした。
もう一つは、複数拠点におけるデータを統合して表示するシステムが必要である。
発明者等は、複数拠点における情報を統合して、一つのデータのように見せる仕組みを構築した。これがクラウドを使うことのメリットである。
サーバーが分散されていても、一つのサーバーのように見えるようにすることで、地点が分かれていても一つのサーバーの稼働として扱うことができる（Web サーバー方式）。
【0155】
＜＜＜2.1.3 ビル管理システムに専用機器を使わないといけない等の機器の制約がないこと＞＞＞
発明者等によるビル管理システムは、専用のアプリケーションや、ソフトウェアを使用することなく、パソコンやスマートフォン、タブレットのブラウザ上で稼働する。
つまり、Web サービスを利用してブラウザで表示できるようにすることで、これを実現している。
発明者等によるビル管理システムは、専用のアプリケーションや、ソフトウェアを使用することなく、パソコンやスマートフォン、タブレットのブラウザ上で稼働する。
つまり、Web サービスを利用してブラウザで表示できるようにすることで、これを実現している。
【0156】
＜＜＜2.1.4 監視対象の機器（照明～施設管理）に制約がないこと＞＞＞
発明者等によるビル管理システム（ビル管理システム１０）は、照明、空調、衛生、警報、エネルギー、施設管理等の各機器を監視できる。
これは、ビル内での統合監視を実現している機能を、クラウド利用時も同じ条件で使用できるようにしている。
発明者等によるビル管理システム（ビル管理システム１０）は、照明、空調、衛生、警報、エネルギー、施設管理等の各機器を監視できる。
これは、ビル内での統合監視を実現している機能を、クラウド利用時も同じ条件で使用できるようにしている。
【0157】
＜＜＜2.1.5 表示のレスポンスが早いこと＞＞＞
発明者等によるビル管理システム１０は、表示のレスポンスが早い。
どんな表示があるかというと、温度や湿度、CO2 濃度、エネルギー利用量の情報の表示である。これらを表示することができる。
クラウド利用に限らず、ビル内での監視結果の表示でも同じことであるが、どんな情報が見たいか、ビル管理システム１０の各種画面上で操作を行うと、そこからデータ処理がされて画面表示される。
表示内容は、表示する対象物と、時間単位や日、週、月、年等の対象期間の組み合わせによって、トレンド表示したり、積算表示させたりすることができる。
これらの表示を実現するために、２つの工夫を行っている。
１つは、表示するためのデータを前処理して蓄積していることである。
どういうことかというと、エネルギーで言えば、電気使用量が見たいわけであるが、その集計は、時間、日、週、月、年等と決まっている。
そうすると、使用機器と、時間、日、月で集計できるように準備しておけば、あとはそれらの組み合わせによって、いかようにも情報は表示できる。
つまり、収集される生データは生データとして存在はするが、データの集計をしやすく、利用しやすいように準備している。
もう１つは、REST（Representational State Transfer）、REST API（REST Application Programing Interface）のコマンド操作によって、例えば、何日の何時何分から何日の何時何分までの特定のデータだけを集計するように指定すれば、そのデータが集計されるようにしていることである。
ここでいうREST、REST APIはデータの受け渡しをするための定められた手続き文にしかすぎない。
ここで重要なのは、定められた手続き文を複数用意していることである。
RESTにより、何を要求指定したら、指定された種別の機器の、時間、日、週、月、年等の期間のデータを返すといった手続きが決められている。
この定めがあるため、オンプレミスであろうが、クラウドであろうが、対象によらず、コマンドによって同じ結果を得ることができるようになっている。
これらのことによって、画面操作をした際の画面表示も迅速に行われるようにしている。
もしこの処理がなければ、膨大なデータそのものの処理をしなくてはいけなくなり、処理に時間が多くかかってしまう。
このことは、データ発生源の場所で処理を行い、クラウドに情報を上げる際にも適用される。（後に述べるスタティックデータ）
その結果、生データ保有と、必要な情報を上位システム（この場合はクラウド）に送出することで、その後の利用時のレスポンスを早くしている。
発明者等によるビル管理システム１０は、表示のレスポンスが早い。
どんな表示があるかというと、温度や湿度、CO2 濃度、エネルギー利用量の情報の表示である。これらを表示することができる。
クラウド利用に限らず、ビル内での監視結果の表示でも同じことであるが、どんな情報が見たいか、ビル管理システム１０の各種画面上で操作を行うと、そこからデータ処理がされて画面表示される。
表示内容は、表示する対象物と、時間単位や日、週、月、年等の対象期間の組み合わせによって、トレンド表示したり、積算表示させたりすることができる。
これらの表示を実現するために、２つの工夫を行っている。
１つは、表示するためのデータを前処理して蓄積していることである。
どういうことかというと、エネルギーで言えば、電気使用量が見たいわけであるが、その集計は、時間、日、週、月、年等と決まっている。
そうすると、使用機器と、時間、日、月で集計できるように準備しておけば、あとはそれらの組み合わせによって、いかようにも情報は表示できる。
つまり、収集される生データは生データとして存在はするが、データの集計をしやすく、利用しやすいように準備している。
もう１つは、REST（Representational State Transfer）、REST API（REST Application Programing Interface）のコマンド操作によって、例えば、何日の何時何分から何日の何時何分までの特定のデータだけを集計するように指定すれば、そのデータが集計されるようにしていることである。
ここでいうREST、REST APIはデータの受け渡しをするための定められた手続き文にしかすぎない。
ここで重要なのは、定められた手続き文を複数用意していることである。
RESTにより、何を要求指定したら、指定された種別の機器の、時間、日、週、月、年等の期間のデータを返すといった手続きが決められている。
この定めがあるため、オンプレミスであろうが、クラウドであろうが、対象によらず、コマンドによって同じ結果を得ることができるようになっている。
これらのことによって、画面操作をした際の画面表示も迅速に行われるようにしている。
もしこの処理がなければ、膨大なデータそのものの処理をしなくてはいけなくなり、処理に時間が多くかかってしまう。
このことは、データ発生源の場所で処理を行い、クラウドに情報を上げる際にも適用される。（後に述べるスタティックデータ）
その結果、生データ保有と、必要な情報を上位システム（この場合はクラウド）に送出することで、その後の利用時のレスポンスを早くしている。
【0158】
＜＜＜2.1.6 何を上げて、何を上げないかの選別＞＞＞
重要なのは、時々刻々と発生する膨大な生データ（後に述べるダイナミックデータ）から、何を選別して上位階層に送出し、何は上位階層に上げないで、そのアプリケーション・エッジ・デバイス（オンプレミス機器）上に保存しておくかを決めることである。
発明者等は、アプリケーション・エッジ・デバイス（オンプレミス機器、アプリケーション・エッジ・デバイス６２）で保有するデータ、上位階層に上げるデータの選別を効果的に行い、表示速度を早くしている。
このことは、後で述べるクラウドを利用する場合の通信量、ＣＰＵ使用量、保存領域量の削減にも役立っている。
表示したいデータは、「ヒストリカルトレンドデータ」であるが、ビルで発生する全てのデータを集めてしまうと、膨大な量になってしまう。
実際に、そのデータを見たい時というのは、ある特定の警報が出た時、何かの問題が発生した時である。
その警報に対して、その前後の５分～１０分だけを見ればよい。この場合は、その警報を発したサイト（ビル）のアプリケーション・エッジ・デバイス６２にアクセスし、その時間帯のデータだけを表示する指示を送ると、そのデータを表示させることができる。
重要なのは、時々刻々と発生する膨大な生データ（後に述べるダイナミックデータ）から、何を選別して上位階層に送出し、何は上位階層に上げないで、そのアプリケーション・エッジ・デバイス（オンプレミス機器）上に保存しておくかを決めることである。
発明者等は、アプリケーション・エッジ・デバイス（オンプレミス機器、アプリケーション・エッジ・デバイス６２）で保有するデータ、上位階層に上げるデータの選別を効果的に行い、表示速度を早くしている。
このことは、後で述べるクラウドを利用する場合の通信量、ＣＰＵ使用量、保存領域量の削減にも役立っている。
表示したいデータは、「ヒストリカルトレンドデータ」であるが、ビルで発生する全てのデータを集めてしまうと、膨大な量になってしまう。
実際に、そのデータを見たい時というのは、ある特定の警報が出た時、何かの問題が発生した時である。
その警報に対して、その前後の５分～１０分だけを見ればよい。この場合は、その警報を発したサイト（ビル）のアプリケーション・エッジ・デバイス６２にアクセスし、その時間帯のデータだけを表示する指示を送ると、そのデータを表示させることができる。
【0159】
＜＜＜2.1.7 スタティックデータとダイナミックデータ＞＞＞
通常、クラウドのシステムをつくるときは、すべてのデータを上げる。
発明者等によるビル管理システム１０で、クラウドに上げるデータは、スタティックデータである。
スタティックデータは、警報、エネルギーやファシリティなどの情報をまとめたものである。この情報量は全体の一部、数％である。
クラウドに上げるスタティックデータは、頻度としては、５分から１０分毎程度でよい。
ただし、アラームは重要度が高いため、発生した場合には常に上げる。
ここで、アラームは、異常が発生した場合に発せられるが、異常が発生したか否かは、相当程度の値の変化があった場合である。相当程度の値の変化があったか否かは、"change of value"の値の変化があったか否か、及び、規定値より５％以上の数値変化があったか否かのうちの一方又は両方の基準を用いて判断される。ここでの判断を行うことができるのは、クラウドに繋がったエッジ・デバイス（ここではアプリケーション・エッジ・デバイス６２、統合・エッジ・デバイス６４、及び、エンタープライズ・エッジ・サーバー６６）である。また、"change of value"の値は、アラームの判定に用いられる値に変化があったかを示すフラグ（True or Falseのフラグ）である。
クラウドに上げる方法は２種類あり、一つはMQTT（Message Queueing Telemetry Transport）を使用する方法。もう一つはポーリングによる方法である。どちらを使用するかはクラウド側（例えば、後述する図５のクラウド７２の側）で定めている。
MQTTを使用する場合、アラームが発生すれば、エッジ・デバイス側から毎秒、MQTTに係るメッセージが発信される。ポーリングを使用する場合は、ポーリングに係る問い合わせが、インターネット回線６８を介したクラウド側との通信により、対応するエッジ・デバイス（ここではアプリケーション・エッジ・デバイス６２、統合・エッジ・デバイス６４、及び、エンタープライズ・エッジ・サーバー６６）に来た時点で、アラームに係る処理が行われる。
クラウドに上げるデータは、スタティックデータである。刻一刻と変化して発生するデータはダイナミックデータと呼ばれている。ダイナミックデータはクラウドには上げない。ダイナミックデータは、アプリケーション・エッジ・デバイス側で保持する。
通常、クラウドのシステムをつくるときは、すべてのデータを上げる。
発明者等によるビル管理システム１０で、クラウドに上げるデータは、スタティックデータである。
スタティックデータは、警報、エネルギーやファシリティなどの情報をまとめたものである。この情報量は全体の一部、数％である。
クラウドに上げるスタティックデータは、頻度としては、５分から１０分毎程度でよい。
ただし、アラームは重要度が高いため、発生した場合には常に上げる。
ここで、アラームは、異常が発生した場合に発せられるが、異常が発生したか否かは、相当程度の値の変化があった場合である。相当程度の値の変化があったか否かは、"change of value"の値の変化があったか否か、及び、規定値より５％以上の数値変化があったか否かのうちの一方又は両方の基準を用いて判断される。ここでの判断を行うことができるのは、クラウドに繋がったエッジ・デバイス（ここではアプリケーション・エッジ・デバイス６２、統合・エッジ・デバイス６４、及び、エンタープライズ・エッジ・サーバー６６）である。また、"change of value"の値は、アラームの判定に用いられる値に変化があったかを示すフラグ（True or Falseのフラグ）である。
クラウドに上げる方法は２種類あり、一つはMQTT（Message Queueing Telemetry Transport）を使用する方法。もう一つはポーリングによる方法である。どちらを使用するかはクラウド側（例えば、後述する図５のクラウド７２の側）で定めている。
MQTTを使用する場合、アラームが発生すれば、エッジ・デバイス側から毎秒、MQTTに係るメッセージが発信される。ポーリングを使用する場合は、ポーリングに係る問い合わせが、インターネット回線６８を介したクラウド側との通信により、対応するエッジ・デバイス（ここではアプリケーション・エッジ・デバイス６２、統合・エッジ・デバイス６４、及び、エンタープライズ・エッジ・サーバー６６）に来た時点で、アラームに係る処理が行われる。
クラウドに上げるデータは、スタティックデータである。刻一刻と変化して発生するデータはダイナミックデータと呼ばれている。ダイナミックデータはクラウドには上げない。ダイナミックデータは、アプリケーション・エッジ・デバイス側で保持する。
【0160】
＜＜＜2.1.8 セキュリティ＞＞＞
クラウドを利用する場合の課題として、セキュリティの問題がある。
一般的にはクラウドを利用する場合はインターネット回線を用いる。インターネット回線の利用時において、一般的なインターネット回線網を使用すると、ハッキング等の問題が生じる。
発明者等はこの問題に対処するため、ＶＰＮ（Virtual Private Network）網を使用する。これによって、インターネット網における外部組織からの攻撃を避け、安全な通信を行うことが可能になる。
クラウドを利用する場合の課題として、セキュリティの問題がある。
一般的にはクラウドを利用する場合はインターネット回線を用いる。インターネット回線の利用時において、一般的なインターネット回線網を使用すると、ハッキング等の問題が生じる。
発明者等はこの問題に対処するため、ＶＰＮ（Virtual Private Network）網を使用する。これによって、インターネット網における外部組織からの攻撃を避け、安全な通信を行うことが可能になる。
【0161】
＜＜＜2.1.9 ビル～クラウド間、クラウド～ビル管理システム間の通信障害が発生しても、大きな影響がない＞＞＞
オンプレミスで利用する場合とクラウドをする場合の一番大きな違いは、インターネット網の通信回線を使用するかどうかである。
社内のビル内でのビル管理システムであれば、インターネット回線網に障害が発生しても何も問題はないが、クラウド利用であればそうはいかない。
アマゾン（登録商標）やマイクロソフト（登録商標）、グーグル（登録商標）といった巨大プラットフォーマーであっても時々、通信回線の異常が発生し、クラウドが利用できないことが生じる。クラウドを利用したビル管理システムであれば同様に、影響を受ける。
ただし、インターネット回線網に障害が発生した場合であっても、刻一刻と発生するデータを止めることはないし、そのデータが欠落して表示できなくなるということがないよう、工夫をしている。
つまり、回線異常時はデータ通信ができないが、データ通信が復旧すれば、未送信のデータをクラウド上に自動的に上げ、データ監視の連続性を担保する。
オンプレミスで利用する場合とクラウドをする場合の一番大きな違いは、インターネット網の通信回線を使用するかどうかである。
社内のビル内でのビル管理システムであれば、インターネット回線網に障害が発生しても何も問題はないが、クラウド利用であればそうはいかない。
アマゾン（登録商標）やマイクロソフト（登録商標）、グーグル（登録商標）といった巨大プラットフォーマーであっても時々、通信回線の異常が発生し、クラウドが利用できないことが生じる。クラウドを利用したビル管理システムであれば同様に、影響を受ける。
ただし、インターネット回線網に障害が発生した場合であっても、刻一刻と発生するデータを止めることはないし、そのデータが欠落して表示できなくなるということがないよう、工夫をしている。
つまり、回線異常時はデータ通信ができないが、データ通信が復旧すれば、未送信のデータをクラウド上に自動的に上げ、データ監視の連続性を担保する。
【0162】
＜＜＜2.1.10 主な技術＞＞＞
発明者等のビル管理システムにおけるキモ（肝）の部分は、何をスタティックデータとしてクラウドに上げ、何をダイナミックデータとしてアプリケーション・エッジ・デバイス６２に残しておくかである。この選択がまず第一に重要である。
その次に、スタティックデータとしてクラウドに上げているデータの内容そのものに工夫がされている。
単に、ダイナミックデータの中から、クラウドに上げるデータを抽出してそのデータをスタティックデータとしてクラウドに上げているのであれば、クラウド側での加工処理が発生し、それが処理遅延の原因と、課金額の増額につながる。
何をクラウドに上げれば、全体のパフォーマンスが最大化するかをわかり抜いた上での工夫が本実施形態のビル管理システム１０には組み込まれている。
発明者等のビル管理システムにおけるキモ（肝）の部分は、何をスタティックデータとしてクラウドに上げ、何をダイナミックデータとしてアプリケーション・エッジ・デバイス６２に残しておくかである。この選択がまず第一に重要である。
その次に、スタティックデータとしてクラウドに上げているデータの内容そのものに工夫がされている。
単に、ダイナミックデータの中から、クラウドに上げるデータを抽出してそのデータをスタティックデータとしてクラウドに上げているのであれば、クラウド側での加工処理が発生し、それが処理遅延の原因と、課金額の増額につながる。
何をクラウドに上げれば、全体のパフォーマンスが最大化するかをわかり抜いた上での工夫が本実施形態のビル管理システム１０には組み込まれている。
【0163】
＜＜3 効果＞＞
＜＜＜3.1.1 画面表示のレスポンス向上＞＞＞
以上のような工夫をこらすことで、本実施形態のビル管理システム１０は以下のような効果を奏する。
まず一番大きいのは、画面表示のレスポンスが速いことである。
クラウドシステムである以上、距離が離れており、通信回線の帯域等の影響を受ける。
そのため、何の処理も施さないで、クラウドにビッグデータを乗せ、機器指定ならびに期間指定をして画面表示させると、それなりに多大な時間がかかる。
さらに、一度表示させる指示をしたあと、すぐに条件変更を行うと、その画面変更のための処理が次に発生し、処理時間がさらにかかり、結果として画面表示に遅れが生じる。
つまり、変更処理をするたびに、何秒もの時間、待たされることになりかねない。
本実施形態のビル管理システム１０は、画面の表示変更が軽快に動作するという点で優れている。
＜＜＜3.1.1 画面表示のレスポンス向上＞＞＞
以上のような工夫をこらすことで、本実施形態のビル管理システム１０は以下のような効果を奏する。
まず一番大きいのは、画面表示のレスポンスが速いことである。
クラウドシステムである以上、距離が離れており、通信回線の帯域等の影響を受ける。
そのため、何の処理も施さないで、クラウドにビッグデータを乗せ、機器指定ならびに期間指定をして画面表示させると、それなりに多大な時間がかかる。
さらに、一度表示させる指示をしたあと、すぐに条件変更を行うと、その画面変更のための処理が次に発生し、処理時間がさらにかかり、結果として画面表示に遅れが生じる。
つまり、変更処理をするたびに、何秒もの時間、待たされることになりかねない。
本実施形態のビル管理システム１０は、画面の表示変更が軽快に動作するという点で優れている。
【0164】
＜＜＜3.1.2 クラウド利用料の低減＞＞＞
すでに述べたように、刻一刻と発生する生データをすべてクラウドに上げるとどうなるかというと、相当量のデータとなる。
これがビル１棟であっても大きいが、複数、十、百、数百棟ものビル群の情報を上げると膨大な量のデータとなる。
クラウドの利用には、クラウドとの接続する通信回線費用のほか、クラウド自身との通信量、処理のためのＣＰＵ使用量、保存領域使用量に応じて課金されるのが通常である。
ビッグデータをそのまま処理しようとすると、莫大な金額が発生することが想定される。しかし、本実施形態のビル管理システム１０によれば、送出量そのものが全体の数％であることを考えれば、利用料金もそれに応じた少ないものとすることができる。データ量を抑制することで、クラウド利用量そのものを削減することにより、ＣＰＵ使用量、通信量、データ保存量等を削減し、クラウド利用料金そのものを削減できる。
すでに述べたように、刻一刻と発生する生データをすべてクラウドに上げるとどうなるかというと、相当量のデータとなる。
これがビル１棟であっても大きいが、複数、十、百、数百棟ものビル群の情報を上げると膨大な量のデータとなる。
クラウドの利用には、クラウドとの接続する通信回線費用のほか、クラウド自身との通信量、処理のためのＣＰＵ使用量、保存領域使用量に応じて課金されるのが通常である。
ビッグデータをそのまま処理しようとすると、莫大な金額が発生することが想定される。しかし、本実施形態のビル管理システム１０によれば、送出量そのものが全体の数％であることを考えれば、利用料金もそれに応じた少ないものとすることができる。データ量を抑制することで、クラウド利用量そのものを削減することにより、ＣＰＵ使用量、通信量、データ保存量等を削減し、クラウド利用料金そのものを削減できる。
【0165】
＜＜＜3.1.3 セキュリティの向上＞＞＞
インターネット回線のパブリック網ではなく、ＶＰＮの使用により、セキュリティの問題を解消できる。
インターネット回線のパブリック網ではなく、ＶＰＮの使用により、セキュリティの問題を解消できる。
【0166】
＜＜＜3.1.4 監視人の低減＞＞＞
本実施形態の、クラウド利用によるビル管理システム１０によれば、ビルの監視ルームに人を縛りつけておく必要がなくなる。この効果は意外と大きい。
つまり、各ビルに１名ずつの管理人を配置している企業があるとする。その企業が複数棟のビルを所有している場合、ビル毎に管理人を配置していることになるが、本実施形態のビル管理システム１０によれば、ビル毎に管理人を配置する必要がなくなる。特にビルを数百、数千棟保有している企業にとっては、この削減効果は大きいものになる。
本実施形態の、クラウド利用によるビル管理システム１０によれば、ビルの監視ルームに人を縛りつけておく必要がなくなる。この効果は意外と大きい。
つまり、各ビルに１名ずつの管理人を配置している企業があるとする。その企業が複数棟のビルを所有している場合、ビル毎に管理人を配置していることになるが、本実施形態のビル管理システム１０によれば、ビル毎に管理人を配置する必要がなくなる。特にビルを数百、数千棟保有している企業にとっては、この削減効果は大きいものになる。
【0167】
＜＜＜3.1.5 監視ルームの削減＞＞＞
すでに監視ルームがあるビルの場合は、管理人の削減でよいが、新しくビルを建てる場合、監視ルームそのものが不要になる。
監視ルームそのものの撤去、監視ルームへの独自機器の設置削減が可能である。
すでに監視ルームがあるビルの場合は、管理人の削減でよいが、新しくビルを建てる場合、監視ルームそのものが不要になる。
監視ルームそのものの撤去、監視ルームへの独自機器の設置削減が可能である。
【0168】
＜＜＜3.1.6 専用の監視装置に依存しない＞＞＞
本実施形態に係るビル管理システム１０は、ブラウザ上で動作するので、専用機器を使わなくても済む。専用のアプリやソフトウェアの制約にとらわれず、ブラウザで見ることができる。
これは、専用アプリケーション開発の必要性がなくなることのほか、ソフトウェアの修正・機能追加等にも柔軟に対応ができるという発明の効果に繋がる。
クラウド側のソフトウェアが軽くなるというメーカー側の都合だけでなく、ビル管理システムを利用するユーザー側にとっても、ソフトウェアの機能改善のバージョンアップのたびに、アプリをダウンロードする必要がない。
本実施形態に係るビル管理システム１０は、ブラウザ上で動作するので、専用機器を使わなくても済む。専用のアプリやソフトウェアの制約にとらわれず、ブラウザで見ることができる。
これは、専用アプリケーション開発の必要性がなくなることのほか、ソフトウェアの修正・機能追加等にも柔軟に対応ができるという発明の効果に繋がる。
クラウド側のソフトウェアが軽くなるというメーカー側の都合だけでなく、ビル管理システムを利用するユーザー側にとっても、ソフトウェアの機能改善のバージョンアップのたびに、アプリをダウンロードする必要がない。
【0169】
＜＜＜3.1.7 多拠点を遠隔で監視できる＞＞＞
多拠点のビルを監視する場合においても、スタティックとダイナミックのデータを分けたのは効果的である。
従来のシステムでは、通信回線が切れてしまうと、ビルの監視のみならず、制御がまったくできなくなっていた。
本実施形態に係るビル管理システム１０は、この課題を克服するために、スタティックデータとダイナミックデータの利用方法を分けることによって、たとえ回線が異常により、クラウド間とビル間の通信が途絶えたとしても、ビル管理システム１０の稼働にはまったく影響が出ないようになっている。図５は、通信障害発生時の状況の一例を概略的に示している。図中の「×」印は、通信障害が発生した回線を示している。例えば、クラウド７２とビル２（符号７６を付す）との間の回線異常発生時には、スタティックデータがクラウドに上がって来なくなるが、必要に応じて、ダイアルアップルーター８０、８２を経由してＶＰＮ網での接続が可能となる。回線が復旧すると、通信が再開され、停止していた時間帯のデータを含めた、データのアップロードが行われる。
多拠点のビルを監視する場合においても、スタティックとダイナミックのデータを分けたのは効果的である。
従来のシステムでは、通信回線が切れてしまうと、ビルの監視のみならず、制御がまったくできなくなっていた。
本実施形態に係るビル管理システム１０は、この課題を克服するために、スタティックデータとダイナミックデータの利用方法を分けることによって、たとえ回線が異常により、クラウド間とビル間の通信が途絶えたとしても、ビル管理システム１０の稼働にはまったく影響が出ないようになっている。図５は、通信障害発生時の状況の一例を概略的に示している。図中の「×」印は、通信障害が発生した回線を示している。例えば、クラウド７２とビル２（符号７６を付す）との間の回線異常発生時には、スタティックデータがクラウドに上がって来なくなるが、必要に応じて、ダイアルアップルーター８０、８２を経由してＶＰＮ網での接続が可能となる。回線が復旧すると、通信が再開され、停止していた時間帯のデータを含めた、データのアップロードが行われる。
【0170】
＜＜4 補足＞＞
＜＜＜4.1.1 分析の事例＞＞＞
例えば、エネルギーに関して、何かの警報が発生して、エネルギー使用量が増えていたとする。
すると、エネルギー使用量の増加に気付いた者は、「どうして、エネルギーをこんなに使っているのだろうか？」と考え、その原因を調べることになる。
そのためには、ある特定の時間帯を見て、その時間帯にだけ、何が起きたのかを調べる。
ある程度、知見のある者であれば、「もしかしたらボイラーがおかしかったのではないか」と推定して、ボイラーについて、この時間帯にどのように動いたのかを見る。
たとえば、その時間の温度がどうなっているかを見る。
本来であれば、冬場には 40 度や 50 度の温水を送っているべきなのに、たまたまそのときだけ 20 度であったということがわかったりする。
この原因によって、エネルギーの効率が悪かったことが判明する。
また、メンテナンスの観点から、「この時間帯には、こんなことが起きているから、ボイラーを調べなさい」とわかる。
このように、過去の履歴データは、必要になる時だけ見にいけばよく、通常、問題が発生していない時には見る必要がない。
特に、ボイラーや機械的なものに関しては、秒単位でデータを集めるため、膨大なデータ量になってしまう。
それに対して、エネルギーのデータは、例えば10 分に 1 度、取ればよい。
10 分に１度のデータでよいものと、１秒に１回データを取るものでは、量は 600 倍違う。これが１つのビル内でも複数箇所存在する。
よって、刻一刻と変わるダイナミックデータは、アプリケーション・エッジ・デバイス側に置き、必要な場合にのみ見にいけばよいようにし、クラウドには乗せないようにしている。
＜＜＜4.1.1 分析の事例＞＞＞
例えば、エネルギーに関して、何かの警報が発生して、エネルギー使用量が増えていたとする。
すると、エネルギー使用量の増加に気付いた者は、「どうして、エネルギーをこんなに使っているのだろうか？」と考え、その原因を調べることになる。
そのためには、ある特定の時間帯を見て、その時間帯にだけ、何が起きたのかを調べる。
ある程度、知見のある者であれば、「もしかしたらボイラーがおかしかったのではないか」と推定して、ボイラーについて、この時間帯にどのように動いたのかを見る。
たとえば、その時間の温度がどうなっているかを見る。
本来であれば、冬場には 40 度や 50 度の温水を送っているべきなのに、たまたまそのときだけ 20 度であったということがわかったりする。
この原因によって、エネルギーの効率が悪かったことが判明する。
また、メンテナンスの観点から、「この時間帯には、こんなことが起きているから、ボイラーを調べなさい」とわかる。
このように、過去の履歴データは、必要になる時だけ見にいけばよく、通常、問題が発生していない時には見る必要がない。
特に、ボイラーや機械的なものに関しては、秒単位でデータを集めるため、膨大なデータ量になってしまう。
それに対して、エネルギーのデータは、例えば10 分に 1 度、取ればよい。
10 分に１度のデータでよいものと、１秒に１回データを取るものでは、量は 600 倍違う。これが１つのビル内でも複数箇所存在する。
よって、刻一刻と変わるダイナミックデータは、アプリケーション・エッジ・デバイス側に置き、必要な場合にのみ見にいけばよいようにし、クラウドには乗せないようにしている。
【0171】
＜＜＜4.1.2 エンジニアリングの仕事量の削減＞＞＞
以上、述べてきたように、クラウド利用の観点から、「必要なスタティックデータをクラウドに乗せ」、「利用頻度の少ないダイナミックデータはオンプレミス側に置く」というのは当たり前のように思うかもしれない。
ところが、現実にはこのようになっていない。
そのため、現場では何が起きているかというと、「どのようにしてクラウドにデータを乗せるか」という議論から始まる。
空調や照明、衛生、警報、エネルギー、施設管理等の従来型のビル管理を行っている企業がクラウドにデータを乗せようとすると、各機器を担当する会社から技術者やプロジェクトマネージャー等を集めて、クラウドに乗せるためのデータについて、フォーマットをどうするか、乗せ方をどうするか等の取り決めを行うことになる。
実際、あるプロジェクトで、20 万点のデータをクラウドに乗せたいという依頼があり、サポートしたところ、クラウド上に A 社管理の場所、B 社管理の場所・・・のように、会社・機器ごとの場所を用意し、そこにデータを保管することにした。そして、それらのデータをどのように統合していくのかというデータベースを作った。
そうしてデータは集まったものの、今度はそのデータをどう活用すればよいかということになる。
こうした取り決めの議論が延々と続いて、クラウドのシステムが出来上がる。
世の中ではオープン化と言われ、どのようなベンダーの機器でも接続できることが期待されているが、現実には実現しておらず、発明者等は前述したような本実施形態に係るビル管理システム１０によってこの問題を解決するための方法を提供する。
以上、述べてきたように、クラウド利用の観点から、「必要なスタティックデータをクラウドに乗せ」、「利用頻度の少ないダイナミックデータはオンプレミス側に置く」というのは当たり前のように思うかもしれない。
ところが、現実にはこのようになっていない。
そのため、現場では何が起きているかというと、「どのようにしてクラウドにデータを乗せるか」という議論から始まる。
空調や照明、衛生、警報、エネルギー、施設管理等の従来型のビル管理を行っている企業がクラウドにデータを乗せようとすると、各機器を担当する会社から技術者やプロジェクトマネージャー等を集めて、クラウドに乗せるためのデータについて、フォーマットをどうするか、乗せ方をどうするか等の取り決めを行うことになる。
実際、あるプロジェクトで、20 万点のデータをクラウドに乗せたいという依頼があり、サポートしたところ、クラウド上に A 社管理の場所、B 社管理の場所・・・のように、会社・機器ごとの場所を用意し、そこにデータを保管することにした。そして、それらのデータをどのように統合していくのかというデータベースを作った。
そうしてデータは集まったものの、今度はそのデータをどう活用すればよいかということになる。
こうした取り決めの議論が延々と続いて、クラウドのシステムが出来上がる。
世の中ではオープン化と言われ、どのようなベンダーの機器でも接続できることが期待されているが、現実には実現しておらず、発明者等は前述したような本実施形態に係るビル管理システム１０によってこの問題を解決するための方法を提供する。
【0172】
なお、本実施形態に係るビル管理システム１０によって行われるビル管理の方法は、ビル管理方法として捉えることが可能である。また、ビル管理システム１０により実行されるコンピュータプログラムは、ビル管理プログラムとして捉えることが可能である。さらに、ビル管理システム１０は、ビル管理装置として捉えることが可能である。
【0173】
＜実施形態から抽出可能な発明＞
これまでに説明したような実施形態から、以下のような発明を抽出することが可能である。
（１）複数の管理項目（空調、照明、衛生、警報、エネルギーなど）のいずれかに分類される複数種類の設備機器（エアコン、照明機器、扉、無線式センサー装置３０等のセンサー類、スイッチ類、その他の電気機器類など）と、
複数種類の検出項目（温度、湿度、照度、加速度、コンタクトなど）の検出が可能なセンサー装置（無線式センサー装置３０など）と、
昇順に上位層となる第１階層装置（マイクロ・エッジ・デバイス６０など）、第２階層装置（アプリケーション・エッジ・デバイス６２など）、第３階層装置（統合・エッジ・デバイス６４など）、第４階層装置（エンタープライズ・エッジ・サーバー６６など）のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
少なくとも１つの前記管理項目を１つの項目系として複数の項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）を定めることが可能であり、
複数の前記項目系が、少なくとも、空調系、照明系、警報系、及び、エネルギー系を含む、ビル管理システムであって、
前記センサー装置が複数備えられ、
複数の前記センサー装置が、
少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力可能であり、
複数の前記項目系に跨るセンサー装置群を構成し、
前記第１階層装置で共通仕様の通信規格に基づき統一化された情報のうち、予め指定された情報（スタティックデータなど）のみが、クラウドを介して前記第２階層装置へ送出される、ビル管理システム。
（２）前記指定された情報はアラームの情報を含む、上記（１）に記載のビル管理システム。
（３）前記第１階層装置が、前記設備機器に対しＩＰアドレスの割り振りを行う、上記（１）に記載のビル管理システム。
（４）グローバルＤＮＳにより多地点を特定する、請求項１に記載のビル管理システム。
（５）前記第２階層装置が、
前記第１階層装置からの前記共通通信規格のデジタル情報を受信し、
複数の前記センサー装置から収集したデジタル情報に基づき、複数の前記センサー装置から収集した情報をデータベース化する、上記（１）～（４）に記載のビル管理システム。
（６）前記第２階層装置は、前記第３階層装置が備えられていない場合には、
ユーザーの端末装置（携帯情報端末２２、２４など）から、少なくとも、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択し、
前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（５）に記載のビル管理システム。
（７）前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置は、前記第４階層装置が備えられていない場合には、
ユーザーの端末装置（携帯情報端末２２、２４など）から、少なくとも、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記第２階層装置に対し、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択して送出するよう要求し、
前記第２階層装置から前記共通通信規格により、前記公衆無線通信回線を介して送出された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（５）に記載のビル管理システム。
（８）前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置が複数備えられている場合には前記第４階層装置が備えられ、
前記第４階層装置は、
ユーザーの端末装置（携帯情報端末２２、２４など）から、少なくとも、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記第３階層装置を介して、前記第２階層装置に、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択して送信するよう要求し、
前記第３階層装置は、
前記第２階層装置から、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して送出された前記処理前情報を、前記第４階層装置に中継し、
前記第４階層装置は、
前記第３階層装置により中継された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（５）に記載のビル管理システム。
（９）前記指定された情報が、予め所定のコマンド操作により選択される、上記（６）に記載のビル管理システム。
（１０）上記（１）～（１０）のビル管理システムで行われるビル管理方法。
（１１）上記（１）～（１０）の「ビル管理システム」を「ビル管理装置」に置き換えた発明。
これまでに説明したような実施形態から、以下のような発明を抽出することが可能である。
（１）複数の管理項目（空調、照明、衛生、警報、エネルギーなど）のいずれかに分類される複数種類の設備機器（エアコン、照明機器、扉、無線式センサー装置３０等のセンサー類、スイッチ類、その他の電気機器類など）と、
複数種類の検出項目（温度、湿度、照度、加速度、コンタクトなど）の検出が可能なセンサー装置（無線式センサー装置３０など）と、
昇順に上位層となる第１階層装置（マイクロ・エッジ・デバイス６０など）、第２階層装置（アプリケーション・エッジ・デバイス６２など）、第３階層装置（統合・エッジ・デバイス６４など）、第４階層装置（エンタープライズ・エッジ・サーバー６６など）のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
少なくとも１つの前記管理項目を１つの項目系として複数の項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）を定めることが可能であり、
複数の前記項目系が、少なくとも、空調系、照明系、警報系、及び、エネルギー系を含む、ビル管理システムであって、
前記センサー装置が複数備えられ、
複数の前記センサー装置が、
少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力可能であり、
複数の前記項目系に跨るセンサー装置群を構成し、
前記第１階層装置で共通仕様の通信規格に基づき統一化された情報のうち、予め指定された情報（スタティックデータなど）のみが、クラウドを介して前記第２階層装置へ送出される、ビル管理システム。
（２）前記指定された情報はアラームの情報を含む、上記（１）に記載のビル管理システム。
（３）前記第１階層装置が、前記設備機器に対しＩＰアドレスの割り振りを行う、上記（１）に記載のビル管理システム。
（４）グローバルＤＮＳにより多地点を特定する、請求項１に記載のビル管理システム。
（５）前記第２階層装置が、
前記第１階層装置からの前記共通通信規格のデジタル情報を受信し、
複数の前記センサー装置から収集したデジタル情報に基づき、複数の前記センサー装置から収集した情報をデータベース化する、上記（１）～（４）に記載のビル管理システム。
（６）前記第２階層装置は、前記第３階層装置が備えられていない場合には、
ユーザーの端末装置（携帯情報端末２２、２４など）から、少なくとも、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択し、
前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（５）に記載のビル管理システム。
（７）前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置は、前記第４階層装置が備えられていない場合には、
ユーザーの端末装置（携帯情報端末２２、２４など）から、少なくとも、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記第２階層装置に対し、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択して送出するよう要求し、
前記第２階層装置から前記共通通信規格により、前記公衆無線通信回線を介して送出された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（５）に記載のビル管理システム。
（８）前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置が複数備えられている場合には前記第４階層装置が備えられ、
前記第４階層装置は、
ユーザーの端末装置（携帯情報端末２２、２４など）から、少なくとも、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記第３階層装置を介して、前記第２階層装置に、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択して送信するよう要求し、
前記第３階層装置は、
前記第２階層装置から、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して送出された前記処理前情報を、前記第４階層装置に中継し、
前記第４階層装置は、
前記第３階層装置により中継された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（５）に記載のビル管理システム。
（９）前記指定された情報が、予め所定のコマンド操作により選択される、上記（６）に記載のビル管理システム。
（１０）上記（１）～（１０）のビル管理システムで行われるビル管理方法。
（１１）上記（１）～（１０）の「ビル管理システム」を「ビル管理装置」に置き換えた発明。
【0174】
＜その他＞
当業者は、本発明の精神及び範囲から外れることなく、様々な変更、置換、及び修正をこれに加えることが可能であることを理解されたい。
当業者は、本発明の精神及び範囲から外れることなく、様々な変更、置換、及び修正をこれに加えることが可能であることを理解されたい。
【符号の説明】
【0175】
１０ ：ビル管理システム
１２ ：空調関連系
１４ ：コンセント系
１６ ：水回り系
１８ ：警報系
２０ ：エネルギー系
２２、２４ ：携帯情報端末
３０ ：無線式センサー装置
６０ ：マイクロ・エッジ・デバイス
６０Ａ ：デバイス群
６２ ：アプリケーション・エッジ・デバイス
６４ ：統合・エッジ・デバイス
６６ ：エンタープライズ・エッジ・サーバー
１２ ：空調関連系
１４ ：コンセント系
１６ ：水回り系
１８ ：警報系
２０ ：エネルギー系
２２、２４ ：携帯情報端末
３０ ：無線式センサー装置
６０ ：マイクロ・エッジ・デバイス
６０Ａ ：デバイス群
６２ ：アプリケーション・エッジ・デバイス
６４ ：統合・エッジ・デバイス
６６ ：エンタープライズ・エッジ・サーバー
【図1】
【図2】
【図3】
【図4】
【図5】