(57)【要約】  クラウドネットワーク上に維持されている、建築現場の晴天モデルに基づいて、建物の窓の１つまたは複数のゾーンの色付けを制御するためのシステム。【選択図】図８Ａ
2021518498.tif 000002
【特許請求の範囲】
【請求項１】
建築現場のグレアおよび反射モデルからの出力に基づいて、建物の色合い調節可能な窓の各ゾーンの色合いレベルを判定する方法であって、前記方法が、
前記建築現場の３Ｄモデルに対して属性を初期化し、かつ割り当てることと、
前記３Ｄモデルにおいて、１つまたは複数の３次元占有領域を生成することと、
前記３Ｄモデルに基づいて、前記グレアおよび反射モデルを生成することと、
晴天のグレアまたは反射モデルにおける各ゾーンの色合い調節可能な窓を通る３次元光投射と、３次元占有領域との交差を判定することと、
前記判定された交差に基づいて、１つまたは複数の条件が存在するかどうかを評価することと、
前記評価に基づいて、各ゾーンの色合い状態を判定することと、を含む、方法。
【請求項２】
前記３Ｄモデルが、クラウドベースの３Ｄモデリングプラットフォーム上に存在する、請求項１に記載の方法。
【請求項３】
各時間間隔で各ゾーンの色合い状態を有するスケジュールデータを前記建物のマスタコントローラにプッシュすることをさらに含み、前記マスタコントローラが、前記スケジュールデータからの前記色合い状態の最小値に基づく各ゾーンの最終的な色合い状態と、赤外線センサの読み取り値および光センサの読み取り値のうちの一方または両方に基づく気象ベースの色合い状態と、を設定する、請求項１または２に記載の方法。
【請求項４】
少なくとも１人の顧客を含む１人または複数のユーザからの入力に基づいて、前記３Ｄモデルをカスタマイズすることをさらに含む、請求項１から３のいずれか一項に記載の方法。
【請求項５】
前記建築現場の前記３Ｄモデルを初期化することが、前記建築現場における前記建物および周辺物体の建築図面から前記３Ｄモデルを自動的に生成することを含む、請求項１から４のいずれか一項に記載の方法。
【請求項６】
建築図面から前記３Ｄモデルを自動的に生成することが、
前記建築図面から前記建物の壁、床、および外面以外のすべてを取り除くことと、前記建築現場における前記建物を取り巻く物体の外面を構築することと、を含む、請求項５に記載の方法。
【請求項７】
前記３Ｄモデルに属性を割り当てることをさらに含み、前記晴天のグレアおよび反射モデルが、割り当てられた属性を有する前記３Ｄモデルに基づいて生成される、請求項１から６のいずれか一項に記載の方法。
【請求項８】
属性を割り当てることが、
前記３Ｄモデルにおける前記建物を取り巻く物体に反射特性を割り当てることと、
前記３Ｄモデルの窓開口部の各々に固有の窓ＩＤをマッピングすることと、
前記窓開口部を前記１つまたは複数のゾーンにグループ化することと、
前記１つまたは複数のゾーンの各々に、固有ゾーンＩＤをマッピングすることと、
光線追跡エンジンを使用して、かつ前記建物を取り巻く前記物体の前記反射特性に基づいて、前記晴天のグレアおよび反射モデルを生成することと、のうちの１つまたは複数を含む、請求項７に記載の方法。
【請求項９】
前記３Ｄモデルにおける１つまたは複数の３次元占有領域を判定することが、
ユーザからＧＵＩを介して、前記３Ｄモデルの床に描かれた２次元占有者エリア、および目の高さを受信することと、
３次元占有領域を生成するように、前記２次元占有者エリアを前記目の高さまで押し出すことと、を含む、請求項１から８のいずれか一項に記載の方法。
【請求項１０】
前記判定された交差に基づいて、１つまたは複数の条件が存在するかどうかを評価することが、
前記３次元占有領域全体に対する前記交差のパーセンテージが最大パーセンテージを上回り、かつ前記判定された交差の持続時間が最大持続時間を上回る場合に、グレア条件が存在すると判定することと、
前記判定された交差の持続期間が最大持続期間を上回る場合に、反射条件が存在すると判定することと、を含む、請求項１から９のいずれか一項に記載の方法。
【請求項１１】
建築現場の３Ｄモデルを生成し、前記建築現場の建物の色合い調節可能な窓の各ゾーンの色合い状態のスケジュールを判定するためのシステムであって、前記システムが、
コンピュータ可読媒体、および前記コンピュータ可読媒体と通信する１つまたは複数のプロセッサを有する、ネットワークと、
前記コンピュータ可読媒体に記憶された晴天ロジックモジュールであって、前記晴天ロジックモジュールが、前記３Ｄモデルに基づいて、グレアモデルおよび反射モデルを生成することと、前記グレアモデルおよび／または前記反射モデルからの出力に基づいて、各時間間隔における各ゾーンの色合い状態を判定することと、通信ネットワークを介して、各ゾーンの色合い状態の前記スケジュールを前記建物における窓コントローラのネットワークにプッシュすることと、を行うように構成されており、前記窓コントローラのネットワークが、前記スケジュールからの前記色合い状態の最小値と、赤外線センサの読み取り値および光センサの読み取り値のうちの一方または両方に基づく気象ベースの色合い状態と、に基づいて、前記建物の色合い調節可能な窓の前記１つまたは複数のゾーンの各々の前記色合い状態を制御するように構成されている、晴天ロジックモジュールと、を備える、システム。
【請求項１２】
前記ネットワークが、クラウドネットワークである、請求項１１に記載のシステム。
【請求項１３】
前記クラウドネットワーク上に存在する３Ｄモデリングシステムをさらに備え、前記３Ｄモデリングシステムが、クラウドベースの３Ｄモデリングプラットフォーム上で前記建築現場の前記３Ｄモデルを初期化するように構成されている、請求項１２に記載のシステム。
【請求項１４】
建築現場の３Ｄモデルの空間をカスタマイズし、前記建築現場における建物の色合い調節可能な窓の１つまたは複数のゾーンの色付けを制御するためのシステムであって、前記システムが、
１つまたは複数のプロセッサ、および前記１つまたは複数のプロセッサと通信するコンピュータ可読媒体を有する、ネットワークと、
１人または複数のユーザから前記３Ｄモデルの空間をカスタマイズするための入力を受信し、視覚表現を前記１人または複数のユーザに出力するように構成された通信インターフェースと、
３Ｄモデリングシステムであって、前記３Ｄモデリングシステムが、前記１人または複数のユーザから受信した前記入力に基づいて、前記３Ｄモデルをカスタマイズするように構成された、３Ｄモデリングシステムと、
前記コンピュータ可読媒体に記憶された晴天ロジックモジュールであって、前記晴天ロジックモジュールが、前記カスタマイズされた３Ｄモデルに基づいて、グレアモデルおよび反射モデルを生成することと、前記グレアモデルおよび／または前記反射モデルからの出力に基づいて、各時間間隔における各ゾーンの色合い状態を判定することと、前記カスタマイズされた３Ｄモデルの視覚表現を前記１人または複数のユーザに、前記通信インターフェースを介して提供することと、を行うように構成された、晴天ロジックモジュールと、を備える、システム。
【請求項１５】
ネットワークが、クラウドネットワークであり、前記３Ｄモデリングシステムが、前記クラウドネットワーク上に存在する、請求項１４に記載のシステム。
【請求項１６】
前記視覚表現が、前記カスタマイズされた３Ｄモデルに基づいて、前記グレアモデルからの直射太陽光線、または前記反射モデルからの反射された太陽光線を含む、請求項１４または１５に記載のシステム。
【請求項１７】
前記通信インターフェースが、前記１人または複数のユーザが前記入力を変化させること、および前記通信インターフェース上でリアルタイムに前記視覚表現を見直すことを可能にするように構成されたスライドバーを含む、請求項１４から１６のいずれか一項に記載のシステム。
【請求項１８】
建築現場における建物の色合い調節可能な窓の１つまたは複数のゾーンの色合いを制御する方法であって、前記方法が、
前記ゾーンの各々の晴天の色合いレベルを有するスケジュール情報を受信することであって、前記スケジュール情報が、クラウドネットワーク上で維持される前記建築現場の晴天のグレアおよび反射モデルから導出される、受信することと、
光センサの読み取り値および赤外線センサの読み取り値のうちの一方または両方を使用して、雲の条件を判定することと、
前記判定された雲の条件を使用して、気象ベースの色合いレベルを計算することと、
色合い調節可能な窓の前記ゾーンの色合いを前記晴天の色合いレベルおよび前記気象ベースの色合いレベルの最小値に移行させるように、ネットワークを介して、色合い命令を窓コントローラに通信することと、を含む、方法。
【請求項１９】
クラウドネットワーク上に維持される、前記建築現場の前記晴天のグレアおよび反射モデルが、クラウドネットワーク上に存在する、請求項１８に記載の方法。
【請求項２０】
太陽高度を判定することをさらに含み、
前記太陽高度が、太陽が午前の領域または夕方の領域にあることを示している場合、前記雲の条件が、赤外線センサの読み取り値に基づいて判定され、
前記太陽高度が、太陽が昼間の領域にあることを示している場合、前記雲の条件が、光センサの読み取り値および赤外線センサの読み取り値の両方に基づいて判定される、請求項１８または１９に記載の方法。
【請求項２１】
複数の赤外線センサからの赤外線センサの読み取り値のうちの最小読み取り値を計算することをさらに含み、
前記計算された最小読み取り値が、前記午前の領域または前記夕方の領域の間の前記雲の条件を判定するために使用される、請求項２０に記載の方法。
【請求項２２】
上空温度読み取り値の最小値と、周囲温度読み取り値の最小値との間の差を計算することをさらに含み、
前記計算された差が、前記午前の領域または前記夕方の領域の間の前記雲の条件を判定するために使用される、請求項２０または２１に記載の方法。
【請求項２３】
上空温度読み取り値の最小値と、気象入力データからの周囲温度との間の差を計算することをさらに含み、
前記計算された差が、前記午前の領域または前記夕方の領域の間の前記雲の条件を判定するために使用される、請求項２０から２２のいずれか一項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、２０１８年３月２１日に出願された、「ＭＥＴＨＯＤＳ  ＡＮＤ  ＳＹＳＴＥＭＳ  ＦＯＲ  ＣＯＮＴＲＯＬＬＩＮＧ  ＴＩＮＴＡＢＬＥ  ＷＩＮＤＯＷＳ  ＷＩＴＨ  ＣＬＯＵＤ  ＤＥＴＥＣＴＩＯＮ」と題する米国仮特許出願第６２／６４６，２６０号、および２０１８年５月３日に出願された、「ＣＯＮＴＲＯＬ  ＭＥＴＨＯＤＳ  ＡＮＤ  ＳＹＳＴＥＭＳ  ＵＳＩＮＧ  ＥＸＴＥＲＮＡＬ  ３Ｄ  ＭＯＤＥＬＩＮＧ  ＡＮＤ  ＳＣＨＥＤＵＬＥ−ＢＡＳＥＤ  ＣＯＭＰＵＴＩＮＧ」と題する米国仮特許出願第６２／６６６，５７２号の利益、およびそれらに対する優先権を主張し、本出願はまた、２０１８年７月２０日に出願された、「ＣＯＮＴＲＯＬ  ＭＥＴＨＯＤ  ＦＯＲ  ＴＩＮＴＡＢＬＥ  ＷＩＮＤＯＷＳ」と題する米国特許出願１６／０１３，７７０の一部継続出願でもあり、２０１６年１１月９日に出願された、「ＣＯＮＴＲＯＬ  ＭＥＴＨＯＤ  ＦＯＲ  ＴＩＮＴＡＢＬＥ  ＷＩＮＤＯＷＳ」と題する米国特許出願１５／３４７，６７７の継続出願であり、２０１５年５月７日に出願された、「ＣＯＮＴＲＯＬ  ＭＥＴＨＯＤ  ＦＯＲ  ＴＩＮＴＡＢＬＥ  ＷＩＮＤＯＷＳ」と題する国際特許出願ＰＣＴ／ＵＳ１５／２９６７５の一部継続出願であり、２０１４年５月９日に出願された、「ＣＯＮＴＲＯＬ  ＭＥＴＨＯＤ  ＦＯＲ  ＴＩＮＴＡＢＬＥ  ＷＩＮＤＯＷＳ」と題する米国仮特許出願第６１／９９１，３７５号に対する優先権およびその利益を主張し、米国特許出願１５／３４７，６７７はまた、２０１３年２月２１日に出願された、「ＣＯＮＴＲＯＬ  ＭＥＴＨＯＤ  ＦＯＲ  ＴＩＮＴＡＢＬＥ  ＷＩＮＤＯＷＳ」と題する米国特許出願第１３／７７２，９６９号の一部継続出願でもあり、これらの出願の各々は、その全体が、あらゆる目的のために、参照によって本明細書に組み込まれる。
【０００２】
本明細書に開示される実施形態は、概して、色合い調節可能な窓（例えば、エレクトロクロミック窓）の色合いおよび他の機能を制御する方法を実施するための窓コントローラおよび関連する制御ロジックに関する。
【背景技術】
【０００３】
エレクトロクロミズムは、材料が、異なる電子状態に置かれたときに、典型的には電圧変化を受けることによって、光学的性質において電気化学的に媒介される可逆変化を示す現象である。光学的性質は、典型的には、色、透過率、吸光度、および反射率のうちの１つまたは複数である。１つの周知のエレクトロクロミック材料が、酸化タングステン（ＷＯ３）である。酸化タングステンは、電気化学還元によって、透明から青色への着色移行が起こる陰極エレクトロクロミック材料である。
【０００４】
エレクトロクロミック材料は、例えば、家庭用、商業用および他の用途の窓に組み込むことができる。そのような窓の色、透過率、吸光度、および／または反射率は、エレクトロクロミック材料の変化を誘発することによって変化させることができ、換言すれば、エレクトロクロミック窓は、電子的に暗くまたは明るくすることができる窓である。窓のエレクトロクロミックデバイスに小さな電圧を印加すると窓が暗くなり、電圧を逆にすると、明るくなる。この能力は、窓を通過する光の量の制御を可能にし、エレクトロクロミック窓を省エネルギー装置として使用する機会を提供する。
【０００５】
エレクトロクロミズムは１９６０年代に発見されたが、エレクトロクロミックデバイス、特にエレクトロクロミック窓は、残念ながら、依然として様々な問題を抱えており、エレクトロクロミック技術、装置、およびエレクトロクロミックデバイスを製造および／または使用する関連方法における多くの最近の進歩にもかかわらず、それらの完全な商業的可能性を実現し始めていない。
【発明の概要】
【０００６】
一実施形態では、１つまたは複数の色合い調節可能な窓は、全固体型および無機エレクトロクロミックデバイスのみを含む。
【０００７】
特定の態様は、建築現場のグレアおよび反射モデルからの出力に基づいて、建物の色合い調節可能な窓の各ゾーンの色合いレベルを判定する方法に関する。この方法は、建築現場の３Ｄモデルに対して属性を初期化し、かつ割り当てる。この方法はまた、３Ｄモデルにおいて、１つまたは複数の３次元占有領域を生成し、その３Ｄモデルに基づいて、グレアおよび反射モデルも生成する。さらに、この方法は、晴天のグレアまたは反射モデルにおける各ゾーンの色合い調節可能な窓を通る３次元光投射との、３次元占有領域の交差を判定し、判定された交差に基づいて、１つまたは複数の条件が存在するかどうかを評価し、その評価に基づいて、各ゾーンの色合い状態を判定する。一実施態様では、３Ｄモデルは、クラウドベースの３Ｄモデリングプラットフォーム上に存在する。
【０００８】
特定の態様は、建築現場の３Ｄモデルを生成し、建築現場の建物の色合い調節可能な窓の各ゾーンの色合い状態のスケジュールを判定するためのシステムに関する。このシステムは、コンピュータ可読媒体、およびコンピュータ可読媒体と通信する１つまたは複数のプロセッサを有する、ネットワークを備える。このシステムは、コンピュータ可読媒体に記憶された晴天ロジックモジュールをさらに備え、その晴天ロジックモジュールは、３Ｄモデルに基づいて、グレアモデルおよび反射モデルを生成することと、グレアモデルおよび／または反射モデルからの出力に基づいて、各時間間隔における各ゾーンの色合い状態を判定することと、通信ネットワークを介して、各ゾーンの色合い状態のスケジュールを建物における窓コントローラのネットワークにプッシュすることと、を行うように構成される。この窓コントローラのネットワークは、スケジュールからの色合い状態の最小値と、赤外線センサの読み取り値および光センサの読み取り値のうちの一方または両方に基づく気象ベースの色合い状態と、に基づいて、建物の色合い調節可能な窓の１つまたは複数のゾーンの各々の色合い状態を制御するように構成される。一実施態様では、そのネットワークは、クラウドネットワークである。
【０００９】
特定の態様は、建築現場の３Ｄモデルの空間をカスタマイズし、建築現場における建物の色合い調節可能な窓の１つまたは複数のゾーンの色付けを制御するためのシステムに関する。このシステムは、１つまたは複数のプロセッサ、および１つまたは複数のプロセッサと通信するコンピュータ可読媒体を有する、ネットワークと、１人または複数のユーザから３Ｄモデルの空間をカスタマイズするための入力を受信し、視覚表現を１人または複数のユーザに出力するように構成された通信インターフェースと、１人または複数のユーザから受信した入力に基づいて、３Ｄモデルをカスタマイズするように構成されている３Ｄモデリングシステムと、コンピュータ可読媒体に記憶された晴天ロジックモジュールであって、その晴天ロジックモジュールは、カスタマイズされた３Ｄモデルに基づいて、グレアモデルおよび反射モデルを生成することと、グレアモデルおよび／または反射モデルからの出力に基づいて、各時間間隔における各ゾーンの色合い状態を判定することと、カスタマイズされた３Ｄモデルの視覚表現を１人または複数のユーザに、通信インターフェースを介して提供することと、を行うように構成されている、晴天ロジックモジュールと、を備える。一実施態様では、ネットワークは、クラウドネットワークであり、３Ｄモデリングシステムは、クラウドネットワーク上に存在する。
【００１０】
特定の態様は、建築現場における建物の色合い調節可能な窓の１つまたは複数のゾーンの色合いを制御する方法に関する。この方法は、ゾーンの各々の晴天の色合いレベルを有するスケジュール情報を受信することであって、スケジュール情報は、建物現場の晴天のグレアおよび反射モデルから導出される、受信することと、光センサの読み取り値および赤外線センサの読み取り値のうちの一方または両方を使用して、雲の条件を判定することと、判定された雲の条件を使用して、気象ベースの色合いレベルを計算することと、色合い調節可能な窓のゾーンの色合いを晴天の色合いレベルおよび気象ベースの色合いレベルの最小値に移行させるように、ネットワークを介して、色合い命令を窓コントローラに通信することと、を含む。一実施態様では、建築現場の晴天グレアおよび反射モデルは、クラウドネットワーク上に存在する。
【００１１】
これらおよび他の特徴および実施形態が、図面を参照して以下により詳細に説明される。
【図面の簡単な説明】
【００１２】
【図１Ａ】ガラス基板上に形成されたエレクトロクロミックデバイス、すなわちエレクトロクロミックライトの概略図である。
【図１Ｂ】ガラス基板上に形成されたエレクトロクロミックデバイス、すなわちエレクトロクロミックライトの概略図である。
【図１Ｃ】ガラス基板上に形成されたエレクトロクロミックデバイス、すなわちエレクトロクロミックライトの概略図である。
【図２Ａ】絶縁されたガラスユニットに一体化された、図１Ａ〜図１Ｃに関連して説明されたエレクトロクロミックライトの断面概略図を示す。
【図２Ｂ】絶縁されたガラスユニットに一体化された、図１Ａ〜図１Ｃに関連して説明されたエレクトロクロミックライトの断面概略図を示す。
【図３Ａ】エレクトロクロミックデバイスの概略断面図である。
【図３Ｂ】色あせた状態の（または色あせた状態に移行中の）エレクトロクロミックデバイスの概略断面図である。
【図３Ｃ】図３Ｂに示されているが、着色された状態の（または着色された状態に移行中の）エレクトロクロミックデバイスの概略断面図である。
【図４】窓コントローラの構成要素の簡略ブロック図である。
【図５】開示された実施形態による、色合い調節可能な窓、および少なくとも１つのセンサを含む部屋の概略図である。
【図６】特定の実施態様による、建物および建物管理システム（ＢＭＳ）の一例の概略図である。
【図７】特定の実施態様による、建物の１つまたは複数の色合い調節可能な窓の機能を制御するためのシステムの構成要素のブロック図である。
【図８Ａ】様々な実施態様による、クラウドネットワーク上で晴天モデルを維持し、かつモデルからの出力から導出されたデータに基づいて建物の色合い調節可能な窓を制御する際に必要とされる、システムおよびユーザの一般的なシステムアーキテクチャを描く概略図である。
【図８Ｂ】図８Ａに示したシステムアーキテクチャのいくつかのシステム間で通信されるデータの流れの図解例である。
【図９】一例による、建築現場の３Ｄモデルの説明図である。
【図１０】図９の３Ｄモデルに基づくグレア／シャドーモデルの視覚表現の説明図であり、一例による、晴天条件下の上空の１つの位置における、太陽からの直射太陽光の光線を示す。
【図１１】一例による、図９の３Ｄモデルに基づく反射モデルの視覚表現の説明図であり、晴天条件下の現場における、建物からの反射太陽光の光線を示す。
【図１２】一実施態様による、晴天モデルスケジュール情報を生成する際の晴天モジュールのロジック演算の一例の概略図である。
【図１３】図８Ａに示したシステムアーキテクチャのクラウドベースのシステムを通るモデルデータフローの概略図である。
【図１４】様々な実施態様による、３Ｄモデルプラットフォーム上の３Ｄモデルを初期化する際に必要とされる一般的な動作のフローチャートである。
【図１５】様々な実施態様による、３Ｄモデルへの属性の割り当て、条件モデルの生成、および晴天スケジューリング情報の生成に関連する他の動作に必要とされる一般的な動作のフローチャートである。
【図１６】様々な実施態様による、３Ｄモデリングプラットフォーム上の窓管理の視覚表現の一例である。
【図１７Ａ】様々な実施態様による、３Ｄモデリングプラットフォーム上のゾーン管理の視覚表現の一例である。
【図１７Ｂ】様々な実施態様による、３Ｄモデリングプラットフォーム上のゾーン管理の視覚表現の一例である。
【図１８】様々な実施態様による、ゾーン管理においてユーザが使用することができるインターフェースの一例である。
【図１９】様々な実施態様による、各ゾーンに割り当てられた特性を見直すために、ゾーン管理においてユーザが使用することができるインターフェースの一例である。
【図２０Ａ】一実施態様による、３Ｄモデルの床に描かれた２次元のユーザ位置の図解例である。
【図２０Ｂ】図２０Ａの２次元物体を上方の目の高さに押し出すことによって生成された３次元占有領域の図解例である。
【図２１】図２０Ｂに示した３次元占有領域に基づいて、グレア条件なしを返したグレア／シャドーモデルを使用する図解例である。
【図２２】図２０Ｂに示した３次元占有領域に基づいて、グレア条件ありを返した直接反射（１回のはね返り）を使用する図解例である。
【図２３】一態様による、建築現場の晴天３Ｄモデルをカスタマイズするためのユーザ入力を実施するための動作およびプロセスのフローチャートである。
【図２４】一態様による、太陽が窓上にグレアの影響をどのように与えるかを確認するための、５つの色合い調節可能な窓のゾーン上への太陽光の直射光線の視覚表現の一例である。
【図２５】一態様による、太陽が、反射した放射線の影響をどのように与えているかを確認するために、２つの建物から関心のある建物の５つの色合い調節可能な窓のゾーンへの反射した（１回のはね返り）太陽光の光線の視覚表現の一例である。
【図２６】様々な実施態様による、建物の色合い調節可能な窓の１つまたは複数のゾーンを制御するための窓制御システムによって実施される一般的な制御ロジックを示すフローチャートを示す。
【図２７】様々な実施態様による、晴天モデルの出力、モジュールＣ、およびモジュールＤからの入力に基づいて、色合いを決定するための制御ロジックを示すフローチャートを示す。
【図２８】様々な実施態様による、モジュールＤのロジックを示すフローチャートを示す。
【図２９】様々な実施態様による、日の出から日没までの異なる太陽高度での太陽を示す概略図を示す。
【図３０】実施態様による、太陽高度が朝、昼間、または夕方の領域を示しているかどうかに応じて、赤外線センサおよび／または光センサデータのいずれかを使用して色付け決定を行うための制御ロジックのフローチャートを示す。
【図３１】実施態様による、モジュールＤの朝ＩＲセンサアルゴリズムのための制御ロジックのフローチャートを示す。
【図３２】実施態様による、モジュールＤの夕方ＩＲセンサアルゴリズムのための制御ロジックのフローチャートを示す。
【図３３】実施態様による、モジュールＣの昼間ＩＲセンサアルゴリズム、および／またはモジュールＤの昼間光センサアルゴリズムを実施することができる昼間アルゴリズムのための制御ロジックのフローチャートを示す。
【図３４】一実施態様による、２４時間期間中の、摂氏ミリ温度単位のフィルタリングされたＩＲセンサ値対時刻のグラフを示す。
【図３５】１つまたは複数のエレクトロクロミック窓の色合いレベルを判定するための、モジュールＣの一例の制御ロジックのフローチャートを示す。
【図３６】１つまたは複数のエレクトロクロミック窓の色合いレベルを判定するための、モジュールＣの別の例の制御ロジックのフローチャートを示す。
【発明を実施するための形態】
【００１３】
以下の説明では、提示された実施形態の完全な理解を提供するために、多数の具体的な詳細が説明される。開示された実施形態は、これらの具体的な詳細の一部またはすべてがなくても実施され得る。他の例では、開示された実施形態を不必要に分かりにくくしないために、周知のプロセス動作は詳細に説明されていない。開示された実施形態は特定の実施形態と共に説明されるが、開示された実施形態を限定することを意図していないことが理解されるであろう。開示された実施形態はエレクトロクロミック窓（スマートウィンドウとも称される）に焦点を当てているが、本明細書に開示された態様は、他の種類の色合い調節可能な窓にも適用し得ることを理解されたい。例えば、エレクトロクロミックデバイスの代わりに、液晶デバイスまたは懸濁粒子デバイスを組み込んだ色合い調節可能な窓を、開示された実施形態のいずれにも組み込むことができる。
【００１４】
１．エレクトロクロミックデバイスおよび窓コントローラの概要
本明細書に開示されているシステムおよび方法の実施形態に読者を順応させるために、エレクトロクロミックデバイスおよび窓コントローラの簡単な説明を提供する。この最初の説明は、本内容の脈絡のためだけに提供され、続いて記載されるシステム、窓コントローラ、および方法の実施形態は、この最初の説明の特定の特徴および製造プロセスに限定されない。
【００１５】
Ａ．エレクトロクロミックデバイス
本明細書に記載の実施形態を例示するために、エレクトロクロミックライトの特定の実施例が図１Ａから図１Ｃを参照して説明される。図１Ａは、ガラス板１０５から開始し製造されるエレクトロクロミックライト１００の断面図（図１Ｃの断面カットＸ'−Ｘ'参照）である。図１Ｂは、エレクトロクロミックライト１００の端面図（図１Ｃの観察視点Ｙ−Ｙ'参照）を示し、図１Ｃは、エレクトロクロミックライト１００のトップダウン図を示す。図１Ａは、ライトの外周の周りに領域１４０を生成するために端縁が除去された、ガラス板１０５上での製造後のエレクトロクロミックライトを示す。エレクトロクロミックライトもレーザスクライブ加工され、バスバーが取り付けられている。ガラスライト１０５は、拡散障壁１１０と、拡散障壁上の第１の透明導電酸化物層（ＴＣＯ）１１５とを有する。この実施例では、端縁除去プロセスはＴＣＯ１１５および拡散障壁１１０の両方を除去するが、他の実施形態ではＴＣＯのみが除去され、拡散障壁はそのまま残される。ＴＣＯ１１５は、ガラス板上に製造されたエレクトロクロミックデバイスの電極を形成するために使用される２つの導電層のうちの第１導電層である。この実施例では、ガラス板は、下層のガラスと拡散障壁層とを含む。したがって、この実施例では、拡散障壁が形成され、次いで、第１のＴＣＯ、（例えば、エレクトロクロミック層、イオン伝導体層、および対電極層を有する）エレクトロクロミックスタック１２５、および第２のＴＣＯ１３０が形成される。一実施形態では、エレクトロクロミックデバイス（エレクトロクロミックスタックおよび第２のＴＣＯ）は統合蒸着システム内で製造され、ガラス板は、スタックの製造中のどの時間においても統合蒸着システムを離れない。一実施形態では、第１のＴＣＯもまた、統合蒸着システムを使用して形成され、ガラス板は、エレクトロクロミックスタックおよび（第２の）ＴＣＯ層の蒸着中、統合蒸着システムを離れない。一実施形態では、層（拡散障壁、第１のＴＣＯ、エレクトロクロミックスタック、および第２のＴＣＯ）のすべてが統合蒸着システム内で蒸着され、ガラス板は、蒸着中、統合蒸着システムを離れない。この実施例では、エレクトロクロミックスタック１２５の蒸着前に、分離トレンチ１２０がＴＣＯ１１５および拡散障壁１１０を貫通して切断される。トレンチ１２０は、製造が完了した後にバスバー１の下に存在するＴＣＯ１１５の領域を電気的に絶縁することを考慮して作製される（図１Ａ参照）。これは、望ましくない可能性がある、バスバーの下のエレクトロクロミックデバイスの電荷の蓄積および着色を回避するために行われる。
【００１６】
エレクトロクロミックデバイス形成後、端縁除去プロセスおよび追加のレーザスクライブ加工が行われる。図１Ａは、この実施例では、レーザスクライブトレンチ１５０、１５５、１６０、および１６５を囲む外周領域からデバイスが除去された領域１４０を示す。トレンチ１５０、１６０、および１６５は、エレクトロクロミックスタックを貫通し、さらに第１のＴＣＯおよび拡散障壁をも貫通する。トレンチ１５５は、第２のＴＣＯ１３０およびエレクトロクロミックスタックを貫通するが、第１のＴＣＯ１１５は貫通しない。レーザスクライブトレンチ１５０、１５５、１６０、および１６５は、動作可能なエレクトロクロミックデバイスからの端縁除去プロセス中に損傷を受ける可能性があった、エレクトロクロミックデバイスの部分１３５、１４５、１７０、および１７５を分離するために作製される。この実施例では、レーザスクライブトレンチ１５０、１６０、および１６５は、デバイスの分離に役立つように、第１のＴＣＯを貫通している（レーザスクライブトレンチ１５５は第１のＴＣＯを貫通していないが、そうでない場合、トレンチが、第１のＴＣＯとの、およびしたがってエレクトロクロミックスタックとのバスバー２の電気的なつながりを遮断してしまう）。レーザスクライブプロセスに使用される１つまたは複数のレーザは、通常、パルス型レーザ、例えばダイオード励起固体レーザであるが、必ずしもこれに限らない。例えば、レーザスクライブプロセスは、ＩＰＧ  Ｐｈｏｔｏｎｉｃｓ（マサチューセッツ州オックスフォード）またはＥｋｓｐｌａ（リトアニア、ビリニュス）の好適なレーザを使用して実施することができる。スクライブ加工はまた、例えば、先端にダイヤモンドが付いたスクライブによって機械的に行うこともできる。当業者は、エレクトロクロミックデバイスの外周の周りの連続した経路の間で、複数のレーザスクライビングプロセスを異なる深さで実施し得ること、および／またはレーザ切込み深さを変えて、または変えないで単一のプロセスを実行し得ること、を理解するであろう。一実施形態では、端部の除去が、第１のＴＣＯの深さまで行われる。
【００１７】
レーザスクライブ加工完了後、バスバーが取り付けられる。非貫通バスバー１が、第２のＴＣＯに適用される。非貫通バスバー２は、デバイスが蒸着されなかった領域（例えば、デバイス蒸着から第１のＴＣＯを保護するマスクから）に第１のＴＣＯと接触して、もしくは、この実施例では、第１のＴＣＯまで材料を除去するために端縁除去プロセス（例えば、ＸＹまたはＸＹＺ検流計を有する装置を使用するレーザアブレーション）が使用された領域に適用される。この実施例では、バスバー１およびとバスバー２の両方が非貫通バスバーである。貫通バスバーは、通常、エレクトロクロミックスタック内に押し込まれて貫通し、スタックの底部でＴＣＯと接触するバスバーである。非貫通バスバーは、エレクトロクロミックスタック層を貫通しないが、むしろ、例えばＴＣＯなどの導電層の表面に電気的および物理的接触するバスバーである。
【００１８】
ＴＣＯ層は、非従来型バスバー、例えば、スクリーンパターニング法およびリソグラフィパターニング法を用いて製造されたバスバーを使用して、電気的に接続され得る。一実施形態では、導電性インクをシルクスクリーニングし（または別のパターニング方法を使用し）、続いてインクを熱硬化または焼結することによって、デバイスの透明導電層との電気的なつながりが確立される。上述のデバイス構成を使用することの利点として、例えば、貫通バスバーを使用する従来の技術よりも簡単な製造、およびより少ないレーザスクライブ加工が挙げられる。
【００１９】
バスバーが接続された後、デバイスは、例えば、バスバーの配線などを含む絶縁ガラスユニット（ＩＧＵ）に統合される。いくつかの実施形態では、バスバーの一方または両方が完成したＩＧＵの内側にあるが、一実施形態では、一方のバスバーがＩＧＵのシールの外側にあり、他方のバスバーがＩＧＵの内側にある。前者の実施形態では、領域１４０は、ＩＧＵを形成するために使用されるスペーサの一面とのシールを作製するために使用される。したがって、バスバーとのワイヤまたは他の接続部は、スペーサとガラスとの間に延びる。多くのスペーサが、導電性のステンレス鋼などの金属でできているので、バスバーおよびそれへのコネクタと金属スペーサとの間の電気的なつながりによる短絡を回避するための措置を講じることが望ましい。
【００２０】
上述のように、バスバーが接続された後、エレクトロクロミックライトは、例えばバスバーの配線などを含むＩＧＵに統合される。本明細書に記載の実施形態では、バスバーの両方が、完成したＩＧＵの一次シールの内側にある。
【００２１】
図２Ａは、ＩＧＵ２００に統合された、図１Ａから図１Ｃに関連して説明されるエレクトロクロミック窓の断面概略図を示す。スペーサ２０５は、エレクトロクロミックライトを第２のライト２１０から分離するために使用される。ＩＧＵ２００内の第２のライト２１０は、非エレクトロクロミックライトであるが、本明細書に開示される実施形態はそれに限定されない。例えば、ライト２１０は、その上にエレクトロクロミックデバイス、および／または低Ｅコーティングなどの１つまたは複数のコーティングを有することができる。ライト２０１はまた、図２Ｂに示されるように合わせガラスであってもよい（ライト２０１は、樹脂２３５を介して補強窓ガラス２３０に積層される）。スペーサ２０５とエレクトロクロミックライトの第１のＴＣＯ層との間には、一次シール材２１５がある。この一次シール材は、スペーサ２０５と第２のガラスライト２１０との間にもある。スペーサ２０５の外周の周りには、二次シール２２０がある。バスバーの配線／リード線が、コントローラへの接続のためにシールを横切る。二次シール２２０は、描かれているよりはるかに厚くてもよい。これらのシールは、水分がＩＧＵの内部空間２２５に入らないようにするのに役立つ。それらはまた、ＩＧＵの内部のアルゴンまたは他のガスが漏れるのを防止するのに役立つ。
【００２２】
図３Ａは、エレクトロクロミックデバイス３００の断面を概略的に示したものである。エレクトロクロミックデバイス３００は、基板３０２、第１の導電層（ＣＬ）３０４、エレクトロクロミック層（ＥＣ）３０６、イオン伝導層（ＩＣ）３０８、対電極層（ＣＥ）３１０、および第２の導電層（ＣＬ）３１４を含む。層３０４、３０６、３０８、３１０、および３１４は、集合的にエレクトロクロミックスタック３２０と称される。エレクトロクロミックスタック３２０全体に電位を印加するように動作可能な電圧源３１６は、例えば、色あせた状態から着色状態（図示）へのエレクトロクロミックデバイスの移行をもたらす。層の順序は、基板に対して逆にすることができる。
【００２３】
上記のように異なる層を有するエレクトロクロミックデバイスは、全固体型デバイスおよび／または全無機デバイスとして製造することができる。そのようなデバイスおよびそれらを製造する方法が、２００９年１２月２２日に出願され、発明者としてＭａｒｋ  Ｋｏｚｌｏｗｓｋｉらの名前が挙げられた、「Ｆａｂｒｉｃａｔｉｏｎ  ｏｆ  Ｌｏｗ−Ｄｅｆｅｃｔｉｖｉｔｙ  Ｅｌｅｃｔｒｏｃｈｒｏｍｉｃ  Ｄｅｖｉｃｅｓ」と題する米国特許出願第１２／６４５，１１１号、および２００９年１２月２２日に出願され、発明者としてＺｈｏｎｇｃｈｕｎ  Ｗａｎｇらの名前が挙げられた、「Ｅｌｅｃｔｒｏｃｈｒｏｍｉｃ  Ｄｅｖｉｃｅｓ」と題する米国特許出願第１２／６４５，１５９号により詳細に記載されており、これらはいずれも、その全体が参照により本明細書に組み込まれる。ただし、スタック内の層のうちの任意の１つまたは複数が、何らかの量の有機材料を含み得ることを理解されたい。同じことが、１つまたは複数の層中に少量存在し得る液体についても言える。固体材料は、蒸着され得るか、あるいはそうでなければ、ゾル−ゲルまたは化学蒸着を利用する特定のプロセスなどの、液体成分を利用する方法によって形成され得ることも理解されたい。
【００２４】
さらに、色あせた状態と着色状態との間の移行への言及は非限定的であり、実施され得るエレクトロクロミック移行の、多くの例の中の一例のみを示唆していることを理解されたい。本明細書で特に明記しない限り（前述の論議を含む）、色あせ−着色移行への言及がされるときは常に、対応するデバイスまたはプロセスは、非反射−反射、透明−不透明などの他の光学状態の移行を包含する。さらに、用語「色あせた」は、例えば、無着色、透明、または半透明の光学的に無彩色な状態を指す。なおさらに、本明細書中で別段の定めがない限り、エレクトロクロミック移行の「色」は、任意の特定の波長または波長範囲に限定されない。当業者に理解されるように、適切なエレクトロクロミック材料および対電極材料の選択が、関連する光学的移行を左右する。
【００２５】
本明細書に記載の実施形態では、エレクトロクロミックデバイスは、色あせた状態と着色状態との間を可逆的に循環する。場合によっては、デバイスが色あせた状態にあるとき、スタック内の利用可能なイオンが主に対電極３１０内に存在するように、エレクトロクロミックスタック３２０に電位が印加される。エレクトロクロミックスタックの電位が反転すると、イオンがイオン伝導層３０８を横切ってエレクトロクロミック材料３０６に輸送され、材料を着色状態に移行させる。同様に、本明細書に記載の実施形態のエレクトロクロミックデバイスは、異なる色合いレベル（例えば、色あせた状態、最も暗い着色状態、および色あせた状態と最も暗い着色状態との間の中間レベル）の間で可逆的に循環され得る。
【００２６】
再び図３Ａを参照すると、電圧源３１６は、放射センサおよび他の環境センサと共に動作するように構成されてもよい。本明細書に記載されるように、電圧源３１６は、デバイスコントローラ（この図には示されていない）とインターフェースを取る。さらに、電圧源３１６は、季節、時刻、および測定された環境条件などの様々な基準に従って、エレクトロクロミックデバイスを制御するエネルギー管理システムとインターフェースを取ることができる。そのようなエネルギー管理システムは、大面積エレクトロクロミックデバイス（例えば、エレクトロクロミック窓）と連動して、建物のエネルギー消費を劇的に低減することができる。
【００２７】
好適な光学的、電気的、熱的、および機械的特性を有する任意の材料を基板３０２として使用することができる。そのような基板として、例えば、ガラス、プラスチック、および鏡材が挙げられる。好適なガラスとして、ソーダ石灰フロートガラスを含む、透明または着色ソーダ石灰ガラスが挙げられる。ガラスは強化されていてもいなくてもよい。
【００２８】
多くの場合、基板は、住宅用窓の用途に合わせた大きさのガラス板である。そのようなガラス板の大きさは、住宅の特定のニーズに応じて大きく変わり得る。他の場合、基板は建築用ガラスである。建築用ガラスは、通常商業用の建物に使用されるが、住宅用の建物にも使用され得、通常屋内環境を屋外環境から分離するが、必ずしもこれに限定されない。特定の実施形態では、建築用ガラスは、少なくとも２０インチ×２０インチであり、はるかに大きくても、例えば、約８０インチ×１２０インチの大きさであってもよい。建築用ガラスは、通常少なくとも約２ｍｍの厚さ、通常約３ｍｍ〜約６ｍｍの間の厚さである。もちろん、エレクトロクロミックデバイスは、建築用ガラスよりも小さいまたは大きい基板に拡大縮小可能である。さらに、エレクトロクロミックデバイスは、任意のサイズおよび形状の鏡の上に設けることができる。
【００２９】
基板３０２の上部に導電層３０４がある。特定の実施形態では、導電層３０４および３１４のうちの一方または両方は、無機および／または固体である。導電層３０４および３１４は、導電性酸化物、薄い金属被覆、導電性金属窒化物、および複合導体を含む、いくつかの異なる材料から作製されてもよい。通常、導電層３０４および３１４は、少なくとも、エレクトロクロミズムがエレクトロクロミック層によって示される波長範囲において透明である。透明導電酸化物は、金属酸化物、および１つまたは複数の金属でドープされた金属酸化物を含む。このような金属酸化物およびドープ金属酸化物の例として、酸化インジウム、酸化インジウムスズ、ドープ酸化インジウム、酸化スズ、ドープ酸化スズ、酸化亜鉛、アルミニウム酸化亜鉛、ドープ酸化亜鉛、酸化ルテニウム、ドープ酸化ルテニウムなどが挙げられる。多くの場合これらの層に酸化物が使用されるので、それらは「透明導電酸化物」（ＴＣＯ）層と称されることがある。実質的に透明である薄い金属被覆もまた、使用され得、ならびにＴＣＯと金属被覆との組み合わせも使用され得る。
【００３０】
導電層の機能は、電圧源３１６によって提供される電位を、比較的小さなオーミック電位降下で、エレクトロクロミックスタック３２０の表面全体にわたってスタックの内部領域に拡散させることである。電位は、導電層への電気的接続にかかわらず、導電層に伝達される。いくつかの実施形態では、１つが導電層３０４と接触し、１つが導電層３１４と接触しているバスバーが、電圧源３１６と導電層３０４および３１４との間の電気的接続を提供する。導電層３０４および３１４はまた、他の従来の手段で、電圧源３１６に接続されてもよい。
【００３１】
導電層３０４をエレクトロクロミック層３０６が覆っている。いくつかの実施形態では、エレクトロクロミック層３０６は無機および／または固体である。エレクトロクロミック層は、金属酸化物を含む多数の異なるエレクトロクロミック材料のうちの任意の１つまたは複数を含有し得る。このような金属酸化物として、酸化タングステン（ＷＯ３）、酸化モリブデン（ＭｏＯ３）、酸化ニオブ（Ｎｂ２Ｏ５）、酸化チタン（ＴｉＯ２）、酸化銅（ＣｕＯ）、酸化イリジウム（Ｉｒ２Ｏ３）、酸化クロム（Ｃｒ２Ｏ３）、酸化マンガン（Ｍｎ２Ｏ３）、酸化バナジウム（Ｖ２Ｏ５）、酸化ニッケル（Ｎｉ２Ｏ３）、酸化コバルト（Ｃｏ２Ｏ３）などが挙げられる。動作中に、エレクトロクロミック層３０６は、対電極層３１０にイオンを移動させ、対電極層３１０からイオンを受け取って光学遷移を引き起こす。
【００３２】
一般に、エレクトロクロミック材料の着色（または任意の光学的性質、例えば、吸光度、反射率、および透過率の変化）は、材料への可逆的イオン挿入（例えば、インターカレーション）および対応する電荷平衡電子の注入によって引き起こされる。典型的には、光学遷移の原因となるイオンの一部は、エレクトロクロミック材料内に不可逆的に束縛されている。不可逆的に束縛されたイオンの一部または全部は、材料中の「隠れ電荷」を補償するために使用される。ほとんどのエレクトロクロミック材料では、好適なイオンとして、リチウムイオン（Ｌｉ＋）および水素イオン（Ｈ＋）（すなわちプロトン）が挙げられる。しかしながら、場合によっては、他のイオンが好適になる。様々な実施形態において、エレクトロクロミック現象を生じさせるためにリチウムイオンが使用される。リチウムイオンの酸化タングステン（ＷＯ３−ｙ（０＜ｙ≦約０．３））へのインターカレーションが、酸化タングステンを透明（色あせた状態）から青（着色状態）に変化させる。
【００３３】
再び図３Ａを参照すると、エレクトロクロミックスタック３２０において、イオン伝導層３０８は、エレクトロクロミック層３０６と対電極層３１０との間に挟まれている。いくつかの実施形態では、対電極層３１０は無機および／または固体である。対電極層は、エレクトロクロミックデバイスが色あせた状態にあるときにイオン溜としての機能を果たす多くの異なる材料のうちの１つまたは複数を含み得る。例えば、適切な電位の印加によって開始されるエレクトロクロミック移行中、対電極層は、自身が保持するイオンの一部または全部をエレクトロクロミック層に移動させ、エレクトロクロミック層を着色状態に変化させる。同時に、ＮｉＷＯの場合、対電極層はイオンの損失と共に着色する。
【００３４】
いくつかの実施形態では、ＷＯ３と補完的な対電極用の好適な材料として、酸化ニッケル（ＮｉＯ）、酸化ニッケルタングステン（ＮｉＷＯ）、酸化ニッケルバナジウム、酸化ニッケルクロム、酸化ニッケルアルミニウム、酸化ニッケルマンガン、酸化ニッケルマグネシウム、酸化クロム（Ｃｒ２Ｏ３）、酸化マンガン（ＭｎＯ２）、およびプルシアンブルーが挙げられる。
【００３５】
酸化ニッケルタングステンからなる対電極３１０から電荷が除去される（すなわち、対電極３１０からエレクトロクロミック層３０６にイオンが輸送される）と、対電極層は、透明状態から着色状態に移行する。
【００３６】
図示のエレクトロクロミックデバイスでは、エレクトロクロミック層３０６と対電極層３１０との間にイオン伝導層３０８がある。イオン伝導層３０８は、エレクトロクロミックデバイスが色あせた状態と着色状態との間を移行するときにイオンが（電解質のように）中を通って輸送される媒体としての機能を果たす。好ましくは、イオン伝導層３０８は、エレクトロクロミック層および対電極層に関連するイオンに対して高度に伝導性であるが、ごくわずかな電子移動が通常の動作中に起こる、十分に低い電子伝導性を有する。高いイオン伝導率を有する薄いイオン伝導層は、高速イオン伝導、したがって高性能エレクトロクロミックデバイスのための高速スイッチングを可能にする。特定の実施形態では、イオン伝導層３０８は無機および／または固体である。
【００３７】
（異なるＩＣ層を有するエレクトロクロミックデバイスのための）好適なイオン伝導層の例として、ケイ酸塩、酸化ケイ素、酸化タングステン、酸化タンタル、酸化ニオブ、およびホウ酸塩が挙げられる。これらの材料は、リチウムを含む様々なドーパントでドープすることができる。リチウムドープ酸化ケイ素には、酸化リチウムシリコンアルミニウムが含まれる。いくつかの実施形態では、イオン伝導層はケイ酸塩系構造体を含む。いくつかの実施形態では、酸化ケイ素アルミニウム（ＳｉＡｌＯ）がイオン伝導層３０８に使用される。
【００３８】
エレクトロクロミックデバイス３００は、１つまたは複数の不動態層などの、１つまたは複数の追加の層（図示せず）を含んでもよい。特定の光学特性を改善するために使用される不動態層が、エレクトロクロミックデバイス３００に含まれてもよい。耐湿性または耐ひっかき性を提供するための不動態層も、エレクトロクロミックデバイス３００に含まれてもよい。例えば、導電層を、反射防止または保護酸化物または窒化物層で処理してもよい。他の不動態層は、エレクトロクロミックデバイス３００を密閉する機能を果たし得る。
【００３９】
図３Ｂは、色あせた状態（または色あせた状態へ移行中）のエレクトロクロミックデバイスの概略断面図である。特定の実施形態では、エレクトロクロミックデバイス４００は、酸化タングステンエレクトロクロミック層（ＥＣ）４０６および酸化ニッケルタングステン対電極層（ＣＥ）４１０を含む。エレクトロクロミックデバイス４００は、基板４０２、導電層（ＣＬ）４０４、イオン伝導層（ＩＣ）４０８、および導電層（ＣＬ）４１４も含む。
【００４０】
電源４１６は、導電層４０４および４１４への好適な接続（例えばバスバー）を通して、エレクトロクロミックスタック４２０に電位および／または電流を印加するように構成されている。いくつかの実施形態では、電圧源は、ある光学状態から別の光学状態へのデバイスの移行を駆動するために、数ボルトの電位を印加するように構成されている。図３Ａに示されるような電位の極性は、イオン（この実施例ではリチウムイオン）が、（破線の矢印で示されるように）主に酸化ニッケル−タングステン対電極層４１０内に存在するようなものである。
【００４１】
図３Ｃは、図３Ｂに示されるが、着色状態（または着色状態への移行中）のエレクトロクロミックデバイス４００の概略断面図である。図３Ｃでは、電圧源４１６の極性が反転されて、エレクトロクロミック層がより負になって追加のリチウムイオンを受け入れ、それによって着色状態に移行する。破線の矢印で示されるように、リチウムイオンは、イオン伝導層４０８を横切って酸化タングステンエレクトロクロミック層４０６に輸送される。酸化タングステンエレクトロクロミック層４０６は着色状態で示されている。酸化ニッケルタングステン対電極４１０もまた着色状態で示されている。説明したように、酸化ニッケルタングステンは、リチウムイオンを放棄する（デインターカレートする）につれて次第により不透明になる。この実施例では、両方の層４０６およびと４１０の着色状態への移行が、スタックおよび基板を通って透過する光の量を減らす方向に付加的であるという相乗効果がある。
【００４２】
上述のように、エレクトロクロミックデバイスは、イオンに対して高伝導性であり、電子に対して高抵抗性であるイオン伝導性（ＩＣ）層によって分離されたエレクトロクロミック（ＥＣ）電極層および対電極（ＣＥ）層を含み得る。したがって、従来理解されているように、イオン伝導層は、エレクトロクロミック層と対電極層との間の短絡を防止する。イオン伝導層は、エレクトロクロミック電極および対電極が電荷を保持し、それによってそれらの色あせた状態または着色状態を維持することを可能にする。異なる層を有するエレクトロクロミックデバイスでは、構成要素が、エレクトロクロミック電極層と対電極層との間に挟まれたイオン伝導層を含むスタックを形成する。これら３つのスタック構成要素間の境界は、組成および／または微細構造の急激な変化によって画定される。したがって、デバイスは、２つの急激な界面を有する３つの異なる層を有する。
【００４３】
特定の実施形態では、対電極およびエレクトロクロミック電極は、イオン伝導層を独立に蒸着させることなく、互いに直接隣接して、時には直接接触して形成される。いくつかの実施形態では、別個のＩＣ層ではなく、界面領域を有するエレクトロクロミックデバイスが使用される。そのようなデバイス、およびそれらを製造する方法が、２０１０年４月３０日に出願された米国特許第８，３００，２９８号および米国特許出願第１２／７７２，０７５号、ならびに２０１０年６月１１日に出願された米国特許出願第１２／８１４，２７７号および同第１２／８１４，２７９号に記載されており、これら３つの特許出願および特許の各々は、「Ｅｌｅｃｔｒｏｃｈｒｏｍｉｃ  Ｄｅｖｉｃｅｓ」と題され、各々は、発明者としてＺｈｏｎｇｃｈｕｎ  Ｗａｎｇらの名前を挙げており、そして各々は、その全体が参照により本明細書に組み込まれる。
【００４４】
Ｂ．窓コントローラ
窓コントローラは、エレクトロクロミック窓のエレクトロクロミックデバイスの色合いレベルを制御するために使用される。いくつかの実施形態では、窓コントローラは、色あせた状態および着色状態の２つの色合い状態（レベル）の間で、エレクトロクロミック窓を移行させることができる。他の実施形態では、コントローラは、（例えば、単一のエレクトロクロミックデバイスを有する）エレクトロクロミック窓を中間の色合いレベルにさらに移行させることができる。いくつかの開示された実施形態では、窓コントローラは、エレクトロクロミック窓を４つ以上の色合いレベルに移行させることができる。特定のエレクトロクロミック窓は、各ライトが２状態ライトである単一のＩＧＵ内の２つ（またはそれ以上）のエレクトロクロミックライトを使用することによって、中間の色合いレベルを可能にする。これについては、このセクションにおいて、図２Ａおよび２Ｂを参照して説明される。
【００４５】
図２Ａおよび２Ｂに関して上述したように、いくつかの実施形態では、エレクトロクロミック窓は、ＩＧＵ２００の一方のライト上にエレクトロクロミックデバイス４００と、ＩＧＵ２００の他方のライト上に別のエレクトロクロミックデバイス４００とを含むことができる。窓コントローラが各エレクトロクロミックデバイスを、色あせた状態および着色状態の２つの状態の間で移行させることができる場合、エレクトロクロミック窓は、両方のエレクトロクロミックデバイスが着色されている着色状態、一方のエレクトロクロミックデバイスが着色されている第１の中間状態、他方のエレクトロクロミックデバイスが着色されている第２の中間状態、および両方のエレクトロクロミックデバイスが色あせている色あせた状態の４つの異なる状態（色合いレベル）を達成することができる。マルチペインエレクトロクロミック窓の実施形態がさらに、「ＭＵＬＴＩ−ＰＡＮＥ  ＥＬＥＣＴＲＯＣＨＲＯＭＩＣ  ＷＩＮＤＯＷＳ」と題し、発明者としてＲｏｂｉｎ  Ｆｒｉｅｄｍａｎらの名前が挙げられている米国特許第８，２７０，０５９号に記載されており、これはその全体が参照により本明細書に組み込まれる。
【００４６】
いくつかの実施形態では、窓コントローラは、２つ以上の色合いレベルの間で移行することが可能なエレクトロクロミックデバイスを有するエレクトロクロミック窓を移行させることができる。例えば、窓コントローラは、エレクトロクロミック窓を色あせた状態、１つまたは複数の中間レベル、および着色状態に移行させることが可能であり得る。いくつかの他の実施形態では、窓コントローラは、エレクトロクロミックデバイスを組み込んだエレクトロクロミック窓を、色あせた状態と着色状態との間の任意の数の色合いレベルの間で移行させることができる。エレクトロクロミック窓を１つまたは複数の中間の色合いレベルに移行させるための方法およびコントローラの実施形態がさらに、「ＣＯＮＴＲＯＬＬＩＮＧ  ＴＲＡＮＳＩＴＩＯＮＳ  ＩＮ  ＯＰＴＩＣＡＬＬＹ  ＳＷＩＴＣＨＡＢＬＥ  ＤＥＶＩＣＥＳ」と題し、発明者としてＤｉｓｈａ  Ｍｅｈｔａｎｉらの名前が挙げられている米国特許第８，２５４，０１３号に記載されており、これはその全体が参照により本明細書に組み込まれる。
【００４７】
いくつかの実施形態では、窓コントローラは、エレクトロクロミック窓内の１つまたは複数のエレクトロクロミックデバイスに給電することができる。通常、窓コントローラのこの機能は、以下でさらに詳細に説明される１つまたは複数の他の機能で増強される。本明細書に記載の窓コントローラは、制御の目的のために関連付けられているエレクトロクロミックデバイスに給電する機能を有するものに限定されない。すなわち、エレクトロクロミック窓用の電源は窓コントローラとは別にすることができ、この場合、コントローラは、自身の電源を有し、窓電源からの電力の印加を窓に指向する。しかしながら、窓コントローラに電源を含め、窓に直接給電するようにコントローラを構成すると、エレクトロクロミック窓に給電するための別個の配線が必要なくなるので、便利である。
【００４８】
さらに、このセクションで説明される窓コントローラは、窓コントローラを建物制御ネットワークまたは建物管理システム（ＢＭＳ）に統合することなく、単一の窓または複数のエレクトロクロミック窓の機能を制御するように構成され得るスタンドアロンコントローラとして説明される。とはいえ、窓コントローラは、本開示の建物管理システムのセクションでさらに説明されるように、建物制御ネットワークまたはＢＭＳに統合されてもよい。
【００４９】
図４は、開示された実施形態の窓コントローラ４５０のいくつかの構成要素、および窓コントローラシステムの他の構成要素のブロック図を示す。図４は窓コントローラの簡略ブロック図であり、窓コントローラに関するより詳細は、いずれも２０１２年４月１７日に出願され、いずれも「ＣＯＮＴＲＯＬＬＥＲ  ＦＯＲ  ＯＰＴＩＣＡＬＬＹ−ＳＷＩＴＣＨＡＢＬＥ  ＷＩＮＤＯＷＳ」と題され、いずれも発明者としてＳｔｅｐｈｅｎ  Ｂｒｏｗｎの名前が挙げられた米国特許出願第１３／４４９，２４８号および第１３／４４９，２５１号、ならびに２０１２年４月１７日に出願され、発明者としてＳｔｅｐｈｅｎ  Ｂｒｏｗｎらの名前が挙げられ、「ＣＯＮＴＲＯＬＬＩＮＧ  ＴＲＡＮＳＩＴＩＯＮＳ  ＩＮ  ＯＰＴＩＣＡＬＬＹ  ＳＷＩＴＣＨＡＢＬＥ  ＤＥＶＩＣＥＳ」と題された米国特許第１３／４４９，２３５号に見出すことができ、これらはすべて、その全体が参照により本明細書に組み込まれる。
【００５０】
図４において、窓コントローラ４５０の図示された構成要素は、マイクロプロセッサ４５５または他のプロセッサと、パルス幅変調器４６０と、信号調整モジュール４６５と、構成ファイル４７５を有するコンピュータ可読媒体（例えばメモリ）と、を有する窓コントローラ４５０を含む。窓コントローラ４５０は、１つまたは複数のエレクトロクロミックデバイス４００に命令を送信するために、ネットワーク４８０（有線または無線）を介してエレクトロクロミック窓内の１つまたは複数のエレクトロクロミックデバイス４００と電子的に通信する。いくつかの実施形態では、窓コントローラ４５０は、ネットワーク（有線または無線）を介してマスタ窓コントローラと通信するローカル窓コントローラであり得る。
【００５１】
開示された実施形態では、建物は、建物の外部と内部との間にエレクトロクロミック窓を有する少なくとも１つの部屋を有することがある。１つまたは複数のセンサを建物の外部および／または部屋の内部に位置付けてもよい。実施形態では、１つまたは複数のセンサからの出力は、窓コントローラ４５０の信号調整モジュール４６５に入力することができる。場合によっては、建物管理システムのセクションでさらに説明されるように、１つまたは複数のセンサからの出力をＢＭＳに入力することができる。図示の実施形態のセンサは建物の外側垂直壁に位置付けられたものとして示されているが、これは単純化のためであり、センサは、部屋の内側、または外側に対する他の表面上などの他の位置にあってもよい。場合によっては、２つ以上のセンサを使用して同じ入力を測定してもよく、これにより、１つのセンサが故障する、またはそうでなければ誤った測定値を有する場合に、冗長性を提供することができる。
【００５２】
図５は、少なくとも１つのエレクトロクロミックデバイスを有するエレクトロクロミック窓５０５を有する部屋５００の概略図（側面図）を示す。エレクトロクロミック窓５０５は、部屋５００を含む建物の外部と内部との間に位置付けられている。部屋５００はまた、図４の窓コントローラ４５０を含み、その窓は、エレクトロクロミック窓５０５に接続され、かつエレクトロクロミック窓５０５の色合いレベルを制御するように構成されている。外部センサ５１０が、建物の外部の垂直面に位置付けられている。他の実施形態では、部屋５００内の周囲光を測定するために、内部センサも使用され得る。さらに他の実施形態では、占有者がいつ部屋５００内にいるかを判断するために、占有者センサも使用され得る。
【００５３】
外部センサ５１０は、太陽などの光源から、または表面、大気中の粒子、雲などからセンサに反射される光から流れる、デバイスに入射する放射光を検出することができる光センサなどのデバイスである。外部センサ５１０は、光電効果から生じる電流の形態の信号を生成してもよく、この信号は、センサ５１０に入射する光の関数であってもよい。場合によっては、デバイスは、ワット／ｍ２の単位、または他の同様な単位の放射照度に換算して放射光を検出することができる。他の場合、デバイスは、フートキャンドルの単位または同様な単位で、可視波長範囲の光を検出することができる。多くの場合、これらの放射照度値と可視光との間には線形関係がある。
【００５４】
いくつかの実施形態では、外部センサ５１０は、赤外光を測定するように構成されている。いくつかの実施形態では、外部光センサは、赤外光および／または可視光を測定するように構成される。いくつかの実施形態では、外部光センサ５１０はまた、温度および／または湿度データを測定するためのセンサを含み得る。いくつかの実施形態では、インテリジェンスロジックが、外部センサを使用して判定された、もしくは外部ネットワーク（例えば、気象観測所）から受信された１つまたは複数のパラメータ（例えば、可視光データ、赤外線データ、湿度データ、および温度データ）を使用して、妨害する雲の存在を判断する、ならびに／または雲によって引き起こされる妨害を定量化することができる。赤外線センサを使用して雲を検出する様々な方法が、米国を指定し、その全体が本明細書に組み込まれる、２０１７年１０月６日に出願され「ＩＮＦＲＡＲＥＤ  ＣＬＯＵＤ  ＤＥＴＥＣＴＯＲ  ＳＹＳＴＥＭＳ  ＡＮＤ  ＭＥＴＨＯＤＳ」と題された国際特許出願第ＰＣＴ／ＵＳ１７／５５６３１号に記載されている。
【００５５】
日光が地表に当たる角度が変化するので、日光からの放射照度値は、時刻および季節に基づいて予測することができる。外部センサ５１０は、建物に起因する反射光および妨害された光、天候の変化（例えば、雲）などを考慮した放射光をリアルタイムで検出することができる。例えば、曇った日には日光が雲によって遮られて、外部センサ５１０によって検出される放射光は、晴れ渡った日よりも低いであろう。
【００５６】
いくつかの実施形態では、単一のエレクトロクロミック窓５０５に関連付けられた１つまたは複数の外部センサ５１０が存在し得る。１つまたは複数の外部センサ５１０からの出力を互いに比較して、例えば、外部センサ５１０のうちの１つが、外部センサ５１０に留まった鳥などの物体によって遮られているかどうかを判定することができる。場合によっては、いくつかのセンサが信頼できないおよび／または高価である可能性があるため、建物内で比較的少数のセンサを使用することが望ましい場合がある。特定の実装例では、単一のセンサまたは少数のセンサを使用して、建物またはおそらく建物の片側に当たる、太陽からの放射光の現在のレベルを判定することができる。雲が太陽の前を通過する、または建設用車両が沈みかけた太陽の前に駐車することがあり得る。これらは、通常建物に当たると計算される、太陽からの放射光の量からの偏差をもたらすであろう。
【００５７】
外部センサ５１０は、一種の光センサであってもよい。例えば、外部センサ５１０は、電荷結合素子（ＣＣＤ）、フォトダイオード、フォトレジスタ、または光電池であってもよい。当業者は、光センサおよび他のセンサ技術における将来の進展もまた、光強度を測定し、光レベルを表す電気出力を提供するので、使えることを理解するであろう。
【００５８】
いくつかの実施形態では、外部センサ５１０からの出力を信号調整モジュール４６５に入力することができる。入力は、信号調整モジュール４６５への電圧信号の形態であってもよい。信号調整モジュール４６５は、出力信号を窓コントローラ４５０に渡す。窓コントローラ４５０は、構成ファイル４７５からの様々な情報、信号調整モジュール４６５からの出力、オーバライド値に基づいて、エレクトロクロミック窓５０５の色合いレベルを判定する。次いで、窓コントローラ４５０は、所望の色合いレベルに移行させるために、エレクトロクロミック窓５０５に電圧および／または電流を印加するよう、ＰＷＭ４６０に命令する。
【００５９】
開示の実施形態では、４つ以上の異なる色合いレベルのうちの任意の１つにエレクトロクロミック窓５０５を移行させるために、エレクトロクロミック窓４５０に電圧および／または電流を印加するよう、ＰＷＭ４６０に命令することができる。開示された実施形態では、エレクトロクロミック窓５０５は、０（最も明るい）、５、１０、１５、２０、２５、３０、および３５（最も暗い）として記載される少なくとも８つの異なる色合いレベルに移行され得る。色合いレベルは、エレクトロクロミック窓５０５を通して透過される光の可視透過率値および太陽熱利得係数（ＳＨＧＣ）値に線形に対応し得る。例えば、上記の８つの色合いレベルを使用すると、０の最も明るい色合いレベルは０．８０のＳＨＧＣ値に対応し得、５の色合いレベルは０．７０のＳＨＧＣ値に対応し得、１０の色合いレベルは０．６０のＳＨＧＣ値に対応し得、１５の色合いレベルは０．５０のＳＨＧＣ値に対応し得、２０の色合いレベルは０．４０のＳＨＧＣ値に対応し得、２５の色合いレベルは０．３０のＳＨＧＣ値に対応し得、３０の色合いレベルは０．２０のＳＨＧＣ値に対応し得、３５（最も暗い）の色合いレベルは０．１０のＳＨＧＣ値に対応し得る。
【００６０】
窓コントローラ４５０、または窓コントローラ４５０と通信するマスタコントローラは、任意の１つまたは複数の予測制御ロジック構成要素を利用して、外部センサ５１０からの信号および／または他の入力に基づいて所望の色合いレベルを判定することができる。窓コントローラ４５０は、エレクトロクロミック窓５０５を所望の色合いレベルに移行させるために、エレクトロクロミック窓５０５に電圧および／または電流を印加するよう、ＰＷＭ４６０に命令することができる。
【００６１】
−ビル管理システム（ＢＭＳ）
本明細書に記載されている窓コントローラはまた、ＢＭＳとの統合にも適しており、またはＢＭＳの内部にもあり／一部でもある。ＢＭＳは、換気装置、照明、電力システム、エレベータ、防火システム、およびセキュリティシステムなどの建物の機械および電気設備を監視および制御する、建物内に設置されたコンピュータベースの制御システムである。ＢＭＳは、１つまたは複数のコンピュータへの通信チャネルによる相互接続を含むハードウェア、ならびに占有者および／または建物の管理者によって設定される好みに従って、建物内の条件を維持するための関連ソフトウェアからなる。例えば、ＢＭＳは、イーサネット（登録商標）などのローカルエリアネットワークを使用して実装され得る。ソフトウェアは、例えば、インターネットプロトコルおよび／またはオープンスタンダードに基づいてもよい。一例が、Ｔｒｉｄｉｕｍ，Ｉｎｃ．（バージニア州リッチモンド）のソフトウェアである。ＢＭＳで一般的に使用される１つの通信プロトコルが、ＢＡＣｎｅｔ（建物自動化および制御ネットワーク）である。
【００６２】
ＢＭＳは、大型の建物では最も一般的であり、通常、少なくとも建物内の環境を制御するように機能する。例えば、ＢＭＳは、建物内の温度、二酸化炭素レベル、および湿度を制御することができる。通常、ヒータ、エアコン、送風機、通気口などの、ＢＭＳによって制御される多くの機械装置がある。建物環境を制御するために、ＢＭＳは、定義された条件下でこれらの様々なデバイスをオンおよびオフにすることができる。典型的な最新のＢＭＳのコア機能は、冷暖房のコスト／需要を最小化しながら、建物の占有者にとって快適な環境を維持することである。したがって、最新のＢＭＳは、監視および制御を行うためだけでなく、様々なシステム間の相乗効果を最適化する、例えば、エネルギーを節約し、建物の運用コストを低減するためにも使用される。
【００６３】
いくつかの実施形態では、窓コントローラは、ＢＭＳと統合され、そこでは窓コントローラは、１つまたは複数のエレクトロクロミック窓（例えば、５０５）または他の色合い調節可能な窓を制御するように構成されている。他の実施形態では、窓コントローラは、ＢＭＳ内にあり、またはその一部であり、ＢＭＳは、色合い調節可能な窓、および建物の他のシステムの機能の両方を制御する。一例では、ＢＭＳは、建物内の色合い調節可能な窓の１つまたは複数のゾーンを含むすべての建物システムの機能を制御することができる。
【００６４】
いくつかの実施形態では、１つまたは複数のゾーンの各色合い調節可能な窓は、少なくとも１つの固体型および無機エレクトロクロミックデバイスを含む。一実施形態では、１つまたは複数のゾーンの色合い調節可能な窓の各々は、１つまたは複数の固体型および無機エレクトロクロミックデバイスを有するエレクトロクロミック窓である。一実施形態では、１つまたは複数の色合い調節可能な窓は、少なくとも１つの全固体型および無機エレクトロクロミックデバイスを含むが、例えば、ＩＧＵの各ライトまたはペインが色合い調節可能である場合、２つ以上のエレクトロクロミックデバイスを含み得る。一実施形態では、エレクトロクロミック窓は、２０１０年８月５日に出願され、「Ｍｕｌｔｉｐａｎｅ  Ｅｌｅｃｔｒｏｃｈｒｏｍｉｃ  Ｗｉｎｄｏｗｓ」と題された米国特許出願第１２／８５１，５１４号に記載されているような多状態エレクトロクロミック窓である。
【００６５】
図６は、建物６０１と、セキュリティシステム、暖房／換気／空調（ＨＶＡＣ）、建物の照明、電力システム、エレベータ、消防システムなどを含む、多くの建物システムを管理するＢＭＳ６０５との一例の概略図を示す。セキュリティシステムは、磁気カードアクセス、回転ドア、ソレノイド駆動ドアロック、監視カメラ、盗難警報機、金属探知機などを含み得る。消防システムは、火災警報器、および給水配管制御を含む火災抑制システムを含み得る。照明システムは、屋内照明、屋外照明、緊急警報灯、避難誘導灯、および非常口照明を含み得る。電力システムは、主電源、バックアップ発電機、および無停電電源（ＵＰＳ）グリッドを含み得る。
【００６６】
また、ＢＭＳ６０５は、窓制御システム６０２を管理する。窓制御システム６０２は、マスタコントローラ６０３、ネットワークコントローラ６０７ａおよび６０７ｂ、ならびにエンドまたはリーフコントローラ６０８を含む窓コントローラの分散型ネットワークである。エンドまたはリーフコントローラ６０８は、図４に関して説明された窓コントローラ４５０と同様であってもよい。例えば、マスタコントローラ６０３は、ＢＭＳ６０５のすぐそばにあってもよく、建物６０１の各階には、１つまたは複数のネットワークコントローラ６０７ａおよび６０７ｂがあってもよく、一方で建物の各窓には、それ自体のエンドコントローラ６０８があってもよい。この例では、リーフコントローラ６０８の端部の各々が、建物６０１の特定のエレクトロクロミック窓を制御する。窓制御システム６０２は、クラウドネットワーク６１０と通信して、データを受信する。例えば、窓制御システム６０２は、クラウドネットワーク６１０上で維持されている晴天モデルから色合いスケジュール情報を受信することができる。マスタコントローラ６０３は、ＢＭＳ６０５とは別個のものとして図６に示されているが、別の実施形態では、マスタコントローラ６０３は、ＢＭＳ６０５の一部であるか、またはその内部にある。
【００６７】
コントローラ６０８の各々は、それが制御するエレクトロクロミック窓から離れた位置にあり得るか、またはエレクトロクロミック窓の中に一体化され得る。単純にするために、建物６０１の１０個のエレクトロクロミック窓のみが、マスタ窓コントローラ６０２によって制御されるものとして図示してある。典型的な設定では、窓制御システム６０２によって制御される建物には、多数のエレクトロクロミック窓が存在し得る。本明細書に記載されている窓コントローラをＢＭＳに組み込む利点および特徴が、適宜、以下にさらに詳細に、また図６と関連して説明される。
【００６８】
開示された特定の実施形態の一態様は、本明細書に記載されているように、多目的の窓コントローラを含むＢＭＳである。窓コントローラからのフィードバックを組み込むことによって、ＢＭＳは、例えば、強化された、１）環境制御、２）省エネルギー、３）セキュリティ、４）制御オプションの柔軟性、５）他のシステムへのより少ない依存性、したがってそのより少ない保守に起因する、他のシステムの改善された信頼性および有効寿命、６）情報の可用性および診断法、７）スタッフの効率的な使い方、およびスタッフからのより高い生産性、ならびにこれらの様々な組み合わせ、を提供することができ、その理由は、エレクトロクロミック窓を自動的に制御することができるからである。いくつかの実施形態では、ＢＭＳは、存在しなくてもよく、またはＢＭＳは、存在はするが、マスタコントローラと通信しなくてもよく、もしくは高レベルでマスタコントローラと通信してもよい。これらの場合には、ＢＭＳの保守は、エレクトロクロミック窓の制御を妨げないことになる。
【００６９】
特定の開示された例によれば、ＢＭＳ（例えば、ＢＭＳ６０５）または建物ネットワークのシステムは、毎日、毎月、毎四半期、または毎年のスケジュールに従って実行する。例えば、照明制御システム、窓制御システム、ＨＶＡＣ、およびセキュリティシステムは、人々が就業日中にいつ建物内にいるかを考慮する２４時間スケジュールで動作することができる。夜間には、建物は、省エネモードに入ることができ、日中、建物システムは、占有者に快適さを提供しながら、建物のエネルギー消費を最小にするように動作することができる。別の例として、建物システムは、休日期間か、または建物での占有が少ない他の期間にわたって、電源を落とすか、または省エネモードに入ってもよい。
【００７０】
ＢＭＳスケジュールは、地理的情報と組み合わせることができる。地理的情報は、建物の緯度および経度を含んでもよい。地理的情報はまた、建物の各側が面している方向に関する情報を含んでもよい。そのような情報を使用して、建物の異なる側の異なる部屋を異なる方法で制御することができる。例えば、冬には、建物の東向きの部屋の場合、窓コントローラは、朝に色合いを有さないように窓に命令することによって、その部屋は、部屋内に差し込む太陽光によって暖まり、照明制御パネルは、太陽光からの採光のために減光するように照明に命令することができる。西向きの窓は、西側の窓の色合いが省エネに大きな影響を及ぼさない場合があるため、朝は、部屋の占有者が制御可能であり得る。しかしながら、東向きの窓および西向きの窓の動作モードは、夕方に切り替わることがある（例えば、太陽が沈んでいるときに、西向きの窓は、色合い調整されず、暖房および照明の両方のために太陽光を入れることができる）。
【００７１】
例えば、図６の建物６０１と同様に、建物の一例が、以下に説明されており、建物ネットワークまたはＢＭＳ、建物の外部の窓（すなわち、建物の外部から建物の内部を分離する窓）のための色合い調節可能な窓（例えば、エレクトロクロミック窓）、および多数の異なるセンサを含む。建物の外部の窓を通過する光は、一般に、その窓から約２０フィート〜３０フィートまでの建物の内部の光レベルに影響を及ぼす。すなわち、外部の窓から約２０フィート〜３０フィートを上回る建物内の任意の空間は、外部の窓を通過する光をほとんど受けない。建物内の外部の窓から離れたそのような空間は、主に建物の内部照明システムによって照らされる。さらに、建物内の温度は、外部の光および／または外部の周囲温度によって影響を受け得る。例えば、寒い日に建物が暖房システムによって暖房されているとき、ドアおよび／または窓に近い部屋は、建物の内部領域よりも早く熱を失い、内部領域と比べてより冷たくなる。
【００７２】
外部センサを備える建物の場合、外部センサは、建物の屋根の上に存在する場合がある。代替的にまたは追加的に、建物は、各外部窓に関連付けられた外部センサ（例えば、図５の部屋５００に関連して説明された外部センサ５１０）、または建物の各側面上の外部センサを含むことができる。建物の各側面上の外部センサは、例えば、太陽が日中全体を通じて位置を変えるにつれて、建物の側面上の放射照度を追跡することが可能である。
【００７３】
図２３、図２６〜図３６に関して説明された方法に関して、窓コントローラが建物ネットワークまたはＢＭＳ内に一体化されると、外部センサからの出力は、ＢＭＳの建物ネットワークに入力され得、ローカルな窓コントローラへの入力として提供され得る。例えば、いくつかの実施形態では、任意の２つ以上のセンサからの出力信号が受信される。いくつかの実施形態では、ただ１つの出力信号が受信され、いくつかの他の実施形態では、３つ、４つ、５つ、またはそれ以上の出力が受信される。これらの出力信号は、建物ネットワークまたはＢＭＳを介して受信され得る。
【００７４】
いくつかの実施形態では、受信された出力信号は、建物内の暖房システム、冷房システム、および／または照明によるエネルギーまたは電力消費を示す信号を含む。例えば、建物の暖房システム、冷房システム、および／または照明のエネルギーまたは電力消費を監視して、エネルギーまたは電力消費を示す信号を提供することができる。この監視を可能にするために、デバイスは、建物の回路および／または配線とインターフェースが取られてもよく、またはそれに取り付けられてもよい。代替的に、建物内の電力システムは、建物内の個々の部屋または建物内の部屋のグループのための暖房システム、冷房システム、および／または照明によって消費される電力が監視され得るように設置されてもよい。
【００７５】
色合い命令を提供して、色合い調節可能な窓の色合いを、判定された色合いレベルに変更することができる。例えば、図６を参照すると、このことは、マスタコントローラ６０３がコマンドを１つまたは複数のネットワークコントローラ６０７ａおよび６０７ｂに発行することを含み得、そして次に、それらのネットワークコントローラは、建物の各窓を制御するエンドコントローラ６０８にコマンドを発行する。エンドコントローラ６０８は、命令に従って色合いの変化を生じさせるために、窓に電圧および／または電流を印加することができる。
【００７６】
いくつかの実施形態では、色合い調節可能な窓およびＢＭＳを含む建物が、建物に電力を供給している１つまたは複数のユーティリティによって実行される要求応答プログラムに登録されるか、またはそれに参加することができる。このプログラムは、ピーク負荷の発生が予想されるときに、建物のエネルギー消費が低減されるプログラムであってもよい。ユーティリティは、予想されるピーク負荷が発生する前に、警告信号を送出することができる。例えば、警告は、予想されるピーク負荷発生の前日、朝、または約１時間前に送信してもよい。ピーク負荷の発生は、例えば、冷房システム／空調機がユーティリティから大量の電力を取っている暑い夏の日に起こると予想され得る。警告信号は、建物のＢＭＳによって、または建物内の色合い調節可能な窓を制御するように構成された窓コントローラによって受信され得る。この警告信号は、図７に示されるように、モジュールＡ、Ｂ、およびＣを解除するオーバライド機構であってもよい。次いで、ＢＭＳは、窓コントローラ（複数可）に命令して、ピーク負荷が予想されるときに建物内の冷房システムの消費電力を低減する際、色合い調節可能な窓５０５内の適切で光学的に切り替え可能なデバイス（例えば、エレクトロクロミックデバイス）を暗い色合いレベル支援に移行させることができる。
【００７７】
いくつかの実施形態では、建物の外部窓用の色合い調節可能な窓（すなわち、建物の内部を建物の外部から分離する窓）は、ゾーンにグループ化して、ゾーン内の色合い調節可能な窓に同様に命令するようにしてもよい。例えば、建物の異なる階、または建物の異なる側面にある色合い調節可能な窓のグループは、異なるゾーン内にあってもよい。例えば、建物の１階に、東向きの色合い調節可能な窓のすべてがゾーン１にあってもよく、南向きの色合い調節可能な窓のすべてがゾーン２にあってもよく、西向きの色合い調節可能な窓のすべてがゾーン３にあってもよく、北向きの色合い調節可能な窓のすべてがゾーン４にあってもよい。別の例として、建物の１階のすべての色合い調節可能な窓がゾーン１にあってもよく、２階のすべての色合い調節可能な窓がゾーン２にあってもよく、３階のすべての色合い調節可能な窓がゾーン３にあってもよい。さらに別の例として、東向きの色合い調節可能な窓のすべてがゾーン１にあってもよく、南向きの色合い調節可能な窓のすべてがゾーン２にあってもよく、西向きの色合い調節可能な窓のすべてがゾーン３にあってもよく、北向きの色合い調節可能な窓のすべてがゾーン４にあってもよい。さらに別の例として、１つの階の東向きの色合い調節可能な窓が、異なるゾーンに分割され得る。建物の同じ側面および／または異なる側面および／または異なる階の任意の数の色合い調節可能な窓が、１つのゾーンに割り当てられてもよい。個々の色合い調節可能な窓が、独立に制御可能なゾーンを有する実施形態では、色合い調節ゾーンは、個々の窓のゾーンの組み合わせを使用して建物の１つの表面上に設けてもよく、例えば、個々の窓は、そのゾーンのすべてが色合い調節されてもよい、またはされなくてもよい。
【００７８】
いくつかの実施形態では、ゾーン内の色合い調節可能な窓は、同じ窓コントローラによって制御されてもよい。いくつかの他の実施形態では、ゾーン内の色合い調節可能な窓は、異なる窓コントローラによって制御され得るが、窓コントローラは、すべて、センサからの同じ出力信号を受信し、同じ機能または参照表を使用してゾーンの窓の色合いのレベルを判定することができる。
【００７９】
いくつかの実施形態では、ゾーン内の色合い調節可能な窓は、透過率センサからの出力信号を受信する１つまたは複数の窓コントローラによって制御されてもよい。いくつかの実施形態では、透過率センサは、ゾーン内の窓に近接して取り付けられてもよい。例えば、透過率センサは、ゾーンに含まれるＩＧＵを含むフレームの中または上に取り付け（例えば、マリオン、フレームの水平サッシの中または上に取り付け）てもよい。いくつかの他の実施形態では、建物の単一側面上に窓を含むゾーン内の色合い調節可能な窓は、透過率センサからの出力信号を受信する１つまたは複数の窓コントローラによって制御されてもよい。
【００８０】
いくつかの実施形態では、センサ（例えば、光センサ）は、出力信号を窓コントローラに提供して、第１のゾーン（例えば、マスタ制御ゾーン）の色合い調節可能な窓（例えば、エレクトロクロミック窓５０５）を制御することができる。窓コントローラはまた、第１のゾーンと同じ方法で第２のゾーン（例えば、スレーブ制御ゾーン）内の色合い調節可能な窓を制御することもできる。いくつかの他の実施形態では、別の窓コントローラが、第１のゾーンと同じ方法で第２のゾーンの色合い調節可能な窓を制御することもできる。
【００８１】
いくつかの実施形態では、建物管理者、第２のゾーン内の部屋の占有者、または他の個人が、第２のゾーン（すなわち、スレーブ制御ゾーン）内の色合い調節可能な窓を手動で命令して（例えば、色合いもしくは透明コマンド、またはＢＭＳのユーザコンソールからのコマンドを使用して）、着色状態（レベル）または透明状態などの色合いレベルに入ることができる。いくつかの実施形態では、第２のゾーンの窓の色合いレベルがそのような手動コマンドでオーバライドされると、第１のゾーン（すなわち、マスタ制御ゾーン）の色合い調節可能な窓は、透過率センサからの出力を受信している窓コントローラの制御下に留まる。第２のゾーンは、一定期間手動コマンドモードに留まり、その後、透過率センサからの出力を受信する窓コントローラの制御下に戻ることができる。例えば、第２のゾーンは、オーバライドコマンドを受信した後１時間手動モードに留まり、その後、透過率センサからの出力を受信する窓コントローラの制御下に戻ることができる。
【００８２】
いくつかの実施形態では、建物の管理者、第１のゾーンの部屋の占有者、または他の人が、手動で（例えば、色合いコマンドまたはＢＭＳのユーザコンソールからのコマンドを使用して）第１のゾーン（すなわち、マスタ制御ゾーン）の窓に、着色状態または透明状態などの色合いレベルに入るよう命令することができる。いくつかの実施形態では、第１のゾーンの窓の色合いレベルがそのような手動コマンドでオーバライドされると、第２のゾーン（すなわち、スレーブ制御ゾーン）の色合い調節可能な窓は、外部センサからの出力を受信する窓コントローラの制御下に留まる。第１のゾーンは、一定期間手動コマンドモードに留まり、その後、透過率センサからの出力を受信する窓コントローラの制御下に戻ることができる。例えば、第１のゾーンは、オーバライドコマンドを受信した後１時間手動モードに留まり、その後、透過率センサからの出力を受信する窓コントローラの制御下に戻ることができる。いくつかの他の実施形態では、第２のゾーンの色合い調節可能な窓は、第１のゾーンの手動オーバライドが受信されたときに、それらの窓があった色合いレベルに留まることができる。第１のゾーンは、一定期間手動コマンドモードに留まり、その後、第１のゾーンおよび第２のゾーンの両方が、透過率センサからの出力を受信する窓コントローラの制御下に戻ることができる。
【００８３】
窓コントローラがスタンドアロン窓コントローラであるのか、それとも建物ネットワークとインターフェース接続されているのかに関わりなく、本明細書に記載の色合い調節可能な窓の制御の方法のいずれも、使用済みの制御、色合い調節可能な窓の色合いであり得る。
【００８４】
−無線または有線通信
いくつかの実施形態では、本明細書に記載の窓コントローラは、窓コントローラと、センサと、別個の通信ノードとの間の有線または無線通信のための構成要素を含む。無線または有線通信は、窓コントローラと直接インターフェースを取る通信インターフェースを用いて達成され得る。そのようなインターフェースは、マイクロプロセッサに固有であっても、これらの機能を可能にする追加の回路を介して提供されてもよい。
【００８５】
無線通信用の別個の通信ノードは、例えば、別の無線窓コントローラ、エンド窓コントローラ、中間窓コントローラ、またはマスタ窓コントローラ、遠隔制御デバイス、またはＢＭＳであり得る。ワイヤレス通信は、窓コントローラで次の操作、すなわち、１）色合い調節可能な窓（例えば、エレクトロクロミック窓５０５）をプログラミングおよび／または操作すること、２）本明細書に記載された様々なセンサおよびプロトコルからの、色合い調節可能な窓からのデータを収集すること、ならびに３）無線通信のための中継点として色合い調節可能な１つまたは複数の窓を使用すること、のうちの少なくとも１つのために使用される。色合い調節可能な窓から収集されたデータはまた、例えば、エレクトロクロミックデバイスが活性化された回数、エレクトロクロミックデバイスの経時的な効率などのデータをカウントすることを含むこともできる。これらの無線通信機能が以下により詳細に説明される。
【００８６】
一実施形態では、無線通信は、例えば、赤外線（ＩＲ）および／または高周波（ＲＦ）信号を介して、関連付けられたエレクトロクロミック窓（例えば、エレクトロクロミック窓５０５）を操作するために使用される。特定の実施形態では、コントローラは、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＥｎＯｃｅａｎ、ＷｉＦｉ、Ｚｉｇｂｅｅ（登録商標）などの無線プロトコルチップを含むであろう。窓コントローラは、ネットワークを介する無線通信を有してもよい。窓コントローラへの入力は、直接または無線通信を介して、エンドユーザによって壁スイッチで手動で入力することができるか、あるいは、入力は、エレクトロクロミック窓が構成要素である建物のＢＭＳからであってもよい。
【００８７】
一実施形態では、窓コントローラが、コントローラの分散型ネットワークの一部である場合、各々が無線通信コンポーネントを有するコントローラの分散型ネットワークを介して、データを複数のエレクトロクロミック窓の各々へ、および各々から転送するために、無線通信が使用される。例えば、図６を再び参照すると、マスタコントローラ６０３は、ネットワークコントローラ６０７ａおよび６０７ｂの各々と無線で通信し、これらのネットワークコントローラは、各々がエレクトロクロミック窓に関連付けられているエンドまたはリーフコントローラ６０８と次々に無線で通信する。マスタコントローラ６０３はまた、ＢＭＳ６０５と無線で通信することができる。一実施形態では、窓コントローラのネットワーク内の、少なくとも１つのレベルの通信は、無線で実行される。
【００８８】
いくつかの実施形態では、複数のモードの無線通信が、窓コントローラ分散型ネットワーク内で使用される。例えば、マスタ窓コントローラが、ＷｉＦｉまたはＺｉｇｂｅｅ（登録商標）を介して中間コントローラと無線通信し得る一方、中間コントローラは、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｚｉｇｂｅｅ（登録商標）、ＥｎＯｃｅａｎ、または他のプロトコルを介してエンドコントローラと通信する。別の実施例では、窓コントローラは、無線通信のためのエンドユーザの選択肢での柔軟性のために、冗長な無線通信システムを有する。
【００８９】
例えば、マスタおよび／または中間窓コントローラと、エンドまたはリーフ窓コントローラとの間の無線通信は、ハード通信線の設置を不要にする利点をもたらす。このことはまた、窓コントローラと、ＢＭＳまたは建物ネットワークとの間の無線通信にも当てはまる。一態様では、これらの役割での無線通信は、窓を操作して、例えば、建物内の環境および省エネルギーを最適化するためにＢＭＳにデータを提供するための、エレクトロクロミック窓への、およびエレクトロクロミック窓からのデータ転送に有用である。窓位置データならびにセンサからのフィードバックは、そのような最適化のために相乗的に作用する。例えば、細かいレベル（窓毎）の微気候情報が、ＢＭＳに送られ、建物システムの制御命令を判定するために使用されて、その結果、建物の様々な環境を最適化することができる。
【００９０】
−色合い調節可能な窓の機能を制御するためのシステムの実施例
図７は、実施形態による、建物（例えば、図６に示された建物６０１）の１つまたは複数の色合い調節可能な窓の機能（例えば、異なる色合いレベルへの移行）を制御するためのシステム７００の構成要素のブロック図である。システム７００は、ＢＭＳ（例えば、図６に示されたＢＭＳ６０５）によって管理されるシステムのうちの１つであってもよく、またはＢＭＳとは無関係に動作してもよい。
【００９１】
システム７００は、制御信号を色合い調節可能な窓に送信してその機能を制御することができる窓コントローラのネットワークを有する窓制御システム７０２を含む。システム７００はまた、マスタコントローラ７０３と電子通信するネットワーク７０１も含む。予測制御ロジック、色合い調節可能な窓（複数可）の機能を制御するための他の制御ロジックおよび命令、センサデータ、ならびに／または晴天モデルに関するスケジュール情報は、ネットワーク７０１を介してマスタコントローラ７０３に通信することができる。ネットワーク７０１は、有線または無線ネットワーク（例えば、クラウドネットワーク）であり得る。一実施形態では、ネットワーク７０１は、ＢＭＳと通信して、ＢＭＳが、色合い調節可能な窓（複数可）を制御するための命令を、ネットワーク７０１を介して建物内の色合い調節可能な窓（複数可）に送信するのを可能にすることができる。
【００９２】
システム７００はまた、色合い調節可能な窓（図示せず）のエレクトロクロミックデバイス７８０、およびオプションの壁スイッチ７９０も含み、これらは、両方ともマスタコントローラ７０３と電子通信している。この図示された例では、マスタコントローラ７０３は、エレクトロクロミックデバイス７８０（複数可）に制御信号を送信して、エレクトロクロミックデバイス（複数可）７８０を有する色合い調節可能な窓の色合いレベルを制御することができる。各壁スイッチ７９０はまた、エレクトロクロミックデバイス７８０（複数可）およびマスタコントローラ７０３とも通信する。エンドユーザ（例えば、色合い調節可能な窓を有する部屋の占有者）は、壁スイッチ７９０を使用して、エレクトロクロミックデバイス（複数可）７８０を有する色合い調節可能な窓のオーバライド色合いレベルおよび他の機能を入力することができる。
【００９３】
図７では、窓制御システム７０２は、マスタコントローラ７０３、マスタコントローラ７０３と通信する複数のネットワークコントローラ７０５、および多段の複数のエンドまたはリーフ窓コントローラ７１０を含む窓コントローラの分散型ネットワークとして示されている。各複数のエンドまたはリーフ窓コントローラ７１０は、単一のネットワークコントローラ７０５と通信する。図７のシステム７００の構成要素は、いくつかの点で、図６に関して説明された構成要素と類似であってもよい。例えば、マスタコントローラ７０３は、マスタコントローラ６０３と同様であり得、ネットワークコントローラ７０５は、ネットワークコントローラ６０７ａ、６０７ｂと同様であってもよい。図７の分散型ネットワーク内の窓コントローラの各々は、プロセッサ（例えば、マイクロプロセッサ）およびそのプロセッサと電気通信するコンピュータ可読媒体を含む。
【００９４】
図７では、各リーフまたはエンド窓コントローラ７１０は、単一の色合い調節可能な窓のエレクトロクロミックデバイス（複数可）７８０と通信して、建物内のその色合い調節可能な窓の色合いレベルを制御する。ＩＧＵの場合、リーフまたはエンド窓コントローラ７１０は、ＩＧＵの色合いレベルを制御するＩＧＵの複数のライト上のエレクトロクロミックデバイス（複数可）７８０と通信することができる。他の実施形態では、各リーフまたはエンド窓コントローラ７１０は、複数の色合い調節可能な窓、例えば、色合い調節可能な窓のゾーンと通信することができる。リーフまたはエンド窓コントローラ７１０は、色合い調節可能な窓に統合されてもよく、またはリーフまたはエンド窓コントローラ１４１０が制御する色合い調節可能な窓と別個であってもよい。図７のリーフおよびエンド窓コントローラ７１０は、図６のエンドまたはリーフコントローラ６０８と類似であってもよく、および／または図４に関して説明された窓コントローラ４５０と類似であってもよい。
【００９５】
各壁スイッチ７９０は、壁スイッチ７９０と通信する色合い調節可能な窓の色合いレベルおよび他の機能を制御するために、エンドユーザ（例えば、部屋の占有者）によって操作され得る。エンドユーザは、壁スイッチ７９０を操作して、制御信号を、関連付けられた色合い調節可能な窓内のエレクトロクロミックデバイス（複数可）７８０に通信することができる。壁スイッチ７９０からのこれらの信号は、場合によっては、窓制御システム７０２からの信号をオーバライドする場合がある。他の場合（例えば、高需要の場合）、窓制御システム７０２からの制御信号は、壁スイッチ１４９０からの制御信号をオーバライドする場合がある。各壁スイッチ７９０はまた、リーフまたはエンド窓コントローラ７１０と通信して、壁スイッチ７９０から送信された制御信号に関する情報（例えば、時刻、日付、要求された色合いレベルなど）をマスタ窓コントローラ７０３に返送して、例えば、メモリ内に保存される。場合によっては、壁スイッチ７９０は、手動で操作されてもよい。他の場合には、壁スイッチ７９０は、例えば、赤外線（ＩＲ）および／または高周波（ＲＦ）信号を使用して制御信号を有する無線通信を送信するリモートデバイス（例えば、携帯電話、タブレットなど）を使用するエンドユーザによって無線で制御され得る。場合によっては、壁スイッチ７９０は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＥｎＯｃｅａｎ、ＷｉＦｉ、Ｚｉｇｂｅｅ（登録商標）などの無線プロトコルチップを含んでもよい。図７に示された壁スイッチ７９０は、壁（複数可）上に配置されているが、システム７００の他の実施形態は、部屋内のどこか他の場所に配置されたスイッチを有してもよい。
【００９６】
別の実施形態では、システム７００はまた、通信ネットワーク７０１を介して１つまたは複数のコントローラと電子通信するマルチセンサデバイスを含み、その結果、センサ読み取り値および／またはフィルタリングされたセンサ値をコントローラ（複数可）に通信する。
【００９７】
ＩＩ．一般的なシステムアーキテクチャ
建物のシャドーおよび反射のモデルを積極的に維持および記憶することは、面倒であり、かつ建物のコンピューティングリソースにとって非効率な使用であり得る。本明細書で説明されているシステムアーキテクチャは、これらの建物のモデルを積極的に生成するためには、窓制御システムを必要としない。逆に、建築現場に固有のモデルが生成され、窓制御システムとは別個のクラウドネットワークまたは他のネットワーク上で維持される。これらのモデルから導出された色合いスケジュール情報は、窓制御システムにプッシュされる。窓制御システムは、建物用にカスタマイズされたこれらの定義済みモデルから導出される色合いスケジュール情報を使用して、色合い調節可能な窓で実施される最終的な色付けを決定する。これらのモデルは、例えば、クラウドベースの３Ｄモデリングプラットフォーム上で維持することができる。クラウドベースの３Ｄモデリングプラットフォームを使用して、建築現場の３Ｄモデルの視覚表現を生成し、ユーザが建築現場のモデルをセットアップおよびカスタマイズするための入力と、色合い調節可能な窓に適用される対応する最終的な色合い状態と、を管理するのを可能にすることができる。このシステムアーキテクチャにおいて、色合いスケジュール情報が窓制御システムに読み込まれると、窓制御システムの演算能力を停滞させるモデリング計算を行う必要がない。クラウドベースの３Ｄモデリングプラットフォーム上のモデルへの任意の変更から生じる色合いスケジュール情報は、必要に応じて窓制御システムにプッシュされ得る。システムアーキテクチャは、色合い調節可能な窓を制御することに関して、本明細書では概して説明されているが、建物の他の構成要素は、このアーキテクチャを用いて追加的にまたは代替的に制御することができることが理解されるであろう。
【００９８】
様々な実施態様では、システムアーキテクチャは、建築現場の３Ｄモデルをセットアップおよびカスタマイズするためのクラウドベースのモジュールを含む。例えば、システムアーキテクチャは、クラウドベースの３Ｄモデリングシステムを含み、この３Ｄモデリングシステムは、建築モデル（複数可）データを入力とし使用して、建築現場の３Ｄモデルを初期化し、そのデータとしては、例えば、Ａｕｔｏｄｅｓｋ（登録商標）Ｒｅｖｉｔモデルまたは他の業界標準の建築モデルからのデータが使用されてもよい。最も単純な形式の３Ｄモデルには、窓の開口部、ならびに床および壁のみを有する建物の内部のストリップバージョンを含む、建物の構造の外面が含まれる。より複雑な３Ｄモデルには、建物、ならびに建物の内部および外部のより詳細な特徴を取り囲む物体の外面が含まれる場合がある。
【００９９】
システムアーキテクチャにはまた、クラウドベースの晴天モジュールも含まれ、その晴天モジュールは、反射または非反射特性を３Ｄモデル内の物体の外面に割り当て、内部の３次元占有領域を定義し、ＩＤを窓に割り当て、ユーザ（複数可）からの入力に基づいて窓をゾーンにグループ化する。結果として得られた晴天３Ｄモデル（すなわち、割り当てられた属性を有する構成データを持つ３Ｄモデル）の時間変化シミュレーションを使用して、晴天条件下での上空の太陽の異なる位置における太陽光の方向を判定することができ、建築現場での物体からのシャドーおよび反射と、窓または他の開口部を通って建物の空間に入る太陽光と、窓を通る太陽光の３Ｄ投射の、建物内の３次元占有領域との交差と、が考慮される。晴天モジュールは、この情報を使用して、例えば、グレア条件、直接的および間接的な反射条件、ならびにパッシブヒート条件などの、特定の占有領域のための特定の条件が存在するかどうかを判定する（すなわち、占有者の観点から）。晴天モジュールは、その時点での特定の条件の存在、各条件に割り当てられた色合い状態、および複数の条件が存在する場合の異なる条件の優先度に基づいて、各時間間隔で各ゾーンの晴天色合い状態を判定する。各ゾーンは、１つまたは複数の色合い調節可能な窓を有する。一定期間、通常は１年間にわたる各ゾーンの晴天色合いスケジュール情報は、例えば、建物での窓制御システムのマスタコントローラにプッシュされる。窓制御システムは、赤外線センサおよび／もしくは光センサからの測定値などのセンサデータ、または経時的に取得されたローリングセンサの読み取り値の中央値／平均値などのフィルタリングされたセンサデータに基づいて、各時間間隔で各ゾーンの気象ベースの色合い状態を判定する。次いで、窓制御システムは、気象ベースの色合い状態、および晴天の色合い状態、または各ゾーンの最小値を判定して、最終的な色合い状態を設定し、色合い調節可能な窓のゾーンで最終的な色合い状態を実施するための色合い命令を送信する。したがって、本明細書に記載されている窓制御システムは、建物、または建物の周りおよび内部の３Ｄパラメータを積極的にモデリングせず、それはオフラインで実行され、したがって、窓制御システムの演算能力を主に使用して、センサ、または窓制御システムへの他の入力に応じて、モデルから導出された色合い状態を適用する。
【０１００】
図８Ａは、様々な実施態様による、クラウドネットワーク８０１内で維持されるモデルを初期化およびカスタマイズする際に、かつモデルからの出力に基づいて建物の色合い調節可能な窓を制御する際に必要とされる、システムおよびユーザの一般的なアーキテクチャ８００を示す概略図である。このシステムアーキテクチャ８００は、クラウドベースの晴天モジュール８２０と通信するクラウドベースの３Ｄモデリングシステム８１０と、クラウドネットワークを介してこれらのモジュールのうちの一方または両方と通信する窓制御システム８４０と、を含む。クラウドベースの３Ｄモデリングシステム８１０は、建築現場の３Ｄモデルを初期化および／または修正することができ、３Ｄモデルから導出されたデータ（例えば、一定期間にわたって各ゾーンの色合い状態を有する晴天色合いスケジュール）をクラウドベースの晴天モジュール８２０に通信することができる。一実施態様では、３Ｄモデリングシステムが初期化した３Ｄモデルは、建築現場での周辺構造体および他の物体の外面、ならびに壁、床、および外面以外のすべてを取り除いた建物を含む。クラウドベースの晴天モジュール８２０は、属性を３Ｄモデルに割り当て、例えば、グレア／シャドーモデル、反射モデル、およびパッシブヒートモデルのうちの１つまたは複数などの晴天３Ｄモデルを生成することができる。クラウドベースのシステムは、アプリケーションプログラムインターフェース（ＡＰＩ）を使用して、クラウドネットワーク８０１を介して、互いに、かつ他のアプリケーションと通信する。クラウドベースの３Ｄモデリングシステム８１０、および晴天モジュール８２０の両方は、本明細書にさらに詳細に記載されているようなロジックを含む。これらのクラウドベースのモジュールおよび他のもののロジックは、クラウドネットワークのコンピュータ可読媒体（例えばメモリ）に格納されること、ならびにクラウドネットワーク内の１つまたは複数のプロセッサが、コンピュータ可読媒体と通信してそのロジックの機能を行うための命令を実行することが、理解されるであろう。
【０１０１】
制御アーキテクチャおよびモデルの多くの例は、クラウドネットワーク上に存在する３Ｄモデルプラットフォームおよび様々なモデルと一緒に本明細書に記載されているが、他の実施態様では、３Ｄモデルプラットフォーム、モデル、および制御モジュールのうちの１つまたは複数は、クラウドネットワーク上に存在しない。例えば、３Ｄモデルプラットフォーム、モデル、および制御モジュールのうちの１つまたは複数は、スタンドアロン型コンピュータ、または窓制御システム（例えば、窓制御システム８４０）とは別個であり、かつそれと通信する他のコンピューティングデバイス上に存在してもよい。代替的に、特定の実施態様では、制御ネットワークは、そのクラウドが、対象の建物、他の建物（複数可）、またはその建物と他の建物との組み合わせにおける窓制御システムおよび／またはＢＭＳの一部であるエッジクラウドネットワークであってもよい。
【０１０２】
図８Ａに戻ると、晴天モジュール８２０は、建築現場の３Ｄモデルを使用して、晴天条件下での太陽の異なる位置の時間経過シミュレーションを生成し、建築現場での物体からのシャドーおよび反射を判定することができる。例えば、晴天モジュール８２０は、光線追跡エンジンを使用して、晴天グレア／シャドーモデルおよび反射モデルを生成することができ、晴天モジュール８２０は、晴天条件下のシャドーおよび反射を考慮した建物の窓開口部を通過する太陽光の方向を判定することができる。晴天モジュール８２０は、このシャドーおよび反射ベースのデータを使用して、建物の占有領域（すなわち、おおむね占有者の位置）におけるグレア、反射、およびパッシブヒート条件の存在を判定する。クラウドベースの晴天モジュール８２０は、これらの条件が１年にわたる異なる時間間隔で存在するか否かに基づいて、建物のゾーンの各々の色合い状態の毎年のスケジュール（または他の期間）を判定する。このスケジュールはまた、本明細書では「晴天色合いスケジュール」とも称される。クラウドベースの晴天モジュール８２０は、通常、晴天色合いスケジュール情報を窓制御システム８４０にプッシュする。窓制御システム８４０は、例えば、図６および図７に記載されたネットワークなどの、窓コントローラのネットワークを含む。窓制御システム８４０は、第１番目のゾーン８７２から第ｎ番目のゾーン８７４までの一連のゾーンとして図８Ａに描かれている、建物内の色合い調節可能な窓のゾーンと通信する。窓制御システム８４０は、最終的な色合い状態を判定し、色合い調節可能な窓の色合い状態を制御するための色合い命令を送信する。特定の実施態様では、最終的な色合い状態は、晴天スケジュール情報に基づいて、またセンサデータおよび／または気象データに基づいて、判定される。図示されたシステムアーキテクチャ８００に関して上述したように、窓制御システム８４０は、積極的にモデルを生成せず、それ以外ではモデリングでの演算能力を浪費しない。これらのモデルは、建築現場に固有であり、クラウドネットワーク８０１内で作成、カスタマイズ、および保存される。定義済み晴天色合いスケジュールは、まず、窓制御システム８４０にプッシュされ、次いで３Ｄモデルへの更新が行われる場合にのみ、再度プッシュされる。例えば、建物のレイアウト、周辺エリアに新規物体などに行われる変更が存在する場合には、３Ｄモデルが更新される必要があり得る。
【０１０３】
システムアーキテクチャ８００はまた、顧客および他のユーザと通信して、３Ｄモデルのアプリケーションサービス、レポート、および視覚表現を提供し、３Ｄモデルをセットアップおよびカスタマイズするための入力を受信するためのグラフィカルユーザインターフェース（ＧＵＩ）８９０も含む。３Ｄモデルの視覚表現（本明細書では、また「３Ｄ建築現場視覚表現」とも称される）は、ユーザに提供されて、ＧＵＩ８９０を介してユーザから受信することができる。図示されたユーザは、建築現場でのトラブル対応に関与し、視覚表現を見直し、そして３Ｄモデルを編集する能力を有する現場操作８９２を含む。ユーザはまた、３Ｄモデルの視覚表現および現地での構成変更を見直す能力を有する顧客サクセスマネージャ（ＣＳＭ）８９４も含む。ユーザはまた、様々な顧客と通信する顧客（複数可）構成ポータル８９８も含む。この顧客（複数可）構成ポータル８９８を介して、顧客（複数可）は、３Ｄモデルにマッピングされたデータの様々な視覚表現を見直し、建築現場で構成を変更するための入力を提供することができる。ユーザからの入力のいくつかの例には、例えば、建物の占有エリア、建築現場での３Ｄ物体定義、特定の条件の色合い状態、および建物の条件の優先度を含む空間構成が含まれる。ユーザに提供される出力のいくつかの例には、３Ｄモデル上の色合い状態の視覚表現、標準レポート、および建物の性能評価などの、３Ｄモデルに関するデータの視覚表現が含まれる。特定のユーザが、例示的な目的のために描かれている。他のまたは追加のユーザが含まれ得ることが理解されるであろう。
【０１０４】
図８Ｂは、図８Ａに示したシステムアーキテクチャ８００のいくつかのシステム間で通信されるデータの流れの図解例である。示されるように、晴天モジュール８２０は、晴天モデルスケジュール情報を生成し、その情報を窓制御システム８４０にプッシュする。晴天モジュール８２０は、優先度データを条件値に適用することによって、時間間隔およびゾーン毎に色合い状態を生成するロジックを含む。窓制御システム８４０の制御ロジックは、各ゾーンの最終的な色合い状態を設定する。この例では、最終的な色合い状態は、晴天色合い状態と最大気象色合い状態との間の最小値として、ロジックによって判定される。最大気象色合い状態とは、モジュールＣによって判定される色合い状態と、モジュールＤによって判定される色合い状態との間の最大色合い状態である。他の実施態様では、晴天モジュール８２０のロジックは、他の方法を使用して最終的な色合い状態を判定する。
【０１０５】
Ａ．クラウドベースの３Ｄモデリングシステム
様々な実施態様では、システムアーキテクチャは、３Ｄモデリングプラットフォーム上に建築現場の３Ｄモデル（例えば、ソリッドモデル、表面モデル、またはワイヤフレームモデル）を生成することができるクラウドベースの３Ｄモデリングシステムを有する。様々な市販のプログラムが、３Ｄモデリングプラットフォームとして使用することができる。そのような市販のプログラムの例としては、ワシントン州シアトルのＭｃＮｅｅｌ  Ｎｏｒｔｈ  Ａｍｅｒｉｃａ社が製造しているＲｈｉｎｏ（登録商標）３Ｄソフトウェアがある。市販のプログラムの別の例としては、カリフォルニア州サンラファエルのＡｕｔｏｄｅｓｋ（登録商標）社によるＡｕｔｏｃａｄ（登録商標）コンピュータ支援設計および製図ソフトウェアがある。
【０１０６】
この３Ｄモデルは、色合い調節可能な窓を有する建物の現場での建物および他の物体の３次元表現である。建築現場は、概して、対象の建物を取り巻く領域を指す。この領域は、通常、建物上にシャドーまたは反射を生じさせ得る建物を取り巻くすべての物体を含むように定義される。３Ｄモデルには、建物の外面、および建物を取り巻く他の物体の３次元表現、また壁、床、および外面以外の建物のすべての表面を取り除いた建物の３次元表現が含まれる。３Ｄモデリングシステムは、３Ｄモデルを生成することができ、例えば、Ｒｅｖｉｔまたは他の業界標準の建物モデルなどの標準建物モデルを自動的に使用して、壁、床、および窓開口部を有する外面を除くすべての建物の表面のモデリングされた建物を取り除く。３Ｄモデル内の、外面を除くすべての要素のうちのいずれの他の物体も自動的に取り除かれることになる。別の例として、３Ｄモデルは、３Ｄモデリングソフトウェアを使用してゼロから生成されることができる。３つの建物を有する建築現場９０１の３Ｄモデルの一例が、図９に示されている。
【０１０７】
Ｂ．クラウドベースの晴天モジュール
近年の大規模な建物において、ときには「スマートウィンドウ」と称されるエレクトロクロミック窓などの多数の色合い調節可能な窓を取り付けたことによって、大規模なコンピューティングリソースを必要とし得る複雑な制御および監視システムの必要性が高まっている。例えば、大規模な建物に採用された多数の色合い調節可能な窓は、複雑でメモリ負荷の高い反射モデルおよびグレアモデルを必要とすることになる膨大な数のゾーン（例えば、１０，０００個）を有し得る。これらの色合い調節可能な窓は、受け入れられ続け、より広く展開されているため、それらの窓は、大量のデータの保存および操作を伴うことになる、より高度な制御システムおよびモデルを必要とすることになる。
【０１０８】
本明細書に記載されているシステムアーキテクチャは、３Ｄモデリングプラットフォーム上にクラウドベースのモジュールを実装して、クラウドネットワーク上に保存および維持される晴天３Ｄモデルを生成する。これらの晴天モデルは、例えば、建築現場での晴天条件に基づいているグレア／シャドーモデル、反射モデル、およびパッシブヒートモデルを含む。晴天条件下での上空の１つの位置にある太陽と共に、図９の建築現場９０１のグレア／シャドーモデルの視覚表現の一例が、図１０に示されている。このグレア／シャドーモデルを使用して、特定の時間間隔で対象の建物の窓開口部に入射する直射太陽光（周辺物体によっては、遮られない）を判定することができる。図１１は、図１０に描かれている同じ条件下での、建物の反射モデルの視覚表現の一例である。図１０および図１１に示したグレアおよび反射モデルは、３つのモデリングされた建物の外面に割り当てられた反射特性などの属性を有する、図９に示した建築現場９０１の晴天３Ｄモデルに基づいている。晴天モジュールは、図１０に示したグレア／シャドーモデルのシミュレーションからのデータを使用して、その時間間隔でのグレア条件を判定することができる。晴天モジュールは、図１１に示した反射モデルのシミュレーションからのデータを使用して、その時間間隔での直接反射条件を判定することができる。
【０１０９】
晴天モジュールは、属性を３Ｄモデルに割り当てるように実装されて、晴天３Ｄモデルを生成することができるロジックを含む。晴天モジュールはまた、他のモデルを生成するために使用されて、例えば、グレア／シャドーモデル、反射モデル、およびパッシブヒートモデルなどの様々な条件を判定することができるロジックも含む。建築現場９０１のこれらのモデルを使用して、建物のゾーンの色合い状態の年間スケジュールを生成することができ、その年間スケジュールは、建物の窓制御システムにプッシュされて、最終的な色付けの決定を行う。このシステムアーキテクチャでは、ほとんどのデータが、クラウドネットワーク上に保持される。モデルをクラウドネットワーク上に保持することにより、顧客および他のユーザへのアクセス、ならびに顧客および他のユーザによるカスタマイズを容易にすることができる。例えば、様々なモデルの視覚表現は、ユーザに送信されて、ユーザが入力を見直しおよび送信し、例えば、モデルをセットアップおよびカスタマイズし、かつ／または晴天色合いスケジュールもしくは建物の他のシステム機能において最終的な色合い状態をオーバライドするのを可能にすることができる。例えば、視覚表現は、ユーザによって使用されて、現場のセットアップまたはカスタマイズの一部としてゾーン管理および窓管理などにおける晴天モデルに属性を割り当てることができる。
【０１１０】
Ｃ．現場のセットアップおよびカスタマイズのためのグラフィカルユーザインターフェース（ＧＵＩ）
システムアーキテクチャはまた、様々な顧客および他のユーザにインターフェース接続するためのＧＵＩも含む。このＧＵＩは、アプリケーションサービスまたはレポートをユーザに提供し、ユーザから様々なモデルのための入力を受信することができる。ＧＵＩは、例えば、様々なモデルの視覚表現をユーザに提供することができる。ＧＵＩはまた、ゾーン管理、窓管理、および占有領域定義のためのインターフェースを提供して晴天モデルをセットアップすることもできる。ＧＵＩはまた、優先度データ、外面の反射特性、オーバライド値、および他のデータを入力するためのインターフェースを提供することもできる。さらに、ユーザは、ＧＵＩを使用して、例えば、建築現場の晴天モデルの視覚表現を閲覧した後に、３Ｄモデルの空間をカスタマイズすることができる。カスタマイズのいくつかの例としては、以下が含まれる。
●反射、グレア、およびヒート条件、または建物のゾーンの色付けに対する変更を確認するために、建築現場を再構築する（建物を移動させ、外面特性を修正する）
●変更が色合い状態にどのように影響を及ぼすかを確認するために、建物の内部構造（壁、床）および外殻を再構築する
●窓のゾーンを管理する
●反射特性の変更、ならびに反射モデルおよび色合い状態の対応する変更を確認するために、建物で使用されている材料を変更する
●建物の３Ｄモデルにマッピングされたときの、色合い状態の変化を確認するために、色付け優先度を変更する
●スケジュールデータの色合い状態をオーバライドする
●建築現場で建物を修正する
●新しい条件のモデルを追加する
【０１１１】
Ｄ．窓制御システム
本明細書に記載されているシステムアーキテクチャは、建物の色合い調節可能な窓のゾーンの色合いレベルを制御する窓コントローラのネットワークを含む窓制御システムを含む。システムアーキテクチャの窓制御システムに含まれ得るコントローラのいくつかの例が、図６および図７に関連して説明されている。その窓制御システムに含まれ得る窓コントローラの他の例が、２０１６年１０月２６日に出願された「ＣＯＮＴＲＯＬＬＥＲＳ  ＦＯＲ  ＯＰＴＩＣＡＬＬＹ−ＳＷＩＴＣＨＡＢＬＥ  ＤＥＶＩＣＥＳ」と題する米国特許出願１５／３３４，８３５に記載されており、これは、その全体が参照により本明細書に組み込まれる。
【０１１２】
窓制御システムは、色付けを決定し、色合い命令を送信して窓の色合いレベルを変更するための制御ロジックを含む。特定の実施形態では、制御ロジックは、赤外線センサおよび／または光センサ測定値に基づいて、各ゾーンの色合いレベルを判定するモジュールＣおよびモジュールＤのロジックを含む。上で説明したように、晴天モデルスケジュール情報は、窓制御システムにプッシュされる。一実施態様では、窓制御システムの制御ロジックは、年間のスケジュール情報からの色合い状態と、モジュールＣ／Ｄからの最大色合い状態との間の最小値として、最終的な色合い状態を判定する。
【０１１３】
上述したように、本明細書に記載されているシステムアーキテクチャの窓制御システムは、モデルを生成しない。制御アーキテクチャによって維持されるモデルは、建築現場に固有であり、クラウドベースのモジュールによってクラウドネットワーク内に維持される。
【０１１４】
Ｅ．システムアーキテクチャの一般的なプロセス
上で説明したように、図８Ｂは、システムアーキテクチャ８００のシステムのいくつかのシステム間で通信されるデータの流れの図解例である。示されるように、晴天モジュール８２０は、晴天モデルスケジュール情報を生成し、その情報を窓制御システム８４０にプッシュする。晴天モジュール８２０は、優先度データを条件値に適用することによって、時間間隔およびゾーン毎に色合い状態を生成するロジックを含む。窓制御システム８４０の制御ロジックは、各ゾーンの最終的な色合い状態を設定する。この例では、最終的な色合い状態は、晴天色合い状態と最大気象色合い状態との間の最小値として、ロジックによって判定される。最大気象色合い状態とは、モジュールＣによって判定される色合い状態と、モジュールＤによって判定される色合い状態との間の最大色合い状態である。他の実施態様では、晴天モジュール８２０のロジックは、他の方法を使用して最終的な色合い状態を判定する。
【０１１５】
図１２は、晴天モジュールによって実装されて、晴天条件（本明細書ではまた、「晴天色合いスケジュール情報」とも称される）に基づいて、色合いスケジュール情報を生成する特定のロジック演算の一例の概略図である。この図示された例では、晴天モジュールは、各条件に割り当てられた色合い状態を条件値に適用し、次いで優先度データからの優先度を適用して特定の時間での各ゾーンの色合い状態を判定する。別の例では、晴天モジュールは、優先度データからの優先度を条件値に適用して適合する条件を判定し、次いで色合い状態を当該条件に適用して特定の時間間隔での各ゾーンの色合い状態を判定することができる。
【０１１６】
図１２において、上部の表（「表１」）は、晴天モジュールによって判定された条件値の表の一例であり、１日の朝の間に異なる時間間隔で建物のゾーン１のグレア条件、直接反射条件、およびパッシブヒート条件の値を含む。この例では、条件値は、条件が昼間の間の異なる時間に存在するかどうかに関するバイナリ値（０または１）、すなわち「０−条件は存在せず、１−条件は存在する」である。図１２はまた、各条件（グレア、反射、パッシブヒート）の場合に、各ゾーンに割り当てられた色合い状態の一例である第２の表（「表２」）を含む。例えば、ゾーン１は、グレア条件の色合い４に割り当てられ、ゾーン１は、反射条件の色合い３に割り当てられ、ゾーン１は、パッシブヒート条件の色合い２に割り当てられる。条件が当てはまる場合、晴天モジュールは、当該条件に該当する色合い状態を割り当てる。優先度データは、通常、建物の各ゾーンでの条件（グレア、反射、パッシブヒート）の各々の優先度のリストを参照する。優先度データは、特定の場合には、ユーザによって構成可能であり得る。図１２に示す第３の表（「表３」）は、各ゾーンの条件に優先度を割り当てて、晴天モジュールにどの条件が優先するかを知らせる構成可能な優先度表（例えば、ユーザによって構成可能）の一例である。この例では、建物の各ゾーンのグレア条件、直接反射条件、およびパッシブヒート条件の優先度が与えられる。図１２はまた、４つの曲線がプロットされたグラフも含む。最初の曲線（「ゾーン１グレア」）は、表２のグレア条件に割り当てられた色合い状態を、表１が１日にわたって適用した条件値に適用することに基づいた、１日にわたるゾーン１での晴天色合い状態である。２番目の曲線（「ゾーン１反射」）は、表２の反射条件に割り当てられた色合い状態を、表１が１日にわたって適用した条件値に適用することに基づいた、１日にわたるゾーン１での晴天色合い状態である。３番目の曲線（「ゾーン１パッシブヒート」）は、表２のパッシブヒート条件に割り当てられた色合い状態を、表１が１日にわたって適用した条件値に適用することに基づいた、１日にわたるゾーン１での晴天色合い状態である。４番目の曲線（「優先度制約」）は、表２の各条件（グレア、反射、パッシブヒート）に割り当てられた色合い状態を、表１が１日にわたって適用した条件値に適用することによって判定された色合い状態に適用される表３からの優先度データに基づいた、１日にわたるゾーン１での晴天色合い状態である。
【０１１７】
図１３は、一実施態様のシステムアーキテクチャのクラウドベースのシステムを介するモデルデータフローの概略図である。この３Ｄモデルは、３Ｄプラットフォーム上で生成される。３Ｄモデルの図解例を図９に示す。３Ｄモデルは、窓開口部、壁、および床が定義された、対象の建物の３Ｄバージョンを含む。周辺物体の外面、およびそれらの反射特性が、３Ｄプラットフォーム上の３Ｄモデルに追加される。３Ｄモデルの窓開口部は、各ゾーンにグループ化され、３Ｄプラットフォーム上で名前が付与される。情報は、ユーザから、例えば、ＧＵＩを介して受信される。例えば、ユーザは、占有位置の２Ｄエリアを強調表示または識別することができ、かつ／または建物の３Ｄモデルの空間の床上で、もしくは３Ｄモデルを生成するために使用される建築モデル内で、これらの占有位置の所望の色合い状態を識別することができる。ユーザはまた、ＧＵＩを使用して、例えば、直射グレア条件および反射条件などの各条件に関連付けられる、各占有領域の色合い状態を定義することもできる。ユーザはまた、ユーザの目の高さの値を入力することもできる。ユーザの目の高さのこの値を使用して、占有位置の２Ｄエリアの３Ｄ押し出しを生成し、占有領域の３Ｄ体積を判定することができる。晴天モジュールのロジックを使用して、例えば、グレア／シャドーモデル、反射モデル、およびヒートモデルを含む様々な条件モデルを生成することができる。グレア／シャドーモデルおよび反射モデルの図解例が、図１０および図１１に、それぞれ示されている。条件モデルを使用して、窓制御システムと通信される晴天色合いスケジュール情報を生成することができる。
【０１１８】
ＩＩＩ．晴天モジュール−モジュールのセットアップ／カスタマイズ、およびスケジューリング情報の生成
建築現場の３Ｄモデルは、現場のセットアッププロセス中に初期化される。いくつかの実施態様では、ユーザは、例えば、ＧＵＩを介して、３Ｄモデルを修正する能力を与えられて、建物内の色合い調節可能な窓および／または他のシステムの制御をカスタマイズする。これらのカスタマイズは、３Ｄモデリングプラットフォームを使用した視覚表現を介して、ユーザによって見直しすることができる。例えば、顧客または他のユーザは、カスタマイズ後に、何が建築現場のために設計されたのか、またそれが所与の日にどのように動作し、「その場合、どんな」シナリオが提供されるのかを閲覧することができる。また、異なるユーザが、クラウドネットワーク上に保存された同じ３Ｄモデルを見直して、複数のユーザにサービスすることになるオプションを比較および検討することができる。例えば、顧客サクセスマネージャ（ＣＳＭ）は、ユーザの位置、条件による色合い状態、優先度、および晴天条件中の、施設管理者との予想される行動を見直すことができる。現場のセットアッププロセスには、建築現場の３Ｄモデルを生成することと、属性を３Ｄモデルの要素に割り当てることと、が含まれる。３Ｄモデルプラットフォームは、通常、対象の建物の建築モデルから不要な特徴を取り除き、建物を取り巻く物体の外面を作成することによって、建築現場の３Ｄモデルを生成するために使用される。
【０１１９】
図１４は、様々な実施態様による、３Ｄモデルプラットフォーム上の３Ｄモデルを初期化する際に必要とされる一般的な操作を示すフローチャートである。一実施態様では、３Ｄモデルは、色合い調節可能な窓を有する建物の窓開口部、壁、床、および外面を表す構造上の要素以外のすべての建築モデルを取り除くことによって、建物の建築モデル、および／または周辺構造から自動的に生成される。例えば、建物のＡｕｔｏｄｅｓｋ（登録商標）Ｒｅｖｉｔモデルを受け取って、壁、床、および窓開口部を含む外面を除くすべての要素を取り除くことができる。これらの動作は、３Ｄモデリングシステムによって実装され得る。図１４において、３Ｄモデリングシステムは、色合い調節可能な窓、およびまたデータ、場合によっては、構造、および建築現場で建物を取り巻く他の物体の同じまたは異なる建築モデルを有する建物の建築モデルを受け取る（１４１０）。動作１４２０において、３Ｄモデリングシステムは、色合い調節可能な窓を有する建物の窓開口部、壁、床、および外面を表現する構造上の要素以外のすべてを取り除く。動作１４３０において、３Ｄモデリングシステムは、建物の外面、および建物を取り巻く他の物体を構築するか、または外面以外の周辺物体からすべての要素を取り除く。動作１４３０の出力は、建築現場の３Ｄモデルである。建築現場の３Ｄモデルの一例が、図９に示されている。
【０１２０】
図１５は、特定の実施態様による、３Ｄモデルに属性を割り当てることと、条件モデルを生成することと、晴天色合いスケジューリング情報の生成に関連する他の動作と、に必要とされる一般的な動作を示すフローチャートである。これらの動作のうちの１つまたは複数は、晴天モジュールのロジックを使用して実装され得る。図示してあるように、動作のための入力は、３Ｄモデリングシステム（例えば、図８Ａ中の３Ｄモデリングシステム８１０）からの建築現場の３Ｄモデルである。動作１５１０において、反射または非反射特性は、建築現場の３Ｄモデル内の建物を取り巻く任意の物体の表面要素に割り当てられている。これらの反射特性を使用して、反射モデルを生成し、条件を評価する。
【０１２１】
動作１５２０において、固有の窓ＩＤが、３Ｄモデル内の対象の建物の各窓開口部に割り当てられる。この窓管理動作では、窓開口部は、固有の窓／コントローラＩＤにマッピングされる。一実施態様では、これらのマッピングは、建物の設置での窓の試運転の入力に基づいて、検証および／または修正され得る。
【０１２２】
動作１５３０において、３Ｄモデル内の窓開口部は、ゾーンにグループ化され、ゾーンＩＤおよび／またはゾーンの名前が、ゾーンに割り当てられる。このゾーン管理動作では、３Ｄモデル内の対象の建物の窓開口部が、ゾーンにマッピングされる。各ゾーンは、１つまたは複数の窓開口部にマッピングされる。
【０１２３】
動作１５４０において、３Ｄモデル内の対象の建物内の１つまたは複数の３Ｄ占有領域が、判定される。例えば、ユーザは、２次元（２Ｄ）エリアを３Ｄモデルの床上の占有エリアとして識別／定義することもでき、また各占有エリアに関連付けられた占有者の目の高さを定義することもできる。晴天モジュールのロジックは、その床から定義された目の高さまでの各２Ｄ占有エリアの押し出しを生成して、３Ｄモデルの３Ｄ占有領域を生成することができる。
【０１２４】
動作１５５０において、適用されることになる晴天モデルが判定され、その晴天モデルは、実行されて、窓開口部を通る太陽光の３Ｄ投射を判定する。このモデル管理動作では、様々な晴天モデル、例えば、グレア／シャドーモデルおよび反射モデルが、生成される。晴天モジュールは、光線追跡エンジンを含み、この光線追跡エンジンを使用して、１年または他の期間のうちの１日全体にわたる上空の太陽の異なる位置に基づいて、太陽光の光線の方向を判定することができる。また、光線追跡エンジンを使用して、建物を取り巻く物体の外面の位置および反射特性から、対象の建物を取り巻く物体からの反射光の反射方向および強度を判定することもできる。これらの判定から、３Ｄモデルにおける窓開口部を通る太陽光の３Ｄ投射を判定することができる。
【０１２５】
動作１５６０において、窓開口部を通る太陽光の３Ｄ投射の、３Ｄ占有領域（複数可）との任意の交差の量および持続期間が判定される。１日の各時間間隔で、晴天モデルが実行され、窓開口部を通る太陽光の３Ｄ投射、および判定された３Ｄ投射の、３Ｄ占有領域（複数可）との任意の交差の量が判定される。各時間間隔で交差の量を判定することによって、交差の持続期間を判定することができる。
【０１２６】
動作１５７０において、それらの条件は、動作１５６０で判定された交差特性に基づいて評価される。例えば、特定のゾーンのグレア／条件のための値が、窓開口部を通る判定された３Ｄ投射の、そのゾーンの３Ｄ占有領域（複数可）との任意の交差の量および持続時間に基づいて判定され得る。
【０１２７】
動作１５８０において、優先度データは、動作１５７０で評価された条件値に適用されて、例えば、毎年のスケジュールの中で経時的に建物の各ゾーンの色合い状態を判定する。例えば、図１２に関して説明されたプロセスを、一実施態様において使用して、時間間隔にわたって各ゾーンの色合い状態を判定することができる。晴天条件に基づくこれらの色合い状態は、窓制御システムに通信されて、色合い調節可能な窓で実施される最終的な色付けを決定する。
【０１２８】
Ａ．窓管理
建築現場の３Ｄモデルのセットアップ中に、各窓開口部は、ローカルな窓コントローラに対応する固有の窓ｉｄが割り当てられる。窓開口部を窓ｉｄに割り当てることにより、窓開口部を単一の窓コントローラにマッピングする。各窓ｉｄは、ゾーンにグループ化され得る各窓コントローラを効果的に表す。代替的に、または追加的に、建物の窓およびそれらのコントローラを設置した後に、動作を試運転して、どの窓がどの位置に設定され、どの窓コントローラとペアになるのかを判定することができる。次いで、これらの試運転プロセスからの関連付けを使用して、３Ｄモデルのマッピングと比較および検証を行うことができ、または３Ｄモデルの構成データのマッピングを更新することができる。そのようなマッピングを判定するために使用され得る試運転プロセスの一例が、２０１７年１１月１１日に出願された「ＡＵＴＯＭＡＴＥＤ  ＣＯＭＭＩＳＳＩＯＮＩＮＧ  ＯＦ  ＣＯＮＴＲＯＬＬＥＲＳ  ＩＮ  Ａ  ＷＩＮＤＯＷ  ＮＥＴＷＯＲＫ」と題する国際出願ＰＣＴ／ＵＳ２０１７／０６２６３４に記載されており、これは、その全体が参照により本明細書に組み込まれる。各窓開口部の、窓ＩＤへのマッピングはまた、ユーザのカスタマイズに基づいて、修正することができる。
【０１２９】
一実施態様では、ユーザは、３Ｄモデルプラットフォーム上の３Ｄモデルで窓開口部を選択し、固有の窓ｉｄを割り当てることができる。図１６は、３Ｄモデルにおける対象の建物の床の１４個（１４）の窓開口部に適用されるような実施態様の一例である。示されるように、ユーザは、これらの窓開口部に窓ｉｄ１〜１４を割り当てた。
【０１３０】
Ｂ．ゾーン管理
建物の各ゾーンは、１つまたは複数の色合い調節可能な窓を含む。色合い調節可能な窓は、３Ｄモデルにおいて開口部として表される。各ゾーンの１つまたは複数の色合い調節可能な窓は、同じように動作するように制御されることになる（例えば、同じ終了色合い状態に移行される）。これは、ゾーン内の色合い調節可能な窓のうちの１つに関連付けられた占有領域（複数可）が特定の条件を経験する場合、すべての色合い調節可能な窓が、制御されてその条件に反応することになることを意味する。３Ｄモデルの属性を有する構成データは、ゾーンの名前、ゾーンの代表的な窓のＳＨＧＣ値、および内部放射の最大値のうちの１つまたは複数などのゾーン特性を含む。
【０１３１】
３Ｄモデルの現場のセットアップまたはカスタマイズの一部としてのゾーン管理の間中、ユーザが、ゾーンで一緒にグループ化されることになる窓開口部を定義し、その定義されたゾーンに特性を割り当てることができる。図１７Ａは、３Ｄモデリングプラットフォーム上のグラフィカルインターフェースの図解例であり、このインターフェースにより、ユーザが図１６に示された１４個（１４）の窓開口部から１つまたは複数の窓開口部を選択して、ゾーンとして一緒にグループ化（ゾーンにマッピング）し、そしてそのゾーンに名前を付けることを可能にする。このことは、任意の数のゾーンについて行うことができる。この例では、窓開口部１、２、および３は、「ゾーン１」として定義され、窓開口部４〜７は、「ゾーン２」として定義され、窓開口部８〜１４は、「ゾーン３」として定義される。
【０１３２】
一実施態様では、ユーザは、複数のゾーンを選択し、一緒にグループ化することができ、その結果、複数のゾーンは、同じように動作する。図１７Ｂは、３Ｄモデリングプラットフォーム上のグラフィカルインターフェースの図解例であり、これにより、ユーザが図１７Ａから「ゾーン１」および「ゾーン２」を選択して一緒にグループ化するのを可能にする。示されるように、「ゾーン１」および「ゾーン２」は、一緒にグループ化され、そして同じ方法で制御される。一緒にグループ化されたゾーンの各々は、それらのゾーン名、ＩＤ、および関連付けられた窓ＩＤを保持する。
【０１３３】
図１８は、ユーザが３Ｄモデルのマッピングされていない空間を特定の定義されたゾーンにマッピングするために使用することができるインターフェースの一例である。示されるように、ユーザは、「ゾーン１」にマッピングされるように「オフィス１」、「オフィス２」、「オフィス３」、および「オフィス４」の空間を選択した。この例では、これらの空間に関連付けられた窓は、「ゾーン１」に関連付けられることになる。一態様では、ユーザは、「マッピングを見直す」ボタンを選択して、建築現場の３Ｄモデル上の「ゾーン１」の空間のマッピングされた窓を視覚化することができる。
【０１３４】
ゾーン管理中、各ゾーンは、ゾーン特性が割り当てられる。ゾーン特性のいくつかの例としては、ゾーン名（ユーザ定義された）、ゾーンｉｄ（システム生成された）、窓のＩＤ、ガラスＳＨＧＣ、ワット毎平方メートルで表される空間への最大許容放射が含まれる。図１９は、図１６に示した１４個（１４）の窓開口部からの窓開口部の各ゾーンに割り当てられた特性を見直すことによって使用され得るインターフェースの一例である。この例では、ユーザは、「ゾーン１」を選択して、当該ゾーンＩＤ、ゾーン名、ゾーン内の窓のＩＤ、ガラスＳＨＧＣ値、および最大許容放射を表示することができる。
【０１３５】
Ｃ．３Ｄ占有領域の生成
本明細書で使用されるように、占有領域とは、特定の期間の間、占有される可能性がある３次元体積を指す。占有領域は、現場のセットアップ中に定義され、カスタマイズ中に再定義することができる。特定の実施態様では、占有領域を定義することは、表面（例えば、床）上の２次元占有エリアを占有者の目の高さの垂直平面に押し出し、そして特性を３Ｄ占有領域に割り当てることによって、３次元体積を定義することを含む。特性のいくつかの例には、占有領域名称、グレア色合い状態（グレア条件が存在する場合の色合い状態）、直接反射色合い状態（直接反射放射の異なるレベルの色合い状態）、および間接反射色合い状態（間接反射放射の異なるレベルの色合い状態）が含まれる。
【０１３６】
特定の実施態様では、占有領域が、３Ｄモデリングプラットフォーム上で生成される。ユーザは、ユーザ位置もしくは活動エリアを、２次元形状（例えば、多角形）、または３Ｄモデルの床もしくは他の表面（例えば、机上）の上の形状として、描くか、または定義し、また占有者の目の高さも定義する。３Ｄモデルの床に描かれた２次元の４つの側面のユーザ位置の一例が、図２０Ａに示されている。晴天モジュールは、表面から占有者の目の高さ（例えば、下方の目の高さ、または上方の目の高さ）までの２次元形状の押し出しとして３次元占有領域を定義する。図２０Ａの２次元物体を上方の目の高さまで押し出すことによって生成された３次元占有領域の一例が、図２０Ｂに示されている。
【０１３７】
Ｄ．晴天モデル
特定の実施態様では、グレア／シャドーモデル、直接反射モデル、および間接反射モデルが、建築現場の３Ｄモデルに基づいて生成される。これらのモデルを使用して、晴天の条件に基づいて、３Ｄモデル内の対象の建物の窓開口部を通る太陽光の３Ｄ投射を、経時的に判定することができる。光線追跡エンジンを使用して、各時間間隔の間で太陽の位置での太陽光の光線の方向をシミュレーションする。このシミュレーションを実行して、基本的なグレア条件（占有領域と交差する直接放射）、直接反射グレア条件（直接反射面から占有領域への単一のはね返り反射）、間接反射グレア条件（間接反射面（複数可）から占有領域への多重はね返り反射）などの、建物のゾーンの各々における異なるグレア条件を評価する。このシミュレーションは、晴天条件を前提とし、空間上のシャドー、および建物を取り巻く外部物体による反射を考慮に入れている。このシミュレーションは、１年または他の期間にわたる時間間隔でのグレアおよび他の条件の値を判定する。晴天色合いスケジュールデータには、１年などの期間にわたる各時間間隔（例えば、１０分毎）の条件および／または色合い状態の各々の値が含まれる。
【０１３８】
一般に、晴天モジュールは、異なる条件（例えば、グレア、反射、パッシブヒート）が、１年などの期間の各時間間隔（例えば、１０分毎）で建物の各ゾーンに存在するかどうかを判定するためのロジックを含む。晴天モジュールは、これらの条件の値の色合いスケジュール情報、および／または各時間間隔の各ゾーンの関連付けられた色合い状態を出力する。ある条件の値は、例えば、１（条件が存在する）または０（条件が存しない）のバイナリ値であってもよい。場合によっては、晴天モジュールには、異なる時間での太陽の位置に基づいて、太陽光の光線の方向（直射または反射）を判定する光線追跡エンジンが含まれる。
【０１３９】
一態様では、グレア条件は、単一の占有領域のモデルからの複数のグレアエリアに基づいて評価される。例えば、光投射は、単一の占有領域内の異なる占有エリアと交差する場合がある。一態様では、条件は、単一のゾーン内の複数の高度に基づいて評価される。
【０１４０】
−グレア制御
特定の実施態様では、グレア条件の判定は、グレア（シャドーのない）モデルおよび／または直接反射（１回のはね返り）モデルからの太陽光の３Ｄ投射の、３次元占有領域との交差に基づいて行われる。グレアモデルからの基本的なグレアの明確な判定は、３Ｄ占有領域との全交差の％と、交差の持続時間との関数である。反射モデルに基づく反射グレアの判定は、交差の持続時間の関数である。晴天モジュールは、グレア（シャドーのない）モデルに基づくグレア条件の存在（明確な判定）、および／または建物に対する周辺物体に基づく直接反射（１回のはね返り）モデルを評価するためのロジックを含む。
【０１４１】
一実施態様によれば、各ゾーンについて、ロジックは、ゾーンの窓開口部を通る直射太陽光の３Ｄ投射がゾーン内の任意の３次元占有領域と交差するかどうかを、グレアモデルから判定する。交差の％が全交差の最小％よりも大きく（グレア条件前の窓投射から占有領域に重なる最小閾値が考慮されている）、および交差の持続時間が交差の最小持続時間よりも長い場合（交差の時間の最小量は、その量が顕著になる前に生じる必要がある）は、グレア条件値（例えば、１）、およびグレア条件に関連付けられた色合い状態は返される。ロジックが、グレアモデルから、窓開口部を通る直射太陽光の３Ｄ投射がゾーン内で３次元占有領域のいずれにも交差しない、例えば、ゾーンがシャドー内にあると判定した場合は、グレア条件値（例えば、０）、およびグレア条件に関連付けられていない色合い状態が返される。そのロジックは、一緒にリンクされている可能性がある、ゾーンの最大の色合い状態を取る。交差が何もない場合、最低の色合い状態が返される（例えば、色合い１）。
【０１４２】
別の実施態様では、ロジックは、太陽が３次元占有領域のいずれかと直接交差している場合、各時間間隔に、色合い調節可能な窓の各ゾーン（窓開口部の集合）について判定する。占有領域のいずれかが同時に交差されている場合、出力は、その条件が存在することを示す。占有領域のいずれも交差していない場合、その条件は、存在しない。
【０１４３】
図２１は、基本的なグレアに基づいて、グレア条件を返さなかったグレア／シャドーモデルのシミュレーションを使用した一例である。この例では、シミュレーションは、３Ｄ占有領域とのグレアの少ない交差全体を生成し、グレアは、１日全体を通じて長くは存在しなかったため、晴天モジュールは、グレア条件を返さなかった。
【０１４４】
図２２は、直接１回はね返り反射からのグレアに基づいて、グレア条件を返した直接反射（１回はね返り）モデルのシミュレーションを使用した一例である。この例では、シミュレーションは、３Ｄ占有領域との高い交差全体を生成し、グレアの長期間がこの日に生じたため、グレア値が返された。
【０１４５】
−反射放射制御
晴天モジュールには、モデルに基づいて、晴天条件下での反射条件の存在を評価し、内部放射を最大許容内部放射未満に保つように最低状態を判定するためのロジックが含まれる。このロジックは、ゾーンの窓開口部に達する直接の通常の放射に基づいて、放射条件を判定する。ロジックは、その通常の放射を当該ゾーンに対して定義された閾値未満に保つことができる最も透明な色合い状態に基づいて、色合い状態を判定する。
【０１４６】
ロジックは、３Ｄモデルから色合い調節可能な窓への外部の通常放射を判定し、判定された外部放射レベルにガラスＳＨＧＣを乗じることによって、各色合い状態の内部放射を計算する。ロジックは、ゾーンの最大内部放射を、色合い状態の各々の計算された内部放射と比較し、当該ゾーンの最大内部放射未満であると計算された最も明るい色合い状態を選択する。例えば、モデルからの外部垂直放射は、８００であり、最大内部放射は、２００であり、Ｔ１＝０．５、Ｔ２＝０．２５、およびＴ３＝０．１である。ロジックは、外部放射の判定されたレベルにガラスＳＨＧＣを乗じることによって、各色合い状態の内部放射を計算した結果、Ｃａｌｃ  Ｔ１（８００）＊０．５＝４００、Ｃａｌｃ  Ｔ２（８００）＊０．２５＝２００、およびＣａｌｃ  Ｔ３（８００）＊０．１＝８０であった。ロジックは、Ｔ２がＴ３よりも小さいため、Ｔ２を選択することになる。
【０１４７】
別の実施態様では、ロジックは、太陽が外部物体からの単一のはね返りを有する場合に、窓の各ゾーン（開口部の集合）について判定する。占有領域のいずれかに反射が存在する場合、反射条件が存在する。反射が占有領域のいずれにも存在しない場合、反射条件は存在しない。
【０１４８】
−パッシブヒート制御
特定の実施態様では、晴天モジュールには、晴天モデルからの出力に基づいて、ゾーンの窓にさらに暗い色付け状態を設定するパッシブヒート条件の存在を評価するためのロジックが含まれる。このロジックは、晴天モデルから晴天条件下での色合い調節可能な窓に達する外部太陽放射を判定する。ロジックは、色合い調節可能な窓への外部放射に基づいて、部屋に入る推定された晴天ヒートを判定する。ロジックが、部屋に入る推定された晴天ヒートが最大許容値よりも大きいと判定した場合、パッシブヒート条件は存在し、パッシブヒート条件に基づいて、さらに暗い色合い状態がゾーンに設定される。この最大許容値は、建物の外部温度、および／またはユーザ入力に基づいて、設定されてもよい。一例では、外部温度が低い場合、最大許容外部放射は、非常に高く設定されて、建物空間に入るパッシブヒートのレベルを高めることを可能にすることができる。
【０１４９】
Ｅ．建築現場の晴天モデルのカスタマイズ
図２３は、一態様による、建築現場の晴天３Ｄモデルをカスタマイズするためのユーザ入力を実施するための動作およびプロセスのフローチャートである。これらの現場編集動作は、晴天モジュールのロジックによって実施することができる。晴天モデルの属性は、いつでも編集可能（カスタマイズ可能）であり、定義／再定義することができる。ユーザは、例えばＧＵＩを介して、入力を入れることができる。このフローチャートでは、プロセスは、３Ｄモデルを開くことによって開始される（２２０２）。次いで、ユーザは、編集するゾーン、または編集するユーザ位置を選択するオプションを有する（２２１０、２２２０）。ユーザがゾーンを編集することを選択した場合、ユーザは、当該ゾーンに定義された窓を再グループ化し（２２１２）、ゾーンに新しい名前を付け（２２１４）、かつ／またはゾーンの許容内部放射もしくは他の特性を編集することができる（２２１６）。ユーザがユーザ位置を編集することを選択した場合（２２２０）、ユーザは、ユーザの基本設定を編集して、グレアモデルまたは反射モデルを選択してユーザ位置にマッピングし（２２２２）、かつ／またはユーザ位置を削除するか（２２２４）、もしくはユーザ位置を追加する（２２２６）。１つまたは複数の編集が行われると、ユーザは、その変更を登録して、建築現場の晴天３Ｄモデルを更新する（２２３０）。それらの変更を使用して、修正された晴天３Ｄモデルに基づいて新しいスケジュールデータを生成し、そのスケジュールデータは、エクスポートされ、窓制御モジュールに通信される（２２４０）。
【０１５０】
Ｆ．視覚表現
特定の実施態様では、システムアーキテクチャには、ＧＵＩが含まれ、このＧＵＩにより、ユーザが晴天モデルの属性の変更を行って、モデルの変更、および／または３Ｄモデリングプラットフォーム上の視覚表現におけるスケジュールデータの変更を確認することができる。３Ｄモデリングプラットフォーム上の建築現場の視覚表現は、カスタマイズの目的のために使用することができる。
【０１５１】
一態様では、ユーザは、グレア／シャドー晴天モデルからゾーンまたはゾーングループ、および日付／時刻を選択することによって、その太陽がゾーンまたはゾーングループへのグレアにどのように影響を及ぼしているかを確認することができる。図２４は、太陽が窓のグレアにどのように影響を及ぼしているかを確認するための、特定の日付／時刻での５つの色合い調節可能な窓のゾーンにおける太陽光の直射光線の視覚表現の一例である。一例では、ＧＵＩは、スライダ、または他の可動セレクタインターフェースを含むことができ、これにより、ユーザがその日の異なる時間間隔にわたってスライドさせて、太陽の経路、および直射太陽光からのグレアの影響を１日にわたって確認することができる。
【０１５２】
別の態様として、ユーザは、反射モデルからゾーンまたはゾーングループ、および日付／時刻を選択することによって、その太陽がゾーンまたはゾーングループへの反射にどのように影響を及ぼしているかを確認することができる。図２５は、太陽が特定の日付／時刻に反射される放射にどのように影響を及ぼしているかを確認するための、対象の建物の５つの色合い調節可能な窓のゾーンに対する２つの建物からの太陽光の反射（１回のはね返り）光線の視覚表現の一例である。一例では、ＧＵＩは、スライダ、または他の可動セレクタインターフェースを含むことができ、これにより、ユーザがその日の異なる時間間隔にわたってスライドさせて、太陽の経路、および反射された放射の影響を１日の経過にわたって確認することができる。
【０１５３】
別の態様では、ユーザは、反射モデル、およびグレア／シャドーの晴天モデルの両方を実装することによって、太陽がゾーンまたはゾーングループへのグレアおよび反射光にどのように影響を及ぼしているかを確認することができる。
【０１５４】
ＩＩＩ．窓制御システム
赤外線センサおよび光センサに基づく例示的なロジックモジュールが、２０１７年１０月６日に出願された「ＩＮＦＲＡＲＥＤ  ＣＬＯＵＤ  ＤＥＴＥＣＴＯＲ  ＳＹＳＴＥＭＳ  ＡＮＤ  ＭＥＴＨＯＤＳ」と題する国際ＰＣＴ出願ＰＣＴ／ＵＳ１７／５５６３１に記載されており、それは、その全体が参照により本明細書に組み込まれる。
【０１５５】
Ａ．晴天色合いスケジュールデータ、ならびにモジュールＣおよびＤを使った制御方法
図２６は、様々な実施態様による、建物の色合い調節可能な窓の１つまたは複数のゾーンを制御する方法のための制御ロジックを示すフローチャート２６００を含む。この制御ロジックは、晴天モジュールから受信した晴天色合いスケジュールデータから判定された色合いレベル、モジュールＣによって判定された色合いレベル、およびモジュールＤによって判定された色合いレベルのうちの１つまたは複数に基づいて、各ゾーンの最終的な色合いレベルを判定する。窓制御システムは、色合い命令を通信して、ゾーン（複数可）の色合い調節可能な窓の各々を最終的な色合いレベルに移行させる。例えば、窓制御システムは、マスタコントローラを含むことができ、このマスタコントローラは、この制御ロジックを実装して、色付けの決定を行い、各ゾーンの最終的な色合いレベルを、当該ゾーンの色合い調節可能な窓を制御するローカルな窓コントローラ（複数可）に通信する。一実施態様では、色合い調節可能な窓は、エレクトロクロミック窓であり、その各々は、少なくとも１つのエレクトロクロミックデバイスを含む。例えば、各々の色合い調節可能な窓は、２つのガラスライトであって、これらのライトのうちの少なくとも１つにエレクトロクロミックデバイスを有する、２つのガラスライトを備える断熱ガラスユニットであってもよい。制御ロジックのための命令は、本明細書に記載されている１つもしくは複数の窓コントローラおよび／またはマルチセンサデバイスの１つまたは複数のプロセッサによって実行され得る。例えば、マルチセンサデバイスのプロセッサが、フィルタリングされるセンサ値を判定し、これらのフィルタリングされるセンサ値を窓コントローラに通信し得、その窓コントローラは、そのフィルタリングされるセンサ値に基づいて色合いレベルを判定する。別の例では、窓コントローラの１つまたは複数のプロセッサが、マルチセンサデバイスから受信したセンサ読み取り値に基づいて、フィルタリングされるセンサ値、および対応する色合いレベルを判定することができる。
【０１５６】
図２６の例示された反復制御ロジックの動作は、動作２６１０でのタイマによって計時されるような時間間隔で実行される。このロジック演算は、いくつかの態様では、一定の時間間隔で実行され得る。ある場合では、ロジック演算は、２〜５分毎に行われる。他の場合では、例えば、移行するのに最大３０分以上かかる場合があるエレクトロクロミックライトの大きな部品（例えば、最大６フィートｘ１０フィート）の色合い移行の場合には、３０分毎または２０分毎などのより少ない頻度を基本としてロジック演算を実行することが望ましい場合がある。
【０１５７】
動作２６２０において、制御ロジックは、晴天モジュール（複数可）から受信した晴天色合いスケジュールデータから計算される色合いレベル、ロジックモジュールＣによって計算される色合いレベル、およびロジックモジュールＤによって計算される色合いレベルによって計算される色合いレベルのうちの１つまたは複数に基づいて、時間ｔｉの単一の瞬間でゾーンの色合いレベルを設定する。制御ロジックはまた、これらの色合いレベルを判定するための計算も実行する。これらの色合いレベルを判定するために使用される計算の一例が、図２７に関して詳細に説明されている。モジュールＣおよびＤから色合いレベルを判定するために使用することができる別の計算例が、図３０に関して詳細に説明されている。これらの計算は、窓コントローラ（複数可）および／またはマルチセンサデバイスの１つまたは複数のプロセッサによって実行することができる。例えば、マルチセンサデバイスのプロセッサが、フィルタリングされるセンサ値を判定し、これらのフィルタリングされるセンサ値を窓コントローラに通信し、その窓コントローラは、そのフィルタリングされるセンサ値に基づいて色合いレベルを判定し得る。別の例では、窓コントローラの１つまたは複数のプロセッサが、マルチセンサデバイスから受信したセンサ読み取り値に基づいて、フィルタリングされるセンサ値、および対応する色合いレベルを判定することができる。
【０１５８】
特定の実施態様では、窓制御システムによって実装される制御ロジックは、色合い調節可能な窓が実際の移行に先立ってどのように移行するかを計算する予測ロジックである。これらの場合には、判定される色合いレベルは、将来の時刻、例えば、移行が完了する前後に基づいている。例えば、計算で使用される将来の時間は、移行が、色合い命令を受信した後に完了されることを可能にするのに十分である将来の時刻であり得る。これらの場合には、窓コントローラは、実際の移行に先立って、現在の時刻で色合い命令を送信することができる。移行の完了までに、色合い調節可能な窓は、当該将来の時刻で望まれる色合いレベルに移行していることになる。
【０１５９】
モジュールＣおよびモジュールＤは、判定された雲遮蔽条件に基づいて、各々、雲遮蔽条件および色合いレベルを判定する。モジュールＣの動作は、生の光センサ読み取り値またはフィルタリングされた光センサ値に基づいて雲遮蔽条件を判定し、判定された雲遮蔽条件に基づいて色合いレベルを判定する。光センサ読み取り値／値は、入力としてモジュールＣに直接送信することができる。代替的に、モジュールＣは、光センサ読み取り値／値について、データベースに問い合わせることができる。光センサ読み取り値は、複数の光センサ（複数可）によって取得された測定値、例えば、マルチセンサデバイスの測定値である。一態様では、プロセッサは、モジュールＣのロジックを使用して、光センサ読み取り値／値を閾値と比較することによって、雲遮蔽条件を判定する。一実施態様では、モジュールＣはまた、生の光センサ読み取り値を使用して、フィルタリングされた光センサ値を計算することができる。一般に、モジュールＣの動作は、晴天モデル（複数可）からの晴天色合いスケジュールデータ内の色合いレベルと同じか、またはそれよりも明るい色合いレベルを判定する。
【０１６０】
特定の実施態様では、モジュールＤのロジックは、フィルタリングされた赤外線（ＩＲ）センサ値（例えば、読み取り値のローリング平均値または中央値）を使用して、建物の１つまたは複数のエレクトロクロミック窓のゾーンの色合いレベルを判定する。モジュールＤには、ローカルセンサ（Ｔａｍｂ）または気象入力（Ｔｗｅａｔｈｅｒ）からの上空温度読み取り値（Ｔｓｋｙ）および周囲温度読み取り値、ならびに上空温度読み取り値と周囲温度読み取り値との間の差、デルタ（Δ）に基づいて、フィルタリングされたＩＲセンサ値を計算するためのロジックが含まれる。生のセンサ読み取り値は、モジュールＤに直接入力されるか、またはデータベースのクエリに応答して、データベースから取り出される。周囲温度読み取り値は、ローカル周囲温度センサにより取得された測定値Ｔａｍｂ、または気象入力からの周囲温度読み取り値Ｔｗｅａｔｈｅｒである。上空温度読み取り値は、通常、１つまたは複数の赤外線センサによって取得される。周囲温度読み取り値は、様々なソースから受信され得る。例えば、周囲温度読み取り値は、赤外線センサにオンボードで搭載された１つまたは複数の周囲温度センサ、または例えば、建物のマルチセンサデバイスの独立型温度センサから通信されてもよい。別の例として、周囲温度読み取り値は、気象入力から受信されてもよい。一般に、モジュールＤの動作は、モジュールＣによって判定された色合いレベルよりも暗いかまたは同じである色合いレベルを判定する。他の実施態様では、モジュールＤのロジックは、生の赤外線（ＩＲ）センサ値を使用して、建物の１つまたは複数のエレクトロクロミック窓のゾーンの色合いレベルを判定する。
【０１６１】
図２６に戻ると、動作２６３０において、制御ロジックは、様々なタイプのオーバライドがそのロジックを解除するのを可能にするためのオーバライドが存在するかどうかを判定する。オーバライドが存在する場合、制御ロジックは、動作２６４０において、ゾーンの最終的な色合いレベルをオーバライド値に設定する。例えば、オーバライドは、制御システムをオーバライドして色合いレベルを設定することを望む、空間の現在の占有者によって入力されてもよい。別の例として、オーバライドが、高需要（またはピーク負荷）のオーバライドであり、これは、建物のエネルギー消費を低減することができるという実用性の要求と関連する。例えば、大都市圏の特に暑い日には、自治体のエネルギー生成および流通システムに過度に重い負担をかけないように、自治体全体のエネルギー消費を削減する必要がある場合がある。このような場合には、建物管理は、制御ロジックからの色合いレベルをオーバライドして、すべての色合い調節可能な窓が高色合いレベルを有することを確実にすることができる。このオーバライドにより、ユーザの手動のオーバライドをオーバライドすることができる。オーバライドの値の中には、優先度のレベルがあってもよい。
【０１６２】
動作２６５０において、制御ロジックは、判定されている、建物の各ゾーンの色合いレベルが判定されたかどうかを判定する。そうでない場合、制御ロジックは、反復して次のゾーンの最終的な色合いレベルを判定する。判定されている、最終的なゾーンの色合い状態が完了すると、各ゾーンの色合いレベルを実施するための制御信号は、ゾーンの色合い調節可能な窓のデバイス（複数可）と電気通信する電力供給源にネットワークを介して送信されて、動作２６６０において最終的な色合いレベルに移行することができ、制御ロジックは、次の時間間隔の間反復して動作２６１０に戻る。例えば、色合いレベルは、１つまたは複数のエレクトロクロミック窓のエレクトロクロミックデバイス（複数可）と電気通信する電力供給源にネットワークを介して送信されて、窓を色合いレベルに移行させることができる。特定の実施形態では、建物の窓への色合いレベルの送信は、効率を念頭において実施されてもよい。例えば、色合いレベルの再計算により、現在の色合いレベルからの色合いの変更は必要ないことが示唆された場合、更新された色合いレベルを有する命令の送信はない。別の例として、制御ロジックは、より小さい窓を有するゾーンの色合いレベルを、より大きい窓を有するゾーンの色合いレベルよりも、より頻繁に再計算することができる。
【０１６３】
ある場合では、図２６の制御ロジックは、単一のデバイス、例えば単一のマスタ窓コントローラ上の、建物全体のすべてのエレクトロクロミック窓の色合いレベルを制御するための制御方法を実装する。このデバイスは、建物の各々のエレクトロクロミック窓の計算を実行することができ、また、別々のエレクトロクロミック窓内のエレクトロクロミックデバイスに色合いレベルを送信するためのインターフェースを提供することができる。
【０１６４】
図２７は、一実施態様によれば、晴天モデル（複数可）、モジュールＣ、およびモジュールＤからの晴天色合いスケジュール情報に基づいて、時間ｔｉの単一の瞬間でゾーンの色合いを決定するための制御ロジックを示すフローチャート２７００を含む。動作２６１０において、ゾーンの晴天の色合いレベルは、晴天モデルから出力された晴天スケジュールデータに基づいて、判定される。例えば、晴天色合いスケジュールデータは、異なる時間間隔の晴天色合い状態を含み得、制御ロジックは、時間ｔｉにおけるゾーンの晴天色合い状態を判定する。晴天色合いスケジュールデータは、異なる条件（例えば、グレア条件、反射条件、パッシブヒート条件）、および／または優先度データに基づいて、１日にわたって異なる時間間隔の晴天色合い状態を含むことができる。例えば、晴天色合いスケジュールデータは、図１２のグラフに示される、例えば優先度制約曲線によって示されるような優先度データが制約する異なる条件と関連付けられた色合いレベルに基づいて、異なる時間間隔にわたる晴天色合い状態の形式であってもよい。この例では、ロジックは、時間ｔｉにおいて優先度制約された曲線に基づいて、色合い状態を判定している。動作２６２０において、制御ロジックは、ロジックモジュールＣを使用して、ゾーンの色合いレベルを判定する。ロジックモジュールＣによって実行される動作は、図３５を参照して詳細に説明される。動作２６３０において、制御ロジックは、ロジックモジュールＤを使用して、ゾーンの色合いレベルを判定する。ロジックモジュールＤによって実行される動作は、図２８、図３０、図３１、および図３２を参照して詳細に説明される。動作２６４０において、制御ロジックは、モジュールＣおよびモジュールＤから最大色合いレベルを計算する。動作２６５０において、制御ロジックは、動作２６１０で判定された晴天色合いレベルから最小色合いレベルを計算し、また動作２６４０で判定されたモジュールＣおよびＤから最大色合いレベルを計算する。
【０１６５】
モジュールＣおよびモジュールＤから色合いレベルを導出するために使用され得る制御ロジックの別の例が、図３０に関して説明されている。
【０１６６】
また、実施形態の制御ロジックの特定の適応性のある構成要素が存在し得る。例えば、制御ロジックは、エンドユーザ（例えば、占有者）が１日中の特定の時間にアルゴリズムをどのようにオーバライドしようとするかを判定することができ、その後、より予測可能な方法でこの情報を利用して、所望の色合いレベルを判定する。例えば、エンドユーザは、壁スイッチを使用して、連続した一連の日々にわたる各日の特定の時間に、制御ロジックによって提供される色合いレベルをあるオーバライド値にオーバライドすることができる。制御ロジックは、これらの事例に関する情報を受信し、制御ロジックを変更して、１日中の当該時刻において色合いレベルをエンドユーザからのオーバライド値に変更するオーバライド値を導出することができる。
【０１６７】
−モジュールＤの実施例
特定の実施態様では、モジュールＤは、フィルタリングされた赤外線（ＩＲ）センサ値（例えば、読み取り値のローリング平均値または中央値）を使用して、建物の１つまたは複数のエレクトロクロミック窓のゾーンの色合いレベルを判定する。モジュールＤは、曇りのオフセット値、ならびにローカルセンサ（Ｔａｍｂ）もしくは気象入力（Ｔｗｅａｔｈｅｒ）からの上空温度読み取り値（Ｔｓｋｙ）および周囲温度読み取り値、ならびに／または上空温度読み取り値と周囲温度読み取り値との間の差であるデルタ（Δ）を使用して、フィルタリングされたＩＲセンサ値を計算するロジックを含む。この曇りのオフセット値は、モジュールＤのロジックによって曇り条件を判定するために使用されることになる閾値に対応する温度オフセットである。モジュールＤのロジックは、ネットワークコントローラまたはマスタコントローラの１つまたは複数のプロセッサによって実行することができる。代替的に、モジュールＤのロジックは、マルチセンサデバイスの１つまたは複数のプロセッサによって実行することができる。ある場合では、モジュールＤから計算されたフィルタリングされたＩＲセンサ値は、メモリに格納されているＩＲセンサ測定データベースに保存される。この場合、モジュールＤの計算を実行する１つまたは複数のプロセッサは、ＩＲセンサ測定データベースから入力としてＩＲセンサ値を取り出す。
【０１６８】
図２８は、特定の実施態様による、モジュールＤのロジックを示すフローチャート２８００を例示する。モジュールＤのロジックは、ローカル窓コントローラ、ネットワークコントローラ、マスタコントローラ、またはマルチセンサデバイスのうちの１つまたは複数のプロセッサによって実行することができる。動作２８１０において、モジュールＤの動作を実行するプロセッサ（複数可）は、現在の時刻に関連付けられたデータとして受信する。センサ読み取り値は、建物の通信ネットワークを介して、例えば、屋上のマルチセンサデバイスから受信することができる。受信したセンサ読み取り値には、上空温度読み取り値（Ｔｓｋｙ）、建物のローカルセンサからの周囲温度読み取り値（Ｔａｍｂ）または気象入力からの周囲温度読み取り値（Ｔｗｅａｔｈｅｒ）、および／またはＴｓｋｙとＴａｍｂの差の読み取り値（Δ）が含まれる。建物のローカルセンサからの周囲温度読み取り値（Ｔａｍｂ）は、ＩＲセンサデバイスに搭載されているか、またはＩＲセンサデバイスとは別個にある周囲温度センサによって取得された測定値である。周囲温度センサ読み取り値は、代替的に、気象入力データからのものであってもよい。
【０１６９】
別の実施態様では、モジュールＤのロジックは、建物の２つ以上のＩＲセンサデバイス（例えば、屋上のマルチセンサデバイスの）によって取得された測定値の生のセンサ読み取り値を受信および使用し、それぞれのＩＲセンサデバイスは、周囲温度（Ｔａｍｂ）を測定するためのオンボードの周囲温度センサと、そのセンサの視界内で受信される赤外線放射に基づいて、上空温度（Ｔｓｋｙ）を測定するために上空に向けられたオンボード赤外線センサと、を有する。通常、２つ以上のＩＲセンサデバイスを使用して、冗長性を提供する。ある場合では、各赤外線センサデバイスは、周囲温度（Ｔａｍｂ）および上空温度（Ｔｓｋｙ）の読み取り値を出力する。別の場合では、各赤外線センサデバイスは、周囲温度（Ｔａｍｂ）、上空温度（Ｔｓｋｙ）、およびＴｓｋｙとＴａｍｂとの間の差、デルタΔの読み取り値を出力する。ある場合では、各赤外線センサデバイスは、ＴｓｋｙとＴａｍｂとの間の差であるデルタΔの読み取り値を出力する。一態様によれば、モジュールＤのロジックは、建物の２つのＩＲセンサデバイスによって取得された測定値の生のセンサ読み取り値を使用する。別の態様では、モジュールＤのロジックは、建物の１〜１０個のＩＲセンサデバイスによって取得された測定値の生のセンサ読み取り値を使用する。
【０１７０】
別の実施態様では、モジュールＤのロジックは、建物の赤外線センサによって取得され、かつそのセンサの視野内の受信した赤外線放射に対して上空に向けられた生の上空温度（Ｔｓｋｙ）の読み取り値、および気象入力データ（Ｔｗｅａｔｈｅｒ）からの周囲温度の読み取り値を受信および使用する。気象入力データは、通信ネットワークを介して、１つまたは複数の気象サービス、および／または他のデータソースから受信される。気象入力データには、通常、例えば、雲の覆域のパーセンテージ、視認性データ、風速データ、温度データ、降水確率のパーセンテージ、および／または湿度などの気象条件に関連するデータが含まれる。通常、気象入力データは、窓コントローラによって、通信ネットワークを介する信号で受信される。特定の態様によれば、窓コントローラは、通信ネットワークにわたる通信インターフェースを介して、気象入力データの要求を有する信号を１つまたは複数の気象サービスに送信することができる。その要求には、普通、制御される窓（複数可）の位置の少なくとも経度および緯度が含まれる。それに応じて、１つまたは複数の気象サービスは、通信インターフェースを通る通信ネットワークを介して、気象入力データを有する信号を窓コントローラに送信する。通信インターフェースおよびネットワークは、有線または無線の形態であってもよい。場合によっては、気象サービスは、気象ウェブサイトを介してアクセス可能であり得る。気象ウェブサイトの一例が、ｗｗｗ．ｆｏｒｅｃａｓｔ．ｉｏに見出すことができる。別の例は、Ｎａｔｉｏｎａｌ  Ｗｅａｔｈｅｒ  Ｓｅｒｖｉｃｅ（ｗｗｗ．ｗｅａｔｈｅｒ．ｇｏｖ）である。気象入力データは、現在の時刻に基づいてもよく、または将来の時刻で予報されてもよい。気象入力データを使用するロジックに関するより多くの詳細については、２０１６年７月７日に出願された「ＣＯＮＴＲＯＬ  ＭＥＴＨＯＤ  ＦＯＲ  ＴＩＮＴＡＢＬＥ  ＷＩＮＤＯＷＳ」と題する国際出願ＰＣＴ／ＵＳ１６／４１３４４の中に見出すことができ、これは、その全体が参照により本明細書に組み込まれる。
【０１７１】
図２８に戻ると、動作２８２０において、モジュールＤのロジックは、１つまたは複数の赤外線センサからの上空温度読み取り値、１つまたは複数のローカル周囲温度センサまたは気象入力のどちらかからの周囲温度読み取り値、および曇りオフセット値に基づいて、温度値（Ｔｃａｌｃ）を計算する。曇りオフセット値とは、モジュールＤの曇り条件を判定するために使用される第１および第２の閾値を判定する温度オフセットを指す。一例では、曇りオフセット値は、摂氏−１７ミリ度である。一態様では、摂氏−１７ミリ度である曇りオフセット値は、摂氏０ミリ度である第１の閾値に対応する。別の例では、曇りオフセット値は、摂氏−３０ミリ度〜摂氏０ミリ度の範囲である。
【０１７２】
特定の実施態様では、モジュールＤは、２つ以上の熱センサペアからの上空温度読み取り値に基づいて、温度値（Ｔｃａｌｃ）を計算する。熱センサの各ペアは、赤外線センサおよび周囲温度センサを有する。一実施態様では、各ペアの熱センサは、ＩＲセンサデバイスの一体化型構成要素である。各ＩＲセンサデバイスは、オンボードの赤外線センサ、およびオンボードの周囲温度センサを有する。２つのＩＲセンサデバイスは、通常、冗長性を提供するために使用される。別の実施態様では、赤外線センサおよび周囲温度センサは、別々である。
【０１７３】
動作２８２０において、モジュールＤのロジックは、次式を使って、温度値（Ｔｃａｌｃ）を計算する。
Ｔｃａｌｃ＝最小値（Ｔｓｋｙ１，Ｔｓｋｙ２，...）−最小値（Ｔａｍｂ１，Ｔａｍｂ２，...）−曇りオフセット（式１）
ここで、Ｔｓｋｙ１、Ｔｓｋｙ２、...は、複数の赤外線センサによって取得された温度読み取り値であり、Ｔａｍｂ１、Ｔａｍｂ２、...は、複数の周囲温度センサによって取得された温度読み取り値である。２つの赤外線センサおよび２つの周囲温度センサが使用される場合、Ｔｃａｌｃ＝最小値（Ｔｓｋｙ１，Ｔｓｋｙ２）−最小値（Ｔａｍｂ１，Ｔａｍｂ２）−曇りオフセットである。同じタイプの複数のセンサからの読み取り値の最小値を使用して、より少ない曇り覆域を示し得る下方温度値に向かう結果をバイアスし、結果として、より高い色合いレベルがもたらされ、グレアを回避するようにその結果をバイアスする。
【０１７４】
別の実施態様では、モジュールＤのロジックは、周囲温度センサ読み取り値が利用不可能または不正確になったとき、例えば、周囲温度センサが、屋上などのローカルなソースから放射する熱を読み取っている場合に、ローカル周囲温度センサの使用から気象入力データの使用に切り替えることができる。この実施態様では、気象入力データ（Ｔｗｅａｔｈｅｒ）からの上空温度読み取り値および周囲温度読み取り値に基づいて、温度値（Ｔｃａｌｃ）が、計算される。この実施態様では、温度値は、次のように計算される。
Ｔｃａｌｃ＝最小値（Ｔｓｋｙ１，Ｔｓｋｙ２，...）−Ｔｗｅａｔｈｅｒ−曇りオフセット（式２）
【０１７５】
別の実施態様では、温度値（Ｔｃａｌｃ）は、２つ以上のＩＲセンサデバイスにより測定された、上空温度と周囲温度との間の差Δの読み取り値に基づいて計算され、各温度は、オンボード赤外線センサ測定および周囲温度センサを有する。この実施態様では、温度値は、次のように計算される。
Ｔｃａｌｃ＝最小値（Δ１，Δ２，...）−曇りオフセット（式３）
ここで、Δ１，Δ２，...は、複数のＩＲセンサデバイスによって測定された上空温度と周囲温度との間の差Δの読み取り値である。
【０１７６】
式１および式３を使用する実施態様では、制御ロジックは、上空温度と周囲温度との間の差を使用して、ＩＲセンサ値入力を判定し、曇り条件を判定する。周囲温度読み取り値は、上空温度読み取り値よりも変動が少ない傾向がある。上空温度と周囲温度との間の差を入力として使用して色合い状態を判定することによって、経時的に判定される色合い状態は、より小さい程度で変動し、より安定した窓の色付けを提供することができる。
【０１７７】
別の実施態様では、制御ロジックは、２つ以上の赤外線センサからの上空温度読み取り値のみに基づいて、Ｔｃａｌｃを計算する。この実施態様では、モジュールＤによって判定され、そしてモジュールＤに入力されたＩＲセンサ値は、上空温度読み取り値に基づいており、周囲温度読み取り値には基づいていない。この場合では、モジュールＤは、上空温度読み取り値に基づいて、曇り条件を判定する。Ｔｃａｌｃを判定するための上述した実施態様は、各タイプの２つ以上の冗長センサに基づいているが、制御ロジックは、単一センサからの読み取り値を使って実施されてもよいことを理解されたい。
【０１７８】
動作２８３０において、プロセッサは、動作２８２０で判定されたＴｃａｌｃを有する短期ボックスカーおよび長期ボックスカーを更新する。ボックスカーを更新するには、最新のセンサ読み取り値をボックスカーに追加し、最も古いセンサ読み取り値をボックスカーから削除する。
【０１７９】
本明細書に記載されているモジュールＤおよび他の制御ロジックの場合、フィルタリングされたセンサ値が、色付けを決定するための入力として使用される。本明細書に記載されているモジュールＤおよび他のロジックは、短期および長期のボックスカー（フィルタ）を使用してフィルタリングされたセンサ値を判定する。短いボックスカー（例えば、１０分間、２０分間、５分間などにわたって取得されたサンプル値を利用するボックスカー）は、長いボックスカー（例えば、１時間、２時間などにわたって取得されたサンプル値を利用するボックスカー）のより多い数のセンササンプル（例えば、ｎ＝１０、２０、３０、４０など）に比べて、より少ない数のセンササンプル（例えば、ｎ＝１、２、３、...、１０など）に基づいている。ボックスカー（照度）値は、ボックスカー内のサンプル値の平均値、代表値、中央値、または他の代表的な値に基づいてもよい。一例では、短いボックスカー値は、センササンプルの中央値であり、長いボックスカー値は、センササンプルの中央値である。モジュールＤは、通常、短いボックスカー値および長いボックスカー値の各々について、センササンプルのローリング中央値を使用する。別の例では、短いボックスカー値は、センササンプルの平均値であり、長いボックスカー値は、センササンプルの平均値である。モジュールＣは、通常、センササンプルの平均値に基づいて、短いおよび／または長いボックスカー値から判定されるフィルタリングされた光センサ値を使用する。
【０１８０】
短いボックスカー値はより少ない数のセンササンプルに基づいているため、短いボックスカー値は、長いボックスカー値よりも現在のセンサ読み取り値により密接に追従する。したがって、短いボックスカー値は、長いボックスカー値よりも、急速に変化する条件により迅速に、およびより大きな程度で応答する。計算された短いおよび長いボックスカー値の両方がセンサ読み取り値よりも遅れるが、短いボックスカー値は、長いボックスカー値よりも少ない程度で遅れる。短いボックスカー値は、現在の条件に対して、長いボックスカー値よりも迅速に反応する傾向がある。長いボックスカーを使用して、通過する雲のような、頻繁に起こる持続時間の短い気象変動に対する窓コントローラの応答を平準化することができ、これに対して、短いボックスカーは、平準化を同様には行わないが、空一面雲りの条件のような急速で顕著な気象変化に対してより迅速に応答することができる。通過する曇の条件の場合、長いボックスカー値のみを使用する制御ロジックは、現在通過する曇の条件に迅速に反応しないことになる。この場合、長いボックスカー値は、色付けの決定に使用されて、適切な高色合いレベルを判定することができる。霧が消散する条件の場合、色付けの決定に短期ボックスカー値を使用することがより適切であり得る。この場合、短期ボックスカーは、霧が消散した後の新たな日当たりの良い状態に、より迅速に反応する。短期ボックスカー値を使用して色付けを決定することによって、色合い調節可能な窓は、日当たりの良い条件に迅速に調整することができ、霧が急速に消散するときには、占有者を快適に保つ。
【０１８１】
動作２８４０において、プロセッサは、動作２８３０で更新されたボックスカー内の現在のセンサ読み取り値に基づいて、短いボックスカー値（Ｓｂｏｘｃａｒ値）および長いボックスカー値（Ｌｂｏｘｃａｒ値）を判定する。この例では、各ボックスカー値は、動作２８３０で行われた最後の更新の後に、ボックスカー内のセンサ読み取り値の中央値を取得することによって計算される。別の実施態様では、各ボックスカー値は、各ボックスカー内の現在のセンサ読み取り値の平均値を取得することによって計算される。他の実施態様では、各ボックスカー内のセンサ読み取り値の他の計算を使用してもよい。
【０１８２】
特定の実施態様では、本明細書に記載されている制御ロジックは、短期ボックスカー値と長期ボックスカー値との間の差を評価して、決定を行う際にどのボックスカー値を実装するかを判定する。例えば、短期ボックスカー値と長期ボックスカー値との間の差の絶対値が閾値を上回る場合には、短期ボックスカー値を計算に使用する。この場合、短期のセンサ読み取り値の短いボックスカー値は、長期センサ読み取り値の閾値によってさらに大きくなり、その閾値は、十分大きな有意性がある短期変動、例えば、より低い色合い状態に移行することを推奨し得る大きな雲を示し得る。短期ボックスカー値と長期ボックスカー値との間の差の絶対値が閾値を上回らない場合には、長期ボックスカーが使用される。図２８に戻ると、動作２８５０において、ロジックは、Ｓｂｏｘｃａｒ値とＬｂｏｘｃａｒ値との間の差の絶対値の値がデルタ閾値よりも大きいかどうか（｜Ｓｂｏｘｃａｒ値−Ｌｂｏｘｃａｒ値｜＞デルタ閾値）を評価する。場合によっては、デルタ閾値の値は、摂氏０ミリ度〜摂氏１０ミリ度の範囲である。ある場合では、デルタ閾値の値は、摂氏０ミリ度である。
【０１８３】
差の絶対値がデルタ閾値を上回っている場合、Ｓｂｏｘｃａｒ値は、ＩＲセンサ値に割り当てられ、短期ボックスカーは、リセットされてその値を空にする（動作２８６０）。差の絶対値がデルタ閾値を上回っていない場合、Ｌｂｏｘｃａｒ値は、ＩＲセンサ値に割り当てられ、長期ボックスカーは、リセットされてその値を空にする（動作２８７０）。動作２８８０において、フィルタリングされたＩＲセンサ値は、ＩＲセンサ測定データベースに保存される。
【０１８４】
−太陽高度に応じたモジュールＣおよび／またはモジュールＤの実装
朝および夕方では、太陽光レベルは、低く、例えばマルチセンサの可視光光センサにより取得される読み取り値は、曇り条件に矛盾しないと考えられ得る低い値である。このため、朝および夕方の間に取得される可視光光センサの読み取り値は、誤って曇り条件を示す可能性がある。さらに、建物または丘／山からの任意の障害物もまた、取得された可視光光センサの読み取り値のみに基づいて、曇り条件の誤った表層的な表示をもたらし得る。さらに、日の出前に取得された可視光光センサの読み取り値は、単独で取得した場合、結果として誤った表層的な曇り条件となり得る。制御ロジックが、日の出の直前に取得された可視光光センサの読み取り値のみに基づいて、前もって日の出における色合いレベルを判定することを予測する場合、誤った表層的な曇り条件は、エレクトロクロミック窓を、部屋内のグレアを可能にする日の出の明るい状態に移行させる原因になる可能性がある。
【０１８５】
図２９は、日の出から日没までの異なる太陽高度における太陽を図示した概略図を示す。この説明図は、太陽高度が０度（日の出）よりも大きく、かつΘ１未満（ここで、Θ１は、約５度、約７度、約１０度、約１２度、または１０〜１５度の範囲）、すなわち朝の領域にあるとき、または、太陽高度が１８０度（日没）から約Θ２未満（ここで、Θ２は、約５度、約７度、約１０度、約１２度、１０〜１５度の範囲）であるときに、赤外線センサの読み取り値を使用して、例えばモジュールＤを実装することによって、曇り条件を判定する必要があることを示している。この説明図はまた、太陽高度がΘ１より大きく、かつ１８０度からのΘ２を上回るときが昼間の期間であり、赤外線および光センサの読み取り値、または光センサの読み取り値を使用して、例えばモジュールＣ／Ｄを使用して曇り条件を判定する必要があることも示している。
【０１８６】
図３０は、実施態様に基づいて、太陽高度が朝、昼間、または夕方の領域を示しているかどうかに応じて、赤外線センサおよび／もしくは光センサデータのどちらか一方またはその両方を使用して色付けの決定を行うための制御ロジックを用いたフローチャート３０００を示す。太陽高度に応じて、モジュールＣまたはモジュールＤのどちらかまたはその両方が実装される。図３０の制御ロジックは、図２６のブロック２６２０で判定されたロジックの一例である。
【０１８７】
動作３０２２において、制御ロジックは、計算された太陽高度が時間ｔｉの単一の瞬間で０未満であるかどうかを判定する。一実施態様では、制御ロジックはまた、太陽の位置に基づいて、太陽高度を判定し、窓（複数可）を有する建物の緯度および経度、ならびに１日の時刻ｔｉおよび１年の日（日付）に基づいて太陽の位置を計算する。公的に利用可能なプログラムが、太陽の位置を判定するための計算を提供することができる。
【０１８８】
動作３０２２において、太陽高度が０未満であると判定された場合、それは夜間であり、制御ロジックは、動作３０２４において夜間の色合い状態を設定する。夜間の色合い状態の一例が、最低の色合い状態である透明の色合いレベルである。透明の色合いレベルは、夜間の色合い状態として使用され、例えば、建物外部のセキュリティ担当者が透明な窓を通して建物の照明された部屋（複数可）の内部を確認することを可能にすることによって、セキュリティを提供することができる。夜間の色合い状態の別の例としては、最も高い色合いレベルであり、その色合いレベルはまた、窓が最も暗い色合い状態にあるときに、他人が夜間に建物の内部を見ることができないことによってプライバシーおよび／またはセキュリティを提供することもできる。太陽高度が０未満であると判定された場合、制御ロジックは、夜間の色合い状態を返す。
【０１８９】
動作３０３０において、制御ロジックは、太陽高度が下方の太陽高度閾値Θ１（例えば、Θ１は、約５度、約１２度、約１０度、１０〜１５度の範囲）以下であるか、または１８０度からの上方の太陽高度閾値Θ２（ここで、Θ２は、約５度、約１２度、約１０度、１０〜１５度の範囲）以上であるかを判定する。太陽高度がこの範囲にある場合、制御ロジックは、時刻ｔｉが朝または夕方であると判定する。
【０１９０】
太陽高度がこの範囲にない場合、制御ロジックは、動作３０３２において、太陽高度が増加しているかまたは減少しているかを判定する。制御ロジックは、太陽高度が、経時的に計算された太陽高度値を比較することによって、増加しているかまたは減少しているかを判定する。制御ロジックが、太陽高度が増加していると判定した場合、朝であると判定され、制御ロジックは、動作３０３４において、モジュールＤの朝のＩＲセンサアルゴリズム実装を実行する。使用することができる朝のＩＲセンサアルゴリズムの一例が、図３１のフローチャート３１００に関して説明されている。
【０１９１】
制御ロジックが、太陽高度が動作３０３２において、増加していない（減少している）と判定した場合、それは夕方であると判定され、制御ロジックは、動作３０３６において、モジュールＤの夕方のＩＲセンサアルゴリズム実装を実行する。使用することができる夕方のＩＲセンサアルゴリズムの一例が、図３２に示されたフローチャート３２００に関して説明されている。モジュールＤの朝または夕方のどちらかのＩＲセンサアルゴリズムを実行して、モジュールＤに基づいて色合いレベルを判定した後、制御ロジックは、モジュールＤ色合いレベルの最小値、および動作３０４０において晴天モデル（複数可）から出力された晴天色合いスケジュールからの色合いレベルを判定し、最小値の色合いレベルを返す。
【０１９２】
動作３０３０において、太陽高度がΘ１より大きく、かつ１８０−Θ２未満であると判定された場合、それは昼間領域であり、制御ロジックは、光センサおよび／または赤外線センサの読み取り値に基づいて判定するために、モジュールＣおよび／またはモジュールＤを実装する昼間アルゴリズムを実行する（動作３０４０）。制御ロジックは、色合いレベルを、モジュールＣ／Ｄ色合いレベルの最小値、および動作３０４０において晴天モデルから出力された晴天色合いスケジュールからの色合いレベルに設定し、最小値色合いレベルを返す。
【０１９３】
−モジュールＤの朝のＩＲセンサアルゴリズムおよび夕方のＩＲセンサアルゴリズムの実施例
モジュールＤは、フィルタリングされたＩＲセンサ値について赤外線センサ測定値データベースに問い合わせ、次いで、そのフィルタリングされたＩＲセンサ値に基づいて、曇り条件および関連する色合いレベルを判定する。フィルタリングされたＩＲセンサ値が下方閾値を下回る場合、それは、「日当たりの良い」条件であり、モジュールＤからの色合いレベルは、最も高い色合いレベルに設定される。フィルタリングされたＩＲセンサ値が上方閾値を上回る場合、それは、「曇り」の条件であり、モジュールＤからの色合いレベルは、最低の色合いレベルに設定される。フィルタリングされたＩＲセンサ値が上方閾値以下で、かつ下方閾値以上である場合、モジュールＤからの色合いレベルは、中間の色合いレベルに設定される。これらの計算で使用される上方閾値および下方閾値は、朝のＩＲセンサアルゴリズム、夕方のＩＲセンサアルゴリズム、または昼間アルゴリズムが実装されているかどうかに基づいている。
【０１９４】
図３４は、２４時間の期間中の、摂氏ミリ度単位のフィルタリングされたＩＲセンサ値対時間のグラフを示す。このグラフは、フィルタリングされたＩＲセンサ値の範囲の３つの領域を示す。上方閾値を上回る上方領域は、「曇り」領域である。上方閾値を上回るフィルタリングされたＩＲセンサ値は、「曇り」領域内にある。上方閾値と下方閾値との間の中間領域は、「断続的な曇り」または「部分的な曇り」領域である。下方閾値を下回る下方領域は、「晴れ」領域であり、また「日当たりの良い」領域とも称される。上方閾値を下回るフィルタリングされたＩＲセンサ値は、「晴れ」または「日当たりの良い」領域内にある。このグラフは、２つの２４時間の期間にわたって取得された読み取り値に基づいて計算されたフィルタリングされたＩＲセンサ値の２つの曲線を有する。第１の曲線３４３０は、午後に雲を有する第１日目に取得された、計算されたフィルタリングされたＩＲセンサ値を示す。第２の曲線３４３２は、全日中、日当たりの良い／晴れの第２日目に取得された、計算されたフィルタリングされたＩＲセンサ値を示す。下方閾値は、中間領域と下方領域との間の下限を表す。上方閾値は、中間領域と上方領域との間の上限を表す。夕方の間に使用される下方閾値および上方閾値（夕方の下方閾値、および夕方の上方閾値）は、通常、朝の間に使用される下方閾値および上方閾値（朝の下方閾値、および朝の上方閾値）よりも高い。
【０１９５】
図３１は、モジュールＤの朝のＩＲセンサアルゴリズムのための制御ロジックのフローチャート３１００を示す。朝のＩＲセンサアルゴリズムは、色付け制御ロジックが、現在の時刻が朝の領域の間にあると判定したときに、実装され得る。この朝のＩＲセンサアルゴリズムは、制御ロジックが、太陽高度角度が高度閾値未満であり、かつ太陽高度角度が増加していると判定したときに、図３１に示されたフローチャートの動作３１３４において実施され得る制御ロジックの一例である。
【０１９６】
フローチャート３１００の制御ロジックは、動作３１１０において開始され、フィルタリングされたＩＲセンサ値は、朝の下方閾値と比較されて、フィルタリングされたＩＲセンサ値が朝の下方閾値未満であるかどうかを判定する。モジュールＤの制御ロジックは、赤外線センサ測定値データベースまたは他のデータベースに問い合わせて、フィルタリングされたＩＲセンサ値を取り出す。代替的に、制御ロジックは、フィルタリングされたＩＲセンサ値を計算する。フィルタリングされたＩＲセンサ値を計算し、その値を赤外線センサ測定値データベースに格納するために使用され得る制御ロジックの一例が、図２８のフローチャートを参照して説明されているモジュールＤの制御ロジックである。朝の下方閾値とは、朝の領域の間に適用される、下方領域（「日当たりの良い」または「晴れ」領域）と中間領域（「部分的な曇り」領域）との間のフィルタリングされたＩＲセンサ値の下限における温度値である。特定の実施態様では、朝の下方閾値は、摂氏約−２０〜約２０ミリ度の範囲である。一例では、朝の下方閾値は、摂氏約１度である。
【０１９７】
動作３１１０において、フィルタリングされたＩＲセンサ値が朝の下方閾値未満であると判定された場合、フィルタリングされたＩＲセンサ値は、「晴れた」または「日当たりの良い」領域である下方領域内にある。この場合、制御ロジックは、モジュールＤから、高色合い状態（例えば、色合いレベル４）に色合いレベルを設定し、モジュールＤから色合いレベルを渡す（動作３１２０）。
【０１９８】
動作３１１０において、フィルタリングされたＩＲセンサ値が朝の下方閾値未満ではないと判定された場合、動作３１３０において、制御ロジックは、次に進み、フィルタリングされたＩＲセンサ値が朝の上方閾値以下であり、かつ朝の下方閾値以上であるかどうかを判定する。朝の上方閾値とは、その日の朝の領域の間に適用される中間領域（「部分的な曇り」領域）および上方領域（「曇り」領域）との間の、フィルタリングされたＩＲセンサ値の上限における温度である。特定の実施態様では、朝の上方閾値は、摂氏−２０〜２０ミリ度の範囲である。一例では、朝の上方閾値は、摂氏３ミリ度である。
【０１９９】
動作３１３０において、フィルタリングされたＩＲセンサ値が朝の上方閾値以下であり、かつ朝の下方閾値以上であると判定された場合、フィルタリングされたＩＲセンサ値は、「部分的な曇り」領域である中間領域内にあると判定される（動作３１４０）。この場合、制御ロジックは、モジュールＤの色合いレベルを中間色合い状態（例えば、色合いレベル２または３）に設定し、モジュールＤからの色合いレベルは、渡される。
【０２００】
動作３１３０において、フィルタリングされたＩＲセンサ値が朝の上方閾値以下ではなく、かつ朝の下方閾値以上である（すなわち、フィルタリングされたセンサ値が朝の上方閾値を上回る）と判定された場合、フィルタリングされたＩＲセンサ値は、「曇り」または「空一面雲り」の条件である上方領域内にあると判定される（動作３１５０）。この場合、制御ロジックは、モジュールＤの色合いレベルを低色合い状態（例えば、色合いレベル２、または下方の色合いレベル）に設定し、モジュールＤからの色合いレベルは渡される。
【０２０１】
図３２は、モジュールＤの夕方のＩＲセンサアルゴリズムのための制御ロジックのフローチャート３２００を示す。夕方のＩＲセンサアルゴリズムは、色付け制御ロジックが、現在の時刻が夕方の領域の間にあると判定したときに、実装され得る。夕方のＩＲセンサアルゴリズムは、制御ロジックの一例であり、その制御ロジックは、それが太陽高度の角度が高度閾値未満であり、太陽高度の角度が減少していると判定したときに、図３０に示されたフローチャートの動作３０３６において実装され得る。
【０２０２】
フローチャート３２００の制御ロジックは、動作３２１０において開始され、フィルタリングされたＩＲセンサ値は、夕方の下方閾値と比較されて、フィルタリングされたＩＲセンサ値が夕方の下方閾値未満であるかどうかを判定する。モジュールＤの制御ロジックは、赤外線センサ測定値データベースまたは他のデータベースに問い合わせて、フィルタリングされたＩＲセンサ値を取り出す。代替的に、制御ロジックは、フィルタリングされたＩＲセンサ値を計算する。フィルタリングされたＩＲセンサ値を計算し、その値を赤外線センサ測定値データベースに格納するために使用され得る制御ロジックの一例が、図２８のフローチャートを参照して説明されているモジュールＤの制御ロジックである。夕方の下方閾値とは、夕方の領域の間に適用される、下方領域（「日当たりの良い」または「晴れ」領域）と中間領域（「部分的な曇り」領域）との間のフィルタリングされたＩＲセンサ値の下限の温度値である。特定の実施態様では、夕方の下方閾値は、摂氏−２０〜２０ミリ度の範囲である。一実施態様では、夕方の下方閾値は、摂氏２ミリ度である。
【０２０３】
動作３２１０において、フィルタリングされたＩＲセンサ値が夕方の下方閾値未満であると判定された場合、制御ロジックは、フィルタリングされたＩＲセンサ値が「晴れ」または「日当たりの良い」領域である下方領域内にあると判定する。この場合、制御ロジックは、動作３２２０において、モジュールＤからの色合いレベルを高色合い状態（例えば、色合いレベル４）に設定し、そのモジュールＤからの色合いレベルを渡す。
【０２０４】
動作３２１０において、フィルタリングされたＩＲセンサ値が夕方の下方閾値未満でないと判定された場合、動作３２３０において、制御ロジックは、次に進み、フィルタリングされたＩＲセンサ値が夕方の上方閾値以下であり、かつ夕方の下方閾値以上であるかどうかを判定する。夕方の上方閾値とは、その日の夕方の領域の間に適用される、中間領域（「部分的な曇り」領域）と上方領域（「曇り」領域）との間のフィルタリングされたＩＲセンサ値の上限における温度である。特定の実施態様では、夕方の上方閾値は、摂氏−２０〜２０ミリ度の範囲である。一例では、夕方の上方閾値は、摂氏５ミリ度である。
【０２０５】
動作３２３０において、フィルタリングされたＩＲセンサ値が夕方の上方閾値以下であり、かつ夕方の下方閾値以上であると判定された場合、フィルタリングされたＩＲセンサ値は、「部分的な曇り」領域である中間領域内にあると判定される（動作３２４０）。この場合、制御ロジックは、モジュールＤの色合いレベルを中間色合い状態（例えば、色合いレベル２または３）に設定し、モジュールＤからの色合いレベルは、通過する。
【０２０６】
動作３２３０において、フィルタリングされたＩＲセンサ値が夕方の上方閾値以下でなく、かつ夕方の下方閾値以上である（すなわち、フィルタリングされたセンサ値が夕方の上方閾値を上回る）と判定された場合、フィルタリングされたＩＲセンサ値は、「曇り」である上方領域にあると判定される（動作３２５０）。この場合、制御ロジックは、モジュールＤの色合いレベルを低色合い状態（例えば、色合いレベル２または下方の色合いレベル）に設定し、モジュールＤからのこの色合いレベルは渡される。
【０２０７】
−モジュールＣおよび／またはモジュールＤの昼間アルゴリズムの実施例
昼間の間、赤外線センサにより取得された温度読み取り値は、赤外線センサの周りのローカルエリアが加熱された場合、変動する傾向があり得る。例えば、屋上に設置された赤外線センサは、真昼の太陽から熱を吸収するため、屋上によって加熱される場合がある。特定の実施態様では、昼間アルゴリズムは、特定の環境下でその色付け決定におけるＩＲセンサ読み取り値の使用を無効にし、モジュールＣを使用して光センサ読み取り値のみから色合いレベルを判定する。他の環境では、昼間アルゴリズムは、モジュールＤを使用してＩＲセンサ読み取り値に基づいて第１の色合いレベルを判定し、モジュールＣを使用してＩＲセンサ読み取り値に基づいて第２の色合いレベル判定し、次いで色合いレベルを第１および第２の色合いレベルの最大値に設定する。
【０２０８】
図３３は、昼間アルゴリズムの制御ロジックを図示しているフローチャート３３００を例示し、この昼間アルゴリズムは、モジュールＣの昼間ＩＲセンサアルゴリズム、および／またはモジュールＤの昼間光センサアルゴリズムを実装することができる。昼間アルゴリズムは、色付け制御ロジックが、現在の時刻が昼間領域の間にあると判定したときに使用される。昼間アルゴリズムは、制御ロジックの一例であり、この例は、太陽の高度角度が０以上であり、かつ高度閾値以下であるときに、図３０に示されたフローチャートの動作３０４０において実装され得る。
【０２０９】
動作３３１０において、ＩＲセンサ読み取り値を使用することが有効であるかどうかが判定される。ある場合では、色付け制御ロジックの既定値は、光センサ読み取り値が、例えば、光センサの不具合に起因して利用不可能である場合を除き、ＩＲセンサ読み取り値を使用することを無効にすることができる。別の場合では、制御ロジックは、ＩＲセンサデータが、例えば、ＩＲセンサの不具合に起因して利用不可能である場合、ＩＲセンサ読み取り値を使用することを無効にすることができる。
【０２１０】
動作３３１０において、ＩＲセンサ読み取り値を使用することが有効であると判定された場合、制御ロジックは、モジュールＤの昼間ＩＲセンサアルゴリズム、およびモジュールＣの昼間光センサアルゴリズムの両方を実行する（動作３３２０）。この場合、制御ロジックは、動作３３３０および動作３３３２の両方に進む。動作３３１０において、ＩＲセンサ読み取り値を使用することが有効でないと判定された場合、制御ロジックは、モジュールＣの昼間光センサアルゴリズムを実行する（動作３３５０）。
【０２１１】
動作３３３０において、モジュールＤの昼間ＩＲセンサアルゴリズムのロジックは、第１の色合い状態を判定するために実行される。フィルタリングされたＩＲセンサ値が、赤外線センサ測定値データベースまたは他のデータベースから取り出される。代替的に、昼間ＩＲセンサアルゴリズムのロジックは、フィルタリングされたＩＲセンサ値を計算する。フィルタリングされたＩＲセンサ値を計算し、その値を赤外線センサ測定値データベースに格納するために使用され得るロジックの一例が、図２８のフローチャートを参照して説明されているモジュールＤの制御ロジックである。昼間ＩＲセンサアルゴリズムのロジックは、フィルタリングされたＩＲセンサ値を昼間下方閾値と比較して、フィルタリングされたＩＲセンサ値が、昼間下方閾値を下回るか、昼間上方閾値を上回るか、または昼間下方閾値と昼間上方閾値との間にあるかどうかを判定する。昼間下方閾値とは、昼間領域の間に適用される、下方領域（「日当たりの良い」または「晴れ」領域）と中間領域（「部分的な曇り」領域）との間のフィルタリングされたＩＲセンサ値の下限における温度である。特定の実施態様では、昼間下方閾値は、摂氏−２０〜２０ミリ度の範囲である。一例では、昼間下方閾値は、摂氏−１ミリ度である。昼間上方閾値とは、その日の夕方の領域の間に適用される、中間領域（「部分的な曇り」領域）と上方領域（「曇り」領域）との間のフィルタリングされたＩＲセンサ値の上限における温度値である。特定の実施態様では、昼間上方閾値は、摂氏−２０〜２０ミリ度の範囲である。一例では、昼間上方閾値は、摂氏５ミリ度である。フィルタリングされたＩＲセンサ値が昼間下方閾値未満であると判定された場合、フィルタリングされたＩＲセンサ値は、「晴れ」または「日当たりの良い」領域である下方領域内にある。この場合、制御ロジックは、モジュールＤからの第１の色合いレベルを高色合い状態（例えば、色合いレベル４）に設定する。フィルタリングされたＩＲセンサ値が、昼間上方閾値以下であり、かつ上方昼間閾値以上であると判定された場合、フィルタリングされたＩＲセンサ値は、「部分的な曇り」領域である中間領域内にあると判定される。この場合、制御ロジックは、第１の色合いレベルを中間色合い状態（例えば、色合いレベル２または３）に設定する。フィルタリングされたＩＲセンサ値が、昼間上方閾値以下ではなく、かつ昼間下方閾値以上である（すなわち、フィルタリングされたセンサ値は、昼間上方閾値を上回る）と判定された場合、フィルタリングされたＩＲセンサ値は、「曇り」領域である上方領域内にあると判定される。この場合、制御ロジックは、モジュールＤの第１の色合いレベルを低色合い状態（例えば、色合いレベル２または下方の色合いレベル）に設定する。
【０２１２】
動作３３３２において、モジュールＣの昼間光センサのセンサアルゴリズムのロジックは、第２の色合いレベルを判定するために実行される。モジュールＣは、光センサ読み取り値を使用して、リアルタイム放射照度に基づいて、第２の色合いレベルを判定する。第２の色合いレベルを判定するために使用され得るモジュールＣの制御ロジックの一例が、以下のセクションの図３５に示されたフローチャート３５００に関して説明されている。
【０２１３】
動作３３４０において、昼間アルゴリズムのロジックは、動作３３３０において判定されたＩＲセンサ読み取り値に基づいて、モジュールＤを使用して第１の色合いレベルの最大値を計算し、また、動作３３３２において判定された光センサ読み取り値に基づいて、モジュールＣを使用して第２の色合いレベルを計算する。昼間アルゴリズムからの色合いレベルは、計算された第１の色合いレベルの最大、および計算された第２の色合いレベル、ならびにそれに設定される。モジュールＣまたはＤからの色合いレベルは返される。
【０２１４】
動作３３１０において、ＩＲセンサ読み取り値を使用することが有効でないと判定された場合、制御ロジックは、モジュールＣの昼間光センサアルゴリズムを実行する（動作３３５０）。動作３３５０において、モジュールＣの昼間光センサのセンサアルゴリズムのロジックは、第２の色合いレベルを判定するために実行される。この場合、昼間アルゴリズムからの色合い状態は、光センサ読み取り値に基づいて第２の色合いレベルに設定され、モジュールＣからのこの色合いレベルが返される。第２の色合いレベルを判定するために使用され得るモジュールＣの制御ロジックの一例が、図３５に示されたフローチャートに関して説明されている。
【０２１５】
−モジュールＣおよびモジュールＣ'の実施例
図３５は、１つまたは複数のエレクトロクロミック窓の色合いレベルを判定するためのモジュールＣの一例のための制御ロジックのフローチャート３５００を示す。動作３５２０において、現在のフィルタリングされた光センサ値が、建物の外部の条件を反映して受信され、閾値処理が実施されて、適用する提案された色合いレベルを計算する。一例では、現在のフィルタリングされた光センサ値は、１つのサンプル時刻において複数の光センサ（例えば、マルチセンサデバイスの１３個（１３）の光センサ）が取得した測定値の最大値である。別の例では、フィルタリングされた光センサ値は、異なるサンプル時刻で取得された複数の光センサ読み取り値のローリング平均値または中央値であり、この場合、各読み取り値は、サンプル時刻における複数の光センサによって取得されたすべての読み取り値のうちの最大読み取り値である。別の例では、フィルタリングされた光センサ値は、単一光センサによって、異なるサンプル時刻で取得された複数の光センサ読み取り値のローリング平均値または中央値である。現在のフィルタリングされた光センサ値を計算するために使用され得る制御ロジックの一例が、モジュールＣの制御ロジックを示す図３６のフローチャート３６００に説明されている。モジュールＣのロジックは、ローカル窓コントローラ、ネットワークコントローラ、マスタコントローラ、および／またはマルチセンサデバイスの１つまたは複数のプロセッサによって実行することができる。
【０２１６】
動作３５２０において、制御ロジックは、閾値処理を使用し、現在のフィルタリングされた光センサ値が、ある期間にわたって１つまたは複数の閾値を横断したかどうかを判定することによって、提案された色合いレベルを計算する。この期間は、例えば、現在の時刻と、光センサにより取得された最後のサンプルの時刻との間の期間、または現在の時刻と、以前に取得された複数のサンプル読み取り値のうちの最初の時刻との間の期間であってもよい。光センサ読み取り値は、１分に１回、１０秒毎に１回、１０分毎に１回などの定期的な基準で取得されてもよい。
【０２１７】
一実施態様では、閾値処理は、２つの閾値、すなわち、下方光センサ閾値および上方光センサ閾値を使用することを包含する。光センサ値が、上方光センサ閾値よりも高いと判定された場合、光センサ値は、「晴れ」または「日当たりの良い」領域である、より高い領域にある。この場合、制御ロジックは、モジュールＣからの提案された色合いレベルは、より高色合い状態（例えば、色合いレベル４）であると判定する。光センサ値が、上方光センサ閾値以下であり、かつ下方光センサ閾値以上であると判定された場合、光センサ値は、「部分的な曇り」領域である中間領域にあると判定される。この場合、制御ロジックは、モジュールＣからの提案された色合いレベルが、中間色合い状態（例えば、色合いレベル２または３）であると判定する。光センサのセンサ値が、夕方の上方閾値を上回ると判定された場合、光センサ値は、「曇り」領域である上方領域にあると判定される。この場合、制御ロジックは、モジュールＣからの提案された色合いレベルが低色合い状態（例えば、色合いレベル２または下方の色合いレベル）であると判定する。
【０２１８】
現在の時刻ｔｉが、閉鎖期間が終了した後の瞬間的な時刻である場合、制御ロジックは、閉鎖期間中にモニタリングされた条件に基づいて、動作３５２０における提案された色合いレベルを計算する。閉鎖期間中にモニタリングされた条件に基づいて計算された、この提案された色合いレベルは、モニタリングされた入力の統計的な評価に基づいている。様々な技術が、待機時間中にモニタリングされる入力の統計的な評価のために使用することができる。一例としては、待機時間中に加算平均した色合いレベルである。待機時間中、制御ロジックは、入力をモニタリングし、判定された色合いレベルを計算する動作を実施する。次いで、動作は、待機時間にわたって、判定された色合いレベルを加算平均して、どの方向が１つの色合い領域移行のために提案されるかを判定する。
【０２１９】
動作３５２５において、制御ロジックは、現在の時刻が閉鎖期間中にあるかどうかを判定する。現在の時刻が閉鎖期間中にある場合、モジュールＣは、色合いレベルを変更しない。閉鎖期間中、外部条件の光センサ値は、モニタリングされている。さらに、制御ロジックは、閉鎖期間中、動作３５２０によって判定された提案された色合いレベルをモニタリングする。現在の時刻が、閉鎖期間中にないと判定された場合、制御ロジックは、動作３５３０に進む。
【０２２０】
動作３５３０において、ロジックは、さらに進んで、現在の情報が色合い移行を提案するかどうかを判定する。この動作３５３０は、動作３５２０で判定された提案された色合いレベルを、１つまたは複数の窓に適用された現在の色合いレベルと比較して、色合いレベルが異なっているかどうかを判定する。提案された色合いレベルが現在の色合いレベルと異なっていない場合、色合いレベルは変更されない。
【０２２１】
動作３５５０において、提案された色合いレベルが、現在の色合いレベルと異なっている場合、ロジックは、１つの色合いレベルである新しい色合いレベルを、動作３５２０で判定された提案された色合いレベルに設定する（提案された色合いレベルが、現在の色合いレベルから２つ以上異なる色合いレベルであっても）。例えば、動作３５２０において判定された提案された色合い領域が、第１の色合いレベルから第３の色合いレベルになっても、モジュールＣによって返される色合いレベルは、１つの色合いレベルを第２の色合いレベルに移行させることができる。
【０２２２】
動作３５７０において、閉鎖期間が設定されて、閉鎖期間中、他の色合いレベルへの移行を閉鎖する。閉鎖期間中、外部条件の光センサ値は、モニタリングされている。さらに、制御ロジックは、閉鎖期間中にモニタリングされた条件に基づいて、各間隔の間で、提案された色合い領域を計算する。モジュールＣから渡された新しい色合いレベルは、動作３５２０において判定された提案された色合いレベルに向かう１つの色合いレベルとして、動作３５５０において判定される。
【０２２３】
図３６は、一実施態様による、フィルタリングされた光センサ値を判定し、フィルタリングされた光センサ値をデータベースに格納するために使用され得るモジュールＣ'のロジックを描くフローチャート３６００を示す。次いで、動作３５２０において、フィルタリングされた光センサ値は、図３５に図示してあるモジュールＣによって取り出すことができる。一態様では、モジュールＣは、図３５に図示してあるロジックを含み、さらに、モジュールＣ'のロジックを含み、図３５の動作に先立ってその動作を実行する。
【０２２４】
モジュールＣ１'のロジックは、ローカル窓コントローラ、ネットワークコントローラ、マスタコントローラ、および／またはマルチセンサデバイスの１つまたは複数のプロセッサによって実行されてもよい。動作３１１０において、モジュールＣ１'の動作を実行するプロセッサ（複数可）は、現在の時刻での入力光センサ読み取り値として受信する。光センサ読み取り値は、建物の通信ネットワークを介して、例えば、屋上のマルチセンサデバイスから受信することができる。受信した光センサ読み取り値は、リアルタイムの放射照度読み取り値である。
【０２２５】
動作３６１０において、モジュールＣ'のロジック動作を実行するプロセッサ（複数可）は、現在の時刻において入力された生の光センサ読み取り値として受信する。光センサ読み取り値は、建物の通信ネットワークを介して、例えば、屋上のマルチセンサデバイスから受信することができる。受信した光センサ読み取り値は、リアルタイムの放射照度読み取り値である。
【０２２６】
動作３６２０において、モジュールＣ'のロジック動作を実行するプロセッサ（複数可）は、２つ以上の光センサにより取得された生の測定値に基づいて、光センサ値を計算する。例えば、光センサ値は、単一のサンプル時刻において２つ以上の光センサにより取得された測定の最大値として計算されてもよい。
【０２２７】
動作３６３０において、プロセッサ（複数可）は、動作３６２０で判定された光センサ値を有する短期ボックスカーおよび長期ボックスカーを更新する。本明細書に記載されているモジュールＣおよび他の制御ロジックでは、フィルタリングされた光センサ値が、色付けを決定するための入力として使用される。本明細書に記載されているモジュールＣおよび他のロジックは、短期および長期ボックスカー（フィルタ）を使用して、フィルタリングされたセンサ値を判定する。短いボックスカー（例えば、１０分間、２０分間、５分間などにわたって取得されたサンプル値を利用するボックスカー）は、長いボックスカー（例えば、１時間、２時間などにわたって取得されたサンプル値を利用するボックスカー）のより多い数のセンササンプル（例えば、ｎ＝１０、２０、３０、４０など）に比べて、より少ない数のセンササンプル（例えば、ｎ＝１、２、３、...、１０など）に基づいている。ボックスカー（照度）値は、ボックスカー内のサンプル値の平均値、代表値、中央値、または他の代表的な値に基づいてもよい。一例では、短いボックスカー値は、センササンプルの平均値であり、長いボックスカー値は、光センササンプルの平均値である。
【０２２８】
動作３６４０において、プロセッサ（複数可）は、動作３６３０において更新されたボックスカー内の現在の光センサ読み取り値に基づいて、短いボックスカー値（Ｓｂｏｘｃａｒ値）および長いボックスカー値（Ｌｂｏｘｃａｒ値）を判定する。この例では、各ボックスカー値は、動作３６３０において行われた最後の更新の後に、ボックスカー内の光センサ読み取り値の平均値を取ることによって計算される。別の例では、各ボックスカー値は、動作３６３０において行われた最後の更新の後に、ボックスカー内の光センサ読み取り値の中央値を取ることによって計算される。
【０２２９】
動作３６５０において、モジュールＣ'のロジック動作を実行するプロセッサ（複数可）は、Ｓｂｏｘｃａｒ値とＬｂｏｘｃａｒ値との間の差の絶対値の値が、デルタ閾値を上回るかどうかを評価する（｜Ｓｂｏｘｃａｒ値−Ｌｂｏｘｃａｒ値｜＞デルタ閾値）。場合によっては、デルタ閾値の値は、摂氏０ミリ度〜摂氏１０ミリ度の範囲である。ある場合では、デルタ閾値の値は、摂氏０ミリ度である。
【０２３０】
その差がデルタ閾値を上回る場合、Ｓｂｏｘｃａｒ値は、光センサ値に割り当てられ、短期ボックスカーは、リセットされてその値を空にする（動作３６６０）。その差がデルタ閾値を上回らない場合、Ｌｂｏｘｃａｒ値は、光センサ値に割り当てられ、長期ボックスカーは、リセットされてその値を空にする（動作３６７０）。動作３６８０において、光センサ値は、データベースに保存される。
【０２３１】
特定の実施態様では、本明細書に記載されている制御ロジックは、１つまたは複数の赤外線センサおよび周囲温度センサからの温度読み取り値に基づいて、フィルタリングされたセンサ値を使用して、朝および夕方の、ならびに／または日の出直前の時刻における曇り条件を判定する。１つまたは複数の赤外線センサは、太陽光レベルとは概ね無関係に動作して、色付け制御ロジックが日の出前の曇り条件を判定し、また、太陽が沈んでいるときに、朝および夕方の間に適切な色合いレベルを判定および維持することを可能にしている。さらに、１つまたは複数の赤外線センサからの温度読み取り値に基づいて、フィルタリングされたセンサ値を使用して、可視光光センサが影に隠れるか、または他の方法で遮られている場合であっても、曇り条件を判定することができる。
【０２３２】
本明細書に記載されている特定の実施形態では、制御ロジックは、将来の時刻において発生する可能性が高い条件（本明細書ではまた、「将来の条件」とも称される）に基づいて、色合いレベルを判定する。例えば、色合いレベルが、将来の時刻（例えば、ｔｉ＝現在の時刻＋１つまたは複数のエレクトロクロミック窓の移行時間などの時間の持続期間）における曇り条件の発生の尤度に基づいて、判定されてもよい。これらのロジック演算で使用される将来の時刻は、色合いレベルへの窓の移行が、制御命令を受信した後に完了することを可能にするのに十分な将来の時間に設定することができる。これらの場合、コントローラが、実際の移行に先立って、現在の時刻に命令を送信することができる。移行が完了するまでに、窓は、当該将来の時刻において望まれる色合いレベに移行することになる。他の実施形態では、開示された制御ロジックを使用して、例えば、持続期間を０に設定することによって、現在の時刻において発生するまたは発生しそうである条件に基づいて、色合いレベルを判定することができる。例えば、特定のエレクトロクロミック窓では、新しい色合いレベル、例えば中間色合いレベルへの移行時間が非常に短いため、現在の時刻に基づいて、ある色合いレベルに移行するための命令を送信することが適切であり得る。
【０２３３】
上記のような技術は、コンピュータソフトウェアをモジュール式または統合方式で使用する制御ロジックの形態で実施することが可能であることを理解されたい。本明細書で提供される開示および教示に基づいて、当業者は、ハードウェア、およびハードウェアとソフトウェアとの組み合わせを使用して開示された技術を実施するための他の手段および／または方法を知り、理解するであろう。
【０２３４】
本出願に記載されるソフトウェアコンポーネントまたは機能のうちのいずれも、例えば、従来のもしくはオブジェクト指向の技術を使用する、例えば、Ｊａｖａ（登録商標）、Ｃ＋＋、またはＰｙｔｈｏｎなどの任意の好適なコンピュータ言語を使用して、プロセッサによって実行されるソフトウェアコードとして実装され得る。ソフトウェアコードは、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）などのコンピュータ可読媒体、ハードドライブまたフロッピーディスクなどの磁気媒体、もしくはＣＤ−ＲＯＭなどの光媒体上に、一連の命令またはコマンドとして格納されてもよい。任意のそのようなコンピュータ可読媒体は、単一の計算装置上または中に存在してもよく、システムまたはネットワーク内の異なる計算装置上または中に存在してもよい。
【０２３５】
前述の開示された実施形態は、理解を容易にするためにある程度詳細に記載されているが、記載された実施形態は例示的であり、限定的ではないと考えられるべきである。特定の変更および修正が、添付の特許請求の範囲内で実施され得ることが、当業者には明らかであろう。
【０２３６】
窓または建物の内部を通って受けられる採光を制御するための前述の開示された実施形態は、エレクトロクロミック窓のような光学的に切り替え可能な窓との関連で記載されてきたが、当業者は、本明細書に記載の方法が、窓用日よけ、窓用カーテン、窓用ブラインド、または光が建物の内部空間に達するのを制限または遮断するように調整され得る他のデバイスの位置を調整するための適切なコントローラ上でどのように実施され得るかを理解できる。場合によっては、本明細書に記載の方法を使用して、１つまたは複数の光学的に切り替え可能な窓の色合い、および窓用日よけ装置の位置の両方を制御することができる。すべてのそのような組み合わせが本開示の範囲内に入ることを意図している。
【０２３７】
本開示の範囲から逸脱することなく、任意の実施形態からの１つまたは複数の特徴を任意の他の実施形態の１つまたは複数の特徴と組み合わせることができる。さらに、本開示の範囲から逸脱することなく、任意の実施形態に対して修正、追加、または省略を行うことができる。任意の実施形態の構成要素は、本開示の範囲から逸脱することなく、特定の必要性に従って統合または分離することができる。
【図１Ａ】
2021518498.tif 000003
【図１Ｂ】
2021518498.tif 000004
【図１Ｃ】
2021518498.tif 000005
【図２Ａ】
2021518498.tif 000006
【図２Ｂ】
2021518498.tif 000007
【図３Ａ】
2021518498.tif 000008
【図３Ｂ】
2021518498.tif 000009
【図３Ｃ】
2021518498.tif 000010
【図４】
2021518498.tif 000011
【図５】
2021518498.tif 000012
【図６】
2021518498.tif 000013
【図７】
2021518498.tif 000014
【図８Ａ】
2021518498.tif 000015
【図８Ｂ】
2021518498.tif 000016
【図９】
2021518498.tif 000017
【図１０】
2021518498.tif 000018
【図１１】
2021518498.tif 000019
【図１２】
2021518498.tif 000020
【図１３】
2021518498.tif 000021
【図１４】
2021518498.tif 000022
【図１５】
2021518498.tif 000023
【図１６】
2021518498.tif 000024
【図１７Ａ】
2021518498.tif 000025
【図１７Ｂ】
2021518498.tif 000026
【図１８】
2021518498.tif 000027
【図１９】
2021518498.tif 000028
【図２０Ａ】
2021518498.tif 000029
【図２０Ｂ】
2021518498.tif 000030
【図２１】
2021518498.tif 000031
【図２２】
2021518498.tif 000032
【図２３】
2021518498.tif 000033
【図２４】
2021518498.tif 000034
【図２５】
2021518498.tif 000035
【図２６】
2021518498.tif 000036
【図２７】
2021518498.tif 000037
【図２８】
2021518498.tif 000038
【図２９】
2021518498.tif 000039
【図３０】
2021518498.tif 000040
【図３１】
2021518498.tif 000041
【図３２】
2021518498.tif 000042
【図３３】
2021518498.tif 000043
【図３４】
2021518498.tif 000044
【図３５】
2021518498.tif 000045
【図３６】
2021518498.tif 000046
【国際調査報告】
2021518498.tif 000047
2021518498.tif 000048
2021518498.tif 000049
2021518498.tif 000050