JP2019519834A - 感知デバイスのローカライズためのシステム及び方法 - Google Patents

感知デバイスのローカライズためのシステム及び方法 Download PDF

Info

Publication number
JP2019519834A
JP2019519834A JP2018555279A JP2018555279A JP2019519834A JP 2019519834 A JP2019519834 A JP 2019519834A JP 2018555279 A JP2018555279 A JP 2018555279A JP 2018555279 A JP2018555279 A JP 2018555279A JP 2019519834 A JP2019519834 A JP 2019519834A
Authority
JP
Japan
Prior art keywords
module
devices
cloud
data
building server
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.)
Granted
Application number
JP2018555279A
Other languages
English (en)
Other versions
JP6868039B2 (ja
Inventor
ユルゲン マリオ ヴァンヘール
ユルゲン マリオ ヴァンヘール
フェムケ リフトヴート
フェムケ リフトヴート
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Signify Holding BV
Original Assignee
Signify Holding BV
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from PCT/EP2017/054317 external-priority patent/WO2017182181A1/en
Application filed by Signify Holding BV filed Critical Signify Holding BV
Publication of JP2019519834A publication Critical patent/JP2019519834A/ja
Application granted granted Critical
Publication of JP6868039B2 publication Critical patent/JP6868039B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H05—ELECTRIC TECHNIQUES NOT OTHERWISE PROVIDED FOR
    • H05B—ELECTRIC HEATING; ELECTRIC LIGHT SOURCES NOT OTHERWISE PROVIDED FOR; CIRCUIT ARRANGEMENTS FOR ELECTRIC LIGHT SOURCES, IN GENERAL
    • H05B47/00—Circuit arrangements for operating light sources in general, i.e. where the type of light source is not relevant
    • H05B47/10—Controlling the light source
    • H05B47/175—Controlling the light source by remote control
    • H05B47/19—Controlling the light source by remote control via wireless transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B17/00—Monitoring; Testing
    • H04B17/30—Monitoring; Testing of propagation channels
    • H04B17/309—Measuring or estimating channel quality parameters
    • H04B17/318—Received signal strength
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • H—ELECTRICITY
    • H05—ELECTRIC TECHNIQUES NOT OTHERWISE PROVIDED FOR
    • H05B—ELECTRIC HEATING; ELECTRIC LIGHT SOURCES NOT OTHERWISE PROVIDED FOR; CIRCUIT ARRANGEMENTS FOR ELECTRIC LIGHT SOURCES, IN GENERAL
    • H05B47/00—Circuit arrangements for operating light sources in general, i.e. where the type of light source is not relevant
    • H05B47/10—Controlling the light source
    • H05B47/105—Controlling the light source in response to determined parameters
    • H05B47/11—Controlling the light source in response to determined parameters by determining the brightness or colour temperature of ambient light
    • H—ELECTRICITY
    • H05—ELECTRIC TECHNIQUES NOT OTHERWISE PROVIDED FOR
    • H05B—ELECTRIC HEATING; ELECTRIC LIGHT SOURCES NOT OTHERWISE PROVIDED FOR; CIRCUIT ARRANGEMENTS FOR ELECTRIC LIGHT SOURCES, IN GENERAL
    • H05B47/00—Circuit arrangements for operating light sources in general, i.e. where the type of light source is not relevant
    • H05B47/10—Controlling the light source
    • H05B47/105—Controlling the light source in response to determined parameters
    • H05B47/115—Controlling the light source in response to determined parameters by determining the presence or movement of objects or living beings
    • H05B47/1965—
    • H—ELECTRICITY
    • H05—ELECTRIC TECHNIQUES NOT OTHERWISE PROVIDED FOR
    • H05B—ELECTRIC HEATING; ELECTRIC LIGHT SOURCES NOT OTHERWISE PROVIDED FOR; CIRCUIT ARRANGEMENTS FOR ELECTRIC LIGHT SOURCES, IN GENERAL
    • H05B47/00—Circuit arrangements for operating light sources in general, i.e. where the type of light source is not relevant
    • H05B47/10—Controlling the light source
    • H05B47/175—Controlling the light source by remote control
    • H05B47/19—Controlling the light source by remote control via wireless transmission
    • H05B47/195—Controlling the light source by remote control via wireless transmission the transmission using visible or infrared light
    • H—ELECTRICITY
    • H05—ELECTRIC TECHNIQUES NOT OTHERWISE PROVIDED FOR
    • H05B—ELECTRIC HEATING; ELECTRIC LIGHT SOURCES NOT OTHERWISE PROVIDED FOR; CIRCUIT ARRANGEMENTS FOR ELECTRIC LIGHT SOURCES, IN GENERAL
    • H05B47/00—Circuit arrangements for operating light sources in general, i.e. where the type of light source is not relevant
    • H05B47/20—Responsive to malfunctions or to light source life; for protection

Abstract

複数のシステムデバイスを含む物理的環境内のシステムデバイスのコミッショニングにおけるエラーを自動的に検出するシステム及び方法であって、（ｉ）複数のシステムデバイスの各々により、１つ以上の近隣のシステムデバイスから無線信号を受信するステップ（１３５２）と、（ｉｉ）複数のシステムデバイスの各々により、受信した無線信号の強度を決定するステップ（１３５４）と、（ｉｉｉ）インストーラー（６１０）から、物理的環境内で第１のシステムデバイスをコミッショニングする要求を受信するステップ（１３５６）であって、要求は、第１のシステムデバイスの意図する位置を含む、ステップと、（ｉｖ）第１のシステムデバイスの近隣の少なくとも１つのシステムデバイスから決定された無線信号強度、及びコミッショニング要求を受信するステップ（１３５８）であって、第１のシステムデバイスの近隣の少なくとも１つのシステムデバイスの位置は既知である、ステップと、（ｖ）近隣の少なくとも１つのシステムデバイスから受信した無線信号強度に少なくとも部分的に基づいて、第１のシステムデバイスが意図する位置に位置していないと判定するステップ（１３６０）と、（ｖｉ）第１のシステムデバイスが意図する位置に位置していないことをインストーラーにアラートするステップ（１３６２）と、を含む、システム及び方法が開示される。

Description

本発明は、全般的に、屋内空間又は屋外空間などの物理的環境の、クラウドベースの監視及び制御を対象とする。とりわけ、本明細書で開示される様々な発明システム、方法、及び装置は、物理的環境内の感知デバイスのローカライズ及びコミッショニングを改善することに関する。
屋内環境並びにリソース（例えば、機器の使用）の監視は、近年、エネルギー効率がコスト削減にとって極めて重要となってきているため、重要性が増してきており、様々な努力傾注分野における技術的進歩は、関連データをリアルタイムで収集及び処理することを可能にしている。しかしながら、これらの技術的進歩にもかかわらず、以下である程度詳細に述べるように、最新技術によって未だ十分に対処されていない、多数の障害（例えば、データの機密性及び拡張性の問題）が存在する。
様々な理由のために、屋内照明並びに屋外照明は、現在、従来の蛍光灯、ＨＩＤ、及び白熱灯から、半導体光源（例えば、発光ダイオード（light-emitting diode；ＬＥＤ））を組み込んだデジタル照明技術へと移行している。ＬＥＤ照明は、数ある利点のうちでも特に、可制御性、高いエネルギー変換及び光学効率、耐久性、並びに著しく低い運用コストの利点をもたらす。更には、より最近の制御可能ＬＥＤ技術の進歩は、劇場、オフィス、又は家庭の設定で使用するための様々な照明効果及びシーンを作り出すように、容易に制御されることが可能な、効率的かつ堅牢な様々なフルスペクトル照明光源をもたらしている。
照明技術と同様に、センサ技術の分野においても、急速な発展がもたらされている。これらの改良の結果として、センサは、より小さく、より安価になり、それゆえ、よりユビキタスになりつつある。それらは現在、様々な日常デバイス（例えば、光源ハウジング、カメラ、及び様々な他の小型機器）内に適合しているため、それらは、より単純な環境メトリック（例えば、自然照明、騒音、占有、温度、湿度）のみならず、リソース及び空間の使用、活動レベル、侵入、並びにムードなどの、様々なセンサタイプの協調的使用を必要とし得る、より複雑なメトリックも継続的に測定及び監視するために使用されている。
更には、無線通信、スマートモバイルデバイス、及びクラウドコンピューティングの分野における革新の交わりは、スマート環境に関する更に多くの可能性を生み出している。比類なき移動性及び計算能力、接続されている機器（例えば、モノのインターネット（Internet of Things））、ユビキタス接続されたセンサへのアクセス、並びにクラウドベースサービスの処理及び分析能力を有する、新世代のコンピューティングデバイスを使用して、現在、身近の環境及び遠隔の環境の双方から、ほぼリアルタイムでデータを収集及び処理することが可能である。より多くのデバイスが、公衆ネットワーク又はプライベートネットワーク（例えば、インターネット）に接続するばかりではなく、互いに接続及び通信することも可能であるため、物理的環境に関するデータが急増している。多くのタイプのデバイス内における、センサの急増及び統合により、現在では、デバイスが故障した場合、又はそのデバイスの寿命に近づいている場合、並びに、これらのデバイスを取り巻く環境条件についての数多くの情報が周知となる。そのようなデータは、絶え間なく生成されるため、好ましくない条件が是正されるか又は惨事が回避され得るように、タイムリーかつ有意義な方式で、そのデータを分析する必要性が、ますます増大している。しかしながら、以下で論じられるように、これらのスマート物理空間内の条件を監視及び操作することを追及する際に、回避される必要がある多くの落とし穴が存在する。
センサは、私的な人物又は人々の集団に関連付けられている部屋を含む、物理的建物の隅々から、データを収集しているため、収集されたデータは、個人、及びそれらの個人が関与しているアクティビティを特定することが可能な、スマートフォン又はタブレットからのセンシティブな画像データ又はデータである恐れがある。そのようなデータの収集及び処理は、データの機密性の問題を生じさせるものであり、この問題は、物理空間を監視するためのシステムの適切な機能の主眼となり得る。そのようなデータが、どの程度まで匿名化及び／又は集約化される必要があるか、生のデータ又は分析されたデータを誰が見ることになるか、特定の個人を識別することを回避するために、どのようにしてデータが提示されるか、データが、その発信元（例えば、生のデータを収集するセンサ）から、その送信先（例えば、クラウドベースのサーバ、又は個人のスマートフォン上のアプリ）に、どのようにして安全に送信されるかということは、慎重に考慮され、実施されることが必要である。空間及びリソースの使用を監視するための既存のシステムは、そのような問題に対処する包括的な方策を開発していない。
更には、物理空間から収集された、空間及びリソースの使用のデータは、エネルギー効率又は他の使用効率を結果として得ることが可能な洞察をもたらすために、正確にタイムスタンプされ、十分な粒度で収集され、タイムリーに処理される必要がある。例えば、適切にタイムスタンプされていない占有データは、会議室又は廊下などの空間が、いつ多用されているかということに関して、正確な情報をもたらし得ない。また、このデータを、分析のために適切なクラウドサーバに提供することが遅れると、例えば、人通りの多い領域の保守をタイムリーにスケジュールすることができなかったり、近い将来に（例えば、代替の廊下を提案して、人の流れを導くことによって）そのような空間のスケジューリングに良い影響を与えることができなかったりすることになる。この場合も、空間及びリソースの使用を監視するための既存のシステムは、そのような問題に対処する包括的な方策を開発していない。
大企業の本部として機能する建物などの広大なサイトでの、エネルギー及び／又は空間の使用を適切に管理するためには、多数の（及び、様々な）センサデバイスが、典型的には、基本データの生成を実行するために必要とされる。更には、そのような施設は、典型的には、多種多様な機器（例えば、プリンタ、スキャナ、照明デバイス）を有し、それらの使用を監視することはまた、エネルギー効率に関する有用な情報をもたらすであろう。これらのデバイスは全て、ローカルエリアネットワークなどのネットワークに接続することが可能であってもよいが、それらが生成するデータは、様々なフォーマットとなる可能性が高い。したがって、存在している全てのデバイスによって生成される情報を使用することになる、いずれのシステムも、これらのデバイスから入来するデータのフォーマットを、そのシステムによって使用される様々なデータ処理アプリケーションによって理解及び処理されることが可能な、１つ以上の共通フォーマットに変換することが可能である必要がある。同時に、そのような建物全体にわたるシステムは、様々なデバイスが、互いに、及びそのシステムとインタフェースすることを（例えば、新たな通信プロトコル又は新たなタイプのデバイスに対するサポートを追加することを容易にさせる、ＡＰＩを公開することによって）容易にさせる必要がある。また、空間及びリソースを監視するための、そのような建物又はサイト全体にわたるシステムは、それらの機能的複雑性が増大するにもかかわらず、そのようなシステム内の個々の構成要素のインストール及び更新は、途中のあらゆるステップで、高度に熟練したインストーラーの関与を必要とすることなく、比較的シームレスである必要がある。
更には、そのようなシステムは、そのシステムのいずれの部分にも負担をかけることなく、新たなデバイスを組み込む能力を有することが必要である。換言すれば、そのようなシステムは、ネットワーク帯域幅、インストール効率、及びデータ分析の観点から、デバイス及びユーザの数の増大、またその結果として、生成されるデータの量の増大に、無理なく適応することが可能であるべきという点で、拡張可能であることが必要である。また、最後に、そのような複雑なシステムは、著しいデータ損失を伴うことなく、エラーを管理することが可能である必要がある。換言すれば、それらは、ハードウェア又はソフトウェアに不具合が生じる場合に、データの損失を予測して最小限に抑えることが必要である。
そのようなシステムは、コミッショニング又はローカライズにおけるエラーなく、新たなデバイスを組み込む能力を有することが必要である。例えば、新たな照明器具、センサデバイス及び／又は他のデバイスがシステムに追加される場合、あり得るエラーの中でも特に、インストーラー(installer)は、誤って複数のデバイスをネットワークに一度に追加したり、間違ったデバイスをコミッショニング又はローカライズしたりする可能性がある。これらのエラーは、正すのに費用及び時間の両方がかかり得る。空間及び資源使用を管理するための既存のシステムは、コミッショニング又はローカライズにおけるこれらのエラーを適切に検出せず、防止しない。
更には、そのような環境の構成要素間の通信のセキュリティ、並びに、コマンド及び／又はセンサログデータの完全性及び／又は機密性を確保するために、その環境内の様々な構成要素及びエンティティが認証されるべきである。そのような認証は、多くの場合、トランスポート層で、例えば、ネットワークスタックのＴＣＰ又はＵＤＰで実施されるが、これは、異なるアプリケーション層プロトコルが確実に動作することを、その層が可能にするためである。トランスポート層の認証は、証明書などのクレデンシャルを使用して、又は、共有秘密（例えば、事前共有鍵）を使用する動作を実行することによって、実施されることが多い。例えば、ルート証明書が、１つの通信ピア上にインストールされてもよい。ルート証明書は、証明書チェーンを検証するために使用されてもよい。しかしながら、一部の場合には、このことは、公開鍵基盤（Public Key Infrastructure；「ＰＫＩ」）の確立及び維持管理を必要とし得る。ＰＫＩは、経済的にも、また必要とされる専門知識の点からも、コスト高となる傾向にある。
少なくとも上述の難題に対して、物理的環境を監視及び制御するための既存のシステムは、解決策を提供しない。以下で提示されるシステム、方法、及び装置は、これらの難題及び他の難題に対処するように考案された解決策を提供する。
本明細書では、様々な実施形態は、前セクションに記載されている問題に対処するために、物理的環境のクラウドベースの監視及び制御のためのシステム及び方法を対象とする。本セクションは、様々な実施形態に伴う、様々なシステム構成要素、そのような構成要素間の対話、及び様々なステップの基本的理解をもたらすために、これらの方法及びシステムのうちの一部の、簡略化された概要を提示する。この概要は、全ての発明実施形態の網羅的な概説として意図されているものではない。本セクションで説明されるシステム構成要素及び方法ステップは、必ずしも不可欠な構成要素又はステップではない。この概要セクションの目的は、以降の「発明を実施するための形態」への導入部として、より簡略化された形態で、様々な概念の概説を提示することである。
様々な実施形態は、複数のシステムデバイスを含む物理的環境内のシステムデバイスのコミッショニングにおけるエラーを自動的に検出する方法を開示する。本方法は、（ｉ）複数のシステムデバイスの各々により、１つ以上の近隣のシステムデバイスから無線信号を受信するステップと、（ｉｉ）複数のシステムデバイスの各々により、受信した無線信号の強度を決定するステップと、（ｉｉｉ）インストーラーから、物理的環境内で第１のシステムデバイスをコミッショニングする要求を受信するステップであって、要求は、第１のシステムデバイスの意図する位置(intended location)を含む、ステップと、（ｉｖ）第１のシステムデバイスの近隣の少なくとも１つのシステムデバイスから決定された無線信号強度、及びコミッショニング要求を受信するステップであって、第１のシステムデバイスの近隣の少なくとも１つのシステムデバイスの位置は既知である、ステップと、（ｖ）近隣の少なくとも１つのシステムデバイスから受信した無線信号強度に少なくとも部分的に基づいて、第１のシステムデバイスが意図する位置に位置していないと判定するステップ（１３６０）と、（ｖｉ）第１のシステムデバイスが意図する位置に位置していないことをインストーラーにアラートするステップと、を含んでもよい。様々な態様では、本方法は、意図する位置に位置するシステムデバイスのアイデンティティを含む提言(recommendation)をインストーラーに行うステップを含んでもよい。他の態様では、本方法は、意図する位置に位置するシステムデバイスを自動的にコミッショニングするステップを含んでもよい。様々な態様では、本方法は、複数のシステムデバイスの少なくともいくつかにより、物理的環境からローカライズ情報を受信するステップを含んでもよい。ローカライズ情報は、例えば、光レベル、占有情報、又は１つ以上の近隣のシステムデバイスからのメッセージング周波数(messaging frequency)であってもよい。
ある実施形態では、第１のシステムデバイスが意図する位置に位置していないと判定するステップは、（ｉ）複数の近隣のシステムデバイスから受信した無線信号強度を分析するステップと、（ｉｉ）これら無線信号強度に基づいて、複数の近隣のシステムデバイスのどのシステムデバイスが第１のシステムデバイスに最も近いか判定するステップとを含む。
様々な実施形態は、コミッショニングにおけるエラーを自動的に検出するためのシステムを開示する。本システムは、無線信号を送信するよう構成され、近隣のシステムデバイスから送信された無線信号を受信するよう構成される複数のシステムデバイスであって、当該システムは、受信した無線信号の強度を決定するよう構成される、複数のシステムデバイスと、物理的環境内で第１のシステムデバイスをコミッショニングする要求を送るよう構成されるコミッショニングデバイスであって、要求は、第１のシステムデバイスの意図する位置を含む、コミッショニングデバイスと、（ｉ）第１のシステムデバイスの近隣の少なくとも１つのシステムデバイスから決定された無線信号強度、及びコミッショニング要求を受信する、（ｉｉ）近隣の少なくとも１つのシステムデバイスから受信した無線信号強度に少なくとも部分的に基づいて、第１のシステムデバイスが意図する位置に位置していないと判定する、及び（ｉｉｉ）第１のシステムデバイスが意図する位置に位置していないというアラートをコミッショニングデバイスに送るよう構成されるコンピューティングクラウドと、を含んでもよい。様々な態様では、コンピューティングクラウドは、意図する位置に位置する正しいシステムデバイスのアイデンティティに関する提言をコミッショニングデバイスを介して行うよう構成され得る。様々な態様では、コンピューティングクラウドは、意図する位置に位置するシステムデバイスを自動的にコミッショニングするよう構成され得る。
他の実施形態は、本明細書で説明される方法のうちの１つ以上などの方法を実行するために、プロセッサによって実行可能な命令を記憶する、非一時的コンピュータ可読記憶媒体を含み得る。更に他の実施形態は、メモリと、本明細書で説明される方法のうちの１つ以上などの方法を実行するための、メモリ内に記憶されている命令を実行するように動作可能な１つ以上のプロセッサとを含む、システムを含み得る。
本開示の目的に関して本明細書で使用されるとき、用語「ＬＥＤ」は、任意の電界発光ダイオード、あるいは、電気信号に応答して放射線を生成すること、及び／又はフォトダイオードとして機能することが可能な、他のタイプのキャリア注入／接合ベースのシステムを含むように理解されるべきである。それゆえ、ＬＥＤという用語は、限定するものではないが、電流に応答して光を放出する様々な半導体ベースの構造体、発光ポリマー、有機発光ダイオード（organic light emitting diode；ＯＬＥＤ）、電界発光ストリップなどを含む。特に、ＬＥＤという用語は、赤外スペクトル、紫外スペクトル、及び（一般に、約４００ナノメートル〜約７００ナノメートルの放射波長を含む）可視スペクトルの様々な部分のうちの１つ以上で放射線を生成するように構成されてもよい、（半導体ダイオード及び有機発光ダイオードを含めた）全てのタイプの発光ダイオードを指す。ＬＥＤの一部の例としては、限定するものではないが、（以下で更に論じられる）様々なタイプの赤外ＬＥＤ、紫外ＬＥＤ、赤色ＬＥＤ、青色ＬＥＤ、緑色ＬＥＤ、黄色ＬＥＤ、アンバーＬＥＤ、橙色ＬＥＤ、及び白色ＬＥＤが挙げられる。また、ＬＥＤは、所与のスペクトルに関する様々な帯域幅（例えば、半値全幅、すなわちＦＷＨＭ）（例えば、狭帯域幅、広帯域幅）と、所与の一般的色分類内の様々な主波長とを有する放射線を生成するように、構成及び／又は制御されてもよい点も理解されたい。
例えば、本質的に白色光を生成するように構成されているＬＥＤ（例えば、白色ＬＥＤ）の一実装形態は、それぞれが異なる電界発光スペクトルを放出する、いくつものダイを含んでもよく、それらのスペクトルは組み合わされて、実質的な白色光を形成するように混合する。別の実装形態では、白色光ＬＥＤは、第１のスペクトルを有する電界発光を、異なる第２のスペクトルに変換する、蛍光体材料に関連付けられてもよい。この実装形態の一実施例では、比較的短い波長及び狭い帯域スペクトルを有する電界発光が、蛍光体材料を「ポンピング」すると、その蛍光体材料が、やや広いスペクトルを有する、より長い波長の放射線を放射する。
また、ＬＥＤという用語は、ＬＥＤの物理的及び／又は電気的パッケージのタイプを制限しない点も理解されたい。例えば、上述のように、ＬＥＤは、それぞれが異なる放射線スペクトルを放出するように構成された（例えば、個別に制御可能であってもよく、又は制御可能でなくてもよい）複数のダイを有する、単一の発光デバイスを指してもよい。また、ＬＥＤは、ＬＥＤ（例えば、何らかのタイプの白色ＬＥＤ）の一体部分として見なされる、蛍光体に関連付けられてもよい。一般に、ＬＥＤという用語は、パッケージ化ＬＥＤ、非パッケージ化ＬＥＤ、表面実装ＬＥＤ、チップオンボードＬＥＤ、Ｔ型パッケージ実装ＬＥＤ、放射状パッケージＬＥＤ、電力パッケージＬＥＤ、何らかのタイプの収容部及び／又は光学要素（例えば、拡散レンズ）を含むＬＥＤなどを指してもよい。
用語「光源」は、限定するものではないが、（上記で定義されたような１つ以上のＬＥＤを含む）ＬＥＤベースの光源を含めた、様々な放射源のうちの任意の１つ以上を指すことを理解されたい。所与の光源は、可視スペクトル内、可視スペクトル外、又は双方の組み合わせの電磁放射を生成するように構成されてもよい。それゆえ、用語「光」及び用語「放射線」は、本明細書では互換的に使用される。更には、光源は、一体化構成要素として、１つ以上のフィルタ（例えば、カラーフィルタ）、レンズ、又は他の光学構成要素を含み得る。また、光源は、限定するものではないが、指標、表示、及び／又は照明を含めた、様々な用途に関して構成されてもよい点も理解されたい。「照明源」は、内部空間又は外部空間を効果的に照明するための十分な強度を有する放射線を生成するように、特に構成されている光源である。この文脈では、「十分な強度」とは、アンビエント照明（すなわち、間接的に知覚され得る光であって、例えば、全体的又は部分的に、知覚される前に様々な介在表面のうちの１つ以上から反射され得る光）を供給するために十分な、空間又は環境内で生成される可視スペクトルにおける放射力を指す（多くの場合、放射力又は「光束」の点から、光源からの全ての方向での全光出力を表すために、単位「ルーメン」が採用される）。
用語「スペクトル」は、１つ以上の光源によって生成される放射線の、任意の１つ以上の周波数（又は、波長）を指すことを理解されたい。したがって、用語「スペクトル」は、可視範囲の周波数（又は、波長）のみならず、赤外、紫外、及び、電磁スペクトル全体の他の領域の周波数（又は、波長）も指す。また、所与のスペクトルは、比較的狭い帯域幅（例えば、本質的に少ない周波数成分又は波長成分を有するＦＷＨＭ）又は比較的広い帯域幅（様々な相対強度を有する、いくつかの周波数成分又は波長成分）を有し得る。また、所与のスペクトルは、２つ以上の他のスペクトルの混合（例えば、複数の光源からそれぞれ放出された放射線を混合すること）の結果であってもよい点も理解されたい。
本開示の目的上、用語「色」は、用語「スペクトル」と互換的に使用される。しかしながら、用語「色」は、一般に、観察者によって知覚可能な放射線の特性を主に指すために使用される（ただし、この使用法は、この用語の範囲を限定することを意図するものではない）。したがって、用語「異なる色」は、異なる波長成分及び／又は帯域幅を有する、複数のスペクトルを暗示的に指す。また、用語「色」は、白色光及び非白色光の双方に関連して使用されてもよい点も理解されたい。
用語「照明設備」及び用語「照明器具」は、特定のフォームファクタ、アセンブリ、若しくはパッケージでの、１つ以上の照明ユニットの実装又は構成を指すために、本明細書では互換的に使用される。用語「照明ユニット」は、本明細書では、同じタイプ又は異なるタイプの１つ以上の光源を含む装置を指すために使用される。所与の照明ユニットは、光源に関する様々な取り付け構成、エンクロージャ／ハウジングの様々な構成及び形状、並びに／又は電気的接続及び機械的接続の様々な構成のうちの、任意の１つを有し得る。更には、所与の照明ユニットは、オプションとして、光源の動作に関連する様々な他の構成要素（例えば、制御回路）に関連付けられて（例えば、含んで、結合されて、及び／又は一緒にパッケージ化されて）もよい。「ＬＥＤベースの照明ユニット」とは、上述のような１つ以上のＬＥＤベースの光源を、単独で、又は他の非ＬＥＤベースの光源と組み合わせて含む、照明ユニットを指す。「マルチチャネル」照明ユニットとは、それぞれが異なる放射線スペクトルを生成するように構成された、少なくとも２つの光源を含む、ＬＥＤベース又は非ＬＥＤベースの照明ユニットを指し、異なる光源スペクトルのそれぞれが、そのマルチチャネル照明ユニットの「チャネル」と称されてもよい。
用語「コントローラ」は、本明細書では全般的に、１つ以上の光源の操作に関連する、様々な装置を説明するために使用される。コントローラは、本明細書で論じられる様々な機能を実行するように、数多くの方式で（例えば、専用ハードウェアなどを使用して）実装されることができる。「プロセッサ」は、本明細書で論じられる様々な機能を実行するように、ソフトウェア（例えば、マイクロコード）を使用してプログラムされてもよい、１つ以上のマイクロプロセッサを採用する、コントローラの一例である。コントローラは、プロセッサを採用して、又はプロセッサを採用せずに実装されてもよく、また、一部の機能を実行するための専用ハードウェアと他の機能を実行するためのプロセッサ（例えば、１つ以上のプログラムされたマイクロプロセッサ、及び関連回路）との組み合わせとして実装されてもよい。本開示の様々な実施形態で採用されてもよいコントローラ構成要素の例としては、限定するものではないが、従来のマイクロプロセッサ、特定用途向け集積回路（application specific integrated circuit；ＡＳＩＣ）、及びフィールドプログラマブルゲートアレイ（field-programmable gate array；ＦＰＧＡ）が挙げられる。
様々な実装形態では、プロセッサ又はコントローラは、１つ以上の記憶媒体（本明細書では「メモリ」と総称される、例えば、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、及びＥＥＰＲＯＭなどの、揮発性及び不揮発性のコンピュータメモリ、フロッピーディスク、コンパクトディスク、光ディスク、磁気テープなど）に関連付けられてもよい。一部の実装形態では、これらの記憶媒体は、１つ以上のプロセッサ及び／又はコントローラ上で実行されると、本明細書で論じられる機能の少なくとも一部を実行する、１つ以上のプログラムでエンコードされてもよい。様々な記憶媒体は、プロセッサ又はコントローラ内に固定されてもよく、あるいは、それらの記憶媒体上に記憶されている１つ以上のプログラムが、本明細書で論じられる本発明の様々な態様を実施するために、プロセッサ又はコントローラ内にロードされることができるように、可搬性であってもよい。用語「プログラム」又は用語「コンピュータプログラム」は、本明細書では、１つ以上のプロセッサ又はコントローラをプログラムするために採用されることが可能な、任意のタイプのコンピュータコード（例えば、ソフトウェア又はマイクロコード）を指すように、一般的な意味で使用される。
１つのネットワーク実装では、ネットワークに結合された１つ以上のデバイスは、そのネットワークに結合された１つ以上の他のデバイスに対するコントローラとして（例えば、マスタ／スレーブの関係で）機能し得る。別の実装形態では、ネットワーク化された環境は、そのネットワークに結合されたデバイスのうちの１つ以上を制御するようにコンフィギュレーションされている、１つ以上の専用コントローラを含み得る。一般に、ネットワークに結合された複数のデバイスは、それぞれが、通信媒体上に存在しているデータへのアクセスを有し得るが、しかしながら、所与のデバイスは、例えば、そのデバイスに割り当てられている１つ以上の特定の識別子（例えば、「アドレス」）に基づいて、ネットワークと選択的にデータを交換する（すなわち、ネットワークからデータを受信する、及び／又はネットワークにデータを送信する）ようにコンフィギュレーションされているという点で、「アドレス可能」であってもよい。
用語「ネットワーク」とは、本明細書で使用されるとき、任意の２つ以上のデバイス間での、及び／又はネットワークに結合された複数のデバイスの間での、（例えば、デバイス制御、データ記憶、データ交換などに関する）情報の転送を容易にする、（コントローラ又はプロセッサを含む）２つ以上のデバイスの任意の相互接続を指す。容易に理解されるように、複数のデバイスを相互接続するために好適なネットワークの様々な実装は、様々なネットワークトポロジのうちのいずれかを含み、様々な通信プロトコルのうちのいずれかを採用してもよい。更には、本開示による様々なネットワークでは、２つのデバイス間の任意の１つの接続は、それら２つのシステム間の専用接続、又は代替的に、非専用接続を表してもよい。２つのデバイスを対象とする情報の搬送に加えて、そのような非専用接続は、それら２つのデバイスのいずれかを必ずしも対象としない情報を搬送してもよい（例えば、オープンネットワーク接続）。更には、本明細書で論じられるデバイスの様々なネットワークは、そのネットワーク全体にわたる情報転送を容易にするために、１つ以上の無線リンク、有線／ケーブルリンク、及び／又は光ファイバリンクを採用してもよい点が、容易に理解されよう。本明細書で使用されるとき、通信可能に結合されるという語句は、仲介エンティティ（例えば、他のデバイス又はネットワーク）を介して、直接又は間接的に、互いに通信することが可能な、２つのデバイス又は他のエンティティを指す。通信可能に結合されるために、２つ以上のデバイスは、専用接続を有する必要はない。それらは、単に、必要に応じて互いからデータを送信及び／又は受信することが可能であるべきである。
用語「ユーザ」とは、本明細書で使用されるとき、本明細書で説明されるシステム及び方法と対話する、任意のエンティティ、人間、又は人工物を指す。例えば、この用語は、限定するものではないが、内勤者又は訪問者などのある空間の占有者、ある空間のリモートユーザ、施設管理者、コミッショニング技術者、建物ＩＴ管理者、サービス技術者、及びインストーラーを含む。
用語「モジュール」又は用語「アプリケーションモジュール」は、本明細書の構成要素を説明するために頻繁に使用される。これらの用語は、ソフトウェア構成要素若しくはファームウェア構成要素、又はそれらの組み合わせを対象としている。単一のソフトウェア／ファームウェアモジュールは、１つ以上のモジュールで構成されてもよい。１つ以上のデバイス上にそれぞれが存在する、１つ以上のプロセッサ上で、１つのソフトウェアモジュール全体が実行されてもよい。同じモジュール（例えば、フロントエンド）の１つ以上の構成要素は、１つのデバイス上で実行又は他の方式で表示されてもよく、そのデバイスは、同じモジュールの他の構成要素を実行又は表示している、別のデバイスからリモートであってもよい。単一のソフトウェアモジュールは、１つ以上のルーチン又は関数を含み得る。ソフトウェアモジュールは、他のモジュールによって使用可能なＡＰＩを公開してもよい。これらの用語は、実行されていないコンピュータコード及び実行中のコード（例えば、「実行時」モジュール）の双方を表現するために使用される。
用語「システムデバイス」は、本明細書の全体にわたって使用される。様々な実例では、その用語は、ゲートウェイ（無線又は他の方式）又は建物サーバなどのデバイスを意味し得る。その用語はまた、センサ、照明デバイス（例えば、照明器具、個別光源）、ＨＶＡＣデバイス（例えば、暖房用デバイス、加湿器、空調機）、電化製品（例えば、スマートボード、冷蔵庫、清掃用機器、食器洗浄機、衣類洗濯機／乾燥機、テレビ）、コンピューティング／通信デバイス（例えば、ルータ、スマートフォン、タブレットコンピュータ）、及び様々な他の感知デバイス又は発光デバイスなどの、物理的環境内で使用される他のデバイスにも適用される。
本明細書で説明される図のうちの多くでは、標識された矢印は、モジュール間の通信（例えば、モジュール−モジュール通信）、デバイス間の通信（例えば、デバイス−デバイス通信）、又は、それらの何らかの組み合わせ（例えば、デバイス−モジュール通信）を表現するために使用される。モジュール−モジュール通信は、例えば、クラウド内のシステムアプリケーションモジュールと建物サーバ内のモジュールとの間、又は建物サーバ内のモジュールと無線ゲートウェイ内の別のモジュールとの間であってもよい。矢印が表す通信のタイプに応じて、その通信は、関数コール又は他のプロセス間通信メカニズムを伴い得る。そのような通信は、一方のモジュール又はデバイスが、コマンド又は他の信号を発行して、アクション又は応答をモジュール又はデバイスから直接呼び出すことによって（例えば、データベースの更新などの行為をモジュールに実行させる結果をもたらす、モジュールに関するＡＰＩを呼び出すことによって）、直接遂行されてもよい。そのような通信はまた、一方のモジュールが、待ち行列又は他のメモリを更新して、別のモジュールが、そのモジュールに何らかの後の時点でアクセスして、その第２のモジュールが、更新された情報を使用することによってアクションを生じさせるなどのように、間接的又は非同期的に遂行されてもよい。様々な通信プロトコル（例えば、ＨＴＴＰＳ及びＭＱＴＴ）が、様々なモジュール及びデバイス間で情報を通信又は交換するために使用されてもよい。例えば、ＨＴＴＰＳは、例えば、建物サーバ内のモジュールとゲートウェイ内の別のモジュールとの間、又は建物サーバとクラウドとの間の、通信プロトコルとして言及される場合がある。しかしながら、データの交換を示す目的のためのＨＴＴＰ及びＭＱＴＴの使用は、限定として見なされるべきではなく、他の通信プロトコル及び技術もまた適用されてもよい。
上述の概念と、以下でより詳細に論じられる追加的概念との全ての組み合わせは（そのような概念が互いに矛盾しないという条件下で）、本明細書で開示される発明の主題の一部であると想到される点を理解されたい。特に、本開示の最後に現れる特許請求される主題の全ての組み合わせは、本明細書で開示される発明の主題の一部であると想到される。また、参照により組み込まれるいずれかの開示にもまた現れ得る、本明細書で明示的に採用されている用語は、本明細書で開示される特定の概念と最も一致する意味が与えられるべきであることも理解されたい。
図面中、同様の参照文字は、一般に、異なる図の全体にわたって同じ部分を指す。また、これらの図面は、必ずしも正しい縮尺ではなく、その代わりに、全般的に、本発明の原理を例示することに重点が置かれている。
物理的環境のクラウドベースの監視及び制御のためのシステムの一実施形態のブロック図を示し、この実施形態は、いくつかのクラウドベースのモジュールと、監視されている環境内に配置された、いくつかのモジュール及びデバイスとを備える。 監視空間に関連付けられた情報の流れを管理するデータプラットフォーム内への、様々なソースからの例示的なデータフローを示す。 物理的環境のクラウドベースの監視及び制御のためのシステムの一実施形態によって利用される、データ記憶及び操作システムの一実施形態を示す。 物理的環境のクラウドベースの監視及び制御のためのシステムの一実施形態内で使用するためのデバイスを、コミッショニングする方法の一実施形態を示す。 物理的環境のクラウドベースの監視及び制御のためのシステムにおける、デバイスのローカライズの様々な実施形態を示す。 物理的環境のクラウドベースの監視及び制御のためのシステムにおける、デバイスのローカライズの様々な実施形態を示す。 物理的環境のクラウドベースの監視及び制御のためのシステムにおける、デバイスのローカライズの様々な実施形態を示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムによって利用されてもよい、様々な照明アプリケーションの対話の一実施形態を示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムの、特定の展開の実施形態のブロック図を示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムの、特定の展開の実施形態のブロック図を示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムの、特定の展開の実施形態のブロック図を示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムに、建物サーバを登録及び接続する方法の一実施形態を示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムに、建物サーバを登録及び接続する方法の一実施形態を示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムにおいて、感知デバイスなどのシステムデバイスの、ソフトウェア又はファームウェアを更新する方法の一実施形態を示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムにおいて、建物サーバをローカライズする方法の実施形態を示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムにおいて、建物サーバをローカライズする方法の実施形態を示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムにおいて、ゲートウェイデバイスをローカライズする方法の一実施形態を示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムにおいて、感知デバイスなどのシステムデバイスをローカライズする方法の実施形態を示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムにおいて、コミッショニングシステムデバイスにおけるエラーを検出するためのシステムの実施形態を示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムにおいて、コミッショニングシステムデバイスにおけるエラーを検出するための方法のフローチャートを示す。 物理的環境を監視及び制御するための例示的なクラウドベースのシステムにおけるシステムデバイスの配置の実施形態を示す。
ここで、実施例が添付図面に示されている、本発明の例示的実施形態を詳細に参照する。
以下の発明を実施するための形態では、特定の詳細を開示している代表的実施形態が、限定ではなく説明目的で、本教示の完全な理解をもたらすために記載されている。しかしながら、本開示の利益を享受した当業者には、本明細書で開示されている特定の詳細から逸脱する、本教示による他の実施形態が、添付の請求項の範囲内に留まる点が明らかとなるであろう。更には、周知のシステム、装置、及び方法の説明は、代表的実施形態の説明を不明瞭にすることがないように、省略される場合がある。そのようなシステム、方法、及び装置は、明らかに本教示の範囲内にある。
システムアーキテクチャ全体の特徴を示す実施形態
図１は、物理的環境のクラウドベースの監視及び制御のための、システム１００Ａを示す。このシステムは、建物サーバ１００、ゲートウェイ１１０Ａ及びゲートウェイ１１０Ｂ、システムデバイス１０１〜１０６、コンピューティングクラウド１１５、システムエネルギーアプリケーションモジュール１２０、システムインテークアプリケーションモジュール１３０、システムプロジェクトアプリケーションモジュール１４０、ユーザ管理アプリケーションモジュール１５０、システムマップアプリケーションモジュール１６０、プロジェクトデータベース１７０Ａ、データデータベース１７０Ｂ、データプラットフォームモジュール１８０、及びクラウド接続性モジュール１９０を含む。システム１００Ａの他の実施形態は、追加的な、又はより少ない、建物サーバ、ゲートウェイ、システムデバイス、クラウド、データベースモジュール、クラウド接続性モジュール、及びデータプラットフォームを含み得る。システム１００Ａの様々な構成要素は、図１に示されるリンク線を使用して、通信可能にリンクされている。しかしながら、図中の２つのブロック又はモジュール間のリンク線の欠如は、必ずしも、それらブロック又はモジュール間の通信能力の欠如を示すものではない。用語「物理的構造」又は用語「物理的環境」は、本明細書で使用されるとき、自立しているか、恒久的であるか、包囲されているか、又は覆われているか否かにかかわらず、任意の建物構造体を指す。この用語は、例えば、オフィス用、住宅用、娯楽用、教育用、行政用、及び商業用の建物及び複合施設、並びに駐車場及び車庫を含む。用語「リンク」は、本明細書で使用されるとき、少なくとも２つのデバイス又はシステム構成要素間での情報の通信を可能にする、物理的又は仮想的な、任意の接続又は構成要素を指す。例えば、リンクは、有線又は無線の通信接続、無線周波数通信接続、及び光通信接続を含む。リンクはまた、共有通信プロトコル、ソフトウェア若しくはハードウェアインタフェース、又はリモートメソッド呼び出し若しくはリモートプロシージャコールも示し得る。
クラウド１１５は、クラウドコンピューティングに関して使用される典型的なクラウドである。クラウドは、そのクラウドへのアクセスを有する様々なデバイスに、共有データ及び処理リソースを提供する。クラウドは、ネットワーク、サーバ、ストレージ、アプリケーション、及びサービスなどのコンピューティングリソースの共有プールへの、オンデマンドのアクセスを可能にする。クラウド１１５は、システムエネルギーアプリケーションモジュール１２０、システムインテークアプリケーションモジュール１３０、システムプロジェクトアプリケーションモジュール１４０、ユーザ管理アプリケーションモジュール１５０、システムマップアプリケーションモジュール１６０を含めた、システム１００Ａに関する様々なクラウドベースのアプリケーションをサポートする。これらのアプリケーション及びクラウドインフラストラクチャは、システム１００Ａの２つの重要な態様を提供する。第１に、特定の建物又は建物群内に、システム１００Ａのようなシステムをインストールすることを担当する、インストーラーは、専門的な訓練を必要としない。第２に、監視及び制御されている物理的環境内での、システムデバイス及びリソースの所望の挙動が、クラウド自体の中に記憶されることにより、容易にコンフィギュレーション可能であり、ダウンロード可能である。
システムエネルギーアプリケーションモジュール１２０は、エネルギー管理に関連する報告を検討するために、又はエネルギー管理に関連する様々なタスクを実行するために、システム１００Ａの一般エンドユーザによって、又はシステム１００Ａの特殊専門ユーザ（例えば、施設管理者）によって使用されてもよい、クラウドベースのソフトウェアアプリケーションである。例えば、施設管理者は、特定の月曜日が、平均的な月曜日と比較された場合に、有意に高いエネルギー消費量を有していたか否かを判定するために、特定の週の１日平均消費量をチェックすること、又は、エネルギー使用量の季節変化を判定するために、過去１年の月間エネルギー消費量についてのデータを検討することを望み得る。それゆえ、システムエネルギーアプリケーションモジュール１２０は、いずれのタイプの情報が提示されることをユーザが見たいかについての情報を収集する目的で、並びに、グラフィック（例えば、棒グラフ、ヒートマップ）形態又は生の形態で必要情報を提示する目的で、本質的に対話型であってもよいユーザインタフェースを、そのユーザに提示することが可能である。このアプリケーションモジュールは、データデータベース１７０Ｂ内に記憶されているエネルギー消費量データを使用して、単独で、又は、クラウド１１５の内部若しくは外部の分析モジュールを使用することによって、分析を実行してもよい。システムエネルギーアプリケーションモジュール１２０は、図６に関連付けられている説明で、より詳細に論じられる。
システムインテークアプリケーションモジュール１３０は、システム１００Ａによって管理される１つ以上の物理的構造に関する、照明及び／又は他のエネルギーの必要性を決定及び／又は確立するために、インテーク技術者（以降では、「インテーカー」）によって、又はシステム１００Ａの他の専門ユーザによって使用されてもよい、クラウドベースのソフトウェアアプリケーションである。システムインテークアプリケーションモジュール１３０によって提供されるユーザインタフェースを少なくとも使用して、インテーカーは、アプリケーションモジュール１３０によって提示されるマップビューから、１つ以上の建物を選択することができる。このインテークは更に、アプリケーションモジュール１３０を使用して、選択された建物の特定のフロアの既存のフロアプランをロードして、続いて、特別な領域（例えば、オープンプラン式のオフィス空間、会議室）及び、これらの空間内で使用するためのシステムデバイス（例えば、光源、光源グリッド、ゲートウェイ、スイッチ）を確立すると共に、それらの空間及びデバイスに関連付けられる様々な注釈（例えば、メモ、写真、音声記録）を提供することができる。システムインテークアプリケーションモジュール１３０はまた、例えば、照明器具／光源が、指定領域に適切に割り当てられると共に、対応のゲートウェイに適切に割り当てられることを確認するために、インテーカーがインテークプロセスをチェックすることも可能にする。システムインテークアプリケーションモジュール１３０からのこの情報は、その後、プロジェクトデータベース１７０Ａに入力するために使用されてもよい。システムインテークアプリケーションモジュール１３０は、図６に関連付けられている説明で、より詳細に論じられる。
システムプロジェクトアプリケーションモジュール１４０は、プロジェクトデータベース１７０Ａ内に記憶されているプロジェクト階層を作成し、見るために、システム１００Ａに関連付けられるインテーカー、専門家、インストーラー、管理者、及びエンドユーザによって使用されてもよい、クラウドベースのソフトウェアアプリケーションである。アプリケーションモジュール１４０はまた、作成及び更新されたプロジェクトを、システムマップアプリケーションモジュール１６０、システムエネルギーアプリケーションモジュール１２０、又はシステムインテークアプリケーションモジュール１３０などの、他のアプリケーションモジュールにも発送する。プロジェクト階層は、例えば、管理者などの適切な権限を有するユーザに、プロジェクトに関連付けられるエンティティ（例えば、企業などの組織）を指定させることによって作成されてもよい。その後、管理者は、そのエンティティに関連付けられている物理的サイト（例えば、アムステルダムの物理的サイト）を追加してもよい。各物理的サイト又は物理的位置に関して、管理者は、その後、１つ以上の建物と、それらの関連住所及び他の識別詳細とを追加してもよい。各建物に関して、管理者はまた、総設備電力、待機総電力、エネルギーベースラインが動的であるか否かなどの、エネルギー設定情報を指定してもよい。各建物又は物理的サイトに関連付けられている、就業時間及び就業日数などの詳細もまた、指定されてもよい。システムプロジェクトアプリケーションモジュール１４０は、図６に関連付けられている説明で、より詳細に論じられる。
ユーザ管理アプリケーションモジュール１５０は、システム１００Ａに関連するユーザを管理するための、クラウドベースのソフトウェアアプリケーションである。ユーザは、自身の指定名称（例えば、インストーラー、管理者、プロジェクトマネージャ、専門家、インテーカー、又はエンドユーザ）に応じて、システム１００Ａに対する異なるレベルのアクセス権が認められてもよい。他の指定名称もまた、指定することが可能である。ユーザは、特定の建物に、又はプロジェクト全体に関連付けられてもよい。ユーザ管理アプリケーションモジュール１５０は、資格認定された個人又はエンティティが、プロジェクトデータベース１７０Ａにアクセスして、プロジェクト階層に関連付けられるユーザ、あるいは、特定のプロジェクト階層内の特定の建物／サイトに関連付けられるユーザを作成、更新、及び削除することを可能にする、様々なユーザインタフェースを提供してもよい。例えば、企業Ａのプロジェクト階層に関連付けられているユーザを管理する権限を有する管理者は、特定の名前、住所、年齢、及び他の詳細を有する、インストーラーの役割を有するユーザを追加して、このユーザが、企業Ａのプロジェクト階層に関連付けられている様々なサイトの建物への、照明器具、スイッチ、及びゲートウェイなどのデバイスのインストールを実行するために、システムインテークアプリケーションモジュール１３０及びシステムプロジェクトアプリケーションモジュール１４０を利用することを可能にする、適切なアクセス権を割り当ててもよい。ユーザ管理アプリケーションモジュール１５０は、図６に関連付けられている説明で、より詳細に論じられる。
システムマップアプリケーションモジュール１６０は、プロジェクト階層に関連付けられている様々なシステムデバイス（例えば、照明器具、センサ、スイッチ、ゲートウェイ）を登録、ローカライズすると共に、それらのシステムデバイスにコンフィギュレーション情報展開するために、インストーラーであるユーザによって使用されてもよい、クラウドベースのソフトウェアアプリケーションである。このアプリケーションモジュールは、これらのデバイスに関連付けられるローカライズ情報、建物の様々なフロアのマップビュー、及び各フロアのフロアプラン上の関連システムデバイスの位置を提示してもよい。このアプリケーションモジュールは、インストーラーが、対話型のマップ／フロアプラン上に、システムデバイスをグラフィカルに追加、除去、又は再配置して、そのマップ／フロアプラン上に、これらのデバイスに関連付けられる他のコンフィギュレーション情報を描写することを可能にし得る。インストールを容易にするために、アプリケーションモジュール１６０は、インストーラーがインストールサイトにいる間に使用することが可能な、スマートフォン又はタブレットコンピュータなどのモバイルデバイス上に、そのフロントエンドをレンダリングしてもよい。システムマップアプリケーションモジュール１６０は、図６に関連付けられている説明で、より詳細に論じられる。
建物サーバ１００は、物理的建物とクラウド１１５などのクラウドとの間のデータゲートウェイとして機能する、システムデバイスである。その多くのタスクの中でも特に、この建物サーバは、クラウドから建物内のシステムデバイスにコンフィギュレーション情報をルーティングし、それらのデバイスからクラウドにエネルギー消費データをルーティングし、クラウドとの一時的な接続損失に事前に対処するべくエネルギー消費データをバッファリングし、建物からクラウドに環境メトリックデータ及び診断データをルーティングするものであり、それらの環境メトリックデータとしては、例えば建物占有データが挙げられ、診断データとしては、例えば、感知診断データが挙げられる。建物サーバ１００はまた、様々なシステム管理タスクも実行し得る。例えば、ゲートウェイに時刻同期を提供し、ソフトウェア／ファームウェアのアップグレードプロセスを管理し（例えば、クラウド１１５から入来するソフトウェア／ファームウェア更新トリガの処理、並びに、ゲートウェイ及び感知器用のソフトウェア／ファームウェアイメージの記憶）、建物全体にわたる機能（例えば、スケジューラ、ＡＤＲ）を実装してもよい。建物サーバ１００は、以下の外部インタフェースを使用してもよい：クラウド１１５からシステムデバイスのコンフィギュレーションデータを取得し、クラウド１１５に発見メッセージをプッシュし、様々なゲートウェイにソフトウェア／ファームウェアの更新について通知するための、ＭＱＴＴ。建物サーバ１００はまた、クラウド１１５にデバイスを登録し、エネルギー使用及び他の環境メトリックデータをクラウド１１５に提供し、ゲートウェイ及び他のシステムデバイスにソフトウェア／ファームウェアの更新を送達するために、ＨＴＴＰＳを使用してもよい。建物サーバ１００はまた、ＭＱＴＴとネットワークプロバイダとの間でデータを交換するための、ＺｅｒｏＣ（ＩＣＥ）プロセス間通信フレームワーク（例えば、下位レベルＤｙｎａｌｉｔｅプロトコル）を採用して、アプリケーション間でセキュリティデータを交換してもよい。
ゲートウェイ１１０Ａ又はゲートウェイ１１０Ｂは、ハードウェア、ハードウェアとコンピュータコード（例えば、ソフトウェア又はマイクロコード）との任意の組み合わせとして、又は完全にコンピュータコードとして実装されてもよい。このモジュールは、１つ又は複数のプロセッサ上で実行されてもよい。一部の実施形態では、ゲートウェイ１１０Ａ又はゲートウェイ１１０Ｂのハードウェア実装は、ＳＴＭ３２チップを含み得る。ゲートウェイ１１０Ａ又はゲートウェイ１１０Ｂは、物理的構造の特定のフロアに関連付けられてもよく、そのフロアに配置されている照明器具などの複数のシステムデバイスからのデータを、送信及び／又は受信してもよい。一部の実施形態では、ゲートウェイ１１０Ａ又はゲートウェイ１１０Ｂは、照明器具、センサ、及びＨＶＡＣデバイスなどの多数の（例えば、１０００個の）システムデバイスからのデータを、送信及び／又は受信してもよい。
ゲートウェイ１１０Ａ又はゲートウェイ１１０Ｂは、様々な機能を提供するようにコンフィギュレーションされてもよい。例えば、照明器具をコミッショニングする際に使用するためのインタフェース（例えば、ＥｎｖｉｓｉｏｎＩＰ）と別のインタフェース（例えば、ＲＳ−４８５規格）との間のゲートウェイを提供すると共に、様々なアプリケーション及びネットワークプロトコル間の変換に関するサービスを提供してもよい。多くの実施形態では、また、システム１００Ａ内の複数のゲートウェイ間でのデータのルーティングを容易にすることもでき、ゲートウェイ１１０Ａ又はゲートウェイ１１０Ｂが、その制御下のデバイスが依然としてオンラインであるか否かを判定することが可能な、システム診断及び／又はハードウェアロールコールに関与してもよい。ゲートウェイ１１０Ａ又はゲートウェイ１１０Ｂはまた、ローカルのスケジューリングタスク、並びに監視及び診断データの管理のために、オフラインデバイスのキャッシング及び／又は報告を担当してもよい。例えば、ゲートウェイ１１０Ａ又はゲートウェイ１１０Ｂは、エネルギー消費及び占有に関して、物理的構造内の１つ以上の領域を監視し、その領域レベルについてのシステム健全性情報を診断及び報告してもよい。また、領域監視情報を記憶してもよい。
一部の実施形態では、ゲートウェイ１１０Ａ又はゲートウェイ１１０Ｂは、システムの一部における、全てのＤｙＮｅｔ及びＥｎｖｉｓｉｏｎＩＰトラフィックを監視する。この情報を記憶及び／又はキャッシュして、この情報を他のシステムモジュールに転送してもよく、それにより、システム１００Ａは、任意の時点で、コミッショニングされた全てのシステムデバイスの状態の正確な全体像を有する。多くの実施形態では、ゲートウェイ１１０Ａ及びゲートウェイ１１０Ｂなどの、複数のゲートウェイモジュールは、単一の建物サーバ１００と通信可能にリンクされてもよく、各ゲートウェイは、建物の特定のフロアに関するフロアコントローラとして機能する。機能的には、ゲートウェイ１１０Ａ又はゲートウェイ１１０Ｂは、以下の機能的構成要素に分割されてもよい：ＦＷ更新構成要素、ＮＴＰクライアント構成要素、ＷＧ診断構成要素、発見及び登録構成要素、並びにＺｉｇＢｅｅクロック同期サーバ構成要素。ＦＷ更新モジュールは、同様に名付けられた建物サーバのモジュールのように、それ自体に関する、及び感知デバイスに関する、ファームウェア及びソフトウェアの更新の調整を主に担当している。このプロセスは、図９との関連において、更に詳細に説明される。ＮＴＰクライアント構成要素は、感知デバイスに時刻データを（例えば、環境メトリックデータにタイムスタンプするために）プッシュすることに関与するという点で、同様に名付けられた建物サーバ内のモジュールと同様である。ＺｉｇＢｅｅクロック同期サーバモジュールもまた、時刻同期に関与し、その関連するタイムスタンプ及び時刻同期プロセスは、図７Ａ〜図７Ｃに付随する説明で、より詳細に説明される。ＷＧ診断構成要素は、ゲートウェイのルーチン動作中に遭遇される、エラー又は他の異常な条件若しくは状態を報告することを、主に担当している。これらのエラー条件又は状態は、その後、更なる分析のために、建物サーバを介してクラウド（例えば、クラウド１１５）に報告される。最後に、発見及び登録構成要素は、建物サーバ及び／又はクラウドに、ゲートウェイが自身を登録することを可能にすることを、主に担当している。
デバイス１０１〜１０６は、サードパーティＺｉｇＢｅｅデバイス、ＺｉｇＢｅｅグリーン電力スイッチ、及びバッテリ駆動センサなどの、システムデバイスである。それらはまた、ゲートウェイ１１０Ａ又はゲートウェイ１１０Ｂのような双方のゲートウェイ、並びに、照明器具ドライバ及び照明器具自体と通信することが可能な、発光デバイス及び感知デバイスも含む。感知器及び発光器は、ソフトウェア、ハードウェア、又はファームウェアとして実装されてもよく、照明器具／デバイスドライバの占有又は昼光制御のためのモジュール、照明器具／デバイスドライバを制御するためのアクチュエータ、アンビエント照明又は他の環境条件を感知するためのセンサ、クロック同期モジュール、存在する場合には、どのテンプレートが、それらの対応の照明器具／デバイスドライバに展開されているかを追跡記録するためのメカニズム、並びに、それらの対応の照明器具／デバイスドライバの挙動についての報告を作成するためのメカニズムを含み得る。
感知照明器具は、感知／発光デバイスの一例である。典型的には、センサ、光源、及び制御モジュールに関連付けられる。一部の実施形態では、センサ及び光源は、同じデバイス又はハウジング内部に配置されている。一部の実施形態では、制御モジュールは、センサ及び／又は光源と同じデバイス又はハウジング内部に収容されている、１つ以上のプロセッサ上で実行される、コンピュータコード（例えば、ソフトウェア又はマイクロコード）を含む。光源は、オン／オフ、調光、及び調節可能な白色光又は有色光の生成などの、１つ以上の光作動機能を実行することが可能であってもよい。センサは、例えば、昼光、占有、ＩＲ、二酸化炭素、湿度、及び温度のうちの１つ以上を感知することが可能なセンサである。制御モジュールは、１つ以上の光源、センサ、ゲートウェイ、及び他のＩＰ照明器具などの、他のモジュール及びデバイスの挙動を制御するための、１つ以上の制御機能を提供する。更には、ＩＰ照明器具は、システム１００Ａの他のモジュールと通信するための、１つ以上の外部インタフェースを提供することができる。
プロジェクト１７０Ａは、システム１００Ａに関連付けられた作成済みのプロジェクト階層に関連するデータを記憶して、アクセス可能にさせるデータベースである。このデータベースには、クラウド１１５を介して、建物サーバ１００などの外部エンティティ、並びに、システムインテークアプリケーションモジュール１３０、システムプロジェクトアプリケーションモジュール１４０、及びシステムマップアプリケーションモジュール１６０などの、クラウドベースのアプリケーションモジュールがアクセス可能である。データ１７０Ｂは、様々な感知デバイスによって収集されたエネルギー使用に関連するデータ、並びに、空間及びリソースの使用に関連する集約／分析データを記憶して、アクセス可能にさせるデータベースである。分析データはまた、データ１７０Ｂがアクセス可能な他のデータリポジトリ内に記憶されてもよく、又は、データ１７０Ｂから抽出されたデータを使用して、オンザフライで作成されてもよい。データプラットフォームモジュール１８０は、工業グレードのビッグデータ照明又はエネルギーインフラストラクチャに、多様なソースからの様々なフォーマットのデータを効率的に管理して効率的に取得するための、ソフトウェア構造及びハードウェア構造を提供する、データ取得、管理、及び記憶メカニズムである。その様々な特徴は、図２及び図３で、より詳細に論じられる。
クラウド接続性サービスモジュール１９０は、クラウド内のアプリケーション及びクラウドがアクセス可能なデータリソース（例えば、システムエネルギーアプリケーションモジュール１２０、プロジェクトデータベース１７０Ａ、及びデータプラットフォームモジュール１８０）と、建物サーバ１００との間の接続性を可能にする。様々な実施形態では、このモジュールは、ＭＱＴＴプロトコルを使用して、クラウド１１５と建物サーバ１００との間で、デバイスのコンフィギュレーション及び制御をやり取りする。デバイス登録、並びに、建物サーバ１００、ゲートウェイ１１０Ａ及びゲートウェイ１１０Ｂ、及び感知デバイスに関するファームウェア又はソフトウェア更新情報、並びに、建物／エネルギー使用メトリックが、ＨＴＴＰｓプロトコルを使用して、クラウド１１５と建物サーバ１００との間で転送される。
以下は、システム１００Ａの例示的な使用の簡単な説明である。上位レベルでは、インストーラー（例えば、インストーラーの役割を割り当てられたユーザ）は、物理的建物内にいる間に、例えば、そのインストーラーのモバイルデバイス上にフロントエンドがレンダリングされている、システムインテークアプリケーションモジュール１３０を使用して、最初に建物サーバ１００をインストールする。その後、建物サーバ１００は、クラウド１１５内の登録サービスにアクセスして、自身を登録する。登録プロセスは、図８Ａ及び図８Ｂに関連付けられている説明で、より詳細に説明される。本質的には、登録プロセスは、データ報告の目的のための、建物サーバ１００とクラウド１１５との間の接続性を確保する、単純なブートストラップのプロセスを伴う。インストーラーが、建物サーバ１００のインストールに成功した後、インストーラーは、ゲートウェイ（例えば、１１０Ａ及び１１０Ｂ）をインストールして、それらを建物のＩＰバックボーンに接続する。ゲートウェイの電源がオンにされると、それらは、建物サーバ１００を自動的に「発見」することが可能である。これらのゲートウェイは、その後、建物サーバ１００を使用して、それら自身をクラウド１１５に登録することになる。このことがどのように行われるかについての詳細は、本出願における他の図に関連して論じられる。インストールの成功後には、クラウド内の（例えば、プロジェクト１７０Ａデータベース内に記憶されている）関連するプロジェクト階層は、システム１００Ａの動作に関して必要な全てのデータを有することになる。ＺｉｇＢｅｅ（登録商標）プロトコルは、環境メトリックデータ、並びにファームウェア／ソフトウェア更新データを、システム／感知デバイスとゲートウェイとの間で通信するための、最も一般的なプロトコルである。ゲートウェイ及び建物サーバはまた、それらゲートウェイ及び感知デバイスに関するファームウェア／ソフトウェア更新データを通信するために、並びに、デバイス／エネルギー使用メトリックなどの環境メトリックデータを通信するために、他の通信プロトコル（例えば、ＴＬＳ及びＨＴＴＰｓ）も使用する。
次に、インストーラーは、タブレットコンピュータなどのポータブルデバイス上で動作する、システムマップアプリケーションモジュール１６０などのクラウドベースのアプリケーションを使用して、その建物内に進入する。インストーラーは、建物サーバ１００のＱＲコードをスキャンする。このＱＲコードは、建物サーバ１００に関連付けられている一意識別子を含む。アプリケーションモジュール１６０は、プロジェクト１７０Ａデータベースから、建物サーバ１００に関連付けられているプロジェクト階層データを取得して、アプリケーションモジュール１６０上に示されているフロアプラン上での、建物サーバの位置のインストーラーの選択に基づいて、建物サーバ１００をローカライズし、必要に応じて建物サーバ１００についての追加情報（例えば、ローカライズ情報）を使用して、プロジェクト１７０Ａデータベースを更新することが可能である。
次に、インストーラーは、ＺｉｇＢｅｅ照明器具などの感知デバイスをローカライズする。システムマップアプリケーションモジュール１６０などのアプリケーションは、プロジェクト１７０Ａデータベースから、関連のプロジェクト階層データを取得し、インストーラーは、各照明器具へと物理的に進んで、フロアプラン上で、その照明器具を表すアイコンを選択する。ＩＲリモートコントローラなどのデバイスを使用して、次いで、インストーラーは、ＺｉｇＢｅｅネットワークなどのパーソナルエリアネットワークに、そのデバイスを追加することができる。次いで、その物理的照明器具は、ＺｉｇＢｅｅネットワークを使用して、割り当てられたゲートウェイ（例えば、ゲートウェイ１１０Ａ）と通信することができる。どのゲートウェイがどのシステムデバイスを担当するべきかなどの、コンフィギュレーション情報は、プロジェクト１７０Ａデータベース内に記憶されている。したがって、照明器具が選択される場合、クラウド１１５は、そのデバイスをゲートウェイに正式に追加するために、どのゲートウェイ接続が開かれる必要があるかを、既に「知っている」。ゲートウェイ−システムデバイスのローカライズは、二重プロセスである。クラウド１１５は、建物サーバ１００を介して、特定のゲートウェイに、それ自体に照明器具などのデバイスを追加するためのコマンドを送信する。デバイス又は照明器具自体も、特定のゲートウェイのＺｉｇＢｅｅネットワークに参加することを試み、そのネットワークに参加することが成功すると、その特定のゲートウェイに自身を告知する。
上記で簡単に説明されたように、ローカライズが完了されると、クラウド１１５は、建物サーバ及びゲートウェイを介して、様々なシステム／感知デバイスに対してコンフィギュレーションデータを展開することになる。コンフィギュレーションデータは、例えば、照明器具などのデバイスの挙動を制御するデータを含む。そのようなデータは、ある領域が現在占有されているとセンサが示していることに対して、どのようにデバイスが反応するべきかについての情報を含む。コンフィギュレーションの展開が完了されると、この事実は、システムマップアプリケーションモジュール１６０上に視覚化されることになる。例えば、自身のコンフィギュレーションデータの受信が成功した照明器具は、変更されたアイコンによって表されることになる。ローカライズ及びコンフィギュレーションデータの展開が完了されると、インストーラーは、それらのローカライズ及び展開の諸態様が成功したか否かを検証するオプションを有する。例えば、アプリケーションモジュール１６０は、展開された照明器具の挙動を試験するための、誘導試験プロシージャを提供する。何らかのそのような試験が成功して完了されると、その建物は、コミッショニングされていると見なされる。
データ取得構成要素及びインフラストラクチャ
図２は、システム１００Ａのデータプラットフォームモジュール１８０で使用されるような、データ取得目的のための情報フローのシステム（２００Ａ）を示す。このシステムは、内部アクセス可能な照明インフラストラクチャ又は他の外部ソースのいずれかから、データを確実に取り込み／取得するための、有限数のメカニズムに関する標準化をもたらす。データの外部ソースの例は、Ｔｗｉｔｔｅｒ（登録商標）及びＦａｃｅｂｏｏｋ（登録商標）などのソーシャルネットワークからのデータ、気象データ、セキュリティデータ、並びに、会議室スケジュールなどのスケジューリングデータである。システム２００Ａは、本質的に、データフローが、バッチ処理及びリアルタイム又はほぼリアルタイムの双方で、下流の消費に接続されることを可能にする、内部プラミングである。リアルタイム又はほぼリアルタイムのデータは、低レイテンシのリアルタイムアプリケーション体験を可能にすることになる。本明細書で説明されるような、物理的環境のクラウドベースの監視及び制御のためのシステム、方法、及び装置との関連におけるデータ取得は、多様なソースからの拡張可能かつ確実なデータの取り込みを容易にする、メカニズム又はデータ取得サービス２２０Ａ〜２２０Ｅを提供することに焦点を合わせる。これらのメカニズムは、ＨＴＴＰ（Ｓ）マイクロバッチ取り込み（２２０Ａ）、ストリーミングデータ取り込み（２２０Ｂ）、バルクデータ取り込み（２２０Ｃ）、ソーシャルコネクタ（２２０Ｄ）、及びウェブコンテンツハーベスタ（２２０Ｅ）である。
ＨＴＴＰ（Ｓ）（２２０Ａ）インタフェース及びストリーミング（２２０Ｂ）インタフェースの双方との簡略化された対話を可能にするために、クライアントによって、ライブラリ（例えば、ＳＤＫ）が使用されてもよい。ＨＴＴＰ（Ｓ）マイクロバッチ取り込み（２２０Ａ）の一例は、例えば、データファブリック２３０内に取り込むための、標準的なインターネットに対応するＨＴＴＰＳベースのデータを提供することが可能な、アプリケーションプログラミングインタフェース（ＡＰＩ）である。これは、標準的なＨＴＴＰセマンティクスを使用してもよく、典型的には、小さいペイロード用に設計され、高い水平方向拡張性要件を有する。例えば、ＨＴＴＰ（Ｓ）マイクロバッチ取り込みＡＰＩ２２０Ａは、１秒当たり数万の要求に適応するように設計されてもよい。このＡＰＩは、典型的には、デバイスｔｏサーバＡＰＩと見なされてもよい。ストリーミングデータ取り込み（２２０Ｂ）の一例は、永続的又は長寿命のデータネットワーク接続を介したデータ取得用に設計されている、サービス又はＡＰＩである。このタイプのデータ取り込みは、典型的には、サーバｔｏサーバである。バルクデータ取り込み（２２０Ｃ）の一例は、典型的には、ラージバイナリオブジェクトの取り込みのための、ＳＦＴＰ標準準拠のインタフェースである。ラージバイナリオブジェクトの例としては、大容量ｚｉｐファイル、及び長尺のビデオクリップが挙げられる。ソーシャルコネクタ（２２０Ｄ）の一例は、ソーシャルネットワークデータサービス２１０Ｃなどのサービスが、データファブリック２３０にアクセスすることを可能にするように設計された、ＡＰＩである。これは、主に、Ｔｗｉｔｔｅｒ（登録商標）及びＦａｃｅｂｏｏｋ（登録商標）などのソーシャルネットワークからの、リアルタイムのデータの取り込みを可能にする。所定の基準に基づいて、ソーシャルネットワークからの特定のタイプの対象データが、２２０ＤのＡＰＩを使用して取り込まれることが許可される。この情報は、例えば、人口統計学的情報若しくはユーザプロファイル情報、又は位置情報であってもよい。また、ウェブコンテンツハーベスタ（２２０Ｅ）の一例は、分析目的での、インターネットウェブサイトからコンテンツを抽出するためのサービス又はＡＰＩである。例えば、特定の領域内の建物における典型的なエネルギー使用が、システム１００Ａなどのシステムによって監視されている近傍の建物におけるエネルギー使用を評価する基準として使用されてもよい。
デバイス及びクライアント２００は、ソフトウェア、ファームウェア、及びハードウェアのエージェントを表す。例えば、データは、直接配信されてもよく、あるいは、ゲートウェイ又はプロキシとして機能する、ビジネスアプリ／サービスを介して取得されてもよい。一部のソースからのデータは、システム２００Ａへの取り込みのために、クラウドベースのアプリ／サービス２１０Ａ（例えば、サーバ／アプリのログ）などのクラウド／サーバを介してルーティングされてもよい。しかしながら、このクラウドベースのアプリ／サービス２１０Ａのプロキシ手法は、そのサービスが自身でデータを消費して、何らかの統合アクションを実行すること（例えば、ＨＴＴＰトランザクションの結果としてデータベースを更新すること）を排除するものではない。しかしながら、殆どのそのような場合には、クライアントに由来する根底的メッセージ特性もまた、下流の分析及び／又は消費を可能にするように、データ取得システム２００Ａに到達する。デバイス＆クライアント（２００）からのデータがルーティングされてもよい、他のクラウド／サーバの例としては、ＦＴＰサーバ（２１０Ｂ）、ソーシャルネットワークデータサービス（２１０Ｃ）、及びインターネットウェブサービス（２１０Ｄ）を挙げることができる。ＦＴＰサーバ２１０Ｂの例としては、クライアントとサーバとの間でファイルを転送するために、ＦＴＰネットワークプロトコル、又は、その任意の派生物若しくは拡張物（例えば、ＦＴＰＳ、ＳＳＨ、ＴＦＴＰ、又はＳＦＴＰ）を使用する、任意のサーバが挙げられる。ソーシャルネットワークデータサービス２１０Ｃの例としては、Ｔｗｉｔｔｅｒ（登録商標）又はＦａｃｅｂｏｏｋ（登録商標）のようなソーシャルネットワークによって提供されるデータサービスが挙げられる。インターネットウェブサービス２１０Ｄの例としては、電子デバイスによって、ワールドワイドウェブ（ＷＷＷ）を介して通信している別の電子デバイスに提供される、任意のサービスが挙げられる。インターネットウェブサービス２１０Ｄは、ＸＭＬなどの機械読み取り可能なファイルフォーマットを転送するために、ＨＴＴＰプロトコルを使用してもよい。インターネットウェブサービス２１０Ｄは、エンドユーザにコンテンツ及び／又はユーザインタフェースを提供するために、１つ以上のデータベースサーバにウェブベースのインタフェースを提供する、ウェブサービスである。
データファブリック２３０は、データ生産者とデータ消費者との間に存在するデータパイプである。これは、データ生産者がデータ消費者から切り離されることを可能にする、データブローカと、アクセスを制御すると共に、適切なデータセットが適切なデータ消費者に配信されることを保証することが可能な、ルーティング構成要素とを含む。ルーティング構成要素は、複数の同時の生産者及び消費者をサポートする、水平方向に拡張可能な、高可用性、高耐久性の永続的待ち行列を含む。これは、インバウンドメッセージの受領のためのＡＰＩ／インタフェース、並びに、内部消費のためのＡＰＩ／インタフェースを提供する。データファブリック２３０は、新たなデータセットをコンフィギュレーションして、必要に応じてデータシンクを新たなデータセットに関連付けることができるという点で、データ駆動型である。したがって、典型的には、データファブリック自体の内部でのデータフローのコンフィギュレーションを管理するために、データファブリックサブシステムを再展開する必要はないはずである。ルーティング構成要素はまた、各メッセージを送信するべきか否か、及び、どこに（例えば、どのデータシンクに）送信するべきかを解明することも担当する。実際には、ルーティングするだけではなく、多重送信もする（例えば、同じメッセージを、必要に応じて複数の宛先に送信することが可能である）。データシンクは、標準的な既製のデータシンクであってもよい。例えば、データシンクは、Ｓ３ストレージへのメッセージ（セット）の書き込み（照合）のために使用されるものであってもよい。データシンクはまた、下流のアプリケーション処理による、ほぼリアルタイムのメッセージの消費を可能にするものであってもよい。一般原則として、全てのデータは（ソースにかかわりなく）、データファブリックを介してルーティングされる。小さいデータ（ＫＢ）に関しては、データは、データファブリックメッセージ内で「インライン」で配信される。より大きいデータセットに関しては、データは、外部ストレージにシリアル化され、データファブリックメッセージを介して「ポインタ」が提供される。この手法は、より大きいデータセット（例えば、オーディオ、画像、及びビデオなどのバイナリコンテンツ）の、ほぼリアルタイムの処理を可能にするために使用されてもよい。
単に例示目的で、ここで、図２に示されるシステム２００Ａによる、データフローの一実施例を提供する。オフィスが非占有状態になっていることを、占有センサが判定し、その結果、照明器具は、光レベルを所定のレベルまで低下させる。オフィスが使用中であった間の連続的期間にわたって収集されたエネルギー使用メトリックが、タイムスタンプされて、適切な無線ゲートウェイ（例えば、図１のゲートウェイ１１０Ａ）に、例えばＺｉｇＢｅｅ（登録商標）通信プロトコルを介して送信される。その後、無線ゲートウェイは、その建物の同じフロア上の他のオフィスから、同様のメトリックデータを取得した後、ＨＴＴＰＳプロトコルを介して、この情報を建物サーバ（例えば、図１の建物サーバ１００）に通信する。建物サーバは、ＨＴＴＰＳプロトコルを使用して、それらのメトリックデータをクラウドベースのアプリケーション２１０Ａに通信する。クラウドベースのアプリケーションサービス２１０Ａは、そのアプリケーションサービスにデータを送信する建物サーバを認証することが必要とされてもよく、その後、自身に提示されるデータのタイプに応じて、ＨＴＴＰＳマイクロバッチ取り込み（２２０Ａ）ＡＰＩ又はストリーミングデータ取り込みＡＰＩ（２２０Ｂ）のいずれかに、適切な関数コールを呼び出してもよい。その後、データは、データファブリック２３０によって、更に処理されてカタログ化され、図１に示されるデータデータベース１７０Ｂなどの、クラウドアクセス可能なデータベース内に記憶される。
図３は、図１のデータプラットフォームモジュール１８０によって利用される、マスタデータストレージの一実施形態を示す。一般に、データプラットフォームモジュール１８０内に取り込まれた全てのデータは、そのデータプラットフォームの一次ストレージ、実際には、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅ（ＡＷＳ）のＳｉｍｐｌｅ Ｓｔｒａｇｅ Ｓｅｒｖｉｃｅ（Ｓ３）の最上部の組織化層に永続化されてもよい。データプラットフォームモジュール１８０の多くの実施形態は、可用性及び持続性のために、そのようなクラウドストレージサービスに依存してもよい。更には、プラットフォームは、そのプラットフォーム内に取り込まれるデータのタイプに従って、異なるクラウドストレージの場所へとデータを分別して組織化するための、データ組織構成体を導入する。
図３は、様々なソース（例えば、データファブリック３１０Ａ、データアクセスサービス３１０Ｂ、及びデータサポートサービス３１０Ｃ）からのデータが、データプラットフォームモジュール１６０の一体部分であるマスタデータストレージ及び関連サービスによって、どのように処理されるかを示す。データファブリック３１０Ａは、図２との関連において説明された、任意のタイプのデータファブリック２３０である。データサポートサービス３１０Ｂは、ストレージ３４０内に記憶されているデータへのアクセスを制御する、インフラストラクチャである。その主目的は、ストレージＡＰＩ３３０へのコールを呼び出しているパーティが、必要な権限／クリアランスを有しているか否かを判定するために、アクセス制御又は認証サービスを提供することである。ストレージＡＰＩ３３０は、データファブリック３１０Ａが、その機能インタフェースを呼び出す際に、そのデータファブリック３１０Ａから多様なデータを受信することが可能である。次いで、それらのデータ自体に対して、必要に応じて特定のデータを集計するか、又は必要に応じて匿名化するなどの、様々なアクションを実行してもよく、その後、それらのデータは、索引付けされて、持続性の拡張可能なオンラインストレージ３４０内に記憶される。監査＆ロギングモジュール３２０は、主に、ストレージＡＰＩ３３０へのコールの記録又はロギングを担当する。このＡＰＩへのコールを開始するパーティについての詳細、並びに、そのパーティをデータアクセスサービス３１０Ｂが認証した結果もまた、モジュール３２０によって記録される。持続性ストレージモジュール３４０に対する読み取り及び書き込みもまた、ロギングモジュール３２０によって記録されてもよい。
データアーカイブサービス３５０は、データがアーカイブされる（例えば、ロングターム高レイテンシストレージ３６０に送信される）か又は削除されることが可能な場合に適用される、ポリシー又は規則と、（例えば、ストレージ３６０などのロングタームストレージからの）データをアーカイブ又は復元するためのメカニズムとを含む、及び／又は実施する、ソフトウェア又はファームウェアモジュールを表す。換言すれば、データアーカイブサービス３５０は、データファブリックによって取り込まれ、次いで持続性ストレージ３４０に記憶されるデータに対して、所定のライフサイクルポリシーを実施する。持続性ストレージ３４０は、典型的には、様々なソースからの多種多様なデータ（例えば、家庭からのＨｕｅ（登録商標）データ）を、それらのデータを混在させることなく、組織化して記憶するために使用される。本質的に、持続性ストレージ３４０は、それらのデータ自体、並びに、それらのデータに関連付けられているメタデータを、別個に維持するための方法論を実装する。記憶及び分析の目的でデータを区別するための、多くの方法が存在している。例えば、データ階層の最上レベルは、大規模なオフィスパークプロジェクトデータを、個人の家庭に関して得られるデータから区別することができる。データ階層の第２のレベルは、顧客のアイデンティティ又は地理的所在地に基づいてデータを区別することによって、実施されてもよい。図３のデータセット１及びデータセット２は、持続性ストレージ３４０による容易なアクセス可能性のために、混在されずに別個に維持されている、異なるデータセットを表す。
デバイスのコミッショニング
図４は、図１のシステム１００Ａなどの、物理的環境のクラウドベースの監視及び制御のためのシステム内で使用するためのデバイスを、コミッショニングする方法の一実施形態を示す。ステップ４１０で、システム１００Ａに関連して説明されたインストーラーなどの、インストーラーは、図１のシステム１００Ａに関連して説明されたシステムインテークアプリケーションモジュール１３０などの、クラウドベースのコミッショニングアプリケーション上で、フロアプラン上のシステムデバイス（例えば、照明器具）を選択する。インストーラーは、この時点で、例えばシステム１００Ａによって監視されることになる建物の、内部に存在している。アプリケーションモジュール１３０のユーザインタフェースは、例えば、インストーラーによって使用されるスマートフォン又はタブレットなどのモバイルデバイス上に表示されてもよい。ステップ４２０で、インストーラーのモバイルデバイス上で動作中のコミッショニングアプリケーションは、フロアプラン上の選択されたシステムデバイスの位置を、クラウドベースのコミッショニングアプリケーション（例えば、クラウドベースのシステムインテークアプリケーションモジュール１３０のバックエンド）に送信する。ステップ４３０で、クラウドベースのコミッショニングアプリケーションは、フロアプラン位置を（例えば、インストーラーが現時点で中にいる建物にリンクされているプロジェクト階層に関連付けられた、プロジェクト１７０Ａデータベース内に）保存して、そのプロジェクト階層内の建物に関連付けられている建物サーバ（例えば、システム１００Ａの建物サーバ１００）に、その建物サーバに関連付けられている正しいゲートウェイへのネットワーク接続を開くように指示する。そのような状況では、建物サーバは、その建物のフロアプラン上の選択されたシステムデバイスの物理的位置に基づいて、正しいゲートウェイ（例えば、システム１００Ａのゲートウェイ１１０Ａ又はゲートウェイ１１０Ｂ）を識別することが可能である。ステップ４４０で、建物サーバは、適切なゲートウェイに、ネットワークを開く要求を送信する。ステップ４５０で、ゲートウェイは、そのネットワーク（例えば、ＺｉｇＢｅｅ（登録商標）ネットワーク）を開くことによって応答する。ゲートウェイのネットワークを開くことが成功したことに続けて、ステップ４６０で、インストーラーは、ＩＲ遠隔制御デバイスを使用して、そのゲートウェイのネットワークに、システムデバイスを「追加」する。インストーラーは、ＩＲリモコンを対象のデバイスに向けて、次いで、そのＩＲ遠隔制御デバイス上の「追加」ボタンを押すことによって、このことを行ってもよい。この時点で、システムデバイス内の論理回路は、そのシステムデバイス（例えば、照明器具）がゲートウェイのオープンネットワークに追加されることを望んでいることをブロードキャストし、ゲートウェイは、そのゲートウェイの関連システムデバイスの群に、このシステムデバイスからの識別情報をローカルで追加すると共に、システムデバイスの識別情報を、建物サーバにも送信する（ステップ４７０）。ステップ４８０で、建物サーバは、例えば、クラウド接続性サービスモジュール１９０及び／又はデータプラットフォームモジュール１８０を介して、クラウド（例えば、クラウド１１５）に、システムデバイスの識別情報を（例えば、ＭＱＴＴ又はＨＴＴＰｓプロトコルを介して）送信する。ステップ４９０で、システムインテークアプリケーションモジュール１３０などの、クラウドベースのアプリケーションは、システムデバイスの識別情報を、ステップ４１０でインストーラーによって当初より示されていたフロアプラン上の位置と結び付けて、そのインストーラーのモバイルデバイス上で実行中の関連アプリケーションに、確認メッセージを送信する。この確認メッセージは、例えば、システムデバイスのコミッショニングが成功したことを示し得る。
デバイスのローカライズのユースケース
上述のように、インストーラーは、システムマップアプリケーションモジュール１６０などのアプリケーションの助けを借りて、建物サーバ１００並びにゲートウェイ１１０Ａ及びゲートウェイ１１０Ｂをローカライズすることができる。このローカライズは、ＱＲコードを使用して達成されてもよい。その一方で、照明器具及び壁スイッチなどの他のシステムデバイスは、以下のユースケースで説明されるように、ＩＲ技術又はボタンの押下を使用してローカライズされてもよい。
典型的ユースケース
図５Ａは、システムデバイス（例えば、天井取り付け照明器具などの感知デバイス）に関する、ローカライズのユースケースを示す。図５Ａに示されるステップでは、ユーザ（例えば、インストーラー）は、システムマップアプリケーションモジュール１６０などのクラウドベースのアプリケーションモジュールのユーザインタフェース上の、システムデバイスを表しているアイコンをタップする（ステップ５１０Ａ）。これに応答して、クラウドベースのアプリケーションモジュールは、そのシステムデバイスに関連付けられている無線ゲートウェイ（例えば、ゲートウェイ１１０Ａ）の無線ネットワーク（例えば、ＺｉｇＢｅｅネットワーク）を開く（ステップ５２０Ａ）。次いで、ユーザは、例えば遠隔制御デバイスを使用して、そのシステムデバイスに赤外線（ＩＲ）トリガを送信する（ステップ５３０Ａ）。次いで、システムデバイスは、そのＩＲトリガが受信されたことを、ユーザに視覚的に（例えば、所定の回数で点滅することによって）示す（ステップ５４０Ａ）。システムデバイスは、無線ネットワークに参加して、クラウドベースのアプリケーションモジュールにＳｉｇｎＯｎメッセージを送信する（ステップ５５０Ａ）。クラウドベースのアプリケーションモジュールは、そのＳｉｇｎＯｎメッセージを受信して、ローカライズの成功を示すために、ユーザに視認可能なユーザインタフェース上のアイコンの表示を変更する（ステップ５６０Ａ）。クラウドベースのアプリケーションモジュールはまた、システムデバイスに、ローカライズの成功を視覚的に、又は他の方式で示すように要求を送信する（ステップ５７０Ａ）。例えば、システムデバイスが照明器具である場合には、その照明器具が光出力を１０％まで減光することを要求してもよい。その要求を受信すると、システムデバイスは、ローカライズの成功を示すことに応じる（ステップ５８０Ａ）。システムデバイスは、この時点で、ローカライズされていると見なされる。多くの実施形態では、システムデバイスのローカライズの成功後に、展開が自動的に開始される。システムデバイスの展開が完了されると、クラウドベースのアプリケーションモジュール上の、その対応するアイコンは、ユーザにフィードバックを提供するために、その「展開済み」状態を示すべく再び変化することになる。一部の実施形態では、いったんシステムデバイスの展開が成功すれば、ユーザに対して、展開の視覚的な確認が更に行われることはない。
一部の状況では、ローカライズが完了される前、及び対象のシステムデバイスがＩＲトリガの受信を示した後のいずれかの時点で、第２のトリガが、システムデバイスによって受信される。そのような状況において、多くの実施形態では、システムデバイスは、自身の関連する無線ゲートウェイに、第２のＳｉｇｎＯｎメッセージを送信することになる。しかしながら、クラウドベースのアプリケーションモジュールは、多くの実施形態では、第２のＳｉｇｎＯｎメッセージを受信して、そのＳｉｇｎＯｎメッセージが、既にローカライズ済みか又はローカライズ待ちのシステムデバイスからであることを認識し、その第２のＳｉｇｎＯｎメッセージを単純に無視することを選択する（例えば、それがエラーであると推定される）。
異なる位置上の感知器からの第２のＳｉｇｎＯｎ
図５Ｂに示されるユースケースでは、システムデバイスは、位置Ａに既にローカライズされている（例えば、システムマップアプリケーションモジュール１６０上に特定のアイコンで示されている）が、それにもかかわらず、ユーザは、そのシステムデバイスを、別の位置Ｂにローカライズすることを望む（ステップ５１０Ｂ）。ユーザは、このことを、アプリケーションモジュール１６０によって提示されているＵＩ内の、位置Ｂを表す別のアイコンをタップすることによって示してもよい。これに応答して、クラウドベースのアプリケーションモジュールは、関連する無線ゲートウェイ（例えば、ゲートウェイ１１０Ａ）の無線ネットワーク（例えば、ＺｉｇＢｅｅネットワーク）を開く（ステップ５２０Ｂ）。次いで、ユーザは、そのシステムデバイスに、遠隔制御デバイスで赤外線トリガを送信し（ステップ５３０Ｂ）、システムデバイスは、そのＩＲトリガが受信されたことを、ユーザに視覚的に示すことによって（例えば、所定の回数で点滅することによって）応答する（ステップ５４０Ｂ）。システムデバイスは、以前に位置Ａにローカライズされた際、その関連する無線ゲートウェイの無線ネットワークに既に参加している可能性があるが、そのシステムデバイスは、依然として、自身に対応する新たな位置（位置Ｂ）を示すＳｉｇｎＯｎメッセージを、クラウドベースのアプリケーションモジュールに送信する（ステップ５５０Ｂ）。クラウドベースのアプリケーションモジュールは、システムデバイスが、位置Ａに対応する位置に既にマッピングされている場合であっても、位置Ｂに対応するシステムデバイスの位置情報を有する、そのＳｉｇｎＯｎメッセージを受信する。ＳｉｇｎＯｎメッセージを受信すると、クラウドベースのアプリケーションモジュールは、様々な実施形態では、そのシステムデバイスが以前にローカライズされていることをユーザにプロンプト表示して、ユーザがシステムデバイスを新たな位置（例えば、位置Ｂ）に再度ローカライズする（例えば、移動させる）ことを望むか否かを問い合わせる（ステップ５６０Ｂ）。ユーザが、システムデバイスを移動させることを実際に望むことを示す場合には、そのシステムデバイスは、位置Ｂにローカライズされることになり、そのシステムデバイスの新たな展開は、そのシステムデバイスの以前に開始されたいずれかの展開が完了した時点で、開始することになる（ステップ５７０Ｂ）。このシステムデバイスの展開が完了されると、クラウドベースのアプリケーションモジュール上の、そのシステムデバイスに関連付けられているアイコンは、そのシステムデバイスの新たな展開状態をユーザに示すように、変化することになる。多くの実施形態では、システムデバイス自身からは、その展開が完了されたことを示すための視覚的な確認が行われることはない。ユーザが、システムデバイスを移動させる（再度ローカライズする）ことを望まないことを示す場合には、システムデバイスのローカライズの変更は実施されず、そのデバイスは、位置Ａにローカライズされたまま維持される（ステップ５８０Ｂ）。
既にローカライズ済みのアイコンが選択されている（又は、何も選択されていない）場合に、感知器をトリガする
図５Ｂに示されるシナリオに関連して、変更形態を考察することができる。互いに近接して配置されている、２つのシステムデバイス（感知器Ａ及び感知器Ｂ）が存在することを考察する。例えば、それぞれが、天井取り付け照明器具であってもよい。感知器Ｂは、クラウドベースのアプリケーションモジュール（例えば、システムマップアプリケーションモジュール１６０）上の位置Ｂに、既にローカライズされていると想定する。また、この変更されたシナリオでは、感知器Ｂのゲートウェイに関連付けられた無線ネットワーク（例えば、ＺｉｇＢｅｅ（登録商標）ネットワーク）が開かれていると想定する。この時点で、ユーザは、未だローカライズされていない感知器Ａに、遠隔制御デバイスを使用して、赤外線（ＩＲ）トリガを送信する。感知器Ａは、そのＩＲトリガを受信したことを（例えば、３回点滅することによって）示す。感知器Ａはまた、無線ネットワークに参加して、クラウドベースのアプリケーションモジュールによって受信されるＳｉｇｎＯｎメッセージを送信する。この時点で、クラウドベースのアプリケーションモジュールは、感知器（感知器Ａ）からのＳｉｇｎＯｎメッセージを受信しているが、感知器Ａがローカライズされるための関連する位置は受信していない。そのような状況において、多くの実施形態では、クラウドベースのアプリケーションモジュールは、「点滅フロー」シーケンスに入ってもよい。そのようなシーケンスでは、ローカライズされていない感知器のリストが提示されてもよい。本シナリオにおける第１及び唯一の感知器（感知器Ａ）は、クラウドベースのアプリケーションモジュールから「点滅」メッセージを受信することになる。これに応答して、ユーザは、そのアプリケーションモジュールのＵＩ上で、点滅する感知器Ａに対応するアイコン（またそれゆえ、位置）を示すことが必要となる。これに応答して、アプリケーションモジュールは、その示された位置に感知器Ａをローカライズするように進む。
ローカライズされていないアイコンが選択されている（又は、何も選択されていない）場合に、複数の感知器をトリガする
図５Ｃは、ローカライズのために使用されるクラウドベースのアプリケーションモジュール（例えば、システムマップアプリケーションモジュール１６０）上で位置／アイコンが選択されていない場合に、複数のシステムデバイス（例えば、感知器）がトリガされる、シナリオ又はユースケースを示す。このユースケースはまた、ローカライズされていないアイコン／位置がアプリケーションモジュール上で選択されている状態で、複数のシステムデバイスがトリガされる場合の、イベントのシーケンスを決定するために使用されてもよい。
ステップ５１０Ｃで、クラウドベースのアプリケーションモジュール上で位置を選択することなく、ユーザ（例えば、インストーラー）は、遠隔制御デバイスを使用して、２つ以上のシステムデバイス（例えば、感知器）にＩＲトリガを送信する。ステップ５２０Ｃで、それら２つ以上のシステムデバイスは、それらがＩＲトリガを受信したことを、（例えば、それらのライトを３回ずつ点滅させることによって）視覚的に又は他の方式で示す。それら２つ以上のシステムデバイスは、それらのゲートウェイデバイスに関連付けられているオープン無線ネットワークに参加し、各システムデバイスは、その無線ネットワークを介して、ＳｉｇｎＯｎを示すメッセージ（例えば、ＳｉｇｎＯｎメッセージ）を送信する（ステップ５３０Ｃ）。クラウドベースのアプリケーションモジュールは、それら２つ以上のＳｉｇｎＯｎの指標を受信して、例えば、それらのＳｉｇｎＯｎメッセージ内の識別情報に基づいて、そのアプリケーションモジュールのＵＩ上の対応するシステムデバイスを識別する（ステップ５４０Ｃ）。識別された対応するシステムデバイスは、トリガされた物理システムデバイスの仮想表現である。ステップ５５０Ｃで、トリガされた２つ以上のシステムデバイスのうちの第１のシステムデバイスは、それ自身を、ユーザに対して（例えば、点滅し続けることによって）視覚的に又は他の方式で識別させる。このことは、クラウドベースのアプリケーションモジュールが、識別された対応する第１のシステムデバイスに、点滅を開始する要求を送信することによるものであってもよい。これに応答して、ユーザは、アプリケーションモジュールのＵＩ上で、どの位置／アイコンを、その点滅している（又は、他の方式で注意喚起している）物理システムデバイスに関連付けるかを指示することになる（ステップ５６０Ｃ）。ステップ５７０Ｃで、クラウドベースのアプリケーションモジュールは、第１のシステムデバイスを、ユーザの選択した位置／アイコンにローカライズするように進む。ローカライズが成功すると、そのシステムデバイスはまた、展開されることになる。クラウドベースのアプリケーションモジュールは、トリガされた２つ以上のシステムデバイスと共に、それらトリガされた２つ以上のシステムデバイスに対応するものとしてクラウドベースのアプリケーションモジュールによって識別されたシステムデバイスのそれぞれを、上述の方法で巡回することにより、ユーザは、それらトリガされたシステムデバイスのそれぞれをローカライズする機会を得ることになる。
既に１つがローカライズされている、複数の感知器をトリガする
図５Ｃに示され、上述されたものと同様のユースケースで、ユーザ（例えば、インストーラー）が、クラウドベースのアプリケーションモジュール（例えば、システムマップアプリケーションモジュール１６０）上で、位置／アイコン（例えば、アイコンＡ）を既に選択していることを考察する。この時点で、少数のシステムデバイス（例えば、感知器Ａ及び感知器Ｂ）に関連付けられているゲートウェイ（例えば、ゲートウェイ１１０Ａ）の無線ネットワーク（例えば、ＺｉｇＢｅｅ（登録商標）ネットワーク）が、開かれていると想定する。次いで、ユーザは、遠隔制御デバイスを使用して、感知器Ａ及び感知器Ｂの双方に赤外線（ＩＲ）トリガを送信する。これに応答して、感知器Ａ及び感知器Ｂは、そのＩＲメッセージが受信されたことを、（例えば、３回点滅することによって）視覚的に又は他の方式で示す。それらの感知器は、その後、オープン無線ネットワークに参加し、それぞれがクラウドベースのアプリケーションモジュールにＳｉｇｎＯｎメッセージを送信する。アプリケーションモジュールは、１つが感知器ＡのＩＤに関連付けられており、もう１つが感知器ＢのＩＤに関連付けられている、２つのＳｉｇｎＯｎメッセージを受信する。しかしながら、感知器Ａは、既にアイコンＡにローカライズされているため、アプリケーションモジュールは、感知器ＡのＳｉｇｎＯｎメッセージを単純に無視してもよい。このシナリオでは、他の１つの感知器（感知器Ｂ）のみが残されているため、感知器Ｂは、アイコンＡに関連付けられている位置に、直ちにローカライズされることが可能である。ローカライズの成功後には、感知器Ｂの展開が開始されることが可能である。
ローカライズ中の潜在的問題
更なるシナリオでは、ユーザ（例えば、インストーラー）が、クラウドベースのアプリケーションモジュール（例えば、システムマップアプリケーションモジュール１６０）のＵＩ上のアイコン（アイコンＡ）をタップしたと想定する。その後、ゲートウェイ（例えば、ゲートウェイ１１０Ａ）に関連付けられている無線ネットワークが、アプリケーションモジュールによって開かれる。ユーザは、遠隔制御デバイスから、システムデバイス（感知器Ｂ）に、ＩＲトリガを送信する。感知器Ｂは、例えば３回点滅することによって、そのＩＲメッセージの受信を示す。この時点で、例示目的で、ローカライズのプロセスを妨害するように発生する恐れがある、２つの潜在的問題を論じる。また、これらの問題に対処するための、潜在的方法も論じる。
問題１：システムデバイスがトリガされるが、ゲートウェイの無線ネットワークに参加することができない
感知器Ｂは、様々な理由から無線ネットワークに参加することができない場合がある。例えば、圏外であるか、又は他の欠陥がある場合もある。その結果、感知器Ｂは、ＳｉｇｎＯｎメッセージを送信することなく、ローカライズの成功の何らかの視覚的指標又は他の指標を、ユーザに提供することがない。成功の指標が示されない場合、ユーザは、ローカライズのプロセスで何か不具合が生じたことを理解する可能性が高い。トラブルシューティングするために、ユーザは、クラウドベースのアプリケーションモジュールのＵＩをチェックして、感知器Ｂに関連付けられているゲートウェイ又は建物サーバ自体がオフラインであるか否かを判定することができる。あるいは、ユーザは、同じ挙動の発生が認められるか否かを明らかにするために、未だローカライズされていない異なるシステムデバイス（例えば、感知器Ａ）をトリガすることを試みてもよい。ユーザはまた、遠隔制御デバイスを使用して、工場出荷時設定コマンドを感知器Ｂに送信し、その後、再度その感知器をトリガすることを試みてもよい。最終的に、ユーザは、感知器Ｂを交換してもよい。
問題２：システムデバイスがネットワークに参加するが、ＳｉｇｎＯｎの指標がクラウドに到達しない
感知器Ｂは、オープン無線ネットワークに参加し、次いで、クラウドベースのアプリケーションモジュールに、ＳｉｇｎＯｎの指標（例えば、ＳｉｇｎＯｎメッセージ）を送信することを試みる。しかしながら、クラウドベースのアプリケーションモジュールとゲートウェイとの間の通信リンクが、その後に断ち切られる（例えば、ゲートウェイと建物サーバ（例えば、建物サーバ１００）との間、建物サーバとクラウド（例えば、クラウド１１５）との間、又はクラウドベースのアプリケーションモジュールとクラウドとの間の通信リンクのうちの１つ以上が遮断される）場合には、ローカライズは、通常どおりに進むことが不可能となる。しかしながら、これらの接続性の切断は、クラウドベースのアプリケーションモジュールのＵＩ上で、ユーザに対して視認可能に示されることになる。感知器ＢからのＳｉｇｎＯｎは、クラウドベースのアプリケーションモジュールには到達することがないため、感知器Ｂのローカライズが進むことはない。しかしながら、遮断された接続が復旧すると直ちに、ユーザは再度、感知器Ｂに第２のＩＲトリガを送信することを試みることができる。この場合も、前と同様に、感知器Ｂは、そのＩＲメッセージの受信を示すために、所定の回数（例えば、３回）点滅することになる。しかしながら、今回は、以前に経験されていた接続の問題が解消されている場合には、クラウドベースのアプリケーションモジュールは、感知器Ｂから送信された新たなＳｉｇｎＯｎメッセージを受信することになり、前のセクションで示された方式で、ローカライズが継続することになる。展開もまた、前述のように、ローカライズの成功に続けて実施されることになる。
感知器の以前の不正確なローカライズの修正
以下の論考は、システムデバイス（例えば、感知器Ａ）の以前の不正確なローカライズが修正されることが可能な、一部の例示的方法を対象とする。この論考は、例示することのみを目的とし、限定することを意図するものではない。感知器Ａは、アイコンＡに関連付けられた位置に既にローカライズされており、これは不正確なローカライズであることを想定する。ユーザ（例えば、インストーラー）が、この不正確なローカライズを修正するための、少なくとも２つの方法が存在する。
第１のシナリオでは、ユーザが、代わりにアイコンＢに感知器Ａをローカライズすることを望んでおり、感知器Ｃが、既にローカライズされているという視覚的指標を、既に物理的に呈している（例えば、既に１０％まで減光されている）ことに、そのユーザが気付いている場合には、ユーザは、遠隔制御デバイスを使用して、感知器Ｃに工場出荷時設定コマンドを送信してもよい。これに応答して、感知器Ｃはリセットして、予め割り当てられていたネットワークから離れ、その旨を示すメッセージ（例えば、「ＬｅａｖｅＮｅｔｗｏｒｋ」メッセージ）を、関連付けられているゲートウェイに送信することになる。このイベントのシーケンスは、アイコンＡに対する感知器Ｃのローカライズを除去する効果を有することになる。クラウドベースのアプリケーションモジュール（例えば、システムマップアプリケーションモジュール１６０）では、アイコンＡの外観は、それに応じて、現時点ではシステムデバイスに関連付けられていないことを示すように変化することになる。ここで、ユーザは、アイコンＢ（又は、そのユーザが選択した任意の他のアイコン）に関連付けられている位置に、感知器Ａをローカライズするように進むことができる。
第２のシナリオでは、ユーザは、アイコンＡに対する感知器Ａのローカライズが、予定どおりには進行しなかった（例えば、ローカライズのプロセス中に何か不具合が生じた）ことを知る。ユーザは、クラウドベースのアプリケーションモジュールを使用して、再ローカライズのプロセスを開始することができる。ユーザは、例えば、感知器Ａからアンマップするために、アイコンＡをタップしてもよい。このことは、アイコンＡに関連付けられている位置に対する感知器Ａのローカライズを除去することになる。次いで、クラウドベースのアプリケーションモジュール（例えば、システムマップアプリケーションモジュール１６０）は、誤ったローカライズを除去するプロセスを開始することになる。例えば、感知器Ａに「工場出荷時設定」信号を送信してもよく、感知器Ａは、これに応答してリセットし、予め関連付けられていたゲートウェイの無線ネットワークから離れることになる。ここで、ユーザは、アイコンＢ（又は、そのユーザが選択した任意の他のアイコン）に関連付けられている位置に、感知器Ａをローカライズすることができる。
コミッショニング及びローカライズアシスタント
図１３Ａは、システムの中でも特に、物理的環境のクラウドベースの監視及び制御のための図１のシステム１００Ａ等の、システム内での使用のために感知デバイス又は発光デバイスをコミッショニングする及び／又はローカライズする際のエラーを自動的に検出するためのシステム１３００の実施形態を示す。システム１３００は、建物サーバ１００、ゲートウェイ１１０Ａ、システムデバイス１０１〜１０３、コンピューティングクラウド１１５、システムインテークアプリケーションモジュール１３０、システムマップアプリケーションモジュール１６０、プロジェクトデータベース１７０Ａ、データデータベース１７０Ｂ、データプラットフォームモジュール１８０、インストーラー６１０、リモートデバイス６２２、及びシステムマップアプリケーションモジュール１６０Ａを備えたコミッショニングデバイス６３２を含む。システム１３００の他の実施形態は、追加的な、又はより少ない、建物サーバ、ゲートウェイ、システムデバイス、クラウド、ユーザ、コミッショニングデバイス、及びリモートデバイスを含み得る。システム１３００の様々な構成要素は、図１３Ａに示されるリンク線を使用して、通信可能にリンクされている。しかしながら、図中の２つのブロック又はモジュール間のリンク線の欠如は、必ずしも、それらブロック又はモジュール間の通信能力の欠如を示すものではない。
本明細書で論じられるように、システムインテークアプリケーションモジュール１３０は、例えば、感知デバイス及び発光デバイスが、指定領域に適切に割り当てられると共に、対応のゲートウェイに適切に割り当てられることを確認するために、システム１３００のインストーラー６１０が、ファンクションの中でも特に、インテークプロセスをチェックするために使用されてもよい、クラウドベースのソフトウェアアプリケーションである。この情報は、その後、プロジェクトデータベース１７０Ａに入力するために使用されてもよい。同様に、システムマップアプリケーションモジュール１６０は、プロジェクト階層に関連付けられている様々なシステムデバイス（例えば、照明器具、センサ、スイッチ、ゲートウェイ）を登録、ローカライズすると共に、それらのシステムデバイスにコンフィギュレーション情報を展開するために、インストーラー６１０によって使用されてもよい、クラウドベースのソフトウェアアプリケーションである。このアプリケーションモジュールは、これらのデバイスに関連付けられるローカライズ情報、建物の様々なフロアのマップビュー、及び各フロアのフロアプラン上の関連システムデバイスの位置を提示してもよい。このアプリケーションモジュールは、インストーラー６１０が、対話型のマップ／フロアプラン上に、システムデバイスをグラフィカルに追加、除去、又は再配置して、そのマップ／フロアプラン上に、これらのデバイスに関連付けられる他のコンフィギュレーション情報を描写することを可能にし得る。インストールを容易にするために、アプリケーションモジュール１６０は、インストーラーがインストールサイトにいる間に使用することが可能な、スマートフォン又はタブレットコンピュータなどのモバイルデバイス上に、そのフロントエンドをレンダリングしてもよい。
インストーラー６１０は、システム１３００の物理的環境内でシステムデバイス１０１〜１０３をコミッショニング及びローカライズするためにコミッショニングデバイス６３２を利用する。コミッショニングデバイスは、タブレット、スマートフォン、又は他のデバイスを含むハンドヘルドコンピューティングデバイスのような任意のコンピュータであってもよい。コミッショニングデバイスは、本明細書に記載されているか、さもなければ構想されているように、デバイスの機能を実行又は容易にするように構成又はプログラムされるプロセッサ６４０を含む。コミッショニングデバイスはまた、システムインテークアプリケーションモジュール１３０又はシステムマップアプリケーションモジュール１６０のバックエンドのような、クラウドベースのコミッショニングアプリケーション又はプログラムを含む。インストーラー６１０は、コミッショニングデバイス上のクラウドベースのコミッショニングアプリケーション上のフロアプラン上のシステムデバイス（例えば、照明器具）を選択する。クラウドベースのコミッショニングアプリケーションは、システムデバイスと関連付けられた無線ゲートウェイ（例えば、ゲートウェイ１１０Ａ）の無線ネットワーク（例えば、ZigBeeネットワーク）を開くためにシステムと通信する。その後、インストーラー６１０は、システムデバイスをゲートウェイのネットワークに追加するために装置にトリガを送信するため、ＩＲ遠隔制御デバイスなどのリモートデバイス６２２を使用する。例えば、インストーラーは、追加されるデバイスにリモートデバイスを指し示し、その後、リモートデバイスの「追加」ボタンを押してもよい。これで、システムデバイスは、ローカライズされていると見なされる。
しかしながら、インストーラー６１０は、あり得るエラーの中でも特に、誤って複数のデバイスをネットワークに一度に追加したり、間違ったデバイスをコミッション又はローカライズしたりする可能性がある。これらのエラーは、コミッショニング及びローカライズ中に見過ごされたり、見逃されたりする可能性がある。したがって、システム１３００は、感知デバイス又は発光デバイスのコミッショニング及び／又はローカライズにおけるエラーを自動的に検出する機能を含んでもよい。
図１３Ｂは、システムデバイスのコミッショニング及び／又はローカライズにおけるエラーを自動的に検出する方法１３５０の実施形態を示す。方法１３５０は、システムの最初のコミッショニング中、及び／又はシステム内のシステムデバイスの置換又は修復の後のエラーを検出するために利用されてもよい。例えば、照明器具が交換された後、照明器具は、再コミッショニングされる必要がある。
本方法のステップ１３５２において、システム１３００内のシステムデバイスは、近隣のシステムデバイスから、それらの近隣のシステムデバイスに関する情報を含む無線信号を受信する。情報は、送信デバイスのアドレス及びネットワーク識別子を含んでもよい。信号は、部分的又は完全に暗号化され得る。例えば、信号は、送信デバイスのアドレス及びネットワーク識別子、例えば、１６ビットアドレス及び１６ビットネットワーク識別子（ＰＡＮ ｉＤ）を含んでもよく、この情報は、暗号化又は非暗号化されてもよい。システムは、システムデバイスが、コミッショニングの前に近隣のシステムデバイスから情報を受信し、格納するよう構成されてもよい。例えば、デバイスは、ZigBeeネットワークレベルリンクステータスコマンド等の無線信号を周期的に送信することができる。デバイスは、他の多くの時間周期が可能であるが、１５秒等の所定の時間周期で情報を周期的に送信することができる。受信された情報は、ネットワークにまだ参加されていないシステムデバイスに格納されることもできる。ネットワークに参加すると、この情報は、システムと共有されることができる。代替的に、システムは、システムデバイスが、コミッショニング中、又はシステムデバイスのコミッショニング又はローカライズの要求時にのみ、近隣のシステムデバイスから情報を受信し、格納するよう構成されてもよい。
本方法のステップ１３５４において、システムデバイスは、受信した無線信号から、無線信号の信号強度を決定する。これは、無線信号を分析し、信号強度を決定又は推定するための任意の方法を使用して達成されることができる。一実施形態によれば、各システムデバイスは、複数の無線信号を受信し、受信した複数の無線信号の各々について信号強度を決定する。その後、各受信された無線信号の強度は、当該無線信号を送信したシステムデバイスの識別情報と関連付けられることができる。一実施形態によれば、システムデバイスは、受信した無線信号の強度及び関連する識別情報をメモリに記憶することができる。
本方法のステップ１３５６において、システムは、システムデバイスをコミッショニング及びローカライズするためにインストーラー６１０から要求又はコマンドを受信する。例えば、インストーラー６１０は、リモートデバイス６２２を使用して、システムデバイスをゲートウェイのネットワークに追加するためにデバイスにトリガを送信してもよい。その後、関連付け要求がシステムに送信される。関連付け要求は、参加するシステムデバイスの識別子を含む。
本方法のオプションのステップ１３５５において、１つ以上のシステムデバイスは、システム内のデバイスのローカライズを容易にするために、他のセンサ情報を取得することができる。例えば、システムデバイスは、ローカライズを容易にするために光レベル感知、占有感知、及び他の情報などの情報を入手し、格納することができる。システムは、この情報を利用して、システムに参加する新たなシステムデバイスのローカライズが正しいかどうか、又はエラーがあるかどうかを分析及び判断してもよい。例えば、（窓に近い）追加システムデバイスによって検出される光レベルが、窓又は他の光源から離れたシステムデバイスによって検出される光レベルに類似している場合、これは、システムに対して、間違ったシステムデバイスがコミッショニングのために識別されたことを示唆する。情報の別の例として、システムデバイスは、近隣のシステムデバイスからメッセージパターンを受信し、格納してもよい。例えば、システムデバイスは、近隣のシステムデバイスが、突然あるタイムフレーム内で複数のメッセージを送信していることを検出又は判断してもよい。これは、近隣のシステムデバイスがコミッショニングされていることを示唆する。これは、例えば、受信するシステムデバイスがすぐにコミッショニングされる可能性があることを示唆し得る。
本方法のステップ１３５８において、システムは、物理的環境内の１つ以上の他のシステムデバイスから無線信号強度情報、及び関連付け要求を受信する。システムはまた、参加するシステムデバイスから無線信号強度情報を受信してもよい。一実施形態によれば、関連付け要求は、参加するシステムデバイスのための識別子情報を含む。すでにシステム内にコミッショニングされている全てのシステムデバイスは、関連付け要求の信号強度を測定することができ、先の無線信号強度情報と共に、この情報をシステムと共有することができる。
本方法のステップ１３６０において、システムは、１つ以上の他のシステムデバイスからの無線信号強度情報に少なくとも部分的に基づいて、正しいシステムデバイスが関連付け要求で選択されたかどうかを判定する。例えば、システムは、システムデバイスによって受信された無線信号強度を分析して、信号を送信したデバイスに対する当該システムデバイスの近似位置を決定してもよい。この近似位置を決定し、それを要求された位置と比較することによって、システムは、正しいシステムデバイスがインストーラーによって選択されたかどうかを判定することができる。
図１３Ｃは、複数のシステムデバイス１０１Ａ〜１０１Ｈを有する物理的環境１３８０を示す。コミッショニングプロセスの一例によれば、システムデバイス１０１Ａ及び１０１Ｅは、システム内ですでにコミッショニングされている。インストーラー６１０は、システムデバイス１０１Ｂをコミッショニングすることを意図しているが、誤ってシステムデバイス１０１Ｆのコミッショニング要求を送信する。例えば、インストーラーは、システムデバイス１０１Ｂの代わりに、システムデバイス１０１Ｆにリモートデバイスを誤って向けたかもしれない。システムは、コミッショニング要求及び無線信号強度から、システムデバイス１０１Ｆがシステムデバイス１０１Ｂでない可能性が高いと判断する。例えば、システムデバイス１０１Ｆは、コミッショニングされているシステムデバイス１０１Ａからよりも強い無線信号をコミッショニングされているシステムデバイス１０１Ｅから受信し、これは、システムデバイス１０１Ｆがシステムデバイス１０１Ｅに近いことを示唆する。インストーラーが正しいシステムデバイス（すなわち１０１Ｂ）を選択した場合、当該システムデバイスは、システムデバイス１０１Ａからより強い無線信号を受信するはずである。一実施形態によれば、システムはまた、光レベル感知情報を使用して位置決定を行う。
コミッショニングプロセスの別の例によれば、システムデバイス１０１Ａ及び１０１Ｅは、システム内ですでにコミッショニングされている。インストーラー６１０は、単一のシステムデバイス１０１Ｂをコミッショニングすることを意図しているが、誤ってシステムデバイス１０１Ｂとシステムデバイス１０１Ｆの両方のコミッショニング要求を送る。システムデバイス１０１Ｂ及び１０１Ｆの両方とも、関連付け要求を送信し得る。システムはまた、システムデバイス１０１Ｂ及び１０１Ｆ並びに／又はシステムデバイス１０１Ａ及び１０１Ｅから信号強度情報を受信し、この情報を分析して、インストーラーが単一のシステムデバイスではなく２つのシステムデバイスをコミッショニングしたと判断する。しかしながら、システムデバイス１０１Ｂ及び１０１Ｆのうちの１つのみが、システムデバイス１０１Ａ及び１０１Ｅからの信号強度情報とマッチし、斯くして、システムは、システムデバイス１０１Ｂが意図したデバイスであると判断してもよい。
本方法のステップ１３６２において、システムは、間違ったシステムデバイスが関連付け要求で選択されたと判断した場合、システムは、間違ったシステムデバイスがコミッショニングのために選択されたことをインストーラーにアラートする。例えば、システムは、インストーラーのコミッショニングデバイスに、誤ったシステムデバイスが、選択された位置に対してコミッショニングされたことを示すアラートメッセージをポップアップさせてもよい。別の実施形態によれば、システムは、デバイスをコミッショニングせずに、アラートメッセージを送信してもよい。アラートは、視覚的アラート、触覚アラート、可聴アラート、メッセージ、テキストメッセージ、又は任意の他のアラートであってもよい。アラートは、インストーラーのコミッショニングデバイスに表示されたマップ上のインジケーションなど、どのシステムデバイスがコミッショニングのために誤って選択されたかに関する情報を含んでもよい。
本方法のオプションのステップ１３６４において、システムは、インストーラーによって選択された位置に基づいて、どのシステムデバイスがコミッショニングされることが意図されたかに関する提言(recommendation)をインストーラーに行ってもよい。これは、ステップ１３６２でアラートと共に提供されてもよいし、インストーラーからの要求に応じて提供されてもよい。一実施形態によれば、システムは、正しいシステムデバイスを自動的にコミッショニングしてもよい。その後、システムは、違うシステムデバイスがコミッショニングされたが、これは選択された位置に適切なシステムデバイスであることをインストーラーにアラートしてもよい。
様々なクラウドベースのシステムアプリケーションモジュール間の例示的な対話
図６は、物理的環境の監視及び制御のための例示的なクラウドベースのシステムによって利用されてもよい、様々なクラウドベースのシステムアプリケーションモジュールの対話の一実施形態を示す。これらのクラウドベースのアプリケーションのうちの一部は、図１との関連において既に論じられている。図６は、追加的モジュール、並びに、既に論じられているモジュールに関する、それらの互いに対する対話及びそれらの例示的な使用などの、更なる詳細を提供する。図６に示されるユーザＡ、ユーザＢ、ユーザＣ、及びユーザＤは、それぞれが異なる役割に関連付けられているユーザである。ユーザの役割に基づいて、そのユーザは、アプリケーションモジュールのうちの１つ以上へのアクセスを付与されてもよい。
ユーザＡは、典型的には、物理的環境を監視及び制御するための例示的なクラウドベースのシステムの動作を、ホスト及び／又は他の方式で管理するエンティティ（例えば、会社Ｚ）自体に関連付けられている、運用要員を表す。様々な実施形態では、ユーザＡは、クラウドベースのシステムによって維持及び制御される全てのプロジェクトデータ（例えば、プロジェクト階層）へのアクセスを有する。このユーザＡは、そのクラウドベースのシステムによって監視されている様々なサイトを監視及び制御する際の、エンドユーザの日々の業務を維持する際に、他の全てのユーザ、特にユーザＤをサポートする。ユーザＢは、インテーク技術者を表し、この文脈内での主要な機能は、プロジェクト階層内の１つ以上の建物のデジタルモデルを作成することであってもよい。ユーザＣは、インストーラー又はコミッショニング技術者などの人物であり、その主要なタスクは、作成された建物のデジタルモデルに基づいて、建物内に物理的及び論理的にデバイスをインストールし、その後、コミッショニング、コンフィギュレーション、及び展開のプロセスに関与することであってもよい。ユーザＤは、施設管理、財務、又は、エンティティ／顧客（例えば、会社Ｘ）に関する持続可能性などの部門からの人員であり、この例示的なクラウドベースのエンドユーザである。
図１との関連で前述されたユーザ管理アプリケーションモジュール１５０は、様々な実施形態では、システム管理者又は同様に資格認定された何らかの人物が、物理的環境を監視及び制御するためのクラウドベースのシステムに関する、新たなユーザアカウントを作成することを可能にする、クラウドベースのソフトウェアモジュールである。例えば、システム管理者は、新たなユーザ（例えば、ユーザＬ）を作成し、そのユーザに、ユーザ名及び一時パスワードなどのクレデンシャルを割り当ててもよく、それにより、ユーザＬは、その後、システムログインアプリケーションモジュール６１０を使用して、図６に示されるクラウドベースのシステムアプリケーションモジュールのうちの１つ以上へのアクセスを得ることができる。
システムユーザアプリケーションモジュール６３０は、様々な実施形態では、１つ以上のプロジェクト階層、サイト、又は建物を、ユーザに割り当てるために使用される。このクラウドベースの監視及び制御システムの様々な実施形態では、プロジェクト階層は、階層のルートである。各プロジェクト階層は、１つ以上のサイトを含んでもよく、各サイトは、１つ以上の建物を含んでもよく、各建物は、１つ以上のフロアを含んでもよい。ユーザ（例えば、ユーザＬ）が、プロジェクト階層ＰＨに割り当てられる場合には、そのユーザは、自身の役割に基づいて、プロジェクト階層ＰＨの様々なフィーチャへのアクセスを有することになる。ユーザのアクセス権はまた、カスタマイズされた方式で制限されてもよい。例えば、ユーザＬがサイト１に割り当てられる場合、そのユーザは、サイト１に関連付けられている建物のみへのアクセスが許可されてもよく、サイト１が属するプロジェクト階層内の、他のサイトへのアクセスは許可されない。
図１との関連で前述されたシステムプロジェクトアプリケーションモジュール１４０は、他の全てのシステムアプリケーションモジュールへのアクセスを制御する、中心システムアプリケーションモジュールである。ユーザが、クラウドベースの監視及び制御システムにログインする際に、そのユーザによって遭遇されるアプリケーションモジュールは、システムプロジェクトアプリケーションモジュール１４０である。ユーザは、自身が割り当てられているプロジェクト階層、サイト、又は建物のみを、見る及び／又は操作することが可能となる。様々な実施形態では、様々なプロジェクト階層、サイト、及び／又は建物へのユーザの割り当ては、そのユーザのログインクレデンシャル（例えば、ユーザＩＤ）に関連付けられているが、システムマップアプリケーションモジュール１６０又はシステムインテークアプリケーションモジュール１３０などの１つ以上のシステムアプリケーションモジュールにアクセスするための、そのユーザの能力は、自身に割り当てられている役割（例えば、インストーラー又はインテーク技術者）に関連付けられている。ユーザが、システムプロジェクトアプリケーションモジュール１４０にアクセスし、例えば、そのユーザが割り当てられている１つのプロジェクト階層（例えば、ＭｅｇａＣｏｒｐ）を提示されると、そのユーザは、グラフィカルユーザインタフェース上で自身に提示されているユーザインタフェース要素を介して、そのプロジェクト階層を選択することができる。次いで、プロジェクト階層ＭｅｇａＣｏｒｐに関連付けられている様々なサイト（例えば、ロンドン及び上海）が提示されてもよい。ロンドンのサイトをクリックすることは、例えば、そのロンドンのサイトに関連付けられている様々な建物（例えば、建物１及び建物２）のグラフィック表現（例えば、アイコン）を、ユーザに提示することになる。多くの実施形態では、ユーザに提示されるシステムプロジェクトアプリケーションモジュール１４０のグラフィカルユーザインタフェースは、ユーザの役割及び／又はログインクレデンシャルに基づいて、そのユーザがアクセスを有する他のシステムアプリケーションモジュール（例えば、システム運用アプリケーションモジュール６２０又はシステムエネルギーアプリケーションモジュール１２０）にアクセスするための１つ以上の方法を、ユーザに提供することになる。
システムインテークアプリケーションモジュール１３０は、図１との関連で前述されている。多くの実施形態では、このアプリケーションモジュールは、運用要員又はインテーク技術者の役割を割り当てられているユーザなどの、適切に資格認定されたユーザが、サイト及びプロジェクト階層内の建物のデジタルモデルを作成することを可能にする。そのような実施形態では、このことはまた、そのユーザがまた、その建物にシステムプロジェクトアプリケーションモジュール１４０を介してアクセスするための、クレデンシャルを有さなければならないことも意味する。必要なクレデンシャルが存在していると想定すると、ユーザ（例えば、ユーザＬ）は、選択された建物の様々な物理フロアをグラフィカルかつ論理的に表現するためのフロアプランを、そのユーザが追加することを可能にする、ユーザインタフェースを提示されることになる。特定の建物のフロアに関するフロアプランが選択されると、次いで、ユーザは、そのフロアプラン内の様々な領域をグラフィカルに細分化して、様々なタイプの空間（例えば、セル式オフィス、オープンプラン式オフィス、会議室、又は廊下）を描写するように進むことができる。ユーザは、そのフロアの仮想レイアウトを、グラフィカルに作成している。様々な実施形態では、ユーザはまた、適切なユーザインタフェース要素及び機能性（例えば、ドラッグアンドドロップ、カットアンドペースト、照明器具及び無線ゲートウェイなどの個々のデバイスを表すアイコン）も提示されることにより、ユーザは、フロアプラン上の多数の部屋又は領域内の特定の場所に、ゲートウェイ、照明器具、照明器具のグリッド、スイッチ、光センサ及び占有センサなどのシステムデバイスを、グラフィカルに描写することができる。様々な態様では、空間内での照明器具などのデバイスの挙動（例えば、特定の廊下内の照明器具が、どのように占有の変化に対応するか）を指示する、コンフィギュレーションデータもまた、この段階で種々の領域（例えば、オフィス、廊下、開放空間）に関連付けられる。システムインテークアプリケーションモジュール１３０はまた、照明器具及びセンサなどの個々のデバイスの挙動（例えば、光出力）を更に制御するための、追加コンフィギュレーションデータを関連付けるために使用されてもよい。様々な実施形態では、アプリケーションモジュール１３０は、運用要員又はインテーク技術者の役割を割り当てられているユーザのみがアクセス可能である。
多くの実施形態によれば、図１との関連で前述されたシステムマップアプリケーションモジュール１６０は、典型的には、クラウドベースの監視及び制御システムに関連付けられたプロジェクト階層の一部である建物の現場にいる間に、インストーラーなどのユーザによって使用される。多くの実施形態では、インストーラーは、建物内に入り、例えばシステムインテークアプリケーションモジュール１３０を使用して作成された、その建物のデジタルモデルのグラフィック描写上に示されている場所に、物理的にデバイスをインストールする。システムマップアプリケーションモジュール１６０は、その後、図４及び図５との関連で前述され、また図１０、図１１、及び図１２との関連でも説明される、コミッショニング、ローカライズ、及び展開のプロセスを支援する。様々な実施形態では、アプリケーションモジュール１６０を使用して、インストーラーは、適切なデジタルフロアプランを識別し、このことは、フロアプラン上の領域である全てのシステムデバイスの可視化をもたらす。コミッショニングプロセスは、目下の建物に関連付けられている建物サーバ（例えば、建物サーバ１００）から開始して、次いで、様々な無線ゲートウェイ、並びに照明器具及びスイッチなどの関連システムデバイスへと続く。前述のように、インストーラーは、スマートフォン又はタブレットなどのモバイルコンピューティングデバイスを使用して、そのインストーラーがコミッショニング及びローカライズすることを望んでいる特定の物理デバイスを、アプリケーションモジュール１６０のユーザインタフェース上で選択することによって、選択する。次いで、インストーラーは、スマートフォン又はタブレット上のカメラを使用して、そのデバイス上のＱＲ（Ｑｕｉｃｋ Ｒｅｓｐｏｎｓｅ（登録商標））コードの写真を撮影するように進み、このことが、様々な他の図に関連して及び本明細書の全体を通して詳細に論じられる、コミッショニング、ローカライズ、及び展開のプロセスを開始させる。このＱＲコードは、純粋に例として使用されるものであり、任意の他のコードが同様に使用されてもよい。様々な実施形態では、システムマップアプリケーションモジュール１６０は、運用要員又はインストーラーの役割を有するユーザのみがアクセス可能である。
システムエネルギーアプリケーションモジュール１２０は、多くの実施形態では、エンドユーザによって、典型的には、クラウドベースの監視及び制御システムの動作をホスト及び／又は他の方式で管理するエンティティ（例えば、会社Ｚ）に関連付けられている、運用要員、あるいは、クラウドベースの監視システムによって建物が監視されている特定のプロジェクト階層に関連付けられた、エンドユーザエンティティに関連付けられている、施設管理要員によってアクセスされてもよい。したがって、様々な実施形態では、適切な役割（例えば、運用要員又は施設管理者）及び適切なアクセスクレデンシャルを有するユーザのみが、アプリケーションモジュール１２０へのアクセスを許可される。そのような実施形態及び他の実施形態では、監視されている全てのシステムデバイス及び領域からの、空間及びリソース利用データは、それらの対応のゲートウェイ及び建物サーバを介して、このクラウドベースの監視システムに関連付けられているクラウド（例えば、図１に示されるクラウド１１５）に転送され、そのクラウドで、それらのデータが分析される。有用な分析を導き出すために、統計的分析及び機械学習技術が採用されてもよく、次いで、それらの分析は、過去の使用、将来のエネルギー消費の予測、及び現在の（リアルタイムの）エネルギー利用を示す、グラフ及び他の視覚化モードの形態で、エンドユーザに提示される。占有データと共に分析されたエネルギー消費データは、殆ど利用されていない物理的領域及びリソースを明らかにすることができ、それゆえ、将来のエネルギー利用を低減させる方策に寄与することが可能である。
システム運用アプリケーションモジュール６２０は、多くの実施形態では、典型的には、クラウドベースの監視システムの動作をホスト及び／又は他の方式で管理するエンティティ（例えば、会社Ｚ）に関連付けられている、運用要員（例えば、図６に示されるユーザＡ）のみがアクセス可能である。このアプリケーションモジュールは、不適切な光レベル、エネルギー及び占有データの収集若しくは分析におけるエラー、又は不正確なコミッショニング、ローカライズ、又は展開などの実行時問題を、リモートでトラブルシューティングし、診断し、対処するための、ユーザインタフェース及びバックエンド論理をユーザに提供する。
展開
図７Ａ〜図７Ｃは、図１に示された物理的環境を監視及び制御するためのクラウドベースのシステムの、展開の一実施形態を示す。図７Ａに示されるクラウドモジュールは、図１との関連で説明されたクラウド１１５と同様である。システムプロジェクトアプリケーションモジュール１４０、システムインテークアプリケーションモジュール１３０、システムマップアプリケーションモジュール１６０、システム運用アプリケーションモジュール６２０、システムエネルギーアプリケーションモジュール１２０、クラウド接続性サービスモジュール１９０、データプラットフォームモジュール１８０及びプロジェクト１７０Ａは、図１及び図６に示されている同一名称のモジュールと同様である。プロジェクトサービスモジュール７０８は、システムインテークアプリケーションモジュール１３０及びシステムマップアプリケーションモジュール１６０などの様々なシステムアプリケーションモジュールが、ＤｙＮｅｔ（登録商標）及びＺｉｇＢｅｅ（登録商標）などの複数の通信プロトコルをサポートすることを可能にする。このモジュールは、本質的に、それらのシステムアプリケーションモジュールが、それらの機能をプロトコル非依存方式で実行することを可能にする。また、プロジェクト１７０Ａデータベースとシステムアプリケーションモジュールとの間の、データの通信も容易にする。
展開構想エンジンモジュール７１１は、感知デバイスなどのシステムデバイスに関する、コンフィギュレーションファイルの生成に関与する。これらのコンフィギュレーションファイルは、個々の感知器又は感知器群に適用可能であり、アンビエント照明、占有、時刻などにおける変化などのイベントに応答して、それらの挙動を制御するために使用される。プラグイン構想モジュール７０９は、展開構想エンジンモジュール７１１が、プロジェクトサービスモジュール７０８とシームレスに通信することを可能にする、プラグインモジュールである。換言すれば、このプラグインは、展開構想エンジンモジュール７１１及びプロジェクトサービスモジュール７０８の双方と通信することができるため、プロジェクトサービスモジュール７０８は、展開構想エンジンモジュール７１１の実装又はアーキテクチャに全く依存せずに、実装されることができる。データ分析構想モジュール７１４は、建物サーバ及びゲートウェイを経て全ての感知デバイスから収集された、エネルギー及びリソース使用情報に対して、必要な分析を実行し、その分析されたデータを、システムエネルギーアプリケーションモジュール１２０に提示するために利用可能にする。
登録、ユーザ認証、及びデバイス認可の概説
図７Ａに示されるデバイス７０１は、各プロジェクト階層に関連付けられている、様々な建物サーバ（例えば、建物サーバ１００）、ゲートウェイ（例えば、ゲートウェイ１１０Ａ）、及びシステムデバイス（例えば、システムデバイス１０１）の全てに関連する情報を保持するようにコンフィギュレーションされている、データベースモジュールである。例えば、特定の建物サーバが、特定のプロジェクト又はサイトに関するリソース及びエネルギー管理の目的で利用されることが可能となる前に、その建物サーバ自身をクラウド（例えば、クラウド１１５）に登録することが必要となる。この登録プロセスは、図８Ａ、図８Ｂに付随する説明で更に詳細に説明される。図１のクラウドベースのシステムの登録ユーザに関連付けられている情報（例えば、ユーザ名、パスワード、役割）は、図７Ａに示されるユーザ７０２データベースモジュール内にセキュアに記憶されている。様々な実施形態では、この情報は、認証プロセス中に、ユーザが、例えば、クラウドベースのシステムアプリケーションモジュールのうちの１つ以上（例えば、システムマップアプリケーションモジュール１６０）にアクセスすることを望む場合に、アイデンティティ管理モジュール７０５によってアクセスされる。標準的な認証技術が、アイデンティティ管理モジュール７０５によって採用されてもよい。様々な実施形態では、Ｆｏｒｇｅｒｏｃｋ ＯｐｅｎＡＭ／ＤＪモジュール７０６は、物理的環境を監視及び制御するための例示的なシステムにおいて自身の役割を実行するために、クラウドへのアクセスを求める様々なデバイス（例えば、建物サーバ及び無線ゲートウェイ）のアイデンティティに対して、適切な認可を保証することを担当している。そのような実施形態では、ポリシーエージェントモジュール７０７は、図示の様々なシステムアプリケーションモジュールにアクセスするための認可を、ユーザに付与することを支援する。例えば、ユーザが適切に認証され、最初のシステムプロジェクトアプリケーションモジュール１４０へのアクセスを得た後であっても、システムインテークアプリケーションモジュール１３０及びシステムマップアプリケーションモジュール１６０などの他のシステムアプリケーションモジュールへの更なるアクセスは、そのユーザが割り当てられている役割に基づいて制限される。役割は、図６に関連付けられている説明で、更に詳細に説明されている。多くの実施形態では、様々な役割に関連付けられたアクセスポリシーが、ＵＲＬを介してコンフィギュレーション／実装されている。例えば、システムプロジェクトアプリケーションモジュール１４０の様々な態様は、それぞれ異なるＵＲＬでアクセスされることが可能であると想定する。管理者の役割を割り当てられているユーザは、これらの異なるＵＲＬ（それぞれが、システムプロジェクトアプリケーションモジュール１４０によって提供される様々な機能性に、ユーザがアクセスすることを可能にする）の全てにアクセスする能力を付与されてもよいが、インストーラーを割り当てられているユーザは、これらのＵＲＬのうちの２つへのアクセスのみが付与されてもよい。ポリシーエージェントモジュール７０７は、各役割がアクセスすることが可能な機能に対して、予め設定されたコンフィギュレーション可能なポリシーを施行する。
ファームウェア／ソフトウェアのイメージ及び更新
図７ＡのＦＷイメージ７００データベースモジュールは、建物サーバ、ゲートウェイ、並びにシステムデバイスの、ファームウェア及び／又はソフトウェアを更新するためのイメージを記憶する。ＦＷ／ＳＷの更新プロセスは、クラウドのＳＷ更新モジュール７０３から建物サーバへの、ＭＱＴＴプロトコルを介したトリガで開始する。様々な実施形態では、このトリガは、必要な更新イメージを取得するためのＵＲＬを含み得る。建物サーバのファームウェア更新の場合には、クラウド内のＳＷ更新モジュール７０３は、ＭＱＴＴを介してトリガを送信することになり、建物サーバ内のＦＷ更新ＢＳモジュール７２１は、そのトリガを認識することになり、次いで、建物サーバは、そのトリガ内のＵＲＬを使用して、更新イメージを取得し、その更新イメージのダウンロードを終了したことを、ＭＱＴＴチャネルを使用してクラウドに報告を返すことになる。これらの実施形態では、クラウド内のＳＷ更新モジュール７０３は、その後、ＭＱＴＴを介して明示的なトリガを送信することになり、そのトリガを受信すると、建物サーバは、新たな更新イメージに切り替えるために必要とされるタスクを実行する（例えば、再起動して、新たなイメージのアプリケーションに切り替える）ことになる。無線ゲートウェイのファームウェア更新を実行するためのプロセスは、上述の建物サーバに関するファームウェア更新と同様である。しかしながら、無線ゲートウェイに関する更新プロセスは、建物サーバをプロキシとして使用する。例えば、無線ゲートウェイによるＵＲＬを介したＦＷイメージの取得は、この図中の建物サーバモジュール内に示されるＨＴＴＰプロキシモジュール７１８を介してプロキシされる。
図７Ａに示される建物サーバは、図１との関連で説明された建物サーバ１００と同様である。この建物サーバの実施形態は、ソフトウェアの更新、デバイスの登録、及びデータ収集を容易にする役割を果たす、様々なモジュールを示している。ＨＴＴＰプロキシモジュール７１８及びＭＱＴＴプロキシモジュール７２０は、それぞれ、ＨＴＴＰプロトコル及びＭＱＴＴプロトコルを使用して、１つ以上の無線ゲートウェイとクラウドとの間の通信をプロキシする。例えば、図７Ａの建物サーバに関連付けられている無線ゲートウェイ内のＭＱＴＴクライアントから発せられる通信は、その建物サーバのＭＱＴＴプロキシモジュール７２０によってルーティングされる。多くの実施形態では、監視されている物理的環境内の１つのデバイス（例えば、建物サーバ）のみが、その環境を監視するために使用されているクラウドへの直接アクセスを有することになる。様々な無線ゲートウェイ及びシステムデバイスからの全てのデータは、その建物サーバを介してプロキシされることになる。そのような実施形態では、無線ゲートウェイ及びシステムデバイスは、クラウド非依存性である。換言すれば、それらは、クラウドに直接接続するためのデータ又は論理を有する必要がない。デバイス登録モジュール７１６は、クラウドへの建物サーバの登録を組織化する。このプロセスは、図８Ａ、図８Ｂに付随する説明で、より詳細に説明される。フィールドネットワーク発見モジュール７１７は、ネットワーク内のデバイスを発見するプロセスに関与する。ネットワークプロバイダモジュール７１９は、クラウド内のプラグイン構想モジュール７０９からコンフィギュレーションデータを受信し、このデータをシステムデバイス（例えば、感知デバイス）に転送することを担当している。更には、ネットワークプロバイダモジュール７１９は、クラウドと無線ゲートウェイとの間の双方向通信を容易にする。例えば、このモジュールは、感知器、無線ゲートウェイ、及び建物サーバ内から発せられるＳｉｇｎＯｎメッセージを、プラグイン構想モジュール７０９を介してクラウドに送信することができる。同様に、ネットワークプロバイダモジュール７１９はまた、クラウドからのコマンド（例えば、ＺｉｇＢｅｅネットワークを開くコマンド）を、無線ゲートウェイに伝搬することもできる。
フェイルオーバモジュール７２６及び回復モジュール７２８は、建物サーバの動作におけるエラーを検出して、そのエラーから回復することを、一体となって担当している。一部の実施形態では、１つ以上の重要なソフトウェアプロセスの動作は、タイマによって継続的に監視される。エラー条件によりプロセスが停止する場合には、タイマもまた停止する。タイマの停止は、１つ以上のプロセス又は建物サーバ自体が、エラー条件から回復するために再起動する結果をもたらす、トリガである。ＢＳ診断モジュール７２７は、その建物サーバのルーチン動作についての情報を収集する。例えば、多くの実施形態では、動作エラーを診断する際に役立ち得るエラーメッセージが収集される。これらのメッセージは、システムエネルギーアプリケーションモジュール１２０などのシステムアプリケーションモジュールによる、分析及び視覚化のために、定期的にクラウドに送信される。建物サーバ内のスケジューリングモジュール７２９は、占有又は昼光の変化などのイベントに基づいた、物理的環境（例えば、建物）内の通常の挙動をオーバーライドするタスクのスケジューリングに関与している。一部の実施形態では、スケジューリングモジュール７２９は、建物サーバ内で実行されるが、他の実施形態では、クラウド内で実行される。
図７Ｂ及び図７Ｃに示されるゲートウェイ（例えば、無線ゲートウェイ）は、図１との関連で前述されたゲートウェイ１１０Ａ及びゲートウェイ１１０Ｂと同様である。図７Ｂ及び図７Ｃは、無線ゲートウェイの様々なモジュールを示す。本明細書の全体を通して説明される殆どのモジュールと同様に、これらのモジュールは、ファームウェアとして、又は完全にソフトウェアとして実装されてもよい。完全にソフトウェアとして実装される場合には、それらは、その無線ゲートウェイ自体に物理的に配置された１つ以上のプロセッサ上で、又は、その無線ゲートウェイからリモートであるが、アクセス可能に配置された１つ以上のプロセッサ上で実行されてもよい。無線ゲートウェイのＮＴＰクライアントモジュール７３５は、感知器などのシステムデバイスに時刻データをプッシュすることに関与している点で、建物サーバ内の同様に名付けられたモジュールと同様である。無線ゲートウェイのＺｉｇＢｅｅクロック同期サーバモジュール７３６もまた、この時刻同期関連プロセスに関与しており、その関与は、無線ゲートウェイのＮＴＰクライアントモジュール７３５と共に、時刻同期についての次のセクションで、より詳細に説明される。無線ゲートウェイのデータ収集モジュール７３３は、システムデバイス（例えば、感知器）からの、エネルギー及び他のメトリックの収集に関与しており、建物サーバを経て、この情報をクラウドに上向きにプッシュしている。その機能性に関する詳細は、メトリックの報告についての以下のセクションで説明される。様々な実施形態では、ＷＧ診断モジュール７３４は、無線ゲートウェイのルーチン動作中に遭遇される、エラー又は他の異常な条件若しくは状態を報告することを、主に担当している。これらのエラー条件又は状態は、その後、更なる分析及び提示のために、建物サーバを介してクラウドに報告される。無線ゲートウェイのＦＷ更新モジュール７３２は、建物サーバ上の同様に名付けられたモジュールのように、その無線ゲートウェイ自体に関する、及び感知デバイスに関する、ファームウェア及びソフトウェアの更新の調整を主に担当している。このプロセスは、図９との関連において、更に詳細に説明される。無線ゲートウェイの発見登録モジュール７３０は、その無線ゲートウェイ自体を建物サーバ及び／又はクラウドに登録する機能を果たす。ＭＱＴＴクライアントモジュール７３１は、無線ゲートウェイから、及び無線ゲートウェイと通信している任意のデバイスから発せられる、ＭＱＴＴプロトコルに基づく通信を、建物サーバのＭＱＴＴプロキシモジュール７２０を介して、建物サーバにルーティングするように機能する。
図７Ｃに示される感知器は、図１との関連で説明されたデバイス１０１〜１０６と同様である。様々な実施形態では、感知器診断モジュール７３７は、感知器の通常動作に関連付けられるエラー状態及びエラー条件を、時刻同期についての以下のセクションで説明されるメトリック報告モジュールに報告する。ＺｉｇＢｅｅクロック同期クライアントモジュール７４３及びＺｉｇＢｅｅクロック同期サーバモジュール７４４もまた、時刻同期についての以下のセクションで説明される。そのような実施形態及び他の実施形態では、ＦＷ更新モジュール７４２は、その感知器のファームウェア及び／又はソフトウェアを更新するプロセスに関与し、このプロセスは、図９に付随する説明で、より詳細に論じられる。センサ７４０は、例えば、赤外線信号、動き又は光強度の変化を感知する。アクチュエータ７３８は、例えば、照明に関連付けられる強度又は他の特性を変更するように、照明器具などのデバイスを作動させる。また、ＨＶＡＣデバイス、ブラインド、カーテン、プロジェクタ、ディスプレイなどの、建物内に見出される様々な他のデバイスも作動させることができる。制御構想モジュール７３９は、多くの実施形態によれば、クラウド内の展開構想エンジンモジュール７１１及びプラグイン構想モジュール７０９から、建物サーバ及びゲートウェイを介して感知器に渡された、コンフィギュレーションデータ（例えば、コンフィギュレーションファイル）を適用する機能を果たす。そのような実施形態では、そのコンフィギュレーションファイルは、占有、温度、又は移動の変化などの、様々な照明条件及び環境条件に対する、特定の感知器又は感知器群の応答を詳述している。
時刻同期
多くの実施形態では、図７Ａの建物サーバの一部として示されるＮＴＰクライアントモジュール７２３は、時刻同期の目的で使用される。このモジュールは、インターネットなどのネットワーク上のＮＴＰサーバモジュール７１５、図７Ａに示される建物サーバの同じく一部であるＮＴＰサーバモジュール７２５、並びに、図７Ｂの無線ゲートウェイＷＧの一部として示されるＮＴＰクライアントモジュール７３５及びＺｉｇＢｅｅクロック同期サーバモジュール７３６と共に機能する。ＮＴＰとは、一般に、コンピュータシステム間のクロック同期のために一般的に使用されるネットワークプロトコルである、既知のネットワークタイムプロトコルを指す。ＮＴＰは、典型的には、コンピューティングデバイスを、協定世界時（Coordinated Universal Time；ＵＴＣ）の数ミリ秒の範囲内で同期させるように機能する。ＮＴＰは、クライアント−サーバモデルの下で動作してもよいが、また、複数のデバイスが潜在的な時間ソースと見なされてもよい、ピアツーピアの解決策で使用されることも可能である。
多くの実施形態では、感知器から収集されたエネルギー及びリソース使用データを正確にタイムスタンプするためには、全ての感知器、無線ゲートウェイ、及び建物サーバを定期的に同期させることが不可欠である。最初に、現在時刻データが、クラウド又は建物サーバの外部に存在するように示されている、ＮＴＰサーバモジュール７１５から取得される。一般に、そのようなＮＴＰサーバは、インターネット上に存在している。様々な実施形態では、建物サーバのＮＴＰクライアントモジュール７２３が、その現在時刻データを受信する。次に、この現在時刻データは、建物サーバ内のＮＴＰサーバモジュール７２５によって受信された後に、図７Ｂに示される無線ゲートウェイのＮＴＰクライアントモジュール７３５に通信される。無線ゲートウェイ内で、この現在時刻データは次に、ＺｉｇＢｅｅクロック同期サーバモジュール７３６に通信される。その後、この無線ゲートウェイの最も近くに存在している感知デバイスを識別するために、レベル発見段階が開始される。多くの実施形態では、このことは、無線ゲートウェイが、特定のレベル（例えば、その無線ゲート自体に関連付けられているレベル０）を有するブロードキャストコマンドを、ＺｉｇＢｅｅを介して送信することによって達成される。無線ゲートウェイに最も近い感知デバイスが、そのブロードキャストコマンドを受信すると、それらの感知デバイスは、それら自身のレベルを１に増大させ、次いで、レベル１を有する同じ又は同様のメッセージを再ブロードキャストする。その再ブロードキャストメッセージを受信する感知デバイスは、その後、自身をレベル２に識別して、再度、そのメッセージを再ブロードキャストすることになる。このプロセスは、全ての近傍感知デバイスが識別されて、レベルに関連付けられるまで継続する。このレベル発見段階に続く第２段階は、既知のペアワイズ時刻同期アルゴリズムを使用することを伴う、同期段階である。同期プロセスの一部として、第１のレベルの１つ以上の感知器の、ＺｉｇＢｅｅクロック同期クライアントモジュール７４３が、無線ゲートウェイのＺｉｇＢｅｅクロック同期サーバモジュール７３６から、現在時刻データを受信する。この情報は、次いで、それらの感知器自身によって、ピアツーピアで伝搬される。これは、図７Ｃに矢印線で示されるように、特定の感知器のＺｉｇＢｅｅクロック同期サーバモジュール７４４が、この情報を、近傍の感知器内のＺｉｇＢｅｅクロック同期クライアントモジュール７４３による受信のために、ＺｉｇＢｅｅネットワークを介して通信する結果であってもよい。
メトリック報告
様々な実施形態では、感知器は、エネルギーデータ及び／又は占有データを定期的に報告することになる（例えば、エネルギーデータは１５分ごとに、占有データは５０秒ごとに報告されてもよい）。各感知器の一部として図７Ｃに示されるメトリック報告モジュール７４１は、ＺｉｇＢｅｅクロック同期クライアントモジュール７４３から時刻データを受信し、次いで、その時刻データが、報告されるエネルギー又はリソース使用データに、タイムスタンプとして追加される。感知器診断モジュール７３７もまた、その感知器自身の動作に関する診断データを、メトリック報告モジュール７４１に提供する。この診断データは、通常の方式で感知又は作動することが不可能であることなどの、その感知器のルーチン動作に関する潜在的問題又は既知の問題を示す、エラーメッセージであってもよい。多くの実施形態では、メトリックデータは、各感知器から以下の方式で送信される。まず、いくつかの異なるパケットタイプ、すなわち、アドレス情報を送信するためのパケットタイプ、第１のメトリックを有するフルタイムスタンプを送信するための別のパケットタイプ、及び、更なるメトリックを有する時間オフセットを送信するための更に別のパケットタイプが利用される。典型的実施形態では、感知器のメトリック報告モジュール７４１が、例えば、エネルギー使用に関するメトリックを報告する場合、最初に、そのメトリックを発信する感知デバイスを識別するために必要なアドレス情報を有する、第１のメッセージを送信する。その後、エネルギー使用に関する第１のメトリックを有する、フルタイムスタンプが送信される。最後に、エネルギー使用に関する第２のメトリックが、第１のメトリックの送信から経過した時間を示す、時間オフセットデータと共に送信される。メトリックデータは、無線ゲートウェイのデータ収集モジュール７３３によって受信される。
一部の実施形態では、感知器は、メトリックデータを報告する際に、自身を無線ゲートウェイに一意に識別させるいずれのアドレス情報も、自身では提供しない。そのような実施形態では、無線ゲートウェイ内の（図７Ｂ及び図７Ｃに示される）データ収集モジュール７３３が、感知器に関するグローバル一意アドレスを、その報告されたメトリックに添付するか又は別の方式で関連付ける。無線ゲートウェイ内のデータ収集モジュール７３３はまた、その無線ゲートウェイ自身のアドレス情報も添付してもよい。様々な実施形態では、この無線ゲートウェイのアドレス情報と特定の感知器又は感知器群に関連付けられたアドレスとの組み合わせは、報告されている特定のメトリック又はメトリックの集合に関連付けられるアドレスの、グローバルに一意な性質を結果としてもたらすものである。無線ゲートウェイ内のデータ収集モジュール７３３は、典型的にはＺｉｇＢｅｅプロトコルを使用して、感知器から情報を受信するが、建物サーバには、典型的にはＨＴＴＰＳを使用して情報を提供する。
定期的に、無線ゲートウェイのデータ収集モジュール７３３は、建物サーバ内のデータ収集モジュール７２４にデータを送信する。様々な実施形態では、無線ゲートウェイは、この情報を定期的にプッシュする。他の実施形態では、建物サーバが、この情報を無線ゲートウェイから引き出す。メトリックデータを受信した後、建物サーバのデータ収集モジュール７２４は、アドレス情報に、その建物サーバ自身のアドレスを追加する。このアドレス情報は、無線ゲートウェイから受信される受信メトリックのそれぞれに追加されてもよく、又は、メトリックのバッチ全体に一括して追加した後に、そのメトリックのバッチをクラウドに送信してもよい。多くの実施形態では、建物サーバは、全ての受信メトリックを短い期間（例えば、５秒間）で収集した後に、それらのメトリックを、クラウドのデータプラットフォームモジュール１８０にバッチ送信する。そのような実施形態では、ある期間にわたってクラウドとの接続性が欠落する場合には、その建物サーバに関連付けられている全ての無線ゲートウェイから受信されたメトリックデータは、最大継続時間（例えば、２４時間）にわたってバッファリングされることになる。クラウドとの接続性が再確立されると、建物サーバは、バッファリングされたメトリックデータを、クラウドにプッシュすることになる。多くの実施形態では、そのようなバッファリングはまた、無線ゲートウェイと建物サーバとの間の接続性が中断された場合のデータ損失を防止するために、無線ゲートウェイでも利用可能である。
建物サーバの登録及び接続
図８Ａ及び図８Ｂは、物理的環境を監視及び制御するためのクラウドベースのシステムのクラウド（例えば、図１のクラウド１１５）に、建物サーバを登録及び接続する方法の、一実施形態を示す。双方の図の上部のボックスは、施設内部の建物サーバ（例えば、図１の建物サーバ１００）と、例えば図１のクラウド１１５に関連付けられている、様々なクラウドベースのモジュールとを表す。デバイス登録モジュール７０４、アイデンティティ管理モジュール７０５、データプラットフォームモジュール１８０は全て、図７Ａとの関連で前述された同一名称のクラウドベースのモジュールの実施形態である。
図８Ａに示されるように、建物サーバ１００は、建物サーバの全てのベンダにわたって、その建物サーバを一意に識別する、ローカルに保存されているＭＡＣアドレスを取得する（建物サーバＩＤを取得する（））。その後、建物サーバ１００は、例えばＡＰＩコールによって、例えば、デバイスｔｏサービス通信を開始する（登録する（））。多くの実施形態では、クラウド（例えば、クラウド１１５）内のデバイス登録モジュール７０４は、登録プロセスを開始するために建物サーバ１００が呼び出すＡＰＩを本質的に公開する。様々な実施形態では、建物サーバ１００は、自身をクラウドに登録するために、その取得された建物サーバＩＤ（例えば、６４ビットＭＡＣアドレス）、建物サーバであることを示すデバイスタイプ、及び鍵付きハッシュメッセージ認証コード（ＨＭＡＣ）を通信する。ＨＭＡＣは、秘密鍵と組み合わせてハッシュ関数を使用する、既知の暗号メッセージ認証コードである。これは、メッセージ認証及びデータ完全性の双方を検証するために使用される。ＨＭＡＣは、ＭＤ５又はＳＨＡ−１などの、任意の既知の暗号学的ハッシュ関数を使用して算出されてもよい。様々な実施形態では、デバイス登録モジュール７０４は、各建物サーバに関する秘密暗号鍵を記憶しているデータベースへのアクセスを有する。各建物サーバは、それ自身の秘密暗号鍵のコピーへのアクセスを有するが、いずれの他の建物サーバの暗号鍵へのアクセスも有さない。クラウド上のデバイス登録モジュール７０４は、その後、受信された建物サーバＩＤ及びＨＭＡＣが、互いに関連付けられていることを検証する（ＢＳＩＤ及びＨＭＡＣを検証する（））。そうすることで、デバイス登録モジュール７０４は、建物サーバ１００を認証する。このプロセスの間に、デバイス登録モジュール７０４が、検証／認証することが不可能な建物サーバからの複数の登録の試みを受信した場合には、そのような建物サーバからの試みを一時的にブロックしてもよい。
次に、デバイス登録モジュール７０４は、様々なクラウドベースのモジュールと対話する際に、建物サーバＩＤと組み合わせて、その建物サーバの動作ＩＤとして機能することになる、パスワードを作成する（パスワードを作成する（））。多くの実施形態では、次いで、デバイス登録モジュール７０４は、アイデンティティ管理モジュール７０５を呼び出して、屋内空間及びリソース使用を監視するためのクラウドベースのシステム内の建物サーバ１００を表す、新たなアイデンティティを作成させる（アイデンティティを作成する（））。この新たなアイデンティティを案出するために、建物サーバＩＤ及びパスワードが使用される。建物サーバ１００に関する新たなアイデンティティの作成が成功すると、アイデンティティ管理モジュール７０５は、クラウドによって認識されている建物サーバの群に、建物サーバ１００を追加するように進む（群に追加する（））。このことは、その建物サーバＩＤ及び建物サーバの新たに創出されたアイデンティティと、所定の群との間に、データベース内での関連付けを単純に作り出すことによって達成されてもよい。クラウドの一部の実施形態では、クラウドに登録されている各建物サーバは、建物サービス群と称されてもよい群に属している。この群に属していることは、特別なタイプのデバイス、すなわち建物サーバとして、デバイスを識別する１つの方法である。その群への追加の成功に続けて、アイデンティティ管理モジュール７０５は、デバイス登録モジュール７０４に、完了が成功したことを通知する（アイデンティティ管理モジュール７０５からデバイス登録モジュール７０４への点線矢印によって示される）。
その後、デバイス登録モジュール７０４は、建物サーバ１００がセキュアなサーバとして機能するために使用する、暗号証明書を作成する。そのような暗号証明書が作成される様々な方法が存在する。典型的には、証明書は、認証局の秘密鍵を使用して署名及び暗号化されている、公開鍵である。この証明書のユーザ（例えば、建物サーバ１００）は、その真正性の証拠として、他のエンティティに公開鍵を提示することができ、それにより、エンティティが別のエンティティを偽装することを防止する。様々な実施形態では、次いで、デバイス登録モジュール７０４は、建物サーバ１００がクラウドと通信するために使用することが可能な、建物サーバ１００に関して以前に生成したパスワード、作成済みの証明書、暗号化秘密鍵、及びリソースについての情報（例えば、ＭＱＴＴのエンドポイント又はＵＲＬ）を、建物サーバ１００に送信する（デバイス登録モジュール７０４から建物サーバ１００への点線矢印によって示される）。
デバイス登録モジュール７０４からの上記の情報を受信すると、建物サーバ１００は、例えば、予めデバイス登録モジュール７０４と共有している、自身の秘密鍵を使用して、暗号化秘密鍵を復号化する（インストール秘密鍵証明書を抽出する（））。建物自体の内部での（例えば、建物サーバ１００と様々な無線ゲートウェイとの間の）セキュアな通信のために、共有秘密が、これらのデバイス間のセキュアな接続を保証するように使用されてもよい。建物サーバ１００は、建物内で使用するための、そのような共有秘密として、サイト鍵を生成する（インストールサイト鍵を生成する（））。
次に、建物サーバ１００は、例えば、デバイス登録モジュール７０４から受信した、自身の建物サーバＩＤ及びパスワードを提供することによって、アイデンティティ管理モジュール７０５によって自身を認証させることを試みる（認証する（ＢＳＩＤ、パスワード））。認証が成功した場合には、アイデンティティ管理モジュール７０５は、建物サーバ１００が、その後クラウド内のサービスにアクセスするために使用してもよい、アクセストークンを返す（「アクセストークン」と標識された点線矢印によって示される）。
多くの実施形態では、クラウドに関連付けられているデータプラットフォームモジュール１８０にアクセスするために、建物サーバ１００は、第２のアクセスクレデンシャルのセットを有することが必要とされる。このことは、他の全てのクラウドモジュールへのアクセスを得ることに関連するセキュリティと、クラウドのデータプラットフォーム自体へのアクセスに関連付けられるセキュリティとを、本質的に区別するものである。以下の論考は、この追加的なクレデンシャルのセットを付与する結果をもたらすことになる、建物サーバ１００の登録プロセスの一部を論じるものである。このプロセスを開始するために、建物サーバは、例えば、ＡＰＩコールを呼び出して（データプラットフォームをアクティブ化する（ＢＳＩＤ、パスワード））、自身の建物サーバＩＤ並びに自身のパスワードを提供する。この通信は、ＨＴＴＰＳを介して行われてもよい。この通信を受信すると、デバイス登録モジュール７０４は、アイデンティティ管理モジュール７０５を呼び出して、供給されたクレデンシャルを検証する（クレデンシャルを検証する（ＢＳＩＤ、パスワード））。検証されると（アイデンティティ管理モジュール７０５からデバイス登録モジュール７０４への、ＯＫと標識された点線矢印）、デバイス登録モジュール７０４は、建物サーバ１００が、データプラットフォームモジュール１８０との通信に使用するための、別のパスワードを生成するように進む（パスワードを作成する（））。多くの実施形態では、次いで、デバイス登録モジュール７０４は、データプラットフォームモジュール１８０に、以下の情報を提供する：建物サーバＩＤ、データプラットフォームアクセスのための新たなパスワード、及び、建物サーバ１００が属する特定の群についての情報（対象デバイス群（））。多くの実施形態では、この通信は、ＨＴＴＰＳを介して達成されてもよい。この情報を使用して、データプラットフォームモジュール１８０は、その建物サーバとの将来の対話において、建物サーバ１００を識別する際に使用するための、一意のアイデンティティを作成する（ＤＰアイデンティティを作成する（））。この新たなアイデンティティの作成が成功すると、データプラットフォームモジュール１８０は、その旨をデバイス登録モジュール７０４に通知する（データプラットフォームモジュール１８０からデバイス登録モジュール７０４への、ＤＰアイデンティティと標識された点線矢印）。デバイス登録モジュール７０４は、次に、この成功の通知を、その新たに生成された建物サーバのデータプラットフォームクレデンシャルと共に、建物サーバ１００に渡す（デバイス登録モジュール７０４から建物サーバ１００への、ＤＰアイデンティティと標識された点線矢印）。
その後、建物サーバ１００は、データプラットフォームモジュール１８０に自身を直接認証させることを、例えば、データプラットフォームモジュール１８０で、この目的のためのＡＰＩを呼び出すことによって試みる。この建物サーバは、データプラットフォームに、自身の建物サーバＩＤ、及びデータプラットフォームモジュール１８０によって作成されたパスワードを供給する。次に、データプラットフォームモジュール１８０は、建物サーバ１００によって供給されたクレデンシャルを検証し（クレデンシャルを検証する（））、データプラットフォームモジュール１８０との将来の通信の際に建物サーバ１００によって使用されるための、アクセストークンを返す（データプラットフォームモジュール１８０から建物サーバ１００への、データプラットフォームトークンと標識された点線矢印）。
図８Ｂに示されるように、登録の後、建物サーバ１００は、例えば、クラウド接続性サービスモジュール１９０が提供するＡＰＩを使用して、クラウド接続性サービスモジュール１９０のメソッドを呼び出し、自身の建物サーバＩＤと、デバイス登録モジュール７０４によって建物サーバ１００に関して最初に作成されたパスワードとを供給することによって、初めてクラウドに接続する（接続する（ＢＳＩＤ、パスワード））。これに応答して、クラウド接続性サービスモジュール１９０が、認証メソッドを呼び出すことにより、アイデンティティ管理モジュール７０５は、その建物サーバのクレデンシャルを認証するように求められる。この目的のために、建物サーバ１００によって提供された建物サーバＩＤ及びパスワードが使用される（認証する（ＢＳＩＤ、パスワード））。多くの実施形態では、認証プロセスは、ＨＴＴＰＳプロトコルを使用して、アイデンティティ管理モジュール７０５でクラウド接続性サービスモジュール１９０によって開始されてもよい。認証が成功すると、アイデンティティ管理モジュール７０５は、建物サーバ１００の認証が成功したことを示すトークンを、クラウド接続性サービスモジュール１９０に返す（「トークン」と標識された点線矢印によって示される）。受信されたトークンを使用して、次いで、クラウド接続性サービスモジュール１９０は、建物サーバ１００が予め割り当てられている群を、アイデンティティ管理モジュール７０５が取得するように要求する（群を取得する（トークン））。これに応答して、アイデンティティ管理モジュール７０５は、建物サーバ１００が割り当てられている群（例えば、その特定のクラウドに関連付けられている全ての登録済み建物サーバに対する参照を含む群）に対する参照を返す。
様々な実施形態では、上記の情報交換の全てが、ＨＴＴＰＳプロトコルを使用して実施されてもよい。建物サーバ１００に割り当てられている群に対する参照を使用して、クラウド接続性サービスモジュール１９０は、建物サーバ１００の認可を検証することができる（認可を検証する（））。このことを行うために、様々な実施形態では、クラウド接続性サービスモジュール１９０は、建物サーバ１００が正しい認可群に属していることを確認する。建物サーバ及びゲートウェイのようなシステムデバイスは、通常、あるデバイス群に関連付けられている。結果として、いずれかのデバイスが、ＭＱＴＴを使用してクラウド接続性サービスモジュール１９０に接続すると、クラウド接続性サービスモジュール１９０は、そのデバイスが、実際にそのデバイス群の一部であるか否かを確認する。多くの実施形態では、ユーザではなく、デバイス又はサービス（例えば、プロトコル構想プラグイン）のみが、ＭＱＴＴを介してクラウドに接続することを許可される。建物サーバ１００の認可ステータスの検証が成功すると、クラウド接続性サービスモジュール１９０は、接続が成功していることを示す通知を（例えば、ＭＱＴＴを使用して）建物サーバ１００に返信する（クラウド接続性サービスモジュール１９０から建物サーバ１００への、「接続済み」と標識された点線矢印によって示される）。建物サーバ１００は、その後、例えばＭＱＴＴの「発行」メカニズムを使用して、クラウド接続性サービスモジュール１９０を介して「ＳｉｇｎＯｎ」メッセージを発行することができる。「ＳｉｇｎＯｎ」メッセージは、特定の建物サーバに関連付けられている特定のトピックに対して発行される。ＭＱＴＴでは、異なるトピックは、異なるチャネル又は機能性に関連付けられている。様々なデバイスは、それらのチャネル上に発行されたメッセージを受信するために、様々なチャネルに加入することができる。したがって、特定のトピックに加入している全てのデバイスは、建物サーバ１００の「ＳｉｇｎＯｎ」メッセージの通知を受信することになる。しかしながら、建物サーバ１００の、その「ＳｉｇｎＯｎ」メッセージを発行しようという望みに肯定応答する前に、クラウド接続性サービスモジュール１９０は、建物サーバ１００の接続呼び出しに続けて以前に実行したように、認可の検証を再び実行する（認可を検証する（））。認可の検証が成功したことに続けて、肯定応答が建物サーバ１００に返される（クラウド接続性サービスモジュール１９０から建物サーバ１００への、「ＡＣＫ」と標識された点線矢印によって示される）。その後、クラウド接続性サービスモジュール１９０は、建物サーバ１００がそのＳｉｇｎＯｎメッセージを発行することを望むトピックの全ての加入者に、建物サーバ１００のＳｉｇｎＯｎメッセージをプッシュする（建物サーバのＳｉｇｎＯｎ（））。加入者として、プラグイン構想モジュール７０９は、そのＳｉｇｎＯｎメッセージを受信し、受信に肯定応答する（プラグイン構想モジュール７０９からクラウド接続性サービスモジュール１９０への、「ＡＣＫ」と標識された点線矢印によって示される）。建物サーバ１００のＳｉｇｎＯｎを受信すると、プラグイン構想モジュール７０９は、その旨を速やかにプロジェクトサービスモジュール７０８に報告し、それにより、プロジェクトサービスモジュール７０８は、新たなデバイスのＳｉｇｎＯｎを認識して、なんらかの必要なアクションを実施することができる（発見済みデバイスをコールバックする（））。
システムデバイスのソフトウェア又はファームウェアの更新
図９は、感知デバイスなどのシステムデバイス（例えば、図１のデバイス１０１）の、ソフトウェア又はファームウェアを更新する方法の一実施形態を示す。図９に示される矢印は、同じプロセッサ、又は異なるプロセッサであるがアクセス可能なプロセッサ上で、ソフトウェア又はファームウェアの実行部分からアクション又は応答を呼び出すための、関数コール、コマンド、又は任意の他のメカニズムを表し得る。以下の説明では、ＨＴＴＰＳは、例えば、建物サーバとゲートウェイとの間、又は建物サーバとクラウドとの間の、通信プロトコルとして言及される場合がある。しかしながら、ＨＴＴＰＳは、任意の実施形態で使用されてもよい多くのプロトコルのうちの１つである。例えば、ＭＱＴＴもまた、これらの通信に適用可能であってもよい。図の上部に示されているモジュールのうち、特に、ＳＷ更新モジュール７０３、プロジェクトサービスモジュール７０８、及びＳＷイメージ７００の３つは、図１のクラウド１１５又は図７Ａのクラウドなどのクラウド内に存在する、ソフトウェアモジュールである。この図に示されるプロジェクトサービスモジュール７０８は、図７Ａに示されるプロジェクトサービスモジュール７０８と同様である。この図の上部に示されている残りの３つのモジュール又はデバイス、すなわち、ＦＷ更新ＢＳモジュール７２１、ゲートウェイ１１０Ａ、及びシステムデバイス１０１は、建物などの物理的構造内に配置された物理デバイスに関連付けられているプロセッサ上で実行される、物理デバイス又はモジュールを表す。
ＳＷ更新モジュール７０３が、最初に、プロジェクトサービスモジュール７０８に対して、「開く」コマンド又は関数コールを実行する。様々な実施形態では、ＳＷ更新モジュール７０３は、特定の既存のプロジェクト階層を開くことを望む。プロジェクト階層は、図５Ａ〜図５Ｃ及び図６との関連で前述されている。これに応答して、特定のプロジェクトの論理モデルが返され、これを使用して、ＳＷ更新モジュール７０３は、特定のフロアに関連付けられているデータへのアクセス（選択する（フロア））と、その特定のフロア上の１つ以上のシステムデバイス（例えば、感知デバイス）に関連付けられているデータへのアクセス（選択する（システムデバイス））とを得る。
更新ファイルを閲覧する（）の矢印は、ＳＷ更新モジュール７０３が、ＳＷイメージ７００リポジトリから、ＳＷ更新モジュール７０３が予め選択したシステムデバイスに関する更新ファイルのＵＲＬを、要求又は別の方式で取得することを示す。ＳＷ更新モジュール７０３は、その後、建物サーバのＦＷ更新ＢＳモジュール７２１に、そのシステムデバイスの更新ファイルのＵＲＬ、デバイスＭＡＣ、及び通信経路のうちの１つ以上を有する、ＦＷ更新メッセージを送信する（ＦＷ更新（ファイルＵＲＬ、デバイスＭＡＣ、通信経路））。更新されるデバイスが、建物サーバ自体である場合には、通信経路は空であってもよい。ゲートウェイ（例えば、無線ゲートウェイ）が更新される場合には、通信経路は、そのゲートウェイのＩＰアドレスである。また、システムデバイスが更新される場合には、通信経路は、無線ゲートウェイのＩＰアドレス、及び／又はＺｉｇＢｅｅショートアドレスである。様々な実施形態では、ＦＷ更新（ファイルＵＲＬ、デバイスＭＡＣ、通信経路）の矢印は、少なくとも感知デバイスなどのシステムデバイスに関する更新の場合には、ＦＷ更新ＢＳモジュール７２１を完全に迂回して、ゲートウェイのＦＷ更新モジュール７３２を直接呼び出すように進むことになる。この図の場合（例えば、図９示される方法の実施形態）では、建物サーバのＦＷ更新ＢＳモジュール７２１は、ＳＷ更新モジュール７０３によって供給されたデバイスＭＡＣが、建物サーバ（例えば、それ自身）に属しているか否かを判定するためにチェックする（デバイスＭＡＣをチェックする（））。属していない場合には、そのデバイスＭＡＣに関連付けられているデバイスに関する更新ファイルの取得を開始する。ＨＴＴＰＳ取得（ファイルＵＲＬ）の矢印は、ＦＷ更新ＢＳモジュール７２１が、ＳＷ更新モジュール７０３から予め受信されているファイルＵＲＬを使用して、適切な更新ファイルを取得するために、ＨＴＴＰＳプロトコルを使用することを示す。
次に、建物サーバのＦＷ更新ＢＳモジュール７２１が、更新される感知デバイスに関する更新ファイルを取得した実施形態では、建物サーバのＦＷ更新ＢＳモジュール７２１は、適切な無線ゲートウェイ（例えば、更新される感知デバイスに関連付けられているもの）に、その更新ファイルのＵＲＬを通知する（ＦＷ更新（））。デバイスＭＡＣ及び通信経路もまた、この時点で、その無線ゲートウェイに中継されてもよい。これに応答して、無線ゲートウェイは、伝達されたファイルＵＲＬを使用して、建物サーバから更新ファイルを取得する（ＨＴＴＰＳ取得（ファイルＵＲＬ））。代替的実施形態では、この情報を建物サーバに問い合わせることを必要とするのではなく、無線ゲートウェイ自体が、ＨＴＴＰＳサーバを実装してもよい。無線ゲートウェイはまた、新たな更新に関して、建物サーバに定期的にポーリングしてもよい。更には、無線ゲートウェイは、ＴＬＳサーバソケットを実装してもよい。
イメージ通知（）の矢印は、無線ゲートウェイが、更新を必要としている特定の感知器に、利用可能な新しい更新が存在していることを送信するトリガである。感知器（システムデバイス１０１）から発している、次のイメージの問い合わせ（）の矢印は、そのトリガに対する感知器からの応答であり、本質的に、新たな更新に関連付けられている詳細について問い合わせるものである。無線ゲートウェイから発している、次のイメージの問い合わせの応答（）の矢印は、この問い合わせに対する応答である。この応答は、バージョン管理情報（例えば、メジャー及びマイナーバージョン番号）、及びハードウェアＩＤなどの、その更新に関連する情報を含み得る。これらの問い合わせ及び応答は、多くの実施形態では、ＺｉｇＢｅｅプロトコルを使用して遂行される。
この時点で、感知器の更新ファイルに関連付けられているイメージの全体が、その感知器自体に転送されるまで、要求及び応答のループが実行される。このループは、感知器が、無線ゲートウェイにイメージブロックを要求することから開始する（イメージブロック要求（））。これに応答して、無線ゲートウェイは、要求されたイメージブロックで応答する（イメージブロック応答（））。このループは、更新イメージファイル内の全てのイメージブロックが、感知デバイスによって受信された時点で終了する。
多くの実施形態によれば、全ての更新ファイルイメージブロックの転送に続けて、感知デバイスは、例えばアップグレード終了要求（）メソッドを呼び出すことによって、無線ゲートウェイから、続行についての更なる命令を要求する。一部の実施形態では、無線ゲートウェイは、更なる通知まではソフトウェア／ファームウェアの更新の開始を控えるべきではないことを指示することによって、感知器に応答してもよい（更新終了応答（））。このアップグレード終了要求／応答の通信は、通常、ＺｉｇＢｅｅプロトコルを使用して達成されるが、必ずしもそれに限定されるものではない。次に、無線ゲートウェイは、感知デバイスに関連付けられた新たなステータスを、建物サーバのＦＷ更新ＢＳモジュール７２１に通知するメソッドを呼び出す（ＨＴＴＰＳ（ステータス、デバイスＭＡＣ））。この通知を受信すると、次に、建物サーバのＦＷ更新ＢＳモジュール７２１は、クラウド上のＳＷ更新モジュール７０３に、特定のＭＡＣアドレスに関連付けられている感知デバイスが、更新の準備が整っていることを通知する（ステータス更新（デバイスＭＡＣ））。これに応答して、ＳＷ更新モジュール７０３は、感知デバイスでの更新の開始をトリガするための、建物サーバのＦＷ更新ＢＳモジュール７２１でのメソッドを呼び出してもよい（ＦＷ更新をトリガする（デバイスＭＡＣ、通信経路））。このトリガは、感知デバイスのＭＡＣアドレス及び／又は感知デバイスの通信経路を通信してもよい。多くの実施形態では、建物サーバのＦＷ更新ＢＳモジュール７２１は、次に、同様のメカニズムを使用して、更新トリガを無線ゲートウェイに通知する（ＦＷ更新をトリガする（デバイスＭＡＣ、通信経路）。この通知に応答して、無線ゲートウェイは、そのＭＡＣデバイスアドレス及び／又は通信経路によって識別された感知デバイスに、現時点で更新の適用を開始してもよいことを通知する（更新終了応答（現在））。感知器は、その後、予め受信されている更新のイメージブロックを使用して、更新を適用する（ＦＷ更新を適用する（））。感知器が更新のインストールを終了し、再起動の成功のような他の必要なタスクを実行した後に、その感知器は、ＳｉｇｎＯｎ及び通常動作の再開の準備が現時点で整っていることを、無線ゲートウェイに示す（ＳｉｇｎＯｎ（））。
建物サーバのローカライズ
図１０Ａ及び図１０Ｂは併せて、物理的環境を監視及び制御するための例示的なクラウドベースのシステムにおいて、建物サーバをローカライズする方法の一実施形態を示す。双方の図の上部のボックスは、施設内部の建物サーバ１００（例えば、図１の建物サーバ１００）と、例えば図１のクラウド１１５に関連付けられている、様々なクラウドベースのモジュールとを表す。プロジェクトサービスモジュール７０８、プラグイン構想モジュール７０９、展開構想エンジンモジュール７１１、クラウド接続性サービスモジュール１９０、及びデバイス登録モジュール７０４は全て、図７Ａとの関連で前述された同一名称のクラウドベースのモジュールの実施形態である。更には、システムマップアプリケーションモジュール１６０は、図１及び図６との関連で前述された、クラウドベースのアプリケーションモジュールである。図１０Ａの左側に示されるユーザＣもまた、図６との関連で前述されている。本質的に、ユーザＣは、インストーラー又はコミッショニング技術者などの人物であり、その主要なタスクは、作成された建物のデジタルモデルに基づいて、建物内に物理的及び論理的にデバイスをインストールすることであってもよい。ユーザＣ、又は何らかの他の同様の資格認定されたユーザは、その後、コミッショニング、コンフィギュレーション、及び展開のプロセスに関与することができる。
この図に示される実施形態は、クラウド内のプロジェクトサービスモジュール７０８が自己始動して（プロジェクトサービスを開始する（））、プラグイン構想モジュール７０９のインスタンスを呼び出す（開始する（））ことから開始する。実行されると、プラグイン構想モジュール７０９のインスタンスは、自身をクラウド接続性サービスモジュール１９０に登録する（登録する（））。その一方で、監視される建物内の建物サーバ１００は、自身をデバイス登録モジュール７０４に登録する。建物サーバ１００の登録プロセスは、図８Ａ及び図８Ｂに付随する説明で、より詳細に説明されている。この登録プロセスにおける初期ステップのうちの１つは、建物サーバ１００が、デバイス登録モジュール７０４でＡＰＩコールを呼び出して（登録する（））、様々な実施形態ではＭＡＣアドレスである、そのローカルに記憶されている建物サーバＩＤを提供することを伴う。デバイス登録モジュール７０４は、登録に成功すると、建物サーバ１００がクラウドとの更なる通信を継続することが可能な、アドレス／位置と、そのクラウドによって提供される様々なサービスにアクセスするために建物サーバ１００が提示することが必要とされる、クレデンシャルとを返す（接続設定（））。これらのクレデンシャルは、典型的には、建物サーバのインスタンスごとに発行される。受信された接続設定及びその建物サーバＩＤを使用して、建物サーバ１００は、次に、デバイス登録モジュール７０４によって提供されたアドレス／位置でクラウド接続性サービスモジュール１９０に連絡することによって、セキュアな接続の作成を開始する（接続を作成する（建物サーバＩＤ））。クラウドとのセキュアな接続の設定が成功すると、クラウド接続性サービスモジュール１９０は、その旨を建物サーバ１００に通知する（「ＯＫ」と標識された矢印によって示される）。
次に、建物サーバ１００は、展開構想エンジン（Envision Deployment Engine；ＥＤＥ）モジュール７１１を介して、自身をクラウドに告知するように進む。建物サーバは、本質的に、まさにこの目的のために、ＥＤＥモジュール７１１によって公開されるＡＰＩを呼び出して、自身についての様々な情報（例えば、その建物サーバＩＤ、並びに、ソフトウェア及びハードウェアのバージョン管理情報）を提供する。このことは、図１０Ａで、建物サーバ告知（デバイス情報）と標識された矢印によって表されている。建物サーバ１００などのデバイスからのデータを、システムプロジェクトアプリケーションモジュール１４０及びシステムマップアプリケーションモジュール１６０などのシステムアプリケーションモジュールに通信するモジュールである、プロジェクトサービスモジュール７０８に、この告知を通信するために、その建物サーバの告知は、最初に、プラグイン構想モジュール７０９に伝搬されなければならない（建物サーバ告知（））。一部の実施形態では、建物サーバ１００からの建物サーバ告知は、展開構想エンジンモジュール７１１にではなく、プラグイン構想モジュール７０９自体に直接送信される。建物サーバの告知が、プラグイン構想モジュール７０９を介してクラウドに到達すると、プロジェクトサービスモジュール７０８に通知され、建物サーバを、既知デバイスのリストに追加する（発見リストにデバイスを追加する（））。プロジェクトサービスモジュール７０８は、建物サーバのＩＤ並びに他の情報（例えば、バージョン管理情報）をデータベースに追加することなどの、任意の既知の手段によって、そのことを行ってもよい。
建物サーバ１００が登録及び接続され、その存在をプロジェクトサービスモジュール７０８が認識すると、ユーザ（例えば、この図に示されるユーザＣ）は、タブレットコンピュータなどのモバイルデバイス上に提示されるアプリケーションのフロントエンドを現場で使用している間に、システムアプリケーションモジュールにアクセスすることができる（アプリを開始する）。ユーザＣは、例えば、システムマップアプリケーションモジュール１６０などの１つ以上のシステムアプリケーションにアクセスするために必要なアクセスクレデンシャルを予め付与されている、インストーラー又はコミッショニング技術者であってもよい。例示的なシステムアプリケーションモジュールは、図１及び図６との関連において、より詳細に前述されている。次いで、ユーザＣは、様々な実施形態では、そのユーザの役割及びクレデンシャルに基づいて、自身がアクセスを有する様々なプロジェクトを閲覧して回り、そのユーザが物理的に存在しているサイトに関連付けられている、プロジェクト階層及び建物を、グラフィカルに選択する（プロジェクトを選択する（建物））。次いで、システムマップアプリケーションモジュール１６０は、選択された建物に関して予め作成されているデータモデルを、プロジェクトサービスモジュール７０８からフェッチ又は要求する（取得する（））。これに応答して、プロジェクトサービスモジュール７０８は、選択された建物に関連付けられているデジタルフロアプランを提供し（フロアプラン（））、そのデジタルフロアプランは、その後、ユーザＣのモバイルコンピューティングデバイス上で実行されているシステムマップアプリケーションモジュール１６０の、フロントエンド上に表示される（点線矢印）。
次に、ユーザＣは、システムマップアプリケーションモジュール１６０のフロントエンド上に、自分が建物サーバをローカライズすることを望んでいることを示す（選択（建物サーバ））。このことは、単純に建物サーバのアイコンを選択して、その建物のフロアプランの視覚的表現上に、そのアイコンをドラッグすることによって行われてもよい。このシステムアプリケーションモジュールとのユーザ対話は、その建物サーバの固有の製造元提供ＱＲコードの写真を、ユーザＣが撮影するべき時間であることを示す。したがって、アプリケーションモジュール１６０は、ユーザＣのモバイルコンピューティングデバイス上のカメラデバイスを起動して（カメラを開始する（））、ユーザＣにＱＲコードを要求する（ＱＲコードを要求する（））。ユーザＣは、ＱＲコードを含む建物サーバの部分の写真を撮影することによって、それに応じる。ＱＲコードは、ここでは一例として使用されており、限定することを意図するものではない。他の実施形態では、建物サーバ上に物理的に取り付けられているか又は別の方式で貼り付けられている、任意の固有コードが使用されてもよい。システムマップアプリケーションモジュール１６０は、その後、ユーザＣのモバイルデバイス上のカメラデバイスによって取り込まれた画像から、ＱＲコードを抽出する（ＱＲコードを返す（ＩＤ））。
建物サーバをローカライズする本実施形態に関連付けられている残りのステップは、図１０Ｂに示される。システムマップアプリケーションモジュール１６０が、ユーザＣのモバイルデバイス上のカメラによって撮影された画像から、ＱＲコードデータを取得すると、アプリケーションモジュール１６０は、そのＱＲコードデータと共に、建物サーバのＩＤを、プロジェクトサービスモジュール７０８に送信する（＜ＢＳ ＩＤ＞を入力する（ＱＲデータ）、ここで「ＢＳ」は建物サーバを表す）。このことは、一部の実施形態では、ＨＴＴＰＳ ＰＵＴメソッド呼び出しを介して達成されてもよい。これに応答して、プロジェクトサービスモジュール７０８は、アクセス可能な発見リスト内の、一致するＱＲコードデータを有するデバイスを検索して、識別されたデバイスのプロファイル、例えば「発見済みデバイスプロファイル」を返す（発見リスト内のデバイスを検索する（ＱＲデータ、発見済みデバイスプロファイル））。次に、プロジェクトサービスモジュール７０８は、メモリ内で、その物理デバイス（例えば、そのＱＲコードがユーザＣによって画像内に取り込まれた建物サーバ）を、その物理建物サーバが中に存在している建物のモデルのフロアプラン上の、ローカライズのための仮想デバイスに関連付ける（仮想デバイスに物理デバイスを関連付ける（モデル、発見済みデバイスプロファイル））。プロジェクトサービスモジュール７０８は、その後、システムマップアプリケーションモジュール１６０に肯定応答を返す（点線矢印）。
肯定応答の受信に続けて、アプリケーションモジュール１６０は、ユーザＣがローカライズしている建物サーバが、オンラインであるか又はオフラインであるかを判定するためにチェックする。したがって、プロジェクトサービスモジュール７０８で適切なＡＰＩコールを呼び出して、必要な建物サーバＩＤを提供する（オンライン状態を得る（建物サーバＩＤ））。プロジェクトサービスモジュール７０８は、関連付けられている発見済みデバイスプロファイルを検索するために、供給された建物サーバＩＤを使用して、（例えば、データベース内の）探索を実行する（探索する（建物サーバＩＤ、発見済みデバイスプロファイル））。次いで、この発見済みデバイスプロファイルを使用して、プロジェクトサービスモジュール７０８は、建物サーバの適切なＩＤ、及びオンライン状態に関する要求を使用して、プラグイン構想モジュール７０９を呼び出して（オンライン状態を得る（ＢＳ ＩＤ））、その後、プラグイン構想モジュール７０９は、それらを使用して正しい建物サーバに連絡し、オンライン状態情報を直接要求することができる（オンライン状態を要求する（））。次いで、建物サーバ１００は、そのオンライン状態（例えば、現在オンラインであるか又はオフラインであるかの指標）を返す（点線矢印）。次いで、この情報は、プラグイン構想モジュール７０９によって、例えば適切なＡＰＩコールの呼び出しを介して、プロジェクトサービスモジュール７０８に伝搬される（デバイス状態をコールバックする（オンライン））。プロジェクトサービスモジュール７０８によって受信された情報（例えば、オンライン又はオフライン）に基づいて、プロジェクトサービスモジュール７０８は、システムマップアプリケーションモジュール１６０に適切に通知する（選択的な点線矢印オンライン及びオフライン）。建物サーバ１００が、現在オンラインである場合には（例えば、ユーザＣがローカライズプロセスの完了を試みている時）、システムマップアプリケーションモジュール１６０は、その建物サーバのローカライズが成功していることを、ユーザＣに通知する（ローカライズの成功を示す（））。あるいは、建物サーバ１００が、現在オフラインであると判定された場合には、プロジェクトサービスモジュール７０８は、様々な実施形態では、その発見済みデバイスプロファイルと物理建物サーバとの間の、予め作成されていた関連付けを除去し、システムマップアプリケーションモジュール１６０は、ローカライズが失敗したことを、ユーザＣに通知する（ローカライズの失敗を示す（））。ユーザＣは、ローカライズが失敗した理由、例えば建物サーバ１００がオフラインであること、及び、ローカライズが適切に完了するためには、建物サーバがオンラインであることが必要であることを、通知されてもよい。
ゲートウェイのローカライズ
図１１は、物理的環境を監視及び制御するための例示的なクラウドベースのシステムにおいて、無線ゲートウェイ（例えば、図１のゲートウェイ１１０Ａ）をローカライズする方法の一実施形態を示す。この図の上部のボックスは、施設内部の（例えば、図１の建物サーバ１００と同様の）建物サーバ１００と、例えば図１のクラウド１１５に関連付けられている、様々なクラウドベースのモジュールとを表す。プラグイン構想モジュール７０９、及びプロジェクトサービスモジュール７０８は、図７Ａとの関連で前述された、同一名称のクラウドベースのモジュールの実施形態である。更には、システムマップアプリケーションモジュール１６０は、図１及び図６との関連で前述された、クラウドベースのアプリケーションである。図１１の左側に示されるユーザＣもまた、図６との関連で前述されている。本質的に、ユーザＣは、インストーラー又はコミッショニング技術者などの人物であり、作成された建物のデジタルモデルに基づいて、建物内に物理的及び論理的にデバイスをインストールし、その後、コミッショニング、コンフィギュレーション、及び／又は展開のプロセスに関与することなどのタスクを実行する。
一部の実施形態では、無線ゲートウェイ１１０Ａに関するローカライズのプロセスは、その無線ゲートウェイが、例えばＭＱＴＴプロトコルを介して、ＳｉｇｎＯｎメッセージを送信することから開始する。このＳｉｇｎＯｎメッセージは、多くの実施形態では、建物サーバの固有ＩＤ、無線ゲートウェイのＩＰアドレス、ゲートウェイに関する情報、及び無線ゲートウェイに関連付けられているＩＤを含む（ＳｉｇｎＯｎ（建物サーバＩＤ、ＩＰアドレス、デバイス情報、無線ゲートウェイＩＤ））。様々な実施形態では、建物サーバは、（例えば、図７Ｂに示されるような）ＭＱＴＴプロキシを実行し、次いで、そのＳｉｇｎＯｎメッセージを、プラグイン構想モジュール７０９に転送する（ＳｉｇｎＯｎ（建物サーバＩＤ、ＩＰアドレス、デバイス情報、無線ゲートウェイＩＤ）と標識された、第２の矢印によって示される）。一方、プラグイン構想モジュール７０９も、そのＳｉｇｎＯｎメッセージ及びその関連パラメータを、クラウド１１５上で動作しているプロジェクトサービスモジュール７０８に転送する。それを行うために、プラグイン構想モジュールは、プロジェクトサービスモジュール７０８が、自身のＡＰＩの一部として公開する、コールバックメソッド又は関数を呼び出してもよい（コールバック（建物サーバＩＤ、ＩＰアドレス、デバイス情報、無線ゲートウェイＩＤ））。このコールバックは、未だローカライズされていない新たなデバイスがＳｉｇｎＯｎを試みており、利用可能であることを、プロジェクトサービスモジュール７０８に通知する方法である。次いで、プロジェクトサービスモジュール７０８は、そのコールバックで受信された無線ゲートウェイ１１０Ａに関する情報を、以前に遭遇していない「新たな」デバイスのリストに追加する（発見リストにデバイスを追加する（））。
その間に、本実施形態では、ユーザＣは、タブレットコンピュータなどのポータブルコンピューティングデバイス上で実行されているシステムマップアプリケーションモジュール１６０のユーザインタフェース上で、無線ゲートウェイ１１０Ａを表すアイコンをグラフィカルに選択する（無線ゲートウェイの選択）。このことは、システムマップアプリケーションモジュール１６０に、ポータブルデバイス上のカメラアプリケーションを起動させる（カメラを開始する（））。次いで、マップアプリケーションモジュール１６０は、無線ゲートウェイに関連付けられているＱＲコードに関して、ユーザＣを促すことができる（ＱＲコードを要求する（））。それに応じるべく、ユーザＣは、ＱＲコードを上に有している、その無線ゲートウェイの一部にカメラを向けて、写真を撮影する（写真を撮影する（））。次いで、その画像がマップアプリケーションモジュール１６０によって分析され、ＱＲコードが抽出される（ＱＲコードを返してデコードする（））。
ＱＲコードが画像から抽出されると、マップアプリケーションモジュール１６０は、プロジェクトサービスモジュール７０８が、そのＱＲコードに関連付けられている物理デバイスを、（例えば、その建物のデジタルフロアプラン上の）建物のデータモデル内に表されており、かつマップアプリケーションモジュール１６０のグラフィカルユーザインタフェース上に表されている、仮想デバイスに関連付けるように要求する（仮想デバイスに物理デバイスを関連付ける（ＱＲコード、仮想デバイスＩＤ））。多くの実施形態では、物理デバイスを識別するために、マップアプリケーションモジュール１６０は、ＱＲコードを供給し、仮想デバイスを識別するために、仮想デバイスＩＤを供給する。これに応答して、プロジェクトサービスモジュール７０８は、自身の発見済みデバイスのリスト内に仮想デバイスを配置し（リスト内でデバイスを検索する（））、その後、メモリ内で、物理デバイス（例えば、そのＱＲコードがユーザＣによって画像内に取り込まれた無線ゲートウェイ）を、ローカライズ目的で仮想デバイス（例えば、システムマップアプリケーションモジュール１６０によって供給された仮想デバイスＩＤに一致する、そのリスト内の仮想デバイス）に関連付ける（仮想デバイスに物理デバイスを関連付ける（））。プロジェクトサービスモジュール７０８は、その後、システムマップアプリケーションモジュール１６０に肯定応答を返す（プロジェクトサービスモジュール７０８からシステムマップアプリケーションモジュール１６０への、点線矢印によって示される）。
この関連付けの肯定応答の受信に続けて、システムマップアプリケーションモジュール１６０は、その無線ゲートウェイに関連付けられるオンライン状態を要求する。プロジェクトサービスモジュール７０８が、その状態を検索することを可能にするために、システムマップアプリケーションモジュールは、その無線ゲートウェイの仮想デバイスＩＤを供給する（オンライン状態を得る（仮想デバイスＩＤ））。プロジェクトサービスモジュール７０８は、その後、この仮想デバイスＩＤに基づいて、発見済みデバイスプロファイルを取得する。様々な実施形態では、このプロファイルは、デバイス（この実施例では、無線ゲートウェイ）の物理アドレスを含む（探索する（仮想デバイスＩＤ、発見済みデバイスプロファイル））。次いで、プロジェクトサービスモジュール７０８は、その無線ゲートウェイのオンライン状態に関する要求を、プラグイン構想モジュール７０９に転送し（オンライン状態を得る（ＤＤＰ）、ここで「ＤＤＰ」は「発見済みデバイスプロファイル」を表す）、この要求は、適切な建物サーバ（この実施例では、建物サーバ１００）へと連鎖的に転送される（オンライン状態を得る（ＤＤＰ））。多くの実施形態では、発見済みデバイスプロファイル内に含まれている、無線ゲートウェイの物理アドレスはまた、対象のゲートウェイに関連付けられている適切な建物サーバのアドレスも識別する。建物サーバ１００は、発見済みデバイスプロファイル内で識別された無線ゲートウェイに、ＳｉｇｎＯｎすることを要求し（ＲｅｕｅｓｔＳｉｇｎＯｎ（））、これに応答して、その無線ゲートウェイはＳｉｇｎＯｎして、その旨を建物サーバに示す（ＳｉｇｎＯｎ（））。建物サーバは、その後、この無線ゲートウェイがオンラインであることをプラグイン構想モジュール７０９に通知し（オンライン状態結果（真））、プラグインは次に、例えば、そのコールバックＡＰＩを使用して、プロジェクトサービスモジュール７０８に通知する（コールバック（オンライン状態が真））。最後に、プロジェクトサービスモジュール７０８は、システムマップアプリケーションモジュール１６０に、その無線ゲートウェイが実際にオンラインであることを通知し（デバイスがオンライン（））、マップアプリケーションモジュールは次に、ユーザＣに、ローカライズの成功を示す（ローカライズの成功を示す（））。
感知デバイスなどのシステムデバイスをローカライズする
図１２Ａ、図１２Ｂ−Ｉ、及び図１２Ｂ−ＩＩは、物理的環境を監視及び制御するための例示的なクラウドベースのシステムにおいて、感知デバイス（例えば、照明器具）などのシステムデバイスをローカライズする方法の一実施形態を示す。図の上部のボックスは、施設内の建物サーバ（例えば、図１の建物サーバ１００）、無線ゲートウェイ（図１のゲート１１０Ａ）、感知デバイス（例えば、図１のデバイス１０１）、ＩＲ遠隔制御デバイス、及び、例えば図１のクラウド１１５に関連付けられている様々なクラウドベースのモジュールを表す。プラグイン構想モジュール７０９及びプロジェクトサービスモジュール７０８は、図７Ａとの関連で前述された同一名称のクラウドベースのモジュールの実施形態である。更には、システムマップアプリケーションモジュール１６０は、図１及び図６との関連で前述された、クラウドベースのアプリケーションである。これらの図の左上に示されるユーザＣもまた、図６との関連で前述されている。本質的に、ユーザＣは、インストーラー又はコミッショニング技術者などの人物であり、この文脈でのその主要なタスクは、作成された建物のデジタルモデルに基づいて、建物内に物理的及び論理的にデバイスをインストールすることであってもよい。多くの実施形態では、ユーザＣは、その後、コミッショニング、コンフィギュレーション、及び展開のプロセスに関与する。
ユーザＣは、システムマップアプリケーションモジュール１６０上に提示された、建物のデジタルフロアプラン上に示されている、照明器具などの感知デバイスを選択することによって、ローカライズのプロセスを開始する（選択する（感知器））。前述のように、マップモジュール１６０のフロントエンドは、タブレットコンピューティングデバイス上で実行されていてもよい。多くの実施形態では、フロアプランを入力するために使用される、基礎となるデータモデルは、選択された感知デバイスに関連付けられている無線ゲートウェイについての情報を既に有しているため、マップモジュール１６０は、プロジェクトサービスモジュール７０８が、その特定の無線ゲートウェイに関連付けられているネットワークを開くことを要求する。ネットワークを開くことを容易にするために、マップモジュール１６０は、そのゲートウェイの適切なＩＤを供給する（ネットワークを開く（ゲートウェイＩＤ））。この要求を受信すると、プロジェクトサービスモジュール７０８は、関連する建物サーバのＩＤ及びゲートウェイのＩＰアドレスを追加した後に、プラグイン構想モジュール７０９に同様の要求を転送する（ネットワークを開く（建物サーバＩＤ、ゲートウェイＩＤ、ゲートウェイＩＰアドレス））。プラグイン構想モジュール７０９は、次に、供給された建物サーバのＩＤによって識別された特定の建物サーバが、ＺｉｇＢｅｅネットワークを開くことを要求する。このことを容易にするために、プラグインは、関連するゲートウェイのＩＰアドレスを供給する（ＺｉｇＢｅｅネットワークを開く（ゲートウェイＩＰアドレス））。建物サーバ（例えば、この実施例では建物サーバ１００）は、これに応答して、そのＺｉｇＢｅｅネットワークを開く同様の要求を、ゲートウェイＩＰアドレスによって識別された無線ゲートウェイに転送する（ＺｉｇＢｅｅネットワークを開く（））。無線ゲートウェイ（例えば、この実施例ではゲートウェイ１１０Ａ）は、そのＺｉｇＢｅｅネットワークを開き、全ての関連する感知デバイスに、その旨を通知する（ビーコンを送信する（））。無線ゲートウェイ１１０Ａはまた、ネットワークの開放が成功したことを、建物サーバ１００にも通知する（ネットワーク開放（））。建物サーバ１００は、次に、ＺｉｇＢｅｅネットワークの開放の成功を、プラグイン構想モジュール７０９に通知する（通知する（開放の成功））。プラグインモジュール７０９は、その役割として、特定のネットワークの状態が「開放」状態に変化したことを、プロジェクトサービスモジュール７０８に通知する（ネットワーク状態の変化（開放））。プロジェクトサービスモジュール７０９は、その後、システムマップアプリケーションモジュール１６０に、アプリケーションモジュールから最初に受信されたネットワーク開放要求が、実際に成功して完了しており、アプリケーションモジュールによって識別された特定のゲートウェイＩＤに関連付けられているネットワークが、実際に開いていることを通知する（ネットワーク開放（ゲートウェイＩＤ））。一部の実施形態では、システムマップアプリケーションモジュール１６０は、この情報を受信すると、自身のＧＵＩ上に、そのＩＲリモコンのダイアログを表示する（ＩＲダイアログを示す（））。
このＩＲリモコンのダイアログが、マップアプリケーションモジュール上で開かれると、ユーザＣは随意に、そのＩＲ遠隔制御デバイスを対象の感知器に向けて、その感知器がその無線ゲートウェイのネットワークに追加されるべきであることを示すために、ボタンを押す。多くの実施形態では、このボタンは、「追加」ボタンに指定されてもよい。ＩＲ遠隔制御デバイスは、この入力を受信し、これに応答して、感知デバイスが、その無線ゲートウェイのオープンネットワークに自身を追加するべきであることを示す信号を、その感知デバイスに送信する（追加する（））。この命令を受信すると、感知デバイスは、無線ゲートウェイ１１０Ａに、そのネットワークに参加する要求を送信し（参加を要求する（））、その後、無線ゲートウェイ１１０Ａは、その無線ネットワークに感知器を追加して（ネットワークにデバイスを追加する（））、感知器に、そのゲートウェイのネットワークに参加する要求が承認されたことを通知する（参加を承認する（））。多くの実施形態では、感知器が、無線ゲートウェイのネットワークに参加する場合には、その感知器は、自身を識別するためのショートアドレスを選択する。次いで、感知器は、無線ゲートウェイ１１０ＡとＳｉｇｎＯｎして、自身のデバイス情報、並びに、自身のショートアドレスを提供する。無線ゲートウェイ１１０Ａは、ＳｉｇｎＯｎ要求を、その感知器に関連付けられている感知器ＩＤ、無線ゲートウェイ自身のＩＤ、建物サーバのＩＤ、無線ゲートウェイのＩＰアドレス、及び感知器のデバイス情報と共に、建物サーバ１００に転送する（ＳｉｇｎＯｎ（感知器ＩＤ、ゲートウェイＩＤ、建物サーバＩＤ、ゲートウェイＩＰアドレス、デバイス情報））。様々な実施形態では、無線ゲートウェイ１１０Ａは、上述の情報のサブセットを提供してもよい。受信すると、建物サーバ１００は、プラグイン構想モジュール７０９に同じ要求を転送する。プラグインモジュールは、同じ又は同様のパラメータを使用する、プロジェクトサービスモジュール７０８のコールバックメソッドを呼び出し（コールバック（感知器ＩＤ、ゲートウェイＩＤ、建物サーバＩＤ、ゲートウェイＩＰアドレス、デバイス情報））、プロジェクトサービスモジュール７０８は、次に、システムマップアプリケーションモジュール１６０に、そのアプリケーション上でユーザＣによって予め選択されていた感知器に対応する、新たなデバイスが発見されたことを通知する。多くの実施形態では、プロジェクトサービスモジュール７０８はまた、関数コールに対するパラメータとしての、一意の物理デバイス識別子も、マップアプリケーションモジュール１６０に転送する（発見済みデバイス（物理デバイスＩＤ））。
その後、図１２Ｂ−Ｉ及び図１２Ｂ−ＩＩに示されるように、プロジェクトサービスモジュール７０８は、その感知デバイスを、クラウドによって管理されているデバイスのリストに追加する（デバイス管理リストに物理デバイスを追加する（物理デバイスＩＤ、仮想デバイスＩＤ））。ゲートウェイ及び建物サーバのローカライズとの関連で前述されたように、物理デバイスＩＤは、典型的には、その物理デバイス自体に関連付けられている一意識別子（例えば、製造元提供ＩＤ）であり、仮想デバイスＩＤは、典型的には、その物理デバイスの（例えば、データベース内の）仮想表現に既に関連付けられていてもよい一意識別子である。例えば、物理感知器を収容する特定の建物に関連付けられているデータモデルは、その物理感知器が、実際にローカライズされるか、又は、その仮想表現に関連付けられる前であっても、その物理感知器を表す仮想識別子を有していてもよい。
次に、プロジェクトサービスモジュール７０８は、データベースなどのメモリ内で、感知器の物理デバイスＩＤを、その仮想デバイスＩＤに関連付ける（仮想デバイスに物理デバイスを関連付ける（物理デバイスＩＤ、仮想デバイスＩＤ））。その一方で、システムマップアプリケーションモジュール１６０は、ユーザＣに、感知デバイスのローカライズが成功したことを（例えば、視覚的に）示す（ローカライズの成功を示す（））。ユーザＣは、その後、例えば、マップアプリケーションモジュール１６０上に表示されているデジタルフロアプラン上で、感知デバイスを表すアイコンを選択することによって、別の感知デバイスをローカライズするように進むことができる（選択（感知デバイス））。様々な実施形態では、クラウドシステムが、建物内の様々な感知デバイスのローカライズに関与している間であっても、既にローカライズされたデバイスの展開は、自動的に、並行して、ユーザＣからの更なる補助又は介入をなんら伴うことなく進行する。
プロジェクトサービスモジュール７０８は、典型的には、ローカライズされた感知デバイス（例えば、照明器具）に関する展開プロセスを、その感知デバイスの仮想デバイスＩＤを使用して、それ自身のメソッドを呼び出すことによって開始する（展開する（仮想デバイスＩＤ））。その後、プロジェクトサービスモジュールは、その感知デバイスに好適なデバイスコンフィギュレーションを作成する要求を、プラグイン構想モジュール７０９に送信する。様々な実施形態では、そのような要求は、感知デバイスの仮想デバイスＩＤ、デバイスが配置される領域（例えば、廊下、会議室、オフィス、建物フロア）の指標、及び、様々な状況下（例えば、占有、光、又は熱の変化など）での感知デバイスの挙動を指示する１つ以上の（人間に読み取り可能又は器械読み取り可能なフォーマットでの）テンプレートフラグメントを含む（デバイスコンフィギュレーションを作成する（仮想デバイスＩＤ、領域、テンプレートフラグメント））。プラグイン構想モジュール７０９は、この要求を受信すると、プロトコル間での何らかの必要な変換を実行した後、その要求を単純に展開構想エンジンモジュール７１１に転送する。この要求を受信すると、展開構想エンジンモジュール７１１は、受信されたテンプレートフラグメント、領域情報、及び仮想デバイスＩＤを使用して、対象の感知デバイスによって読み取り可能な、目標コンフィギュレーションファイルを作成する（デバイスコンフィギュレーションを作成する（仮想デバイスＩＤ、領域、テンプレートフラグメント））。作成の成功の肯定応答が、プラグイン構想モジュール７０９及びプロジェクトサービスモジュール７０８へと、連鎖的に転送されて返される（「ＡＣＫ」と標識された点線矢印によって示される）。
プロジェクトサービスモジュール７０８が、目標コンフィギュレーションの作成の成功の肯定応答を受信すると、感知デバイスのコンフィギュレーションの更新を開始する要求を、プラグイン構想モジュール７０９に送信する（更新コマンドを送信する（仮想デバイスＩＤ、目標コンフィギュレーション））。これに応答して、プラグイン構想モジュール７０９は、何らかの必要なプロトコルフォーマットの変換を実行した後、同様の要求を建物サーバ１００に転送する。次いで、建物サーバ１００は、様々なデバイスのコンフィギュレーションを更新する同様の要求を保持している、更新待ち行列に、その更新要求を仮想デバイスＩＤと共に追加する（待ち行列コマンド（仮想デバイスＩＤ））。これは、ユーザＣが、他のローカライズされたデバイスがコンフィギュレーションされている間に、新たなデバイスをローカライズすることが可能であるためである。このコンフィギュレーションプロセス、特に、それらのデバイス自体への多数のコンフィギュレーションデータブロックの書き込みは、時間を要する場合がある。したがって、多くの実施形態では、最近ローカライズされたデバイスをコンフィギュレーションする要求が、建物サーバ１００によって受信されると、その要求は待ち行列に追加され、先着順で処理される。この実施例で論じられている感知デバイスが、待ち行列に追加される最初のものであると想定すると、建物サーバ１００は、感知デバイスに、建物サーバからのコマンドのリッスンを、この時点で開始するべきであることを通知する（リッスンしてください（））。これに応答して、感知デバイスは、建物サーバ１００に肯定応答を返信する（「ＡＣＫ」と標識された点線矢印によって示される）。
次に、建物サーバ１００は、その建物サーバが、仮想デバイスＩＤによって識別された特定の感知デバイスに、コンフィギュレーションデータのブロックを書き込むことを望んでいるという信号／メッセージを、無線ゲートウェイ１１０Ａに送信する（コンフィギュレーションブロックを書き込む（仮想デバイスＩＤ、コンフィギュレーションブロック））。無線ゲートウェイは、そのメッセージを、仮想デバイスＩＤによって識別された正しい感知デバイスに転送する。感知デバイスから肯定応答を受信すると、その肯定応答は、建物サーバ１００へと連鎖的に転送されて返される（「ＡＣＫ」と標識された２つの点線矢印によって示される）。そのようなシーケンスは、感知デバイスに関して作成された目標コンフィギュレーションファイルに関連付けられている全てのブロックが、その感知デバイスに書き込まれるまで、繰り返し遂行される。全てのブロックが書き込まれると、建物サーバ１００は、特定の感知デバイスのコンフィギュレーション更新が完了されたことを、プラグイン構想モジュール７０９に通知する（更新の完了（仮想デバイスＩＤ））。次いで、このメッセージは、プロジェクトサービスモジュール７０８へと連鎖的に転送され、プロジェクトサービスモジュールは、その特定の感知デバイスのコンフィギュレーションが、この時点で最新のものであるという事実を記録する。プロジェクトサービスは、クラウドベースのアプリケーションモジュールがアクセス可能なデータベースを更新して、その旨を示すことを含めた、様々な方式で、そのことを行ってもよい（デバイスコンフィギュレーションが最新（））。最後に、プロジェクトサービスは、特定の感知デバイスのコンフィギュレーションが現時点で完了していることを示すメッセージを、システムマップアプリケーションモジュール１６０に送信する（更新の完了（仮想デバイスＩＤ））。
建物サーバ１００はまた、その一方で、感知デバイスにリセットメッセージを送信して（リセットする（））、その感知デバイスに自身を再起動させる。多くの実施形態では、それ自身の再起動が成功すると、感知デバイスは、そのデバイス情報、及びそのデバイスが新たなコンフィギュレーションを有していることの指標と共に、建物サーバ１００にＳｉｇｎＯｎメッセージを送信する（ＳｉｇｎＯｎ（デバイス情報、新たなコンフィギュレーション））。
いくつかの発明実施形態が、本明細書で説明及び図示されてきたが、当業者は、本明細書で説明される機能を実行するための、並びに／あるいは、その結果及び／又は利点のうちの１つ以上を得るための、様々な他の手段及び／又は構造体を、容易に構想することとなり、そのような変形態様及び／又は修正態様は、本明細書で説明される発明実施形態の範囲内にあるものと見なされる。より一般的には、本明細書で説明される全てのパラメータ、寸法、材料、及びコンフィギュレーションは、例示であることが意図されており、実際のパラメータ、寸法、材料、及び／又はコンフィギュレーションは、本発明の教示が使用される特定の用途に応じて変化することを、当業者は容易に理解するであろう。当業者は、通常の実験のみを使用して、本明細書で説明される特定の発明実施形態に対する、多くの等価物を認識し、又は確認することが可能であろう。それゆえ、上述の実施形態は、例としてのみ提示されており、添付の請求項及びその等価物の範囲内で、具体的に説明及び特許請求されるもの以外の発明実施形態が実践されてもよい点を理解されたい。本開示の発明実施形態は、本明細書で説明される、それぞれの個別の特徴、システム、物品、材料、キット、及び／又は方法を対象とする。更には、２つ以上のそのような特徴、システム、物品、材料、キット、及び／又は方法の任意の組み合わせは、そのような特徴、システム、物品、材料、キット、及び／又は方法が相互に矛盾しない場合であれば、本開示の発明の範囲内に含まれる。
本明細書で定義及び使用されるような、全ての定義は、辞書定義、参照により組み込まれる文書中での定義、及び／又は定義される用語の通常の意味を支配するように理解されるべきである。
不定冠詞「ａ」及び「ａｎ」は、本明細書及び請求項において使用されるとき、そうではないことが明確に示されない限り、「少なくとも１つ」を意味するように理解されるべきである。
語句「及び／又は」は、本明細書及び請求項において使用されるとき、そのように結合されている要素の「いずれか又は双方」、すなわち、一部の場合には接続的に存在し、他の場合には離接的に存在する要素を意味するように理解されるべきである。「及び／又は」で列挙されている複数の要素は、同じ方式で、すなわち、そのように結合されている要素のうちの「１つ以上」として解釈されるべきである。「及び／又は」の節によって具体的に特定されている要素以外の他の要素は、具体的に特定されているそれらの要素に関連するか又は関連しないかにかかわらず、オプションとして存在してもよい。それゆえ、非限定例として、「Ａ及び／又はＢ」への言及は、「含む（comprising）」などのオープンエンドの言語と共に使用される場合、一実施形態では、Ａのみ（オプションとして、Ｂ以外の要素を含む）、別の実施形態では、Ｂのみ（オプションとして、Ａ以外の要素を含む）、更に別の実施形態では、Ａ及びＢの双方（オプションとして、他の要素を含む）などに言及することができる。
本明細書及び請求項において使用されるとき、「又は」は、上記で定義されたような「及び／又は」と同じ意味を有するように理解されるべきである。例えば、リスト内の項目を分離する際、「又は」又は「及び／又は」は、包括的であるとして、すなわち、少なくとも１つを含むが、また、いくつかの要素又は要素のリストのうちの２つ以上、オプションとして、列挙されていない追加項目も含むとして解釈されるものとする。それとは反対に、明確に示される「〜のうちの１つのみ」若しくは「〜のうちの厳密に１つ」、又は請求項で使用される場合の「〜からなる」などの用語のみが、いくつかの要素又は要素のリストのうちの厳密に１つを含むことに言及する。一般に、用語「又は」は、本明細書で使用されるとき、「〜のいずれか」、「〜のうちの１つ」、「〜のうちの１つのみ」、又は「〜のうちの厳密に１つ」などの、排他性の用語に先行する場合にのみ、排他的選択肢（すなわち、「一方又は他方であるが、双方ではない」）を示すとして解釈されるものとする。「〜から本質的になる」は、請求項で使用される場合、特許法の分野で使用される際の、その通常の意味を有するものとする。
本明細書及び請求項において使用されるとき、１つ以上の要素のリストを参照する語句「少なくとも１つ」は、その要素のリスト内の要素の任意の１つ以上から選択された、少なくとも１つを意味するが、必ずしも、その要素のリスト内で具体的に列挙されているそれぞれの要素のうちの、少なくとも１つを含むものではなく、その要素のリスト内の要素の、任意の組み合わせを排除するものではないことが理解されるべきである。この定義はまた、語句「少なくとも１つ」が言及する、その要素のリスト内で具体的に特定されている要素以外の要素が、具体的に特定されているそれらの要素に関連するか又は関連しないかにかかわらず、オプションとして存在してもよいことも可能にする。それゆえ、非限定例として、「Ａ及びＢのうちの少なくとも１つ」（又は、等価的に「Ａ又はＢのうちの少なくとも１つ」、又は、等価的に「Ａ及び／又はＢのうちの少なくとも１つ」は、一実施形態では、オプションとして２つ以上を含めた、少なくとも１つのＡであり、Ｂは存在しないこと（及び、オプションとしてＢ以外の要素を含む）、別の実施形態では、オプションとして２つ以上を含めた、少なくとも１つのＢであり、Ａは存在しないこと（及び、オプションとしてＡ以外の要素を含む）、更に別の実施形態では、オプションとして２つ以上を含めた、少なくとも１つのＡ、及び、オプションとして２つ以上を含めた、少なくとも１つのＢ（及び、オプションとして他の要素も含む）などに言及することができる。
また、そうではないことが明確に示されない限り、２つ以上のステップ又は行為を含む、本明細書で特許請求されるいずれの方法においても、その方法のステップ又は行為の順序は、必ずしも、その方法のステップ又は行為が列挙されている順序に限定されるものではないことも理解されるべきである。
請求項において現れる括弧内の参照番号は、単に欧州特許慣行に則して便宜上提供されているものであり、いかなる点でも請求項を制限するものとして理解されるべきではない。
請求項並びに上記の明細書では、「備える（comprising）」、「含む（including）」、「運ぶ（carrying）」、「有する（having）」、「包含する（containing）」、「伴う（involving）」、「保持する（holding）」、「〜で構成される（composed of）」などの全ての移行句は、オープンエンドであり、すなわち、含むが限定されないことを意味する点を理解されたい。移行句「〜からなる」及び「〜から本質的になる」のみが、それぞれ、クローズド又は半クローズドの移行句であるものとする。

Claims (15)

  1. 複数のシステムデバイスを含む物理的環境内のシステムデバイスのコミッショニングにおけるエラーを自動的に検出する方法であって、
    前記複数のシステムデバイスの各々により、１つ以上の近隣のシステムデバイスから無線信号を受信するステップと、
    前記複数のシステムデバイスの各々により、受信した前記無線信号の強度を決定するステップと、
    インストーラーから、前記物理的環境内で第１のシステムデバイスをコミッショニングする要求を受信するステップであって、前記要求は、前記第１のシステムデバイスの意図する位置を含む、ステップと、
    前記第１のシステムデバイスの近隣の少なくとも１つのシステムデバイスから決定された無線信号強度、及び前記コミッショニング要求を受信するステップであって、前記第１のシステムデバイスの近隣の前記少なくとも１つのシステムデバイスの位置は既知である、ステップと、
    近隣の前記少なくとも１つのシステムデバイスから受信した前記無線信号強度に少なくとも部分的に基づいて、前記第１のシステムデバイスが前記意図する位置に位置していないと判定するステップと、
    前記第１のシステムデバイスが前記意図する位置に位置していないことを前記インストーラーにアラートするステップと、
    を含む、方法。
  2. 前記第１のシステムデバイスは、照明器具である、請求項１に記載の方法。
  3. 前記意図する位置に位置するシステムデバイスのアイデンティティを含む提言をインストーラーに行うステップを含む、請求項１に記載の方法。
  4. 前記意図する位置に位置するシステムデバイスを自動的にコミッショニングするステップを含む、請求項１に記載の方法。
  5. 前記第１のシステムデバイスが前記意図する位置に位置していないと判定する前記ステップは、（ｉ）複数の近隣のシステムデバイスから受信した無線信号強度を分析するステップと、（ｉｉ）これら無線信号強度に基づいて、前記複数の近隣のシステムデバイスのどのシステムデバイスが前記第１のシステムデバイスに最も近いか判定するステップとを含む、請求項１に記載の方法。
  6. 前記１つ以上の近隣のシステムデバイスからの各々の無線信号は、当該システムデバイスを識別する情報を含む、請求項１に記載の方法。
  7. 前記複数のシステムデバイスの少なくともいくつかにより、前記物理的環境からローカライズ情報を受信するステップを含む、請求項１に記載の方法。
  8. 前記ローカライズ情報は、光レベル、占有情報、又は１つ以上の近隣のシステムデバイスからのメッセージング周波数を含む、請求項７に記載の方法。
  9. 前記第１のシステムデバイスが前記意図する位置に位置していないと判定する前記ステップは、受信した前記ローカライズ情報を利用するステップを含む、請求項８に記載の方法。
  10. コミッショニングにおけるエラーを自動的に検出するためのシステムであって、
    無線信号を送信するよう構成され、近隣のシステムデバイスから送信された無線信号を受信するよう構成される複数のシステムデバイスであって、当該システムは、受信した前記無線信号の強度を決定するよう構成される、複数のシステムデバイスと、
    物理的環境内で第１のシステムデバイスをコミッショニングする要求を送るよう構成されるコミッショニングデバイスであって、前記要求は、前記第１のシステムデバイスの意図する位置を含む、コミッショニングデバイスと、
    （ｉ）前記第１のシステムデバイスの近隣の少なくとも１つのシステムデバイスから決定された無線信号強度、及び前記コミッショニング要求を受信する、（ｉｉ）近隣の前記少なくとも１つのシステムデバイスから受信した前記無線信号強度に少なくとも部分的に基づいて、前記第１のシステムデバイスが前記意図する位置に位置していないと判定する、及び（ｉｉｉ）前記第１のシステムデバイスが前記意図する位置に位置していないというアラートを前記コミッショニングデバイスに送るよう構成されるコンピューティングクラウドと、
    を含むシステム。
  11. 前記コンピューティングクラウドは、前記意図する位置に位置する正しいシステムデバイスのアイデンティティに関する提言をコミッショニングデバイスを介して行うよう構成される、請求項１０に記載のシステム。
  12. 前記コンピューティングクラウドは、前記意図する位置に位置するシステムデバイスを自動的にコミッショニングするよう構成される、請求項１０に記載のシステム。
  13. 前記第１のシステムデバイスが前記意図する位置に位置していないと判定することは、（ｉ）複数の近隣のシステムデバイスから受信した無線信号強度を分析することと、（ｉｉ）これら無線信号強度に基づいて、前記複数の近隣のシステムデバイスのどのシステムデバイスが前記第１のシステムデバイスに最も近いか判定することとを含む、請求項１０に記載のシステム。
  14. 前記１つ以上の近隣のシステムデバイスからの各々の無線信号は、当該システムデバイスを識別する情報を含む、請求項１０に記載のシステム。
  15. 前記複数のシステムデバイスは、前記物理的環境からローカライズ情報を受信するよう構成され、前記ローカライズ情報は、光レベル、占有情報、又は１つ以上の近隣のシステムデバイスからのメッセージング周波数を含む、請求項１０に記載のシステム。
JP2018555279A 2016-04-21 2017-04-12 感知デバイスのローカライズためのシステム及び方法 Active JP6868039B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
IN201641013925 2016-04-21
IN201641013925 2016-04-21
EPPCT/EP2017/054317 2017-02-24
PCT/EP2017/054317 WO2017182181A1 (en) 2016-04-21 2017-02-24 System and methods for cloud-based monitoring and control of physical environments
EP17159990.5 2017-03-09
EP17159990 2017-03-09
PCT/EP2017/058726 WO2017182346A1 (en) 2016-04-21 2017-04-12 Systems and methods for sensic device localization

Publications (2)

Publication Number Publication Date
JP2019519834A true JP2019519834A (ja) 2019-07-11
JP6868039B2 JP6868039B2 (ja) 2021-05-12

Family

ID=60116602

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018555279A Active JP6868039B2 (ja) 2016-04-21 2017-04-12 感知デバイスのローカライズためのシステム及び方法

Country Status (6)

Country Link
US (2) US11134556B2 (ja)
EP (1) EP3446210A1 (ja)
JP (1) JP6868039B2 (ja)
CN (1) CN109074267B (ja)
RU (1) RU2018140866A (ja)
WO (1) WO2017182346A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021125053A1 (ja) * 2019-12-17 2021-06-24 パナソニックＩｐマネジメント株式会社 情報処理装置、情報処理方法及びプログラム

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10506691B2 (en) * 2016-04-21 2019-12-10 Signify Holding B.V. Systems and methods for commissioning and localizing devices used for cloud-based monitoring and control of physical environments
WO2017182363A1 (en) * 2016-04-21 2017-10-26 Philips Lighting Holding B.V. Systems and methods for registering and localizing building servers for cloud-based monitoring and control of physical environments
US20210126971A1 (en) * 2016-10-28 2021-04-29 Insight Energy Ventures, Llc Method of automatically mating a gateway device with an energy measurement device
ES2898686T3 (es) 2017-03-03 2022-03-08 Signify Holding Bv Detectar una nueva puesta en servicio
AU2018263928A1 (en) * 2017-05-02 2019-12-05 Lumigrow, Inc. Lighting system and sensor array for growing plants
WO2018204625A2 (en) * 2017-05-03 2018-11-08 Ndustrial.Io, Inc. Device, system, and method for sensor provisioning
US11184162B1 (en) * 2018-09-28 2021-11-23 NortonLifeLock Inc. Privacy preserving secure task automation
WO2020076630A1 (en) * 2018-10-08 2020-04-16 Convida Wireless, Llc Device discovery and connectivity in a cellular network
US20230221690A1 (en) * 2022-01-07 2023-07-13 Honeywell International Inc. Seamless wireless connection during commissioning of networked building controllers

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030020595A1 (en) * 2001-07-12 2003-01-30 Philips Electronics North America Corp. System and method for configuration of wireless networks using position information
JP2007218614A (ja) * 2006-02-14 2007-08-30 Oki Electric Ind Co Ltd 位置推定方法及び位置推定システム
US20070210961A1 (en) * 2006-03-13 2007-09-13 Romijn Willem A Detemining location information of network equipment in wireless communication systems
US8373362B2 (en) * 2008-04-14 2013-02-12 Digital Lumens Incorporated Methods, systems, and apparatus for commissioning an LED lighting fixture with remote reporting
US8138690B2 (en) 2008-04-14 2012-03-20 Digital Lumens Incorporated LED-based lighting methods, apparatus, and systems employing LED light bars, occupancy sensing, local state machine, and meter circuit
JP4840395B2 (ja) * 2008-04-18 2011-12-21 ソニー株式会社 情報処理装置、プログラム、情報処理方法、および情報処理システム
RU2011111421A (ru) * 2008-08-27 2012-10-10 Конинклейке Филипс Электроникс Н.В. (Nl) Ввод в эксплуатацию сетевой системы
EP2257131A1 (en) * 2009-05-29 2010-12-01 Koninklijke Philips Electronics N.V. An auto-addressing method for a tiled lighting system
US8159156B2 (en) * 2009-08-10 2012-04-17 Redwood Systems, Inc. Lighting systems and methods of auto-commissioning
US8994295B2 (en) * 2009-09-05 2015-03-31 Enlighted, Inc. Commission of distributed light fixtures of a lighting system
DE102009047242B4 (de) * 2009-11-27 2012-10-25 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Vorrichtung und Verfahren zum Bestimmen einer Übereinstimmung einer Position mit einer Referenzposition
US8591411B2 (en) * 2010-03-10 2013-11-26 Sotera Wireless, Inc. Body-worn vital sign monitor
GB201107849D0 (en) * 2011-05-11 2011-06-22 Cambridge Silicon Radio Ltd Cooperative positioning
US20130109406A1 (en) * 2011-10-28 2013-05-02 Qualcomm Incorporated Commissioning system for smart buildings
EP2752094B1 (en) * 2011-11-30 2019-04-03 Signify Holding B.V. System and method for commissioning lighting using sound
US10657768B2 (en) * 2012-06-22 2020-05-19 Zonal Systems, Llc System and method for placing virtual geographic zone markers
EP2685793B1 (en) * 2012-07-12 2019-09-04 LG Innotek Co., Ltd. Lighting control method and lighting control system
US9218532B2 (en) * 2012-09-28 2015-12-22 Intel Corporation Light ID error detection and correction for light receiver position determination
TWI487931B (zh) * 2012-10-01 2015-06-11 Internat Mobile Iot Corp 地表定位系統
US9204291B2 (en) * 2012-10-12 2015-12-01 Crestron Electronics, Inc. User identification and location determination in control applications
US8928232B2 (en) * 2013-05-28 2015-01-06 Abl Ip Holding Llc Lighting network with autonomous commissioning
US9673530B2 (en) * 2013-09-12 2017-06-06 Olea Networks Portable wireless mesh device having improved antenna system
WO2015077767A1 (en) * 2013-11-25 2015-05-28 Daniel Ryan System and method for communication with a mobile device via a positioning system including rf communication devices and modulated beacon light sources
CN103945331B (zh) * 2014-03-05 2017-12-08 西安交通大学 一种利用wifi场强进行离去角度估计的定位方法
US10171939B2 (en) * 2014-07-15 2019-01-01 Belkin International, Inc. Control based on geo-dependent conditions
WO2017025324A1 (en) * 2015-08-07 2017-02-16 Philips Lighting Holding B.V. Lighting control
US10652803B2 (en) * 2015-09-08 2020-05-12 Signify Holding B.V. Commissioning of lighting devices
CN108141943B (zh) * 2015-09-18 2020-03-24 飞利浦照明控股有限公司 用于自动化的照明器材位置映射的系统和方法
US20170156195A1 (en) * 2015-11-30 2017-06-01 Stephen John Shepherd Digital Addressable Lighting Interface Configuration
US20180097572A1 (en) * 2016-10-04 2018-04-05 Hitachi, Ltd. Wireless sensor network localization

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021125053A1 (ja) * 2019-12-17 2021-06-24 パナソニックＩｐマネジメント株式会社 情報処理装置、情報処理方法及びプログラム

Also Published As

Publication number Publication date
US11134556B2 (en) 2021-09-28
CN109074267B (zh) 2022-05-24
JP6868039B2 (ja) 2021-05-12
EP3446210A1 (en) 2019-02-27
US20190132930A1 (en) 2019-05-02
WO2017182346A1 (en) 2017-10-26
CN109074267A (zh) 2018-12-21
US20220039245A1 (en) 2022-02-03
RU2018140866A (ru) 2020-05-21

Similar Documents

Publication Publication Date Title
US11290299B2 (en) System and methods for cloud-based monitoring and control of physical environments
US10813200B2 (en) Systems and methods for commissioning and localizing devices used for cloud-based monitoring and control of physical environments
US11843609B2 (en) Computing cloud for monitoring physical environments
JP6902048B2 (ja) クレデンシャルを検証するためのシステム及び方法
JP6868038B2 (ja) 物理的環境を監視及び制御するためのクラウドベースのシステムにおけるシステムデバイスを更新するためのシステム及び方法
US20220039245A1 (en) Systems and methods for sensic device localization
US11388597B2 (en) Systems and methods for authenticating wireless modules
US11876799B2 (en) Systems and methods for registering and localizing building servers for cloud-based monitoring and control of physical environments

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200410

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210225

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: 20210315

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210409

R150 Certificate of patent or registration of utility model

Ref document number: 6868039

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150