JP7788108B2 - ビル管理システム - Google Patents
ビル管理システムInfo
- Publication number
- JP7788108B2 JP7788108B2 JP2023040742A JP2023040742A JP7788108B2 JP 7788108 B2 JP7788108 B2 JP 7788108B2 JP 2023040742 A JP2023040742 A JP 2023040742A JP 2023040742 A JP2023040742 A JP 2023040742A JP 7788108 B2 JP7788108 B2 JP 7788108B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- tier
- building management
- management system
- building
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Remote Monitoring And Control Of Power-Distribution Networks (AREA)
- Selective Calling Equipment (AREA)
- Telephonic Communication Services (AREA)
Description
本発明は、例えば、情報通信網を介してビル管理を行うビル管理システムに関する。
例えば、後掲の特許文献１には、ネットワーク分散型のビル管理システムに係る発明が開示されている。特許文献１に開示された発明においては、段落００１７や図１に記載されているように、パソコン等の通信端末機（１）からインターネット等の既存のネットワーク（Ｌ１）やビルディングサーバ（２）を介して、ビル内設備機器が監視される。
ところで、ビルの改修の際には、既存の設備機器（センサー類やスイッチ類を含む）を新しいものに変更する作業が発生する。特許文献１に開示されたような従来のネットワークシステムや、従来のビル管理システムでは、共通の通信規格に対応するよう設計されている設備機器を管理することはできても、それ以上の多くの種類の設備機器に対応することまではできていなかった。例えば、特許文献１に開示された発明では、メーカー毎の設備制御機器の選定が必要である（段落０００９）。そして、近年におけるインテリジェントビルの管理や、多棟管理を想定した場合には、監視点数が膨大になるため、従来の技術によったのでは、総合的なビル管理には対応することができなかった。
本発明の目的とするところは、より効果的にビル管理を行うことができるビル管理システムを提供することにある。
上記目的を達成するために本発明に係るビル管理システムは、
複数の管理項目のいずれかに分類される複数種類の設備機器と、
複数種類の検出項目の検出が可能なセンサー装置と、
昇順に上位層となる第１階層装置、第２階層装置、第３階層装置、第４階層装置のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
少なくとも１つの前記管理項目を１つの項目系として複数の項目系を定めることが可能であり、
複数の前記項目系が、少なくとも、空調系、照明系、警報系、及び、エネルギー系を含む、ビル管理システムであって、
前記センサー装置が複数備えられ、
複数の前記センサー装置が、
少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力可能であり、
複数の前記項目系に跨るセンサー装置群を構成し、
前記第１階層装置で共通仕様の通信規格に基づき統一化された情報が前記第２階層装置へ送出され、
前記第２階層装置が、
所定のアプリケーションソフトであるプロダクティビティ・ツールを用いて、予め定められた構造体として、前記第１階層装置からの前記情報をデータベース化することが可能である。
複数の管理項目のいずれかに分類される複数種類の設備機器と、
複数種類の検出項目の検出が可能なセンサー装置と、
昇順に上位層となる第１階層装置、第２階層装置、第３階層装置、第４階層装置のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
少なくとも１つの前記管理項目を１つの項目系として複数の項目系を定めることが可能であり、
複数の前記項目系が、少なくとも、空調系、照明系、警報系、及び、エネルギー系を含む、ビル管理システムであって、
前記センサー装置が複数備えられ、
複数の前記センサー装置が、
少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力可能であり、
複数の前記項目系に跨るセンサー装置群を構成し、
前記第１階層装置で共通仕様の通信規格に基づき統一化された情報が前記第２階層装置へ送出され、
前記第２階層装置が、
所定のアプリケーションソフトであるプロダクティビティ・ツールを用いて、予め定められた構造体として、前記第１階層装置からの前記情報をデータベース化することが可能である。
上記発明によれば、より効果的にビル管理を行うことができるビル管理システムを提供することができる。
＜実施形態に係るビル管理システムの概要＞
以下、本発明の実施形態に係るビル管理システムについて説明する。本実施形態のビル管理システムは、空調（エアコン）、照明、衛生、警報（セキュリティー、アラーム）、エネルギー等といった各種の管理項目を、ビル内やビル外、及び、遠隔地から自在に、一元管理したり、分散制御したりすることを可能としている。
以下、本発明の実施形態に係るビル管理システムについて説明する。本実施形態のビル管理システムは、空調（エアコン）、照明、衛生、警報（セキュリティー、アラーム）、エネルギー等といった各種の管理項目を、ビル内やビル外、及び、遠隔地から自在に、一元管理したり、分散制御したりすることを可能としている。
本実施形態のビル管理システムは、ビル内の各設備機器を含んでいる。設備機器には、例えば、エアコン、照明機器、扉等のように様々な設備機器が含まれている。また、設備機器には、部屋内の温度を検出する温度センサー、湿度を検出する湿度センサー、照明機器の照度を検出する照度センサー、扉の開閉を検出するコンタクトセンサーなど（センサー類）も含まれる。
また、設備機器には、エアコンの操作パネルやリモコン（リモートコントローラ）、照明の操作パネルやリモコン、壁に設置された各種のスイッチなど（スイッチ類）も含まれる。さらに、設備機器には、電力の使用状況の把握に係る変流器、電力量モニタ、サーキットプロテクタ、パワー・サプライ・ユニット、コンパクト・ゲートウェイなど（その他の電気機器類）も含めることが可能である。
これらは設備機器の一例であり、一般にビル管理に用いられるその他の機器も、本実施形態の設備機器に含めることが可能である。
本実施形態のビル管理システムでは、各設備機器により収集された情報に基づき、ビルの設備機器の監視を行うビル管理者や、各設備機器の一般利用者（フロアや区画を利用するテナントの社員など）が、自ら所有する情報携帯端末（スマートフォンやタブレットなど）から、設備機器を選択して指示（コマンド）を入力する、といったことを可能としている。
さらに、本実施形態のビル管理システムにおいては、ビル管理のためのソフトウェア（アプリケーションソフトを含む）の種類が、システムの統合により、最小限に止められている。また、本実施形態のビル管理システムにおいては、全体の監視を可能とする監視システムが標準装備されている。
当たり前のことのように思えるかもしれないが、従来のビル管理システムでは、メーカー（製造業者）やベンダー（販売業者）毎の各種情報の仕様（信号規格、通信規格、ＯＳ（オペレーティング・システム）、プログラミング言語など）の違いに関わらず、横断的に（横方向に跨って）情報を収集して、ビル管理者や、設備機器の一般利用者等に対し、統合されたサービスを提供することは難しかった。本実施形態のビル管理システムは、このことを可能とした。
より具体的には、本実施形態のビル管理システムは、「ビル内監視ルーム（中央監視ルーム）からの解放」を図っている。これは、従来、ビル内に設置されていた中央監視ルームを廃止したり、中央監視に係る人員を一人等のように最小限に止めたりすることが可能であることを意味している。
従来のビル管理システムにおいては、ビル内に中央監視ルームが不可欠であった。しかも、空調、照明、衛生、警報、エネルギー等といった各種の管理項目について設置された機器毎に、独立した管理が行われていた。前述したように、例えば前掲の特許文献１に開示された発明では、メーカー毎の設備制御機器の選定が必要である（段落０００９）。このため、機器類の制御が、システム構成上の縦方向に（縦断的に）は統合できたとしても、メーカーやベンダー毎の各種情報の仕様の違いに関わらず、水平方向に（横断的に）統合することはできず、分断されていた。
図１は、本実施形態のビル管理システム１０の構成を概略的に示している。図中には、設備機器に係る複数の系（項目系）の一例が示されている。図１に示されているのは、空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０である。
空調関連系１２は、エアコン（エアーコンディショナー、空気調和機）や、温度センサー、湿度センサー等といった空調に係る複数の設備機器の系（まとまり、グループ）を示している。
照明・コンセント系１４は、照明機器、照度センサー、商用電源への接続機器等に係る設備機器の系を示している。衛生・水回り系１６は、トイレ、洗面所、給湯等といった衛生や水回りに係る複数の設備機器の系を示している。
状態・警報系１８は、ドアの開閉、地震、権限のない者の侵入等に対処に係る複数の設備機器の系を示している。エネルギー系２０は、使用電力量（電力消費量）や、太陽光発電量、燃料使用量等の把握に係るセンサー類やスイッチ類等の複数の設備機器の系を示している。
ここで、項目系の分類は、上述の例に限られるものではない。例えば、「空調・照明・コンセント系」のように、複数の系を統合してもよい。また、「照明系」、「コンセント系」、「衛生系」、「水回り系」のように、それぞれを独立させてもよい。さらに、「空調１」、「空調２」、「照明１」、「照明２」のように分割してもよい。
上述したような各種の項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）では、様々なメーカーやベンダーの設備機器が用いられるのが一般的である。このため、従来は、各項目系において、メーカーやベンダー毎に、情報通信の抱え込みが生じており、ビルの改修工事や新築工事の際には、メーカーやベンダーの指定の工事業者に工事を発注する必要があった。
また、メーカーやベンダー毎には共通の信号規格や通信規格が使用されていることが多い。このため、メーカーやベンダー毎に、共通の信号規格、通信規格、ＯＳ、プログラミング言語などを用いて管理システムを構築することは可能である。また、マルチプロトコル通信規格に対応するよう予め定められた設備機器を用いた場合には、それらの設備機器のみを統合的に取り扱うことは可能である。しかし、これらの場合は、メーカーやベンダーに対応したサーバーを設置して、管理システムを構築する必要がある。
例えば、１つの項目系（例えば空調関連系１２など）において、複数のメーカーやベンダーの設備機器が採用されている場合には、１つの項目系につき複数のサーバーを設置して、複数の管理システムを構築する必要があった。
また、例えば、各項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）毎に、メーカーやベンダーが統一されているような場合は、項目系毎にサーバーを設置して、管理システムを構築する必要があった。
このように、メーカーやベンダー毎の統合（システム構成上の縦方向の統合）は比較的容易にできるが、各項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）を横断した統合（システム構成上の横方向の統合）は容易ではなかった。そして、従来のビル管理システムにおいては、ＩＴ（情報技術）とＯＴ（運用技術）が分離されていた。
図１に示す本実施形態のビル管理システム１０は、各種の管理項目に係る設備機器の項目を統合し、且つ、適正なクラウド化を行うことで、中央監視ルームを廃止可能としている。本実施形態のビル管理システム１０は、各種の管理項目を、ビル管理者のスマートフォンやタブレット等の携帯情報端末２２から、多数のアプリケーションソフトをインストールすることなく、遠隔で監視できるようにしている。この結果、中央監視ルームに人を縛り付ける必要がなくなり、管理に要する人員の人数や人件費の削減が可能となった。
また、本実施形態のビル管理システム１０は、テナントの社員などの一般利用者も、所定の管理項目を、スマートフォンやタブレット等の携帯情報端末２４から、多数のアプリケーションソフトをインストールすることなく、遠隔で操作できるようにしている。
＜階層構造＞
図１に示すように、本実施形態に係るビル管理システム１０は、大きく分けて、レベル０～レベル４の５つの階層構造を有している。レベル０はセンサーの階層であり、レベル１はセンサー・コントローラー（マイクロ・エッジ・デバイス）の階層である。レベル２はアプリケーション・エッジ・デバイスの階層であり、レベル３は統合コントローラー（統合・エッジ・デバイス）の階層である。レベル４は、エンタープライズ・エッジ・サーバーの階層である。以下に各階層について説明する。
図１に示すように、本実施形態に係るビル管理システム１０は、大きく分けて、レベル０～レベル４の５つの階層構造を有している。レベル０はセンサーの階層であり、レベル１はセンサー・コントローラー（マイクロ・エッジ・デバイス）の階層である。レベル２はアプリケーション・エッジ・デバイスの階層であり、レベル３は統合コントローラー（統合・エッジ・デバイス）の階層である。レベル４は、エンタープライズ・エッジ・サーバーの階層である。以下に各階層について説明する。
＜レベル０：センサー＞
ビル管理システム１０の最も下位レベルの階層はセンサーである。従来、例えば、温度や湿度等といった各種のアナログ情報をデジタル情報に変換するために、シーケンサーを設け、各種の情報に対する閾値を設定して管理する必要があった。
ビル管理システム１０の最も下位レベルの階層はセンサーである。従来、例えば、温度や湿度等といった各種のアナログ情報をデジタル情報に変換するために、シーケンサーを設け、各種の情報に対する閾値を設定して管理する必要があった。
センサーから送出されるデータは、閾値、電流値、レンジ変換等といったいろいろな要素が加わり、一つの塊として形成されている。つまり、シーケンサーの中でデータが処理され、設計者や作業者により閾値が設定され、出力されたデータの一部がビル管理に使用されるだけであった。
従来型のビル管理システムの特徴といってもよいが、従来のビル管理システムは、機器間を物理的に接続して、特定のシリアルバス（RS485）で繋いでいるだけであった。通信は、シリアルバス（RS485）のインターフェースを使って行われており、信号処理は、ＣＰＵを持たない通信用チップを使用して行われていた。このため、従来のビル管理システムには、限られた機能しか備えられておらず、インテリジェンスに欠けていた。
本実施形態に係るビル管理システム１０では、レベル０のセンサーとして、図２に示すような、無線式のインテリジェントセンサー装置（以下では「無線式センサー装置」と称する）３０が用いられている。無線式センサー装置３０は、複数種類（例えば、温度、湿度、照度、加速度、コンタクトの５種類）の検出項目（物理量）の検出が可能である。
無線式センサー装置３０は、複数の項目系（例えば、空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）において使用されている。さらに、無線式センサー装置３０には、複数の機種があり、それぞれの通信規格で無線通信を行う。このため、無線式センサー装置３０には、異なる通信規格で無線通信を行うものが含まれる。さらに、無線式センサー装置３０については、マルチプロトコル対応の設計がされているか否かは問題とならない。
無線式センサー装置３０は、例えば、ビルの壁面、天井、及び、ドア等に設置され、検出した情報をレベル１のセンサー・コントローラー（後述する）に無線送信する。無線式センサー装置３０としては、複数のメーカーやベンダーから提供されている各種のものを混合して採用することが可能である。
無線式センサー装置３０は、図２に示すように、内部に、温度センサー部３２、湿度センサー部３４、照度センサー部３６、加速度センサー部３８、及び、コンタクトセンサー部４０を備えている。さらに、無線式センサー装置３０は、ＣＰＵ４２、記憶部４４、情報形式変換部４６、情報入力部４８、無線通信部５０、及び、発電部５２等を備えている。
温度センサー部３２は、温度センサーを備えており、例えば、室内の空気等の温度を検出可能である。湿度センサー部３４は、湿度センサーを備えており、例えば、室内の空気等の湿度を検出可能である。照度センサー部３６は、照度センサーを備えており、例えば、室内等の明るさを検出可能である。
加速度センサー部３８は、加速度センサーを備えており、例えば、壁に伝わる衝撃等を検出可能である。コンタクトセンサー部４０は、コンタクトセンサー（マグネットコンタクトセンサー）を備えており、例えば、ドアの開閉等を検出可能である。
無線式センサー装置３０に備えられる温度センサー、湿度センサー、照度センサー、加速度センサー、及び、コンタクトセンサーとしては、一般的な各種のセンサーを採用することが可能である。
無線式センサー装置３０においては、エネルギー・ハーベスティング技術を利用して発電し、無線送信する通信規格（EnOcean）が採用されている。無線式センサー装置３０においては、発電部５２の発電（ここでは光発電）により、ＣＰＵ４２やセンサー部３２、３４、３６、３８、４０の正常な動作に必要な電力が供給される。
無線式センサー装置３０は、どの検出項目の検出機能を使用するかを選択することが可能である。また、無線式センサー装置３０は、すべての検出機能を同時に使用することも可能である。
使用する検出機能の設定は、選択された検出機能を識別する情報（検出機能識別情報）を記憶部４４に記憶させて行われる。上記検出機能識別情報の記憶は、無線通信が可能な外部通信機器を利用して行うことが可能である。
上述の外部通信機器としては、例えば、スマートフォンやタブレット端末等の携帯情報端末（携帯情報端末２２、２４など）を例示できる。この場合、携帯情報端末に、所定のアプリケーションソフトをインストールし、このアプリケーションソフトを操作することにより行うことが可能である。所定のアプリケーションソフトには、ビル管理者が使用する管理者用機器管理アプリや、一般利用者用機器管理アプリなどがある。
無線式センサー装置３０においては、ＣＰＵ４２の情報処理により、使用されるセンサー部（センサー部３２、３４、３６、３８、４０のうちの少なくとも一部）の信号が、工業単位の情報に変換され、デジタルデータが生成される。無線式センサー装置３０においては、生成されたデジタルデータを利用して無線パケットが作成され、無線パケットが、後述するレベル１のセンサー・コントローラー（マイクロ・エッジ・デバイス）に送られる。
温度センサー部３２、湿度センサー部３４、照度センサー部３６などのように、連続量を検出するセンサー部については、情報の送信は、所定時間（例えば数十秒～３分など）毎に行われる。また、加速度センサー部３８やコンタクトセンサー部４０の信号に係る情報の送信は、所定の閾値に達するほどの大きさの加速度やコンタクト（接触圧力など）が検出された場合に行われる。
温度センサー部３２、湿度センサー部３４、照度センサー部３６など情報送信間隔を大きくするほど、情報送信量を減らすことができる。上記の所定時間内に、温度センサー部３２、湿度センサー部３４、照度センサー部３６に係る情報を送信してもよく、上記の所定時間毎に、温度センサー部３２、湿度センサー部３４、照度センサー部３６係る情報を順に送信してもよい。
従来のビル管理システムにおいて、情報通信の無線化は、頻繁なバッテリー（電池）交換が必要になることや、無線信号が途切れること等の問題により、敬遠されることが多かった。本実施形態のビル管理システム１０は、このような無線化におけるバッテリーの課題を、エネルギー・ハーベスティング技術により解決している。
なお、エネルギー・ハーベスティング技術に用いられる発電部５２は、光発電を行うものに限らず、例えば、熱電発電、電磁波発電、振動力発電等であってもよい。
熱電発電においては、例えば、ゼーベック効果（温度差が電圧に変換される現象）を利用した熱電変換素子（熱と電力を変換する素子）が用いられ、物体の温度差が電圧に変換される。例えば、空調装置や、ビル内の配管等から発生する熱が、電気エネルギーに変換される。
電磁波発電においては、例えば、ビル内の無線ＬＡＮなどが発する電波のエネルギーをレクテナ（rectifying antenna）により直流電流に変換して発電が行われる。
振動力発電においては、振動によって発生する圧力が、圧電素子などを介して電力に変換される。例えば、ビルのフロア内に圧力センサーが設置され、人が通路を歩く際に発生する圧力や、振動による圧力が、電気エネルギーに変換される。
なお、本実施形態のビル管理システム１０では、照明をオン／オフするためのスイッチとして、無線式スイッチ（図示略）が使用されている。無線式スイッチは、スイッチ機構部や無線通信部を内蔵しており、エネルギー・ハーベスティング技術を利用して、スイッチ機構部の状態を示す情報を、無線により外部に送信する。
無線式スイッチを管理者や一般利用者が手指で操作することにより、オン／オフの情報（オン／オフ情報）が、誘起電力を利用して無線送信される。無線式スイッチは、ビス止めや、マグネットシートの貼付等の方法により、壁面への設置が可能である。
無線式スイッチを使用することにより、配線を要することなく、照明のオン／オフが可能である。配線不要であることから、スイッチ類の置き場所に制約がなく、スイッチの配置の自由度が高い。加えて、バッテリーが不要であり、このことによっても、多くの手間を要していた電池交換作業が不要になる。
以上のように、必要なセンサー類やスイッチ類に対して、可能な限り多くの無線式センサー装置３０や無線式スイッチを用いることで、配線を引き回して、システムの末端を構成するセンサー類やスイッチ類をシーケンサーに接続する作業が不要になる。このため、センサー類やスイッチ類の設置工事を容易に行うことが可能となる。
センサー類やスイッチ類は、前述の項目系１２、１４、１６、１８、２０の中に多数含まれている。また、１つのビルに使用されるセンサー類やスイッチ類は、フロア内の部屋数等によっても異なるが、ビルのインテリジェント化が進むほど多くなる。
このため、部屋数の多いビルや、高度にインテリジェント化されたビルの改築工事や新築工事の際に、センサー類やスイッチ類の配線作業に要する工数（人員数×時間）は相当な値となる。したがって、無線式センサー装置３０や無線式スイッチを用いることで、配線作業の多くを不要にすることができ、工数を大幅に削減することが可能となる。
従来、配線作業に要する作業内容や工数は、作業現場任せになりがちであり、工期の見積りや、人件費の見積りを不正確にする大きな要因であった。例えば、センサー装置とシーケンサーの間の配線や、シーケンサーと上記の機器の配線等をどのように行うかは、作業現場の判断により行われることが多かった。また、設置されるセンサー装置の数は、ビルの形態や規模によって、数百～数十万といった数に達する。さらに、ビルの改修コストや新築コストの多くの部分は、人件費に依って占められている。したがって、配線に要する工数を削減することは、コスト削減に大きく寄与する。
なお、本実施形態に係るビル管理システム１０では、すべてのセンサーやスイッチ類が無線式であることに限られるものではなく、一部のセンサーやスイッチは有線で信号をシーケンサー等に送出するものであってもよい。また、前述したその他電気機器類には、無線通信するものや有線通信するものが含まれていてもよい。
＜レベル１：センサー・コントローラー（マイクロ・エッジ・デバイス）＞
各無線式センサー装置３０から送信されたデジタルデータは、レベル１のセンサー・コントローラー（マイクロ・エッジ・デバイス６０）により受信される。センサー・コントローラーは、マイクロ・エッジ・デバイス６０により構成される。
各無線式センサー装置３０から送信されたデジタルデータは、レベル１のセンサー・コントローラー（マイクロ・エッジ・デバイス６０）により受信される。センサー・コントローラーは、マイクロ・エッジ・デバイス６０により構成される。
本実施形態のビル管理システム１０では、管理対象のビルの規模や棟数等の条件に応じて、複数個のマイクロ・エッジ・デバイス６０が用いられる。図１には、一例として３つのマイクロ・エッジ・デバイス６０が示されている。１つのマイクロ・エッジ・デバイス６０には、例えば、１００個以上（最大２００個程度）の各無線式センサー装置３０の対応付けや、図示は省略するが、有線式のセンサー類やスイッチ類に接続されたシーケンサー類の対応付けが可能である。そして、１つのマイクロ・エッジ・デバイス６０では、１００～２００点程度の監視点数についてのデータ処理が可能である。
従来、例えば、ビルの窓に設置されたブラインドの制御に関して、ブラインド専用のコントローラー（専用コントローラ）が用いられていた。専用コントローラーでは、ブラインド制御プログラムが実行されて、ブラインドの制御に係る処理が行われていた。つまり、ブラインドと専用コントローラーにより構成される制御系において、制御対象（ここではブラインド）の制御が完結していた。
従来より、ビル管理システムにおいては、空調、照明、衛生、セキュリティー、エネルギー等に係る多くの管理項目について監視制御が行われている。これらの管理項目に係る制御（監視制御）においては、前述したように、使用される機器や、機器の製造業者、機種等の違いに応じて、様々な信号規格、通信規格、ＯＳ、プログラム言語等を用いた制御が行われるのが一般的であった。
そして、ビル管理の技術分野において、ＩＴ（情報技術）やＯＴ（運用技術）に関する様々な規格が存在し、これらの規格の内容が異なるため、１つのコントローラーに、既存の各種のセンサー類や、ビルの建設業者が選定したセンサー類等の多種類のセンサー類を通信可能に接続することはできなかった。
これに対し、本実施形態のビル管理システム１０では、すべての情報の出発点となるアナログデータ（無線式センサー装置３０より収集したデータ）が、レベル０の無線式センサー装置３０自身によりデジタル化される。１つのマイクロ・エッジ・デバイス６０に対し、多数の無線式センサー装置３０のデジタル情報が、マイクロ・エッジ・デバイス６０に集約される。
無線式センサー装置３０には、同じデジタル無線通信規格による情報通信を行うものや、互いに異なるデジタル無線通信規格による情報通信を行うものが含まれる。マイクロ・エッジ・デバイス６０は、多数（例えば１５０以上）の数の通信規格（通信プロトコル）を取り扱うことが可能なように構成されている。
マイクロ・エッジ・デバイス６０では、多数の無線式センサー装置３０の情報を、無線式センサー装置３０に採用されている通信規格毎に、共通仕様の通信規格（ここではＩＰ（インターネット・プロトコル））に変換して取り扱うことが可能である。つまり、マイクロ・エッジ・デバイス６０においては、異なる通信規格の信号が入力されて、統一された共通仕様の信号が出力される。マイクロ・エッジ・デバイス６０は、対応付けられた設備機器にＩＰアドレスを割り振り、ＩＰアドレスを用いて識別する。
マイクロ・エッジ・デバイス６０は、個々に、異なる通信規格の信号を集約して共通仕様の信号が出力されるゲートウェイとして機能する。マイクロ・エッジ・デバイス６０を、管理対象のビルの規模や棟数等に応じて多数備えることにより、複数のゲートウェイにより構成されるゲートウェイ群を大規模に形成することが可能である。なお、各項目系１２、１４、１６、１８、２０と、マイクロ・エッジ・デバイス６０との間に、他のゲートウェイ（細分化されたゲートウェイ）が存在する場合もある。ここでいうゲートウェイ群には、マイクロ・エッジ・デバイス６０とは別の機器として存在するゲートウェイも含まれる。マイクロ・エッジ・デバイス６０とゲートウェイとの関係（位置づけ）は、マイクロ・エッジ・デバイスが上位であり、ゲートウェイが下位である。
マイクロ・エッジ・デバイス６０では、無線式センサー装置３０からの情報が吸い上げられ、必要な情報の整理が行われて、上層のアプリケーション・エッジ・デバイス６２（レベル２）に送信される。マイクロ・エッジ・デバイス６０の階層（レベル１）では、例えば、多数のマイクロ・エッジ・デバイス６０によりマイクロ・エッジ・デバイス群６０Ａが構成される。マイクロ・エッジ・デバイス群６０Ａは、概念上、前述のゲートウェイ群に含まれものとすることができる。
マイクロ・エッジ・デバイス群６０Ａは、ゲートウェイの機能を発揮してデータの変換（コンバート）を行い、統一化された仕様の情報（パターン化された形式の情報）を上層の、対応付けられたアプリケーション・エッジ・デバイス６２に送信する。
このように、無線式センサー装置３０やシーケンサー類によりデジタル化されたアナログデータは、マイクロ・エッジ・デバイス６０で前段階処理され、統一化された仕様の情報となって上位層に送出される。マイクロ・エッジ・デバイス６０では、末端の無線式センサー装置３０でデジタル化された情報が、レベル２でのデータベース化のために前段階処理される。
マイクロ・エッジ・デバイス６０としては、図示は省略するが、例えば、ＣＰＵ、記憶部、無線通信部等を備え、マルチプロトコルのデジタル情報を、時分割等の処理や、情報変換の処理により、共通の通信規格に変換するものを採用できる。
＜レベル２：アプリケーション・エッジ・デバイス＞
マイクロ・エッジ・デバイス６０の上層（レベル２）にあるのがアプリケーション・エッジ・デバイス６２である。アプリケーション・エッジ・デバイス６２は、ビルの空調、電気、衛生、中央監視等といった管理項目（アプリケーション）毎にデータを集める役割を担う。
マイクロ・エッジ・デバイス６０の上層（レベル２）にあるのがアプリケーション・エッジ・デバイス６２である。アプリケーション・エッジ・デバイス６２は、ビルの空調、電気、衛生、中央監視等といった管理項目（アプリケーション）毎にデータを集める役割を担う。
前述したように、マイクロ・エッジ・デバイス６０（レベル１）において、センサー（レベル０）のデータが集約され、センサー（レベル０）でデジタル化されたデータが、マイクロ・エッジ・デバイス６０（レベル１）からアプリケーション・エッジ・デバイス６２（レベル２）に送出される。
管理対象のビルの規模にもよるが、例えば、１００個程度のマイクロ・エッジ・デバイス６０に対して、１つのアプリケーション・エッジ・デバイス６２が設置される。所謂中小ビルのレベルであれば、１台のアプリケーション・エッジ・デバイス６２により、ビル全体の管理が可能である。この場合、後述のレベル３及びレベル４は省略することが可能である。
アプリケーション・エッジ・デバイス６２には、中央監視機能が備えられている。中央監視機能は、エネルギー・マネジメント・システム（ＥＭＳ）の監視や制御のための処理を行い、得られた情報を外部機器に提供できるようにした機能である。中央監視機能部により、各無線式センサー装置３０で収集された情報に基づき、電力量等の情報がリアルタイムに処理され、統計的に視覚化されて、表示可能な情報として出力される。つまり、エネルギー・マネジメント・システム（ＥＭＳ）の監視・制御システムが、アプリケーション・エッジ・デバイス６２の中に組み込まれている。
アプリケーション・エッジ・デバイス６２では、図３に示すように、マイクロ・エッジ・デバイス６０から送られた情報が、データベース作成用のソフトウェアに読み込まれ（Ｓ(ステップ)１１）、自動的にデータベースが作成される（Ｓ１２）。さらに、個別の認識データの設定（パラメータ設定など）には、プロダクティビティ・ツールが用いられている。
プロダクティビティ・ツールは、本実施形態のビル管理システム１０で使用されるアプリケーションソフトの１つとして開発されたものである。プロダクティビティ・ツールについては後述する。データベース作成用のソフトウェアとしては、一般的な種々のものを採用できる。
作成されたデータベースには、図４に示すように、収集されたデータの各種の属性（プロパティを含む）が記録されている。記録される属性としては、ＩＰアドレス、ビル名、フロア、エリア、管理項目、情報種別、情報取得日、情報取得時刻などの情報が含まれる。また、センサー類の情報である場合には、各センサーの検出値などの情報（検出値情報）や、オン／オフの情報なども含まれる。
従来、インテリジェントセンサーや、マイクロ・エッジ・デバイス６０への設定データの登録は、一つずつ手作業で打ち込む必要があった。このような作業は、打ち込み作業そのものが多くの手間を要するほか、データの特性や仕組み等を理解していなければ行うことができなかった。本実施形態のビル管理システム１０によれば、自動的にデータベースが作成されるので、手作業や、仕組み等の理解を要することなく、データ登録を行うことが可能である。
さらに、アプリケーション・エッジ・デバイス６２では、中央監視機能部を用いて、データベース化された情報に基づき、各設備機器から収集した温度や湿度、電力量といった情報をリアルタイムに、統計的に視覚化して表示するための情報を出力できる。出力された情報は、インターネット回線（公衆無線通信回線、及び、公衆有線通信回線）６８を介して、ビル管理者のＰＣ（パーソナルコンピュータ）に接続された表示装置や、携帯情報端末などに表示される。ビル管理者のＰＣや携帯情報端末にインストールされているブラウザを介して、中央監視用アプリケーションソフトへの接続が行われる。
前述のＥＭＳ（エネルギー・マネジメント・システム）は、情報の見える化を行っている。すなわち、センサーや照明、空調、衛生、エネルギーといった各機器から集められた情報は、それらが単に存在するだけでは価値を生まない。これらのデータ（情報）を、種類別に分類し、必要な部分、必要な時間だけを集計し、統計処理した上で、画面表示してこそ価値が生まれる。
本実施形態のビル管理システム１０におけるＥＭＳは、電気の使用量を様々なグラフで見ることができるよう構成されている。もちろん、使用している様々な設備機器毎の電気量も見ることが可能である。
一般に、ビルで消費するエネルギーの ６５％は、空調と照明である。点きっぱなしになっている空調と照明を、外部温度や日光などの周辺環境の状態や、人の在室・在籍の状況に応じてコントロールすることができれば、消費エネルギーを大きく節減することができる。
電力の使用量を解析するためには、機器の運転状況、温度、外気温等の複合要素の分析も必要である。本実施形態におけるビル管理システム１０では、エネルギー管理については、トレンドデータの表示が可能となっている。トレンドデータは、最速１秒単位で多くのテータを取り込むことが可能である、このため、エネルギー分析には最適である。
このようなＥＭＳを使用して、エネルギー種別毎の使用量、時系列のエネルギー解析が可能である。さらに、設備機器を選択して、設定や状況表示をリアルタイムに行うことが可能である。
前述のプロダクティビティ・ツールは、同一ネットワーク上に設置されたセンサー類やスイッチ類、及び、各設備機器等の情報を自動収集し、データベース化する（図４）。作成されたデータベースに対して、一つひとつの設定情報を効率的に登録することができる。
従来は、ビル内の照明器具や空調、衛生などの各機器やセンサーから情報を収集して、現在の使用状況を表示したり、制御したりするためには、すべての機器とその機能に対して、一つずつ設定作業を行う必要があった。
例えば、接点情報（監視点数）が数十万点もある巨大ビルに限らず、数百点であっても、その設定を一つずつ手で行わなければならず、非常に多くの時間を要していた。しかも、その情報が現在どうなっているのかといった事項を確認する状態管理にも多くの手間を要していた。
本実施形態のビル管理システム１０では、このような問題を解決するために、前述のプロダクティビティ・ツールが用いられている。プロダクティビティ・ツールを用いることにより、従来、設定するだけで何十日もかかっていた作業がわずかな時間で行えるようになる。しかも登録するデータは、遠隔地からのダウンロードにより設定可能である。プロダクティビティ・ツールにより、工事作業が大幅に簡便化されるとともに、工事費用も大きく削減されることとなる。
＜レベル３：統合コントローラー（統合・エッジ・デバイス）＞
ビル内には、空調、電気、衛生、中央監視といったアプリケーション別のシステム（アプリケーション別システム）が多く構築されている。本実施形態のビル管理システム１０における統合コントローラー（統合・エッジ・デバイス６４）は、これらのアプリケーション別システムを統合し、受信した情報を、インターネット回線（公衆無線通信回線、及び、公衆有線通信回線）６８を介して、さらに上位のシステムへと順次伝達する。情報の伝達には、ＬＡＮ（ローカル・エリア・ネットワーク、構内ネットワーク）も適宜利用される。
ビル内には、空調、電気、衛生、中央監視といったアプリケーション別のシステム（アプリケーション別システム）が多く構築されている。本実施形態のビル管理システム１０における統合コントローラー（統合・エッジ・デバイス６４）は、これらのアプリケーション別システムを統合し、受信した情報を、インターネット回線（公衆無線通信回線、及び、公衆有線通信回線）６８を介して、さらに上位のシステムへと順次伝達する。情報の伝達には、ＬＡＮ（ローカル・エリア・ネットワーク、構内ネットワーク）も適宜利用される。
本実施形態のビル管理システム１０において、統合コントローラー（統合・エッジ・デバイス６４）のハードウェア及びソフトウェアは、１台が、床面積が１０万平米のビルを管理できる程度の処理能力を有するよう構築されている。１０万平米は１０ｈａであり、３１６ｍ×３１６ｍのフロア、又は、１フロアが５０ｍ×５０ｍの４０階建てビルに相当する。このように、１台の統合コントローラー（統合・エッジ・デバイス６４）により、相当程度の規模の管理が可能である。
＜レベル４：エンタープライズ・エッジ・サーバー＞
本実施形態のビル管理システム１０においては、マイクロ・エッジ・デバイス６０（レベル１）、アプリケーション・エッジ・デバイス６２（レベル２）、統合エッジ・デバイス６４（レベル３）の上層に、エンタープライズ・エッジ・サーバー６６（レベル４）の階層が構築されている。これらのデバイスやサーバーは、いずれも、コンピュータ機器を用いて構成されるが、これらの間の大きな違いは、コンピュータ機器としての性能（処理容量、処理速度など）と、メモリ領域の利用形態である。
本実施形態のビル管理システム１０においては、マイクロ・エッジ・デバイス６０（レベル１）、アプリケーション・エッジ・デバイス６２（レベル２）、統合エッジ・デバイス６４（レベル３）の上層に、エンタープライズ・エッジ・サーバー６６（レベル４）の階層が構築されている。これらのデバイスやサーバーは、いずれも、コンピュータ機器を用いて構成されるが、これらの間の大きな違いは、コンピュータ機器としての性能（処理容量、処理速度など）と、メモリ領域の利用形態である。
従来は、監視点数の制約が大きかったが、本実施形態のビル管理システム１０におけるエンタープライズ・エッジ・サーバー６６は、管理対象のビルの規模や棟数が増えて、性能が足りない場合には、未使用のスロット使用し、ＣＰＵの数を増やすことにより対応できるようにしている。また、より処理能力の高いＣＰＵを搭載した基板（ボード）に交換することでも、性能を向上できる。
さらに、エンタープライズ・エッジ・サーバー６６としては、ＶＭ（Virtual Machine、仮想マシン）を構成することが可能なコンピュータ機器が用いられている。ＶＭを構成することにより、管理システムの多重化（ここでは二重化）が可能である。
ＶＭは、システムの他の部分から分離され、１台のハードウェア上で複数が共存するよう構築される。ＶＭにより、複数の異なるＯＳ（オペレーティング・システム）を１台のコンピュータ機器上で同時に実行できるようになる。
例えば、ビル管理のシステムを改修しようとした場合、改修後にも、Windows NT（登録商標）やXPなどといった、近年では新たに導入されることがない古いＯＳ（オペレーティング・システム）を使用し続けなければならないことがある。
従来のビル管理システムでは、監視サーバーがＯＳに依存しているため、上位層の機器を変更すると、上位層に合わせて下位層の機器をもすべて変えなければならない。このため、下位層の機器の少なくとも一部を維持したままシステムを新しくしようとしても、過去のシステムに引きずられ、古いＯＳを残しておく必要がある。
本実施形態のビル管理システム１０においては、エンタープライズ・エッジ・サーバー６６は、仮想サーバーを構成できる。このため、新たにエンタープライズ・エッジ・サーバー６６を導入した場合に、エンタープライズ・エッジ・サーバー６６において、多様なＯＳを並行して動作させることが可能である。そして、例えば、Linux（登録商標）とWindows NT（登録商標）を並行して動作させる、といったことが可能である。
したがって、ビル管理システムの改修の際に、下位層の機器を残し、上位層だけを新しいものに交換するといったことが可能となる。しかも、複数のＯＳに係るシステムをそれぞれ構築することが可能である。このような考え方そのものが、従来と違って、新しい取り組みを示すものである。そして、ＶＭに古いＯＳを残すことができるため、システム改修時のサーバー機器の置き換えが、従来に比べて非常に楽なものとなる。
エンタープライズ・エッジ・サーバー６６を用いるメリットは大きい。単に構成する機器のサイズが小さくなっただけではなく、所定期間（７年程度）毎に発生する改修作業をも容易にする。
従来では、大規模システムの改修には保有システムの退避・保存・リロード等を行うためには丸１日要していた。さらに、サーバー台数分の作業を行う必要があったため、改修作業全体として、何日もの日程を要していた。
本実施形態のビル管理システム１０では、エンタープライズ・エッジ・サーバー６６を用いることにより、このような問題が解決され、システムを停止させることなく、ホット・スワップ（電源を入れたまま）での機器改修（交換・増設等）が可能となった。ホット・スワップでの機器改修を行えるようにするためには、エンタープライズ・エッジ・サーバー６６を二重化構成として冗長化することが可能である。この場合、一方のエンタープライズ・エッジ・サーバー６６を稼働させながら、もう一方のエンタープライズ・エッジ・サーバー６６を改修する。
＜エッジ・デバイスの働き＞
＜＜分散システム＞＞
本実施形態に係るビル管理システム１０の一つの大きな特徴は、無線通信やインターネット通信を適切に組み合わせることにより、監視点数の増大を容易に行えるようにしていることである。従来のビル管理システムでは監視点数に制限があり、その制限は、数千から、多ければ数万程度である。ビルのインテリジェント化や、複数のビルの管理を行う多棟管理を進めようとすると、管理能力が容易に限界に達してしまう。従来のビル管理システムにより、管理点数の制限を超えるシステムを導入する場合は、特別にプログラムを組み、複数のサーバーをブリッジさせる必要があった。
＜＜分散システム＞＞
本実施形態に係るビル管理システム１０の一つの大きな特徴は、無線通信やインターネット通信を適切に組み合わせることにより、監視点数の増大を容易に行えるようにしていることである。従来のビル管理システムでは監視点数に制限があり、その制限は、数千から、多ければ数万程度である。ビルのインテリジェント化や、複数のビルの管理を行う多棟管理を進めようとすると、管理能力が容易に限界に達してしまう。従来のビル管理システムにより、管理点数の制限を超えるシステムを導入する場合は、特別にプログラムを組み、複数のサーバーをブリッジさせる必要があった。
本実施形態のビル管理システム１０では、エンタープライズ・エッジ・サーバー６６が仮想サーバーを構成するため、ＣＰＵの増加により処理能力を容易に増強することが可能である。これにより、無限のリソースといえるハードディスク（記憶手段）も利用して、巨大なビル管理システムを構築することが可能となる。
また、ビル管理システム１０の一つの大きな特徴は、分散システムである。例えば、一つのサーバーを二つに分散することができる。サーバーを分割するが、すべてのデータを一つに集めなくてもよく、分散しておいて、必要に応じて取ってくる（オンデマンドで集める）ことができるようにしている。つまり、すべてのサーバーを繋ぐ必要がない。
必要な時に、必要な操作を行うことにより、複数のサーバーから、必要なデータを集めることが可能である。本実施形態のビル管理システム１０では、例えば、「データＡとデータＢとデータＣだけが欲しい」旨のコマンドをＰＣや携帯情報端末に入力すると、必要なデータが出力される。本実施形態のビル管理システム１０は、あたかも１つのコンピュータが処理しているように動作する。
従来のビル管理システムは、ほとんどがクライアント・サーバー型であり、このような動作はできない。従来のビル管理システムは、分散型にはなることはできず、大きなシステムにならざるを得なかった。この限界を超える仕組みを構築したことが、本実施形態のビル管理システム１０の特徴の一つである。
＜＜エッジ・サーバーの活用＞＞
従来のビル管理システムは、一つのサーバーの中にデータを集約し、その中を統括して管理していた。このため、システム自体が大きくなっていた。しかし、本実施形態のビル管理システム１０は、エッジ・サーバーを使うことでシステムを分散化している。そして、分散化は行っているが、例えば「マイクロ・エッジ・デバイス６０の特定のデータを見たい」旨のコマンドを入力すると、オンデマンドでデータを見ることができる。
従来のビル管理システムは、一つのサーバーの中にデータを集約し、その中を統括して管理していた。このため、システム自体が大きくなっていた。しかし、本実施形態のビル管理システム１０は、エッジ・サーバーを使うことでシステムを分散化している。そして、分散化は行っているが、例えば「マイクロ・エッジ・デバイス６０の特定のデータを見たい」旨のコマンドを入力すると、オンデマンドでデータを見ることができる。
＜＜統一データ様式＞＞
本実施形態のビル管理システム１０における他の特徴の一つは、情報の管理がすべて、統一された様式で行われることである。前述のように、無線式センサー装置３０を用いることにより、統一された様式のデータが自動的に収集される。しかもその様式は、先に述べた４種類のエッジ・デバイス（マイクロ・エッジ・デバイス６０、アプリケーション・エッジ・デバイス６２、統合・エッジ・デバイス６４、及び、エンタープライズ・エッジ・サーバー６６）のすべてで共通化されている。
本実施形態のビル管理システム１０における他の特徴の一つは、情報の管理がすべて、統一された様式で行われることである。前述のように、無線式センサー装置３０を用いることにより、統一された様式のデータが自動的に収集される。しかもその様式は、先に述べた４種類のエッジ・デバイス（マイクロ・エッジ・デバイス６０、アプリケーション・エッジ・デバイス６２、統合・エッジ・デバイス６４、及び、エンタープライズ・エッジ・サーバー６６）のすべてで共通化されている。
マイクロ・エッジ・デバイス６０（レベル１）で取り扱われるデータ様式の構造と、その上位にあるアプリケーション・エッジ・デバイス６２（レベル２）、統合エッジ・デバイス６４（レベル３）、及び、エンタープライズ・エッジ・サーバー６６（レベル４）の構造は同じである。このため、上位レベルのエッジ・デバイスにおいて、上位レベルのエッジ・デバイスのデータを引き継ぐことができる。
以上のようにして統一様式のデータが作成され、作成されたデータが、多様な管理項目（空調、電気、衛生、中央監視等といった種々のアプリケーション）において活用される。統一様式のデータを利用することにより、あたかも、共通な接続構造を有するブロック玩具を組み合わせて目的の造形を作り上げるように、全体的に統合されたビル管理システム１０を構築できるようになる。
＜クラウドの活用＞
＜＜遠隔監視＞＞
本実施形態のビル管理システム１０では、クラウドが活用されている。このため、ビル監視者や一般利用者が、それぞれ独自にサーバーや記憶装置を持たずに、公共通信網を利用して、ビル管理のサービスを受けることが可能である。このようにクラウドを使用する理由の一つは、遠隔監視を行うためである。
＜＜遠隔監視＞＞
本実施形態のビル管理システム１０では、クラウドが活用されている。このため、ビル監視者や一般利用者が、それぞれ独自にサーバーや記憶装置を持たずに、公共通信網を利用して、ビル管理のサービスを受けることが可能である。このようにクラウドを使用する理由の一つは、遠隔監視を行うためである。
ただし、複数の下位機器からデジタル化されたデータをそのまま上位層に上げてしまうと、データを受け取る上位機器で、通信量が増大し、データ処理速度の低下を招きかねない。
発明者等の知見では、ビル管理のためにクラウドを使用する場合、センサー類やスイッチ類により現場（ビル管理システム１０の末端）から集められたデータのうち、クラウドに上げるべきデータは、実際のところ、全収集データの数％（例えば３％程度）で十分である。その数％は、例えば、ＥＭＳ（エネルギー・マネジメント・システム）、エネルギーのデータ、ＦＭＳ（施設管理システム）である。これらのデータを、例えば、３０分に一度や、１時間に一度程度の頻度で収集するだけでも、十分なビル管理を行うことは可能である。
ビル管理に必要なデータは、時々刻々とダイナミックに変化するようなものよりも、スタティックなデータ、つまり静的データである。静的データについては、一定の時間間隔で収集して累積するだけでも、ビル管理においては十分である。このため、後述するように、オンプレミスによるデータ収集と、クラウドによるデータ収集とを併用したビル管理が行われる。何をクラウドに上げれば、全体のパフォーマンスが最大化するかを考慮し、何をスタティックデータとしてクラウドに上げ、何をダイナミックデータとしてアプリケーション・エッジ・デバイスに残しておくかが選定される。
＜＜オンプレ・クラウド＞＞
現在、クラウドサービスは、情報処理サービスの主流となっている。クラウドサービスについては、とにかく多くのデータを集めてビッグデータを集積すればよいと考えられがちであるが、ビル管理システムに応用した場合、実際に膨大なデータを集めても、有効なビル管理システムを構築することは難しかった。
現在、クラウドサービスは、情報処理サービスの主流となっている。クラウドサービスについては、とにかく多くのデータを集めてビッグデータを集積すればよいと考えられがちであるが、ビル管理システムに応用した場合、実際に膨大なデータを集めても、有効なビル管理システムを構築することは難しかった。
有効なビル管理システムの構築が難しかった原因として、集積されたデータの情報をどのように取り扱えばよいかが分かり難く、せっかく集められたデータの９０％以上は使う必要さえない、といった場合もあった。
現場（ビル管理システム１０の末端）で収集されたデータの１００％すべてをクラウドに乗せても（アップロードしても）、そのうちの９０％以上のデータは、何らかのトラブルが発生したような場合以外は使われない。
クラウドに上げる（アップロードする）には、通信費が発生し、ＣＰＵ使用料も発生し、クラウドに上げるための情報を記憶しておく保存領域（「使用領域」ともいう）も必要になる。もし、すべての発生データを保存しておけるような保存領域を確保する場合には、保存領域の大きさは、ギガバイトやテラバイトといった単位の大きさでは済まず、ペタバイト以上に達すると予想される。そのうえ、クラウドの保存容量が巨大なり、クラウドの維持や管理に、当然、莫大な費用を要することとなる。
そこで、本実施形態のビル管理システム１０は、エッジ・デバイス（現場で前処理するシステム）を活用し、オンプレミスなデータ処理とクラウドサービスとを適切に使い分けることにより、有効なビル管理システムの構築を可能としている。
本実施形態のビル管理システム１０では、すべてのデータをクラウドに乗せる（アップロードする）のではなく、選択されたデータがクラウドに乗せられる。平常時は、スタティックなデータのみを選択的に上げ、所定の条件が成立した場合（例えば、警報（アラーム）が発せられた場合など）に限り、その他のデータ（例えば履歴データ）がオンプレミスのデータから利用される。
このようにすることで、例えば、警報が出た場合に、警報の原因となった事象が発生した時間帯のオンプレミスのデータを参照することで、原因を調査するための処理プログラムを実行する、といったことが可能となる。そして、通信量と保存領域の抑制、通信速度やレスポンス（応答）速度の向上が図られている。
＜＜技術の統合＞＞
本実施形態のビル管理システム１０では、収集したデータをクラウドで活用したり、オンプレミスで活用したりするために種々の機器類や、ツール（アプリケーションソフト）類が備えられている。これらの機器類やツール類は、個別に存在しているのではなく、互いに連携している。そして、これらの機器類やツール類は、システムのパフォーマンスを最大化するために不可欠のものとなっている。
本実施形態のビル管理システム１０では、収集したデータをクラウドで活用したり、オンプレミスで活用したりするために種々の機器類や、ツール（アプリケーションソフト）類が備えられている。これらの機器類やツール類は、個別に存在しているのではなく、互いに連携している。そして、これらの機器類やツール類は、システムのパフォーマンスを最大化するために不可欠のものとなっている。
＜中央監視機能＞
＜＜ＩＴとＯＴの融合による多彩な見える化を実現＞＞
ビル管理システムの大きな目的は、ビル内に設置された機器類の一元的な状態監視と制御である。従来は、このような全体的な管理が難しかった。しかし、本実施形態のビル管理システム１０は、様々な工夫を組み合わせて、全体的な管理を実現している。例えば、電力量については、所定期間（指定期間）における全体の合計や、機器毎の合計について、可視化（見える化）が行われている。そして、いつ、どこで、どの機器が、どのくらいの電力を使用しているか、といった事項が確認できるようになっている。
＜＜ＩＴとＯＴの融合による多彩な見える化を実現＞＞
ビル管理システムの大きな目的は、ビル内に設置された機器類の一元的な状態監視と制御である。従来は、このような全体的な管理が難しかった。しかし、本実施形態のビル管理システム１０は、様々な工夫を組み合わせて、全体的な管理を実現している。例えば、電力量については、所定期間（指定期間）における全体の合計や、機器毎の合計について、可視化（見える化）が行われている。そして、いつ、どこで、どの機器が、どのくらいの電力を使用しているか、といった事項が確認できるようになっている。
＜＜照明・温度・湿度等の見える化＞＞
本実施形態のビル管理システム１０において、照明については、照明の点灯状況のほか、オン／オフ、及び、調光制御の状況等を、特定の態様で画面表示することが可能である。また、室内環境については、室内のＣＯ２濃度、温度、湿度などを、特定の態様（ヒートマップなど）で画面表示することが可能である。
本実施形態のビル管理システム１０において、照明については、照明の点灯状況のほか、オン／オフ、及び、調光制御の状況等を、特定の態様で画面表示することが可能である。また、室内環境については、室内のＣＯ２濃度、温度、湿度などを、特定の態様（ヒートマップなど）で画面表示することが可能である。
＜＜環境の見える化－トレンドグラフ＞＞
本実施形態のビル管理システム１０においては、温度、湿度、照度等を、トレンドグラフによっても画面表示することが可能である。
本実施形態のビル管理システム１０においては、温度、湿度、照度等を、トレンドグラフによっても画面表示することが可能である。
＜＜利用状況や連携アプリケーション＞＞
本実施形態のビル管理システム１０においては、スケジュール、操作履歴、帳票、地震警報システム、クラウドアプリケーションなども画面表示することが可能である。
本実施形態のビル管理システム１０においては、スケジュール、操作履歴、帳票、地震警報システム、クラウドアプリケーションなども画面表示することが可能である。
＜遠隔監視機能＞
＜＜多棟管理を可能にするクラウド監視システム＞＞
本実施形態のビル管理システム１０においては、ビル内の空調、照明、衛生、警報、エネルギーに関する各種の機器類について、スマートフォンやタブレット等の携帯情報端末を介して、監視や制御を行うことができる。また、ビルから離れた遠隔地からも、携帯情報端末を介して、監視や制御を行うことができる。
＜＜多棟管理を可能にするクラウド監視システム＞＞
本実施形態のビル管理システム１０においては、ビル内の空調、照明、衛生、警報、エネルギーに関する各種の機器類について、スマートフォンやタブレット等の携帯情報端末を介して、監視や制御を行うことができる。また、ビルから離れた遠隔地からも、携帯情報端末を介して、監視や制御を行うことができる。
携帯情報端末では、インストールされたブラウザを介して、ビル管理のためのアプリケーションソフトに接続し、アプリケーションソフトを利用することが可能である。携帯情報端末のブラウザを介して、操作し易く、レスポンス（応答性）の良い管理画面が提供される。
前述したように、クラウドに乗せるのはスタティックデータのみであり、利用頻度の少ないダイナミックデータはエッジ・デバイスに配置される。このため、クラウドの使用領域が小さく、費用低減や、レスポンス（応答性）の向上が実現される。データ処理量そのものを削減することで、処理に要する時間を削減できる。集計しやすい形（少ない量）でのデータの保管を行う保管形式を採用できる。これらによってもレスポンス（応答性）の向上が実現される。
＜＜ＣＢＭの実現＞＞
複数のビルの管理を行う多棟管理においては、どのビルで障害（異常）が発生しているかを知ることが重要である。従来は、異常の発生を常時確認しているような常時監視が行われていた。これに対し、本実施形態のビル管理システム１０においては、定期的にデータを採取したうえで、異常が発生した場合にだけ対応が行われる「予防保全」（ＣＢＭ： Condition Based Maintenance）が実現されている。
複数のビルの管理を行う多棟管理においては、どのビルで障害（異常）が発生しているかを知ることが重要である。従来は、異常の発生を常時確認しているような常時監視が行われていた。これに対し、本実施形態のビル管理システム１０においては、定期的にデータを採取したうえで、異常が発生した場合にだけ対応が行われる「予防保全」（ＣＢＭ： Condition Based Maintenance）が実現されている。
定期的に採取されるデータに基づき、異常が発見された場合には、携帯情報端末に警報（アラーム）が通知される、といった対策が施されている。さらに、アラームが発生したビルを指定し、ドリルダウンすることで、遠隔地からでもより詳細な状況把握を行うことができる。ドリルダウンにおいては、アラームが発生したビルの属性に紐付けられたデータを選んで、予め定められた各種の分析が実行される。
＜手のひらで監視・制御が可能なスマートパーム（商標登録出願中）＞
本実施形態のビル管理システム１０では、最新のテクノロジーを駆使し、新しい時代にふさわしい、照明とエアコンを制御するインテリジェントなツールが実現されている。ビル管理者や一般利用者等にブラウザを介して提供されるスマートパーム（商標登録出願中）は、照明と空調の両方のリモコン（遠隔操作）を携帯情報端末上で実現して、オフィス内の照明やエアコンを制御・監視することを可能とする。スマートパーム（商標登録出願中）は、あたかも手のひらがスイッチになったような操作性を提供するツールである。
＜＜ネットワークをまたいだ遠隔監視が可能＞＞
本実施形態のビル管理システム１０においては、スマートフォンやタブレット等の携帯情報端末を利用することにより、場所や時間等の制約に縛られず、どこからでもビル管理システムを制御することが可能である。
本実施形態のビル管理システム１０では、最新のテクノロジーを駆使し、新しい時代にふさわしい、照明とエアコンを制御するインテリジェントなツールが実現されている。ビル管理者や一般利用者等にブラウザを介して提供されるスマートパーム（商標登録出願中）は、照明と空調の両方のリモコン（遠隔操作）を携帯情報端末上で実現して、オフィス内の照明やエアコンを制御・監視することを可能とする。スマートパーム（商標登録出願中）は、あたかも手のひらがスイッチになったような操作性を提供するツールである。
＜＜ネットワークをまたいだ遠隔監視が可能＞＞
本実施形態のビル管理システム１０においては、スマートフォンやタブレット等の携帯情報端末を利用することにより、場所や時間等の制約に縛られず、どこからでもビル管理システムを制御することが可能である。
＜＜照明・空調の制御＞＞
本実施形態のビル管理システム１０においては、携帯情報端末を使って、空調や照明等の制御を直接行うことができる。このため、例えば、オフィスの照明や空調（エアコン）の温度を変更するために、オフィス内の人員が壁のスイッチまで移動することが不要になる。
本実施形態のビル管理システム１０においては、携帯情報端末を使って、空調や照明等の制御を直接行うことができる。このため、例えば、オフィスの照明や空調（エアコン）の温度を変更するために、オフィス内の人員が壁のスイッチまで移動することが不要になる。
例えば、照明に関しては、フロア内の全灯について、一括してオン／オフしたり、グループ別にオン／オフしたりすることができるよう、システムが構築されている。また、輝度を上下させる調光についても、手元から操作することができるように、システムが構築されている。
また、ブラウザを介して提供されるスマートパーム（商標登録出願中）には、例えば、フロア単位、グループ単位、及び、照明単位で、電気使用量を表示する機能が備えられている。このため、携帯情報端末を介して、対象の範囲での電気使用量がどの程度であるのかを確認できる。
＜＜設定とＱＲコード（登録商標）の生成＞＞
本実施形態のビル管理システム１０においては、一度設定された照明や空調（エアコン）のグループを、携帯情報端末において変更することが可能となっている。このようにすることにより、例えば、空調の工事業者や、システムの工事業者に、ビル内のテナントが休業している週末を利用してグループ変更の作業を実施してもらう、といったことが不要になる。
本実施形態のビル管理システム１０においては、一度設定された照明や空調（エアコン）のグループを、携帯情報端末において変更することが可能となっている。このようにすることにより、例えば、空調の工事業者や、システムの工事業者に、ビル内のテナントが休業している週末を利用してグループ変更の作業を実施してもらう、といったことが不要になる。
このような作業を行う際には、照明や空調（エアコン）を制御するために、例えば、設定管理用の一般利用者のグループにおいて、予め定められたグループ管理者にＱＲコード（登録商標）が配布される。ＱＲコード（登録商標）は、グループ管理者から、他のグループ員に配布される。グループは、設定が許容されるよう予め定め指定された範囲の一般利用者（ビル管理者や、その他の管理者が含まれていてもよい）により構成される。設定が許容される照明の範囲は、後述する照明のデザインツールを用いて行われる。
配布されたＱＲコード（登録商標）は、グループ員のＰＣに接続された表示装置や携帯情報端末等に表示される。ＱＲコード（登録商標）は、グループ員の他の携帯情報端末のカメラで読み取られ、ＵＲＬ等が表示される。ＵＲＬ等は、対応するアプリケーション・エッジ・デバイス６２に係る設定変更サイトにリンクしている。
グループ員が、ＵＲＬ等を選択すると、対応するアプリケーション・エッジ・デバイス６２に係る設定変更サイトが、グループ員の携帯情報端末に表示される。グループ員は、設定変更サイトにおいて、設定を変更したい設備機器の設定を操作する。
このようにすることで、一般利用者は、設定変更用のアプリケーションソフトをインストールすることなく、ブラウザを介して、照明やエアコンのグループ変更を行うことができる。
＜＜複数のプロジェクトを設定可能＞＞
携帯情報端末を介して設定された内容は、プロジェクトとして保存することが可能である。プロジェクトは、複数保存することが可能である。これにより、例えば、時間帯毎に設定を変えたり、平日と週末で、照明や空調のグループを変えたりすることが可能となる。このようにすることで、グループの変更のために、壁に新たにスイッチや操作盤を取り付ける必要がない。また、スイッチや操作盤に配線を繋げて壁内や床下等に引き回す工事を行う必要もない。さらに、工事業者に作業を依頼することなく、利用者が自社内で設定変更することが可能である。
携帯情報端末を介して設定された内容は、プロジェクトとして保存することが可能である。プロジェクトは、複数保存することが可能である。これにより、例えば、時間帯毎に設定を変えたり、平日と週末で、照明や空調のグループを変えたりすることが可能となる。このようにすることで、グループの変更のために、壁に新たにスイッチや操作盤を取り付ける必要がない。また、スイッチや操作盤に配線を繋げて壁内や床下等に引き回す工事を行う必要もない。さらに、工事業者に作業を依頼することなく、利用者が自社内で設定変更することが可能である。
＜＜照明のデザインツール＞＞
照明器具を設置するにあたっては、フロア内にどれくらいの機器を設置すればよいのか、設置した照明と電源をオン・オフするスイッチとの間のグループ化（グルーピング）をどのように行えばよいのか、といった事項が重要な焦点となる。過度に細かく設計してしまうと、制御が複雑になり、多くの制御用の機械が必要となる。逆に、過度に粗く設計してしまうと、例えば、人がいないところも照明が点灯するなどといった無駄が発生する。
照明器具を設置するにあたっては、フロア内にどれくらいの機器を設置すればよいのか、設置した照明と電源をオン・オフするスイッチとの間のグループ化（グルーピング）をどのように行えばよいのか、といった事項が重要な焦点となる。過度に細かく設計してしまうと、制御が複雑になり、多くの制御用の機械が必要となる。逆に、過度に粗く設計してしまうと、例えば、人がいないところも照明が点灯するなどといった無駄が発生する。
このため、本実施形態のビル管理システム１０では、アプリケーションソフトの１つとして、照明のデザインツールを開発している。照明のデザインツールは、例えば、ビル監視者が、アプリケーション・エッジ・デバイス６２（レベル２）に接続し、表示された照明のデザインツールのサイト内において、設計のための操作を行う。
＜プロダクティビティ・ツールの詳細＞
これまで、本実施形態に係るビル管理システム１０の全体像について説明した。以下では、前述したプロダクティビティ・ツールに焦点をあて、プロダクティビティ・ツールの開発に至った背景や、プロダクティビティ・ツールの詳細について説明する。
これまで、本実施形態に係るビル管理システム１０の全体像について説明した。以下では、前述したプロダクティビティ・ツールに焦点をあて、プロダクティビティ・ツールの開発に至った背景や、プロダクティビティ・ツールの詳細について説明する。
＜＜ビル管理システムの歴史＞＞
ビル管理システムの歴史は意外と古く、1950年代からその考え方はある。1980年代半ばからインテリジェントビルとして、コンピュータ制御のしくみが構築されてきたという経緯がある。
そうした歴史のある業界であるため、ビル管理システムを構築するための手順も伝統的に合理的なしくみが取られてきた。
ビル管理システムの対象となる範囲は、照明、空調、衛生、エネルギー、施設管理等がある。これらは、ビルの設計段階から、どの位置に配置され、どのような情報を収集し、どのように機能を持たせるかということが計画される。
それは、温度であれば、設定する最低温度はいくらで、最高温度はいくらとするか。さらに、どれくらいの刻みで通知するかという定義が行われる。
こうした細かな規定が、機器の種類ごとに決められている。
ビル管理システムの歴史は意外と古く、1950年代からその考え方はある。1980年代半ばからインテリジェントビルとして、コンピュータ制御のしくみが構築されてきたという経緯がある。
そうした歴史のある業界であるため、ビル管理システムを構築するための手順も伝統的に合理的なしくみが取られてきた。
ビル管理システムの対象となる範囲は、照明、空調、衛生、エネルギー、施設管理等がある。これらは、ビルの設計段階から、どの位置に配置され、どのような情報を収集し、どのように機能を持たせるかということが計画される。
それは、温度であれば、設定する最低温度はいくらで、最高温度はいくらとするか。さらに、どれくらいの刻みで通知するかという定義が行われる。
こうした細かな規定が、機器の種類ごとに決められている。
＜設計書の存在＞
ビル内で使用される機器類は、何が、何階の、どの位置に置かれ、その設定内容はどうであるかが、事細かく設計書に記述される。その設計書に基づいて、一つひとつの機器に対して設定を行うとともに、ビル管理システムへの登録も行われる。
当たり前のことであるが、大きなビルになればなるほど、設置される機器類も多くなり、設定される項目も多くなる。この設定作業は当然のことながら、一つひとつ手作業で行わなければならず、非常に手間がかかっていた。
プロダクティビティ・ツールが解決しようとしているのはまさにこの手間がかかるという部分にある。
ビル内で使用される機器類は、何が、何階の、どの位置に置かれ、その設定内容はどうであるかが、事細かく設計書に記述される。その設計書に基づいて、一つひとつの機器に対して設定を行うとともに、ビル管理システムへの登録も行われる。
当たり前のことであるが、大きなビルになればなるほど、設置される機器類も多くなり、設定される項目も多くなる。この設定作業は当然のことながら、一つひとつ手作業で行わなければならず、非常に手間がかかっていた。
プロダクティビティ・ツールが解決しようとしているのはまさにこの手間がかかるという部分にある。
＜プロコトルの違い＞
ビル管理システムにはもう一つの課題がある。それが機器類の相互接続の問題である。
ビル管理に使われている機器は様々あるが、機器同士を接続するにあたって、互いに通信するための取り決めがある。
従来、各機器メーカーは、自社のネットワークに接続するためのプロトコルを使用していたが、公開はしておらず、そのため、メーカーが異なると、互いに接続ができなかった。
この問題解決策の一つとして、オープン化の名のもとに、異なるメーカー製の機器類を、互いに接続することを目的としていくつものプロトコルが制定されてきた。代表的なものがModbus（商品名）やLonWorks（商品名）、BACnet （商品名）、である。
LonWorks は、アメリカのエシュロン（ECHELON社）が提供するオープン化を目指したネットワーク技術である。
BACnet は、ASHRAE（米国冷暖房空調工業会）が制定した規格をもとにして、国際標準規格として登録されたものである。
ビル管理システムにはもう一つの課題がある。それが機器類の相互接続の問題である。
ビル管理に使われている機器は様々あるが、機器同士を接続するにあたって、互いに通信するための取り決めがある。
従来、各機器メーカーは、自社のネットワークに接続するためのプロトコルを使用していたが、公開はしておらず、そのため、メーカーが異なると、互いに接続ができなかった。
この問題解決策の一つとして、オープン化の名のもとに、異なるメーカー製の機器類を、互いに接続することを目的としていくつものプロトコルが制定されてきた。代表的なものがModbus（商品名）やLonWorks（商品名）、BACnet （商品名）、である。
LonWorks は、アメリカのエシュロン（ECHELON社）が提供するオープン化を目指したネットワーク技術である。
BACnet は、ASHRAE（米国冷暖房空調工業会）が制定した規格をもとにして、国際標準規格として登録されたものである。
＜プロトコルが異なることの影響＞
相互接続を目指したオープン化であったが、その後も課題として残ったのが、オープン化といっても、自分たちの領域の中だけの限られた範囲でのオープン化であったことである。
つまり、LonWorks やBACnet のプロトコルを採用する機器類は、BACnet対応やLonWorks対応のビル管理システムでは管理できたが、LonWorks とBACnet が同時に混在するビル管理システムで使用することが難しかった。何が難しいかというと、プロトコルごとに属性がバラバラで、共通のデータを構成しないといけないが、これが大変であった。
たとえば、LonWorks とBACnet のプロトコルを持ったものを混在させると、両者間のデータの変換・取り扱いが難しく、トラブルが続出していた。さらに、シーケンサーやModbus も含めて統合的に処理しなければならなかった。
これらが混在しているのがビル管理システムの課題であった。
相互接続を目指したオープン化であったが、その後も課題として残ったのが、オープン化といっても、自分たちの領域の中だけの限られた範囲でのオープン化であったことである。
つまり、LonWorks やBACnet のプロトコルを採用する機器類は、BACnet対応やLonWorks対応のビル管理システムでは管理できたが、LonWorks とBACnet が同時に混在するビル管理システムで使用することが難しかった。何が難しいかというと、プロトコルごとに属性がバラバラで、共通のデータを構成しないといけないが、これが大変であった。
たとえば、LonWorks とBACnet のプロトコルを持ったものを混在させると、両者間のデータの変換・取り扱いが難しく、トラブルが続出していた。さらに、シーケンサーやModbus も含めて統合的に処理しなければならなかった。
これらが混在しているのがビル管理システムの課題であった。
＜＜設定の難しさ＞＞
＜＜＜ビル管理システムを作るときの難しさ＞＞＞
ビルの管理システムは、照明や空調、エネルギーといった、各種のセンサーから情報を得て、監視システム上で状態や過去のトレンドを表示したり、制御したりするシステムである。
センサーから上がってくるアナログ情報は、シーケンサーやアナログ／デジタル変換機能を備えたセンサーそのものを介してデジタル化され、上位システムに送出される。一つのセンサーから上がってくる情報を上位システムで受け取るにあたっては、そのセンサーの持つ、各情報に特有の名称を付与して、区別する必要がある。ここに、各種の設定を登録する必要性が生じている。
＜＜＜ビル管理システムを作るときの難しさ＞＞＞
ビルの管理システムは、照明や空調、エネルギーといった、各種のセンサーから情報を得て、監視システム上で状態や過去のトレンドを表示したり、制御したりするシステムである。
センサーから上がってくるアナログ情報は、シーケンサーやアナログ／デジタル変換機能を備えたセンサーそのものを介してデジタル化され、上位システムに送出される。一つのセンサーから上がってくる情報を上位システムで受け取るにあたっては、そのセンサーの持つ、各情報に特有の名称を付与して、区別する必要がある。ここに、各種の設定を登録する必要性が生じている。
＜＜＜プロトコルそのものの理解＞＞＞
従来、使用しているセンサーや上位機器の設定には、以下の課題があった。
（ａ）データは、プロトコルごとに構成しなければならない。
（ｂ）機器の特性やプロトコルの特性を理解しておかないといけなかった。
（ｃ）しかも、ものすごく複雑で、取り扱いも、理解することも難しかった。
（ｄ）理解しないで使用したり、そのルールを間違ったりすると、「動かない」という制約がある。
（ｅ）そのため、理解不足によるミスも多かった。
従来、使用しているセンサーや上位機器の設定には、以下の課題があった。
（ａ）データは、プロトコルごとに構成しなければならない。
（ｂ）機器の特性やプロトコルの特性を理解しておかないといけなかった。
（ｃ）しかも、ものすごく複雑で、取り扱いも、理解することも難しかった。
（ｄ）理解しないで使用したり、そのルールを間違ったりすると、「動かない」という制約がある。
（ｅ）そのため、理解不足によるミスも多かった。
＜＜＜専用ツールの存在＞＞＞
プロトコルごとに、設定するための専用のツールがあり、専用のツールは複数ある。さらにプラグインがあったりする。
例えば、LonWorks にはLonMaker というツールがあるが、LonMaker はLonWorks しか設定できない。
これを習得するのが大変であるし、プロトコルごとに一つずつ切り替えて使わなければならない。
プロトコルごとに、設定するための専用のツールがあり、専用のツールは複数ある。さらにプラグインがあったりする。
例えば、LonWorks にはLonMaker というツールがあるが、LonMaker はLonWorks しか設定できない。
これを習得するのが大変であるし、プロトコルごとに一つずつ切り替えて使わなければならない。
＜＜＜設定量の多さ＞＞＞
各プロトコルには多くの設定があり、それらに対しての設定を入れなければならなかった。
LonWorks のSNVT(Standard Network Variable Type)の構成は、219 もの設定項目がある。
設定は手作業であり、その設定の登録に相当の手間がかかっていた。BACnet にも同様に、設定項目が多数ある。
図５は、SNVT対応表の一例を示している。
各プロトコルには多くの設定があり、それらに対しての設定を入れなければならなかった。
LonWorks のSNVT(Standard Network Variable Type)の構成は、219 もの設定項目がある。
設定は手作業であり、その設定の登録に相当の手間がかかっていた。BACnet にも同様に、設定項目が多数ある。
図５は、SNVT対応表の一例を示している。
＜＜解決手段としての構造化体＞＞
＜＜＜実現するための手段＞＞＞
これらの課題や問題を解決するために、取り扱うデータを変換する機能として、構造化体を用意した。この部分が従来にない機能である。
ここで言う「構造化体」は、データストレージに配置される前に事前定義され、ある定められた構造となるように整形されたデータ（情報）のことである。
要は、ビル管理システム内で扱われるデータをもとにしたデータベースを構築し、ビル管理システムで統合的に使用できるようになっている。
＜＜＜実現するための手段＞＞＞
これらの課題や問題を解決するために、取り扱うデータを変換する機能として、構造化体を用意した。この部分が従来にない機能である。
ここで言う「構造化体」は、データストレージに配置される前に事前定義され、ある定められた構造となるように整形されたデータ（情報）のことである。
要は、ビル管理システム内で扱われるデータをもとにしたデータベースを構築し、ビル管理システムで統合的に使用できるようになっている。
＜＜＜様々なデータを受け入れるしくみ＞＞＞
具体的には、ビル内で使用される、照明、センサー、ゲートウェイ、コントローラー等、機器の種類毎にどの場所にデータを保存するかを定め、機器の設定をやりやすくした。また同時に、収集されるデータの取り扱いも容易にした。
LonWorks やBACnet といったプロトコル以外の様々なデータに対応できるようにするため、150 ものプロトコルも用意した。
このようにして、様々な情報を一元的に取り扱えるように整えた。
具体的には、ビル内で使用される、照明、センサー、ゲートウェイ、コントローラー等、機器の種類毎にどの場所にデータを保存するかを定め、機器の設定をやりやすくした。また同時に、収集されるデータの取り扱いも容易にした。
LonWorks やBACnet といったプロトコル以外の様々なデータに対応できるようにするため、150 ものプロトコルも用意した。
このようにして、様々な情報を一元的に取り扱えるように整えた。
＜＜＜データを登録するためのプロダクティビティ・ツール＞＞＞
その上で、各種プロトコルに対応し、様々な設定を入れるためのツールとして、前述したようにプロダクティビティ・ツールを用意した。
プロダクティビティ・ツールは、設定を容易にするためのツールである。
＜＜＜プロダクティビティ・ツールの特徴＞＞＞
プロダクティビティ・ツールの特徴は以下である。
（ａ）LonWorks もBACnet も一つのツールで登録できる。
（ｂ）ゲートウェイを使って、外側で変換をかけなくてもよい。
（ｃ）設定データを登録する時間が短くてすむ。
（ｄ）類似データの登録は、データの複写で行える。
その上で、各種プロトコルに対応し、様々な設定を入れるためのツールとして、前述したようにプロダクティビティ・ツールを用意した。
プロダクティビティ・ツールは、設定を容易にするためのツールである。
＜＜＜プロダクティビティ・ツールの特徴＞＞＞
プロダクティビティ・ツールの特徴は以下である。
（ａ）LonWorks もBACnet も一つのツールで登録できる。
（ｂ）ゲートウェイを使って、外側で変換をかけなくてもよい。
（ｃ）設定データを登録する時間が短くてすむ。
（ｄ）類似データの登録は、データの複写で行える。
＜＜＜構成図例＞＞＞
ここで、ビル管理システム（例えば、ビル管理システム１０）で使用される機器類とプロトコル、プロダクティビティ・ツールの関係図（図７（ｂ））を示す。
アプリケーション・エッジ・デバイス６２には、LonWorks やBACnet といった各種プロトコルを使用したゲートウェイやシーケンサー、センサー類が接続される。
なお、アプリケーション・エッジ・デバイス６２は、監視システムを表示する仕組みを有している。
ここで、ビル管理システム（例えば、ビル管理システム１０）で使用される機器類とプロトコル、プロダクティビティ・ツールの関係図（図７（ｂ））を示す。
アプリケーション・エッジ・デバイス６２には、LonWorks やBACnet といった各種プロトコルを使用したゲートウェイやシーケンサー、センサー類が接続される。
なお、アプリケーション・エッジ・デバイス６２は、監視システムを表示する仕組みを有している。
＜＜＜データベースの工夫＞＞＞
前述した問題を解決するために、一つには、データベースの持ち方を工夫した。具体的には、プロトコルの違いを、構造化体を介すことで解決した。その構造化体に合わせてデータを入れるデータベースを構築した。
そのデータベースは、アナログの入力と出力、デジタルの入力と出力、電力量の積算とカウンターの６種類に集約した。この中に、上限値、下限値等、200項目くらいの大きなデータベースがある。
前述した問題を解決するために、一つには、データベースの持ち方を工夫した。具体的には、プロトコルの違いを、構造化体を介すことで解決した。その構造化体に合わせてデータを入れるデータベースを構築した。
そのデータベースは、アナログの入力と出力、デジタルの入力と出力、電力量の積算とカウンターの６種類に集約した。この中に、上限値、下限値等、200項目くらいの大きなデータベースがある。
＜＜＜レジスターの紐付け＞＞＞
プロダクティビティ・ツールは、従来、手作業で設定しなければならなかったことを自動化する。たとえば、アプリケーション・エッジ・デバイス６２に関し、コントローラーのレジスターの紐付けを行う。
LonWorksのプロトコルで使用されているオブジェクトにはさまざまな情報が登録されている。例えば、 １秒おきに送られてくるものや、何秒毎、あるいは何分毎に送られてくる等といったルールが厳密に定義されている。それらの情報を読んで、決められた場所にデータを登録する。
プロダクティビティ・ツールは、従来、手作業で設定しなければならなかったことを自動化する。たとえば、アプリケーション・エッジ・デバイス６２に関し、コントローラーのレジスターの紐付けを行う。
LonWorksのプロトコルで使用されているオブジェクトにはさまざまな情報が登録されている。例えば、 １秒おきに送られてくるものや、何秒毎、あるいは何分毎に送られてくる等といったルールが厳密に定義されている。それらの情報を読んで、決められた場所にデータを登録する。
＜＜＜データマッピング＞＞＞
コントローラーにはレジスターがあり、その中のコードにオブジェクトの何番が使われるということが規定されている。このマッピングが最も重要である。
何番目のデータが欲しいとなると、そのレジスターを読みにいく。それを自動的に、WEB アクセスを使って、自分のデータベースにマッピングしている。
プロダクティビティ・ツールは、LonWorks やBACnet のデータをWEB アクセスにデータマッピングする際、そのアドレスを理解しなくてもよいようにした。
コントローラーにはレジスターがあり、その中のコードにオブジェクトの何番が使われるということが規定されている。このマッピングが最も重要である。
何番目のデータが欲しいとなると、そのレジスターを読みにいく。それを自動的に、WEB アクセスを使って、自分のデータベースにマッピングしている。
プロダクティビティ・ツールは、LonWorks やBACnet のデータをWEB アクセスにデータマッピングする際、そのアドレスを理解しなくてもよいようにした。
＜＜＜拡張性＞＞＞
新しく登場してくるビル管理用機器に対しては、プロダクティビティ・ツールでデータの登録ができるようにするため、REST（Representational State Transfer） とREST API （REST Application Programing Interface）のコマンド操作（例えば、ビル管理者が予め携帯情報端末２２を用いて行ったコマンド入力操作など）によって、コマンドの送出ができるように機能を付け足す。こうすることで、新製品の設定を容易にすることができる。
大事なのは、機器とのデータの受け渡しがコマンドで対応できるようにすることである。データの受け渡しができる主要なプロトコルは、Modbus、LonWorks、BACnet他、５種類ある。
新しく登場してくるビル管理用機器に対しては、プロダクティビティ・ツールでデータの登録ができるようにするため、REST（Representational State Transfer） とREST API （REST Application Programing Interface）のコマンド操作（例えば、ビル管理者が予め携帯情報端末２２を用いて行ったコマンド入力操作など）によって、コマンドの送出ができるように機能を付け足す。こうすることで、新製品の設定を容易にすることができる。
大事なのは、機器とのデータの受け渡しがコマンドで対応できるようにすることである。データの受け渡しができる主要なプロトコルは、Modbus、LonWorks、BACnet他、５種類ある。
図６（ａ）、（ｂ）、及び、図７（ａ）、（ｂ）は、本実施形態のビル管理システム１０におけるデータマッピングについて、従来例と比較できるように示している。
例えば、図６（ａ）に示すように従来は、SCADA（Supervisory Control And Data Acquisition）のレジスター上に各センサーから上がってきた情報を、プロトコルを介して、一つずつ手作業でアドレスを指定し、WEB アクセスにデータマッピングするようなことが行われていた。
これに対し、本実施形態に係るマッピングでは、図６（ｂ）に示すように、プロダクティビティ・ツールが、各種のプロトコルごとの構造化体（ここではModbus構造化体、LonWorks構造化体、BACnet構造化体など）のデータ変換を行い、統合化された構造体（ここではＮＷＣ構造化体、データベース）を作成する。そして、統合化された構造体は、SCADAへ渡すことができるよう、データ形式が整えられている。
例えば、図６（ａ）に示すように従来は、SCADA（Supervisory Control And Data Acquisition）のレジスター上に各センサーから上がってきた情報を、プロトコルを介して、一つずつ手作業でアドレスを指定し、WEB アクセスにデータマッピングするようなことが行われていた。
これに対し、本実施形態に係るマッピングでは、図６（ｂ）に示すように、プロダクティビティ・ツールが、各種のプロトコルごとの構造化体（ここではModbus構造化体、LonWorks構造化体、BACnet構造化体など）のデータ変換を行い、統合化された構造体（ここではＮＷＣ構造化体、データベース）を作成する。そして、統合化された構造体は、SCADAへ渡すことができるよう、データ形式が整えられている。
従来のビル管理システムは、例えば、図７（ａ）に示すように、各プロトコルを介して、各センサー類等の情報をSCADAに集め、画面表示させていた。
このため、各プロトコルを介した情報を、直接SCADAの項目に手作業でアドレスを指定し、マッピングを行わなければならなかった。
特に、接続されるすべての機器別に情報を登録する必要があり、この手作業での登録量が膨大なものになっていた。ここで、図７（ａ）の「ＨＭＩ」は、画面表示（Human Machine Interface）の略である。
これに対し、本実施形態に係るマッピングでは、図７（ｂ）に示すように、プロダクティビティ・ツールが、各種のプロトコルごとの構造化体（ここではModbus構造化体、LonWorks構造化体、BACnet構造化体など）を用いて、統合化された構造体（ここではＮＷＣ構造化体）を作成し、統合化された構造体を、上位のシステム（ここではSCADA）へ渡せるようにする。つまり、各プロトコルごとの構造化体にデータが登録され、その後、NMC構造化体に集約されて、構造化体がSCADAに渡されるため、アドレスを理解しなくてもよくなった。
したがって、データ登録を大幅に省力化することが可能となった。なお、データベースは、アプリケーション・エッジ・デバイス６２だけでなく、統合・エッジ・デバイス６４やエンタープライズ・エッジ・サーバー６６でも行うことが可能である。
このため、各プロトコルを介した情報を、直接SCADAの項目に手作業でアドレスを指定し、マッピングを行わなければならなかった。
特に、接続されるすべての機器別に情報を登録する必要があり、この手作業での登録量が膨大なものになっていた。ここで、図７（ａ）の「ＨＭＩ」は、画面表示（Human Machine Interface）の略である。
これに対し、本実施形態に係るマッピングでは、図７（ｂ）に示すように、プロダクティビティ・ツールが、各種のプロトコルごとの構造化体（ここではModbus構造化体、LonWorks構造化体、BACnet構造化体など）を用いて、統合化された構造体（ここではＮＷＣ構造化体）を作成し、統合化された構造体を、上位のシステム（ここではSCADA）へ渡せるようにする。つまり、各プロトコルごとの構造化体にデータが登録され、その後、NMC構造化体に集約されて、構造化体がSCADAに渡されるため、アドレスを理解しなくてもよくなった。
したがって、データ登録を大幅に省力化することが可能となった。なお、データベースは、アプリケーション・エッジ・デバイス６２だけでなく、統合・エッジ・デバイス６４やエンタープライズ・エッジ・サーバー６６でも行うことが可能である。
＜＜プロダクティビティ・ツールによる効果（見た目での効果）＞＞
もしプロダクティビティ・ツールがなかったらどうなるか。それは、設定作業にものすごい時間がかかるということが一つ。もう一つは、設定ミスが起きやすいため、エラーが発生する可能性が高くなる。
プロダクティビティ・ツールの特徴の一つは、いろんな構造体を理解していなくとも、マッピングできる点にある。これまでは、マッピングを行うときには、人が判断しないといけなかった。例えば、「スペース・テンプ（室内温度）」というと、それがいったい何の略なのかを覚えておかないといけなかった。プロダクティビティ・ツールにより、この問題が解消した。そして、設定をパターン化することで、プロトコルを深く理解しなくても設定ができるようにした。設定の難しさからの解放が可能となった。
さらに、手作業で一つ一つ入力しなくてもよいように、設定がテンプレート化された。フロアごとのコピー（データコピー）のように、一度設定したデータを、すべて書き換えたり追記したりせずに、利用できるようにした。そして、設定量の多さからの解放を図ることができた。
また、Modbus、LonWorks、BACnet等、例えば150種類ものプロトコルを用意した上で、設定データを構造化体として構築し、プロトコル間の相違を吸収することで、異なるプロトコル間での相互接続を可能にした（構造化体を介してプロトコルの違いの吸収）。
また、従来、手作業で設定しなければならなかった事項について、コントローラーのレジスターへの紐付けを自動的に行えるようになった（レジスターの紐付け）。手作業で設定しなければならなかった事項としては、例えば、処理のタイミングをどのように設定するかや、データの登録位置等がある。
また、データの読み出しにおいて、BACnetやLonWorks等のデータをWEBアクセスしてデータマッピングする際、それらのアドレスを理解しなくても読み出しができるようになった。これにより、従来はすべてのデータ設定をアナログ的作業により作らなければならなかったが、デジタル的な作業により処理することが可能となった。
これらのことをまとめると、本実施形態のビル管理システム１０については、以下のようなことがいえる。
（ａ）マルチベンダー下の一元管理システムを構築した。
（ｂ）BACnet もLonWorks も同じツールで設定できる。
（ｃ）プロトコルを詳しく知らなくても設定ができる。
（ｄ）150 ものプロトコルに対応している。
（ｅ）様々な設定をテンプレートとして持てる。
（ｆ）一度設定した内容を複写して利用することで、ゼロから設定しなくてもすむ。
（ｇ）属性を与えると画面ができ、ダッシュボードも１対１で作れるようになった。
（ｈ）設定作業が楽。
（ｉ）設定ミスで機能しないということが激減した。
（ｊ）従来は何日もかかっていた設定に要する時間が数時間で済む。
もしプロダクティビティ・ツールがなかったらどうなるか。それは、設定作業にものすごい時間がかかるということが一つ。もう一つは、設定ミスが起きやすいため、エラーが発生する可能性が高くなる。
プロダクティビティ・ツールの特徴の一つは、いろんな構造体を理解していなくとも、マッピングできる点にある。これまでは、マッピングを行うときには、人が判断しないといけなかった。例えば、「スペース・テンプ（室内温度）」というと、それがいったい何の略なのかを覚えておかないといけなかった。プロダクティビティ・ツールにより、この問題が解消した。そして、設定をパターン化することで、プロトコルを深く理解しなくても設定ができるようにした。設定の難しさからの解放が可能となった。
さらに、手作業で一つ一つ入力しなくてもよいように、設定がテンプレート化された。フロアごとのコピー（データコピー）のように、一度設定したデータを、すべて書き換えたり追記したりせずに、利用できるようにした。そして、設定量の多さからの解放を図ることができた。
また、Modbus、LonWorks、BACnet等、例えば150種類ものプロトコルを用意した上で、設定データを構造化体として構築し、プロトコル間の相違を吸収することで、異なるプロトコル間での相互接続を可能にした（構造化体を介してプロトコルの違いの吸収）。
また、従来、手作業で設定しなければならなかった事項について、コントローラーのレジスターへの紐付けを自動的に行えるようになった（レジスターの紐付け）。手作業で設定しなければならなかった事項としては、例えば、処理のタイミングをどのように設定するかや、データの登録位置等がある。
また、データの読み出しにおいて、BACnetやLonWorks等のデータをWEBアクセスしてデータマッピングする際、それらのアドレスを理解しなくても読み出しができるようになった。これにより、従来はすべてのデータ設定をアナログ的作業により作らなければならなかったが、デジタル的な作業により処理することが可能となった。
これらのことをまとめると、本実施形態のビル管理システム１０については、以下のようなことがいえる。
（ａ）マルチベンダー下の一元管理システムを構築した。
（ｂ）BACnet もLonWorks も同じツールで設定できる。
（ｃ）プロトコルを詳しく知らなくても設定ができる。
（ｄ）150 ものプロトコルに対応している。
（ｅ）様々な設定をテンプレートとして持てる。
（ｆ）一度設定した内容を複写して利用することで、ゼロから設定しなくてもすむ。
（ｇ）属性を与えると画面ができ、ダッシュボードも１対１で作れるようになった。
（ｈ）設定作業が楽。
（ｉ）設定ミスで機能しないということが激減した。
（ｊ）従来は何日もかかっていた設定に要する時間が数時間で済む。
＜＜その他の効果＞＞
プロダクティビティ・ツールは、見た目での効果としては上記のようなものが挙げられるが、一番大きな効果としては、複数のプロトコルを理解する必要性から解放されたことが挙げられる。
従来であれば、LonWorks のプロトコルを理解するのにも相当な時間を要した。それに加えて、BACnet や他のプロトコルを理解することが憚られることが多かった。
本発明により、この問題も解消した。
プロダクティビティ・ツールは、見た目での効果としては上記のようなものが挙げられるが、一番大きな効果としては、複数のプロトコルを理解する必要性から解放されたことが挙げられる。
従来であれば、LonWorks のプロトコルを理解するのにも相当な時間を要した。それに加えて、BACnet や他のプロトコルを理解することが憚られることが多かった。
本発明により、この問題も解消した。
＜＜＜エンジニアリング作業の改善＞＞＞
従来、ビル管理システムを構築しようとすると、要求仕様、設計、機器選定、ラダー作成等の中間の作業、動作確認、及び、納品・工事の作業（工程）が発生していた。
これに対して、プロダクティビティ・ツールを使用することで、ラダー作成等の中間の作業を行う必要がなくなった。
従来、ビル管理システムを構築しようとすると、要求仕様、設計、機器選定、ラダー作成等の中間の作業、動作確認、及び、納品・工事の作業（工程）が発生していた。
これに対して、プロダクティビティ・ツールを使用することで、ラダー作成等の中間の作業を行う必要がなくなった。
＜＜事例＞＞
あるビルのプロジェクトでは、パッケージエアコンを84台使用している。１台のパッケージエアコンには16 の監視ポイントがある。そうすると、合計で16点×84台＝1,344点のポイントを登録しないといけない。従来であれば、この1,344 のポイントを手作業で登録しており、その設定に何日もかかっていた。それに対し、プロダクティビティ・ツールを使えば、５分～１０分もあれば設定は終わってしまう。しかも、１つの設定を行い、それを複数作るといった作業は、とても早くできる。
あるビルのプロジェクトでは、パッケージエアコンを84台使用している。１台のパッケージエアコンには16 の監視ポイントがある。そうすると、合計で16点×84台＝1,344点のポイントを登録しないといけない。従来であれば、この1,344 のポイントを手作業で登録しており、その設定に何日もかかっていた。それに対し、プロダクティビティ・ツールを使えば、５分～１０分もあれば設定は終わってしまう。しかも、１つの設定を行い、それを複数作るといった作業は、とても早くできる。
監視対象のポイントの名称も、プロダクティビティ・ツールが自動付与する名前をそのまま使ってもよいならば、あっという間に設定は終わる。実際には、名称をわかりやすくするために、日本語で独自のものをつけることが多いため、この部分には、やや時間がかかる。それでも、この部分は、情報設定の付随部分でしかない。
重要なのは、機器そのものに付随する、センサーに定義をする情報の設定部分。プロダクティビティ・ツールは、この作業を簡便化する。
重要なのは、機器そのものに付随する、センサーに定義をする情報の設定部分。プロダクティビティ・ツールは、この作業を簡便化する。
＜＜アナログ作業のデジタル化＞＞
以上のように、プロダクティビティ・ツールは、これまでアナログ的に作業していたものをデジタル化した。このことが、プロダクティビティ・ツールを用いたこと大きな利点である。
以上のように、プロダクティビティ・ツールは、これまでアナログ的に作業していたものをデジタル化した。このことが、プロダクティビティ・ツールを用いたこと大きな利点である。
図８及び図９は、プロダクティビティ・ツールを用いた場合に表示される画面例を示している。これらの画面は、ビル管理者のＰＣに接続された表示装置や、携帯情報端末などに表示することが可能である。
図８（ａ）は、初期画面の一例を示している。プロダクティビティ・ツールを立ち上げると、図８（ａ）に示すような初期画面が表示される。
図８（ｂ）、図９（ａ）、（ｂ）は、テンプレートの作成を行う際の画面例を示している。プロダクティビティ・ツールは、設定を要するパラメーターをテンプレートとして持っており、必要に応じてテンプレートを呼び出して、登録できるようになっている。また、一度、設定したテンプレートを利用して、類似のパラメーターの設定を行うこともできるようになっている。
図８（ｂ）、図９（ａ）、（ｂ）は、各種のプロトコルや管理システムに対応したテンプレートの一例を示している。図８（ｂ）は、LonWorks（商品名）のためのテンプレートの一例を示しており、図９（ａ）は、BACnet （商品名）のためのテンプレートの一例を示している。図９（ｂ）は、SCADAのためのテンプレートの一例を示している。
プロダクティビティ・ツールは、設定を要するパラメーターをテンプレートとして持っており、必要に応じてテンプレートを呼び出して、登録するだけでよい（設定できる）ようになっている。また、一度、設定したテンプレートを利用して、類似のパラメーターの設定を行うこともできるようになっている。
なお、本実施形態に係るビル管理システム１０によって行われるビル管理の方法は、ビル管理方法として捉えることが可能である。また、ビル管理システム１０により実行されるコンピュータプログラムは、ビル管理プログラムとして捉えることが可能である。さらに、ビル管理システム１０は、ビル管理装置として捉えることが可能である。
＜実施形態から抽出可能な発明＞
これまでに説明したような実施形態から、以下のような発明を抽出することが可能である。
（１）複数の管理項目（空調、照明、衛生、警報、エネルギーなど）のいずれかに分類される複数種類の設備機器（エアコン、照明機器、扉、無線式センサー装置３０等のセンサー類、スイッチ類、その他の電気機器類など）と、
複数種類の検出項目（温度、湿度、照度、加速度、コンタクトなど）の検出が可能なセンサー装置（無線式センサー装置３０など）と、
昇順に上位層となる第１階層装置（マイクロ・エッジ・デバイス６０など）、第２階層装置（アプリケーション・エッジ・デバイス６２など）、第３階層装置（統合・エッジ・デバイス６４など）、第４階層装置（エンタープライズ・エッジ・サーバー６６など）のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
少なくとも１つの前記管理項目を１つの項目系として複数の項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）を定めることが可能であり、
複数の前記項目系が、少なくとも、空調系、照明系、警報系、及び、エネルギー系を含む、ビル管理システムであって、
前記センサー装置が複数備えられ、
複数の前記センサー装置が、
少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力可能であり、
複数の前記項目系に跨るセンサー装置群を構成し、
前記第１階層装置で共通仕様の通信規格に基づき統一化された情報が前記第２階層装置へ送出され、
前記第２階層装置が、
所定のアプリケーションソフトであるプロダクティビティ・ツールを用いて、予め定められた構造体として、前記第１階層装置からの前記情報をデータベース化することが可能な、ビル管理システム。
（２）前記第２階層装置は、前記第３階層装置が備えられていない場合には、
ユーザーの端末装置（携帯情報端末２２、２４など）から、少なくとも、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択し、
前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（１）に記載のビル管理システム。
（３）前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置は、前記第４階層装置が備えられていない場合には、
ユーザーの端末装置（携帯情報端末２２、２４など）から、少なくとも、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記第２階層装置に対し、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択して送出するよう要求し、
前記第２階層装置から前記共通通信規格により、前記公衆無線通信回線を介して送出された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（１）に記載のビル管理システム。
（４）前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置が複数備えられている場合には前記第４階層装置が備えられ、
前記第４階層装置は、
ユーザーの端末装置（携帯情報端末２２、２４など）から、少なくとも、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記第３階層装置を介して、前記第２階層装置に、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択して送信するよう要求し、
前記第３階層装置は、
前記第２階層装置から、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して送出された前記処理前情報を、前記第４階層装置に中継し、
前記第４階層装置は、
前記第３階層装置により中継された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（１）に記載のビル管理システム。
（５）上記（１）～（５）のビル管理システムで行われるビル管理方法。
（６）上記（１）～（５）の「ビル管理システム」を「ビル管理装置」に置き換えた発明。
これまでに説明したような実施形態から、以下のような発明を抽出することが可能である。
（１）複数の管理項目（空調、照明、衛生、警報、エネルギーなど）のいずれかに分類される複数種類の設備機器（エアコン、照明機器、扉、無線式センサー装置３０等のセンサー類、スイッチ類、その他の電気機器類など）と、
複数種類の検出項目（温度、湿度、照度、加速度、コンタクトなど）の検出が可能なセンサー装置（無線式センサー装置３０など）と、
昇順に上位層となる第１階層装置（マイクロ・エッジ・デバイス６０など）、第２階層装置（アプリケーション・エッジ・デバイス６２など）、第３階層装置（統合・エッジ・デバイス６４など）、第４階層装置（エンタープライズ・エッジ・サーバー６６など）のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
少なくとも１つの前記管理項目を１つの項目系として複数の項目系（空調関連系１２、照明・コンセント系１４、衛生・水回り系１６、状態・警報系１８、エネルギー系２０など）を定めることが可能であり、
複数の前記項目系が、少なくとも、空調系、照明系、警報系、及び、エネルギー系を含む、ビル管理システムであって、
前記センサー装置が複数備えられ、
複数の前記センサー装置が、
少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力可能であり、
複数の前記項目系に跨るセンサー装置群を構成し、
前記第１階層装置で共通仕様の通信規格に基づき統一化された情報が前記第２階層装置へ送出され、
前記第２階層装置が、
所定のアプリケーションソフトであるプロダクティビティ・ツールを用いて、予め定められた構造体として、前記第１階層装置からの前記情報をデータベース化することが可能な、ビル管理システム。
（２）前記第２階層装置は、前記第３階層装置が備えられていない場合には、
ユーザーの端末装置（携帯情報端末２２、２４など）から、少なくとも、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択し、
前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（１）に記載のビル管理システム。
（３）前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置は、前記第４階層装置が備えられていない場合には、
ユーザーの端末装置（携帯情報端末２２、２４など）から、少なくとも、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記第２階層装置に対し、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択して送出するよう要求し、
前記第２階層装置から前記共通通信規格により、前記公衆無線通信回線を介して送出された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（１）に記載のビル管理システム。
（４）前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置が複数備えられている場合には前記第４階層装置が備えられ、
前記第４階層装置は、
ユーザーの端末装置（携帯情報端末２２、２４など）から、少なくとも、公衆無線通信回線（インターネット回線６８など）を介して、特定の前記管理項目（空調など）に係る要求があると、前記第３階層装置を介して、前記第２階層装置に、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報（空調の温度、部屋の湿度の情報など）を選択して送信するよう要求し、
前記第３階層装置は、
前記第２階層装置から、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して送出された前記処理前情報を、前記第４階層装置に中継し、
前記第４階層装置は、
前記第３階層装置により中継された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報（携帯情報端末２２、２４の操作により空調の温度設定が可能な空調温度設定画面など）を、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、上記（１）に記載のビル管理システム。
（５）上記（１）～（５）のビル管理システムで行われるビル管理方法。
（６）上記（１）～（５）の「ビル管理システム」を「ビル管理装置」に置き換えた発明。
＜その他＞
当業者は、本発明の精神及び範囲から外れることなく、様々な変更、置換、及び修正をこれに加えることが可能であることを理解されたい。
当業者は、本発明の精神及び範囲から外れることなく、様々な変更、置換、及び修正をこれに加えることが可能であることを理解されたい。
１０ ：ビル管理システム
１２ ：空調関連系
１４ ：コンセント系
１６ ：水回り系
１８ ：警報系
２０ ：エネルギー系
２２、２４ ：携帯情報端末
３０ ：無線式センサー装置
６０ ：マイクロ・エッジ・デバイス
６０Ａ ：デバイス群
６２ ：アプリケーション・エッジ・デバイス
６４ ：統合・エッジ・デバイス
６６ ：エンタープライズ・エッジ・サーバー
１２ ：空調関連系
１４ ：コンセント系
１６ ：水回り系
１８ ：警報系
２０ ：エネルギー系
２２、２４ ：携帯情報端末
３０ ：無線式センサー装置
６０ ：マイクロ・エッジ・デバイス
６０Ａ ：デバイス群
６２ ：アプリケーション・エッジ・デバイス
６４ ：統合・エッジ・デバイス
６６ ：エンタープライズ・エッジ・サーバー
Claims (5)
- 複数の管理項目のいずれかに分類される複数種類の設備機器と、
複数種類の検出項目の検出が可能なセンサー装置と、
昇順に上位層となる第１階層装置、第２階層装置、第３階層装置、第４階層装置のうちの少なくとも前記第１階層装置、及び、前記第２階層装置と、を備え、
少なくとも１つの前記管理項目を１つの項目系として複数の項目系を定めることが可能であり、
複数の前記項目系が、少なくとも、空調系、照明系、警報系、及び、エネルギー系を含む、ビル管理システムであって、
前記センサー装置が複数備えられ、
複数の前記センサー装置が、
少なくとも１つの無線通信規格により前記第１階層装置に対してデジタル情報を出力可能であり、
複数の前記項目系に跨るセンサー装置群を構成し、
前記第１階層装置で共通仕様の通信規格である共通通信規格に基づき統一化された情報が前記第２階層装置へ送出され、
前記第２階層装置が、
所定のアプリケーションソフトであるプロダクティビティ・ツールを用いて、予め定められた構造体として、前記第１階層装置からの前記情報をデータベース化することが可能な、ビル管理システム。 - 前記設備機器には、前記センサー装置を含み、
前記第１階層装置は、前記設備機器に識別のためのＩＰアドレスを割り振り、
前記第２階層装置は、前記第１階層装置からの前記情報を、少なくとも前記ＩＰアドレス、及び、前記管理項目を含んでデータベース化する、請求項１に記載のビル管理システム。 - 前記第２階層装置は、前記第３階層装置が備えられていない場合には、
ユーザーの端末装置から、少なくとも、公衆無線通信回線を介して、特定の前記管理項目に係る要求があると、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報を選択し、
前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報を、前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、請求項１に記載のビル管理システム。 - 前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置は、前記第４階層装置が備えられていない場合には、
ユーザーの端末装置から、少なくとも、公衆無線通信回線を介して、特定の前記管理項目に係る要求があると、前記第２階層装置に対し、前記データベース化された情報から前記ユーザーへの応答に必要な処理前情報を選択して送出するよう要求し、
前記第２階層装置から前記共通通信規格により、前記公衆無線通信回線を介して送出された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報を、 前記共通通信規格により、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、請求項１に記載のビル管理システム。 - 前記第２階層装置が複数備えられている場合には、複数の前記第２階層装置に対して１つの前記第３階層装置が備えられ、
前記第３階層装置が複数備えられている場合には前記第４階層装置が備えられ、
前記第４階層装置は、
ユーザーの端末装置から、少なくとも、公衆無線通信回線を介して、特定の前記管理項目に係る要求があると、前記第３階層装置を介して、前記第２階層装置に、前記ユーザーへの応答に必要な処理前情報を選択して送信するよう要求し、
前記第３階層装置は、
前記第２階層装置から、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して送出された前記処理前情報を、前記第４階層装置に中継し、
前記第４階層装置は、
前記第３階層装置により中継された前記処理前情報に基づき、前記特定の前記管理項目についての情報である提供情報を、前記共通通信規格により、少なくとも、前記公衆無線通信回線を介して前記ユーザーの端末装置に提供する、請求項１に記載のビル管理システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2023040742A JP7788108B2 (ja) | 2023-03-15 | 2023-03-15 | ビル管理システム |
| JP2024166004A JP7663885B2 (ja) | 2023-03-15 | 2024-09-25 | ビル管理システム、及び、ビル管理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2023040742A JP7788108B2 (ja) | 2023-03-15 | 2023-03-15 | ビル管理システム |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2024166004A Division JP7663885B2 (ja) | 2023-03-15 | 2024-09-25 | ビル管理システム、及び、ビル管理方法 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2024130828A JP2024130828A (ja) | 2024-09-30 |
| JP2024130828A5 JP2024130828A5 (ja) | 2025-10-23 |
| JP7788108B2 true JP7788108B2 (ja) | 2025-12-18 |
Family
ID=92901321
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2023040742A Active JP7788108B2 (ja) | 2023-03-15 | 2023-03-15 | ビル管理システム |
| JP2024166004A Active JP7663885B2 (ja) | 2023-03-15 | 2024-09-25 | ビル管理システム、及び、ビル管理方法 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2024166004A Active JP7663885B2 (ja) | 2023-03-15 | 2024-09-25 | ビル管理システム、及び、ビル管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (2) | JP7788108B2 (ja) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003111170A (ja) | 2001-09-27 | 2003-04-11 | Toshiba Corp | 家電機器、家電サーバ装置及び中継装置 |
| JP2014528221A (ja) | 2011-10-06 | 2014-10-23 | ナブテスコ株式会社 | 自動ドアの遠隔管理システム |
| JP2015082783A (ja) | 2013-10-23 | 2015-04-27 | 三菱電機株式会社 | 機器制御システムおよび家電機器 |
| US20180278434A1 (en) | 2017-03-21 | 2018-09-27 | ODIN Building Automation Systems, LLC | System and method for remote monitoring and controlling of building automation devices |
| JP2020091744A (ja) | 2018-12-06 | 2020-06-11 | 東邦瓦斯株式会社 | 警報システム及び警報器 |
| JP2021196061A (ja) | 2020-06-09 | 2021-12-27 | グローバル電子株式会社 | 環境設備制御システム |
| JP2022117261A (ja) | 2021-01-29 | 2022-08-10 | 菱洋エレクトロ株式会社 | ＩｏＴシステム、及び、管理サーバ |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003134120A (ja) | 2001-10-24 | 2003-05-09 | Matsushita Electric Works Ltd | ネットワーク分散型ビル管理システム |
| JP2004157788A (ja) | 2002-11-06 | 2004-06-03 | Ntt Power & Building Facilities Inc | 建物性能総合評価システム及びその方法 |
| JP7249078B1 (ja) | 2022-11-30 | 2023-03-30 | 株式会社 ネットワーク・コーポレーション | ビル管理システム |
| JP7788107B2 (ja) | 2023-03-15 | 2025-12-18 | 株式会社 ネットワーク・コーポレーション | ビル管理システム |
-
2023
- 2023-03-15 JP JP2023040742A patent/JP7788108B2/ja active Active
-
2024
- 2024-09-25 JP JP2024166004A patent/JP7663885B2/ja active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003111170A (ja) | 2001-09-27 | 2003-04-11 | Toshiba Corp | 家電機器、家電サーバ装置及び中継装置 |
| JP2014528221A (ja) | 2011-10-06 | 2014-10-23 | ナブテスコ株式会社 | 自動ドアの遠隔管理システム |
| JP2015082783A (ja) | 2013-10-23 | 2015-04-27 | 三菱電機株式会社 | 機器制御システムおよび家電機器 |
| US20180278434A1 (en) | 2017-03-21 | 2018-09-27 | ODIN Building Automation Systems, LLC | System and method for remote monitoring and controlling of building automation devices |
| JP2020091744A (ja) | 2018-12-06 | 2020-06-11 | 東邦瓦斯株式会社 | 警報システム及び警報器 |
| JP2021196061A (ja) | 2020-06-09 | 2021-12-27 | グローバル電子株式会社 | 環境設備制御システム |
| JP2022117261A (ja) | 2021-01-29 | 2022-08-10 | 菱洋エレクトロ株式会社 | ＩｏＴシステム、及び、管理サーバ |
Also Published As
| Publication number | Publication date |
|---|---|
| JP7663885B2 (ja) | 2025-04-17 |
| JP2025016443A (ja) | 2025-02-04 |
| JP2024130828A (ja) | 2024-09-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP4292248B1 (en) | Cloud-based automation system, zone controller, building gateway, and associated processes that enable increased energy efficiency in buildings. | |
| Bhatt et al. | Design and development of wired building automation systems | |
| US8335593B2 (en) | Power-using device monitor | |
| US8645495B2 (en) | Facility maintenance and management system | |
| US7706928B1 (en) | Energy management system with security system interface | |
| US20110113360A1 (en) | Facility monitoring and control system interface | |
| EP2831680B1 (en) | System and method for grouping building automation objects for group communication within a building automation system | |
| US20130085719A1 (en) | Application-generated function block for data exchange between control programs and building automation objects | |
| CN105824303A (zh) | 一种基于物联网的分布式智能仪表控制系统及其方法 | |
| KR20130049254A (ko) | 쓰리디 모델링 기반의 지능형 빌딩통합 자동제어 및 에너지 목표관리 시스템 및 그 방법 | |
| Fütterer et al. | A multifunctional demonstration bench for advanced control research in buildings—monitoring, control, and interface system | |
| JP7748051B2 (ja) | ビル管理システム | |
| JP7788107B2 (ja) | ビル管理システム | |
| JP7262035B1 (ja) | ビル管理システム | |
| CN109801480A (zh) | 一种基于bim的智能楼层监控管理系统 | |
| JP7788108B2 (ja) | ビル管理システム | |
| JP7570609B1 (ja) | ビル管理設備構築支援システム | |
| JP7262036B1 (ja) | ビル管理システム | |
| Nuñez et al. | Tools for the Implementation of an Inmotic System in the Imperial Hotel in Santiago de Cuba, Cuba | |
| Kawasaki et al. | SUSTIE Core Engine: Efficient IoT Platform for Smart Facility Solutions with Gateway, Spatiotemporal Database, and Simulation Interface | |
| Blumstein et al. | Open software-architecture for building monitoring and control | |
| Sita et al. | Interfacing city resources management system with SIMATIC WINCC | |
| CN103645679A (zh) | 楼宇自动化系统 | |
| CN114490236A (zh) | 应用于机房设备监控系统管理的星形结构智能建模方法 | |
| While et al. | Challenges in developing a generic monitoring framework for pan European energy usage and environmental monitoring |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20251015 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20251015 |
|
| A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20251015 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20251127 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20251128 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 7788108 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |