特許 7171866 窓ネットワークにおけるコントローラの自動化されたコミッショニング

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-11-07

(45)【発行日】2022-11-15

(54)【発明の名称】窓ネットワークにおけるコントローラの自動化されたコミッショニング

(51)【国際特許分類】

   E06B 5/00 20060101AFI20221108BHJP

   E06B 9/24 20060101ALI20221108BHJP

   G02F 1/15 20190101ALI20221108BHJP

   G02F 1/163 20060101ALI20221108BHJP

   H04B 1/7163 20110101ALI20221108BHJP

   H04Q 9/00 20060101ALI20221108BHJP

【ＦＩ】

E06B5/00 D

E06B9/24 C

G02F1/15 502

G02F1/163

H04B1/7163

H04Q9/00 301C

H04Q9/00 301D

【請求項の数】 46

【外国語出願】

(21)【出願番号】P 2021154739

(22)【出願日】2021-09-22

(62)【分割の表示】P 2019526561の分割

【原出願日】2017-11-20

(65)【公開番号】P2022003213

(43)【公開日】2022-01-11

【審査請求日】2021-09-30

(31)【優先権主張番号】62/426,126

(32)【優先日】2016-11-23

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/551,649

(32)【優先日】2017-08-29

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】509335373

【氏名又は名称】ビュー， インコーポレイテッド

【住所又は居所原語表記】１９５ Ｓ． Ｍｉｌｐｉｔａｓ Ｂｌｖｄ．， Ｍｉｌｐｉｔａｓ， ＣＡ ９５０３５ Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】110000877

【氏名又は名称】弁理士法人ＲＹＵＫＡ国際特許事務所

(72)【発明者】

【氏名】シュリヴァスタヴァ、ダイリャ

(72)【発明者】

【氏名】ワン、ジュエ

(72)【発明者】

【氏名】ブラウン、ステファン クラーク

(72)【発明者】

【氏名】アマーラーン、デイヴィッド

(72)【発明者】

【氏名】カデット、ロナルド エフ．

【審査官】砂川 充

(56)【参考文献】

【文献】特表２０１６－５１６９２１（ＪＰ，Ａ）

【文献】特表２００９－５０８３８７（ＪＰ，Ａ）

【文献】特表２０１３－５３８３０５（ＪＰ，Ａ）

【文献】国際公開第２０１５／１７１８８６（ＷＯ，Ａ１）

【文献】国際公開第２０１６／０９４４４５（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｅ０６Ｂ １／００－１１／０８

Ｇ０２Ｆ １／００－ １／３９

Ｈ０４Ｂ １／００－ １／７６

Ｈ０４Ｑ ９／００－ ９／１６

(57)【特許請求の範囲】

【請求項1】

（ａ）建物に設置された複数の着色可能な窓のうちの少なくとも１つに関連付けられた送信機から無線通信信号を受信することであって、前記通信が、前記少なくとも１つの着色可能な窓のネットワークＩＤを含む、または識別する、受信することと、
（ｂ）前記受信された無線通信信号を分析して、前記少なくとも１つの着色可能な窓の位置を判定することと、
（ｃ）（ｂ）で判定された前記位置と、前記複数の着色可能な窓のうちの少なくともいくつかの示された位置であって、前記建物の１つ以上の図面または他の表現から示されている、前記示された位置とを比較することと、および
（ｄ）前記少なくとも１つの着色可能な窓の前記ネットワークＩＤを、前記示された位置の１つと関連付けることと、を含む、方法。

【請求項2】

前記送信機が、前記着色可能な窓上、またはその中にある、請求項１に記載の方法。

【請求項3】

前記着色可能な窓が、エレクトロクロミックデバイスを備えた断熱ガラスユニットである、請求項１または２に記載の方法。

【請求項4】

前記無線通信信号が、パルスベースの超広帯域（ＵＷＢ）、ブルートゥース（登録商標）、ＢＬＥ、およびＷｉ－Ｆｉ（登録商標）からなる群から選択される無線プロトコルに準拠する、請求項１から３のうちいずれか１項に記載の方法。

【請求項5】

前記無線通信信号が、パルスベースのＵＷＢプロトコルに準拠する、請求項４に記載の方法。

【請求項6】

前記無線通信信号が、ＥＣＭＡ－３６８またはＥＣＭＡ－３６９に準拠する、請求項５に記載の方法。

【請求項7】

窓または窓コントローラ上またはその近くに配置されたアンテナは、マイクロロケーションチップを介して通信するように構成される、請求項１から６のうちいずれか１項に記載の方法。

【請求項8】

前記（ｂ）において前記受信された無線通信信号を分析することは、ＵＷＢプロトコルを用いているマイクロロケーションチップを備える窓コントローラの相対位置を判定することを含む、請求項１から７のいずれか一項に記載の方法。

【請求項9】

少なくとも１つの前記窓コントローラは、全方向信号をブロードキャストするように構成されたマイクロロケーションチップを有するタグを装備される、請求項８に記載の方法。

【請求項10】

少なくとも１つの前記窓コントローラは、ＵＷＢ信号を送信および受信するように構成されたマイクロロケーションチップを装備される、請求項８に記載の方法。

【請求項11】

前記（ｂ）において前記受信された無線通信信号を分析することは、前記少なくとも１つの着色可能な窓の位置を１５センチメートルまたはそれ以上の精度で判定することを含む、請求項５に記載の方法。

【請求項12】

パルスベースのＵＷＢ無線通信信号は、パルスのタイミングまたは位置決めを変調することによってエンコードされた情報を含む、請求項５に記載の方法。

【請求項13】

パルスベースのＵＷＢ無線通信信号は、パルスの極性、パルスの振幅のうち１つ以上を変調することによって、かつ／または直交パルスを使用することによってエンコードされた情報を含む、請求項５に記載の方法。

【請求項14】

前記送信機が、前記窓に取り付けられた窓コントローラ上に配置されたアンテナを備える、請求項１から１３のうちいずれか１項に記載の方法。

【請求項15】

前記窓コントローラが、パルスベースの超広帯域通信信号を発行するように構成されている、請求項１４に記載の方法。

【請求項16】

前記送信機がマイクロロケーションチップの部分である、請求項１４に記載の方法。

【請求項17】

前記アンテナは、前記マイクロロケーションチップを介して通信するように構成される、請求項１６に記載の方法。

【請求項18】

前記マイクロロケーションチップが、約１０センチメートル以下の範囲内でのマイクロロケーションチップの位置の識別を可能にする様式で、前記無線通信信号を送信するように構成される、請求項１６に記載の方法。

【請求項19】

前記示された位置が１つ以上の非窓構成要素の位置をさらに含み、前記１つ以上の非窓構成要素が、ネットワークＩＤと、無線通信のための送信機と、を有し、前記方法は、
少なくとも１つの非窓構成要素の前記送信機から無線通信信号を受信することであって、前記通信が、前記少なくとも１つの非窓構成要素の前記ネットワークＩＤを含む、受信することと、
前記受信された無線通信信号を分析して、前記少なくとも１つの非窓構成要素の前記位置を判定することと、
前記少なくとも１つの非窓構成要素の前記判定された位置を、前記１つ以上の非窓構成要素の前記示された位置と比較することと、
前記少なくとも１つの非窓構成要素の前記ネットワークＩＤを、前記示された位置の１つと関連付けることと、をさらに含む、請求項１から１８のうちいずれか１項に記載の方法。

【請求項20】

前記少なくとも１つの非窓構成要素が、窓コントローラネットワークのマスターコントローラまたはネットワークコントローラである、請求項１９に記載の方法。

【請求項21】

建物内または建物上の位置に設置され、送信機を有する、複数の着色可能な窓を含む、窓ネットワークと、
以下の動作：
（ａ）前記複数の着色可能な窓のうちの少なくとも１つに関連付けられた送信機から無線通信信号を受信することであって、前記通信が、前記少なくとも１つの着色可能な窓のネットワークＩＤを含む、または識別する、受信することと、
（ｂ）前記受信された無線通信信号を分析して、前記少なくとも１つの着色可能な窓の前記位置を判定することと、
（ｃ）（ｂ）で判定された前記位置と、前記複数の着色可能な窓のうちの少なくともいくつかの示された位置であって、前記建物の１つ以上の図面または他の表現から示されている、前記示された位置とを比較することと、および
（ｄ）前記少なくとも１つの着色可能な窓の前記ネットワークＩＤを、前記示された位置の１つと関連付けることと、を実行するように構成されたコミッショニングロジックと、を備える、システム。

【請求項22】

前記着色可能な窓の各々の前記送信機が、パルスベースの超広帯域（ＵＷＢ）、ブルートゥース、ＢＬＥ、およびＷｉ－Ｆｉ（登録商標）からなる群から選択される無線プロトコルを使用して、無線通信するように構成される、請求項２１に記載のシステム。

【請求項23】

少なくとも１つの送信機が、ＥＣＭＡ－３６８またはＥＣＭＡ－３６９を使用して、無線通信するように構成される、請求項２２に記載のシステム。

【請求項24】

前記示された位置が、ネットワークＩＤと、無線通信のための送信機と、を有する非窓構成要素の位置をさらに備え、前記コミッショニングロジックが、以下の動作：
少なくとも１つの非窓構成要素の前記送信機から無線通信信号を受信することであって、前記通信が、前記少なくとも１つの非窓構成要素の前記ネットワークＩＤを含む、受信することと、
前記受信された無線通信信号を分析して、前記少なくとも１つの非窓構成要素の前記位置を判定することと、
前記少なくとも１つの非窓構成要素の前記判定された位置を、前記非窓構成要素の前記示された位置と比較することと、
前記少なくとも１つの非窓構成要素の前記ネットワークＩＤを、前記示された位置の１つと関連付けることと、を実行するようにさらに構成される、請求項２１から２３のうちいずれか１項に記載のシステム。

【請求項25】

前記建物の様々な既知の位置に配置されたマイクロロケーションチップを備えるアンカーをさらに備える、請求項２１から２４のうちいずれか１項に記載のシステム。

【請求項26】

それぞれの１つの既知の位置に備えられたネットワーク装置の1つ以上のアイテムをさらに備え、前記ネットワーク装置の１つ以上のアイテムは１つ以上の無線ルータ、窓コントローラまたはネットワークコントローラを含む、請求項２５に記載のシステム。

【請求項27】

前記ネットワーク装置の１つ以上のアイテムの少なくとも1つは、全方向信号をブロードキャストするように構成されたマイクロロケーションチップを有するタグを装備される、請求項２６に記載のシステム。

【請求項28】

前記システムは、ブロードキャスト信号が前記タグから前記アンカーに到達するのにかかる時間を分析することで、前記タグの前記位置を判定するように構成される、請求項２７に記載のシステム。

【請求項29】

前記アンカーは、コミッショニングの目的で前記建物内に一時的に設置されるように構成される、請求項２５から２８のうちいずれか１項に記載のシステム。

【請求項30】

前記アンカーは、前記コミッショニングが完了した後に除去されるように構成される、請求項２９に記載のシステム。

【請求項31】

前記システムは、各窓コントローラで受信されたＵＷＢ信号を分析することによって、第２の窓コントローラの前記位置に関連する第１の窓コントローラの前記位置を判定するように構成される、請求項２６に記載のシステム。

【請求項32】

前記システムは、各窓コントローラで受信されたＵＷＢ信号を分析し、集約することによって、全てまたは一部の窓コントローラ間の相対位置を判定するように構成される、請求項２６に記載のシステム。

【請求項33】

装置であって、
以下の動作：
（ａ）複数の着色可能な窓のうちの少なくとも１つに関連付けられた送信機から無線通信信号を受信することであって、前記窓は建物内または建物上の位置に設置されており、前記通信が、前記少なくとも１つの着色可能な窓のネットワークＩＤを含む、または識別する、受信することと、
（ｂ）前記受信された無線通信信号を分析して、前記少なくとも１つの着色可能な窓の前記位置を判定することと、
（ｃ）（ｂ）で判定された前記位置と、前記複数の着色可能な窓のうちの少なくともいくつかの示された位置であって、前記建物の１つ以上の図面または他の表現から示されている、前記示された位置とを比較することと、および
（ｄ）前記少なくとも１つの着色可能な窓の前記ネットワークＩＤを、前記示された位置の１つと関連付けることと、をコントロールするように構成されたコントローラ、を備える、装置。

【請求項34】

前記示された位置が１つ以上の非窓構成要素の位置をさらに含み、前記１つ以上の非窓構成要素が、ネットワークＩＤと、無線通信のための送信機と、を有し、前記コントローラが、以下の動作：
少なくとも１つの非窓構成要素の前記送信機から無線通信信号を受信することであって、前記通信が、前記少なくとも１つの非窓構成要素の前記ネットワークＩＤを含む、受信することと、
前記受信された無線通信信号を分析して、前記少なくとも１つの非窓構成要素の前記位置を判定することと、
前記少なくとも１つの非窓構成要素の前記判定された位置を、前記１つ以上の非窓構成要素の前記示された位置と比較することと、
前記少なくとも１つの非窓構成要素の前記ネットワークＩＤを、前記示された位置の１つと関連付けることと、をコントロールするようにさらに構成される、請求項３３に記載の装置。

【請求項35】

前記無線通信信号が、パルスベースの超広帯域（ＵＷＢ）、ブルートゥース（登録商標）、ＢＬＥ、およびＷｉ－Ｆｉ（登録商標）からなる群から選択される無線プロトコルに準拠する、請求項３３又は３４に記載の装置。

【請求項36】

前記無線通信信号が、パルスベースのＵＷＢプロトコルに準拠する、請求項３５に記載の装置。

【請求項37】

前記無線通信信号が、ＥＣＭＡ－３６８またはＥＣＭＡ－３６９に準拠する、請求項３６に記載の装置。

【請求項38】

前記（ｂ）において前記受信された無線通信信号を分析することは、ＵＷＢプロトコルを用いているマイクロロケーションチップを備える窓コントローラの相対位置を判定することを含む、請求項３７に記載の装置。

【請求項39】

少なくとも１つの前記窓コントローラは、全方向信号をブロードキャストするように構成されたマイクロロケーションチップを有するタグ、かつ／またはＵＷＢ信号を送信および受信するように構成されたマイクロロケーションチップを装備される、請求項３８に記載の装置。

【請求項40】

パルスベースのＵＷＢ無線通信信号は、パルスのタイミングまたは位置決めを変調することによって、かつ／またはパルスの極性、パルスの振幅のうち１つ以上を変調することによって、かつ／または直交パルスを使用することによってエンコードされた情報を含む、請求項３６に記載の装置。

【請求項41】

コントローラに以下の動作：
（ａ）複数の着色可能な窓のうちの少なくとも１つに関連付けられた送信機から無線通信信号を受信することであって、前記窓は建物内または建物上の位置に設置されており、前記通信が、前記少なくとも１つの着色可能な窓のネットワークＩＤを含む、または識別する、受信することと、
（ｂ）前記受信された無線通信信号を分析して、前記少なくとも１つの着色可能な窓の前記位置を判定することと、
（ｃ）（ｂ）で判定された前記位置と、前記複数の着色可能な窓のうちの少なくともいくつかの示された位置であって、前記建物の１つ以上の図面または他の表現から示されている、前記示された位置とを比較することと、
（ｄ）前記少なくとも１つの着色可能な窓の前記ネットワークＩＤを、前記示された位置の１つと関連付けることと、を実行するように備えられる、コンピュータプログラム。

【請求項42】

コントローラに以下の動作：
少なくとも１つの非窓構成要素の前記送信機から無線通信信号を受信することであって、前記通信が、前記少なくとも１つの非窓構成要素の前記ネットワークＩＤを含む、受信することと、
前記受信された無線通信信号を分析して、前記少なくとも１つの非窓構成要素の前記位置を判定することと、
前記少なくとも１つの非窓構成要素の前記判定された位置と前記１つ以上の非窓構成要素の前記示された位置とを比較することと、
前記少なくとも１つの非窓構成要素の前記ネットワークＩＤと前記示された位置の１つとを関連付けることと、を実行するようさらに備えられる、請求項４１に記載のコンピュータプログラム。

【請求項43】

前記無線通信信号が、パルスベースの超広帯域（ＵＷＢ）、ブルートゥース（登録商標）、ＢＬＥ、およびＷｉ－Ｆｉ（登録商標）からなる群から選択される無線プロトコルに準拠する、請求項４１又は４２に記載のコンピュータプログラム。

【請求項44】

前記（ｂ）において前記受信された無線通信信号を分析することは、パルスベースのＵＷＢ無線プロトコルを用いているマイクロロケーションチップを備える窓コントローラの相対位置を判定することを含む、請求項４３に記載のコンピュータプログラム。

【請求項45】

少なくとも１つの前記窓コントローラは、全方向信号をブロードキャストするように構成されたマイクロロケーションチップを有するタグ、かつ／またはＵＷＢ信号を送信および受信するように構成されたマイクロロケーションチップを装備される、請求項４４に記載のコンピュータプログラム。

【請求項46】

パルスベースのＵＷＢ無線通信信号は、パルスのタイミングまたは位置決めを変調することによって、かつ／またはパルスの極性、パルスの振幅のうち１つ以上を変調することによって、かつ／または直交パルスを使用することによってエンコードされた情報を含む、請求項４４に記載のコンピュータプログラム。

【発明の詳細な説明】

【背景技術】

【0001】

［関連出願の相互参照］
本出願は、２０１６年１１月２３日に出願された米国仮特許出願第６２／４２６，１２６号および２０１７年８月２９日に出願された米国仮特許出願第６２／５５１，６４９号の両方の利益を主張するものであり、これらの両方は、「ＡＵＴＯＭＡＴＥＤ ＣＯＭＭＩＳＳＩＯＮＩＮＧ ＯＦ ＣＯＮＴＲＯＬＬＥＲＳ ＩＮ Ａ ＷＩＮＤＯＷ ＮＥＴＷＯＲＫ」と題されており、またこれらの両方は、それらの全体があらゆる目的のために参照により本明細書に組み込まれる。

【0002】

エレクトロクロミズムは、典型的には電圧変化を受けることによって、材料が、異なる電子状態に置かれたときに光学的性質において可逆的な電気化学的に媒介される変化を示す現象である。光学特性は、典型的には、色、透過率、吸光度、および反射率のうちの１つ以上である。

【0003】

エレクトロクロミック材料は、例えば、窓ガラス上の薄膜コーティングとして、家庭用、商業用および他の用途の窓に組み込まれ得る。そのような窓の色、透過率、吸光度、および／または反射率は、エレクトロクロミック材料の変化を引き起こすことによって変化させることができ、例えば、エレクトロクロミック窓は、電子的に暗くまたは明るくすることができる窓である。窓のエレクトロクロミックデバイス（ＥＣ）に小さな電圧をかけると、窓は暗くなり、その電圧極性を逆にすると、窓は明るくなる。この能力は、窓を通過する光の量の制御を可能にし、エレクトロクロミック窓が省エネルギーデバイスとして使用される機会を提示する。

【0004】

エレクトロクロミズムは１９６０年代に発見されたが、エレクトロクロミックデバイス、特にエレクトロクロミック窓は、依然として残念ながら様々な問題を抱えており、エレクトロクロミック技術、装置およびエレクトロクロミックデバイスを製造および／または使用する関連方法における多くの近年の進歩にもかかわらず、それらの完全な商業的可能性を実現し始めていない。例えば、エレクトロクロミック窓および関連するコントローラをコミッショニングすること、ならびにエレクトロクロミック窓および関連するコントローラについての情報を提示するユーザインターフェースに関する問題が依然として残っている。

【発明の概要】

【0005】

本開示の一態様は、ユーザインターフェースを制御して、ネットワークによって接続された複数の光学的に切り替え可能な窓に関する情報を提供するための、非一時的コンピュータ実行可能命令を格納するコンピュータ可読媒体に関するコンピュータプログラム製品に関する。命令は、（ａ）コンピューティングデバイス上に設けられた光学的に切り替え可能な窓のうちの１つ以上に関する情報を表示するための要求を受信すること、および（ｂ）複数の光学的に切り替え可能な窓のうちの少なくともいくつかを監視、グループ化、および／または制御することに関するユーザ入力を受信するための１つ以上のスマートオブジェクトを示す１つ以上のビューを、ユーザインターフェース上に表示することを特徴とし得る。（ｂ）におけるスマートオブジェクトは、光学的に切り替え可能な窓のうちの１つ以上のグラフィック表現であり得る。さらに、（ｂ）におけるスマートオブジェクトは、建物内の１つ以上の光学的に切り替え可能な窓の位置をグラフィカルに示す様式で、１つ以上のビュー内に表示され得る。

【0006】

一部の実施形態では、コンピューティングデバイスは、ネットワークから遠隔の無線デバイスである。

【0007】

一部の実施形態では、コンピュータプログラム製品は、複数の光学的に切り替え可能なデバイスのうちの少なくとも１つの光学的状態を変更するためのユーザ命令を受信するため、およびユーザ命令を、ネットワークに送信するための命令をさらに含む。

【0008】

一部の実施形態では、コンピュータプログラム製品は、１つ以上のビューを表示する前に、複数の光学的に切り替え可能な窓の各々の建物内の位置を含む、位置情報を受信するための命令をさらに含む。

【0009】

一部の実施形態では、位置情報は、地理的位置決めを使用して、窓ネットワークによって判定される。

【0010】

一部の実施形態では、コンピュータプログラム製品は、１つ以上のビューを表示する前に、複数の光学的に切り替え可能な窓のサイズおよび配向を含む情報を受信するための命令をさらに含み、１つ以上のスマートオブジェクトを示す１つ以上のビューを表示することは、１つ以上の光学的に切り替え可能な窓の窓サイズおよび配向に従って、１つ以上のスマートオブジェクトの各々を示すことを含む。

【0011】

一部の実施形態では、少なくとも１つのビューは、モデルの上にオーバーレイされた１つ以上のスマートオブジェクトとともに建物の３次元モデルを提示する。

【0012】

一部の実施形態では、３次元モデルは、複数の光学的に切り替え可能な窓の位置、サイズ、および配向を使用して作成される。

【0013】

一部の実施形態において、少なくとも１つのビューは、２次元の間取り上に示された１つ以上のスマートオブジェクトを提示する。

【0014】

一部の実施形態では、コンピュータプログラム製品は、１つ以上のビューを表示する前に、光学的に切り替え可能な窓のうちの少なくとも１つの現在の着色状態を含む情報を受信するための命令をさらに含み、スマートオブジェクトを示す１つ以上のビューを表示することは、現在の着色状態少なくとも１つの光学的に切り替え可能な窓を示すことを含む。

【0015】

一部の実施形態では、１つ以上のスマートオブジェクトは、触覚的対話、音、動き、配向、およびコンピューティングデバイスの判定された位置を含む群から選択されるユーザ対話によって操作されるように、設計または構成される。

【0016】

一部の実施形態では、コンピュータプログラム製品は、複数の光学的に切り替え可能な窓のうちの少なくとも１つに対するコンピューティングデバイスの位置を受信するための命令をさらに含む。

【0017】

一部の実施形態では、コンピュータプログラム製品は、複数の光学的に切り替え可能な窓のうちの少なくとも１つに対して、コンピューティングデバイスの配向を判定するための命令をさらに含む。

【0018】

一部の実施形態において、１つ以上のビューを表示するための命令は、複数の光学的に切り替え可能な窓のサブセットを表示するための命令を含み、光学的に切り替え可能な窓のそのサブセットは、コンピューティングデバイスの位置に依存する。

【0019】

一部の実施形態では、コンピュータプログラム製品は、１つ以上のビューを表示するための命令が、コンピューティングデバイスの位置または配向に依存する様式で、複数の光学的に切り替え可能な窓のうちの少なくとも１つを表示するための命令を含むことをさらに含む。

【0020】

一部の実施形態では、コンピュータプログラム製品は、カスタマイズされたビューを作成するためのユーザからの命令を受信するため、およびカスタマイズされたビューを表示するための命令をさらに含む。

【0021】

一部の実施形態では、コンピュータプログラム製品は、１つ以上のスマートオブジェクトのユーザ操作を受信するため、ならびにスマートオブジェクトに関連する１つ以上の光学的に切り替え可能な窓についての、適用された着色サイクルの数、窓の製造情報、窓のヘルス情報、窓の寸法、窓のタイプ、窓のシリアル番号、関連する窓の構成要素、窓の設置作業番号、窓の設置日、建物の情報、窓のファサードのゾーニング情報、関連する温度センサからの温度情報、関連する光センサからの光強度情報、関連する湿度センサからの湿度情報、および関連する占有センサからの占有情報からなる群から選択される窓情報を、ユーザに提供するための命令をさらに含む。

【0022】

本開示の別の態様は、各窓がスマートオブジェクトによって表される１つ以上の光学的に切り替え可能な窓の窓ネットワーク用のグラフィカルユーザインターフェースに表示されるビューをレンダリングする方法に関する。この方法は、（ａ）情報を受信することであって、情報が、窓ネットワーク上の各窓についての窓ＩＤおよび位置を含む、受信することと、（ｂ）窓情報に基づいて、スマートオブジェクトを選択することと、（ｃ）一致して示されるべきビューについての視点を選択することと、（ｄ）各選択されたスマートオブジェクトが、光学的に切り替え可能な窓の位置に従って配置されているビューを表示することとを特徴とすることができる。

【0023】

一部の実施形態では、（ｃ）におけるビューの視点を選択することは、建物の２次元の間取り、建物外部の観点からの建物の３次元の視点、部屋内の観点からの２次元の視点、部屋内の観点からの３次元の視点、複数の階を含む２次元の視点、グラフィカルユーザインターフェースを表示するデバイスの位置および配向に対応する観点からの視点、ならびにユーザが作成したカスタムビューからなる群から視点を選択することを含む。

【0024】

一部の実施形態では、（ｃ）における視点は、グラフィカルユーザインターフェースとのユーザ対話に基づいて選択される。

【0025】

一部の実施形態では、（ｃ）における視点は、グラフィカルユーザインターフェースを表示するデバイスの位置または配向に基づいて選択される。

【0026】

一部の実施形態では、（ｃ）における視点は、グラフィカルユーザインターフェースのユーザに付与された許可に基づいて選択される。

【0027】

一部の実施形態では、（ａ）で受信された情報は、窓ネットワーク上の１つ以上の非窓構成要素のＩＤおよび位置をさらに含み、１つ以上の追加のスマートオブジェクトは、１つ以上の他のデバイスのＩＤに基づいて選択され、１つ以上の追加のスマートオブジェクトは、それらの位置に従って、（ｄ）に表示される。

【0028】

一部の実施形態では、１つ以上のデバイスの各々は、温度センサ、光センサ、湿度センサ、気流センサ、占有センサ、窓コントローラ、ネットワークコントローラ、およびマスターコントローラからなる群から選択される。

【0029】

本開示の一態様は、１つ以上の光学的に切り替え可能な窓のネットワークＩＤを、建物内の光学的に切り替え可能な窓（複数可）の設置位置と関連付ける方法に関する。これらの方法では、各光学的に切り替え可能な窓は、無線通信用に構成されたネットワークＩＤおよび送信機を有する。方法は、（ａ）建物の図面または別の表現を受信することであって、図面または別の表現が、建物内または建物上の光学的に切り替え可能な窓の位置を提供する、受信することと、（ｂ）少なくとも１つの光学的に切り替え可能な窓の送信機から無線通信信号を受信することであって、無線通信信号が、少なくとも１つの光学的に切り替え可能な窓のネットワークＩＤを含む、または識別する、受信することと、（ｃ）受信された無線通信信号を分析して、少なくとも１つの光学的に切り替え可能な窓の位置を判定することと、（ｄ）（ｃ）で判定された位置と、（ａ）で受信された図面または他の建物表現からの窓のうちの少なくともいくつかの位置とを比較し、少なくとも１つの光学的に切り替え可能な窓のネットワークＩＤを、図面または他の表現に提供された位置と関連付けることとを特徴とすることができる。

【0030】

一部の実施形態において、複数の光学的に切り替え可能な窓の各々の送信機は、光学的に切り替え可能な窓の上、またはその中にある。

【0031】

一部の実施形態において、光学的に切り替え可能な窓は、エレクトロクロミックデバイスを備えた断熱ガラスユニットである。

【0032】

一部の実施形態において、無線通信信号は、パルスベースの超広帯域、ブルートゥース（登録商標）、ＢＬＥ、およびＷｉ－Ｆｉ（登録商標）からなる群から選択される無線プロトコルに準拠する。

【0033】

一部の実施形態では、無線通信信号は、パルスベースの超広帯域プロトコルに準拠する。

【0034】

一部の実施形態において、無線通信信号は、ＥＣＭＡ－３６８またはＥＣＭＡ－３６９に準拠する。

【0035】

一部の実施形態では、１つ以上の図面または他の表現は、建築図面または相互接続図を含む。

【0036】

一部の実施形態では、ネットワークＩＤはＣＡＮ ＩＤである。

【0037】

一部の実施形態では、方法は、少なくとも１つの光学的に切り替え可能な窓のネットワークＩＤと、１つ以上の図面または他の表現に提供された１つの位置の（ｄ）からの関連付けを格納することをさらに含む。

【0038】

一部の実施形態では、（ｄ）からの関連付けを格納することは、ネットワーク構成ファイルにおける（ｄ）からの関連付けを格納することを含む。

【0039】

一部の実施形態では、ネットワーク構成ファイルは、マスターコントローラ、ネットワークコントローラ、遠隔無線デバイス、およびクラウドからなる群から選択される位置で、メモリに格納される。

【0040】

一部の実施形態では、送信機は、窓に取り付けられ窓コントローラ上に配置されたアンテナを備える。

【0041】

一部の実施形態において、窓コントローラは、パルスベースの超広帯域通信信号を発行するように構成される。

【0042】

一部の実施形態では、送信機はマイクロロケーションチップの部分である。

【0043】

一部の実施形態では、マイクロロケーションチップは、約１０センチメートル以下の範囲内でのマイクロロケーションチップの位置の識別を可能にする様式で、無線通信信号を送信するように構成される。

【0044】

一部の実施形態では、（ａ）における１つ以上の図面または他の表現は、１つ以上の非窓構成要素の位置をさらに含み、１つ以上の非窓構成要素は、ネットワークＩＤと、無線通信のための送信機と、を有し、方法は、少なくとも１つの非窓構成要素の送信機から無線通信信号を受信することであって、通信が、少なくとも１つの非窓構成要素のネットワークＩＤを含む、受信することと、受信された無線通信信号を分析して、少なくとも１つの非窓構成要素の位置を判定することと、少なくとも１つの非窓構成要素の判定された位置を、（ａ）における１つ以上の図面または表現によって提供された複数の非窓構成要素の位置と比較し、少なくとも１つの非窓構成要素のネットワークＩＤを、１つ以上の図面または他の表現で提供された１つの位置と関連付けることと、をさらに含む。

【0045】

一部の実施形態において、少なくとも１つの非窓構成要素は、窓コントローラネットワークのマスターコントローラまたはネットワークコントローラである。

【0046】

本開示の別の態様は、光学的に切り替え可能な窓のネットワークＩＤを建物内の光学的に切り替え可能な窓の設置位置と関連付けるためのシステムに関する。これらのシステムでは、各光学的に切り替え可能な窓は、無線通信用に構成されたネットワークＩＤおよび送信機を有する。システムは、建物内または建物上の位置に設置された送信機を有し、送信機およびコミッショニングロジックを有する、複数の光学的に切り替え可能な窓を備える、窓ネットワークによって特徴付けられ得る。コミッショニングロジックは、以下の動作：（ａ）建物内の複数の光学的に切り替え可能な窓の位置を提供する、建物の１つ以上の図面または他の表現を受信すること、（ｂ）複数の光学的に切り替え可能な窓のうちの少なくとも１つの送信機から無線通信信号を受信することであって、通信が、少なくとも１つの光学的に切り替え可能な窓のネットワークＩＤを含む、または識別する、受信すること、（ｃ）受信された無線通信信号を分析して、少なくとも１つの光学的に切り替え可能な窓の位置を判定すること、および（ｄ）（ｃ）で判定された位置と、（ａ）で受信された１つ以上の図面または他の表現からの複数の光学的に切り替え可能な窓のうちの少なくともいくつかの位置とを比較し、少なくとも１つの光学的に切り替え可能な窓のネットワークＩＤを、１つ以上の図面または他の表現に提供された１つの位置と関連付けること、を実行するように構成されてもよい。

【0047】

一部の実施形態において、光学的に切り替え可能な窓の各々の送信機は、パルスベースの超広帯域、ブルートゥース（登録商標）、ＢＬＥ、およびＷｉ－Ｆｉ（登録商標）からなる群から選択される無線プロトコルを使用して、無線通信するように構成される。

【0048】

一部の実施形態では、光学的に切り替え可能な窓の各々の送信機は、パルスベースの超広帯域プロトコルを使用して、無線通信するように構成される。

【0049】

一部の実施形態では、光学的に切り替え可能な窓の各々の送信機は、ＥＣＭＡ－３６８またはＥＣＭＡ－３６９を使用して、無線通信するように構成される。

【0050】

一部の実施形態では、窓ネットワークは、ネットワークＩＤと、無線通信のための送信機と、を有する非窓構成要素をさらに備え、コミッショニングロジックは、以下の動作：少なくとも１つの非窓構成要素の送信機から無線通信信号を受信することであって、通信が、少なくとも１つの非窓構成要素のネットワークＩＤを含む、受信することと、受信された無線通信信号を分析して、少なくとも１つの非窓構成要素の位置を判定することと、少なくとも１つの非窓構成要素の判定された位置を、（ａ）における１つ以上の図面または表現によって提供された複数の非窓構成要素の位置と比較し、少なくとも１つの非窓構成要素のネットワークＩＤを、１つ以上の図面または他の表現で提供された１つの位置と関連付けることと、を実行するようにさらに構成される。

【0051】

本開示の別の態様は、窓ネットワーク上に１つ以上の光学的に切り替え可能な窓を表示するためのコンピュータプログラム製品のグラフィカルユーザインターフェースを生成するための方法に関する。この方法は、動作（ａ）～（ｅ）を含む。動作（ａ）において、建物モデルが少なくとも部分的に複数の表面によって画定され、各表面がノードＩＤを有する、建物の３次元モデルが受信される。動作（ｂ）において、光学的に切り替え可能な窓の各々に対するネットワークＩＤを含む情報が受信される。動作（ｃ）において、光学的に切り替え可能な窓の各々のネットワークＩＤは、少なくとも１つのノードＩＤとペアにされる。動作（ｄ）において、光学的に切り替え可能な窓を表す１つ以上のスマートオブジェクトが画定され、各スマートオブジェクトは、光学的に切り替え可能な窓に関する情報を提供する。最後に、動作（ｅ）において、３次元モデルおよびスマートオブジェクトが、電子デバイス上に表示される。

【0052】

一部の場合に、建物の３次元モデルは、建物構造体の設計および検査のためのモデリング環境を有する、コンピュータ支援設計ソフトウェアによって産生される。一部の場合に、光学的に切り替え可能な窓の各々のネットワークＩＤを、少なくとも１つのノードＩＤとペアにすることは、各ペアリングをネットワーク構成ファイルに格納することを含む。

【0053】

一部の場合に、各スマートオブジェクトは、光学的に切り替え可能な窓を制御するためのユーザ入力を受信するように構成され、方法は、スマートオブジェクトを介して、光学的に切り替え可能な窓のうちの少なくとも１つを制御するためのユーザ命令を受信する動作、および光学的に切り替え可能な窓のうちの少なくとも１つを制御するためのユーザ命令を、マスターコントローラに送信する動作をさらに含む。

【0054】

一部の場合に、受信された情報は、光学的に切り替え可能な窓の各々についての位置情報を含み、窓の各々のネットワークＩＤを、少なくとも１つのノードＩＤとペアにすることは、位置情報を、３次元モデル内の複数の表面のうちの少なくとも１つの位置と比較するロジックを実行することを含む。

【0055】

一部の場合に、光学的に切り替え可能な窓の各々のネットワークＩＤを、少なくとも１つのノードＩＤとペアにすることは、３次元モデルを表示した後に、ユーザ選択を介して実行される。

【0056】

一部の場合に、３次元モデルは、建物の内部領域における無線電力伝送システムによって生成された、電磁信号を分析することによって生成される。無線電力伝送システムは、一部の場合に、窓ネットワークのサブシステムであり得る。

【0057】

開示された実施形態のこれらおよび他の特徴は、関連する図面を参照してより十分に説明されるであろう。

【図面の簡単な説明】

【0058】

【図1】エレクトロクロミックデバイススタックの従来の形成を示す概略断面図である。

【図2A】複数のエレクトロクロミック窓を制御し、駆動するためのシステムの一例の描写を示す。

【図2B】複数のエレクトロクロミック窓を制御し、駆動するためのシステムの別の例の描写を示す。

【図2C】いくつかの実装形態による、複数のＩＧＵを制御するように動作可能なネットワークシステムの一例のブロック図を示す。

【図3】ＩＧＵが配置され得る階層構造を示す図である。

【図4A】は、窓ネットワーク上で様々な機能を実行するために、ネットワーク構成ファイルが制御ロジックによってどのように使用されるかを示す図である。

【図4B】ネットワーク構成ファイルを作成する典型的なプロセスを示す図である。

【図5A】建築上の間取り図から作成された相互接続図を示す。

【図5B】相互接続図の立面図を示す。

【図6】自動コミッショニングの一実施形態に関連する動作を示すフローチャートである。

【図7】コミッショニングロジックを使用して、ネットワーク構成ファイルを生成し得るプロセスを示す図である。

【図8】相互接続図を必要とせずに、コミッショニングロジックを使用して、ネットワーク構成ファイルを生成し得るプロセスを示す図である。

【図9】ゾーンとゾーン群がリスト形式で提供される、ＩＧＵを制御するための典型的なＧＵＩを示す図である。

【図10】部屋内から見られるように、５つのエレクトロクロミック窓を有する部屋の内部を示す図である。

【図11】スマートオブジェクトを使用して、ユーザに窓ネットワークの制御を提供する、内部透視図を示すＧＵＩの図である。

【図12】スマートオブジェクトを使用して、ユーザに窓ネットワークの制御を提供する、２次元透視図を示すＧＵＩの図である。

【図13】画像からワイヤーフレームモデルを生成するプロセスを示す図である。

【図14】判定された位置とともにスマートオブジェクトを使用して、建物のより認識可能なモデルを生成し得る方法を示す図である。

【図15】建物の３Ｄモデルにスマートオブジェクトを重ね合わせて使用して、窓ネットワークの制御をユーザに提供する外部透視図を示すＧＵＩの図である。

【図16】スマートオブジェクトを使用して、窓ネットワークの制御をユーザに提供する写真を重ね合わせたワイヤーフレームモデルを利用した内部透視図を示すＧＵＩの図である。

【図17】スマートオブジェクトを使用して、ユーザに窓ネットワークの制御を提供する、２次元の間取り透視図を示すＧＵＩの図である。

【図18】スマートオブジェクトの選ばれた選択が表示されるカスタマイズされた図を示すＧＵＩの図である。

【図19】施設管理アプリケーションの構造体を概略的に示す図である。

【図20】施設管理アプリケーションのグラフィカルユーザインターフェースの一例を示す図である。

【図21A】インテリジェンスアルゴリズムで使用され得る窓パラメータを示す図である。

【図21B】インテリジェンスアルゴリズムで使用され得る窓パラメータを示す図である。

【図21C】インテリジェンスアルゴリズムで使用され得る窓パラメータを示す図である。

【図22】インテリジェンスが部屋内の占有領域をどのように計算し得るかを示す図である。

【図23】マルチゾーンの着色可能な窓を制御するために、インテリジェンスパラメータがどのように使用され得るかを示す図である。

【図24】窓ネットワーク上の光学的に切り替え可能な窓を制御するために、施設管理アプリケーションによって使用され得るプロセスを示す図である。

【図25】施設管理アプリケーションが準備および動作され得るプロセスを示す図である。

【図26A】窓ネットワークを設計するために、設計モジュールのグラフィカルユーザインターフェースがどのように使用され得るかを示す図である。

【図26B】窓ネットワークを設計するために、設計モジュールのグラフィカルユーザインターフェースがどのように使用され得るかを示す図である。

【図26C】窓ネットワークを設計するために、設計モジュールのグラフィカルユーザインターフェースがどのように使用され得るかを示す図である。

【図26D】窓ネットワークを設計するために、設計モジュールのグラフィカルユーザインターフェースがどのように使用され得るかを示す図である。

【図27】建物内の光学的に切り替え可能な窓のネットワークを設計するために、設計モジュールが使用され得るプロセスを示す図である。

【発明を実施するための形態】

【0059】

［前書き］
以下の「発明を実施するための形態」は、開示された態様を説明する目的で、特定の実施形態または実装形態を対象とする。しかしながら、本明細書における教示は、多くの様々なやり方で適用、実装され得る。以下の「発明を実施するための形態」では、添付図面を参照する。開示された実装形態は、当業者に、実装形態を実施することを可能にさせるように十分詳細に説明されているが、これらの例が限定的ではなく、他の実装形態が使用されてもよく、また開示された実装形態に、それらの趣旨および範囲を逸脱することなく変更がなされてもよいことが理解されるべきである。なお、開示された実施形態は、エレクトロクロミック窓（スマート窓とも呼ばれる）に焦点を当てるが、本明細書に開示された概念は、例えば、とりわけ、液晶デバイスおよび懸濁粒子デバイスを含む他のタイプの切り替え可能な光学デバイスに適用し得る。例えば、エレクトロクロミックデバイスではなく、液晶デバイスまたは懸濁粒子デバイスが、開示された実装形態のうちのいくつかまたは全てに組み込まれる可能性がある。さらに、「ｏｒ（または）」という接続詞は、本明細書では、特に断りのない限り、適宜、両立的意味にあることが意図され、例えば、「Ａ、Ｂ ｏｒ Ｃ（Ａ、ＢまたはＣ）」という句は、「Ａ」、「Ｂ」、「Ｃ」、「ＡおよびＢ」、「ＢおよびＣ」、「ＡおよびＣ」、および「Ａ、ＢおよびＣ」の可能性を含むことが意図される。「～するように設計される」、「～するように適合される」、「～するように構成される」、「～するようにプログラムされる」、「～するように動作可能」、および「～することが可能である」という用語は、必要に応じて互換的に使用され得る。そのような用語は、米国特許法１１２（ｆ）を引き起こすことを意図していない。さらに、本明細書で使用されるとき、用語窓ガラス、ライト（ｌｉｔｅ）、および基板は互換的に使用される。エレクトロクロミック窓は、ＩＧＵ、ラミネート構造体、またはその両方（すなわち、ＩＧＵが、そのライトとして１つ以上のラミネート状の窓ガラス（例えば、窓ガラスのうちの１つが単一のガラスシートであり、窓ガラスのうちの他方が２枚のガラスシートのラミネートである２重窓ガラスＩＧＵ）を有する）の形態であってもよい。ラミネートは、２枚、３枚またはそれ以上のガラスシートを有してもよい。

【0060】

エレクトロクロミック窓は、例えば、オフィスビルおよび住宅ビルなどの様々な環境で使用することができる。多くの従来のエレクトロクロミック窓の複雑さ（例えば、配線、コントローラの設置およびプログラミングなど）は、それらの使用を妨げる場合がある。例えば、住宅の顧客は、エレクトロクロミック窓およびその設置要件に慣れていない可能性がある地元の請負業者によって窓が設置される可能性が高い。したがって、特定の開示された実施形態における１つの目的は、非エレクトロクロミック窓と同じくらい容易に設置できるエレクトロクロミックＩＧＵおよび窓アセンブリを提供することである。容易な設置を促進する特定の開示される特徴は、無線電力能力および／または自己電力能力、無線制御通信、自己メッシュネットワーク、オンボードコントローラ、自動化されたコミッショニング、ならびに一般的に利用可能な窓（例えば、２重窓ガラスまたは３重窓ガラスＩＧＵ）と一致するフォームファクタを含む。様々な実施形態に含まれ得る他の特徴は、窓上に提供されるセルラーアンテナまたは他のアンテナ、コントローラ内のセルラーリピータ、タッチパネル制御、取り付け可能／取り外し可能コントローラ、学習機能、天気追跡、窓間のセンサ出力および他の制御情報の共有、特定のコントローラ構成要素を含み得るサブフレーム、無線バスバー、内蔵フォトセンサ、ならびに他のセンサなどを含むが、これらに限定されない。これらの特徴のうちの任意の２つ以上を特定の用途に合わせて組み合わせることができる。

【0061】

新生エレクトロクロミック窓技術によって提示される課題は、ネットワークアドレスおよび／または他の識別情報の特定の窓およびそれらの電気コントローラ（窓コントローラ）への正確な割り当て、ならびに建物内の窓および／または窓コントローラの位置特定である。着色制御が機能する（すなわち、窓制御システムが１つまたはセットの特定の窓またはＩＧＵの着色状態を変更できるようにする）には、マスターコントローラ（および／または着色の決定を担当する他のコントローラ）が、その特定の窓または窓のセットに接続されている窓コントローラ（複数可）のネットワークアドレスを識別する必要がある。

【0062】

エレクトロクロミック窓技術によって提示される別の課題は、そのような窓を多く有する建物の特定の窓におけるエレクトロクロミックデバイスの着色状態の手動制御である。これに関連して、多数の窓を有する建物内の個々のエレクトロクロミック窓またはゾーンに関する情報へのアクセスがある。建物の管理者と占有者の両方が、建物内の一部または全てのエレクトロクロミック窓を少なくともある程度制御する必要がある。

【0063】

一部の実施形態では、ＩＧＵまたは他の窓アセンブリは、使用前に最小の物理的接続（例えば、ワイヤー）を必要とする単純な自己完結型のすぐに使えるユニットとして提供される。そのようなユニットは、従来の非エレクトロクロミックＩＧＵまたは窓アセンブリ（その中またはその上のどこかにコントローラを有する）のように見えることができ、従来のＩＧＵと実質的に同じ様式で設置することができる。これらの実施形態は、電力、通信回線などの経路指定に関連する著しい追加作業なしに、迅速な設置を望む住宅顧客にとって特に有益である。

【0064】

［エレクトロクロミックデバイス構造体］
図１は、基板１０２上に配置された従来のエレクトロクロミックデバイス１００を示す。デバイス１００は、基板から続く順に、第１の導電層１０４、第１のエレクトロクロミック層（ＥＣ１）１０６、イオン伝導体層（ＩＣ）１０８、第２のエレクトロクロミック層（ＥＣ２）１１０、および第２の導電層１１２を含む。構成要素１０４、１０６、１０８、１１０、および１１２は、まとめてエレクトロクロミックスタック１１４と呼ばれる。特定の実施形態では、透明導体層は、「ＴＣＯ」と呼ばれることがある透明導電性酸化物などの透明材料で作られる。ＴＣＯ層は透明であるため、ＥＣ１－ＩＣ－ＥＣ２スタックの着色挙動は、例えば、可逆的な陰影を付けるために窓上でそのようなデバイスを使用することを可能にする、ＴＣＯ層を通して観察可能である。エレクトロクロミックスタック１１４にわたって電位を印加するように動作可能な電圧源１１６は、例えば、透き通った状態（すなわち、透明）から着色状態へのエレクトロクロミックデバイスの遷移をもたらす。特定の実施形態では、エレクトロクロミックデバイスは、別個のイオン伝導体層を含まない。２０１４年７月１日に発行された米国特許第８，７６４，９５０号、および２０１５年５月１日に公開されたＰＣＴ公開第ＷＯ２０１５／１６８６２６号を参照のこと。これらの両方は参照によりそれらの全体が本明細書に組み込まれる。

【0065】

図１に示したもののような従来のデバイスおよび本開示の特定のデバイスでは、第１および第２のエレクトロクロミック層のうちの一方は典型的には陰極着色層であり、他方は陽極着色層である。そのような実施形態では、第１および第２のエレクトロクロミック層は、相反する極性にさらされると着色する。例えば、第１のエレクトロクロミック層は、印加されたカソード電位に基づいて着色し得る（そして印加されたアノード電位に基づいて透明になる）一方、第２のエレクトロクロミック層は、印加されたアノード電位に基づいて着色し得る（そして印加されるカソード電位で透明になる）。もちろん、いくつかの用途によってはその配置を逆にすることができる。いずれにせよ、第１および第２のエレクトロクロミック層は、着色および透明度に合わせて機能する。

【0066】

一部の実施形態では、第１および第２のエレクトロクロミック層のうちの一方を、非エレクトロクロミックイオン貯蔵層で置き換えることができる。そのような場合、２つの層のうちの１つのみがエレクトロクロミズムを示し、そのためそれは、適切な電位の印加下で着色し、および透明になる。対電極層と呼ばれることもある他の層は、他の層が陰極電位にさらされると、単にイオン貯蔵庫として働く。

【0067】

図１は一般的なエレクトロクロミックデバイス構造体を描いているが、構造体は限定的であることを意味しない。例えば、図１は異なる層を有するデバイススタックを示しているが、エレクトロクロミックスタックは傾斜構造体であってもよく、またはアンテナ構造体などの追加の構成要素を含んでもよい。本開示における議論の大部分は、エレクトロクロミックデバイスを有する窓に焦点を当てているが、本開示は、より一般的には、液晶デバイスおよび懸濁粒子デバイスなどの任意のタイプの光学的に切り替え可能なデバイスを有する窓に関する。

【0068】

［窓コントローラ］
本明細書に記載の窓コントローラは、それらが制御する光学的に切り替え可能な窓に関して、多くのサイズ、形式、および位置を有することができる。通常、コントローラはＩＧＵまたはラミネートのガラスに取り付けられるが、ＩＧＵまたはラミネートを収容するフレーム内にあってもよい。エレクトロクロミック窓は、１つ、２つ、３つまたはそれ以上の個々のエレクトロクロミック窓ガラス（透明基板上のエレクトロクロミックデバイス）を含み得る。また、エレクトロクロミック窓の個々の窓ガラスは、独立して着色可能なゾーンを有するエレクトロクロミックコーティングを有することができる。本明細書に記載のコントローラは、エレクトロクロミックコーティングがモノリシックであるかゾーンであるかにかかわらず、そのような窓に関連する全てのエレクトロクロミックコーティングを制御することができる。

【0069】

コントローラは、一般に、エレクトロクロミック窓にごく近接して、例えば、ガラス上またはＩＧＵ内に、自己完結型アセンブリのフレーム内で、一般に隣接して構成される。一部の実施形態では、窓コントローラは「原位置（ｉｎ ｓｉｔｕ）」コントローラである。すなわち、コントローラは、窓アセンブリ、ＩＧＵまたはラミネートの一部であり、エレクトロクロミック窓と一致させる、および現場で設置する必要はなくてもよく、例えば、コントローラは、工場からアセンブリの一部として窓とともに移動する。コントローラは、窓アセンブリの窓フレーム内に設置されてもよく、または、例えばＩＧＵの窓ガラスの上または間に、あるいはラミネートの窓ガラスに取り付けられたＩＧＵまたはラミネートアセンブリの一部であってもよい。コントローラがＩＧＵの可視部分に配置されている場合、コントローラの少なくとも一部分は、実質的に透明であり得る。ガラスコントローラのさらなる実施例は、２０１５年１１月１４日に出願された「ＳＥＬＦ ＣＯＮＴＡＩＮＥＤ ＥＣ ＩＧＵ」という名称の米国特許出願第１４／９５１，４１０号に提供されており、これはその全体が参照により本明細書に組み込まれる。一部の実施形態では、局所コントローラは、窓アセンブリの一部分として提供される少なくとも１つの部分（例えば、関連するエレクトロクロミック窓に関する情報を記憶するメモリ構成要素を含む）、および窓アセンブリ、ＩＧＵまたはラミネートの部分である少なくとも１つの部分と嵌め合うように別々に構成されている少なくとも１つの他の部分を有する、１つより多い部分として提供され得る。特定の実施形態では、コントローラは、単一のハウジング内にはなく、むしろ例えば、ＩＧＵの二次シール内に離間している、相互接続された部分のアセンブリであり得る。他の実施形態では、コントローラは、例えば単一のハウジング内、または例えば、ドックとハウジングアセンブリとを組み合わせた、および可視区域内ではなくガラスに近接した、または可視区域内のガラス上に取り付けられた２つ以上の構成要素内の小型ユニットである。

【0070】

一実施形態では、コントローラは、エレクトロクロミック窓の設置前に、ＩＧＵおよび／または窓フレームの中またはその上に組み込まれる。一実施形態では、コントローラは、製造施設を離れる前に、ＩＧＵおよび／または窓フレームの中またはその上に組み込まれる。一実施形態では、コントローラは、実質的に二次シール内でＩＧＵ中に組み込まれる。別の実施形態では、コントローラは、シーリングセパレータと基板との間の一次シールによって画定される周囲内に、部分的に、実質的に、または全体的にＩＧＵの中またはその上に組み込まれる。

【0071】

コントローラをＩＧＵおよび／または窓アセンブリの部分として有することで、ＩＧＵは、例えばＩＧＵまたは窓ユニットとともに移動するコントローラのロジックおよび特徴を有することができる。例えば、コントローラがＩＧＵアセンブリの部分である場合、エレクトロクロミックデバイス（複数可）の特性が経時的に（例えば、劣化によって）変化する事象において、特性評価関数が、例えば、着色状態遷移を駆動するために使用される制御パラメータを更新するために使用され得る。別の実施例では、エレクトロクロミック窓ユニットに既に設置されている場合、コントローラのロジックおよび特徴を使用して、所期の設置に一致するように制御パラメータを較正することができ、例えば、既に設置されている場合、制御パラメータは、エレクトロクロミック窓ガラス（複数可）の性能特性に適合するように再較正され得る。

【0072】

他の実施形態では、特定のコントローラは、窓と事前に関連付けられていないが、むしろ、例えば、任意のエレクトロクロミック窓に一般的な部品を有するドック構成要素が、工場で各窓と関連付けられる。窓の設置後、または他の分野では、コントローラの第２の構成要素がドック構成要素と組み合わされて、エレクトロクロミック窓コントローラアセンブリが完成する。ドック構成要素は、ドックが取り付けられる（例えば、設置後に建物の内部に面し、時には表面４または「Ｓ４」と呼ばれる表面上に）特定の窓の物理的特性およびパラメータで工場でプログラムされるチップを含み得る。第２の構成要素（時には「キャリア」、「ケーシング」、「ハウジング」、または「コントローラ」とも呼ばれる）はドックと嵌め合い、電力が供給されると、第２の構成要素は、チップを読み取り、チップに記憶されている特定の特性およびパラメータに従って、窓に電力を供給するようにそれ自体を構成することができる。このようにして、出荷された窓は、その窓の一部を形成するチップに記憶されたその関連パラメータを有するだけでよく、一方でより洗練された回路および構成要素は、後で組み合わせることができる（例えば、別々に出荷され、ガラス工が窓を取り付けた後に窓製造業者によって取り付けられ、続いて窓製造業者によるコミッショニングが行われる）。様々な実施形態を以下により詳細に説明する。一部の実施形態では、チップは、窓コントローラに取り付けられたワイヤーまたはワイヤーコネクタに含まれる。このようなコネクタ付きワイヤーは、時にはピグテールと呼ばれる。

【0073】

本出願では、「ＩＧＵ」は、２つ（またはそれ以上）の実質的に透明な基板、例えば、２枚の窓ガラスを含み、少なくとも１つの基板は、その上に配置されたエレクトロクロミックデバイスを含み、窓ガラスは、それらの間に配置されたセパレータを有する。ＩＧＵは通常密封封止され、周囲環境から隔離された内部領域を有する。「窓アセンブリ」は、ＩＧＵまたは例えば、独立型ラミネートを含み得、ＩＧＵまたはラミネートの１つ以上のエレクトロクロミックデバイスを、電圧源、スイッチなどに接続するための導線を含み、そしてＩＧＵまたはラミネートを支持するフレームを含み得る。窓アセンブリは、本明細書に記載の窓コントローラ、および／または窓コントローラの構成要素（例えば、ドック）を含み得る。

【0074】

本明細書で使用するとき、用語「アウトボード」は外部環境により近いことを意味し、一方、用語「インボード」は建物の内部により近いことを意味する。例えば、２つの窓ガラスを有するＩＧＵの場合、外部環境の近くに置かれる窓ガラスは、アウトボード窓ガラスまたは外側窓ガラスと呼ばれ、一方で建物の内部の近くに置かれる窓ガラスは、インボード窓ガラスまたは内側窓ガラスと呼ばれる。ＩＧＵの異なる表面は、Ｓ１、Ｓ２、Ｓ３、およびＳ４と呼ばれることがある（２枚の窓ガラスＩＧＵを想定する）。Ｓ１は、アウトボードライトの外側に面する表面（すなわち、外に立っている人が物理的に触れることができる表面）を指す。Ｓ２は、アウトボードライトの内側に面する表面を指す。Ｓ３は、インボードライトの外側に面する表面を指す。Ｓ４は、インボードライトの内側に面する表面（すなわち、建物の中に立っている人が物理的に触れることができる表面）を指す。言い換えれば、表面は、ＩＧＵの最も外側の表面から内側に向かって数えて、Ｓ１～Ｓ４というラベルが付けられる。ＩＧＵが３枚の窓ガラスを含む場合、これと同じ傾向が成り立つ（Ｓ６は建物の中に立っている人が物理的に触れることができる表面である）。２枚の窓ガラスを用いる特定の実施形態では、エレクトロクロミックデバイス（または他の光学的に切り替え可能なデバイス）はＳ３上に配置される。

【0075】

窓コントローラおよびそれらの機能のさらなる実施例は、２０１５年１０月２９日に出願された、「ＭＥＴＨＯＤ ＯＦ ＣＯＭＭＩＳＳＩＯＮＩＮＧ ＥＬＥＣＴＲＯＣＨＲＯＭＩＣ ＷＩＮＤＯＷＳ」という名称の米国仮特許出願第６２／２４８，１８１号、および２０１６年３月９日に出願された、「ＭＥＴＨＯＤ ＯＦ ＣＯＭＭＩＳＳＩＯＮＩＮＧ ＥＬＥＣＴＲＯＣＨＲＯＭＩＣ ＷＩＮＤＯＷＳ」という名称の米国仮特許出願第６２／３０５，８９２号に提示されており、それらの各々はその全体が参照により本明細書に組み込まれる。

【0076】

［窓コントローラネットワーク］
図２Ａは、複数のエレクトロクロミック窓２０２を制御し、駆動するためのシステム２００の一例の描写を示す。それは、窓アンテナなどのエレクトロクロミック窓に関連する１つ以上のデバイスの動作を制御するためにも使用され得る。システム２００は、商業用オフィスビルまたは住宅用建物などの建物２０４での使用に適合され得る。いくつかの実装形態では、システム２００は、現代の暖房、換気、および空調（ＨＶＡＣ：ｈｅａｔｉｎｇ ｖｅｎｔｉｌａｔｉｏｎ ａｎｄ ａｉｒ ｃｏｎｄｉｔｉｏｎｉｎｇ）システム２０６、室内照明システム２０７、セキュリティシステム２０８、および電力システム２０９とともに、建物２０４全体または建物２０４のキャンパスのための単一の総合的かつ効率的なエネルギー制御システムとして機能するように設計される。システム２００のいくつかの実装形態は、ビルマネジメントシステム（ＢＭＳ：Ｂｕｉｌｄｉｎｇ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）２１０との統合に特によく適している。ＢＭＳ２１０は、建物に設置されて、ＨＶＡＣシステム、照明システム、電力システム、エレベータ、火災システム、およびセキュリティシステムなどのその建物の機械設備および電気設備を監視し、制御することができるコンピュータベースの制御システムである。ＢＭＳ２１０は、占有者によって、または建物管理者もしくは他の担当者によって設定された嗜好に従って、建物２０４における状態を維持するためのハードウェア、および関連のファームウェアまたはソフトウェアを含むことができる。ソフトウェアは、例えば、インターネットプロトコルまたはオープンスタンダードに基づくものとすることができる。

【0077】

ＢＭＳは、通常、大きな建物において使用され得、そこでは、ＢＭＳは、その建物内の環境を制御する機能を果たす。例えば、ＢＭＳ２１０は、建物２０４内の照明、温度、二酸化炭素レベル、および湿度を制御することができる。例えば暖房炉または他のヒータ、エアコン、送風機、および通気孔を含む、ＢＭＳ２１０によって制御される多数の機械デバイスまたは電気デバイスが、存在することができる。建物環境を制御するために、ＢＭＳ２１０は、ルールに従って、または条件に応じて、これらの様々なデバイスをオン、オフにすることができる。このようなルールおよび条件は、例えば、建物管理者または担当者によって、選択または指定され得る。ＢＭＳ２１０の１つの主要な機能は、暖房および冷房のエネルギー損失およびエネルギーコストを最小限に抑えながら、建物２０４の占有者にとって快適な環境を維持することである。いくつかの実装形態では、ＢＭＳ２１０は、例えば、エネルギーを節約し、建物運用コストを削減するために、監視し、制御するだけではなく、様々なシステム間の相乗効果を最適化するように構成され得る。

【0078】

いくつかの実装形態は、代替的にまたは追加的に、例えば、熱センサ、光センサ、もしくは他のセンサを通して、あるいは、例えば、ＨＶＡＣシステムもしくは内部照明システムからの入力、またはユーザ制御からの入力を通して検知されたフィードバックに基づき、応答的にまたは反応的に機能するように設計される。さらなる情報は、その全体が参照により本明細書に組み込まれる２０１４年４月２２日に発行された米国特許第８，７０５，１６２号において見出され得る。実装形態によっては、伝統的なまたは従来のＨＶＡＣまたは内部照明システムを有する、商業用構造体および住宅用構造体両方を含む既存の構造体に利用されることも可能である。いくつかの実装形態では、古い住宅での使用に後付けされることも可能である。

【0079】

システム２００は、複数の窓コントローラ２１４を制御するように構成されたネットワークコントローラ２１２を含む。例えば、ネットワークコントローラ２１２は、数十、数百、または数千でも窓コントローラ２１４を制御することができる。その際、各窓コントローラ２１４が、１つ以上のエレクトロクロミック窓２０２を制御し、駆動することができる。実装形態によっては、ネットワークコントローラ２１２は、エレクトロクロミック窓の最終着色状態などの高レベルの命令を発行し、窓コントローラは、これらのコマンドを受信して、電気刺激を印加することによって、着色状態遷移を適宜駆動しかつ／または着色状態を維持するように、それらの窓を直接制御する。各窓コントローラ２１４が駆動することができるエレクトロクロミック窓２０２の枚数およびサイズは、各々のエレクトロクロミック窓２０２を制御する窓コントローラ２１４上の負荷の電圧特性および電流特性によってほぼ制限される。いくつかの実装形態では、各窓コントローラ２１４が駆動することができる最大窓サイズは、所望の時間フレーム内でエレクトロクロミック窓２０２における所望の光学遷移を引き起こすための電圧、電流、または電力の所要量によって制限される。このような所要量は、一方で、窓の表面積の関数である。いくつかの実装形態では、この関係は、非線形である。例えば、電圧、電流、または電力の所要量は、エレクトロクロミック窓２０２の表面積と非線形に上昇することがある。例えば、一部の場合に、第１の導電層２１４および第２の導電層２１６（例えば、図２Ａ参照）のシート抵抗が、第１または第２の導電層の長さおよび幅にわたる距離に従って非線形に上昇することから、この関係は、少なくとも部分的に、非線形である。しかしながら、実装形態によっては、等しいサイズおよび形状の複数のエレクトロクロミック窓２０２を駆動するのに必要とされる電圧、電流、または電力の所要量間の関係は、駆動されるエレクトロクロミック窓２０２の枚数に正比例する。

【0080】

図２Ｂは、複数のエレクトロクロミック窓２０２を制御し、駆動するためのシステム２００の別の実施例を示す。図２Ｂに示されるシステム２００は、図２Ａに示されたシステム２００と同様である。図２Ａのシステムとは対照的に、図２Ｂに示されるシステム２００は、マスターコントローラ２１１を含む。マスターコントローラ２１１は、複数のネットワークコントローラ２１２と通信し、それと連携して機能し、これらのネットワークコントローラ２１２の各々は、図２Ａを参照して説明された複数の窓コントローラ２１４をアドレス指定することができる。いくつかの実装形態では、マスターコントローラ２１１は、高レベルの命令（エレクトロクロミック窓の最終着色状態など）をネットワークコントローラ２１２に発行し、次に、ネットワークコントローラ２１２が、この命令を対応する窓コントローラ２１４に伝達する。

【0081】

いくつかの実装形態では、建物または他の構造体の様々なエレクトロクロミック窓２０２および／またはアンテナが、各々がエレクトロクロミック窓２０２の部分集合を含む、ゾーンまたはゾーン群に群分けされるのが有利である。例えば、各ゾーンは、それらの場所に基づき、同じまたは同様の光学的状態に着色される（または他には遷移される）必要がある建物の具体的な場所または区域におけるエレクトロクロミック窓２０２のセットに対応し得る。より具体的な例として、北面、南面、東面、および西面といった４つの面または側を有する建物を考えてみる。また、建物が１０階建てであることも考えてみる。このような教説的な例では、各ゾーンは、特定の階に、また４つの面のうちの特定の１つにあるエレクトロクロミック窓２０２のセットに対応することができる。いくつかのそのような実装形態では、各ネットワークコントローラ２１２は、１つ以上のゾーンまたはゾーン群をアドレス指定することができる。例えば、マスターコントローラ２１１は、特定のゾーンまたはゾーン群に対する最終着色状態コマンドを、ネットワークコントローラ２１２のうちのそれぞれ１つ以上に発行することができる。例えば、最終着色状態コマンドは、目標ゾーンの各々の抽象的な識別情報を含むことができる。次に、最終着色状態コマンドを受信する指定のネットワークコントローラ２１２が、ゾーン（複数可）の抽象的な識別情報を、ゾーン（複数可）におけるエレクトロクロミック窓２０２に印加される電圧または電流のプロファイルを制御する、それぞれの窓コントローラ２１４の固有のネットワークアドレスにマッピングすることができる。

【0082】

エレクトロクロミック窓の少なくともいくつかがアンテナを有する実施形態では、着色目的のための窓のゾーンは、アンテナ関連機能のためのゾーンに対応してもしなくてもよい。例えば、マスターおよび／またはネットワークコントローラが、着色目的用の窓の２つの別個のゾーン、例えば建物の片側の窓の２つの階を特定し得、この場合、各階は、顧客の嗜好に基づいて異なる着色アルゴリズムを有する。いくつかの実装形態では、ゾーニングは３層以上の階層で実装される。例えば、建物の少なくともいくつかの窓はゾーンにグループ化され、少なくともいくつかのゾーンはサブゾーンに分割され、各サブゾーンは異なる制御ロジックおよび／またはユーザアクセスを受ける。

【0083】

多くの実例では、光学的に切り替え可能な窓は、建物のエンベロープのかなりの部分を形成または占めることができる。例えば、光学的に切り替え可能な窓は、会社のオフィスビル、他の商業用ビル、または住宅用建物の壁、ファサード、また屋根でさえものかなりの部分を形成することができる。様々な実装形態において、光学的に切り替え可能な窓を制御するために、コントローラの分散型ネットワークが使用されることが可能である。図２Ｃは、いくつかの実装形態による、複数のＩＧＵ２２２を制御するように動作可能なネットワークシステム２２０の一例のブロック図を示す。ネットワークシステム２２０の１つの主要な機能は、ＩＧＵ２２２内のエレクトロクロミックデバイス（または他の光学的に切り替え可能なデバイス）の光学状態を制御することである。いくつかの実装形態では、窓２２２のうちの１つ以上は、例えば、各窓が２つ以上の独立して制御可能なエレクトロクロミックデバイスまたはゾーンを含む、マルチゾーン化窓とすることができる。様々な実装形態において、ネットワークシステム２２０は、ＩＧＵ２２２に提供される電力信号の電気特性を制御するように動作可能である。例えば、ネットワークシステム２２０は、ＩＧＵ２２２内のエレクトロクロミックデバイスに印加される電圧を制御するための着色命令（本明細書では「着色コマンド」とも呼ばれる）を生成させ、伝達することができる。

【0084】

いくつかの実装形態では、ネットワークシステム２２０の別の機能には、ＩＧＵ２２２から状態情報（以下、「情報」は、「データ」と同じ意味で使用される）を取得することがある。例えば、所与のＩＧＵの状態情報には、ＩＧＵ内のエレクトロクロミックデバイス（複数可）の識別情報、またはエレクトロクロミックデバイス（複数可）の目下の着色状態についての情報を含めることができる。ネットワークシステム２２０はまた、ＩＧＵ２２２上またはＩＧＵ２２２内に統合されるか、建物内、建物上、またはその周りの様々な他の場所に位置するかを問わず、温度センサ、フォトセンサ（本明細書では光センサとも呼ばれる）、湿度センサ、空気流量センサ、または占有センサなどの様々なセンサ、およびアンテナからデータを取得するようにも動作可能であり得る。

【0085】

ネットワークシステム２２０は、様々な能力または機能を有する任意の適切な個数の分散型コントローラを含むことができる。いくつかの実装形態では、様々なコントローラの機能および配置が、階層的に規定される。例えば、ネットワークシステム２２０は、複数の分散型窓コントローラ（ＷＣ：Ｗｉｎｄｏｗ Ｃｏｎｔｒｏｌｌｅｒ）２２４、複数のネットワークコントローラ（ＮＣ：Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）２２６、およびマスターコントローラ（ＭＣ：Ｍａｓｔｅｒ Ｃｏｎｔｒｏｌｌｅｒ）２２８を含む。いくつかの実装形態では、ＭＣ２２８は、数十または数百のＮＣ２２６と通信し、それらを制御することができる。様々な実装形態において、ＭＣ２２８は、１つ以上の有線リンクまたは無線リンク２４６（以下、総称して「リンク２４６」と呼ばれる）上で、ＮＣ２２６に高レベルの命令を発行する。命令には、例えば、それぞれのＮＣ２２６によって制御されるＩＧＵ２２２の光学的状態における遷移を引き起こすための着色コマンドを含めることができる。今度は、各ＮＣ２２６が、１つ以上の有線リンクまたは無線リンク２４４（以下、総称して「リンク２４４」と呼ばれる）上で、いくつかのＷＣ２２４と通信し、それらを制御することができる。例えば、各ＮＣ２２６は、数十または数百のＷＣ２２４を制御することができる。今度は、各ＷＣ２２４が、１つ以上の有線リンクまたは無線リンク２４２（以下、総称して「リンク２４２」と呼ばれる）上で、１つ以上のそれぞれのＩＧＵ２２２と通信するか、それを駆動するか、それとも制御することができる。

【0086】

ＭＣ２２８は、着色コマンド、状態要求コマンド、データ（例えば、センサデータ）要求コマンド、または他の命令を含む通信を発行することができる。いくつかの実装形態では、ＭＣ２２８は、ある所定の時刻に（曜日または年によって変わることがある）、あるいは特定の事象、状態、または事象もしくは状態の組み合わせの検出に基づいて（例えば、取得されたセンサデータによって、あるいはユーザによって、またはアプリケーションもしくはこのようなセンサデータとこのような要求との組み合わせによって開始された要求の受信に基づいて、判定されるに従って）、このような通信を周期的に発行することができる。いくつかの実装形態では、ＭＣ２２８が、１つ以上のＩＧＵ２２２からなるセットにおける着色状態変化を引き起こすことを判定すると、ＭＣ２２８は、所望の着色状態に対応する着色値を生成させるか、または選択する。いくつかの実装形態では、ＩＧＵ２２２のセットは、第１のプロトコル識別子（ＩＤ：ＩＤｅｎｔｉｆｉｅｒ）（例えば、ＢＡＣｎｅｔ ＩＤ）と関連付けられる。次に、ＭＣ２２８は、着色値および第１のプロトコルＩＤを含む、本明細書では「一次着色コマンド」と呼ばれる通信を生成させ、第１の通信プロトコル（例えば、ＢＡＣｎｅｔ互換プロトコル）を介してリンク２４６上で伝送する。いくつかの実装形態では、ＭＣ２２８は、特定の１つ以上のＷＣ２２４を制御する特定のＮＣ２２６に一次着色コマンドをアドレス指定し、今後は、その１つ以上のＷＣ２２４が、ＩＧＵ２２２のセットを遷移するように制御する。ＮＣ２２６は、着色値および第１のプロトコルＩＤを含む一次着色コマンドを受信し、この第１のプロトコルＩＤを１つ以上の第２のプロトコルＩＤにマッピングする。いくつかの実装形態では、第２のプロトコルＩＤの各々が、ＷＣ２２４のうちの対応する１つを識別する。ＮＣ２２６は、続いて、着色値を含む二次着色コマンドを、第２の通信プロトコルを介してリンク２４４上で、識別されたＷＣ２２４の各々に伝送する。いくつかの実装形態では、次に、二次着色コマンドを受信されたＷＣ２２４の各々が、着色値に基づいて内部メモリから電圧プロファイルまたは電流プロファイルを選択して、そのそれぞれに接続されたＩＧＵ２２２を着色値と一致する着色状態に駆動する。次に、ＷＣ２２４の各々が、電圧信号または電流信号を生成させ、それを、そのそれぞれに接続されたＩＧＵ２２２にリンク２４２上で提供し、電圧プロファイルまたは電流プロファイルを印加する。

【0087】

コントローラの機能および／または配置がどのように階層的に配置され得るかと同様に、エレクトロクロミック窓は、図３に示されるように階層構造で配置され得る。階層構造は、ルールまたはユーザ制御をエレクトロクロミック窓またはＩＧＵの様々な群分けに適用することを可能にすることによって、特定のサイトでのエレクトロクロミック窓の制御を容易にするのを助ける。さらに、審美性のために、部屋または他のサイト位置にある複数の連続した窓は、それらの光学的状態を一致させるおよび／または同じ割合で着色する必要がある場合がある。ゾーンとして連続する窓の群を扱うことにより、これらの目的を促進することができる。

【0088】

上記で示唆したように、様々なＩＧＵ２２２をエレクトロクロミック窓のゾーン３０３に群分けすることができ、その各ゾーン３０３は、少なくとも１つの窓コントローラ２２４およびそのそれぞれのＩＧＵ２２２を含む。いくつかの実装形態では、各ＩＧＵ２２２ゾーンは、１つ以上のそれぞれのＮＣ２２６と、これらのＮＣ２２６によって制御される１つ以上のそれぞれのＷＣ２２４とによって制御される。いくつかのより具体的な実装形態において、各ゾーン３０３は、単一のＮＣ２２６と、この単一のＮＣ２２６によって制御される２つ以上のＷＣ２２４とによって制御され得る。別の言い方をすれば、ゾーン３０３は、ＩＧＵ２２２の論理上の群分けを表すことができる。例えば、各ゾーン３０３は、それらの位置に基づいて一緒に駆動される、建物の具体的な位置または区域におけるＩＧＵ２２２のセットに対応し得る。より具体的な例として、北面、南面、東面、および西面といった４つの面または側を有する建物であるサイト３０１を考えてみる。また、建物が１０階建てであることも考えてみる。このような教説的な例では、各ゾーンは、特定の階に、また４つの面のうちの特定の１つにあるエレクトロクロミック窓２００のセットに対応することができる。追加的にまたは代替的に、各ゾーン３０３は、１つ以上の物理的特性（例えば、サイズまたは年数などのデバイスパラメータ）を共有する、ＩＧＵ２２２のセットに対応し得る。いくつかの他の実装形態では、ＩＧＵ２２２のゾーン３０３は、例えば、セキュリティ指定または業務階層（例えば、管理者のオフィスと境を接するＩＧＵ２２２は、１つ以上のゾーンに群分けされ得る一方、非管理者のオフィスと境を接するＩＧＵ２２２は、１つ以上の異なるゾーンに群分けされ得る）などの１つ以上の非物理的特性に基づき群分けされ得る。

【0089】

いくつかのこのような実装形態では、各ＮＣ２２６は、ＩＧＵ２２２の全てを１つ以上のそれぞれのゾーン３０３の各々にアドレス指定することができる。例えば、ＭＣ２２８は、一次着色コマンドを、目標ゾーン３０３を制御するＮＣ２２６に発行することができる。一次着色コマンドには、目標ゾーンの抽象的な識別情報（以下、「ゾーンＩＤ」とも呼ばれる）を含めることができる。いくつかのこのような実装形態では、ゾーンＩＤは、ちょうど上の例で説明されたものなどの第１のプロトコルＩＤとすることができる。このような場合、ＮＣ２２６は、着色値およびゾーンＩＤを含む一次着色コマンドを受信し、そのゾーンＩＤを、ゾーン内のＷＣ２２４に関連付けられた第２のプロトコルＩＤにマッピングする。いくつかの他の実装形態では、ゾーンＩＤは、第１のプロトコルＩＤよりも高いレベルの抽象化とすることができる。このような場合、ＮＣ２２６は、最初に、ゾーンＩＤを１つ以上の第１のプロトコルＩＤにマッピングし、続いて、その第１のプロトコルＩＤを第２のプロトコルＩＤにマッピングすることができる。

【0090】

任意のデバイスの制御に関する命令（例えば、窓コントローラまたはＩＧＵのための命令）がネットワークシステム２２０を通過するとき、それらは、それらが送られるデバイスの固有のネットワークＩＤを伴う。ネットワークＩＤは、指示が所期のデバイスに確実に届き、実行されるようにするために必要である。例えば、１つより多いＩＧＵの着色状態を制御する窓コントローラは、着色コマンドとともに渡されるＣＡＮ ＩＤ（ネットワークＩＤの形式）などのネットワークＩＤに基づいて、制御するＩＧＵを判定する。本明細書に記載されているような窓ネットワークでは、ネットワークＩＤという用語は、ＣＡＮ ＩＤ、およびＢＡＣｎｅｔ ＩＤを含むが、これらに限定されない。そのようなネットワークＩＤは、窓コントローラ２２４、ネットワークコントローラ２２６、およびマスターコントローラ２３８などの窓ネットワークノードに適用することができる。本明細書で説明するとき、しばしば、デバイスのネットワークＩＤは、それを制御する全てのデバイスのネットワークＩＤを階層構造で含む。例えば、ＩＧＵのネットワークＩＤは、そのＣＡＮ ＩＤに加えて、窓コントローラＩＤ、ネットワークコントローラＩＤ、およびマスターコントローラＩＤを含むことができる。

【0091】

［光学的に切り替え可能な窓のコミッショニングネットワーク］
着色制御が機能する（例えば、窓制御システムが１つまたはセットの特定の窓またはＩＧＵの着色状態を変更できるようにする）には、マスターコントローラ、ネットワークコントローラ、および／または着色の決定を担当する他のコントローラが、その特定の窓または窓のセットに接続されている窓コントローラ（複数可）のネットワークアドレスを識別する必要がある。この目的のために、コミッショニングの機能は、窓コントローラアドレスおよび／または他の識別情報の特定の窓および窓コントローラへの正確な割り当て、ならびに建物内の窓および／または窓コントローラの物理的位置を提供することである。一部の場合には、コミッショニングの目的は、誤った位置に窓を設置する、または誤った窓コントローラにケーブルを接続する際の間違いやその他の問題を修正することである。一部の場合に、コミッショニングの目的は、半自動または完全自動のインストールを提供することである。言い換えれば、設置者のための位置案内がほとんどまたはまったくない状態で、設置を許可することである。

【0092】

一般に、特定の窓またはＩＧＵのためのコミッショニングプロセスは、その窓または他の窓の関連構成要素のためのＩＤを、その対応する窓コントローラと関連付けることを含み得る。プロセスはまた、建物の位置および／または絶対的な位置（例えば、緯度、経度および高度）を窓または他の構成要素に割り当てることができる。エレクトロクロミック窓のネットワークのコミッショニングおよび／または構成に関するさらなる情報は、２０１４年１０月７日に出願された、「ＡＰＰＬＩＣＡＴＩＯＮＳ ＦＯＲ ＣＯＮＴＲＯＬＬＩＮＧ ＯＰＴＩＣＡＬＬＹ ＳＷＩＴＣＨＡＢＬＥ ＤＥＶＩＣＥＳ」という名称の米国特許出願第１４／３９１，１２２号、２０１５年１１月２４日に出願された、「ＳＥＬＦ－ＣＯＮＴＡＩＮＥＤ ＥＣ ＩＧＵ」という名称の米国特許出願第１４／９５１，４１０号、２０１６年３月９日に出願された、「ＭＥＴＨＯＤ ＯＦ ＣＯＭＭＩＳＳＩＯＮＩＮＧ ＥＬＥＣＴＲＯＣＨＲＯＭＩＣ ＷＩＮＤＯＷＳ」という名称の米国仮特許出願第６２／３０５，８９２号、および２０１６年８月２日に出願された、「ＭＥＴＨＯＤ ＯＦ ＣＯＭＭＩＳＳＩＯＮＩＮＧ ＥＬＥＣＴＲＯＣＨＲＯＭＩＣ ＷＩＮＤＯＷＳ」という名称の米国仮特許出願第６２／３７０，１７４号に提示されており、それらの各々はその全体が参照により本明細書に組み込まれる。

【0093】

光学的に切り替え可能な窓のネットワークが物理的に設置された後、ネットワークは、間違った窓（しばしばＩＧＵとして）または建物の場所への窓コントローラの誤った割り当てを修正するようにコミッションされ得る。一部の実施形態では、コミッショニングは、個々の窓およびそれらの位置を、関連する窓コントローラとマッピング（またはペアまたはリンク）する。

【0094】

時には、コミッショニングは、設置中の窓コントローラとそれに関連する光学的に切り替え可能な窓の誤ペアリングに対処することを目的とする。例えば、設置前に、各窓コントローラは、建物内の特定の位置に割り当てられ得る、特定の窓に割り当てられてもよい。しかし、設置中に、窓コントローラおよび／または窓は、誤った位置に設置されることがある。例えば、窓コントローラが間違った窓とペアになっている可能性があり、または窓が間違った位置に設置されている可能性がある。これらの誤ペアリングは、対処が困難な場合がある。さらに、建設プロセス中、建物内の物理的な窓の設置と配線の設置は、通常、異なるチームによって異なる時間に行われる。この課題を認識して、いくつかの実装形態では、窓とコントローラは互いに事前に割り当てられておらず、むしろコミッショニングプロセス中にペアにされる。例えば、窓コントローラが対応する窓に物理的に固定されているために、誤ペアリングが問題にならない場合でも、設置者は、どの窓（したがって、どの窓コントローラ）がどの位置に設置されるのかを知らず、気にしないかもしれない。例えば、多くの窓は、大きさ、形状、および光学的性質が同一であり得、したがって交換可能であり得る。理想的には、設置者は、そのような各窓に関連付けられた固有の窓コントローラを考慮せずに、そのような窓を任意の都合の良い位置に単に設置するだけでよい。本明細書に記載の様々なコミッショニング実施形態は、そのような柔軟な設置を可能にする。

【0095】

設置中に発生する可能性がある問題の具体的な例を以下にいくつか示す。

【0096】

窓を正しい位置に配置する際の誤り：電気的に制御可能な窓は、特に電気的に制御可能な窓を扱うことに慣れていない技術者によって、誤って設置されやすい。これらの人々は通常、ガラス工や低電圧電気工（ＬＶＥ）などの職人である。

【0097】

窓コントローラへのケーブルの誤接続：これは、特に近接した複数の窓で問題になる。上述したように、電気的に制御可能な窓は、特に電気的に制御可能な窓で作業することに慣れていない技術者によって、誤って設置されやすい。

【0098】

壊れた窓または窓コントローラ：設置者は、壊れた窓やコントローラの代わりに利用可能な窓やコントローラを単にインストールすることができる。新しい窓またはコントローラは、計画に含まれていないため、コミッショニング中に考慮されていないか、または認識されていない。

【0099】

正しい位置に多くの窓を設置するプロセスは複雑である。多くの固有の窓を固有の位置に設置する責任を設置者に持たせるというパラダイムを置き換えることが望ましい。上述したように、電気的に制御可能な窓は、特に電気的に制御可能な窓で作業することに慣れていない技術者によって、誤って設置されやすい。したがって、設置プロセスを複雑にする窓およびコントローラの位置に関する考慮事項の大部分または全部を排除することが有用である。

【0100】

一例では、改良されたコミッショニング方法を必要とする設置および付随する問題は、以下の手順から生じる。
ａ．窓コントローラが製造されるとき、固有のネットワークアドレス（例えば、ＣＡＮＩＤ）が各窓コントローラに割り当てられる。
ｂ．窓製造業者（必ずしも窓コントローラの製造業者ではない）、建物の設計者、またはその他のエンティティは、窓コントローラ（指定されたネットワークアドレスを持つ）および窓（ＩＧＵ）に関する情報を特定する。これは、窓コントローラのネットワークアドレスではない窓コントローラＩＤ（ＷＣＩＤ）を割り当てることによって行われる。窓製造業者および／または他のエンティティはまた、どのＩＧＵ（複数可）が窓コントローラ（ＷＣＩＤ）に関連付けられているかを特定する。この目的のために、エンティティは、窓の窓ＩＤ（ＷＩＤ）を特定する。特定の場合には、製造業者および／または他のエンティティは、ＩＧＵとコントローラとの間の相関関係、すなわちコントローラがどの特定のＩＧＵ（複数可）に接続される必要があるかを特定しない。例えば、窓製造業者は、ＷＣ（ＣＡＮＩＤ（例えば、１９１９６９９７）を有する）が任意の特定のＷＩＤ（例えば、０４３４９｀０５２４｀００７１｀００１７｀００）に接続する必要があることを特定する必要はない。その代わりに、製造業者または他のエンティティは、ＷＣ（ＣＡＮＩＤ（例えば、１９１９６９９７）を有する）が、例えばＷＣ１０の窓コントローラＩＤを有することを特定する。窓コントローラＩＤは、相互接続図面、建築図面、または建物の他の表現上のロケーションタグ（例えば、設置における窓に割り当てられた任意の番号）として反映されてもよく（例えば、現れてもよく）、また窓コントローラが窓ＩＤ（例えば、Ｗ３１およびＷ３２（ＩＧのロケーションタグ））によって識別される特定のＩＧＵに接続することを特定してもよい。
ｃ．示されるように、製造業者または他のエンティティは、各窓コントローラに窓コントローラＩＤ（ＷＣｘｘラベル）を適用する。エンティティはまた、マスターコントローラ／ネットワークコントローラ、または個々の着色の決定を発行する役割を果たすロジックを含む他のデバイスによって使用される設定ファイルに、ＷＣｘｘ／ＣＡＮ ＩＤペア情報を入力する。
ｄ．このプロセスは、ＬＶＥまたは他の技術者が電気的に制御可能な窓の設置および／または接続を担当して、窓コントローラのボックスから特定の窓コントローラを選択し、それを建物内の特定の位置に設置することを必要とする。
ｅ．操作（ｃ）または（ｄ）に誤りがあると、誤マッピングを見つけてそれを訂正するための現場でのトラブルシューティングが困難になる。
ｆ．操作（ｃ）と（ｄ）が正しく実行されても、窓コントローラおよび／または窓が損傷する可能性があり、その場合は、設置中に交換する必要がある。変更が手動で追跡され、構成ファイルに反映されない限り、これも問題を引き起こす可能性がある。

【0101】

示されるように、様々な実施形態において、コミッショニングプロセスは、個々の窓を、窓の光学状態を制御することを担当する個々の窓コントローラとペアにする。いくつかの実装形態では、コミッショニングプロセスは、窓および／または窓コントローラ位置を、窓上または窓に近接して配置されているコントローラの窓コントローラＩＤおよび／または窓コントローラネットワーク識別子（例えば、ＣＡＮＩＤ）とペアにする。説明したように、そのようなコントローラは、通常、それらが配置されている、または近接している窓の光学状態を制御するように構成される。場合によっては、コミッショニングプロセスは、階層型ネットワーク内のコントローラのタイプ、および随意的にそのネットワークのトポロジー内のコントローラの論理位置を特定する。個々の光学的に切り替え可能な各窓は、物理的ＩＤ（例えば、上述の窓またはライトＩＤ（ＷＩＤ））、および固有のネットワークＩＤ（例えば、上述のＣＡＮＩＤ）を伴う関連コントローラを有する。一部の場合に、窓コントローラはまた、物理的ＩＤ（例えば、上述のＷＣＩＤ）を含む。一般に、コミッショニングプロセスを使用して、ＩＧＵ（またはＩＧＵ内のライト）、窓コントローラ、ネットワークコントローラ、マスターコントローラ、およびセンサを含むがこれらに限定されない、任意の２つの関連ネットワーク構成要素をリンクまたはペアにすることができる。一部の場合に、コミッショニングプロセスは、ＩＧＵまたはコントローラに関連付けられたネットワーク識別子を、３次元建物モデル上の表面および／または特徴にペアリングすることを含み得る。

【0102】

以下に説明する特定の実施形態では、コミッショニングリンケージは、第１の構成要素のアーキテクチャ的に判定された位置と、第２の構成要素の無線測定位置とを比較することによって行われ、その第２の構成要素は、第１の構成要素と関連付けられる。例えば、第１の構成要素は、光学的に切り替え可能な窓であり得、第２の構成要素は、光学的に切り替え可能な構成要素の光学状態を制御するように構成された窓コントローラであり得る。別の実施例では、第１の構成要素は、測定された放射線データを第２の構成要素である窓コントローラに提供するセンサである。多くの場合、第１の構成要素の位置は、第２の構成要素の位置よりも高い精度で知られており、その位置は無線測定によって判定され得る。第１の構成要素の正確な位置は、建築図面または同様のソースから判定され得るが、コミッショニングプロセスは、手動で測定された窓または他の構成要素の設置後の位置などの代替のソースを使用し得る。ＧＰＳもまた使用され得る。様々な実施形態では、その位置が無線測定によって判定される構成要素（例えば、窓コントローラ）は、窓ネットワークＩＤを有し、そのネットワークＩＤは、例えば構成ファイルを介して、コミッショニングプロセス中に利用可能にされる。そのような場合、コミッショニングプロセスは、第１の構成要素の正確な物理的位置を第２の構成要素のネットワークＩＤとペアにし得る。一部の実施形態では、第１および第２の構成要素は、単一の構成要素である。例えば、窓コントローラはそのような構成要素であり、例えば、その位置は、建築図面および無線測定の両方から判定され得る。そのような場合、コミッショニングプロセスは、構成ファイルからのネットワークＩＤを用いて、建築図面からの物理的位置を簡単に帰属させることができる。

【0103】

コミッショニング中に判定されたリンケージは、様々な窓ネットワーク構成要素、および／またはモバイルアプリケーション、窓制御インテリジェンスアルゴリズム、ビル管理システム（ＢＭＳ）、セキュリティシステム、照明システムなどの関連システムによって参照され得る、ファイル、データ構造、データベースなどに格納される。特定の実施形態では、コミッショニングリンケージはネットワーク構成ファイルに格納される。一部の場合に、ネットワーク構成ファイルが、窓ネットワークによって使用され、ネットワーク上の構成要素間で適切なコマンドが送信され、例えば、マスターコントローラは、構造内のその位置によって、着色変更のために指定された窓について、着色コマンドを窓コントローラに送信する。

【0104】

図４Ａは、ネットワーク上の様々な機能を容易にするために、ネットワーク構成ファイル４０３が制御ロジック４０４によって使用され得る実施形態を示す。以下の説明では「ネットワーク構成ファイル」という用語を使用しているが、任意の適切なファイル、データ構造、データベースなどを、同じ目的のために使用できることを理解されたい。そのようなファイルまたは他の機能は、窓ネットワークの物理的構成要素（例えば、ライトＩＤによって識別されるライト位置）と、そのような物理的構成要素に関連するコントローラ（例えば、ライトの状態を直接制御する窓コントローラ）のネットワークＩＤ（ネットワークアドレスであり得る、またはそれを含み得る）との間のリンケージを提供する。制御ロジックとは、物理的構成要素と関連するコントローラとの間のリンケージを決定または他の目的で行うために使用され得る、いくつかのロジックを指す。示唆されるように、そのようなロジックは、窓ネットワークマスターコントローラ、ネットワークコントローラ、および窓コントローラ、ならびに窓状態を制御するためのモバイルアプリケーション、窓制御インテリジェンスアルゴリズム、ビル管理システム、セキュリティシステム、照明システムなどの関連またはインターフェースシステムで提供されるロジックを含み得る。一部の場合に、ネットワーク構成ファイル４０３は、遠隔無線デバイス上のアプリケーションなどのネットワーク４０８を制御するためのユーザインターフェース、またはインテリジェンスシステム４０９もしくはＢＭＳに、ネットワーク情報を提供するために制御ロジック４０４によって使用される。一部の場合に、モバイルアプリケーションのユーザインターフェース４０８は、ネットワーク構成ファイルによって提供される情報を使用して、マスターコントローラ、ネットワークコントローラ、窓コントローラ、または他のネットワーク構成要素を制御するように構成される。

【0105】

ネットワーク構成ファイルを作成するプロセスの一例を図４Ｂに示す。第１の動作は、窓ネットワークのレイアウトを判定することができるように、建築図面４０１のような建築計画からサイトの物理的レイアウトを判定することである。典型的には、建築図面４０１は、建築物の寸法、電気クローゼットの位置、ならびに他の様々な構造上および建築上の特徴を提供する。建築図面が入手できない場合などの一部の場合に、最初にサイトを調査して、建築図面を作成することができる。建築図面を使用して、個人またはチームは、エレクトロクロミック窓ネットワーク用の配線インフラストラクチャと電力送達システムを設計する。配電部品を含むこのインフラストラクチャは、相互接続図面４０２とも呼ばれることがある修正された建築図面で視覚的に描かれている。相互接続図は、サイトでのワイヤールーティング（例えば、幹線）、ネットワーク上の様々なデバイス（例えば、コントローラ、電源、コントロールパネル、窓、センサ）の配置、およびネットワーク構成要素の識別情報（例えば、ネットワークＩＤ）を示す。一部の場合に、設置されている光学的に切り替え可能な窓のライトＩＤ（ＷＩＤまたはその他のＩＤ）がデバイスの設置位置と一致するまで、相互接続図は完成しない。本質的にまたは明示的に、相互接続図はまた、特定のサイトにおける窓、窓コントローラ、ネットワークコントローラ、およびマスターコントローラを含む、階層型通信ネットワークを示すことができる。しかしながら、典型的には、最初にレンダリングされた相互接続図は、光学的に切り替え可能な窓ネットワーク上のライトまたは他の構成要素に対するネットワークＩＤを含まない。

【0106】

相互接続図が作成された後、それは、相互接続図のテキスト表現であり得る、ネットワーク構成ファイル４０３を作成するために使用される。次いで、ネットワーク構成ファイルは、窓ネットワークをその意図された様式で制御することを可能にする、制御ロジックおよび／または他のインターフェースシステムによって読み取り可能な媒体で提供され得る。相互接続図およびネットワーク構成ファイルが、設置されたネットワークを正確に反映する限り４０４、準備的なネットワーク構成ファイルを作成するプロセスは完了する。しかしながら、コミッショニングは他の情報をファイルに追加して、設置された光学的に切り替え可能な窓を、対応する窓コントローラネットワークＩＤに一致させてリンクさせることができる。相互接続図およびネットワーク構成ファイルが設置されたネットワークと一致しないと任意の時点で判定された場合４０４、相互接続図面４０２を正確なライトＩＤ（または他のＩＤ）情報４１１で更新するために、手動のユーザ介入が必要となり得る。次に、更新された相互接続図から、ネットワーク構成ファイル４０３が、行われた変更を反映するように更新される。

【0107】

図５Ａは、建物の建築図面／間取りから作成された、相互接続図の一例を提供する。相互接続図は、ＩＧＵおよび窓コントローラ５０１、コントロールパネル５０２、幹線５０３、壁インターフェース５０５、ならびにマスターコントローラ、ネットワークコントローラ、およびセンサなどの他の様々なネットワーク構成要素の配置を含む。図示されていないが、相互接続図は、構造情報、構造寸法、および図示されている様々なネットワーク構成要素のネットワークＩＤなどの情報などの追加の情報を含むことがある。

【0108】

場合によっては、相互接続図は、構造体の多くの図を示す図面のパッケージである。一部の場合に、相互接続図パッケージは、類似しているが異なる情報を提供する図面を含むことがある。例えば、２つの図面が同じ間取りを示す場合があるが、１つの図面は、寸法情報を提供し、一方でもう１つの別の図面は、ネットワーク上の構成要素のネットワークＩＤを提供する。図５Ｂは、構造体の立面図を示す相互接続図の別の例を提供し、それからＩＧＵ５０１および他のネットワーク構成要素の座標を判定することができる。一部の場合に、相互接続図は、その全体が参照により本明細書に組み込まれる、２０１６年９月１６日に出願された米国特許出願第１５／２６８，２０４号に記載されているようなエレクトロクロミックデバイス用の配電ネットワークに関する情報を提供する。

【0109】

特定の状況では、相互接続図の変更が必要になる場合がある。例えば、設置者は、窓開口部が相互接続図によって定められた窓に対して小さすぎると判定することができ、したがって、より小さい窓を設置することを決めることができる。変更を修正するには、相互接続図を更新する必要があり得る。いずれにしても、ネットワーク構成ファイル、または光学的に切り替え可能な窓と関連するコントローラとの間のマッピングを格納する他の構造体は、現在の設置を反映するために作成または修正される必要がある。正しいマッピングが設定されていれば、ネットワークは適切に機能する。一部の場合に、ネットワーク構成ファイルが物理的ネットワークを表していないと、その際、窓の着色指示が誤った構成要素に送信される場合があり、または通信がまったく受信されない場合がある。

【0110】

相互接続図が修正されるとき、対応するネットワーク構成ファイル４０３も修正される必要がある。一部の場合に、相互接続図のいくつかの変更がネットワーク構成ファイルに確実に反映されるように、物理的な設置が完了するまで、ネットワーク構成ファイルは作成されない。ネットワークファイルの作成後に相互接続ファイルが変更された場合は、ネットワーク構成ファイルも確実に更新されて変更が反映されるようにする必要がある。相互接続図の更新に失敗した場合、または相互接続図に加えられた変更を反映するためのネットワーク構成ファイルの更新に失敗した場合、窓ネットワークが意図したとおりの命令に応答しないことをもたらす。さらに、相互接続ファイルは、コミッショニングが行われるときに更新され得る。相互接続図から逸脱する設置中に行われた変更を修正するために、窓のライトＩＤ４１１を含むファイルから、光学的に切り替え可能な窓情報を取得することができる。

【0111】

相互接続図が作成されたとき、または設置の変更を考慮して図が更新されたときに、ネットワーク構成ファイルは、作成または更新される。コミッショニングが行われると、構成ファイルがさらに更新される場合がある。相互接続図と同様に、最初にレンダリングされたときのネットワーク構成ファイルには、窓コントローラ、または光学的に切り替え可能な窓ネットワーク上の他の構成要素のネットワークＩＤは含まれていない。

【0112】

特定の実施形態では、ネットワーク構成ファイルは、制御ロジックソフトウェアによって、読み取り、解釈し、一部の場合に更新することができる、コンピュータ可読形式の相互接続図の写しである。全てのネットワーク構成要素（例えば、窓、窓コントローラ、ネットワークコントローラ、およびセンサ）は、ネットワーク上の様々なデバイスが階層構造で互いにどのように関連しているかに関する情報を含む、ネットワーク構成ファイルによって表される。

【0113】

通常、ネットワーク構成ファイルは相互接続図の説明文である。ネットワーク構成ファイルは、索引付けのための構造も記録間の構造的関係もないフラットファイル形式を持っていてもよい。フラットファイルタイプの例には、プレーンテキストファイル、コンマ区切り値ファイル、および区切り文字値ファイルが含まれる。通常、ＪａｖａＳｃｒｉｐｔ（登録商標）のオブジェクト表記形式（ＪＳＯＮ）、または人間が読めるテキストを使用して、属性と値のペアで構成されるデータオブジェクトを送信するその他のオブジェクト表記形式が、ネットワーク構成ファイルに使用される。もちろん、前述のように、ネットワーク構成ファイル内の情報は、他の形式および場所に格納され得る。

【0114】

一実施形態では、ネットワーク構成ファイルはＪＳＯＮ形式をとる。この実施形態では、様々なデバイスおよびデバイスのグループ化が、ＪＳＯＮオブジェクトとして定義されることになる。例えば、窓のゾーンをオブジェクトとして定義するときは、そのゾーンが属する何らかのゾーン群、そのゾーン群が報告する何らかのネットワークコントローラ（複数可）、およびネットワークを担当するマスターコントローラをエンコードするために、コンマ区切りのテキストが使用されることになる。オブジェクトはさらに、どの窓コントローラ、窓、および任意の追加のネットワーク構成要素（例えば、フォトセンサまたは窓アンテナ）がゾーンに含まれているかを提供する。通常、ネットワーク構成要素は、オブジェクト内で少なくともネットワークＩＤによって参照される。説明したように、最初に相互接続図から生成されたとき、ネットワーク構成ファイルは、窓コントローラのネットワークＩＤをまだ含んでいないという意味で不完全である。

【0115】

ネットワーク構成ファイルは、窓ネットワーク内の様々な場所に格納され得る。例えば、ネットワーク構成ファイルは、マスターコントローラ、ネットワークコントローラ、遠隔無線デバイスに接続されたメモリに、またはクラウドに格納されてもよい。一部の実施形態では、ネットワーク構成ファイルは、１つの場所に格納され、そこからネットワーク上の他の全てのデバイスがそれにアクセスすることができる。別の実施形態では、ネットワーク構成ファイルは窓コントローラネットワーク上の複数のデバイスにローカルに格納され、新しいデバイスがネットワークに追加されたときなど、ネットワーク構成ファイルが１つの場所で更新されたときは、更新されたネットワーク構成ファイルを使用して、別の場所にある古いネットワークファイルを更新する。

【0116】

ネットワーク構成ファイルからの情報を使用して、制御ロジックは、窓およびネットワーク上の他の構成要素に命令を送ることができる。制御ロジックは命令をマスターコントローラ４０５に渡し、マスターコントローラ４０５は次に、命令を適切なネットワークコントローラ４０６に送信する。主要な実施形態では、ネットワークコントローラは、例えば、ＢＡＣｎｅｔ通信プロトコル（ビル自動化および制御ネットワークプロトコル、ＩＳＯ１６４８４－５）を介して、適切な窓コントローラ４０７に命令を送信する。その後、窓コントローラは、電気信号を適用して、窓コントローラのＣＡＮ ＩＤに基づいて、光学的に切り替わる窓の着色状態を制御する。

【0117】

制御ロジックは、窓ネットワーク上の様々な場所に格納され、および／またはそこで使用され得る。例えば、一実施形態では、制御ロジックは、マスターコントローラ上に格納して使用することができる。他の実施形態では、制御ロジックを含むソフトウェアは、クラウド上で、またはマスターコントローラに命令を送信する遠隔デバイス上で実行され得る。一部の場合に、電子デバイスから操作される施設管理アプリケーションを介して、制御ロジックを少なくとも部分的に実装することができる。

【0118】

制御ロジックの１つの目的は、ユーザが窓ネットワーク上の１つ以上のエレクトロクロミック窓および他のデバイスを制御することを可能にするグラフィカルユーザインターフェース４０８の形態で、ユーザに制御可能なオプションを提示することである。例えば、ユーザは、ネットワーク上のライトＩＤのリストを提示され、それからユーザは特定の窓の着色状態を選択し修正することができる。あるいは、ユーザは、ユーザによって事前に判定された、または選択された窓のゾーンに基づいて、窓のグループ化を制御するための命令を送信することができる。

【0119】

一部の実施形態では、制御ロジックはさらに、窓制御インテリジェンス４０９、ＢＭＳ、セキュリティシステムなどと通信することができる。例えば、停電の場合に冷却コストを節約するために、ＢＭＳは全ての窓をそれらの着色状態に構成し得る。

【0120】

［自動的な位置判定］
本開示の一態様は、設置後の自動化した窓位置判定を可能にする。窓コントローラ、ならびに場合によっては、アンテナおよび／またはオンボードコントローラで構成された窓は、例えば、時間的に変化する電場、磁場、または電磁場などの様々な形態の無線電磁伝送を介して通信するために、送信機で構成されてもよい。電磁通信に使用される一般的な無線プロトコルには、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＢＬＥ、Ｗｉ－Ｆｉ（登録商標）、ＲＦ、および超広帯域（ＵＷＢ）が含まれるが、これらに限定されるものではない。２つ以上のデバイス間の相対位置は、無線で送信された信号の受信強度または電力、到達時間または位相、周波数、および到着角度などの１つ以上のアンテナで受信された伝送に関する情報から判定され得る。これらの測定基準からデバイスの位置を判断する際、場合によっては、建物の物理的なレイアウト、例えば壁および家具を考慮する三角形分割アルゴリズムが実施され得る。最終的に、そのような技術を使用して、個々の窓ネットワーク構成要素の正確な位置を得ることができる。例えば、ＵＷＢマイクロロケーションチップを有する窓コントローラの位置は、その実際の位置の１０センチメートル以内に容易に判定することができる。場合によっては、１つ以上の窓の位置は、その全体が参照により本明細書に組み込まれる、２０１７年５月４日に出願された、「ＷＩＮＤＯＷ ＡＮＴＥＮＮＡＳ」という名称のＰＣＴ特許出願第ＵＳ１７／３１１０６号に記載されているものなどの地理的位置決め方法を使用して判定され得る。本明細書で使用されるとき、地理的位置決めおよび測位は、窓またはデバイスの位置または相対位置が電磁信号の分析によって部分的に判定される任意の方法を指すことができる。

【0121】

パルスベースの超広帯域（ＵＷＢ）技術（ＥＣＭＡ－３６８およびＥＣＭＡ－３６９）は、短距離（最長２３０フィート）にわたって低電力（通常０．５ｍＷ未満）で、大量のデータを伝送する無線技術である。ＵＷＢ信号の特性は、それが、帯域幅スペクトルの少なくとも５００ＭＨｚ、またはその中心周波数の少なくとも２０％を占めることである。ＵＷＢプロトコルによれば、構成要素は、同時にいくつかの周波数チャネルにわたって、キャリア信号上で極めて正確にタイミングが取られたデジタル信号パルスをブロードキャストする。情報は、パルスのタイミングまたは位置決めを変調することによって伝送され得る。代替的に、情報は、パルスの極性、その振幅をエンコードすることによって、かつ／または直交パルスを使用することによって、伝送され得る。低電力情報伝送プロトコルであることとは別に、ＵＷＢ技術は、他の無線プロトコルに比べて屋内位置アプリケーションにいくつかの利点を提供し得る。広範囲のＵＷＢスペクトルは、ＵＷＢ信号が壁を含む様々な物質に浸透することを可能にする長い波長を有する低周波数を含む。これらの低浸透周波数を含む広範囲の周波数は、いくつかの波長が、通常、見通し内軌道を有するようになるので、マルチパス伝搬エラーの機会を少なくする。パルスベースのＵＷＢ通信の別の利点には、パルスが、通常、極めて短く（５００ＭＨｚ幅パルスでは、６０ｃｍ未満、１．３ＧＨｚ帯域幅パルスでは、２３ｃｍ未満）、反射パルスが元のパルスと重なるようになる機会を少なくすることである。

【0122】

マイクロロケーションチップを有する窓コントローラの相対位置は、ＵＷＢプロトコルを使用して判定され得る。例えば、マイクロロケーションチップを使用して、各デバイスの相対位置は、１０ｃｍの精度内に判定され得る。様々な実施形態では、窓コントローラ、および一部の場合に、窓または窓コントローラ上またはその近くに配置されたアンテナは、マイクロロケーションチップを介して通信するように構成される。一部の実施形態では、窓コントローラは、全方向信号をブロードキャストするように構成されたマイクロロケーションチップを有する、タグを装備することができる。アンカーとしても知られる受信マイクロロケーションチップは、無線ルータ、ネットワークコントローラ、または既知の位置を有する窓コントローラなどの様々な位置に配置され得る。ブロードキャスト信号がタグの送信可能距離内でアンカーに到達するのにかかる時間を分析することによって、タグの位置を判定することができる。一部の場合に、設置者がコミッショニングの目的で建物内に一時的なアンカーを設置し、コミッショニングプロセスが完了した後にそれらを除去してもよい。複数の光学的に切り替え可能な窓がある一部の実施形態では、窓コントローラは、ＵＷＢ信号を送信および受信するように構成されたマイクロロケーションチップを装備され得る。各窓コントローラで受信されたＵＷＢ信号を分析することによって、送信範囲限界内に位置する窓コントローラ間の互いの相対距離が判定され得る。この情報を集約することによって、全ての窓コントローラ間の相対位置が判定され得る。少なくとも１つの窓コントローラの位置が分かっているとき、またはアンカーも使用されているとき、各窓コントローラまたはマイクロロケーションチップを有する他のネットワークデバイスの実際の位置を判定することができる。そのようなアンテナは、以下に説明されるように自動コミッショニング手順において使用されてもよい。しかしながら、本開示はＵＷＢ技術に限定されず、高解像度の位置情報を自動的に報告するための任意の技術が使用され得ることを理解されたい。多くの場合、そのような技術は、自動的に配置されるべき構成要素に関連する１つ以上のアンテナを使用するであろう。

【0123】

説明したように、相互接続図または他の建築情報のソースは、多くの場合、様々な窓ネットワーク構成要素の位置情報を含む。例えば、窓は、時には非常に高い精度で、例えば、１センチメートル以内にｘ、ｙ、ｚ次元で列挙されたそれらの物理的な位置座標を有し得る。同様に、ネットワーク構成ファイルなどの、そのような図面から導出されたファイルまたはドキュメントは、関連する窓ネットワーク構成要素の正確な物理的位置を含み得る。特定の実施形態では、座標は、構造体に設置されたときのライトまたはＩＧＵの一角に対応する。相互接続図において座標を特定するための特定の角または他の特徴の選択は、アンテナまたは他の位置認識構成要素の配置によって影響され得る。例えば、窓および／またはペアの窓コントローラは、関連するＩＧＵの第１の角（例えば、左下角）の近くに配置されたマイクロロケーションチップを有することができる。その場合、ライトの相互接続図座標は、最初の角に指定され得る。同様に、ＩＧＵが窓アンテナを有する場合には、相互接続図上に列挙された座標は、ＩＧＵライトの表面上のアンテナの位置またはアンテナに近接する角を表すことができる。一部の場合に、座標は、建築図面およびＩＧＵなどのより大きな窓構成要素上のアンテナ配置の知識から得ることができる。一部の場合に、窓の配向も相互接続図に含まれる。

【0124】

本明細書は、窓の正確な物理的位置情報のソースとして相互接続図をしばしば参照するが、本開示は相互接続図に限定されない。光学的に切り替え可能な窓を有する建物または他の構造体における、構成要素位置の任意の同様の正確な表現が使用され得る。これには、相互接続図から導出されたファイル（例えば、ネットワーク構成ファイル）、ならびに相互接続図とは無関係に、例えば、建物の建設中に行われた手動または自動測定によって産生されたファイルまたは図面が含まれる。建築図面から座標を判定することができない一部の場合に、例えば壁上の窓コントローラの垂直位置では、設置および／またはコミッショニングを担当する担当者によって未知の座標が判定される場合がある。建築図および相互接続図は、建築設計および建築において広く使用されているので、ここでは便宜上使用されているが、やはり本開示は、物理的位置情報のソースとして相互接続図に限定されない。

【0125】

相互接続図、または構成要素位置および地理的位置決めの同様の詳細な表現を使用する特定の実施形態では、相互接続図によって指定されているように、コミッショニングロジックは、構成要素位置を、光学的に切り替え可能な窓の窓コントローラなどの構成要素のネットワークＩＤ（または相互接続図で利用できない他の情報）とペアにする。一部の実施形態では、これは、地理的位置決めによって提供されたデバイス位置と相互接続図に提供された列挙された座標との間の測定された相対距離を比較することによって行われる。ネットワーク構成要素の位置は、例えば、約１０ｃｍよりもよい高精度で判定され得るので、自動コミッショニングは、手動コミッショニング窓によってもたらされ得る複雑さを回避するような手法で容易に実行され得る。

【0126】

窓（または他の構成要素）の物理的な場所とペアになっているコントローラネットワークＩＤまたは他の情報は、様々なソースから取得できる。特定の実施形態では、窓コントローラのネットワークＩＤは、各窓に取り付けられたメモリデバイス（例えば、窓コントローラ用のドックまたはピグテール）に格納されるか、または窓のシリアル番号に基づいて、クラウドからダウンロードされ得る。コントローラのネットワークＩＤの一実施例は、ＣＡＮ ＩＤ（ＣＡＮバスを介した通信に使用される識別子）である。コントローラのネットワークＩＤに加えて、他の格納された窓情報には、コントローラのＩＤ（そのネットワークＩＤではなく）、窓のライトＩＤ（例えば、ライトのシリアル番号）、窓のタイプ、窓の寸法、製造日、バスバーの長さ、ゾーンメンバーシップ、現在のファームウェア、およびその他の様々な窓の詳細が含まれ得る。どの情報が格納されているかに関わらず、それはコミッショニングプロセス中にアクセスされてもよい。アクセスされると、そのような情報の一部または全部は、相互接続図、部分的に完成したネットワーク構成ファイル、または他のソースから取得された物理的位置情報にリンクされる。

【0127】

図６は、設置された光学的に切り替え可能な窓をコミッショニングするための例示的なプロセスフローを提示する。示されるように、コミッショニングプロセス６０１はプロセス動作６０３で開始し、コミッショニングシステムは、相互接続図またはそれから派生した構成ファイルなどの建築ソースから光学的に切り替え可能な窓の各々の位置を受信する。これらの窓は、特定の建物、または建物の一階または建物のファサードなどの建物の一部分に存在する、全ての切り替え可能な窓を含み得る。特定の実施形態において、窓の位置を受信することに加えて、コミッショニングシステムはまた、窓に関連するＩＤ、例えば、建築的なソースまたは別のソースに含まれ得るライトＩＤまたはシリアル番号を受信する。上述のように、建築的なソースまたは同様のソースから得られる位置情報は、窓の非常に正確な３次元位置を含む。特定の実施形態では、動作６０３で受信された位置は、約１０センチメートル、または約５センチメートル、または約１センチメートルの範囲内で正確である。

【0128】

動作６０３はコミッショニングに必要な非常に正確な窓位置情報を提供するが、動作６０５および６０７は、窓コントローラおよび／またはそれが制御する窓（複数可）を一意に識別するために必要な情報を提供する。プロセス動作６０５に示されるように、コミッショニングシステムは、建物全体またはその部分の窓コントローラに、窓コントローラの位置を判定するための無線プロセスを実行するように指示する。説明したように、そのような動作は、窓コントローラまたはコミッショニングに使用される他の窓ネットワーク構成要素について適度に高精度の位置情報を提供する、ＵＷＢプロトコル通信または他の無線プロセスを使用することができる。説明したように、ＵＷＢ処理は、多くの場合、ＵＷＢプロトコルを実施するように構成されたマイクロロケーションチップを含むネットワーク構成要素の約１０センチメートル以内に、位置情報を提供することができる。原則として、ネットワークコントローラまたは他の構成要素を、光学的に切り替え可能な窓について得られた高精度の位置情報と関連付けるために必要な位置情報を提供するために、任意の適切に正確な無線または非無線プロトコルさえも使用できる。特定の実施形態では、窓コントローラの位置を特定するいくつかのそのような手順は、少なくとも約２０センチメートル、または少なくとも約１５センチメートル、または少なくとも約１０センチメートルの精度でネットワークコントローラの位置情報を提供する。

【0129】

プロセス動作６０７では、プロセス動作６０５で取得された窓コントローラの位置情報が、窓コントローラに関する固有の情報と関連付けられる。そのような情報は、窓コントローラ、および一部の実施形態では、そのようなコントローラに関連付けられた窓（複数可）を一意に記述する。このような固有情報の例には、窓コントローラのネットワークＩＤ、窓コントローラの物理的（非ネットワーク）ＩＤ、窓コントローラの設定パラメータ、窓コントローラによって制御されるべき全ての窓のシリアル番号、および窓コントローラによって制御されるべき窓を記述するその他の様々なパラメータが含まれる。コミッショニングシステムは、動作６０５の無線測定手順を通じて取得された窓コントローラの大まかに位置付けられた位置を含むファイルまたは他の情報の集合、および窓コントローラに関する一意の識別情報を産生する。この情報により、コミッショニングシステムは、実際のコミッショニングプロセスを実行するために必要な全てを有する。

【0130】

示される実施形態では、コミッショニングプロセスは、設置における窓の各々、または設置の部分にわたってループし、各窓を連続してコミッションする。もちろん、一部の実施形態では、様々な窓の分析またはコミッショニングは並行して行われてもよい。図６に示す実施形態では、個々の窓は、コミッショニングのための現在の窓がプロセス動作６０９で選択されている状態で連続的に考察される。コミッショニングのために現在の窓が選択された状態で、コミッショニングシステムは、プロセス動作６０３で建築的なソースから判定されるように、現在の窓の位置に最も近い、動作６０５において無線で判定される位置を有する窓コントローラを識別する。プロセス動作６１１を参照。ほとんどの窓の相対サイズと窓コントローラの無線で測定された位置の精度を考えると、特定の窓をそれらに関連付けられた窓コントローラに関連付けることにはほとんど曖昧さがない。窓の位置と窓コントローラとの間の距離を判定するための様々な技術が使用され得る。いくつかを以下に説明する。技術は、窓を個別にまたはまとめて検討することができる。

【0131】

動作６１１においてコミッショニングシステムが最も近い窓コントローラを判定した後、システムは、建築的なソースから判定されるように、識別された窓コントローラ（および／またはその窓（複数可））に関するネットワークＩＤおよび／または他の固有情報を、現在の窓およびその位置に関連付ける。プロセス動作６１３を参照。

【0132】

この時点で、現在の窓は効果的にコミッションされているので、コミッショニングシステムは、コミッションされるべき切り替え可能な窓が他にあるかどうかを判定する。決定動作６１５を参照。このような窓がさらに存在する場合、プロセス制御はプロセス動作６０９に戻り、そこでコミッショニングシステムは、コミッショニングのために次の切り替え可能な窓を選択する。一方では、コミッションされるべき窓がもうない場合、プロセス制御は、窓とコントローラのペアリングを終了し、そうでなければコミッショニングプロセスを完了する、プロセス動作６１７に向けられる。

【0133】

図７は、コミッショニングロジック７０１（コミッショニングシステムの部分）およびネットワーク構成ファイル４０３を含むプロセス７００を示す。プロセス４００と同様に、プロセス７００は、建築図面４０１から建物情報を集めることから開始する。建築図面によって提供された建物情報を使用して、設計者または設計チームは、特定のサイトにおける窓ネットワークの計画を含む、相互接続図面４０２を作成する。ＩＧＵおよび窓コントローラなどのネットワーク構成要素が設置されると、デバイス間の相対位置は、本明細書の他の箇所で説明されているように電磁伝送の分析によって測定され得る。次に、測定された位置およびネットワークＩＤ情報７０２は、相互接続図面４０２に示すように、デバイスのネットワークＩＤ（または他の固有の情報）を階層型ネットワーク内のその場所とペアにする、コミッショニングロジック７０１に渡される。相互接続図から取得または導出された関連付けられた窓または他のデバイスの位置もまた、ネットワークＩＤまたは他の固有の情報とペアにされる。その後、ペアになった情報は、ネットワーク構成ファイル４０３に格納される。ネットワークまたは窓のインストールに変更が加えられていない限り、ネットワーク構成ファイルに変更の必要はない。しかし、変更が行われた場合、例えば、ＩＧＵが異なる窓コントローラを有するものと交換された場合、コミッショニングロジック７０１を一度使用して、変更を判定し、それに従ってネットワーク構成ファイル４０３を更新する。

【0134】

例として、建物の壁に沿って以下の３つの位置（各々関連する窓の左下角に関連付けられた位置）：第１の窓コントローラを（０ｆｔ、０ｆｔ、０ｆｔ）に置くことを意図した第１の位置、第２の窓コントローラを（５ｆｔ、０ｆｔ、０ｆｔ）に置くことを意図した第２の位置、および第３の窓コントローラを（５ｆｔ、４ｆｔ、０ｆｔ）に置くことを意図した第３の位置に配置された窓コントローラを有する相互接続図を考慮する。３つのコントローラの座標を測定するときは、コントローラのうちの１つを基準位置として設定する（例えば、コミッショニングを担当するコントローラ担当者が、基準点として第１の位置にコントローラを設定する）。この基準点から、他の２つの窓の座標が測定され、結果として（５．１ｆｔ、.２ｆｔ、.１ｆｔ）および（５．０ｆｔ、３．９ｆｔ、－.１ｆｔ）の窓座標が得られる。コミッショニングロジックは、次に、座標（５．１ｆｔ、.２ｆｔ、.１ｆｔ）を有する窓が第２の位置にあること、および座標（５．０ｆｔ、３．９ｆｔ、ー.１ｆｔ）を有する窓が第３の位置にあることを容易に認識する。次に、相互接続図から各構成要素の物理的および階層的位置を記述する情報は、ネットワーク構成要素の位置が判定されたときに、ネットワークを介してコミッショニングロジックに送信され得る、ネットワークＩＤ情報（または他の固有の情報）とペアにされる。

【0135】

コミッショニングロジックは、物理的デバイス座標を相互接続図に列挙されている座標とマッチさせるために、多様な統計的方法を組み込んでもよい。一実施形態では、マッチングは、デバイスを可能な相互接続位置の各々に割り当てる様々な順列を反復し、次いで相対距離測定を使用して判定された他の構成要素の位置が、相互接続図で指定されている他のネットワーク構成要素の位置にどれだけ厳密に対応しているかを観察することによって実行される。場合によっては、相互接続図によって指定された最も近い構成要素の位置までの各構成要素の距離の二乗平均誤差を最小にする置換を選択することによって、相互接続図に列挙された座標とネットワーク構成要素をマッチさせる。

【0136】

この自動コミッショニング方法は、例えば、新しい構成要素がネットワークに追加された場合、古い構成要素がネットワークから削除された場合、またはネットワーク上で交換された場合にも有用であり得る。新しい構成要素の場合に、その構成要素は、窓ネットワークによって認識されてもよく、その位置は前述の方法のうちの１つによって判定されてもよい。その後、コミッショニングロジックは、その追加を反映するようにネットワーク構成ファイルを更新し得る。同様に、コミッショニングロジックは、構成要素が削除され、窓ネットワークによって認識されなくなったときに、ネットワーク構成ファイルを更新し得る。構成要素が交換された場合、コミッショニングロジックは、ネットワーク上に構成要素が存在しないこと、および欠けている構成要素の同じ座標から報告される新しい構成要素が存在することに気付く場合がある。コミッショニングロジックは、構成要素が交換されたと結論付けることができ、したがって、新しい構成要素のネットワークＩＤでネットワーク構成ファイルを更新する。

【0137】

一部の実施形態では、コミッショニングロジックはまた、図８に示されるように、プロセス８００によってネットワーク構成ファイルのネットワークトポロジ部分を生成し得る。この実施形態では、窓デバイスがサイトに設置され８０１、ネットワーク構成要素が、互いに通信することによって、ネットワークの階層構造を自己判定する８０２。ネットワークの階層構造は、各構成要素が、そのネットワークＩＤ（または他のＩＤ）情報、ならびに階層内のその下の任意のデバイスのネットワークＩＤ（または他のＩＤ）情報を報告しているその上のネットワーク構成要素に自己報告するときに判定され得る。例えば、ＩＧＵは、ＷＣに報告することができ、ＷＣはＮＣに報告することができ、ＮＣはＭＣに報告することができる。このパターンがネットワーク上の全ての構成要素に対して繰り返されると、システム階層は自己判定され得る。この場合、ネットワークは、設置中に発生する相互接続図からの逸脱によって容易に発生する可能性がある、ネットワークトポロジエラーを回避する。次に、この自己判定構造は、ネットワーク構成ファイル４０３を作成するときにデバイスの測定位置７０２を使用することができる、コミッショニングロジック７０１に渡される。

【0138】

図６に示すステップまたは本明細書に記載の他のコミッショニング手順を実行するための命令およびロジックは、十分なメモリおよび処理能力を有する窓ネットワーク上の任意のコントローラを含む任意の適切な処理装置に展開することができる。実施例としては、マスターコントローラ、ネットワークコントローラ、さらには窓コントローラが含まれる。他の実施形態では、コミッショニングシステムは、コミッショニングまたは関連する管理機能のみを実行するが、関連する窓ネットワークと通信する、専用の管理処理マシン上で実行される。一部の実施形態では、コミッショニングシステムは、コミッションされるべき窓を有する建物の外側に存在する。例えば、コミッショニングシステムは、切り替え可能な窓ネットワーク遠隔監視サイト、コンソール、またはビル照明システム、ＢＭＳ、ビルサーモスタットシステム（例えば、ＮＥＳＴ（カリフォルニア州パロアルトのネストラボ））等などの任意の補助システムに存在し得る。そのようなシステムの例は、２０１５年１２月８日に出願された、ＰＣＴ特許出願公開第２０１６／０９４４４５号、および２０１５年３月５日に出願された、ＰＣＴ特許出願公開第２０１５／１３４７８９号に記載されており、各々は参照によりその全体が本明細書に組み込まれる。特定の実施形態では、コミッショニングシステムは、リースされたサーバファームまたはクラウドなどの共有計算リソース内で実行される。

【0139】

［切り替え可能な窓に関する情報を制御およびアクセスするためのグラフィカルユーザインターフェース］
本開示の別の態様は、ユーザが窓ネットワークに接続された遠隔デバイスから１つ以上の光学的に切り替え可能な窓を制御することを可能にする、グラフィカルユーザインターフェース（ＧＵＩ）に関する。窓のユーザ制御を容易にするためにＧＵＩを使用したアプリケーションの実施例には、Ｖｉｅｗ Ｉｎｃ．から入手可能なＤｙｎａｍｉｃ Ｇｌａｓｓ（商標）が含まれ、これは、ｉＯＳ（登録商標）およびアンドロイドモバイルデバイスプラットフォームで利用可能である。光学的に切り替え可能な窓を制御するためのモバイルアプリケーションの他の実施例は、参照によりその全体が本明細書に組み込まれる、Ｄｈａｒｉａ Ｓｈｒｉｖａｓｔａｖａにより２０１３年４月１２日に出願された、「Ａｐｐｌｉｃａｔｉｏｎｓ ｆｏｒ Ｃｏｎｔｒｏｌｌｉｎｇ Ｏｐｔｉｃａｌｌｙ Ｓｗｉｔｃｈａｂｌｅ Ｗｉｎｄｏｗｓ」という名称のＰＣＴ特許出願公開第２０１３／１５５，４６７号に記載されている。

【0140】

ユーザが遠隔デバイスからエレクトロクロミック窓の光学状態を制御することを可能にするアプリケーションが存在するが、それらはしばしば、限られたユーザ経験しか提供しない。図９は、モバイルデバイスアプリケーション用の従来のユーザインターフェースの一例を示す。このような１つのアプリケーションは、ユーザがゾーン群のリスト（この場合は「群」とラベル付けされている）９０１、またはユーザがどの窓に着色コマンドを送信するかを選択できるゾーンを提示されていることを自身が発見したときに初めて、ナビゲートするのがユーザにとって面倒となる可能性がある。特定のサイトのゾーン群または特定のゾーンの名前を記憶していないユーザにとって、これはナビゲートするのが面倒なインターフェースとなる可能性がある。例えば、部屋が互いに隣接する５つの窓１００１～１００５を有する、部屋１０００の内部を示す図１０を例にとる。図１０では、部屋は様式化された眼１００６の視点から見られている。例えば、１００１＝「ＷＣ１」、１００２＝「ＷＣ２」などのように連続的に番号が付けられる論理的な命名システムが窓に与えられていても、番号付けがどの順序で始まるのかユーザにはすぐにはわからない可能性がある。例えば、観察者から見て、番号付けは左から右へ、または右から左へと進むことができる。さらに、番号付けは、最も左側の窓１００１から始まる、最も右側の窓１００５から始まる、または内部窓１００２～１００４のうちの１つから始まることができる。この問題は、ゾーンや時にはサブゾーンにグループ化されていることが多い、何百もの光学的に切り替わる窓を含むことがある、大きなオフィスビルなどの大規模なサイトを検討するときに、かなりより複雑になる。

【0141】

窓コントローラ名の連続的なリストを提示するリストタイプのインターフェースが時には実行可能であるが、より直感的なインターフェースは、窓が実際に現れる配置および／または配向でグラフィカルに描かれているものの１つである。さらに、窓のグラフィック描写は、スマートオブジェクトであり得る。スケーリングされた画像としてグラフィカルに示されるスマートオブジェクトとして窓がユーザに提示されると、ユーザ体験が大幅に向上することが分かった。

【0142】

本明細書に記載の「スマートオブジェクト」は、スマートオブジェクトが表す１つ以上の物理的デバイスに関する情報を収集および／または提示するために、ユーザによって（例えば、タッチセンシティブディスプレイとの接触によって）操作され得る１つ以上の材料アイテムの表現である。スマートオブジェクトによって表され得るアイテムの例としては、窓、窓のゾーン、窓が設置されている建物、窓に接触または隣接している構造体、ならびにコントローラ、センサ、およびワイヤーなどの窓ネットワーク構成要素を含む。一部の実施形態では、スマートオブジェクトは、そのオブジェクトによって表されるネットワーク構成要素（複数可）を制御するためのユーザインターフェースも提供する。一部の実施形態では、スマートオブジェクトとのユーザ相互作用は、窓着色の変化または窓の着色のためのスケジュールもしくはアルゴリズムの変化をトリガする。本明細書に記載のスマートオブジェクトを用いたユーザ操作は、ＧＵＩアプリケーションを実行しているデバイスによって検出および／または測定され得る、任意のユーザアクションを指すことができる。例えば、スマートオブジェクトは、触覚的な相互作用（例えば、接触または力）、音、運動（例えば、直線または角加速度）、またはサイト内のユーザの位置によって操作され得る。一実施形態では、窓のスマートオブジェクトは、ユーザに見えるようにグラフィカルに描かれる。言い換えれば、オブジェクトは、実際の窓のそれらが表す特徴（例えば、窓の形状および配置（部屋、建物、または他の窓に対する））を模倣し得る。スマートオブジェクトは、データストア（例えばデータベース）内のデータまたはそのようなデータに対するクエリと関連付けられてもよい。例えば、スマートオブジェクトとのユーザの相互作用は、データストアからのデータの検索またはデータストアへのデータの格納をトリガし得る。

【0143】

図１１は、図１０に示されるような部屋１０００内の５つの隣接する窓１００１～１００５の制御のためにユーザに提示される、スマートオブジェクトを表示するＧＵＩを示す。この実施例では、窓１００１～１００５は、ＧＵＩにおいて、関連する窓を表すためにユーザによって容易に理解され得るスマートオブジェクト１１０１～１１０５によって表される。スマートオブジェクトをより認識しやすくするために、壁や天井などの部屋１０００の追加の特徴も、ＧＵＩによって示される部屋１１００のＧＵＩの表現で描くことができる。一部の場合に、部屋のワイヤーフレームモデルに従って、追加の特徴が描かれてもよい。ＧＵＩを実行しているモバイルデバイスがコンパスを有する場合などのいくつかの実装形態では、配向機能１１０６はモバイルデバイスの配向と連動して回転し、一部の場合に、スマートオブジェクト自体がＧＵＩ上で移動および変換され、そのためユーザは、ユーザによって知覚されるのと同様の配向のビューを提示される。図１１に示すものなどのＧＵＩの実施形態を使用して、ユーザは、単にそれに触れること、それにカーソルを移動すること、それをクリックすること、または何らかの他の方法でスマートオブジェクトを選択し得ることによって、窓を選択し得る。一部の場合に、窓１００４を表すスマートオブジェクト１１０４などのスマートオブジェクトは、例えばタッチまたは力によって、ユーザによって選択されたことを示すために、外観が変化してもよい（例えば、陰影が付けられる、ハイライト表示される、拡大されるなど）。一部の場合に、スマートオブジェクトを選択すると、ＧＵＩがそのスマートオブジェクトが表すネットワーク構成要素に関する情報を表示したり、ユーザに制御可能なオプションを表示したりすることがもたらされる。表示され得る情報の例には、構成要素のタイプ（例えば、定義されたサイズのエレクトロクロミック窓、特定のタイプのセンサまたはコントローラなど）、識別番号またはコード（例えば、ＣＡＮＩＤ、ライトＩＤ、シリアル番号、またはＩＰアドレス）、製造日、設置日、サイクル数（窓の場合）、関連構成要素（オブジェクトがエレクトロクロミック窓の場合は窓コントローラ）、窓が属するゾーンおよび／またはサブゾーンなどが含まれる。

【0144】

スマートオブジェクトを使ってＧＵＩでゾーンを作成することは、直感的な作業であり得る。部屋１０００の例を続けると、ゾーンのリストを表示するＧＵＩから窓１００２、１００２、および１００３のゾーン群を作成しようとするユーザは、最初にどのゾーンラベルがどの窓に対応するかを解読しなければならないことがある。あるいは、スマートオブジェクトを備えたＧＵＩを使用して、左端の３つの窓（１００１～１００３）を選択するプロセスは、主導的なユーザ操作によって行われてもよい。例えば、左の３つの窓（１００１～１００３）は、１１０１～１１０３を個別にタップするか、または１１０１～１１０３の上で指をスワイプすることによって選択され得る。このステップの前後に、ＧＵＩは、選択された窓がゾーンの一部になることを要求するユーザ入力を受信する。同様のプロセスで、窓をゾーンから削除することができる。このゾーニングプロセスは、選択されたスマートオブジェクトのゾーニング特性を変更する。窓ネットワーク上で動作する適切な制御システムは、この変更をゾーン情報の維持を担当するマスターコントローラまたは他のエンティティに提示する。

【0145】

コミッショニングが地理的位置決めで自動化され得るのと同じ方法で、グラフィカルユーザインターフェースの窓位置情報は、各ネットワーク構成要素または構成要素の組み合わせ（例えば、光学的に切り替え可能な窓と関連付けられた窓コントローラ）の位置座標とネットワークＩＤをリンクするロジックで自動的に生成され得る。実際、上述のコミッショニングロジックは、ＧＵＩのための位置およびネットワークＩＤを提供するために採用され得る。

【0146】

特定の実施形態では、ユーザインターフェースを生成するために、建物または他の構造体用のＧＵＩをレンダリングすることを担当するアプリケーションロジックは、最初にネットワーク上の全てのデバイスのインベントリを取り、ネットワーク構成要素をグラフィカルに表す対応するスマートオブジェクトを識別および／または産生する。一部の場合に、インベントリを取得することは、単にネットワーク構成ファイル（または窓の位置およびコントローラ情報を含む同様のファイル）にアクセスすることを意味し、一部の場合に、インベントリを取得することは、様々なネットワーク構成要素から必要な情報を要求する。通常、ＧＵＩ内のスマートオブジェクトは、それらが表す構成要素の尺度化された画像によって表される。一部の場合に、これにはＣＡＮ ＩＤまたはコントローラＩＤを、特定のデバイスタイプ用に設計されたスマートオブジェクトと関連付けることを要求する場合がある。一部のインターフェースでは、スマートオブジェクトは、エレクトロクロミック窓にのみ使用されるが、他のアプリケーションは、ネットワーク上の他のデバイスまたはデバイスの群用のスマートオブジェクトを含み得る。その場合、制御ロジックは、座標情報を使用して、識別されたスマートオブジェクトを、それらの物理的な位置を表す方法で表示する。

【0147】

説明したように、一部の実施形態では、ＧＵＩに表示されるべきネットワーク構成要素の位置は、地理的位置決めを通じて提供または判定される。一部の実施形態では、位置座標は、ネットワーク構成ファイルから、または相互接続図から提供される。さらに別の実施形態では、建築図面を検査した後またはサイトで手動測定を行った後に、座標情報が設置者によって手動でＧＵＩロジックに提供される。

【0148】

ネットワーク構成要素がスマートオブジェクトによって表される生成されたユーザインターフェースは、コンピュータ可読ファイル形式で保存することができる。ＧＵＩロジックは、窓ネットワークおよび／またはＧＵＩを表示するためのユーザデバイス上の様々な場所に格納されて、実行され得る。一実施形態では、ＧＵＩロジックはマスターコントローラ上で実行される。一部の実施形態では、ネットワークＩＤ、ライトＩＤなどとともに窓位置情報を含むネットワーク構成ファイルは、必要なグラフィカルユーザインターフェースをレンダリングおよび／または提示するのに必要なＧＵＩロジックの全部または一部を有する遠隔デバイス（例えば、電話またはタブレット）に渡される。他の実施形態では、ＧＵＩロジックは、クラウド内にあり、グラフィカルユーザインターフェースを実行しているコンピュータや電話などのデバイスにダウンロードすることができるファイルを生成する。

【0149】

ＧＵＩは遠隔デバイスでユーザに提示されることが多いが、ＧＵＩロジックによって生成された情報を含むファイルは、ネットワークコントローラ、マスターコントローラ、遠隔デバイスまたはクラウドを含むが、これらに限定されない多数の場所に格納され得る。一部の実施形態では、ＧＵＩロジックによって生成された情報は、ネットワーク構成ファイルに格納される。一部の場合に、ＧＵＩを提示するアプリケーションがユーザによってアクセスされるたびに、ＧＵＩロジックは実行される。ＧＵＩが表示され得るデバイスの例は、スマートフォン、タブレット、デスクトップコンピュータ、ラップトップコンピュータ、テレビ、光学的に切り替え可能なデバイス上に配置された透明ディスプレイなどを含む。

【0150】

図１２は、複数の階および部屋が同じビュー内に（例えば、一度にユーザデバイスの画面上に）示され得る、実施形態を示す。一部の実施形態では、スペースまたは境界１２０５を使用して、あるフロア（例えば、１２０３）に配置された窓と、別のフロア（例えば、１２０１および１２０２）に配置された窓とを区別する。一部の実施形態では、スマートオブジェクト１２０１および１２０２によって示される窓などの、通常単一の画面上で同時に見られない窓は、窓の群を区別するために使用されるそれらの間の拡大スペースまたは境界１２０４を有する。特定の階に複数のＩＧＵがある実施形態では、ＧＵＩは、例えば、タッチセンシティブボタン１２０６を用いて、ユーザ操作を通じて横方向に提示されたビュー１２００をパンするためのオプションを提供することができる。サイトが多数のフロアを含むとき、ユーザは、例えば、タッチセンシティブボタン１２０７を用いてフロアをスクロールすることができる。指をスワイプしても、同じ目的を果たすことができる。

【0151】

一部の場合に、ＧＵＩは、ワイヤーフレームモデルを利用することによって、建物、部屋、または構造体の２Ｄまたは３Ｄ透視図を提示する。本明細書で使用される場合、「ワイヤーフレームモデル」という用語は、表現された構造体の形状を表す、一連の線から作成された３Ｄモデルである。典型的には、線は連続表面の端に現れ、それによって、観察者がモデルが表す構造体を理解することを可能にする視覚的輪郭が提供される。一部の場合に、線は、人間の目で容易に区別されるであろう特徴（例えば、建物の表面に沿った色彩または材料の変化）にも対応し得る。ＧＵＩで使用されるワイヤーフレームモデルは、様々なソースから生成されてもよい。一部の場合に、特定のサイトのワイヤーフレームモデルは、建築図面または建物の設計モデルから適合され得る。一部の場合に、ワイヤーフレームモデルは、Ｔｒｉｍｂｌｅ ＮａｖｉｇａｔｉｏｎのＳｋｅｔｃｈＵｐ（商標）、Ａｕｔｏｄｅｓｋ ＲｅｖｉｔなどのＣＡＤソフトウェアを使用して、窓ネットワーク設置者によって迅速に作成され得る。一部の場合に、ワイヤーフレームモデルは、モデルがそれが表す構造体によりよく似ているように、パターン化またはテクスチャ化されていてもよい。一部の場合に、画像をワイヤーフレームモデル上にパターン化して、モデルにより現実的な外観を提供することができる。一部の場合に、ＭａｔｔｈｅｒｐｏｒｔのＰｒｏ ３Ｄ カメラなどの３Ｄカメラを使用して、建物の内部用に、ワイヤーフレームモデルが作成される。

【0152】

図１３は、建物の１つの外面の２Ｄワイヤーフレームを作成するプロセスを示す。このプロセスでは、ユーザは、最初に建物の外部の写真１３０１を撮るか、または選択する。例えば、写真は、携帯電話またはタブレットで撮られ得る。次に、写真は、建物の構造的特徴に対応する画像内のパターンを認識する、画像処理ソフトウェアによって処理され、ワイヤーフレームモデル１３０２を作成する。この実施例では、ワイヤーフレームモデルは、建物１３０３のフロア境界と窓位置１３０４とを識別している。一部の場合に、設置者は、建物１３０４の不必要な部分などの特徴がワイヤーフレームモデルに含まれないように、ワイヤーフレームモデルを編集する能力を有し得る。図１３に示すように、ワイヤーフレームモデルは、モデルを作成するために使用される画像１３０４の上にオーバーレイされてもよく、その結果、ワイヤーフレームモデルは、ＧＵＩで提示されたときにより認識可能になる。ワイヤーフレームモデル上の窓１３０４の位置は、ワイヤーフレーム上の位置に対して、特定の窓を表すスマートオブジェクトと迅速にペアにされ得る。一部の場合に、地理的位置決め方法が使用される場合などに、これは、ＧＵＩロジックによって自動的に行われる。説明したプロセスは２Ｄワイヤーフレームモデルを作成するためのプロセスを示しているが、３Ｄモデルは、別の視点から建物の追加の写真を撮ることによって、容易に作成され得る。一部の場合に、画像処理１３０５は、カリフォルニア州サンラフェルのＡｕｔｏＤｅｓｋ、Ｉｎｃ製のＲｅｖｉｔなどの市販のソフトウェアを介して直接的に行われ、一部の場合に、ワイヤーフレームモデルに基づいて、ＧＵＩを生成するように調整されたソフトウェアを使用して、画像処理が行われる。一部の場合に、画像処理用に調整されたソフトウェアをスマートフォンまたはタブレットから実行して、設置者が、設置時に即座にワイヤーフレームモデルを迅速に作成できるようにすることができる。

【0153】

図１４は、光学的に切り替え可能な窓および／または関連するＩＧＵを表すスマートオブジェクトの集合（サンプルスマートオブジェクト１４０１によって表される）をＧＵＩロジックによって使用して、建物、およびＩＧＵの選択と制御をさらに容易にするために、窓ネットワークが設置される他の構造体の認識可能なワイヤーフレームモデルが作成され得る実施形態を示す。ＧＵＩで生成されたワイヤーフレームは、例えば、建物に利用可能なワイヤーフレームモデルがまだない場合などに有用であり得る。一部の場合に、正確なワイヤーフレームモデルが作成されるように、配向情報をＧＵＩロジックに提供する必要がある。配向情報の重要性を理解するために、部屋の北東隅にあるＩＧＵを検討することができる。窓がその上隅に地理的に位置する場合、窓が部屋の北側にあるのか、部屋の東側にあるのか、または窓が部屋の中の天窓であるのかを判定することが難しい場合がある。一部の場合に、ＩＧＵの配向は、相互接続図、ネットワーク構成ファイルから、またはＩＧＵデバイスに関連する傾斜計もしくはコンパスなどのセンサからの情報によって提供されてもよい。次いで、ＧＵＩロジックを使用して、多くの場合、建物１４０２の構造に似ている全てのＩＧＵの描写を作成する。一部の場合に、ＧＵＩロジックは、スマートオブジェクト１４０１の配置および配向を使用して、建物のワイヤーフレームまたはシェルモデル１４０３を作成する。一部の場合に、スマートオブジェクト１４０１をワイヤーフレーム１４０３の上にオーバーレイして、より認識しやすい建物構造体１４０４を作成する。

【0154】

図１４に示す建物全体のビューはまた、建物の管理者またはネットワーク管理者など、全ての窓を担当するユーザにとって有用であり、窓、または窓が配置されている建物の領域をすばやく選択するのにも有用であり得る。建物全体のビューから領域または窓を選択することによって、ＧＵＩは次に、選択された領域の「ズームイン」ビューを示すことができる。この「ズームイン」ビューは、建物全体だけでなく、選択された領域内の窓（複数可）をも示すことができる。一部の場合に、選択された領域をより明確に示すために、建物全体のビューとは異なる視点から、「ズームイン」ビューを示すことができる。

【0155】

図１５は、ＩＧＵを表すスマートオブジェクト１５０１が建物１５０２の３Ｄモデル上にオーバーレイされている実施形態を示す。ワイヤーフレームモデルのようにスマートオブジェクトが建物の３Ｄモデルにオーバーレイされている場合は、建物を外側から見た人にすぐに認識できるような建物の表現が作成される。そのような実施形態は、特定のサイトで多くの窓を制御することに関心がある施設管理者などのユーザにとって、特に有用であり得る。一部の実施形態では、スマートオブジェクトは、現在の着色状態を示すために陰影１５０３を付けられ得る。特定の実施形態では、建物１５０２の３Ｄレンダリングも同様にスマートオブジェクトであり、例えば、それは、エンドユーザが建物の各面上のスマートオブジェクトを見ることができるように、ｚ軸に沿って回転することによってエンドユーザによって操作されてもよい。別の例では、エンドユーザは、（例えば、屋根または窓の間のスペースのような場所でタッチすることによって）建物オブジェクト１５０２をタッチし、例えば、建物の名前および場所、作業番号（窓供給業者の場合）、この作業サイトの建物数（例えば、設置場所の３棟のうち１棟）、設置窓の数、設置窓の面積（平方フィート）、ＧＵＩで表示するファサード上の窓の面積（平方フィート）、ＧＵＩで表示するファサードのゾーニング情報などの建物に関する情報が表示される。

【0156】

図１６は、部屋１６００の内部からの斜視図を示すＧＵＩの実施形態を示す。この実施例では、部屋の内部の写真が部屋１６０１のワイヤーフレームモデルとペアになっており、それにより、光学的に切り替え可能な窓１６０３および１６０４のスマートオブジェクトが、それらが表す窓上にオーバーレイされた特徴として現れる。そうすることで、本物そっくりのユーザインターフェースがユーザに提供される。ワイヤーフレームモデル１６０１が図１６に示されているが、一部の実施形態では、ユーザの気をそらさないようにするために、ワイヤーフレーム自体をビューから隠すことができる。没入型仮想空間を作成するために、例えば、Ｍａｔｔｅｒｐｏｒｔ ＰＲＯカメラを使用して建物の内部がモデル化されるときなどの一部の場合に、ＧＵＩはまた、ナビゲーション機能１６１０も含んでもよく、そのため部屋内の異なる視点に移動したり、または隣接する部屋に移動したりすることができる。一部の場合に、ＧＵＩに描かれた画像は、オンライン不動産閲覧アプリケーションで使用されるような部屋の３Ｄ回転可能画像であり得る。一部の実施形態では、ＧＵＩは、ＧＵＩインターフェース内でのユーザの対話に基づくユーザへの通知をさらに含むことができ、例えば、アイコン１６０５は、選択された窓の着色状態を変更できることをユーザに通知するために現れ得る。

【0157】

一部の実施形態では、図１６に示されるものなどのＧＵＩの視点は、ライブ画像もしくはビデオ、または部屋１６００からのストリームを示すことができる。例えば、ユーザがリアルタイムで部屋の外観を見ることができるように、ＧＵＩインターフェースは、防犯カメラ（例えば、ネストカム防犯カメラ）から更新され得る。これは、施設管理者などの遠隔ユーザにとって、スペースが使用されているかどうか、および部屋の照明がどのように見えるかを判定するのに有用であり得る。

【0158】

図１７は、ＧＵＩロジックが、光学的に切り替え可能な窓１７０１～１７０２のスマートオブジェクトを、建物の２Ｄ間取り上にオーバーレイするために使用されるＧＵＩの実施形態を示す。一部の場合に、２Ｄ間取りは、建築図面として作成され、一部の場合に、間取りは、設置者によって手動で作成される。場合によっては、建物の片側に多数の窓があり、建物の内部に関するユーザの知識に基づいて窓を選択する方が簡単な場合などに、この視点は３Ｄ視点よりも優れている。この視点を使用して、スマートオブジェクトは、例えば、選択されたことを示す色付きで示されている所望の窓１７０２上で選択矩形１７０３をドラッグアウトすることによって、容易に選択され得る。

【0159】

一部の実施形態では、ＧＵＩを使用するソフトウェアはまた、ユーザがカスタマイズされたビューを作成することを可能にする。例えば、ユーザによって制御可能なデバイスのスマートオブジェクトのみを表示するようにカスタマイズされたビューを作成することができ、それによってユーザの制御が制限される。場合によっては、カスタマイズされたビューは、ＧＵＩがそこからユーザに提示されるところの遠隔無線デバイスに対して、指定された近接内にあるスマートオブジェクトのみを示し得る。他の実施形態では、最も頻繁に使用されるＩＧＵユニット、またはカスタマイズされたビューに含まれるようにユーザによって選択されたＩＧＵに基づいて、カスタマイズされたビューを作成することができる。例えば、オフィスワーカーは、自身のオフィスの窓および頻繁に会議を開催する会議室だけを表示するように設定された、ＧＵＩ／ソフトウェアを持っている場合がある。

【0160】

図１８は、３階建ての光学的に切り替え可能な窓についてのスマートオブジェクト１８０１のみが表示されている、建物のカスタマイズされたビュー１５０２の一例を示している。図１８に示す例示的なＧＵＩは、例えば、建物内の選択された部屋を貸し出したテナントに関連し得る。関係のないオプションでテナントに負担をかけないようにするため、および／またはそれらにリースされていない部屋の窓を制御できないようにするために、建物の他の区域に対応するスマートオブジェクトは削除されている。例えば、カスタマイズされたビューは、あるテナントが別のテナントに属する窓の着色状態を制御する機能を削除することもある。

【0161】

一部の実施形態では、カスタマイズされたビューはまた、特定の観点についての嗜好を有するユーザによって作成され得る。例えば、あるユーザは通常、図１１または図１３に示すような内部ＧＵＩ視点を好むかもしれないが、施設管理者などの別のユーザは、通常、図１５に示すＧＵＩなどの外部視点を好むことがある。

【0162】

一部の実施形態では、ＧＵＩによって示される視点、および一部の場合に、カスタマイズされたビューの視点は、ＧＵＩを提供する遠隔デバイスの場所に依存し得る。例えば、内部視点（図１１など）または外部視点（図１５など）がユーザに提供されるかどうかは、ＧＵＩを実行している遠隔デバイスが建物の外の建物の部屋の中にあると判定されるかどうかに依存し得る。

【0163】

以前に開示されたＧＵＩの実施形態のいずれもまた、窓情報を検索するための単純化されたアクセスを可能にし得る。多くの場合、窓情報を収集するには、ユーザにとって面倒であると認識される手順が必要となる場合がある。例えば、ユーザが特定の窓に関する情報を収集したい場合は、最初に自身で相互接続図上でその窓を見つけて、ライトＩＤを収集する必要がある。ライトＩＤが判定されると、次に、窓情報が、サポートエンジニアのチームに連絡することによって、またはライトＩＤ情報を含むデータベースを参照することによって検索され得る。

【0164】

前述の実施形態のうちの１つを使用して、ユーザは、ＧＵＩを実行しているアプリケーションから窓情報を、直接的に収集することができる場合がある。例えば、窓を選択した後、ユーザは、窓情報を要求するオプションを選択することができる場合がある。例えば、ボタンを押すことによって、ＧＵＩとの対話を通じて情報を要求すると、ＧＵＩは、ＣＡＮ ＩＤ、物理的な窓座標、窓の寸法、現在の着色レベル、製造日、製造施設、工場出荷時の窓の健全性、および窓が受けた着色サイクルの数を含むが、これらに限定されない情報を表示することができる。

【0165】

一部の実施形態では、問題を診断するためにサポートチームに連絡するためのオプションが、ユーザに提示されてもよい。一部の場合に、サポートチームへの連絡に、窓情報が含まれることがある。一部の実施形態では、ユーザに、認識された問題をテキストで説明する機会を提示することができる。一部の実施形態では、ユーザは、知覚される問題を示す画像を添付することができ、例えば、ユーザは、遠隔デバイス上で撮られた写真を添付することができる。一部の場合に、窓コントローラまたは他のネットワーク構成要素で収集された、ＩＧＵのリーク電流または使用履歴などの追加情報も、問題の特定に役立つようにサポートチームに送信され得る。一実施形態では、エンドユーザには、前述のスマートオブジェクトのうちの１つ、例えば、窓スマートオブジェクトを使用して、サポートサービスに警告するオプションが提示される。例えば、スマートオブジェクトが画面上でタッチされると、窓に関する問題を示す選択を含むメニューが表示される。ユーザがこの選出を選択すると、別のメニュー（例えば、プルダウンメニュー）が現れて、ユーザは警告または別のメッセージをサポートサービスに送ることができるようになる。問題はサポートサービスにすでに知られているかもしれないし、知られていないかもしれない。例えば、着色問題は、サービスによって集められたＩ／Ｖデータによって、サポートサービスに知られている場合があり、または例えば、エンドユーザは、ＩＧＵへの水分の浸入をもたらす傷ついたシールなどのサポートサービスが知らない問題を見る場合がある（ただし、ＩＧＵ内のエレクトロクロミックデバイスが他の方法で気密封止されていない場合、サポートサービスへのＩ／Ｖデータで示される場合がある）。

【0166】

［光学的に切り替え可能な窓を見るためのシステム］
特定の実施形態では、ソフトウェアツール（施設管理アプリケーションとも呼ばれる）は、建物または建物の群内の光学的に切り替え可能な窓と対話するための、３次元のユーザ認識可能なグラフィカルユーザインターフェースを提供する。いくつかの実装形態では、ツールは、ユーザが窓に関する情報を制御または受信することを可能にするユーザモードと、ユーザがユーザ動作モードでソフトウェアがどのように動作するかを、設計、設定、および／または構成できるようにする構成モードとを含む。施設管理アプリケーションは、これら２つのモードを使用して説明されているが、ユーザモードにある状態として説明されている特徴は、構成モードにも存在し得、逆もまた同様であることを理解されたい。さらに、単一のアプリケーションではなく、別々のツールまたはモジュールを使用して、２つのモードを実装することができる。施設管理アプリケーションのグラフィカルユーザインターフェースは、コンピュータ、電話、またはタブレットなどの様々な電子デバイスに表示することができる。一部の場合に、グラフィカルユーザインターフェースは、管理者コンソールに表示されてもよく、一部の場合に、グラフィカルユーザインターフェースは、光学的に切り替え可能な窓の表面に配置された透明ディスプレイに表示されてもよい。光学的に切り替え可能な窓に組み込むことができる透明ディスプレイ技術の例は、２０１７年６月２２日に出願された、「ＥＬＥＣＴＲＯＣＨＲＯＭＩＣ ＷＩＮＤＯＷＳ ＷＩＴＨ ＴＲＡＮＳＰＡＲＥＮＴ ＤＩＳＰＬＡＹ ＴＥＣＨＮＯＬＯＧＹ」という名称の米国仮特許出願第６２／５２３，６０６号に記載されており、その全体が参照により本明細書に組み込まれる。

【0167】

このツールは、すでに別の目的で作成されている可能性がある、３Ｄ建物モデルを使用するグラフィカルユーザインターフェースを提供し、ソフトウェアツールの目的のためだけに建物モデルを作成するコストを削減または低減する。窓ネットワークが設置されている多くの現代的な建物では、正確で詳細な３Ｄ建物モデルがすでに存在している。そのようなモデルは、新しい建物を設計するときに建築家やエンジニアによって使用され、そのようなモデルは、建物を改築するときに細心の注意を払って更新され得る。そのような３Ｄ建物モデルを使用することによって、ツールは、ユーザが窓ネットワーク上の窓に関する詳細な情報を見ることを可能にし、ユーザがそのような窓の切り替えを制御することを可能にし得る、強力で直感的なグラフィカルユーザインターフェースを生成し得る。

【0168】

３Ｄ建物モデルは、建物の３次元ジオメトリを反映する数学的表現を使用する。モデルは、適切なソフトウェアによって解釈される場合、建物の特徴、およびその幾何学的特性（例えば、１つ以上の面によって画定される寸法、表面、および体積）に関する詳細を提供することができる、パラメータを含むファイルとして実装されてもよい。建物の特徴（例えば、いくつかの構造上の構成要素、または家具などの建物内に配置されているいくつかの構成要素）は、１つ以上の面で表される。例えば、窓は、１つ以上の窓ペインを表す単一の表面によって表すことができる。より詳細な、または正確なモデルでは、窓は、窓フレームを含む窓の全てまたはほとんどの外面を画定する、複数の表面として表すことができる。一部の場合に、特徴は、その特徴の設計または製造に使用された部分または特定の特徴のための正確なコンピュータ支援設計モデルであり得る。建物モデルにおける機能の詳細は、例えば、以下に説明されるような、表面を画定するその１つ以上の正確な位置、画定する表面（複数可）の寸法、特徴／構成要素の製造情報、特徴／構成要素の履歴情報などの詳細を含むことができる。

【0169】

ビューアモジュールは、建物モデルファイルを読み取って、電子デバイスのスクリーン上に示され得る、建物の３次元可視化を生成し得る。３次元可視化は、様々な建物特徴の複数の表面からレンダリングされ、その各々は１つ以上の多角形状によって定義される。表面は、建物を構成する特徴または物理的側面に対応する。例えば、梁または骨組構造は各々、建物モデル内の１つ以上の表面によって表すことができる。表面の解像度は、非常に高い場合があり、時には、モデルに反映されている寸法は、実際の建物構造体の数センチメートル以内にある場合がある。一部の場合に、表面は、レンダリングされたときに、建物の外観をより正確に反映するように着色またはテクスチャード加工される。建物モデル内では、表面はノードＩＤなどの識別子で識別されるが、このようなＩＤは、ビューアで表示される必要はない。一部の場合に、本明細書の他の箇所に記載されているワイヤーフレームモデルまたはシェルモデルは、ソフトウェアツールまたはアプリケーションと互換性があり得る。

【0170】

建物モデルは通常、建物の設計段階中に生成され、建物の所有者、または建物の設計および建設を担当する所有者の販売者によって提供されてもよい。多くの場合、３Ｄ建物モデルは、Ａｕｔｏｄｅｓｋ Ｒｅｖｉｔなどのコンピュータ支援設計ソフトウェアまたは他の同様のソフトウェア設計パッケージを使用して生成される。一部の場合に、建物モデルは、建物の建設後にのみ作成され、その場合は、Ｌｉｇｈｔ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｒａｎｇｉｎｇ（ＬｉＤＡＲ）などの位置検出システムを利用できる。例えば、建物モデルは、マターポート３ＤカメラのようなＬｉＤＡＲカメラを使用して生成され得る。一部の実施形態では、建物空間（複数可）の３Ｄモデルは、例えば、ＲＦ波を送信し、次いで１つ以上の受信機に対する（反射された、または直接的な）ＲＦ波を受信する１つ以上のデバイスから反射された、または送信されたエネルギーから入力を受信する、全方向ビーコンを使用して生成され得る。この能力を有する１つのそのようなシステムは、２０１５年１１月１９日に出願され、ＵＳ２０１６０２９９２１０Ａ１として公開された、「Ｔｅｃｈｎｉｑｕｅｓ ｆｏｒ Ｉｍａｇｉｎｇ Ｗｉｒｅｌｅｓｓ Ｐｏｗｅｒ Ｄｅｌｉｖｅｒｙ Ｅｎｖｉｒｏｎｍｅｎｔｓ ａｎｄ Ｔｒａｃｋｉｎｇ Ｏｂｊｅｃｔｓ Ｔｈｅｒｅｉｎ」という名称の米国特許出願第ＵＳ１４９４５７４１号に記載されている、Ｏｓｓｉａ（商標）無線電力供給システムであり、その全体が参照により本明細書に組み込まれる。特定の実施形態では、ＥＣ窓は、無線電力を受信および／または送信するように構成されている。そのような無線電力能力とともに使用されると、本明細書に記載されるようにＥＣシステムは自動コミッションすることができ、建物または空間地図は、その無線電力伝送サブシステムを使用して、ＥＣ窓システム／窓ネットワークによって生成される。

【0171】

３次元（３Ｄ）モデルには、多くの場合、エンジニア、建築家、または施設管理者に関連する可能性がある、様々な建物の情報が含まれる。建物モデルファイルには、建物の機能に対応するメタデータと、それらの機能が互いにどのように相互作用するかが含まれ得る。実例として、建物内に天然ガスを供給するために使用されるパイプを考慮する。ファイル内のメタデータには、パイプのモデル、製造業者、設置日、設置業者、材料、寸法およびフィッティングタイプなどの情報を含む、（１つ以上の表面を使用して表示され得る）パイプの表現にリンクされた情報が含まれ得る。別の例として、建物内のＩ字形ビームの全部または一部分を表面として表すことができ、そのような表面は、Ｉ字形ビームの位置、その構造材料、その販売者などに関する情報を含むことができる。

【0172】

さらに別の例では、建物モデルの表面または特徴は、タグまたはキーワードを使用して、モデルファイル内で索引付けすることができる。これらのタグは、表面／特徴に関連付けられている名前、または対応するメタデータに含まれていてもよい。表面または特徴は、表面／特徴を様々なカテゴリにリンクするタグを有していてもよい。カテゴリは、例えば、特徴タイプ、特徴モデル、サイズ、位置、または他の任意の関連パラメータに基づいてもよい。次いで、施設管理アプリケーションは、一部の場合に、ある特定のタグに対応する機能を識別することができる。施設管理アプリケーションはまた、建物モデル内の機能を検索するために、使用されてもよい。例えば、ユーザが次の検索：［特徴タイプ：窓のオーバーハング］、［階：３］、［方向：西］を入力した場合に、ユーザは、建物の西側に面する、３階の全てのオーバーハングの特徴を識別することができる。一部の場合に、これらのタグは、建物モデルの生成に使用されるソフトウェアによって、建物設計中に自動的に特徴／表面に追加され得る。一部の場合に、特徴のライブラリから建物モデルに特徴が追加されるときなど、すでに適切なタグを持つ建物モデルに、特徴がインポートされる場合がある。建物が追加の交換などによって変更された場合、建物モデルは、変更を反映するために更新されてもよい。例えば、建物が改築された場合は、特徴は、建物モデルに追加され、またはそれから削除されてもよい。一部の場合に、建物モデル内の表面の表現は変更されないままであるが、影響を受ける表面に関するメタデータ情報が更新される。例えば、構造上の構成要素のメタデータを更新して、その構成要素が最後に安全性について検査された日付を示すことができる。

【0173】

一部の場合に、建物モデルは、窓ネットワークを念頭に置いて生成される。例えば、モデルが最初に作成されたときに、または後で、窓ネットワークの構成要素（例えば、ＩＧＵ、ネットワークコントローラ、および窓コントローラ）が建物モデルに追加される。そのような構成要素がモデルに追加されるとき、それらの各々は、１つ以上の特徴および／または１つ以上の表面として定義される。一部の場合に、窓ネットワークの構成要素は、窓ネットワーク構成要素のライブラリから追加され、そこでは構成要素は、それらの寸法、外観などによって、全て建物モデルに含めることができる対応するメタデータの形態で表される。

【0174】

一部の場合に、建物モデルは、光学的に切り替え可能な窓のためのグラフィカルユーザインターフェースを生成するのに不可欠ではない情報を含む、非常に複雑なファイルの形態で提供される。例えば、建物モデルは、建物モデルの編集履歴などの重要ではない情報、または窓ネットワークとインターフェースしない構成要素に関するメタデータ情報を含む場合がある。そのような情報は、モデルがグラフィカルユーザインターフェースの機能を生成またはレンダリングするために使用される前に、削除されてもよい。一部の場合に、ファイルは「．ＲＶＴ」ファイルタイプ、またはＡｕｔｏｄｅｓｋ Ｒｅｖｉｔなどのコンピュータ支援設計ソフトウェアパッケージを使用して生成された別の独自のファイルタイプを有する場合がある。一部の場合に、建物モデルは、そのモデルを施設管理アプリケーションによる使用に適したものにする、ポストプロダクションプロセスを経てもよい。一部の場合に、建物モデルは、不要な情報がファイルから削除された単純な形式で、エクスポートおよび保存されてもよい。一部の場合に、建物モデルは、複数の電子デバイスタイプを介して、および／または様々なオペレーティングシステムにわたって容易にアクセスされ得る、オープンソース形式で保存され得る。例えば、一部の場合に、建物モデルは、ウェブブラウザと互換性があるかまたはウェブブラウザ内に統合されているビューアモジュールによってアクセスされ得る、形式で保存され得る。

【0175】

図１９は、施設管理アプリケーション１９００（上述のツールの一例）の構造を示すブロック図を提供する。アプリケーションは、３Ｄ建物モデル１９０２、または少なくともそのモデルからの情報を受け取り、その建物モデルをビューアモジュール１９１０で解釈するように構成される。アプリケーションはまた、窓ネットワークに関する情報のソース（例えば、マスターコントローラ１９２０または窓ネットワーク上の別の構成要素）から窓情報１９２４を受信するように構成される。そのような情報は、ネットワークＩＤ（例えば、ＣＡＮ ＩＤ）、および／または窓ネットワーク上の個々の窓を一意に識別する他の情報を含み得る。なおもさらに、アプリケーションは、窓ネットワークエンティティ（例えば、光学的に切り替え可能な窓）を建物モデル上のノードＩＤにリンクさせる情報を含む、ネットワーク構成ファイル１９３０を受信するように構成される。アプリケーションはまた、アプリケーションによって処理される光学的に切り替え可能な窓のためのスマートオブジェクトを受信する（または少なくともそのような窓のためのスマートオブジェクトを産生するのに十分な情報を受信する）ように構成され得る。アプリケーションは、１つ以上のアプリケーションプログラミングインターフェースまたは他の適切なソフトウェアインターフェースによって、これらの様々な情報を受信するように構成され得る。

【0176】

ビューアモジュールは、建物の窓が、グラフィカルユーザインターフェース上で（例えば、コンピュータ、電話、タブレット、光学的に切り替え可能な窓に関連する透明ディスプレイ、または別の電子デバイスなど上で）受信された窓情報と一致する、スマートオブジェクトとして表示されることを可能にする様式で、建物モデル（またはそのようなモデルからの情報）を解釈する。

【0177】

示された施設管理アプリケーションはまた、ネットワーク構成ファイル１９３０を更新するために、および／または窓ネットワーク上の光学的に切り替え可能な窓を制御するための制御命令１９２２を提供するために使用され得る、ユーザ入力１９０４を受信するように構成される。特定の実施形態では、アプリケーションは、タッチスクリーン、音声コマンドインターフェース、および／またはアプリケーションを操作するデバイスがユーザ命令を受信するために有することができる他の特徴を介して、本明細書に記載される任意の目的のためにユーザ入力を受信するように構成される。光学的に切り替え可能な窓のネットワークに関連して使用することができる音声コマンドインターフェースの例は、２０１７年５月２５日に出願された、「ＣＯＮＴＲＯＬＬＩＮＧ ＯＰＴＩＣＡＬＬＹ－ＳＷＩＴＣＨＡＢＬＥ ＤＥＶＩＣＥＳ」という名称のＰＣＴ特許出願第ＰＣＴ／ＵＳ１７／２９４７６号に記載されており、その全体が本明細書に組み込まれる。ここで、ソフトウェアツールの様々な機能をより詳細に説明する。

【0178】

窓ネットワーク上の１つ以上のコントローラを介してアクセスされることに加えて、ネットワーク構成ファイル１９３０は、施設管理アプリケーションによってアクセスされ得る。前述のように、ネットワーク構成ファイルは、窓ネットワーク上で情報を送信し、および／または光学的に切り替え可能なデバイスを動作させるために制御ロジックによって使用される、様々なネットワーク情報を含むことができる。施設管理アプリケーションによってアクセスされると、ネットワーク構成ファイルはまた、建物モデルの特徴および／または表面を、窓ネットワークの態様にリンクまたはマッピングすることができる。例えば、建物モデルのノードＩＤは、特定のＩＧＵ、ゾーン、ゾーン群、窓座標、窓ＩＤ、およびネットワークＩＤ（例えば、ＣＡＮ ＩＤまたはＢＡＣｎｅｔ ＩＤ）にリンクされ得る。一部の場合に、ネットワーク構成ファイルは、コミッショニングプロセス中またはアプリケーションのマッピング機能を利用している間に更新される、データベース構造体を有する。一部の場合に、施設管理アプリケーションによって使用されるネットワーク構成ファイル１９３０は、マスターコントローラによってアクセスされるのと同じファイル、または同じファイルのコピーである。一部の場合に、施設管理アプリケーションによって使用されるネットワーク構成ファイルは、マスターコントローラに情報を提供する、ネットワーク構成ファイルとは異なる情報を格納することができる。例えば、一部の場合に、アプリケーションで使用されるネットワーク構成ファイルは、建物モデルのノードＩＤと窓ＩＤのみをペアにする。このような場合、マスターコントローラによってアクセスされるネットワーク構成ファイルには、ネットワークコントローラまたは窓コントローラに通信を送信するために使用される、窓ＩＤとネットワークＩＤ（例えば、ＣＡＮ ＩＤ、ＢＡＣｎｅｔ ＩＤなど）との間のマッピングなどの追加情報が含まれる。

【0179】

一部の場合に、建物モデルおよび／またはネットワーク構成ファイルは、施設管理アプリケーションを実行するために使用されるデバイスに格納される。一部の場合に、建物モデルおよび／またはネットワーク構成ファイルのインスタンスが多数のデバイスに複数存在し、その各々は、施設管理アプリケーションを実行するように設定される。一部の場合に、建物モデルおよび／またはネットワーク構成ファイルは、施設管理ソフトウェアを実行しているデバイスの外部の場所（例えば、クラウド内、遠隔サーバ上、または窓ネットワーク内のコントローラなど）に格納される。

【0180】

施設管理アプリケーションに含まれるか、またはそれによってアクセスされるものは、ビューアモジュール１９１０である。ビューアモジュールは、３Ｄ建物モデル（またはその部分）を読み取り、施設管理アプリケーション（例えば、電話、タブレット、またはラップトップなど）を実行またはアクセスしているデバイス上でモデルの視覚的レンダリングを提供する、ソフトウェアモジュールである。一部の場合に、ビューアモジュールは、独自のファイルタイプに使用されるライセンスのあるソフトウェアであり、一部の場合に、ビューアは、オープンソースソフトウェアであり得る。

【0181】

施設管理アプリケーションはまた、権限を持つユーザがグラフィカルユーザインターフェースを設定できるようにする、マッピング機能を有する。マッピング機能は、建物モデル内の表面および／または特徴のノードＩＤを、ＩＧＵ、ゾーン、ゾーン群、およびその他の窓ネットワーク構成要素に関連付ける。一部の場合に、マッピング機能は、ノードＩＤを、対応するスマートオブジェクトとペアにすることもできる。マッピング機能は、ネットワーク構成ファイルから窓ネットワークに関する情報にアクセスすることができる。マッピング機能はまた、ユーザ入力を介して行われたまたは識別された関係を、ネットワーク構成ファイルに保存することができる。

【0182】

一部の場合に、ビューアモジュールまたは関連するユーザインターフェースは、グラフィカルユーザインターフェース内の表面および／または特徴の代わりに、スマートオブジェクトを表示するように構成される。一部の場合に、特徴は、自動または手動でその特徴をＩＤ、データ、またはスクリプトと関連付けることによって、スマートオブジェクトに変換され得る。あるいは、ビューアモジュールまたはユーザインターフェースは、グラフィカルユーザインターフェースに表示される対応する表面または特徴の上に、スマートオブジェクトをオーバーレイするように構成される（例えば、スマートオブジェクトは、表面が選択可能なスマートオブジェクトに対応することを示す、表面の周囲にハイライト表示された境界を提供することができる）。一部の場合に、スマートオブジェクトは、窓ネットワークによって提供される情報（例えば、ＩＧＵの着色状態または屋内／屋外温度）を示すために、３Ｄモデルの外観を修正することができる。

【0183】

施設管理アプリケーションは、任意選択的に制御機能を含み、それを通じてユーザは、１つ以上の光学的に切り替え可能な窓を制御することができる。例えば、アプリケーションは、特定のＩＧＵまたはＩＧＵのゾーンについての着色状態を設定するために、マスターコントローラ（または制御機能を有する他の窓ネットワークエンティティ）に命令を送信することができる。一部の場合に、制御機能は、制御ロジックとして機能し（例えば、図４Ａの４０４参照）、他の場合には、制御機能は、窓ネットワーク上の他の場所にある（例えば、マスターコントローラにある）制御ロジックに制御命令を中継し得る。一部の場合に、アプリケーションを使用して、ユーザの許可に基づいて、スケジューリングルーチンまたはルールが定義または実行される。一部の場合に、アプリケーションを使用して、窓ネットワークによって提供される他の機能が制御される。例えば、窓ネットワーク上のＩＧＵが窓アンテナを用いて構成されている場合、施設管理アプリケーションは、窓アンテナを用いて実施される無線ネットワークの許可を構成するために使用されてもよい。

【0184】

施設管理アプリケーションは、電話、タブレット、およびコンピュータなどの様々な電子デバイスから、ユーザ入力１９０４を受信することができる。一部の場合に、グラフィカルユーザインターフェースは、光学的に切り替え可能な窓の表面に配置された透明ディスプレイ上に表示され、ユーザ入力は、透明ディスプレイとのユーザ対話によって受信される。例えば、透明ディスプレイは、ＩＧＵのＳ１～Ｓ４上に配置されてもよく、ライトの実行可能部分にわたって、部分的にまたは完全に延在してもよい。一部の場合に、窓はまた、表示されたＧＵＩを制御し、および／またはエレクトロクロミック窓を操作する、ガラス上の透明窓コントローラを含み得る。一部の場合に、ＧＵＩインターフェース用の透明ディスプレイを、日付、時間、または天気の表示などの他の機能にも使用することができる。一部の場合に、アプリケーションは、ＡｐｐｌｅのＳｉｒｉプラットフォーム、ＡｍａｚｏｎのＡｌｅｘａプラットフォーム、またはＧｏｏｇｌｅ Ａｓｓｉｓｔａｎｔプラットフォームを使用するデバイスなどの音声で制御されるスピーカーデバイスから、音声でユーザ入力を受信するように構成される。一部の場合に、施設管理アプリケーションは、インターネット接続を有する電子デバイスを介してアクセスされるウェブベースのアプリケーションであり、ここにおいて、ユーザは適切な許可を有する。例えば、一部の場合に、ユーザがウェブベースのアプリケーションにログインするための資格を有する場合、および／またはデバイスが窓ネットワークから近い距離にあると判定される場合にのみ、ユーザはアプリケーションへのアクセスを許可される。一部の場合に、施設管理アプリケーションは、建物モデルファイルおよび／またはネットワーク構成ファイルのコピーを含み得る。例えば、建物モデルファイル、ネットワーク構成ファイル、および施設管理アプリケーションは、アプリケーションの動作性能を向上させ、一部の場合に、インターネット接続が失われてもアプリケーションの使用を可能にするために、電子デバイスに保存またはインストールされ得るプログラムにパッケージ化することができる。一部の状況によっては、実行可能アプリケーションがデバイスに保存されているときに、関連する構成要素またはファイルに遠隔の場所からアクセスすることができる。例えば、建物モデルおよび／またはネットワーク構成ファイルは、遠隔に格納され、必要なときにだけアプリケーションの機能を実行するために全体的または部分的に検索されてもよい。一部の場合に、例えば、様々なデバイス上にプログラムのインスタンスが複数ある場合、構成モードでアプリケーションを動作させている間に行われたプログラムに対する変更は、例えば、クラウドを使用して、他のデバイス上に配置されて実行されているプログラムのコピーにプッシュされてもよい。

【0185】

施設管理アプリケーションを構成モードで動作させるとき、許可を有するユーザ（例えば、施設管理者）は、後にユーザモードで使用するためにアプリケーションがどのように機能するかを設定および構成することができる。図２０は、施設管理アプリケーションが構成モードで動作しているときに表示され得る、グラフィカルユーザインターフェースの実例を提供する。施設管理者は、建物モデルが表示されるウェブブラウザなどの窓２００２で、施設管理アプリケーションを開くことができる。管理者は、エレクトロクロミックＩＧＵに対応する表面２００６などの窓ネットワーク上の構成要素に対応する、建物モデルの特徴または表面を位置決めすることができる。表面または特徴が選択されると、次に、管理者は、ポップアップ窓２００８または他のインターフェースを提示され、それから管理者は、選択された表面および／または特徴を、窓ネットワーク上の構成要素に識別またはマッピングすることができる。例えば、一部の場合に、管理者は、アプリケーションによって提供されるネットワーク構成要素のリストから、表面および／または特徴がどのデバイスに対応するかを選択することができる（例えば、アプリケーションは、ネットワーク構成ファイルからネットワーク構成要素のリストを受信することができる）。一部の場合に、管理者は、窓ネットワークの構成要素に対応する表面および／または特徴を識別し、その後、アプリケーションに提供されるロジックを使用して、窓ネットワーク上の構成要素のネットワークＩＤを、対応する識別された表面および／または機能に自動的にリンクすることができる。例えば、地理的位置を使用した自動コミッショニングに関して前述した方法を使用して、ロジックは、窓ネットワーク構成要素の判定された位置を建物モデル内の識別された表面および／または特徴の位置と比較することによって、建物モデル内のノードＩＤを、対応するＩＧＵまたは他の構成要素のネットワークＩＤにマッピングするために使用され得る。一部の場合に、プロセスは、窓または窓ネットワークの他の構成要素に対応する、建物モデル内の表面および／または特徴を自動的に識別する。一部の場合に、設定モードを使用して窓ネットワークがコミッションされ得るように、コミッショニングロジックが施設管理アプリケーションから動作されてもよい。

【0186】

建物モデル内の表面および／または特徴が、ノードＩＤを介して（例えば、ネットワークＩＤを介して）窓ネットワーク上の構成要素に手動で、または自動的にペアにされた後、スマートオブジェクトは選択または生成される。最終的に、これらはユーザ動作モードでの表示および選択のために利用可能にされる。スマートオブジェクトは、建物モデルのノードＩＤにリンクされており、本明細書の他の箇所で説明されているように様々なフォーマットで表示することができる。例えば、スマートオブジェクトは、建物モデルに表面の代わりに表示されてもよく、またはスマートオブジェクトは、建物モデルにおいて１つ以上の表面が選択されたときに、活性化されるように（例えば、制御可能な特徴のリストを提示するように）構成され得る。一部の場合に、建物モデル内のスマートオブジェクトのサイズ、寸法、および配置が、窓ネットワークの構成要素とペアにされた建物モデルの表面（複数可）および／または特徴と対応するように、スマートオブジェクトはアプリケーションによって生成される。一部の場合に、アプリケーションは、建物モデル内のメタデータ、またはスマートオブジェクトの作成に使用されるネットワーク構成ファイルから情報を受信する。生成されたスマートオブジェクトで利用可能な特徴は、スマートオブジェクトが関連付けられている構成要素のＩＤ（例えば、窓ＩＤまたはネットワークＩＤ）に依存し得る。例えば、スマートオブジェクトが光学的に切り替え可能な窓とペアになっている場合、スマートオブジェクトは、現在の着色状態を表示し、および／またはユーザが色付け状態を調節することを可能にする、特徴を有することができる。エレクトロクロミック窓が関連するセンサ（例えば、内部光センサ、外部光センサ、内部温度センサ、外部温度または居住者センサ）を有する場合、その際、スマートオブジェクトはまた、検知された情報、および／または検知された情報を調整するのを助けるための光学的に切り替え可能な窓の着色状態を制御するためのオプションを表示するように構成されてもよい。一部の場合に、スマートオブジェクトは、スマートオブジェクトのライブラリ（例えば、アプリケーション内に格納されているか、または遠隔サーバからダウンロードされたライブラリ）から選択され、スマートオブジェクトのライブラリは、窓ネットワークに設置され得る様々な構成要素を含む。一部の場合に、スマートオブジェクトは、構成モード内の建物モデルに表示され、そこでそれらは、さらなる編集のために選択され得る。

【0187】

再び図２０を参照すると、施設管理者は次に、窓ネットワークがどのように構成されているかを編成することができる。例えば、２００８などのダイアログボックスを使用して、施設管理者は、特定のＩＧＵを、特定のゾーンまたはＩＧＵのゾーン群に属するように構成することができる。一例として、建物モデル内の表面および／または特徴を選択した後、アプリケーションは、窓を追加することができるゾーンのリストを表示するか、または新しいゾーンを作成するオプションをユーザに提示することができる。一部の場合に、動作の構成モードを使用して、ユーザモードで表示され得るカスタマイズされたビューを作成することができる。例えば、構成モード内で利用可能なナビゲーションコントロール２００４を使用して、ユーザは、ユーザモードで表示されるであろう観点または視点を選択することができる。

【0188】

構成モードを使用して、建物管理者は、光学的に切り替え可能な窓の着色スケジュール、ならびに／または建物内の照明および／もしくは温度を調整するためのルールを定義することができる。管理者は、他のユーザに許可を追加的に設定することができる。例えば、大きな建物のテナントは、自身の賃貸スペース内の光学的に切り替え可能な窓に対する制御のみを与えられてもよい。一部の場合に、施設管理者は、他のユーザおよび／またはデバイスに、アプリケーションの構成モードへのアクセスを許可して、その結果、彼らが自身のルールを確立し、および／または自身のカスタマイズされたビューを作成することができる。一部の場合に、施設管理者または管理アカウントのユーザによって確立されたルールに違反しないように、ユーザが行うことができるルールまたは他の変更は制限される。

【0189】

ユーザモードで動作するとき、建物の構造を描くグラフィカルユーザインターフェースが提示され、そこではインターフェースは、気象ネットワーク上の光学的に切り替え可能な窓を制御するために使用され得る、スマートオブジェクトを有する。ユーザ動作モードで提示され得るインターフェースの特定の非限定的な例は、図１２、および図１５～図１８に関連して、提示および説明される。アプリケーションのユーザモードにあるとき、ビューアモジュールは、建物モデル、またはそのいくつかの特徴、またはそれの派生した描出を表示することができる。いずれにしても、表示された表現は、窓に関する情報（例えば、現在の着色状態、製造業者、サイズなど）を判定すること、および窓の着色状態を制御することなどの目的で、ユーザが選択できる光学的に切り替え可能な窓を示す。説明したように、窓はスマートオブジェクトとして表示されてもよい。一部の場合に、最初にユーザモードで提示されるビューは、ユーザおよび／またはデバイスに依存し得る。例えば、施設管理者は遠隔の場所にいるかもしれないし、または複数の建物の光学的に切り替え可能な窓を担当しているかもしれないので、施設管理者は最初に、管理者が管理許可を有する様々な場所の地図を提示される可能性がある。例えば、グーグルマップＡＰＩを使用して、建物管理者は最初に、識別された様々な建物を有する地図を提示されてもよい。建物管理者は次に、関心のある建物を選択して、対応する建物モデルを表示することができる。一部の場合に、ユーザインターフェースに表示されるビューは、アプリケーションがアクセスされているデバイスの位置に依存する。例えば、モバイルデバイスは、本明細書の他の箇所に記載されているような地理的位置決め方法によって位置決めされてもよく、ユーザは、それらが位置決めされている部屋の視点で提示されてもよい。施設管理アプリケーションを実行するデバイスがカメラを有する場合、アプリケーションは、ユーザが１つ以上の窓および／または建物の特徴を捉えて写真を撮ることを可能にするように構成され得、その場合、アプリケーションは、その写真からデバイスの配置または方向を認識し、ＧＵＩ内に対応するビューまたは視点を提示する。一部の場合に、窓は、視覚的に邪魔にならないが、施設管理アプリケーション内の画像解析モジュールによって容易に認識されることができる、ＩＤ（例えば、窓の端の近くの、または窓フレーム上に位置する不規則なパターン）を有することができる。一部の場合に、画像解析モジュールは、画像内に取り込まれた特徴を、建物モデルのジオメトリと比較して、アプリケーションを実行しているデバイスの位置を判定することができる。

【0190】

アプリケーションのユーザモードにあるとき、全ての光学的に切り替え可能な窓または窓のサブセットは、スマートオブジェクトとして表示されてもよく、そのような窓のリストはユーザの許可に基づいて判定される。特定の実施形態では、ユーザインターフェースは、ユーザが、１つ以上のスマートオブジェクトに触れることまたは別の方法で選択することによって、自身が制御したい窓ネットワーク上の特定のデバイスを選択することを可能にするように構成される。ＩＧＵに対応するスマートオブジェクトを選択した後、例えば、アプリケーションは、ＩＧＵ、またはＩＧＵが属するゾーンもしくはゾーン群内の全てのＩＧＵの着色状態を制御するためのオプションをユーザに提示することができる。１つ以上のＩＧＵとペアになっているスマートオブジェクトを選択した後、ユーザには追加的に、光学的に切り替え可能な窓を制御するためのオプションが提示されることがある。例えば、アプリケーションは、ＨＶＡＣシステムによるエネルギー消費を低減するために、ＩＧＵが自動的に着色されるというオプションをユーザに提供してもよく、またはアプリケーションは、光学的に切り替え可能な窓の着色状態を制御する、ルールを設定する機会をユーザに提供してもよい。例えば、アプリケーションは、時刻または建物内のユーザの位置に基づいて、ルールを確立するためのオプションをユーザに提示することができる。

【0191】

一部の場合に、ユーザモード（または構成モード）は、ビデオゲームまたはＣＡＤツールで一般的に使用されているものと類似している建物モデルをナビゲートするためのナビゲーション特徴を提示するように構成される。例えば、キーボード上のキー、またはスクリーン上のボタンを使用して、建物モデルをナビゲートし、提示されているビューの視点を変更することができる。一部の場合に、ナビゲーション特徴は、建物モデルをナビゲートするために使用され得る、６つの自由度を提供する。例えば、ユーザは、前進／後退（サージ）、上／下への移動（ヒーブ）、および左／右への移動（スウェイ）に対応する観点とともに移動する、３つの垂直軸に沿って観点を平行移動させることができる。一部の場合に、ユーザはまた、３つの直交軸を中心に観点を回転させることができ、回転は、ヨー（上下軸）、ピッチ（横軸）、およびロール（前後軸）に関して言及される。一部の場合に、観点は、観点を通過しない軸を中心に回転してもよい。例えば、ボタンをキーで押すことによって、建物の外観（例えば、図１５に示すように）を、建物の中心を通る垂直軸を中心に回転させることができる。

【0192】

施設管理アプリケーションのユーザモードにおいて、特定のＩＧＵを表すスマートオブジェクトを選択すると、そのＩＧＵが属するＩＧＵのゾーン全体を選択することになる可能性があるので、ユーザによって行われたそのような調節は、ゾーン内の全てのＩＧＵに適用される。一部の場合に、ユーザは、既に選択されているＩＧＵのゾーン内のＩＧＵを選択することによって、ＩＧＵのゾーンから単一のＩＧＵに選択を絞り込むことができる。一部の場合に、建物モデルの表面および／または特徴は、スマートオブジェクトに置き換えられているか、またはオーバーレイされている場合にのみ、ユーザモードで選択され得る。一部の場合に、グラフィカルユーザインターフェースは、構成モードとユーザモードとを切り替えるためのトグルスイッチまたは別の同様の選択特徴を含む。一部の場合に、特定の特徴（例えば、スマートオブジェクトを追加する能力など）が削除されている点を除けば、ユーザモードは構成モードと視覚的に類似するように現れる。

【0193】

構成モードおよび／またはユーザモードを使用して、施設管理アプリケーションは、様々な機能に使用することができる。例えば、アプリケーションは、窓ネットワークを構成および／またはコミッショニングするために使用されてもよい。このアプリケーションを使用して、光学的に切り替え可能な窓の光学的な着色状態を、（個別にまたはゾーンとしてのいずれか）制御することもできる。アプリケーションを使用して、特定のユーザの着色状態のスケジュールまたは着色の嗜好を構成することもできる。

【0194】

一部の場合に、施設管理アプリケーションは、建物の特定の部分が直射日光を受けることを防ぐために、制御ロジックによって実行される「インテリジェンス」アルゴリズムによって使用される建物モデルから、インテリジェンスパラメータを判定してもよい。例えば、ユーザは、建物内で直射日光が必要とされない物理的空間（例えば、デスクまたはワークステーションなどの占有領域に対応する空間）に対応する、建物モデル内の領域を画定することができる。制御ロジック（例えば、マスターコントローラ、クラウド、または施設管理アプリケーションを実行しているデバイス上で動作する）は、その際、オーバーハングおよび窓の近くの他の不透明構造などの建物の幾何学的レイアウト、ならびに他の点では太陽光が妨げられずに、直射日光を必要としないグレアフリー領域を通過するときに窓が着色されるというルールを確立するための太陽の位置などのインテリジェンスパラメータを考慮する、ルールを確立することができる。一般に、インテリジェンスパラメータは、建物、その周辺、または建物の１つ以上の着色可能な窓に入る直射日光もしくは太陽光線に影響を与える環境に関するいくつかの情報である。インテリジェンスアルゴリズムは、太陽位置、窓の配向（および本明細書で議論される他の窓のインテリジェンスパラメータ）、背景太陽光線、雲量などを含むパラメータに基づいて、窓の着色状態を判定し得る。インテリジェンスアルゴリズムの例は、２０１５年５月７日に出願された、「ＣＯＮＴＲＯＬ ＭＥＴＨＯＤ ＦＯＲ ＴＩＮＴＡＢＬＥ ＷＩＮＤＯＷＳ」という名称の米国特許出願公開第２０１７／００７５１８３号、および２０１７年４月６日に出願された、「ＭＥＴＨＯＤＳ ＯＦ ＣＯＮＴＲＯＬＬＩＮＧ ＭＵＬＴＩ－ＺＯＮＥ ＴＩＮＴＡＢＬＥ ＷＩＮＤＯＷＳ」という名称のＰＣＴ特許出願第ＰＣＴ／ＵＳ１６／５５００５号にさらに論じられており、その両方は、それらの全体が参照により本明細書に組み込まれる。

【0195】

これから、インテリジェンスアルゴリズムによって使用される窓パラメータのいくつかを、図２１Ａ～図２１Ｃに示す実施例を参照しながら説明する。一般に、インテリジェンスで使用されるパラメータ／寸法は、建物モデルに提示される建物寸法のほんの一部である。これらのパラメータは、制御ロジックによって使用されるように、例えば、ネットワークコントローラ、マスターコントローラ、またはクラウドに配置された、ファイルまたはデータベースに格納されてもよい。一部の場合に、これらのパラメータは、ネットワーク構成ファイルに格納されることがある。

【0196】

図２１Ａは、建物２１１０の外壁にある窓２１０５を示す。基本的な測定のいくつかには、窓の高さ（Ａ）、窓の幅（Ｂ）、および部屋のフロアからの窓台の高さ（Ｃ）が含まれる。窓の方位角（Ｄ）は、北の軸から表面の法線までの時計回りで測定された角度であり、窓の傾き（Ｅ）は、垂直軸から表面の法線までの測定された角度である。

【0197】

図２１Ｂは、インテリジェンスパラメータがどのように、壁２１１０上の窓２１０５の上方のオーバーハング２１１５に関係するかを示す。これらのパラメータを使用して、制御ロジックは、オーバーハングが太陽光が窓２１０５を通過するのを妨げるときを判定することができる。オーバーハングの窓の上部を越える高さは、（Ａ）と寸法される。窓からの傾斜角は（Ｂ）と寸法される。寸法（Ｂ）は、ほとんどのオーバーハングについて一般に約９０度である。窓からの左の延長線（Ｃ）と右の延長線（Ｄ）は、窓の端からオーバーハングの始点までの距離である。最後に、深さ（Ｅ）は、オーバーハングが壁２１１０からどれだけ突出しているかの測定値である。

【0198】

図２１Ｃは、窓２１０５の近くに配置された左右のフィン構造体（２１２０および２１２５）について、インテリジェンスパラメータがどのように測定され得るかを示す。左フィン２１２０は、寸法（Ａ）、（Ｂ）、（Ｃ）、（Ｄ）、および（Ｅ）によって特徴付けられ、一方で、右フィン２１２５は、寸法（Ｆ）、（Ｇ）、（Ｈ）、（Ｉ）、および（Ｊ）によって特徴付けられる。左右のフィン延長部（Ａ）および（Ｆ）は、窓の端からそれぞれのフィンの平面までの水平距離である。測定値（Ｂ）および（Ｇ）は、窓の上部とそれぞれのフィンの上部との間の垂直距離であり、時々これらの測定値は、窓の上部のより上方のフィン距離と言及される。測定値（Ｃ）および（Ｈ）は、窓の下部とそれぞれのフィンの下部との間の垂直距離であり、時々これらの測定値は、窓の下部のより下方のフィン距離と言及される。測定値（Ｄ）および（Ｉ）は、窓からのフィン傾斜角を画定する。一般に、これらの測定値は約９０度である。最後に、測定値（Ｅ）および（Ｊ）は、フィン深さを画定し、これは各フィンが壁２１１０から突出する距離である。

【0199】

図２２は、インテリジェンスが部屋内の占有領域をどのように計算し得るかの例証としてのデスクの座標を示す。インテリジェンスは、基準点（この場合、示されている光学的に切り替え可能な窓の角）からの占有領域の水平（ＸおよびＹ）および垂直（Ｚ、図示せず）距離を計算してもよく、その結果、窓の着色は、占有領域への直射日光を防ぐように制御される。この実施例では、太陽の方位が示される臨界角Ｚ１およびＺ２の外側にある場合、その際、太陽のグレアは、デスクに座っている占有者によって画定された占有領域を照らす。インテリジェンスロジックは、空の太陽の位置を使用して、太陽の方位が臨界の天使の外側にあるときを判定し、それに応じて窓を着色することができる。

【0200】

図２３は、５つの着色ゾーンを有するマルチゾーンの着色可能な窓２３００を制御するために、インテリジェンスパラメータがどのように使用され得るかの一例を提供する。マルチゾーンの着色可能な窓２３００は、建物の内側と外側との間の部屋２３５０の外側垂直壁に配置されている。マルチゾーンの着色可能な窓２３００は、窓２３００の上部にある第１着色ゾーン２３０２と、第１着色ゾーン２３０２の下にある４つの他の着色ゾーン２３０４、２３０６、２３０８、および２３１０とを含む。図示の例では、太陽は空の高い位置にある。着色ゾーンは、第１の着色ゾーン２３０２が、第１の着色状態および最も明るい着色状態（例えば、漂白または透明状態）にあり、他の着色ゾーン２３０４、２３０６、２３０８、および２３１０が、第１の着色状態よりも暗い第２の着色状態にあるように制御される。示された着色制御構成では、第１の着色ゾーン２３０２は、直射日光からのグレアがデスクおよび占有者とともに占有領域に投射することを防ぎながら、高高度にある太陽からの自然光が部屋に入ることを可能にする。代わりに、第１の着色ゾーン２３０２を通る直射日光は、部屋の非占有領域にグレアを投射する（矢印で示される）。この図示の例では５つのゾーンが使用されているが、建物内の照明条件を制御するために、窓および／または着色ゾーンの数が異なる部屋構成をインテリジェンスによってどのように制御できるかを理解することができる。

【0201】

当業者であれば、上記の説明から、建物の構造体、窓の位置決め、占有領域の位置、および天気などの他のパラメータを使用して、占有領域における直射日光のグレア効果を低減するために、窓をいつ着色する必要があるかを判定することができる方法を容易に理解することができる。しばしば、インテリジェンスアルゴリズムは、図２１Ａ～図２１Ｃで識別されたパラメータの一部または全部、および図２２に示したような部屋内の占有領域の位置に基づいている。インテリジェンスパラメータを取得するために、これらの測定値は、設置者によって手動で取られるか、または建築図面からコピーされることがあり、その両方とも時間がかかりかつコストがかかる可能性がある。施設管理アプリケーションを使用して、パラメータを識別するプロセスは、自動化されてもよく、または少なくとも部分的に自動化されてもよい。

【0202】

一部の実施形態では、設置者は、施設管理アプリケーションを使用して、測定が手動で行われるとき、または建築図面からコピーされるときなど、窓パラメータを識別する手動プロセスを支持することができる。一部の場合に、設置者は、建物の視覚的な検査を実行することによって、または建築図面を参照することによって、インテリジェンスアルゴリズムに必要なパラメータを決定する。施設管理アプリケーションを使用することによって、設置者は、建物モデルをすばやくナビゲートして、モデルを１つまたは様々な視点から表示することにより、インテリジェンスパラメータを記録する必要がある場所をより簡単に見つけることができる。例えば、設置者は、空中の観点から建物モデルを見ることができ、それにより、設置者が関連パラメータをより明確かつ迅速に識別することを可能にする。一部の場合に、建物モデル内の特徴および表面は、特徴または表面が選択されたときに寸法情報を含む、その特徴の１つ以上の特性を表示することができる。一部の場合に、施設管理アプリケーションは、建物モデル上のユーザが選択した２点間で仮想測定値を取得できるように構成され得る。建物モデルを使用して得られた測定値は、手動測定値が得られるとき、またはパラメータが建築図面から得られるときにインテリジェンスパラメータを検証するために使用され得る。建物モデルが建物の特徴に対して正確な寸法（例えば、数センチメートル以内の正確さ）を有する場合、建物モデルは、物理的測定を必要とせずに直接的にインテリジェンスパラメータを提供することに依存することができる。

【0203】

一部の実施形態では、施設管理は、インテリジェンスパラメータを識別するプロセスを少なくとも部分的に自動化することができる。本明細書の他の箇所で論じられるように、建物モデル内の特徴は、建物モデル内でそれらを分類するために使用され得る、タグまたはメタデータを有し得る。例えば、図２１Ｃのフィン２１２０のように、建物の外側にフィンがある場合、フィンを表すモデル内の特徴は、それが窓開口部＃７２および＃７３に隣接し、西向きの面にあり、１階にあるなどのフィンであることを示すタグを有することができる。一部の場合に、最初の特徴が選択されると、オプションが提示され得、選択された場合、同じタグ（複数可）を有する対応する特徴についてのデータを表示または提供する。例えば、第１のフィンを選択した後、建物の外面にある他のフィンの一部または全部を識別または提供するオプションが、ユーザに提供され得る。同様に、窓開口部が選択されている場合、ユーザは、土台の高さ、凹部、または隣接するフィン／オーバーハング寸法などのインテリジェンスパラメータを表示または提供するためのオプションを提示され得る。

【0204】

一部の場合に、施設管理アプリケーションを使用して、インテリジェンスパラメータを識別および記録するプロセスを完全に自動化することができる。建物の外面の寸法データを有しているので、ロジックを使用して、図２１Ａ～図２１Ｃに示すようなパラメータのサブセットを自動的に計算することができる。次にアプリケーションは、設置者が検出されたパラメータを確認することを要求してもよい。この自動化された方法は、建物ジオメトリが複雑な場合にインテリジェンスパラメータを判定するプロセスを簡単にし得る。実例として、オーバーハングが、窓の幅（寸法（Ｂ）、図２１Ａ）にわたって一定ではない深さ（寸法（Ｅ）、図２１Ｂ）を有する場合、ロジックは、可変のオーバーハング深さを記述するためにインテリジェンスアルゴリズムによって使用され得る、関数または可能であればマトリクスを識別し得る。

【0205】

建物モデルが家具のレイアウトを含む場合には、図２１Ａ～図２１Ｃに示されるように、占有領域（例えば、デスクまたは休憩室のテーブル）の位置などの他のインテリジェンスパラメータもまた識別され得る。一部の場合に、アプリケーションは、窓インテリジェンスによる使用のために保存される前に、識別されたパラメータを確認するようにユーザに要求することができる。一部の場合に、施設管理アプリケーションは、ユーザが建物モデル内の占有領域を迅速に画定することを可能にする、ウィジェットを含み得る。例えば、ユーザは、グラフィカルユーザインターフェースに提示された平面図上に長方形の特徴を描くまたは配置して、Ｘ座標およびＹ座標を画定することができる可能性がある。ユーザはその際、一部の場合に、プルダウンメニューから領域の高さを画定するためのオプションを有し得る。施設管理アプリケーションが、（例えば、マイクロロケーションチップ、ＧＰＳ、磁力計、および／またはロケーションサービスに使用される他のセンサを使用して）デバイスの位置を自動的に判定することができるモバイルデバイス上で動作しているとき、ウィジェットは、モバイルデバイスの物理的位置に基づいて占有領域を画定するために、ユーザによって選択され得る。例えば、デスクトップを占有領域として定義するために、ユーザは、ウィジェットを使用して適切なアクションを選択した後に、単にモバイルデバイスをデスクトップの画定する端に配置し得、その後アプリケーションは、インテリジェンスアルゴリズムによって使用されるべきインテリジェンスパラメータを保存することができる。

【0206】

一部の場合に、ユーザは、施設管理アプリケーションを使用して、窓の現在の状態を迅速に見つけ、および／または窓のスマートオブジェクトのメタデータとして提供され得る、他の窓情報を検索することができる。一部の場合に、施設管理アプリケーションを使用して、窓ネットワーク上のデバイスを位置決めし、またはエラーのトラブルシューティングを行うことができる。例えば、アプリケーションは、３Ｄ建物モデル内の特徴としての非窓構成要素（例えば、窓コントローラ、ネットワークコントローラ、マスターコントローラ、コントロールパネル、配線など）を表示するように構成され得る。

【0207】

一部の場合に、フィールドシステムエンジニア（ＦＳＥ）が使用するときに、アプリケーションは、誤動作が検出された構成要素またはメンテナンスが必要な構成要素のリストを提示し得る。一部の場合に、表示されている建物モデル内でこれらの特徴がハイライト表示されたり、何らかの形でマークされたりし得ることで、ＦＳＥは注意が必要な場所を簡単に認識できる。通常、ＦＳＥは、誤動作しているデバイスがどこにあるのか、または相互接続図や建築図面で見ることができるかどうかを、施設管理者に問い合わせる必要がある。これは、誤動作している窓が現場の担当者によって気付かれなかったり、または誤動作しているデバイスが窓ネットワークを介して自己検出されたりした場合でも、空港や病院などの大規模な現場では厄介なプロセスとなり得る。ＦＳＥを楽にするために、アプリケーションは、問題となっている特定の構成要素への指示を提供することがある。例えば、アプリケーションは、施設システムエンジニアがとるべき経路を示す、建物の平面図にオーバーレイされた経路を表示することができる。一部の場合に、アプリケーションが、建物内に自動的に配置されているタブレットまたはモバイルデバイスで動作している場合などに、アプリケーションは、ＧＰＳナビゲーションシステムで使用されているターンバイターンの指示に似たターンバイターンの指示を提供し得る。ＦＳＥを誤動作しているデバイスに向けることに関して説明したが、アプリケーションはまた、アプリケーションの通常のユーザに使用され得る、地図および経路を提供することができる。一部の場合に、窓は、デバイスの位置を決めるために使用されるアンテナを有し得る。窓ネットワークを使用して位置検出およびユーザのルーティングを行う方法は、２０１７年５月４日に出願された、「ＷＩＮＤＯＷ ＡＮＴＥＮＮＡＳ」という名称のＰＣＴ特許出願第ＵＳ１７／３１１０６号にさらに記載されており、その全体が参照により本明細書に組み込まれる。

【0208】

窓ネットワーク上の構成要素を視覚化するためのアクセスを有することによって、ＦＳＥは、修理に役立つ情報を知ることができる。例えば、建物モデルに表示されているような構成要素を検査した（例えば、モデルのその部分へのズーミングを見ることによる）後、天井にある窓コントローラにアクセスするには梯子が必要であること、または乾式壁の後ろに隠されている窓コントローラにアクセスするには、特定のツールが必要であることを、ＦＳＥに認識させることができる。アプリケーションはまた、モデル番号、インストール日、インストールされたファームウェア、様々な接続デバイスなどの構成要素の技術的詳細、および使用パターンなどの他の技術的詳細、ならびにＦＳＥが問題を診断するのに役立ち得る履歴データ（例えば、特定のＩＧＵについての経時的なリーク電流）を表示し得る。建物モデルを詳細に見ることができる能力を有するため、フィールドシステムエンジニアは、修理を行うために準備された現場に到着することができ、他の点では、必要な材料またはツールを集めるために必要な余分な移動を潜在的に省くことができる。

【0209】

一部の実施形態では、フィールドシステムエンジニアは、施設管理アプリケーションを使用して、様々なフィルタを使用して設置済み構成要素を分類することができる。例えば、特徴がモデルに追加されると、それはインストール日、製造日、部品モデル番号、ＩＧＵのサイズ、コントローラのファームウェアなどの情報を含む、タグまたはメタデータを有する場合がある。この情報は、例えば、ＦＳＥが別のサービス要求の対応をするためにすでに現場にいるときに、予防的なメンテナンスを行うのに役立つ場合がある。例えば、ある期間内に製造されたいくつかの窓コントローラが、製造上の欠陥のために時期尚早の故障を起こす傾向があると判定された場合、ＦＳＥは、アプリケーション内に設けられたソート基準を使用して、問題のコントローラを識別できる場合がある。ＦＳＥは、その場合、問題が発生する前に問題のある構成要素を置き換えることができる。

【0210】

一部の場合に、施設管理アプリケーションは、１つ以上のデバイスが異常に動作しており、次回サービス要求を実行するためにＦＳＥが現場にいるときにＦＳＥによって検査されるべきであることを示す、警告を提供することができる。建物モデルを見るとき、要素は、それらの状態を示すために色分けされてもよい。例えば、正常に機能しているデバイスは緑色に着色され得、異常に機能しているデバイスは黄色に着色され得、および誤動作しているデバイスは赤色に着色され得る。例えば、１つ以上のコントローラが、それらに異常な電流または電圧が供給されていることを報告する場合、その際、配線を検査するように、ＦＳＥに依頼する警告が提供されてもよい。ＦＳＥは、最初に建物モデルを調べて、この情報を見つけることによって、設置されている配線が適切であり、他の現場で問題が発生していないことを確認できる可能性がある。一部の場合に、建物モデルによって提供される情報で問題を診断するのに十分な場合があるが、それ以外の場合は、手動による検査が依然として必要な場合がある。例えば、ＦＳＥは、誤った配線が取り付けられたこと、または絶縁が失敗して、ワイヤーが損傷したことを発見する可能性がある。

【0211】

施設管理アプリケーションはまた、サービス要求に応答するときに、ＦＳＥがメモおよび観察された製造上の欠陥を文書化できるように構成されてもよい。例えば、ＦＳＥが、構成要素に欠陥があることに気付いた場合（例えば、ＩＧＵに報告されていないピンホール欠陥がある場合）、ＦＳＥは、モバイルデバイスで写真を撮ることによって欠陥を文書化し、それは窓製造業者に報告され得る。次に、複数の現場から収集された欠陥文書を使用して、製造プロセスにおける問題の原因を特定することができる。一部の場合に、ＦＳＥが建物モデルに示されている構成要素との不一致に気付いた場合（例えば、誤った構成要素が設置された場合、または破損した構成要素が交換された場合）、アプリケーションは、ＦＳＥが建物モデル情報を更新して、物理的に設置されたシステムを正確に反映することを可能にする。

【0212】

図２４は、施設管理アプリケーションがユーザモードで動作しているときに、施設管理アプリケーションによって使用され得る例示的なプロセスを提供する。アプリケーションがユーザによって開かれ、またはアクセスされると、アプリケーションは、窓ネットワークから（例えば、マスターコントローラとの通信を介して）、現在の着色状態を要求し得る２４０２。一部の場合に、現在の着色状態は、窓に新しい制御信号が与えられるたびに更新されるネットワーク構成ファイルから検索されてもよい。一部の場合に、現在の着色状態は、建物モデルファイルのメタデータ内に保存されることがある。ビューアモジュールは、次に、電子デバイス上に提示されるグラフィカルユーザインターフェース内に、３Ｄ建物モデルおよびスマートオブジェクトを表示するために使用される２４０４。１つ以上のスマートオブジェクトの選択を受信する２４０６と、アプリケーションは、（例えば、ネットワーク構成ファイルを参照することによって、）どのＩＧＵ、ゾーン、または他の窓ネットワーク構成要素が選択されたかを識別する。対応する窓構成要素を識別すると、アプリケーションは次に、ユーザに利用可能な様々な制御オプションを表示する２４１０。例えば、窓が選択されている場合、アプリケーションは、現在の着色状態を調節したり、または新しいルールを確立したりするためのオプションを表示することができる。選択されたＩＧＵまたはＩＧＵのゾーンを制御するためのユーザ命令を受信する２４１２と、施設管理アプリケーションは、窓ネットワーク上のマスターコントローラに、対応する制御命令を送信する２４１４。ユーザの指示を実行すると、施設管理アプリケーションは、次に、着色調節が進行中であることを表示し得る２４１６。一部の場合に、アプリケーションは、調節された着色状態を要求したユーザを表示し得、調節が完了するまでにかかる時間の見積もりを提供する。一部の場合に、調節された着色状態は、建物モデルファイルのメタデータ内に保存される。

【0213】

図２５は、施設管理アプリケーションを構成モードで使用することができるプロセスを提供する。ステップ２５０２において、３Ｄ建物モデルが取得または生成される。次に、建物モデルは、その建物モデルを施設管理アプリケーションによる使用に適したものにするために、ポストプロダクション２５０４を受けることができる。例えば、建物モデルは、建物管理アプリケーションのビューアモジュールによって、読み取り可能なフォーマットで保存されてもよく、または光学的に切り替え可能なネットワークの制御に関連しない情報を削除することによって、簡略化されてもよい。窓ネットワークの特徴に対応する建物モデル内のノードＩＤは、次に、それらの対応するネットワークＩＤにマッピングされる２５０６。例えば、これは、試運転ロジックを使用して自動的に行われてもよく、またはアプリケーションの設定モードを使用して、マッピングを実行するユーザによって行われてもよい。このマッピングが行われると、施設管理アプリケーションは、窓ネットワーク上の光学的に切り替え可能な窓を制御するためのユーザコマンドを受信するために使用される２５０８。例えば、ユーザは、ＩＧＵの着色状態を調節するため、または着色ルールまたは着色スケジュールを確立するためのアプリケーションに、コマンドを提供することができる。ユーザ入力から着色コマンドを受信すると、着色命令は、次に、窓ネットワーク上のマスターコントローラまたは別のコントローラに提供される２５１０。

【0214】

一部の実施形態では、施設管理アプリケーションはまた、建物内の他のデバイスおよびシステムを制御するために使用される。施設管理アプリケーションを使用して、ユーザが光学的に切り替え可能な窓を手動で制御することができるインターフェースを提供するのと同様の手段において、アプリケーションはまた、機械式ブラインド、照明システム、およびセキュリティシステムに関連する情報を制御および／または受信する能力を、ユーザに提供し得る。例えば、建物がドアを電子的にロックするネットワークで構成されている場合、施設管理アプリケーションを使用して、ドアを選択的にロックおよびロック解除し、ならびに／または他のユーザが同じことをするためのルールを確立することができる。一部の場合に、アプリケーションによって制御され得る他のデバイスおよびシステムは、窓ネットワーク上に配置され、一部の場合に、それらは、アプリケーションを実行している電子デバイスを介してアクセス可能な別のネットワーク（例えば、ローカル無線ネットワーク）上に配置される。

【0215】

設計モジュール：
一部の場合に、施設管理アプリケーションは、アプリケーションを建物内の窓ネットワークのレイアウトを設計するために使用することを可能にする構成モード内で実行可能な設計モジュールを有することができる。一部の場合に、設計者は、検査のために物理的建物を訪れる必要なく、窓ネットワークを設計することができる。例えば、設計モジュールを介して建物モデルを検査することによって、設計者は、仮想測定を行い、設計モジュール内のツールを使用して、年間の様々な時期での建物内への光の浸透を理解することができる。従来の設計プロセスでは、設計エンジニアは、まず建築図面を考慮して、建物のレイアウトを理解することから始める。建物の構造体を理解していれば、設計者はその際、物理的な設置の指示書として設置者が使用できる、２Ｄ設置概略図を作成することができる。設計プロセスは面倒であり、不正確な図面、建築図面の誤読、および設計者による設計ルールの考慮の忘れやすさの結果として、エラーが発生する可能性がある。設計モジュールを使用することによって、窓ネットワークを設計し、設置を完了するためのタイムラインは、本明細書で論じられる理由のために促進され得る。

【0216】

特定の実施形態では、設計モジュール内では、設計者は、建物モデルに挿入され得るオブジェクトまたは特徴のライブラリへのアクセスを有する。これらのオブジェクトまたは特徴は、窓、窓コントローラ、ネットワークコントローラ、マスターコントローラ、センサ、配線、ならびに電力および通信用の回路を含む様々な窓ネットワーク構成要素と、窓ネットワーク上のいくつかのその他のデバイスとを表す。オブジェクトのライブラリはまた、設置中に必要とされ得る構造的構成要素（例えば、コントローラ用のデバイスの取り付け、配線など）を含む、窓ネットワークがインターフェースすることができる構造体および／または構成要素を含み得る。一部の実施形態では、建物モデルに追加される窓ネットワークの構成要素は、本明細書の他の箇所で論じるように、光学的に切り替え可能な窓のネットワークを制御するためのグラフィカルユーザインターフェースの一部分として後で使用されるスマートオブジェクトとともにインポートされ得る。

【0217】

設計モジュール内では、ライブラリからの構成要素を容易に選択して、建物モデルにインポートすることができる。一部の場合に、設計モジュールは、特定の用途に適した構成要素を自動的に選択または提案し、仮想測定を可能にし、および設計ルールを施行するかまたは設計ルールが破られたときに警告を提供することによって、設計プロセスを支援し得る。

【0218】

図２６Ａ～図２６Ｄは、窓ネットワークの特徴を建物モデルに追加するために設計モジュールをどのように使用することができるかを示す。これらの図は、窓２６１０を部屋２６００内に配置し、電力を供給して窓ネットワーク上の通信を提供するためにトランクライン２６０５を介して窓ネットワークの残りの部分に接続する方法を設計するときに、グラフィカルユーザインターフェースによって表示され得るステップの進行を示す。設計モジュールを使用して窓ネットワークの様々な特徴を設計するために、図２６Ａ～図２６Ｄに示すものと同様のプロセスを使用することができる。

【0219】

図２６Ａは、窓開口部２６０１を有する部屋２６００を示す、設計モジュール内のグラフィカルユーザインターフェースを示す。描かれている状況は、窓ネットワークのいくつかの側面がすでに設計されているものであるが、部屋にどのように光学的に切り替え可能な窓を装備し、窓ネットワークの残りの部分に接続するかはまだ判定されていない。図示の例では、部屋の壁内でのトランクライン２６０５の配置は既に判定されている。この実施例では、トランクラインは、例えば、建物内の別の電気経路をたどるように配置されていてもよい。一部の実施形態では、ユーザは、建物モデル内で開口部２６０１にナビゲートして、それを選択することによって、開口部２６０１を手動で識別することができ、一部の場合に、窓開口部は、設計モジュールによって自動的に識別され得る。建物モデルに含まれる寸法情報から、設計モジュールは、選択された窓開口部に適切であり得る、窓タイプの選択を提供し得る。例えば、設計モジュールは、単一の窓ガラスもしくは二重の窓ガラスのオプション、または窓が複数の着色ゾーンを持つためのオプションを提供することができる。一部の場合に、設計モジュールは、設計者によって後で変更され得る、特定の窓オプションを自動的に選択または提案することができる。改築用途において、設計モジュールは、建物の構造的完全性を損なうことなく、窓開口部を壁から切り取ることができる場所を示すことができる。

【0220】

図２６Ｂは、窓オブジェクト２６１０が窓開口部２６０１に対して選択されたときの、図２６Ａに示した段階の後の段階を示す。一部の場合に、窓２６１０などの構成要素が選択された後、設計モジュールは、選択された構成要素を窓ネットワークの残りの部分と結合するのに必要となる可能性がある、窓ネットワーク構成要素を表す追加的なオブジェクトをインポートし得る。例えば、図２６Ｂでは、窓コントローラ２６１５、単線バス２６１２、ドロップライン２６２０、およびトランクライン－Ｔ２６２５のオブジェクトは、これらの構成要素を使用して、窓２６１０をトランクライン２６０５に結合し得るのにつれて、建物モデルに自動的にインポートされる。示されるように、オブジェクト２６１２、２６１５、２６２０、および２６２５は、最初は窓２６１０内にサブオブジェクトとして配置される。他の実施形態では、設計モジュールは、すでに追加された構成要素を窓ネットワークの残りの部分に接続するために必要な構成要素を追加することを、ＧＵＩインターフェースを介して簡単に提案することができる。例えば、窓オブジェクトを窓開口部内に配置した後、設計モジュールは、対応する窓コントローラを追加するためのオプションを設計者に提示することができる。

【0221】

オブジェクトが建物モデル内に配置されるとき、それらは、以下でさらに詳細に説明されるように、設計ルールを実施するために使用され得る結合点２６３０を有し得る。示されるように、窓２６１０は、窓の位置を開口部２６１０に固定する結合点を有する。この結合点は、ピグテールコネクタに関する位置をさらに示し、エレクトロクロミック窓は、それを通じて電力を受信することができる。

【0222】

図２６Ｃは、窓コントローラ２６１５の配置が選択された、図２６Ｂに示される段階の後の段階を示す。窓コントローラを表すオブジェクト上の結合点２６３０は、窓コントローラの配置を制限するルールを有することができる。例えば、ルールは、窓２６１０上の電気コネクタ（例えば、ピグテールコネクタ）を表す結合点から対応する結合点までの距離を、５フィート未満に制限することができる。このルールは、物理的に設置されたオブジェクトを接合するのに使用される単線バスケーブル２６１２または他の配線の十分な長さを確実にするように、設計モジュール内で確立され得る。一部の実施形態では、ユーザは、例えば、オブジェクトを選択された位置にドラッグすることによって、その配置を選択することができる。他の場合には、設計モジュールは、自動的に配置位置を提案することができる。

【0223】

図２６Ｄは、図２６Ｃに示した段階の後の段階を示し、窓２６１０は、トランクライン２６０５および窓ネットワークの残りの部分に電気的に結合されている。トランク－Ｔ２６２５が配置されるトランクライン２６０５に沿った位置は、設計モジュールロジックによって自動的に選択されてもよく、または一部の場合に、設計者によって手動で選択されてもよい。トランクＴの結合点と窓コントローラとの間のルールは、例えば、２つの構成要素が特定の長さを有するドロップライン２６２０によって結合されることを要求し得る。一部の場合に、設計モジュールは、トランクＴを窓コントローラに接続する必要がある、例えば、ドロップライン２６２０に必要なケーブルの長さを短くする、位置を提案することができる。一部の場合に、設計モジュールは、設計者が、ドロップラインまたは他の配線が２つの結合点の間を通る経路を調節することができるように構成され得る。

【0224】

図２６Ａ～図２６Ｄで説明したように、ライブラリから建物モデルにインポートされた窓ネットワーク構成要素用のオブジェクトは、設計ルールを実施するために使用される、関連付けられた結合点（図２６Ｄの２６３０参照）を有することができる。結合点は、建物モデルにオブジェクトを固定することができ、建物モデル内の２つ以上のオブジェクトを結合することができる。結合点に適用される設計ルールは、設置時にネットワークが機能することを確実にし、完全に手動の設計プロセス中に行われた間違いや見落としに起因する設置中の遅延を防ぐのに役立ち得る。結合点に関連する設計ルールの例を次に説明する。

【0225】

インターフェースルール－結合点は、設計者が、物理的に接続できない部品（例えば、２つの雌型コネクタプラグ）が建物モデル内で接続されることを特定することを妨げるルールを有し得る。このタイプのインターフェースチェックは、窓コントローラとトランクラインとの間の誤ったタイプのケーブル接続、または特定の位置の誤ったタイプのコントローラが設置回路図で特定されていることを含む状況を防ぐ。

【0226】

寸法ベースのルール－いくつかの結合点は、建物モデルに配置されたオブジェクト間の距離を制限する寸法ベースのルールを有し得る。設計モジュールは、建物モデルからの寸法情報を使用してオブジェクト間の距離をチェックすることによって、寸法ベースのルールを実施することができる。一部の場合に、窓コントローラと窓との間の結合点（または単線バスケーブルの両端上の等価的な結合点）は、例えば、単線バスケーブルが全て固定長になるように製造される場合、最大分離距離を列挙することができる。同様に、ドロップラインなどのスプールケーブルに関連する結合点は、配線の電気的性能がそれが長すぎて損なわれる場合に、結合点間の最大許容距離を設定し得る。

【0227】

配置ルール－結合点を使用して、構成要素を建物モデルに固定するときに、結合点を配置できる場所が、ルールによって制限されることがある。例えば、ビルディングコードまたはファイヤコードがビルディング内の窓ネットワーク構成要素の配置に制限を課す場合、結合点ルールは、コードに違反する場所へのオブジェクトの配置を妨げる可能性がある。一部の場合に、ルールは、窓コントローラを、ドアなどの移動可能な表面または乾式壁などの壊れやすい建物の特徴ではなく、鋼鉄製の梁やコンクリートの柱などの剛直な建物の特徴に取り付けることを要求する場合がある。別の例として、ルールは、美的な理由からコントローラを天井または壁の中に配置するように特定し得る。

【0228】

技術的なルール－時には、構成要素の技術的な制限を構成するためのルールが使用され得る。例えば、窓コントローラが４つまでの窓を制御する能力のみを有する場合、窓コントローラに関連する結合点は、５番目の窓がコントローラに接続されるのを妨げ得る。同様に、トランクラインに関連付けられた結合点は、接続によってトランクラインがその電流定格を超えることになる場合、追加の窓がトランクラインに接続されるのを防ぐことができる。

【0229】

ユーザ定義ルール－一部の場合に、設計者は、建物全体で一貫した窓ネットワーク実装を作成するためにユーザ定義ルールを確立することができる。一実施例として、ユーザは、各窓が窓の真上の天井に配置された関連付けられた窓コントローラを有するべきであるというルールを作成することができる。一部の場合に、（手動または自動のいずれかで）窓が開くために窓が選択された後、設計モジュールは、窓コントローラを窓の上の天井に自動的に配置し得る。設計者が自動化した配置に満足していない場合、その際、設計者は、設計ルールが満たされるという条件で配置を調節することができる。

【0230】

警告－一部の場合に、設計者が設計ルールに違反した、または設計ルールに違反しそうになったときに、設計ルールは、グラフィカルユーザインターフェースを通じて提供される警告を誘発し得る。例えば、窓コントローラを接続する単線バスの長さが５フィートに固定されている場合、設計者が窓コントローラを関連付けられた窓から４フィートより多く離して配置すると、警告が表示され得る。設置プロセス中に余裕を持たせる可能性がある控えめな設計を生成するように設計者を奨励するために、警告が役立つ場合がある。例えば、設置者が、配線を設置することが特徴の前に置かれる代わりにその特徴の周りにくるようにすることがより簡単であるか、または必要であることを発見した場合、その際、設置者はそのようにする自由を有することができる。

【0231】

一部の実施形態では、設計モジュールは、建物モデルに窓ネットワーク構成要素のためのオブジェクトを自動的に加えるように構成され得る。例えば、建物モデルをインポートした後、設計モジュールはまず、窓開口部を認識し、各窓開口部に対して、適切な窓オブジェクトを選択することができる。窓オブジェクトを選択した後、設計モジュールは、設計ルールが実行されるように、建物モデルに、他の窓構成要素（例えば、窓コントローラ、ネットワークコントローラ、コントロールパネル、センサ、電力および通信用の配線など）を自動的に追加することができる。一部の実施形態では、設計モジュールは、材料費または設置費を最小にするような手段で、建物モデルを自動的に追加することができる。例えば、設計モジュールは、必要最小限の量のコントローラが必要とされるように、最小量のケーブル接続が使用されるように、または設置プロセスが、（例えば、コントローラおよび配線を壁の外面に取り付けることによって）最も単純にされるように、建物モデルを自動的に追加することができる。一部の場合に、設計者は建物モデルを自動的に追加し、その後、設計者は、窓ネットワーク設計を調節して、顧客の特別な考慮事項、または考慮されない可能性があるが設計モジュールロジックの考慮事項を考慮し得る。

【0232】

一部の場合に、設計モジュールは、建物情報モデル（ＢＩＭ）を修正することができる場合がある。建物情報モデルは、施設の物理的および機能的特徴のデジタル表現である。ＢＩＭは、建物のライフサイクル中に下された決定を導くために使用され得る、共有知識リソースを提供する。一部の場合に、設計モジュールで使用される３Ｄ建物モデルとそれに関連するメタデータは、他の建物用途にも使用されるＢＩＭである。一部の場合に、窓ネットワークが設計された後、窓ネットワーク構成要素を含む建物モデルは、建物のライフサイクルの間に将来の決定を下すために建物の所有者によって使用され得る、更新されたＢＩＭモデルとして保存される。

【0233】

一部の場合に、窓ネットワークが設計された後、施設管理アプリケーションは、窓ネットワークを制御するためのグラフィカルユーザインターフェースを構成するように、設計者を促してもよい。一部の場合に、建物モデルに窓ネットワークオブジェクトを追加するときに、対応するスマートオブジェクトがまた、建物モデルに追加され、後でユーザモードで窓ネットワークを制御するために使用され得る。

【0234】

一部の場合に、設計モジュールは、光学的に切り替え可能な窓のネットワークを設置することの１つ以上の効果を要約する、報告を出力することができる。例えば、設計モジュール内のロジックは、光学的に切り替え可能な窓のネットワークを実装することによってもたらされ得る、エネルギー節約を推定し得る。これは、例えば、建物モデルを使用し、建物内のＨＶＡＣおよび照明システムにおける現在のエネルギー使用パターンを考慮して、年間を通して建物内への太陽光束を推定することによって行われ得る。報告はまた、設置のための予想コスト、設置のための予想時間、投資時間フレームの予想される収益率、ならびに（本明細書の他の箇所で論じたように）スマートオブジェクトを使用して光学的に切り替え可能な窓ネットワークを制御するために、建物モデルを使用して生成されたＧＵＩからの例示的ビューなどの情報を提供し得る。一部の場合に、設計モジュールは、単に建物モデルをインポートし、建物モデルに窓ネットワーク構成要素を自動的に加えることに基づいてＢＯＭを生成することによって、窓ネットワークを設置するための概算の推定を提供するために使用され得る。

【0235】

設計モジュールは窓ネットワークの設計について説明されているが、一部の実施形態では、設計モジュールは、通信ネットワーク（例えば、イーサネット（登録商標）ネットワーク）、照明ネットワーク、低電圧電子装置用ネットワーク、および任意の他の建物システムなど、他のシステムが建物内でどのように実装されるかを設計するために使用され得る。

【0236】

建物モデルに窓ネットワークオブジェクトを加えた後、設計モジュールは、設置プロセス中に使用される様々な出力を提供するように構成され得る。例えば、設計モジュールは、窓ネットワークを設置するのに必要な原材料、サブアセンブリ、中間アセンブリ、サブ構成要素、部品および各々の数量の全てを列挙する、材料表（ＢＯＭ）を自動的に生成することができる。一部の場合に、設計モジュールは、必要な構成要素についての価格設定および入手可能性情報を自動的に収集することができる。一部の場合に、設計モジュールは、生成されたＢＯＭに基づいて、窓ネットワークをインストールするための推定コスト、または／および設置時間フレームを自動的に生成することができる。

【0237】

設計モジュールは、一部の場合に、３Ｄ建物モデルを使用して生成された設計から、２Ｄ設置概略図および図面を生成するように構成され得る。例えば、設計モジュールは、設置者が設計を正しく実施するために必要な情報で適切にラベル付けされた、図５Ａおよび図５Ｂに示された相互接続図と同様の図を自動的に生成するように構成され得る。設置概略図の自動的な生成は、設置概略図の従来の製図中に頻繁に生じるコストおよびエラーを減らすことができる。

【0238】

図２７は、設計者が窓ネットワークを設計するために使用することができる方法２７００を示す。ステップ２７０２において、建物モデルが施設管理アプリケーションの設計モジュールにロードまたはインポートされる。一部の場合に、設計モジュールは、設置されている施設管理アプリケーションに対する拡張機能またはプラグインであり得るか、または一部の場合に、施設管理アプリケーションの残りの部分とは別に動作し得る。一部の場合に、窓ネットワークオブジェクトのライブラリを含む設計モジュールの態様が、Ａｕｔｏｄｅｓｋ ＲｅｖｉｔなどのＣＡＤソフトウェアアプリケーションのプラグインとして使用され得る。ステップ２７０４において、設計モジュールによって実施されることになる設計ルールが判定される。一部の場合に、設計ルールは、設計モジュールによってアクセスされる構成要素のライブラリからのオブジェクトに関連付けられ、編集することはできない。警告を誘発するためのルールなどのいくつかの設計ルールは、設計者によって編集または調節されてもよい。一部の場合に、設計者は、完成した設計の一貫性を向上させるために特定の結合点またはオブジェクトに対して一連のルールを課したり、または設計モジュールが建物モデルに窓ネットワーク構成要素のオブジェクトをどのように自動的に加えるかを判定したりすることができる。ステップ２７０６において、建物モデルに、窓ネットワーク構成要素を表すオブジェクトが加えられる。これらのオブジェクトは、設計ルールに従って、建物内のオブジェクトの配置を制限する結合点で互いにインターフェースする。一部の場合に、建物モデルにオブジェクトを加えることは、適切な窓オブジェクトを配置する場所を判定し、次に必要に応じて追加のオブジェクトを配置して、機能性窓ネットワークに対応する結合点で結合されたオブジェクトのネットワークを作成する、設計モジュール内のロジックによって自動化できる。一部の場合に、建物モデルに加えることは部分的に自動化されていてもよく、例えば、ユーザは、光学的に切り替え可能な窓をどこに配置するかを選択し、設計モジュールは、他の構成要素の配置を判定することができる。一部の場合に、建物モデルに加えることは、主に手動のプロセスであってもよい。ステップ２７０８において、設計者は建物モデル内のオブジェクトの配置を調節することができる。例えば、設計者が建物モデルにオブジェクトを自動的に加える方法に満足していない場合、設計者は、オブジェクトの位置および／またはそれらに関連する結合点を調節することができる。建物モデル内のオブジェクトの配置を判定した後、ステップ２７１０において、設計モジュールを使用して、様々な出力を自動的に生成することができる。一部の場合に、設計モジュールは、材料表（ＢＯＭ）または設置概略図を自動的に生成してもよい。一部の場合に、設計モジュールは、建物の所有者が後で維持、改築、およびその他の建物関連の決定を下すために使用できる、建物情報モデル（ＢＩＭ）を作成または更新してもよい。一部の場合に、設計モジュールを使用して、光学的に切り替え可能な窓ネットワークを設置することによる様々なコストおよび利点を判定することができる報告を、自動的に生成することができる。一部の場合に、設計モジュールを使用して、設計された窓ネットワークを制御するためのグラフィカルユーザインターフェースを生成することもできる。

【0239】

［結論］
理解を明確にするために前述の実施形態をある程度詳細に説明してきたが、添付の特許請求の範囲の範囲内で特定の変更および修正を実施できることは明らかであろう。本実施形態のプロセス、システム、および装置を実装する多くの代替手段があることに留意されたい。したがって、本実施形態は、限定的ではなく例示的であると見なされるべきであり、実施形態は、本明細書で与えられる詳細に限定されるべきではない。
［項目１］
光学的に切り替え可能な窓のネットワークＩＤを、建物内の上記光学的に切り替え可能な窓の設置位置と関連付ける方法であって、複数の光学的に切り替え可能な窓の各々が、ネットワークＩＤと、無線通信用に構成された送信機と、を有し、上記方法は、
（ａ）上記建物の１つ以上の図面または他の表現を受信することであって、上記１つ以上の図面または他の表現が、上記建物内または上記建物上の上記複数の光学的に切り替え可能な窓の位置を提供する、受信することと、
（ｂ）上記複数の光学的に切り替え可能な窓のうちの少なくとも１つの上記送信機から無線通信信号を受信することであって、上記無線通信が、上記少なくとも１つの光学的に切り替え可能な窓の上記ネットワークＩＤを含む、または識別する、受信することと、
（ｃ）上記受信された無線通信信号を分析して、上記少なくとも１つの光学的に切り替え可能な窓の上記位置を判定することと、
（ｄ）（ｃ）で判定された上記位置と、（ａ）で受信された上記１つ以上の図面または他の表現からの上記複数の光学的に切り替え可能な窓のうちの少なくともいくつかの上記位置とを比較し、上記少なくとも１つの光学的に切り替え可能な窓の上記ネットワークＩＤを、上記１つ以上の図面または他の表現に提供された１つの位置と関連付けることと、を含む、方法。
［項目２］
上記複数の光学的に切り替え可能な窓の各々の上記送信機が、上記光学的に切り替え可能な窓上、またはその中にある、項目１に記載の方法。
［項目３］
上記光学的に切り替え可能な窓が、エレクトロクロミックデバイスを備えた断熱ガラスユニットである、項目１または２に記載の方法。
［項目４］
上記無線通信信号が、パルスベースの超広帯域、ブルートゥース（登録商標）、ＢＬＥ、およびＷｉ－Ｆｉ（登録商標）からなる群から選択される無線プロトコルに準拠する、項目１から３のうちいずれか１項に記載の方法。
［項目５］
上記無線通信信号が、パルスベースの超広帯域プロトコルに準拠する、項目４に記載の方法。
［項目６］
上記無線通信信号が、ＥＣＭＡ－３６８またはＥＣＭＡ－３６９に準拠する、項目５に記載の方法。
［項目７］
上記１つ以上の図面または他の表現が、建築図面または相互接続図を含む、項目１から６のうちいずれか１項に記載の方法。
［項目８］
上記ネットワークＩＤがＣＡＮ ＩＤである、項目１から７のうちいずれか１項に記載の方法。
［項目９］
上記少なくとも１つの光学的に切り替え可能な窓の上記ネットワークＩＤと、上記１つ以上の図面または他の表現に提供された上記１つの位置の（ｄ）からの上記関連付けを格納することをさらに含む、項目１から８のうちいずれか１項に記載の方法。
［項目１０］
（ｄ）からの上記関連付けを格納することが、ネットワーク構成ファイル内に（ｄ）からの上記関連付けを格納することを含む、項目９に記載の方法。
［項目１１］
上記ネットワーク構成ファイルが、マスターコントローラ、ネットワークコントローラ、遠隔無線デバイス、およびクラウドからなる群から選択される場所にあるメモリに格納される、項目１０に記載の方法。
［項目１２］
上記送信機が、上記窓に取り付けられた窓コントローラ上に配置されたアンテナを備える、項目１から１１のうちいずれか１項に記載の方法。
［項目１３］
上記窓コントローラが、パルスベースの超広帯域通信信号を発行するように構成されている、項目１２に記載の方法。
［項目１４］
上記送信機がマイクロロケーションチップの部分である、項目１から１３のうちいずれか１項に記載の方法。
［項目１５］
上記マイクロロケーションチップが、約１０センチメートル以下の範囲内でのマイクロロケーションチップの位置の識別を可能にする様式で、上記無線通信信号を送信するように構成される、項目１４に記載の方法。
［項目１６］
（ａ）における上記１つ以上の図面または他の表現が、１つ以上の非窓構成要素の位置をさらに含み、上記１つ以上の非窓構成要素が、ネットワークＩＤと、無線通信のための送信機と、を有し、上記方法は、
少なくとも１つの非窓構成要素の上記送信機から無線通信信号を受信することであって、上記無線通信が、上記少なくとも１つの非窓構成要素の上記ネットワークＩＤを含む、受信することと、
上記受信された無線通信信号を分析して、上記少なくとも１つの非窓構成要素の上記位置を判定することと、
上記少なくとも１つの非窓構成要素の上記判定された位置を、（ａ）における上記１つ以上の図面または表現によって提供された上記１つ以上の非窓構成要素の上記位置と比較し、上記少なくとも１つの非窓構成要素の上記ネットワークＩＤを、上記１つ以上の図面または他の表現で提供された１つの位置と関連付けることと、をさらに含む、項目１から１５のうちいずれか１項に記載の方法。
［項目１７］
上記少なくとも１つの非窓構成要素が、窓コントローラネットワークのマスターコントローラまたはネットワークコントローラである、項目１６に記載の方法。
［項目１８］
光学的に切り替え可能な窓のネットワークＩＤを、建物内の光学的に切り替え可能な窓の設置位置と関連付けるためのシステムであって、複数の光学的に切り替え可能な窓の各々が、ネットワークＩＤと、無線通信用に構成された送信機と、を有し、上記システムは、
建物内または建物上の位置に設置され、送信機を有する、複数の光学的に切り替え可能な窓を含む、窓ネットワークと、
以下の動作：
（ａ）上記建物の１つ以上の図面または他の表現を受信することであって、上記１つ以上の図面または他の表現が、上記建物内の上記複数の光学的に切り替え可能な窓の上記位置を提供する、受信すること、
（ｂ）上記複数の光学的に切り替え可能な窓のうちの少なくとも１つの上記送信機から無線通信信号を受信することであって、上記無線通信が、上記少なくとも１つの光学的に切り替え可能な窓の上記ネットワークＩＤを含む、または識別する、受信すること、
（ｃ）上記受信された無線通信信号を分析して、上記少なくとも１つの光学的に切り替え可能な窓の上記位置を判定すること、および
（ｄ）（ｃ）で判定された上記位置と、（ａ）で受信された上記１つ以上の図面または他の表現からの上記複数の光学的に切り替え可能な窓のうちの少なくともいくつかの上記位置とを比較し、上記少なくとも１つの光学的に切り替え可能な窓の上記ネットワークＩＤを、上記１つ以上の図面または他の表現に提供された１つの位置と関連付けること、を実行するように構成されたコミッショニングロジックと、を備える、システム。
［項目１９］
上記光学的に切り替え可能な窓の各々の上記送信機が、パルスベースの超広帯域、ブルートゥース、ＢＬＥ、およびＷｉ－Ｆｉ（登録商標）からなる群から選択される無線プロトコルを使用して、無線通信するように構成される、項目１８に記載のシステム。
［項目２０］
上記光学的に切り替え可能な窓の各々の上記送信機が、パルスベースの超広帯域プロトコルを使用して、無線通信するように構成される、項目１８または１９に記載のシステム。
［項目２１］
上記光学的に切り替え可能な窓の各々の上記送信機が、ＥＣＭＡ－３６８またはＥＣＭＡ－３６９を使用して、無線通信するように構成される、項目２０に記載のシステム。
［項目２２］
上記窓ネットワークが、ネットワークＩＤと、無線通信のための送信機と、を有する非窓構成要素をさらに備え、上記コミッショニングロジックが、以下の動作：
少なくとも１つの非窓構成要素の上記送信機から無線通信信号を受信することであって、上記無線通信が、上記少なくとも１つの非窓構成要素の上記ネットワークＩＤを含む、受信することと、
上記受信された無線通信信号を分析して、上記少なくとも１つの非窓構成要素の上記位置を判定することと、
上記少なくとも１つの非窓構成要素の上記判定された位置を、（ａ）における上記１つ以上の図面または表現によって提供された上記非窓構成要素の上記位置と比較し、上記少なくとも１つの非窓構成要素の上記ネットワークＩＤを、上記１つ以上の図面または他の表現で提供された１つの位置と関連付けることと、を実行するようにさらに構成される、項目１８から２１のうちいずれか１項に記載のシステム。

【図1】

【図2A】

【図2B】

【図2C】

【図3】

【図4A】

【図4B】

【図5A】

【図5B】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21A】

【図21B】

【図21C】

【図22】

【図23】

【図24】

【図25】

【図26A】

【図26B】

【図26C】

【図26D】

【図27】