JP7749685B2 - 建物管理システム、同システムにおける故障状態に起因して浪費された炭素排出量を判定する方法、及び故障検出のシステム - Google Patents

Description

関連出願の相互参照
本出願は、２０２１年３月１７日に出願されたインド特許仮出願第２０２１／２１０１１４２５号の利益及びそれに対する優先権を主張するものであり、その開示全体が、参照により本明細書に組み込まれる。

本開示は、概して、建物管理システム（ＢＭＳ）に関し、より詳細には、故障又は警報状態に起因して建物設備によって浪費されたエネルギー量を判定することに関する。

様々な実装形態では、ＢＭＳは、多種多様な建物サブシステム及び設備を監視及び制御することによって動作する。ＢＭＳは、建物運用を改善することができ、建物（例えば、システム及び設備）効率を向上させること、運用コストを減少させること、（例えば、自動化を通じて）ユーザ入力を低減すること、ダウンタイムを低減することなどによって、建物所有者又はオペレータが様々な運用目標を達成することを可能にすることができる。ＢＭＳに含まれる設備などの建物設備には、効率の低下及び予期しないダウンタイムをもたらす故障状態が発生することがあり、その結果、エネルギー（電力など）の浪費をもたらす可能性がある。したがって、故障状態で浪費されたエネルギー量だけでなく、故障に関連付けられたコスト及び故障に起因して生成された排出量も判定することが有益であろう。

本開示の１つの実装形態は、建物管理システム（ＢＭＳ）であって、命令が記憶された１つ以上のメモリデバイスを含み、命令が、１つ以上のプロセッサによって実行されたときに、１つ以上のプロセッサに、動作データを使用して１つ以上の故障検出ルールを評価して、複数の建物デバイスのうちの少なくとも１つに故障状態が発生しているかどうかを判定することと、複数の建物デバイスのうちの少なくとも１つに故障状態が発生していると判定することに応答して、故障状態に関連付けられた故障排出モデルに基づいて、故障状態に起因して生成された炭素排出量を判定することと、故障状態に関連付けられた炭素排出量に基づいて自動応答を開始することと、を含む動作を実施させる、建物管理システム（ＢＭＳ）である。

いくつかの実施形態では、動作は、ユーザ入力に基づいて、１つ以上の故障検出ルールのうちの少なくとも１つを取得することと、１つ以上の故障検出ルールを複数の建物デバイスにマッピングすることと、を更に含む。

いくつかの実施形態では、ユーザ入力は、１つ以上の故障検出ルールのうちのある故障検出ルールに関連付けられた故障の説明と、故障の優先度と、故障検出ルールを定義する方程式と、を含む。

いくつかの実施形態では、動作は、動作データに関連付けられた測定単位に基づいて故障排出モデルを修正することを更に含み、故障排出モデルは、故障排出モデルの各項が共通の測定単位によって定義されるように修正される。

いくつかの実施形態では、動作は、故障状態に関連付けられた故障排出モデルに基づいて、故障状態に起因して浪費されたエネルギー量を計算することを更に含み、生成された炭素排出量は、浪費されたエネルギー量と、浪費されたエネルギーを生成するために使用されたエネルギー源を含むエネルギー混合情報とに基づいて判定される。

いくつかの実施形態では、第１の建物デバイスにおける故障状態に起因して浪費されたエネルギー量は、第１の建物デバイスの故障状態のために第２の建物デバイスによって消費された追加のエネルギーを含む。

いくつかの実施形態では、自動応答は、故障状態を補正するための作業指図を生成することを含み、作業指図は、複数の建物デバイスのうちの少なくとも１つに故障状態が発生していることを識別し、かつ故障の説明と、複数の建物デバイスのうちの少なくとも１つの場所と、を含む。

いくつかの実施形態では、自動応答は、故障状態に基づいて、故障状態の指標と、複数の建物デバイスのうちの少なくとも１つに故障状態が発生していることの指標と、生成された排出の指標とを含むグラフィカルユーザインターフェースを生成することと、ユーザデバイスを介してグラフィカルユーザインターフェースを表示することと、を含む。

いくつかの実施形態では、自動応答は、故障状態の検出に基づいて警告を生成することであって、警告が、故障状態の優先度の指標を含み、優先度が、故障に起因して生成された排出量に基づいて判定される、生成することと、警告をユーザデバイスに送信することと、を含む。

本開示の別の実装形態は、建物管理システム（ＢＭＳ）における故障状態に起因して浪費されたエネルギー量を判定する方法である。方法は、複数の建物デバイスから動作データを取得することと、動作データを使用して１つ以上の故障検出ルールで評価して、複数の建物デバイスのうちの少なくとも１つに故障状態が発生しているかどうかを判定することと、複数の建物デバイスのうちの少なくとも１つに故障状態が発生していると判定することに応答して、故障状態に関連付けられた故障排出モデルに基づいて、故障状態に起因して生成された炭素排出量を判定することと、故障状態に関連付けられたコストに基づいて自動応答を開始することと、を含む。

いくつかの実施形態では、方法は、ユーザデバイスへのユーザ入力を介して、１つ以上の故障検出ルールのうちの少なくとも１つを受信することと、１つ以上の故障検出ルールを複数の建物デバイスにマッピングすることと、を更に含む。

いくつかの実施形態では、ユーザ入力は、１つ以上の故障検出ルールのうちのある故障検出ルールに関連付けられた故障の説明と、故障の優先度と、故障検出ルールを定義する方程式と、を含む。

いくつかの実施形態では、動作は、動作データに関連付けられた測定単位に基づいて故障排出モデルを修正することを更に含み、故障排出モデルは、故障排出モデルの各項が共通の測定単位によって定義されるように修正される。

いくつかの実施形態では、方法は、故障状態及びエネルギー混合情報に関連付けられた故障排出モデルに基づいて、故障状態に起因して浪費されたエネルギー量を計算することを更に含み、浪費されたエネルギー量は、故障状態の時間期間にわたって複数の建物デバイスのうちの少なくとも１つによって消費された第１のエネルギー量と、通常動作の時間期間中に複数の建物デバイスのうちの少なくとも１つによって消費された第２のエネルギー量とを比較することによって判定され、生成された炭素排出量は、浪費されたエネルギー量と、浪費されたエネルギーを生成するために使用されたエネルギー源を含むエネルギー混合情報と、に基づいて判定される。

いくつかの実施形態では、第１の建物デバイスにおける故障状態に起因して浪費されたエネルギー量は、第１の建物デバイスにおける故障のために第２の建物デバイスによって消費された追加のエネルギーを含む。

いくつかの実施形態では、自動応答は、故障状態を補正するための作業指図を生成することを含み、作業指図は、複数の建物デバイスのうちの少なくとも１つに故障状態が発生していることを識別し、かつ故障の説明と、複数の建物デバイスのうちの少なくとも１つの場所と、を含む。

いくつかの実施形態では、自動応答は、故障状態に基づいて、故障状態の指標と、複数の建物デバイスのうちの少なくとも１つに故障状態が発生していることの指標と、生成された排出の指標とを含むグラフィカルユーザインターフェースを生成することと、ユーザデバイスを介してグラフィカルユーザインターフェースを表示することと、を含む。

いくつかの実施形態では、自動応答は、故障状態の検出に基づいて警告を生成することであって、警告が、故障状態の優先度の指標を含み、優先度が、故障に起因して生成された排出量に基づいて判定される、生成することと、警告をユーザデバイスに送信することと、を含む。

本開示の更なる別の実装形態は、故障検出システムであって、命令が記憶された１つ以上のメモリデバイスを備え、命令が、１つ以上のプロセッサによって実行されたときに、１つ以上のプロセッサに、ユーザ入力を介して少なくとも１つの故障検出ルールを受信することであって、少なくとも１つの故障検出ルールが、少なくとも１つの故障検出ルールを定義する方程式を含む、受信することと、少なくとも１つの故障検出ルールを、１つ以上の建物デバイスにマッピングすることと、１つ以上の建物デバイスから動作データを取得することと、動作データを使用して少なくとも１つの故障検出ルールを評価して、１つ以上の建物デバイスのうちのある建物デバイスに故障状態が発生していることを判定することと、故障状態に関連付けられた故障排出モデルに基づいて、故障状態に起因して浪費されたエネルギー量を判定することと、浪費されたエネルギー量とエネルギー混合情報とに基づいて、故障状態に起因して生成された炭素排出量を計算することと、を含む動作を実施させる、故障検出システムである。

いくつかの実施形態では、動作は、故障状態に基づいて自動応答を開始することを更に含み、自動応答は、故障状態を補正するための作業指図を生成することを含み、作業指図は、建物デバイスに故障状態が発生していることを識別し、かつ故障の説明と、建物デバイスの場所と、を含む。

本開示の様々な目的、態様、特徴、及び利点は、添付の図面と併せて、同様の参照文字が全体を通して対応する要素を識別する、詳細な説明を参照することによって、より明らかになり、よりよく理解されるであろう。図面において、同様の参照番号は、概して、同じ、機能的に同様、及び／又は構造的に同様の要素を示す。

いくつかの実施形態による、ＨＶＡＣシステムを装備した建物の図面である。 いくつかの実施形態による、図１の建物と併せて使用され得るウォーターサイドシステムのブロック図である。 いくつかの実施形態による、図１の建物と併せて使用され得るエアサイドシステムのブロック図である。 いくつかの実施形態による、図１の建物を監視及び／又は制御するために使用され得る建物管理システム（ＢＭＳ）のブロック図である。 いくつかの実施形態による、図１の建物及びＨＶＡＣシステムを監視及び制御するために使用することができる別の建物管理システム（ＢＭＳ）のブロック図である。 いくつかの実施形態による、建物設備を監視し、故障状態を検出するための故障検出システムのブロック図である。 いくつかの実施形態による、建物設備を監視し、故障状態を検出するための故障検出システムのブロック図である。 いくつかの実施形態による、故障に関連付けられたコストを判定するための方法である。 いくつかの実施形態による、故障に起因して生成された排出量を判定するための方法である。 図７Ａの方法において生じるデータフローを示すチャートである。 図７Ｂの方法において生じるデータフローを示すチャートである。 いくつかの実施形態による、故障検出ルールを確立するための例示的なインターフェースである。 いくつかの実施形態による、故障データを視認するための例示的なインターフェースである。 いくつかの実施形態による、作業指図管理のための例示的なインターフェースである。 いくつかの実施形態による、データ点の読み取り頻度を設定するための例示的なインターフェースである。 いくつかの実施形態による、故障リストを視認するための例示的なインターフェースである。 いくつかの実施形態による、故障検出ルールを確立するための例示的なインターフェースである。 いくつかの実施形態による、故障データを視認するための例示的なインターフェースである。 いくつかの実施形態による、例示的な電気コストルール及び熱コストルールを示す表である。 いくつかの実施形態による、例示的な電気コストルール及び熱コストルールを示す表である。 いくつかの実施形態による、例示的な電気コストルール及び熱コストルールを示す表である。 いくつかの実施形態による、例示的な電気コストルール及び熱コストルールを示す表である。 いくつかの実施形態による、エネルギー源のコスト及び炭素排出量を入力するための例示的なインターフェースである。 いくつかの実施形態による、故障情報を視認するための例示的なインターフェースである。 いくつかの実施形態による、統計的故障データを視認するための例示的なインターフェース。 いくつかの実施形態による、統計的故障データを視認するための例示的なインターフェース。

図を全体的に参照すると、いくつかの実施形態による、故障検出及び故障コスト判定のためのシステム及び方法が示されている。具体的には、故障検出システムは、故障検出ルールのデータベースを維持し得、その各々は、対応する建物デバイス、システム、サブシステムなどにマッピングすることができる。定期的又は不定期な時間間隔で（例えば、毎秒、毎分、毎日、断続的に、需要に応じてなど）、建物設備動作データは、１つ以上の建物デバイスに故障が発生しているかどうかを判定するために、故障検出ルールに関して（例えば、故障検出ルールに関連付けられた特定の基準を満たすことによって）収集及び分析され得る。

建物デバイスに故障が発生していると判定された（すなわち、建物デバイスが故障状態にある）場合には、故障検出システムは、故障の持続時間にわたって浪費されるエネルギー（例えば、電気エネルギー、熱エネルギーなど）の量を判定するように構成され得る。エネルギーは、例えば、建物デバイスが非効率的に動作すること、又は故障状態にあるデバイスを補償するためにより大きな体積で動作する追加の建物デバイスに起因して浪費され得る。エネルギー浪費の量が判定されると、故障検出システムは、関連付けられたエネルギー資源（例えば、電気、天然ガスなど）の現在のコスト又はレートに基づいて、浪費されるエネルギーに関連付けられたコストを計算し得る。例えば、３０分間にわたって故障状態が発生している建物ＨＶＡＣシステムのチラーは、エネルギー提供者（例えば、電力会社）から１ｋＷｈ当たりＹドルで購入された電力のＸｋＷｈを浪費し得る。したがって、故障状態のコストは、浪費されるエネルギーに関連付けられた総ドル額として判定され得る。また、故障検出システムは、エネルギー源のタイプ及び故障の持続時間に基づいて、故障に起因して生成された排出量も計算し得る。

いくつかの実施形態では、故障の検出時、並びに／又は故障に起因して生成された故障及び／若しくは排出に関連付けられたコストの判定に応答して、１つ以上の自動応答アクションが開始され得る。そのようないくつかの実施形態では、自動化されたアクションは、技術者又は他のユーザに故障状態を補正するように命令する作業指図を生成することを含む。作業指図は、故障状態が発生している建物デバイスの識別を含んでよく、また故障の説明及び建物デバイスの場所を含んでもよい。いくつかの実施形態では、作業指図を生成することはまた、技術者からの訪問を自動的にスケジュールすることを含んでもよい。いくつかの実施形態では、自動化されたアクションは、検出された故障に関連する情報と、故障に関連付けられたコスト及び／又は故障に起因して生成された排出に関連するコストとを提示する、様々なユーザインターフェースを生成及び表示することを含むことができる。したがって、故障状態は、迅速に解決され得、場合によっては、高優先度、高コスト、及び／又は高排出の故障は、他の故障よりも緊急に識別及び補正され得る。

建物システムを用いた建物
ここで図１～図４を参照すると、いくつかの実施形態による、本開示のシステム及び方法を実装することができる例示的なＢＭＳ及びＨＶＡＣシステムが示されている。特に図１を参照すると、建物１０の斜視図が示されている。建物１０は、ＢＭＳによりサービス提供されている。ＢＭＳは、概して、建物又は建物区域の中若しくはその周囲の設備を制御、監視、及び管理するように構成されたデバイスのシステムである。ＢＭＳは、例えば、ＨＶＡＣシステム、セキュリティシステム、照明システム、火災安全システム、建物機能若しくはデバイスを管理することができる任意の他のシステム、又はそれらの任意の組み合わせを含むことができる。

建物１０にサービスを提供するＢＭＳは、ＨＶＡＣシステム１００を含む。ＨＶＡＣシステム１００は、建物１０に加熱、冷却、換気、又は他のサービスを提供するように構成された複数のＨＶＡＣデバイス（例えば、ヒータ、チラー、空気処理ユニット、ポンプ、ファン、熱エネルギー貯蔵など）を含むことができる。例えば、ＨＶＡＣシステム１００は、ウォーターサイドシステム１２０及びエアサイドシステム１３０を含むように示されている。ウォーターサイドシステム１２０は、加熱された又は冷やされた流体をエアサイドシステム１３０の空気処理ユニットに提供することができる。エアサイドシステム１３０は、加熱された又は冷やされた流体を使用して、建物１０に提供される空気流を加熱又は冷却することができる。ＨＶＡＣシステム１００で使用することができる例示的なウォーターサイドシステム及びエアサイドシステムは、図２～図３を参照しながらより詳細に説明される。

ＨＶＡＣシステム１００は、チラー１０２、ボイラ１０４、及び屋上空気処理ユニット（ＡＨＵ）１０６を含むように示されている。ウォーターサイドシステム１２０は、ボイラ１０４及びチラー１０２を使用して、作動流体（例えば、水、グリコールなど）を加熱又は冷却することができ、作動流体をＡＨＵ１０６に循環させることができる。様々な実施形態では、ウォーターサイドシステム１２０のＨＶＡＣデバイスは、建物１０内又はその周囲に（図１に示されるように）、又は中央プラント（例えば、チラープラント、蒸気プラント、熱プラントなど）などのオフサイトの場所に位置することができる。作動流体は、建物１０で加熱又は冷却が必要とされるかどうかに応じて、ボイラ１０４で加熱されるか、又はチラー１０２で冷却されることができる。ボイラ１０４は、例えば、可燃性材料（例えば、天然ガス）を燃焼させることによって、又は電気加熱要素を使用することによって、循環流体に熱を加えることができる。チラー１０２は、循環流体を熱交換器（例えば、蒸発器）内の別の流体（例えば、冷媒）との熱交換関係に置いて、循環流体から熱を吸収することができる。チラー１０２及び／又はボイラ１０４からの作動流体は、配管１０８を介してＡＨＵ１０６に輸送することができる。

ＡＨＵ１０６は、作動流体を、ＡＨＵ１０６を通過する空気流との熱交換関係に置くことができる（例えば、冷却コイル及び／又は加熱コイルの１つ以上の段階を介して）。空気流は、例えば、外気、建物１０内からの戻り空気、又はその両方の組み合わせであることができる。ＡＨＵ１０６は、空気流と作動流体との間で熱を伝達して、空気流に加熱又は冷却を提供することができる。例えば、ＡＨＵ１０６は、作動流体を含む熱交換器上に又は熱交換器を通って空気流を通過させるように構成された、１つ以上のファン又は送風機を含むことができる。次いで、作動流体は、配管１１０を介してチラー１０２又はボイラ１０４に戻ることができる。

エアサイドシステム１３０は、ＡＨＵ１０６によって供給される空気流（すなわち、供給空気流）を、空気供給ダクト１１２を介して建物１０に送達することができ、空気戻りダクト１１４を介して建物１０からＡＨＵ１０６に戻り空気を提供することができる。いくつかの実施形態では、エアサイドシステム１３０は、複数の可変風量（ＶＡＶ）ユニット１１６を含む。例えば、エアサイドシステム１３０は、建物１０の各フロア又は各ゾーンに別個のＶＡＶユニット１１６を含むように示されている。ＶＡＶユニット１１６は、ダンパ又は建物１０の個々のゾーンに提供される供給空気流の量を制御するように動作することができる他の流量制御要素を含むことができる。他の実施形態では、エアサイドシステム１３０は、中間ＶＡＶユニット１１６又は他の流量制御要素を使用することなく、供給空気流を建物１０の１つ以上のゾーンに（例えば、供給ダクト１１２を介して）送達する。ＡＨＵ１０６は、供給空気流の属性を測定するように構成された様々なセンサ（例えば、温度センサ、圧力センサなど）を含むことができる。ＡＨＵ１０６は、ＡＨＵ１０６内及び／又は建物ゾーン内に位置するセンサから入力を受信することができ、ＡＨＵ１０６を通る供給空気流の流量、温度、又は他の属性を調整して、建物ゾーンの設定値条件を達成することができる。

図２では、ウォーターサイドシステム２００は、複数のサブプラント２０２～２１２を有する中央プラントとして示されている。サブプラント２０２～２１２は、ヒータサブプラント２０２、熱回収チラーサブプラント２０４、チラーサブプラント２０６、冷却塔サブプラント２０８、高温熱エネルギー貯蔵（ＴＥＳ）サブプラント２１０、及び低温熱エネルギー貯蔵（ＴＥＳ）サブプラント２１２を含むように示されている。サブプラント２０２～２１２は、建物又は構内の熱エネルギー負荷（例えば、温水、冷水、加熱、冷却など）を供するために、公益事業者からの資源（例えば、水、天然ガス、電気など）を消費する。例えば、ヒータサブプラント２０２は、ヒータサブプラント２０２と建物１０との間で温水を循環させる温水ループ２１４内の水を加熱するように構成され得る。チラーサブプラント２０６は、チラーサブプラント２０６建物１０との間で冷水を循環させる冷水ループ２１６内の水を冷やすように構成され得る。熱回収チラーサブプラント２０４は、熱を冷水ループ２１６から温水ループ２１４に伝達して、温水に追加の加熱及び冷水に追加の冷却を提供するように構成され得る。復水器水ループ２１８は、チラーサブプラント２０６内の冷水から熱を吸収し、冷却塔サブプラント２０８内の吸収された熱を排出するか、又は吸収された熱を温水ループ２１４に伝達し得る。高温ＴＥＳサブプラント２１０及び低温ＴＥＳサブプラント２１２は、後続の使用のために、それぞれ、高温熱エネルギー及び低温熱エネルギーを貯蔵し得る。

温水ループ２１４及び冷水ループ２１６は、加熱されたかつ／又は冷やされた水を、建物１０の屋上に位置する空気ハンドラ（例えば、ＡＨＵ１０６）又は建物１０の個々のフロア若しくはゾーン（例えば、ＶＡＶユニット１１６）に送達し得る。空気ハンドラは、空気に加熱又は冷却を提供するために水が流れる熱交換器（例えば、加熱コイル又は冷却コイル）を通して、空気を押し出す。加熱又は冷却された空気は、建物１０の熱エネルギー負荷を供するように、建物１０の個々のゾーンに送達され得る。次いで、水は、サブプラント２０２～２１２に戻り、更なる加熱又は冷却を受ける。

サブプラント２０２～２１２は、建物への循環のための加熱及び冷却水として示され説明されているが、熱エネルギー負荷を供するために、水の代わりに、又は水に加えて、任意の他のタイプの作動流体（例えば、グリコール、ＣＯ２など）が使用されてよいことが理解されよう。他の実施形態では、サブプラント２０２～２１２は、中間熱伝達流体を必要とせずに、建物又は構内に直接加熱及び／又は冷却を提供し得る。ウォーターサイドシステム２００に対するこれら及び他の変形形態は、本発明の教示の範囲内である。

サブプラント２０２～２１２の各々は、サブプラントの機能を容易にするように構成された様々な設備を含み得る。例えば、ヒータサブプラント２０２は、温水ループ２１４内の温水に熱を加えるように構成された複数の加熱要素２２０（例えば、ボイラ、電気ヒータなど）を含むように示されている。ヒータサブプラント２０２はまた、温水ループ２１４内で温水を循環させ、個々の加熱要素２２０を通る温水の流量を制御するように構成されたいくつかのポンプ２２２及び２２４を含むようにも示されている。チラーサブプラント２０６は、冷水ループ２１６内の冷水から熱を除去するように構成された複数のチラー２３２を含むように示されている。チラーサブプラント２０６はまた、冷水ループ２１６内で冷水を循環させ、個々のチラー２３２を通る冷水の流量を制御するように構成されたいくつかのポンプ２３４及び２３６を含むようにも示されている。

熱回収チラーサブプラント２０４は、冷水ループ２１６から温水ループ２１４に熱を伝達するように構成された複数の熱回収熱交換器２２６（例えば、冷媒回路）を含むように示されている。熱回収チラーサブプラント２０４はまた、熱回収熱交換器２２６を通して温水及び／又は冷水を循環させ、個々の熱回収熱交換器２２６を通して水の流量を制御するように構成されたいくつかのポンプ２２８及び２３０を含むように示されている。冷却塔サブプラント２０８は、復水器水ループ２１８内の復水器水から熱を除去するように構成された複数の冷却塔２３８を含むように示されている。冷却塔サブプラント２０８はまた、復水器水ループ２１８内で復水器水を循環させ、個々の冷却塔２３８を通る復水器水の流量を制御するように構成されたいくつかのポンプ２４０を含むように示されている。

高温ＴＥＳサブプラント２１０は、後で使用するために温水を貯蔵するように構成された高温ＴＥＳタンク２４２を含むように示されている。高温ＴＥＳサブプラント２１０はまた、高温ＴＥＳタンク２４２への又は高温ＴＥＳタンク２４２からの温水の流量を制御するように構成された、１つ以上のポンプ又は１つ以上のバルブを含み得る。低温ＴＥＳサブプラント２１２は、後で使用するために冷水を貯蔵するように構成された低温ＴＥＳタンク２４４を含むように示されている。低温ＴＥＳサブプラント２１２はまた、低温ＴＥＳタンク２４４への又は低温ＴＥＳタンク２４４からの冷水の流量を制御するように構成された、１つ以上のポンプ又は１つ以上のバルブを含み得る。

いくつかの実施形態では、ウォーターサイドシステム２００内の１つ以上のポンプ（例えば、ポンプ２２２、２２４、２２８、２３０、２３４、２３６、及び／又は２４０）又はウォーターサイドシステム２００内のパイプラインは、それに関連付けられた絶縁バルブを含む。絶縁バルブは、ウォーターサイドシステム２００内の流体流れを制御するために、ポンプと一体化されていてもよく、又はポンプの上流若しくは下流に位置決めされていてもよい。様々な実施形態では、ウォーターサイドシステム２００は、ウォーターサイドシステム２００の特定の構成及びウォーターサイドシステム２００によって供される負荷のタイプに基づいて、より多くの、より少ない、又は異なるタイプのデバイス及び／又はサブプラントを含み得る。

ここで図３を参照すると、いくつかの実施形態によるエアサイドシステム３００のブロック図が示されている。様々な実施形態では、エアサイドシステム３００は、ＨＶＡＣシステム１００内のエアサイドシステム１３０を補完又は置き換えてもよく、又はＨＶＡＣシステム１００とは別個に実装されてもよい。ＨＶＡＣシステム１００に実装されるとき、エアサイドシステム３００は、ＨＶＡＣシステム１００内のＨＶＡＣデバイスのサブセット（例えば、ＡＨＵ１０６、ＶＡＶユニット１１６、ダクト１１２～１１４、ファン、ダンパなど）を含んでよく、建物１０内又はその周囲に位置していてよい。エアサイドシステム３００は、ウォーターサイドシステム２００によって提供される加熱された又は冷やされた流体を使用して、建物１０に提供される空気流を加熱又は冷却するように動作し得る。

図３では、エアサイドシステム３００は、エコノマイザ型空気処理ユニット（ＡＨＵ）３０２を含むように示されている。エコノマイザ型ＡＨＵは、加熱又は冷却のために空気処理ユニットによって使用される、外気及び戻り空気の量を変化させる。例えば、ＡＨＵ３０２は、戻り空気ダクト３０８を介して建物ゾーン３０６から戻り空気３０４を受け取り得、供給空気ダクト３１２を介して供給空気３１０を建物ゾーン３０６に送達し得る。いくつかの実施形態では、ＡＨＵ３０２は、建物１０の屋上に位置するか（例えば、図１に示されるようなＡＨＵ１０６）、さもなければ戻り空気３０４及び外気３１４の両方を受け取るように位置決めされた屋上ユニットである。ＡＨＵ３０２は、排気ダンパ３１６と混合ダンパ３１８と外気ダンパ３２０とを操作して、供給空気３１０を形成するように結合する、外気３１４及び戻り空気３０４の量を制御するように構成され得る。混合ダンパ３１８を通過しない任意の戻り空気３０４は、排気３２２として排気ダンパ３１６を通ってＡＨＵ３０２から排気され得る。

ダンパ３１６～３２０の各々は、アクチュエータによって操作され得る。例えば、排気ダンパ３１６は、アクチュエータ３２４によって操作され得、混合ダンパ３１８は、アクチュエータ３２６によって操作され得、外気ダンパ３２０は、アクチュエータ３２８によって操作され得る。アクチュエータ３２４～３２８は、通信リンク３３２を介してＡＨＵコントローラ３３０と通信し得る。アクチュエータ３２４～３２８は、ＡＨＵコントローラ３３０から制御信号を受信し得、フィードバック信号をＡＨＵコントローラ３３０に提供し得る。フィードバック信号は、例えば、現在のアクチュエータ若しくはダンパ位置の指標、アクチュエータによって加えられるトルク若しくは力の量、診断情報（例えば、アクチュエータ３２４～３２８によって実施される診断試験の結果）、ステータス情報、試運転情報、構成設定、較正データ、及び／又はアクチュエータ３２４～３２８によって収集、記憶、若しくは使用され得る他のタイプの情報若しくはデータを含み得る。ＡＨＵコントローラ３３０は、アクチュエータ３２４～３２８を制御するために１つ以上の制御アルゴリズム（例えば、状態ベースのアルゴリズム、極値探索制御（ＥＳＣ）アルゴリズム、比例積分（ＰＩ）制御アルゴリズム、比例積分微分（ＰＩＤ）制御アルゴリズム、モデル予測制御（ＭＰＣ）アルゴリズム、フィードバック制御アルゴリズムなど）を使用するように構成されたエコノマイザコントローラであり得る。

更に図３を参照すると、ＡＨＵ３０２は、供給空気ダクト３１２内に位置決めされた、冷却コイル３３４、加熱コイル３３６、及びファン３３８を含むように示されている。ファン３３８は、供給空気３１０を冷却コイル３３４及び／又は加熱コイル３３６に強制的に通し、供給空気３１０を建物ゾーン３０６に提供するように構成され得る。ＡＨＵコントローラ３３０は、通信リンク３４０を介してファン３３８と通信して、供給空気３１０の流量を制御し得る。いくつかの実施形態では、ＡＨＵコントローラ３３０は、ファン３３８の速度を調節することによって、供給空気３１０に適用される加熱又は冷却の量を制御する。

冷却コイル３３４は、配管３４２を介して、ウォーターサイドシステム２００から（例えば、冷水ループ２１６から）冷やされた流体を受け取り得、冷やされた流体を、配管３４４を介してウォーターサイドシステム２００に戻し得る。バルブ３４６は、配管３４２又は配管３４４に沿って位置決めされて、冷却コイル３３４を通る冷やされた流体の流量を制御し得る。いくつかの実施形態では、冷却コイル３３４は、供給空気３１０に適用される冷却量を調節するために、（例えば、ＡＨＵコントローラ３３０、ＢＭＳコントローラ３６６などによって）独立して作動及び作動解除され得る冷却コイルの複数の段階を含む。

加熱コイル３３６は、配管３４８を介して、ウォーターサイドシステム２００から（例えば、温水ループ２１４から）加熱された流体を受け取り得、加熱された流体を、配管３５０を介してウォーターサイドシステム２００に戻し得る。バルブ３５２は、配管３４８又は配管３５０に沿って位置決めされて、加熱コイル３３６を通る加熱された流体の流量を制御し得る。いくつかの実施形態では、加熱コイル３３６は、供給空気３１０に適用される加熱量を調節するために、（例えば、ＡＨＵコントローラ３３０、ＢＭＳコントローラ３６６などによって）独立して作動及び作動解除され得る加熱コイルの複数の段階を含む。

バルブ３４６及び３５２の各々は、アクチュエータによって制御され得る。例えば、バルブ３４６は、アクチュエータ３５４によって制御され得、バルブ３５２は、アクチュエータ３５６によって制御され得る。アクチュエータ３５４～３５６は、通信リンク３５８～３６０を介してＡＨＵコントローラ３３０と通信し得る。アクチュエータ３５４～３５６は、ＡＨＵコントローラ３３０から制御信号を受信し得、フィードバック信号をコントローラ３３０に提供し得る。いくつかの実施形態では、ＡＨＵコントローラ３３０は、供給空気ダクト３１２内（例えば、冷却コイル３３４及び／又は加熱コイル３３６の下流）に位置決めされた温度センサ３６２から、供給空気温度の測定値を受信する。ＡＨＵコントローラ３３０はまた、建物ゾーン３０６に位置する温度センサ３６４から建物ゾーン３０６の温度の測定値を受信してもよい。

いくつかの実施形態では、ＡＨＵコントローラ３３０は、アクチュエータ３５４～３５６を介してバルブ３４６及び３５２を動作させて、供給空気３１０に提供される加熱又は冷却の量を調節する（例えば、供給空気３１０の設定値温度を達成する、又は供給空気３１０の温度を設定値温度範囲内に維持する）。バルブ３４６及び３５２の位置は、冷却コイル３３４又は加熱コイル３３６によって供給空気３１０に提供される加熱又は冷却の量に影響を及ぼし、所望の供給空気温度を達成するために消費されるエネルギー量と相関し得る。ＡＨＵコントローラ３３０は、コイル３３４～３３６を作動又は作動解除すること、ファン３３８の速度を調整すること、又はその両方の組み合わせによって、供給空気３１０及び／又は建物ゾーン３０６の温度を制御し得る。

更に図３を参照すると、エアサイドシステム３００は、建物自動化システム（ＢＭＳ）コントローラ３６６及びクライアントデバイス３６８を含むように示されている。ＢＭＳコントローラ３６６は、システムレベルコントローラ、アプリケーション若しくはデータサーバ、ヘッドノード、又はエアサイドシステム３００、ウォーターサイドシステム２００、ＨＶＡＣシステム１００、及び／若しくは建物１０にサービスを提供する他の制御可能なシステムのためのマスタコントローラとして機能する１つ以上のコンピュータシステム（例えば、サーバ、監督コントローラ、サブシステムコントローラなど）を含み得る。ＢＭＳコントローラ３６６は、同様又は異なるプロトコル（例えば、ＬＯＮ、ＢＡＣｎｅｔ（登録商標）など）に従って、通信リンク３７０を介して、複数のダウンストリーム建物システム又はサブシステム（例えば、ＨＶＡＣシステム１００、セキュリティシステム、照明システム、ウォーターサイドシステム２００など）と通信し得る。様々な実施形態では、ＡＨＵコントローラ３３０とＢＭＳコントローラ３６６とは、（図３に示されるように）分離されていてもよく、又は統合されていてもよい。統合された実装形態では、ＡＨＵコントローラ３３０は、ＢＭＳコントローラ３６６のプロセッサによって実行されるように構成されたソフトウェアモジュールであってよい。

いくつかの実施形態では、ＡＨＵコントローラ３３０は、ＢＭＳコントローラ３６６から情報（例えば、コマンド、設定値、動作境界など）を受信し、ＢＭＳコントローラ３６６に情報（例えば、温度測定値、バルブ又はアクチュエータの位置、動作ステータス、診断など）を提供する。例えば、ＡＨＵコントローラ３３０は、ＢＭＳコントローラ３６６に、温度センサ３６２～３６４からの温度測定値、設備のオン／オフ状態、設備の動作能力、及び／又は建物ゾーン３０６内の可変状態又は条件を監視若しくは制御するためにＢＭＳコントローラ３６６によって使用することができる任意の他の情報を提供し得る。

クライアントデバイス３６８は、ＨＶＡＣシステム１００、そのサブシステム、及び／又はデバイスを制御、視認、又は別様にそれらと対話するための１つ以上のヒューマンマシンインターフェース若しくはクライアントインターフェース（例えば、グラフィカルユーザインターフェース、報告インターフェース、テキストベースのコンピュータインターフェース、クライアントフェイシングウェブサービス、ウェブクライアントにページを提供するウェブサーバなど）を含み得る。クライアントデバイス３６８は、コンピュータワークステーション、クライアント端末、リモート若しくはローカルインターフェース、又は任意の他のタイプのユーザインターフェースデバイスであり得る。クライアントデバイス３６８は、固定型端末又はモバイルデバイスであり得る。例えば、クライアントデバイス３６８は、デスクトップコンピュータ、ユーザインターフェースを有するコンピュータサーバ、ラップトップコンピュータ、タブレット、スマートフォン、ＰＤＡ、又は任意の他のタイプのモバイルデバイス若しくは非モバイルデバイスであり得る。クライアントデバイス３６８は、通信リンク３７２を介してＢＭＳコントローラ３６６及び／又はＡＨＵコントローラ３３０と通信し得る。

ここで図４を参照すると、いくつかの実施形態による建物自動化システム（ＢＭＳ）４００のブロック図が示されている。ＢＭＳ４００は建物１０内に実装されて、様々な建物機能を自動的に監視及び制御し得る。ＢＭＳ４００は、ＢＭＳコントローラ３６６及び複数の建物サブシステム４２８を含むように示されている。建物サブシステム４２８は、建物電気サブシステム４３４、情報通信技術（ＩＣＴ）サブシステム４３６、セキュリティサブシステム４３８、ＨＶＡＣサブシステム４４０、照明サブシステム４４２、エレベータ／エスカレータサブシステム４３２、及び火災安全サブシステム４３０を含むように示されている。様々な実施形態では、建物サブシステム４２８は、より少ない、追加の、又は代替のサブシステムを含むことができる。例えば、建物サブシステム４２８はまた、又は代替的に、冷媒サブシステム、広告若しくは標識サブシステム、調理サブシステム、販売サブシステム、プリンタ若しくはコピーサービスサブシステム、又は建物１０を監視若しくは制御するために制御可能な設備及び／若しくはセンサを使用する任意の他のタイプの建物サブシステムを含み得る。いくつかの実施形態では、建物サブシステム４２８は、図２及び図３を参照して説明されるように、ウォーターサイドシステム２００及び／又はエアサイドシステム３００を含む。

建物サブシステム４２８の各々は、その個々の機能及び制御活動を完了するための任意の数のデバイス、コントローラ、及び接続部を含み得る。ＨＶＡＣサブシステム４４０は、図１～図３を参照して説明されるように、ＨＶＡＣシステム１００と同じ構成要素の多くを含み得る。例えば、ＨＶＡＣサブシステム４４０は、チラー、ボイラ、任意の数の空気処理ユニット、エコノマイザ、フィールドコントローラ、監督コントローラ、アクチュエータ、温度センサ、及び建物１０内の温度、湿度、空気流、若しくは他の可変条件を制御するための他のデバイスを含み得る。照明サブシステム４４２は、建物空間に提供される光の量を制御可能に調整するように構成された、任意の数の照明器具、バラスト、照明センサ、調光器、又は他のデバイスを含み得る。セキュリティサブシステム４３８は、占有センサ、ビデオ監視カメラ、デジタルビデオレコーダ、ビデオ処理サーバ、侵入検知デバイス、アクセス制御デバイス及びサーバ、又は他のセキュリティ関連デバイスを含み得る。

更に図４を参照すると、ＢＭＳコントローラ３６６は、通信インターフェース４０７及びＢＭＳインターフェース４０９を含むように示されている。インターフェース４０７は、ＢＭＳコントローラ３６６と外部アプリケーション（例えば、監視及び報告アプリケーション４２２、企業制御アプリケーション４２６、リモートシステム及びアプリケーション４４４、クライアントデバイス４４８上に常駐するアプリケーションなど）との間の通信を容易にして、ＢＭＳコントローラ３６６及び／又はサブシステム４２８に対するユーザ制御、監視、及び調整を可能にし得る。また、インターフェース４０７は、ＢＭＳコントローラ３６６とクライアントデバイス４４８との間の通信も容易にし得る。ＢＭＳインターフェース４０９は、ＢＭＳコントローラ３６６と建物サブシステム４２８（例えば、ＨＶＡＣ、照明セキュリティ、エレベータ、配電、ビジネスなど）との間の通信を容易にし得る。

インターフェース４０７、４０９は、建物サブシステム４２８又は他の外部システム若しくはデバイスとデータ通信を行うための有線又は無線通信インターフェース（例えば、ジャック、アンテナ、送信機、受信機、送受信機、有線端末など）であるか、又はそれらを含むことができる。様々な実施形態では、インターフェース４０７、４０９を介した通信は、直接的（例えば、ローカル有線通信又は無線通信）であっても、通信ネットワーク４４６（例えば、ＷＡＮ、インターネット、セルラネットワークなど）を介してもよい。例えば、インターフェース４０７、４０９は、イーサネット（登録商標）ベースの通信リンク又はネットワークを介してデータを送信及び受信するためのイーサネットカード及びポートを含むことができる。別の例では、インターフェース４０７、４０９は、無線通信ネットワークを介して通信するためのＷｉＦｉ送受信機を含むことができる。別の例では、インターフェース４０７、４０９のうちの一方又は両方は、セルラ又は携帯電話通信送受信機を含み得る。一実施形態では、通信インターフェース４０７は、電力線通信インターフェースであり、ＢＭＳインターフェース４０９は、イーサネットインターフェースである。他の実施形態では、通信インターフェース４０７及びＢＭＳインターフェース４０９は両方とも、イーサネットインターフェースであるか又は同じイーサネットインターフェースである。

更に図４を参照すると、ＢＭＳコントローラ３６６は、プロセッサ４０６とメモリ４０８とを含む処理回路４０４を含むように示されている。処理回路４０４は、処理回路４０４及びその様々な構成要素が、インターフェース４０７、４０９を介してデータを送信及び受信することができるように、ＢＭＳインターフェース４０９及び／又は通信インターフェース４０７に通信可能に接続され得る。プロセッサ４０６は、汎用プロセッサ、特定用途向け集積回路（ＡＳＩＣ）、１つ以上のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）、処理構成要素のグループ、又は他の好適な電子処理構成要素として実装され得る。

メモリ４０８（例えば、メモリ、メモリユニット、記憶デバイスなど）は、本出願に記載された様々なプロセス、層、及びモジュールを完了又は促進するためのデータ及び／又はコンピュータコードを記憶するための、１つ以上のデバイス（例えば、ＲＡＭ、ＲＯＭ、フラッシュメモリ、ハードディスク記憶装置など）を含み得る。メモリ４０８は、揮発性メモリ又は不揮発性メモリであり得るか、又はそれを含み得る。メモリ４０８は、データベース構成要素、オブジェクトコード構成要素、スクリプト構成要素、又は本出願に記載された様々な活動及び情報構造をサポートするための任意の他のタイプの情報構造を含み得る。一実施形態によれば、メモリ４０８は、処理回路４０４を介してプロセッサ４０６に通信可能に接続され、本明細書に記載された１つ以上のプロセスを（例えば、処理回路４０４及び／又はプロセッサ４０６によって）実行するためのコンピュータコードを含む。

いくつかの実施形態では、ＢＭＳコントローラ３６６は、単一のコンピュータ内（例えば、１つのサーバ内、１つの筐体内など）に実装される。様々な他の実施形態では、ＢＭＳコントローラ３６６は、（例えば、分散された場所に存在することができる）複数のサーバ又はコンピュータにわたって分散され得る。更に、図４は、アプリケーション４２２及び４２６を、ＢＭＳコントローラ３６６の外側に存在するものとして示しているが、いくつかの実施形態では、アプリケーション４２２及び４２６は、ＢＭＳコントローラ３６６内（例えば、メモリ４０８内）でホストされてよい。

更に図４を参照すると、メモリ４０８は、企業統合層４１０、自動測定及び検証（ＡＭ＆Ｖ）層４１２、需要応答（ＤＲ）層４１４、故障検出及び診断（ＦＤＤ）層４１６、統合制御層４１８、及び後の建物サブシステム統合４２０を含むように示されている。層４１０～４２０は、建物サブシステム４２８及び他のデータソースから入力を受信し、入力に基づいて建物サブシステム４２８のための最適制御アクションを判定し、最適制御アクションに基づいて制御信号を生成し、生成された制御信号を建物サブシステム４２８に提供するように構成され得る。以下の段落では、ＢＭＳ４００内の層４１０～４２０の各々によって実施される一般的な機能のいくつかを記載する。

企業統合層４１０は、クライアント又はローカルアプリケーションに、様々な企業レベルのアプリケーションをサポートするための情報及びサービスを供するように構成され得る。例えば、企業制御アプリケーション４２６は、グラフィカルユーザインターフェース（ＧＵＩ）又は任意の数の企業レベルのビジネスアプリケーション（例えば、会計システム、ユーザ識別システムなど）にサブシステムスパニング制御を提供するように構成され得る。企業制御アプリケーション４２６はまた、又は代替的に、ＢＭＳコントローラ３６６を構成するための構成ＧＵＩを提供するように構成され得る。更になお他の実施形態では、企業制御アプリケーション４２６は、インターフェース４０７及び／又はＢＭＳインターフェース４０９で受信された入力に基づいて、建物の性能（例えば、効率性、エネルギー使用、快適性、又は安全性）を最適化するために層４１０～４２０と連携することができる。

建物サブシステム統合層４２０は、ＢＭＳコントローラ３６６と建物サブシステム４２８との間の通信を管理するように構成され得る。例えば、建物サブシステム統合層４２０は、センサデータ及び入力信号を建物サブシステム４２８から受信し、出力データ及び制御信号を建物サブシステム４２８に提供し得る。建物サブシステム統合層４２０はまた、建物サブシステム４２８間の通信を管理するように構成され得る。建物サブシステム統合層４２０は、複数のマルチベンダ／マルチプロトコルシステムにわたって通信（例えば、センサデータ、入力信号、出力信号など）を変換する。

需要応答層４１４は、建物１０の需要を満たすことに応答して、資源使用（例えば、電気使用、天然ガス使用、水使用など）及び／又はそのような資源使用の金銭的コストを最適化するように構成され得る。最適化は、使用時間価格、抑制信号、エネルギー利用可用性、又は公益事業者、分散型エネルギー生成システム４２４、エネルギー貯蔵装置４２７（例えば、高温ＴＥＳ２４２、低温ＴＥＳ２４４など）から、若しくは他のソースから受信された他のデータに基づいていてよい。需要応答層４１４は、ＢＭＳコントローラ３６６の他の層（例えば、建物サブシステム統合層４２０、統合制御層４１８など）から入力を受信し得る。他の層から受信した入力は、温度、二酸化炭素レベル、相対湿度レベル、空気品質センサ出力、占有センサ出力、部屋スケジュールなどの環境入力又はセンサ入力を含み得る。入力はまた、電力使用量（例えば、ｋＷｈで表される）、熱負荷測定値、価格情報、予測される価格設定、平滑化された価格設定、公益事業者からの抑制信号などの入力を含み得る。

例示的な実施形態によれば、需要応答層４１４は、それが受信するデータ及び信号に応答するための制御ロジックを含む。これらの応答は、統合された制御層４１８内の制御アルゴリズムと通信すること、制御戦略を変更すること、設定値を変更すること、又は制御された様式で建物の設備若しくはサブシステムを作動／作動解除することを含むことができる。需要応答層４１４はまた、貯蔵されたエネルギーをいつ利用するかを判定するように構成された制御ロジックも含み得る。例えば、需要応答層４１４は、ピーク使用時間の開始直前に、エネルギー貯蔵装置４２７からのエネルギーの使用を開始することを判定し得る。

いくつかの実施形態では、需要応答層４１４は、需要を表す、又は需要に基づいた１つ以上の入力（例えば、価格、抑制信号、需要レベルなど）に基づいてエネルギーコストを最小化する制御アクションをアクティブに開始する（例えば、自動的に設定値を変更する）ように構成された制御モジュールを含む。いくつかの実施形態では、需要応答層４１４は、設備モデルを使用して、制御アクションの最適なセットを判定する。設備モデルは、例えば、建物設備の様々なセットによって実施される入力、出力、及び／又は機能を説明する熱力学モデルを含み得る。設備モデルは、建物設備（例えば、サブプラント、チラーアレイなど）又は個々のデバイス（例えば、個々のチラー、ヒータ、ポンプなど）のコレクションを表し得る。

需要応答層４１４は、１つ以上の需要応答ポリシー定義（例えば、データベース、ＸＭＬファイルなど）を更に含んでもよく、又はそれを利用してもよい。ポリシー定義は、需要入力に応答して開始された制御アクションが、ユーザのアプリケーション、所望の快適性レベル、特定の建物設備に合わせて、又は他の懸念事項に基づいて調節され得るように、ユーザによって（例えば、グラフィカルユーザインターフェースを介して）編集又は調整され得る。例えば、需要応答ポリシー定義は、特定の需要入力に応答してどの設備をオン又はオフにし得るか、システム又は設備の一部をどのくらいの時間オフにすべきか、どのような設定値を変更できるか、許容設定値調整範囲は何であるか、通常スケジュールされた設定値に戻る前にどのくらいの時間高い需要設定値を保持するか、容量制限にどのくらい近づいているか、どの設備モードを利用するか、エネルギー貯蔵デバイス（例えば、熱貯蔵タンク、バッテリバンクなど）への、及びエネルギー貯蔵デバイス（例えば、熱貯蔵タンク、バッテリバンクなど）からのエネルギー転送速度（例えば、最大速度、警報速度、他の速度境界情報など）、並びにオンサイトのエネルギー生成をいつ（例えば、燃料電池、モータ発電機セットなどを介して）ディスパッチするかを指定することができる。

統合制御層４１８は、建物サブシステム統合層４２０のデータ入力若しくは出力、及び／又は後の需要応答４１４を使用して、制御判定を行うように構成され得る。建物サブシステム統合層４２０によって提供されるサブシステム統合により、統合制御層４１８は、サブシステム４２８が単一の統合スーパーシステムとして振る舞うように、サブシステム４２８の制御活動を統合することができる。例示的な一実施形態では、統合制御層４１８は、複数の建物サブシステムからの入力及び出力を使用して、別個のサブシステムが単独で提供することができる快適性及び省エネルギーと比較して、より大きな快適性及び省エネルギーを提供する制御ロジックを含む。例えば、統合制御層４１８は、第１のサブシステムからの入力を使用して、第２のサブシステムの省エネ制御判定を行うように構成され得る。これらの判定の結果は、建物サブシステム統合層４２０に送り返すことができる。

統合制御層４１８は、論理的に需要応答層４１４の下にあるように示されている。統合制御層４１８は、建物サブシステム４２８及びそれらのそれぞれの制御ループが需要応答層４１４と協調して制御されることを可能にすることによって、需要応答層４１４の有効性を高めるように構成され得る。この構成は、従来のシステムと比較して、破壊的な需要応答挙動を有利に低減し得る。例えば、統合制御層４１８は、冷却水温度（又は温度に直接的若しくは間接的に影響を与える別の構成要素）の設定値に対する需要応答駆動の上方調整が、チラーで節約されたよりも大きな総建物エネルギー使用量をもたらすであろうファンエネルギー（又は空間を冷却するために使用される他のエネルギー）の増加をもたらさないことを保証するように構成され得る。

統合制御層４１８は、要求された負荷の除去が進行中であっても、制約（例えば、温度、照明レベルなど）が適切に維持されることを需要応答層４１４がチェックするように、需要応答層４１４にフィードバックを提供するように構成され得る。制約はまた、安全性、設備動作制限及び性能、快適性、消防コード、電気コード、エネルギーコードなどに関連する設定値又は感知された境界を含み得る。統合制御層４１８はまた、論理的に、故障検出及び診断層４１６並びに自動測定及び検証層４１２の下にある。統合制御層４１８は、２つ以上の建物サブシステムからの出力に基づいて、これらのより高いレベルに計算された入力（例えば、集計）を提供するように構成され得る。

自動測定及び検証（ＡＭ＆Ｖ）層４１２は、統合制御層４１８又は需要応答層４１４にコマンドを受けた制御戦略が適切に機能していることを検証するように構成され得る（例えば、ＡＭ＆Ｖ層４１２、統合制御層４１８、建物サブシステム統合層４２０、ＦＤＤ層４１６によって集約されたデータ又はその他を使用して）。ＡＭ＆Ｖ層４１２によって行われる計算は、個々のＢＭＳデバイス又はサブシステムのための建物システムエネルギーモデル及び／又は設備モデルに基づき得る。例えば、ＡＭ＆Ｖ層４１２は、モデル予測出力を建物サブシステム４２８からの実際の出力と比較して、モデルの精度を判定し得る。

故障検出及び診断（ＦＤＤ）層４１６は、建物サブシステム４２８、建物サブシステムデバイス（すなわち、建物設備）、並びに需要応答層４１４及び統合制御層４１８によって使用される制御アルゴリズムに対して継続的な故障検出を提供するように構成され得る。ＦＤＤ層４１６は、統合制御層４１８から、１つ以上の建物サブシステム若しくはデバイスから直接、又は別のデータソースからデータ入力を受信し得る。ＦＤＤ層４１６は、検出された故障を自動的に診断し、それに応答し得る。検出又は診断された故障への応答には、警告メッセージを、ユーザ、保守点検スケジューリングシステム、又は故障を修復することを試みるか若しくは故障を回避するように構成された制御アルゴリズムに提供することが含まれ得る。

ＦＤＤ層４１６は、建物サブシステム統合層４２０で利用可能な詳細なサブシステム入力を使用して、故障した構成要素又は故障の原因（例えば、ダンパリンケージの緩み）の特定の識別情報を出力するように構成され得る。他の例示的な実施形態では、ＦＤＤ層４１６は、「故障」イベントを、受信した故障イベントに応答して制御戦略及びポリシーを実行する統合制御層４１８に提供するように構成される。例示的な実施形態によれば、ＦＤＤ層４１６（又は統合制御エンジン又はビジネスルールエンジンによって実行されるポリシー）は、システムをシャットダウンしてもよく、又は故障したデバイス若しくはシステムの周囲の制御アクティビティを指示して、エネルギーの浪費を低減してもよく、設備の寿命を延ばしてもよく、又は適切な制御応答を保証してもよい。

ＦＤＤ層４１６は、様々な異なるシステムデータストア（又はライブデータのためのデータ点）を記憶するか又はそれにアクセスするように構成され得る。ＦＤＤ層４１６は、データストアの何らかのコンテンツを使用して、設備レベルでの故障（例えば、特定のチラー、特定のＡＨＵ、特定の端末ユニットなど）及び他のコンテンツを識別して、構成要素又はサブシステムレベルでの故障を識別し得る。例えば、建物サブシステム４２８は、ＢＭＳ４００及びその様々な構成要素の性能を示す時間的（すなわち、時系列）データを生成し得る。建物サブシステム４２８によって生成されたデータは測定又は計算された値を含み得、測定又は計算された値は、統計的特性を示し、対応するシステム又はプロセス（例えば、温度制御プロセス、流量制御プロセスなど）がその設定値からの誤差に関してどのように実施しているかに関する情報を提供する。これらのプロセスはＦＤＤ層４１６によって検査されて、システムの性能の劣化が始まったときに公開され、故障がより深刻になる前に故障を修復するようにユーザに警告することができる。

ここで図５を参照すると、いくつかの実施形態による、別の建物管理システム（ＢＭＳ）５００のブロック図が示されている。ＢＭＳ５００は、ＨＶＡＣシステム１００、ウォーターサイドシステム２００、エアサイドシステム３００、建物サブシステム４２８、並びに他のタイプのＢＭＳデバイス（例えば、照明設備、セキュリティ設備など）及び／又はＨＶＡＣ設備のデバイスを監視及び制御するために使用することができる。

ＢＭＳ５００は、自動設備発見及び設備モデル分配を容易にするシステムアーキテクチャを提供する。設備発見は、複数の異なる通信バス（例えば、システムバス５５４、ゾーンバス５５６～５６０及び５６４、センサ／アクチュエータバス５６６など）にわたって、及び複数の異なる通信プロトコルにわたって、ＢＭＳ５００の複数のレベルで生じ得る。いくつかの実施形態では、設備発見は、各通信バスに接続されたデバイスのステータス情報を提供するアクティブノードテーブルを使用して達成される。例えば、各通信バスは、新たなノードについての対応するアクティブノードテーブルを監視することによって、新たなデバイスについて監視されることができる。新たなデバイスが検出されると、ＢＭＳ５００は、ユーザインタラクションなしで、新たなデバイスとのインタラクションを開始することができる（例えば、デバイスからのデータを使用して、制御信号を送信する）。

ＢＭＳ５００内のいくつかのデバイスは、設備モデルを使用してネットワークにそれら自身を提示する。設備モデルは、他のシステムとの統合に使用される設備オブジェクト属性、ビュー定義、スケジュール、トレンド、及び関連するＢＡＣｎｅｔ値オブジェクト（例えば、アナログ値、バイナリ値、マルチステート値など）を定義する。ＢＭＳ５００内のいくつかのデバイスは、独自の設備モデルを記憶する。ＢＭＳ５００内の他のデバイスは、外部に（例えば、他のデバイス内に）記憶された設備モデルを有する。例えば、ゾーンコーディネータ５０８は、バイパスダンパ５２８のための設備モデルを記憶することができる。いくつかの実施形態では、ゾーンコーディネータ５０８は、ゾーンバス５５８上のバイパスダンパ５２８又は他のデバイスのための設備モデルを自動的に作成する。他のゾーンコーディネータは、ゾーンバスに接続されたデバイスの設備モデルを作成することもできる。デバイスの設備モデルは、デバイスによってゾーンバス上で公開されるデータ点のタイプ、デバイスタイプ、及び／又は他のデバイス属性に基づいて自動的に作成されることができる。自動設備発見及び設備モデル分配のいくつかの例は、以下でより詳細に考察される。

更に図５を参照すると、ＢＭＳ５００は、システムマネージャ５０２、いくつかのゾーンコーディネータ５０６、５０８、５１０、及び５１８、並びにいくつかのゾーンコントローラ５２４、５３０、５３２、５３６、５４８、及び５５０を含むように示されている。システムマネージャ５０２は、ＢＭＳ５００内のデータ点を監視し、監視された変数を様々な監視アプリケーション及び／又は制御アプリケーションに報告することができる。システムマネージャ５０２は、データ通信リンク５７４（例えば、ＢＡＣｎｅｔ ＩＰ、イーサネット、有線又は無線通信など）を介して、クライアントデバイス５０４（例えば、ユーザデバイス、デスクトップコンピュータ、ラップトップコンピュータ、モバイルデバイスなど）と通信することができる。システムマネージャ５０２は、データ通信リンク５７４を介してクライアントデバイス５０４にユーザインターフェースを提供することができる。ユーザインターフェースは、ユーザがクライアントデバイス５０４を介してＢＭＳ５００を監視及び／又は制御することを可能にし得る。

いくつかの実施形態では、システムマネージャ５０２は、システムバス５５４を介してゾーンコーディネータ５０６～５１０及び５１８と接続される。システムマネージャ５０２は、マスタスレーブトークンパッシング（ＭＳＴＰ）プロトコル又は任意の他の通信プロトコルを使用して、システムバス５５４を介してゾーンコーディネータ５０６～５１０及び５１８と通信するように構成することができる。システムバス５５４はまた、システムマネージャ５０２を、定容積（ＣＶ）屋上ユニット（ＲＴＵ）５１２、入出力モジュール（ＩＯＭ）５１４、サーモスタットコントローラ５１６（例えば、ＴＥＣ５０００シリーズサーモスタットコントローラ）、及びネットワーク自動化エンジン（ＮＡＥ）又はサードパーティコントローラ５２０などの他のデバイスと接続することができる。ＲＴＵ５１２は、システムマネージャ５０２と直接通信するように構成することができ、システムバス５５４に直接接続することができる。他のＲＴＵは、中間デバイスを介してシステムマネージャ５０２と通信することができる。例えば、有線入力５６２は、サードパーティＲＴＵ５４２を、システムバス５５４に接続するサーモスタットコントローラ５１６に接続することができる。

システムマネージャ５０２は、設備モデルを含む任意のデバイスに対してユーザインターフェースを提供することができる。ゾーンコーディネータ５０６～５１０及び５１８並びにサーモスタットコントローラ５１６などのデバイスは、システムバス５５４を介してそれらの設備モデルをシステムマネージャ５０２に提供することができる。いくつかの実施形態では、システムマネージャ５０２は、設備モデル（例えば、ＩＯＭ５１４、サードパーティコントローラ５２０など）を含まない接続されたデバイスのための設備モデルを自動的に作成する。例えば、システムマネージャ５０２は、デバイスツリー要求に応答する任意のデバイスのための設備モデルを作成することができる。システムマネージャ５０２によって作成された設備モデルは、システムマネージャ５０２内に記憶することができる。次いで、システムマネージャ５０２は、システムマネージャ５０２によって作成された設備モデルを使用して、それら自身の設備モデルを含まないデバイスのためのユーザインターフェースを提供することができる。いくつかの実施形態では、システムマネージャ５０２は、システムバス５５４を介して接続された各タイプの設備についてのビュー定義を記憶し、記憶されたビュー定義を使用して、設備についてのユーザインターフェースを生成する。

各ゾーンコーディネータ５０６～５１０及び５１８は、ゾーンバス５５６、５５８、５６０、及び５６４を介して、ゾーンコントローラ５２４、５３０～５３２、５３６、及び５４８～５５０のうちの１つ以上と接続することができる。ゾーンコーディネータ５０６～５１０及び５１８は、ＭＳＴＰプロトコル又は任意の他の通信プロトコルを使用して、ゾーンバス５５６～５６０及び５６４を介してゾーンコントローラ５２４、５３０～５３２、５３６、及び５４８～５５０と通信することができる。ゾーンバス５５６～５６０及び５６４はまた、ゾーンコーディネータ５０６～５１０及び５１８を、可変風量（ＶＡＶ）ＲＴＵ５２２及び５４０、切り替えバイパス（ＣＯＢＰ）ＲＴＵ５２６及び５５２、バイパスダンパ５２８及び５４６、並びにＰＥＡＫコントローラ５３４及び５４４などの他のタイプのデバイスと接続することができる。

ゾーンコーディネータ５０６～５１０及び５１８は、様々なゾーン分割システムを監視しかつこれらにコマンドを出すように構成することができる。いくつかの実施形態では、各ゾーンコーディネータ５０６～５１０及び５１８は、別個のゾーン分割システムを監視しかつこれらにコマンドを出し、別個のゾーンバスを介してゾーン分割システムに接続される。例えば、ゾーンコーディネータ５０６は、ゾーンバス５５６を介してＶＡＶ ＲＴＵ５２２及びゾーンコントローラ５２４に接続することができる。ゾーンコーディネータ５０８は、ゾーンバス５５８を介してＣＯＢＰ ＲＴＵ５２６、バイパスダンパ５２８、ＣＯＢＰゾーンコントローラ５３０、及びＶＡＶゾーンコントローラ５３２に接続することができる。ゾーンコーディネータ５１０は、ゾーンバス５６０を介してＰＥＡＫコントローラ５３４及びＶＡＶゾーンコントローラ５３６に接続することができる。ゾーンコーディネータ５１８は、ゾーンバス５６４を介して、ＰＥＡＫコントローラ５４４、バイパスダンパ５４６、ＣＯＢＰゾーンコントローラ５４８、及びＶＡＶゾーンコントローラ５５０に接続することができる。

ゾーンコーディネータ５０６～５１０及び５１８の単一のモデルは、複数の異なるタイプのゾーン分割システム（例えば、ＶＡＶゾーン分割システム、ＣＯＢＰゾーン分割システムなど）を処理するように構成することができる。各ゾーン分割システムは、ＲＴＵ、１つ以上のゾーンコントローラ、及び／又はバイパスダンパを含むことができる。例えば、ゾーンコーディネータ５０６及び５１０は、それぞれＶＡＶ ＲＴＵ５２２及び５４０に接続されたＶｅｒａｓｙｓ ＶＡＶエンジン（ＶＶＥ）として示されている。ゾーンコーディネータ５０６は、ゾーンバス５５６を介してＶＡＶ ＲＴＵ５２２に直接接続され、一方、ゾーンコーディネータ５１０は、ＰＥＡＫコントローラ５３４に提供された有線入力５６８を介してサードパーティＶＡＶ ＲＴＵ５４０に接続される。ゾーンコーディネータ５０８及び５１８は、それぞれＣＯＢＰ ＲＴＵ５２６及び５５２に接続されたＶｅｒａｓｙｓ ＣＯＢＰエンジン（ＶＣＥ）として示されている。ゾーンコーディネータ５０８は、ゾーンバス５５８を介してＣＯＢＰ ＲＴＵ５２６に直接接続され、一方、ゾーンコーディネータ５１８は、ＰＥＡＫコントローラ５４４に提供された有線入力５７０を介してサードパーティＣＯＢＰ ＲＴＵ５５２に接続される。

ゾーンコントローラ５２４、５３０～５３２、５３６、及び５４８～５５０は、センサ／アクチュエータ（ＳＡ）バスを介して個々のＢＭＳデバイス（例えば、センサ、アクチュエータなど）と通信することができる。例えば、ＶＡＶゾーンコントローラ５３６は、ＳＡバス５６６を介してネットワーク化されたセンサ５３８に接続されるように示されている。ゾーンコントローラ５３６は、ＭＳＴＰプロトコル又は任意の他の通信プロトコルを使用して、ネットワーク化されたセンサ５３８と通信することができる。１つのＳＡバス５６６のみが図５に示されているが、各ゾーンコントローラ５２４、５３０～５３２、５３６、及び５４８～５５０は、異なるＳＡバスに接続することができることを理解されたい。各ＳＡバスは、ゾーンコントローラを、様々なセンサ（例えば、温度センサ、湿度センサ、圧力センサ、光センサ、占有センサなど）、アクチュエータ（例えば、ダンパアクチュエータ、バルブアクチュエータなど）、及び／又は他のタイプの制御可能な設備（例えば、チラー、ヒータ、ファン、ポンプなど）と接続することができる。

各ゾーンコントローラ５２４、５３０～５３２、５３６、及び５４８～５５０は、異なる建物ゾーンを監視及び制御するように構成することができる。ゾーンコントローラ５２４、５３０～５３２、５３６、及び５４８～５５０は、それらのＳＡバスを介して提供される入力及び出力を使用して、様々な建物ゾーンを監視及び制御することができる。例えば、ゾーンコントローラ５３６は、ＳＡバス５６６を介して、ネットワーク化されたセンサ５３８から受信された温度入力（例えば、建物ゾーンの測定された温度）を、温度制御アルゴリズムにおけるフィードバックとして使用することができる。ゾーンコントローラ５２４、５３０～５３２、５３６、及び５４８～５５０は、建物１０内又はその周囲の可変状態又は条件（例えば、温度、湿度、空気流、照明など）を制御するために、様々なタイプの制御アルゴリズム（例えば、状態ベースのアルゴリズム、極値探索制御（ＥＳＣ）アルゴリズム、比例積分（ＰＩ）制御アルゴリズム、比例積分微分（ＰＩＤ）制御アルゴリズム、モデル予測制御（ＭＰＣ）アルゴリズム、フィードバック制御アルゴリズムなど）を使用することができる。

故障検出及びエネルギー浪費
上記で簡単に議論されたように、ＢＭＳは、例えば運用コスト及びエネルギー使用量を低減すること、ダウンタイムを減少させること、占有者の快適性を向上することなどによって建物運用を最適化するために、建物設備（例えば、図１～図５に示される任意の建物設備）及び／又は建物サブシステム（例えば、建物サブシステム４２８）を監視及び／又は制御するように構成され得る。したがって、設備の保守点検は、建物運用を最適化する上で重要な要因となり得る。例えば、最適ではない状態で動作している設備は、他の建物設備よりも効率が低く、これにより、運用コストが高くなり、エネルギー使用量が増加する可能性がある。別の例では、他の構成要素への需要が建物要件（例えば、設定値）を満たすために増加するにつれて、操作不可能である設備は、ＢＭＳの他の構成要素に追加のストレスを引き起こし得る。

この点で、本明細書に記載されたシステムなどの故障検出システムは、設備及び／又はサブシステムの故障を有利に検出し得、その結果、検出された故障は、占有者の快適性を維持しながら、ダウンタイム及び浪費されるエネルギーを低減するために迅速に修復され得る。いくつかの実施形態では、故障検出システムは、検出された故障の優先度を判定するだけでなく、故障状態中のエネルギー浪費の量を判定し、浪費されたエネルギーに基づいて、故障のコストを判定し得るように構成されている。有利には、故障検出システムは、事前定義された優先度又は故障に関連付けられたコストのいずれかに基づいて、故障に優先順位を付け得る。例えば、はるかに大きなコストをもたらす故障は、より安価な他の故障よりも優先され得る。

ここで図６Ａ及び図６Ｂを参照すると、いくつかの実施形態による、建物設備を監視し、故障状態を検出するための故障検出システム６００のブロック図が示されている。上で考察されたように、システム６００は、設備の故障を検出するだけでなく、エネルギー浪費、排出（例えば、温室効果ガス排出、炭素排出、汚染物質など）、故障に関連するコストを判定することによって、かつ検出された故障を補正するための作業指図を生成するなどの自動化されたアクションを開始することによって、故障に応答し得るように構成され得る。様々な実施形態では、システム６００は、コンピュータ、サーバなどの単一のコンピューティングデバイスを介して、又は複数のコンピューティングデバイスを介して（例えば、分散型若しくはクラウドベースのサーバシステムを介して）実装される。そのようないくつかの実施形態では、システム６００を実装するコンピューティングデバイスは、上述した建物１０のＢＭＳなどのＢＭＳに含まれ得る。いくつかの実施形態では、システム６００は、ＢＭＳコントローラ３６６などのＢＭＳコントローラを介して実装される。例えば、システム６００は、これも上述したＦＤＤ層４１６の構成要素であり得る。

システム６００は、プロセッサ６０４及びメモリ６１０を含む処理回路６０２を含むように示されている。これらの構成要素は、様々な異なるタイプ及び量のプロセッサ及びメモリを使用して実装することができることが理解されるであろう。例えば、プロセッサ６０４は、汎用プロセッサ、特定用途向け集積回路（ＡＳＩＣ）、１つ以上のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）、処理構成要素のグループ、又は他の好適な電子処理構成要素であることができる。プロセッサ６０４は、メモリ６１０に通信可能に結合することができる。処理回路６０２は、１つのプロセッサ６０４と１つのメモリ６１０とを含むように示されているが、本明細書で考察されるように、処理回路及び／又はメモリは、様々な実施形態において複数のプロセッサ及び／又はメモリを使用して実装され得ることを理解されたい。全てのそのような変形形態は、本開示の範囲内であることが企図される。

メモリ６１０は、本開示に記載された様々なプロセスを完了及び／又は促進するためのデータ及び／又はコンピュータコードを記憶するための１つ以上のデバイス（例えば、メモリユニット、メモリデバイス、記憶デバイスなど）を含むことができる。メモリ６１０は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードドライブストレージ、一時ストレージ、不揮発性メモリ、フラッシュメモリ、光メモリ、又はソフトウェアオブジェクト及び／又はコンピュータ命令を記憶するための任意の他の好適なメモリを含むことができる。メモリ６１０は、データベース構成要素、オブジェクトコード構成要素、スクリプト構成要素、又は本開示に記載された様々な活動及び情報構造をサポートするための任意の他のタイプの情報構造を含むことができる。メモリ６１０は、処理回路６０２を介してプロセッサ６０４に通信可能に接続することができ、本明細書に記載された１つ以上のプロセスを（例えば、プロセッサ６０４によって）実行するためのコンピュータコードを含むことができる。

メモリ６１０は、故障検出ルールを生成及び／又は修正するように構成されたルール生成器６１２を含むように示されている。いくつかの実施形態では、故障検出ルールは、故障動作を特徴付ける１つ以上のパラメータ（例えば、条件、基準、閾値など）を含み、合致した場合、故障検出ルールが満たされたためにシステムに故障が存在することを示す。いくつかの実施形態では、故障検出ルールは、正常（すなわち、非故障）動作を特徴付ける１つ以上のパラメータを含み、合致した場合、故障検出ルールが「破られた」こと、したがって、システムに故障が存在することを示す。そのようないくつかの実施形態では、１つ以上の条件又は基準は、故障の式又は方程式を含むことができる。例えば、故障検出ルールは、設備の動作データに基づいて、「真」又は「偽」のいずれかとして評価される１つ以上の演算子（例えば、ＡＮＤ、ＯＲ、ＮＯＴなど）を含むブール式であり得る。「真」又は「偽」の結果が故障状態を示すかどうかは、故障検出ルールが故障動作又は正常動作を特徴付けるかどうかに依存し得る。故障検出ルールは他のパラメータ、例えばルールの識別子（すなわち、名前）、ルールの説明、故障のカテゴリ及び優先度、関連付けられた建物設備タイプ、並びに任意の他の好適なパラメータなどを含み得る。故障検出ルールの例は、図８に関して以下でより詳細に説明される。

いくつかの実施形態では、故障検出ルールの第１のセットは、（例えば、ＢＭＳ又は建物設備を動作させる前に）事前に定義され、故障検出ルールの第１のセットは、故障検出及び診断（ＦＤＤ）ルールデータベース６２４に記憶される。故障検出ルールの第１のセットは、例えば、ユーザによって、又はリモートシステムによって事前に定義されてよく、記憶のためにシステム６００に送信されてよい。いくつかの実施形態では、故障検出ルールの第１のセットは、システム６００の初期化の前に、ＦＤＤルールデータベース６２４に事前にプログラムされるか、又は記憶される。

いくつかの実施形態では、ルール生成器６１２は、故障検出ルールの第２のセットの一部として、１つ以上の追加の故障検出ルールを生成するように構成されている。そのようないくつかの実施形態では、ルール生成器６１２は、新たな故障検出ルールのための１つ以上のパラメータを定義するユーザ入力を受信するように構成されている。次いで、ルール生成器６１２は、ユーザ入力に基づいて、新しい故障検出ルールを生成することができる。いくつかの実施形態では、ルール生成器６１２は、ニューラルネットワーク又は他の人工知能システムを介して設備動作データを分析することなどによって、経時的に新たな故障検出ルールを判定する。この点で、ルール生成器６１２は、経時的にＢＭＳ又はユーザプリファレンスを学習することによって、新たな故障検出ルールを自動的に識別し、生成し得る。

メモリ６１０はまた、故障検出ルールを建物デバイス及び／又は建物システム（例えば、建物サブシステム４２８）にマッピングするように構成されたマッピングエンジン６１４を含むように示されている。故障検出ルールを建物デバイスにマッピングすることは、概して、建物デバイスを故障検出ルールに関連付けること、又はその逆を含み、その結果、建物デバイスに関連付けられた動作データを、マッピングされた故障検出ルールに従って分析することができる。いくつかの実施形態では、故障検出ルールは、建物デバイスへの参照、又は建物デバイスを表すＢＭＳ内のオブジェクト（例えば、ソフトウェアオブジェクト）への参照を含む。そのようないくつかの実施形態では、マッピングすることは、タグ又はポインタを生成し、故障検出ルール及び／又は建物デバイスのいずれかに関連付けられたデータオブジェクトにタグ又はポインタを記憶することを含む。例えば、建物デバイスを表すオブジェクトへのポインタは、故障検出ルールを含むデータ構造に記憶されてよい。故障検出ルールを建物デバイス又は複数の建物デバイスにマッピングする他の方法もまた利用されてよく、したがって本明細書で企図されることが理解されるであろう。

図６Ａに示されるように、メモリ６１０はまた、故障コストモデル生成器６１６を含み、故障コストモデル生成器６１６は、故障の時間期間にわたって浪費されたエネルギー量を判定するため、かつ／又は故障に関連付けられたコストを判定するための故障コストモデルを生成するように構成されている。上述したような故障検出ルールと同様に、故障コストモデルは、モデルを定義する式又は方程式を含む複数のパラメータを含み得る。この点で、故障コストモデルは、故障の検出に応答して、故障に関するエネルギー浪費及びコストを計算するために利用され得る。いくつかの実施形態では、故障コストモデルは、建物デバイスによって消費されるエネルギー量、故障の時間期間、及びデバイスによって消費される資源のコストに関連する１つ以上の変数を含み得る。

図６Ｂに示されるように、メモリ６１０はまた、故障の時間期間にわたって浪費されたエネルギー量を判定するために、かつ／又は故障に関連付けられた排出（例えば、炭素排出、温室効果ガス排出など）を判定するために、故障排出モデルを生成するように構成された故障排出モデル生成器６６６も含む。上述したような故障コストルールと同様に、故障排出モデルは、モデルを定義する式又は方程式を含む複数のパラメータを含み得る。この点で、故障排出モデルは、故障の検出に応答して、故障に起因して生成された過剰排出量（例えば、炭素排出量）を計算するために利用され得る。いくつかの実施形態では、故障排出モデルは、１つ以上の変数を含み得、１つ以上の変数は、少なくとも建物デバイスによって消費されたエネルギー量、故障の時間期間、及びデバイスによって生成された、又はそうでなければ故障に起因する排出の割合に関連する。

図６Ａに示されるように、いくつかの実施形態では、故障コストモデル生成器６１６は、経時的に故障コストモデルを生成及び／又は修正し得、故障コストモデルデータベース６２６に故障コストモデルを記憶し得る。いくつかの実施形態では、故障コストモデルデータベース６２６は、ユーザによって定義され、かつ／又はシステム６００の初期化の前に定義されたモデルなどの事前定義された故障コストモデルの第１のセット、並びにシステム６００の動作中に生成される故障コストモデルの第２のセットを含み得る。この点で、故障コストモデル生成器６１６は、新たなモデルを生成するためにシステム挙動又はユーザプリファレンスを学習するように構成され得る。いくつかの実施形態では、故障コストモデル生成器６１６は、システム６００の動作中に集められた経験的データに基づいて、様々な故障、及び様々な故障の結果として生じた資源消費（例えば、エネルギー消費、水消費など）の変化を示す新たな故障コストモデルを生成する。例えば、故障コストモデル生成器６１６は、故障が検出される前と後に資源消費を比較して、故障の結果として資源消費が変化する量を判定し得る。いくつかの実施形態では、故障コストモデル生成器６１６によって生成された各故障コストモデルは、関連する故障への参照を含み得、又はその逆も含み得る。他の実施形態では、故障コストモデルは、故障検出ルールの一部として生成及び記憶され得る。

図６Ｂに示されるように、いくつかの実施形態では、故障排出モデル生成器６６６は、経時的に故障排出モデルを生成及び／又は修正し得、故障排出モデルデータベース６７６に故障排出モデルを記憶し得る。いくつかの実施形態では、故障排出モデルデータベース６７６は、ユーザによって定義され、かつ／又はシステム６００の初期化の前に定義されたモデルなどの事前定義された故障排出モデルの第１のセット、並びにシステム６００の動作中に生成される故障排出モデルの第２のセットを含み得る。この点で、故障排出モデル生成器６６６は、新たなモデルを生成するためにシステム挙動又はユーザプリファレンスを学習するように構成され得る。いくつかの実施形態では、故障排出モデル生成器６６６は、システム６００の動作中に集められた経験的データに基づいて、様々な故障、及び様々な故障の結果として生じた資源消費（例えば、エネルギー消費、水消費など）の変化を示す新たな故障コストモデルを生成する。例えば、故障排出モデル生成器６６６は、故障が検出される前と後に資源消費を比較して、故障の結果として資源消費が変化する量を判定し得る。いくつかの実施形態では、故障排出モデル生成器６６６によって生成された各故障コストモデルは、関連する故障への参照を含み得、又はその逆も含み得る。他の実施形態では、故障排出モデルは、故障検出ルールの一部として生成及び記憶され得る。

メモリ６１０はまた、故障を検出するために建物設備の動作データを分析するように構成された故障検出器６１８を含む。具体的には、故障検出器６１８は、動作データを受信すること、又は動作データを要求／検索することのいずれかによって、複数の建物デバイス又はサブシステムから動作データを取得するように構成され得る。いくつかの実施形態では、動作データは、まさに秒、毎分、毎時などの規則的な時間間隔で受信又は検索される。故障検出器６１８は、各時間間隔で任意の新たに取得された動作データを分析し、それによって各建物デバイス又はサブシステムを各時間間隔で故障についてチェックするように構成され得る。そのようないくつかの実施形態では、動作データを取得し、その後故障についてデータを分析するための時間間隔は、ユーザ入力に基づいて判定される。他の実施形態では、時間間隔は、定義されるか、又は所定のものである。例えば、時間間隔は、プロセッサ６０４の処理速度に基づいて、又は建物デバイスが関連する動作データをポーリング及び送信する速度に基づいて設定され得る。

いくつかの実施形態では、故障検出器６１８は、ＦＤＤルールデータベース６２４に記憶された１つ以上の故障検出ルールに関して動作データを比較及び分析することによって、故障を検出する。そのようないくつかの実施形態では、故障検出器６１８は、（例えば、動作データに含まれるメタデータに基づいて）動作データに関連付けられた建物デバイス又は建物デバイスタイプを識別することができ、適切な故障検出ルールに関して動作データを検索及び／又は分析することができる。故障検出ルールを分析することは、動作データに基づいて、故障検出ルールに関連付けられた式又は方程式が真であるか偽であるかを判定することを含み得る。例えば、チラーの故障検出ルールは、冷却水出力温度が所定の値（例えば、閾値）未満である場合、「真」とみなされ得る。この故障検出ルールが「真」である場合、ルールは満たされたとみなされ得、故障検出器６１８は、関連付けられた建物デバイスに故障が発生しているものとしてフラグを立て得る。

いくつかの実施形態では、故障検出器６１８はまた、故障が検出されると、故障に関する追加のデータを記録する（すなわち、記憶する）ように構成されている。例えば、故障検出器６１８は、故障が検出された日時を記録するように構成され得る。同様に、故障検出器６１８はまた、故障が補正された日時を記録し得る。いくつかの実施形態では、故障検出器６１８は、故障の時間期間（すなわち、デバイスに故障状態が発生する可能性が高い時間量）を推定するように構成されている。そのようないくつかの実施形態では、故障検出器６１８は、時間の経過とともに、故障の検出と、各建物デバイスの故障若しくは特定の故障の解決との間の平均時間間隔を学習するように構成することができる。したがって、故障検出器６１８は、履歴データに基づいて、故障を解決するために所要する時間量を推定することができる。加えて、故障検出器６１８は、検出された故障が解決されるにつれて、各故障についての解決までの推定時間を更新するように構成され得る。

更に図６Ａ及び図６Ｂを参照すると、メモリ６１０は、ユーザインターフェース（ＵＩ）生成器６２０を更に含む。ＵＩ生成器６２０は、ＢＰＩ関連情報を提示するためのグラフィカルインターフェースを生成するように構成され得る。例えば、ＵＩ生成器６２０は、ＢＭＳのＢＰＩ値を示すグラフ、チャート、アニメーションなどを提示するインターフェースを生成してよい。いくつかの実施形態では、ＵＩ生成器６２０はまた、ＢＭＳの非効率性を示すインターフェースを生成し、提示してもよい。例えば、ＢＰＩの計算中に非ゼロペナルティスコアを引き起こした特定のＢＭＳ構成要素（例えば、コントローラ、デバイス、センサなど）を示すインターフェースが生成されてよい。ＵＩ生成器６２０によって生成される様々なユーザインターフェースは、図８～図１０に関して以下でより詳細に説明される。

ＵＩ生成器６２０によって生成された様々なユーザインターフェースは、ユーザデバイス６３２を介して提示され得る。ユーザデバイス６３２は、ユーザにデータを提示するためのインターフェースを有する任意のデバイスであり得る。例えば、ユーザデバイス６３２は、少なくともインターフェースを提示するための画面、及びユーザ入力を受信するための入力デバイスを含み得る。いくつかの実施形態では、ユーザデバイス６３２は、デスクトップ又はラップトップコンピュータ、スマートフォン、タブレット、スマートウォッチなどである。ユーザデバイス６３２は、通信インターフェース６３０を介してシステム６００に通信可能に結合され得、これはまた、システム６００がネットワーク４４６を介してデータを送信及び受信するためのインターフェースを提供する。

再び図６Ａを参照すると、メモリ６１０はまた、１つ以上の故障コストモデル（例えば、故障コストモデルデータベース６２６に記憶される）に基づいて、浪費されたエネルギー量及び故障のコストを判定するように構成された故障コスト分析器６２２を含む。この点で、故障コスト分析器６２２は、（例えば、故障検出器６１８からの指標に応答して）検出された故障に関連付けられた故障コストモデルを（例えば、故障コストモデルデータベース６２６から）検索するように構成され得る。故障コスト分析器６２２は、個別に、又は故障検出器６１８からの指標に基づいて、故障の時間期間と、故障期間中にわたって故障デバイスによって消費されたエネルギー量とを判定し得る。いくつかの実施形態では、故障状態の間にデバイスによって消費されたエネルギー量は、故障のタイプに基づいて可変である。例えば、特定のタイプの故障は、デバイスが通常よりも多い又は少ないエネルギーを消費する原因となり得る。いくつかの実施形態では、故障状態の間にデバイスによって消費されるエネルギー量は、故障のタイプに基づいて固定されているか又は既知である。例えば、特定のタイプの故障により、デバイスが、設定された量のエネルギーを消費するか、又は設定された量だけエネルギー消費が増加する可能性が最も高いことが既知であり得る。

いくつかの実施形態では、故障コスト分析器６２２はまた、建物又はシステムによって消費されるエネルギー総量に影響を及ぼし得る、他の関連する建物デバイスのエネルギー消費を説明する。例えば、３つのチラーを含む建物では、第１のチラーの出力を低減する第１のチラーの故障により、２つの残りのチラーが、建物の快適性設定（例えば、設定値）を維持するために出力を増加させ、それにより２つの残りのチラーのエネルギー使用量が増加する可能性がある。したがって、故障コスト分析器６２２は、故障に応答して、全ての建物デバイスにわたる総過剰エネルギー使用量（すなわち、エネルギー浪費）を判定し得る。

いくつかの実施形態では、故障コスト分析器６２２は、建物デバイスに故障が発生していた時間の長さ、故障に起因する判定されたエネルギー浪費、及び電気、天然ガスなどの関連するエネルギー資源を得るための現在のレート若しくはコストに基づいて、故障に関連付けられたコストを計算するように構成されている。そのような実施形態では、故障コスト分析器６２２は、ネットワーク４４６を介してなど、資源供給者（例えば、電力会社、天然ガス提供者など）から現在のレートデータを取得してよい。例えば、故障コスト分析器６２２は、資源供給者のウェブサイト又はサーバからレートデータを検索してよい。この点で、資源購入レートは時間の経過とともに（例えば、需要に基づいて）変動し得るため、故障コスト分析器６２２は、現在のレートを検索することによって、故障に対してより正確なコストを提供し得る。しかしながら、他の実施形態では、故障コスト分析器６２２は、固定資源コストを利用するか、又は（例えば、故障コスト計算を実施することに応答してではなく）規則的な間隔で資源コストを更新する。

本明細書に記載されたコスト計算（例えば、故障コストモデル）は、主に金銭的コストを考慮するように記載されているが、コスト計算は、本開示の教示から逸脱することなく、金銭的コストに加えて、又は金銭的コストの代わりに、１つ以上の他の制御対象（例えば、資源消費、炭素排出、占有者の快適性、疾患伝播リスク、設備の劣化若しくは信頼性など）を考慮する任意のタイプのコスト関数で修正又は置き換えることができることが企図される。コスト計算で計算される「コスト」とは、金銭的コスト（例えば、ドル若しくは他の通貨の単位で表される）及び／又は資源消費（例えば、エネルギー、水、天然ガス、若しくは任意の他の資源の単位で表される）、炭素排出量（例えば、炭素の単位で表される）、占有者の快適性（例えば、快適性の単位で表される）、疾患伝播リスク（例えば、リスク若しくは確率の単位で表される）、及び／又は設備の信頼性（例えば、信頼性若しくは予想される故障の単位で表される）などの、他のタイプのコストであり得ることを理解されたい。したがって、本開示を通して「コスト」への言及は、必ずしも金銭的コストである必要はなく、最適化することが望ましい場合がある任意の他の制御対象を含み得ることを理解されたい。

再び図６Ｂを参照すると、メモリ６１０はまた、（例えば、故障コストモデルデータベース６２６に記憶された）１つ以上の故障排出モデルに基づいて、故障によって生成された追加の排出量を判定するように構成された故障排出分析器６７２を含む。この点で、故障排出分析器６７２は、（例えば、故障検出器６１８からの指標に応答して、）検出された故障に関連付けられた故障排出モデルを（例えば、故障排出モデルデータベース６７６から）検索するように構成され得る。故障排出分析器６７２は、個別に、又は故障検出器６１８からの指標に基づいて、故障の時間期間と、故障期間中にわたって故障デバイスによって生成された追加の排出量とを判定し得る。いくつかの実施形態では、故障状態の間にデバイスによって生成された追加の排出量は、故障のタイプに基づいて可変である。例えば、特定のタイプの故障は、デバイスが通常よりも多い又は少ない排出量を生成する原因となり得る。いくつかの実施形態では、故障状態の間にデバイスによって消費されるエネルギー量は、故障のタイプに基づいて固定されているか又は既知である。例えば、特定のタイプの故障により、デバイスが、設定された量のエネルギーを消費するか、エネルギー消費が増加するか、又は設定された量だけ増加した排出を生成する可能性が最も高いことが既知であり得る。

いくつかの実施形態では、故障排出分析器６７２はまた、建物又はシステムによって生成される総排出量に影響を及ぼし得る、他の関連する建物デバイスのエネルギー消費を説明する。例えば、３つのチラーを含む建物では、第１のチラーによって生成される排出を低減する第１のチラーの故障により、２つの残りのチラーが、建物の快適性設定（例えば、設定値）を維持するために出力を増加させ、それにより２つの残りのチラーによって生成される排出量が増加する可能性がある。したがって、故障排出分析器６７２は、故障に応答して、全ての建物デバイスにわたる総過剰エネルギー使用量（すなわち、エネルギー浪費）を判定し得る。

いくつかの実施形態では、故障排出分析器６７２は、建物デバイスに故障が発生していた時間の長さと故障に起因する判定されたエネルギー浪費とに基づいて、故障に起因して生成された排出量を計算するように構成されている。そのような実施形態では、故障排出分析器６７２は、ネットワーク４４６を介してなど、資源供給者（例えば、電力会社、天然ガス提供者など）からエネルギー混合データを取得してよい。エネルギー混合データは、資源供給者によって使用される再生可能エネルギーの割合、及び／又は発電に使用される化石燃料のタイプを含み得る。例えば、故障排出分析器６７２は、資源供給者のウェブサイト又はサーバからエネルギー混合データを検索してよい。この点で、資源供給者によって使用されるエネルギー混合は、時間の経過とともに（例えば、需要に基づいて）変動し得るため、故障排出分析器６７２は、現在のレートを検索することによって、故障に起因して生成された排出量のより正確な計算を提供し得る。しかしながら、他の実施形態では、故障排出分析器６７２は、固定排出レートを利用するか、又は（例えば、故障排出量計算を実施することに応答してではなく）規則的な間隔でエネルギー混合データを検索する。

いくつかの実施形態では、検出された故障に応答して、及び／又は、浪費されたエネルギー、生成された排出、又は故障のコストの判定に応答して、システム６００（例えば、具体的には、故障検出器６１８、故障排出分析器６７２、及び／又は故障コスト分析器６２２）は、自動応答を開始するように構成され得る。自動応答は、例えば、検出された故障に関する作業指図を生成し、故障を補正するための技術者からの訪問を自動的にスケジュールすることを含み得る。いくつかの実施形態では、システム６００は、作業指図自体を生成するか、又は作業指図を生成するための要求をリモート作業指図管理システムに送信する。いずれの場合も、作業指図は、故障のタイプ、故障が発生しているデバイスのデバイス及び場所、故障が検出された日時、並びに故障を診断及び補正する際に技術者を支援し得る任意の他の関連する故障情報を示し得る。

いくつかの実施形態では、自動応答は、警告を生成することと（例えば、ユーザデバイスに）送信することとを含み、警告は、故障を識別し、故障に関連付けられたコスト及び／又は故障によって生成された排出を示す。例えば、システム６００は、テキストメッセージ、電子メール、音声呼、プッシュ通知を介して、又は任意の他の方法によって、ユーザデバイス６３２に警告を送信し得る。いくつかの実施形態では、自動応答は、ＵＩ生成器６２０によって、故障及び影響を受けたデバイスを識別する情報を表示するユーザインターフェースを生成することと、故障コスト分析器６２２によって計算されたエネルギー及びコスト情報並びに／又は故障排出分析器６７２によって計算された排出情報を提示することとを含む。例えば、ユーザインターフェースは、故障情報を提示するためのグラフ、テキスト、画像、及び他の要素を含むユーザデバイス６３２を介して提示することができる。

ここで図７Ａを参照すると、いくつかの実施形態による、故障に関連付けられたコストを判定するための方法７００が示されている。図７Ｃは、方法７００において生じるデータフローを示すチャートである。方法７００は、例えば、設備の故障を検出し、故障に関連付けられたコストを判定し、故障に基づいて自動応答を開始するために、システム６００によって実装され得る。有利には、浪費されるエネルギー量と故障に関連付けられたコストとを判定することは、より完全な洞察をユーザ（例えば、建物管理者）に提供するだけでなく、高コストの故障状態の優先順位付けを可能にし得る。この点で、高コストの故障、又は大量のエネルギーを浪費する故障は、他のより安価な故障よりも迅速に対処され得、それによって故障に起因する過剰なコストを最小限に抑える。方法７００の特定のステップは任意選択であり得、いくつかの実施形態では、方法７００は、全てのステップよりも少ないステップを使用して実装され得ることが理解されよう。

ステップ７０２において、１つ以上の故障検出ルールが取得される。いくつかの実施形態では、１つ以上の故障検出ルールは、検索のために事前に定義されデータベースに記憶される。いくつかの実施形態では、１つ以上の故障検出ルールの少なくとも一部は、ユーザ定義である。そのような実施形態では、ユーザ（例えば、建物管理者）は、ユーザインターフェースを介して１つ以上の故障検出ルールのパラメータを入力し得、故障検出ルールは、ユーザの入力に基づいて生成することができる。いずれの場合も、１つ以上の故障検出ルールを取得することは、データベースから１つ以上の故障検出ルールを検索すること、及び／又は新たな故障検出ルールを定義するユーザ入力を受信することを含み得る。いくつかの実施形態では、故障検出ルールの第１のセットは事前に定義され得、故障検出ルールの第２のセットはシステム６００の動作中にユーザによって定義され得る。

ステップ７０４において、１つ以上の故障検出ルールの各々が、１つ以上の建物デバイスにマッピングされる。上述したように、故障検出ルールを建物デバイスにマッピングすることは、概して、建物デバイスを故障検出ルールに関連付けること、又はその逆を含み、その結果、建物デバイスに関連付けられた動作データを、マッピングされた故障検出ルールに従って分析することができる。いくつかの実施形態では、故障検出ルールは、建物デバイスへの参照、又は建物デバイスを表すＢＭＳ内のオブジェクト（例えば、ソフトウェアオブジェクト）への参照を含む。そのようないくつかの実施形態では、マッピングすることは、タグ又はポインタを生成し、故障検出ルール及び／又は建物デバイスのいずれかに関連付けられたデータオブジェクトにタグ又はポインタを記憶することを含む。例えば、建物デバイスを表すオブジェクトへのポインタは、故障検出ルールを含むデータ構造に記憶されてよい。故障検出ルールを建物デバイス又は複数の建物デバイスにマッピングする他の方法もまた利用されてよく、したがって本明細書で企図されることが理解されるであろう。

いくつかの実施形態では、故障検出ルールは、例えば、デジタルツイン内の仮想データ点又は仮想メータにマッピングされ得る。デジタルツインは、建物及び／又は建物のエンティティ（例えば、空間、設備の一部、占有者など）の仮想表現であることができる。更に、デジタルツインは、例えば、施設管理、クリーンエア最適化、エネルギー予測、設備保守点検など、建物内で実施されるサービスを表すことができる。デジタルツインは、２０２１年１１月２９日に出願された米国特許出願第１７／５３７０４６号に更に記載されており、その内容全体は、参照により本明細書に組み込まれる。デジタルツインは、仮想データ点又は仮想メータを含み得、これらは物理メータによって直接測定されない物理パラメータに対応している。仮想データ点は、実データ点の関数として定義され得る。例えば、流体のエンタルピーを表す仮想エンタルピー点は、流体の温度及び圧力を表す実数点に基づいて計算することができる。仮想データ点は、２０１６年６月１４日に出願された米国特許第１０，６４９，４１９号（出願第１５／１８２５８０号）、及び２０１８年８月１日に出願された米国特許第１１，２８１，１６９号（出願第１６／０５２０８３）に更に記載されており、それらの内容全体は、参照により本明細書に組み込まれる。

ステップ７０６において、１つ以上の建物デバイス及び／又は１つ以上の仮想データ点の各々から動作データが取得される。いくつかの実施形態では、動作データは、建物デバイス又は建物デバイスコントローラに照会することなどによって、１つ以上の建物デバイスに要求及び／又はそれから検索される。いくつかの実施形態では、動作データは、１つ以上の建物デバイスから自動的に受信される。いずれの場合も、動作データは、規則的又は不規則な時間間隔（例えば、毎秒複数回、毎分、毎日、毎月、断続的に、需要に応じてなど）で取得され得る。例えば、システム６００は、規則的な時間間隔で各建物デバイスに動作データを要求してよく、かつ／又は１つ以上の建物デバイスは、規則的な時間間隔で動作データを送信してよい。有利には、各建物デバイスについての動作データは、データの不一致を防止するために、又は異なるデバイスから異なる時間にデータが受信されることを防止するために、同じ時間間隔で取得されてよい。

いくつかの実施形態では、規則的な時間間隔は、事前に定義されている。例えば、時間間隔は、システム６００の処理速度に基づいて設定され得る。しかしながら、他の実施形態では、動作データを取得するための時間間隔は、ユーザによって定義される。例えば、建物管理者は、３０秒ごとに動作データを取得し、次に、３０秒ごとに各建物デバイスの故障チェックを実施することを選択し得る。

ステップ７０８において、動作データに基づいて故障状態が検出される。いくつかの実施形態では、動作データは、１つ以上の故障検出ルールと比較されるか、又はそれに基づいて分析される。そのような実施形態では、動作データのセットは、動作データを送信及び／又は収集した関連付けられた建物デバイスを示し得、次いで、これを使用して、デバイスに関連付けられた１つ以上の故障検出ルールを判定することができる。次いで、故障検出ルールは、動作データに基づいて評価され得、故障検出ルールのいずれかが満たされているかどうかを判定する（例えば、「真」として評価される）。例えば、建物デバイスに関する特定のパラメータの値は、故障検出ルールの要件が満たされているかどうかを判定するために、故障検出ルールと比較されてよい。故障検出ルールが真であると判定された場合、そのルールは満たされているとみなされ、故障を示し得る。

いくつかの実施形態では、ステップ７０８は、故障検出ルールを分析する前に、故障検出ルール又は動作データのうちの１つを修正することを含むことができる。そのような実施形態では、故障検出ルール及び／又は動作データは、動作データのフォーマット若しくは測定単位に基づいて、及び／又は表示のための好適な測定単位（例えば、ユーザ定義の測定単位）に基づいて、修正されてよい。例えば、第１のチラーは摂氏で水温を測定し得、第２のチラーは華氏で水温を測定し得る。したがって、チラーに適用される動作データ及び／又は故障検出ルールは、異なる測定単位に対応するように修正され得る。例えば、故障検出ルールは、摂氏及び華氏に関して自動的に修正されてよく、又は測定単位のうちの１つに基づいて第２の故障検出ルールが自動的に生成されてもよい。代替的に、動作データは、故障検出ルールによって定義された測定単位に変換されてもよい。

ステップ７１０において、故障状態に関連付けられた故障コストモデルに基づいて、故障状態の時間期間にわたって浪費されたエネルギー量が判定される。例えば、建物デバイスは、故障の過程で１０ｋＷｈの電気を浪費すると判定され得る。１つ以上の故障検出ルールと同様に、１つ以上の故障コストモデルが生成及び／又は事前定義され、故障コストモデルデータベースに記憶され得る。この点で、検出された故障に関連付けられた故障コストモデルは、故障の検出に応答して、検出された特定の故障の識別情報に基づいて検索され得る。例えば、故障コストモデルデータベースは、各々が特定の故障に対応する多くの異なる故障コストモデルを記憶し得る。ステップ７０８で故障を検出すると、故障を特徴付ける１つ以上の属性（例えば、故障ＩＤ、故障のタイプ、故障が起こったデバイス、トリガされた特定の故障検出ルールのＩＤなど）を使用して、ステップ７１０で対応する故障コストモデルを識別及び検索し得る。上述したように、故障コストモデルは、モデルを定義する式又は方程式を含む複数のパラメータを含み得る。例えば、故障コストモデルは、建物デバイスによって消費されたエネルギーの、少なくとも量、故障の時間期間、及びデバイスによって消費された資源のコストに関連する、１つ以上の変数を含む式又は方程式を含み得る。

いくつかの実施形態では、故障コストモデルは、動作データのフォーマット若しくは測定単位に基づいて、及び／又は表示のための好適な測定単位（例えば、ユーザ定義の測定単位）に基づいて修正される。そのようないくつかの実施形態では、故障コストモデルは、（例えば、ステップ７０８において）故障検出ルール又は受信した動作データを修正するのではなく、モデルの各項が共通の測定単位によって定義されるように修正される。いくつかの実施形態では、故障コストモデル（例えば、及び／又は故障コストモデル生成器６１６）は、入力動作データに基づくなどして、測定単位を自動的に検出して、故障コストモデル自体を、又は故障コストモデルの出力を調整するように構成されている。例えば、様々な異なるフォーマットの又は測定単位の動作データが故障コストモデルに入力されてよく、故障コストモデルは、異種データを共通のフォーマットに自動的に変換し、結果を共通のフォーマットで出力するように構成されてよい。

いくつかの実施形態では、ステップ７１０はまた、故障状態の時間期間（すなわち、持続時間）を判定すること、及び／又は建物デバイスに故障が発生している時間量を推定することを含む。例えば、故障コストモデルは、現在の瞬間まで（例えば、リアルタイムで）浪費されたエネルギー量を判定するために、故障の検出と現在の時間との間の時間期間にわたって分析され得る。代替的に、故障コストモデルは、浪費されたエネルギー量を推定するために、将来に延びる推定される時間期間にわたって分析され得る。いくつかの実施形態では、故障の推定される時間期間は、履歴データに基づいて、又は技術者がサービスのためにいつデバイスに到達できるかの判定に基づいて、判定され得る。いくつかの実施形態では、仮想メータ又は仮想データ点からのデータのみならず、建物デバイスデータを例えばデジタルツインで使用して、傾向を判定し、将来の故障を予測してもよい。浪費されるエネルギーの予測量、コスト、及び故障の持続時間は、以前のデータ読み取り値からの傾向に基づいて判定することができる。例えば、故障は、故障を示すレベルに向かって継続的に増加しているデータ読み取り値を報告するデータ点に基づいて予測され得る。故障が起こる前に予測することにより、予防的保守点検を実施して、故障を防止し、生成されたであろうコスト又は排出量を低減又は排除することができる。いくつかの故障又は故障のタイプは、典型的には、補正アクションを必要とせずにそれら自体を解決する一時的な故障であり得る。いくつかの実施形態では、建物デバイスに故障が発生するであろう時間量は、過去の故障の履歴と、故障がそれら自体を解決する前に持続した対応する時間期間とに基づいて推定される。他の故障又は故障のタイプは、補正アクションが取られない限り、典型的には自己解決しない永続的な故障であり得る。いくつかの実施形態では、建物デバイスに故障が発生するであろう時間量は、サービス技術者が故障をどのくらいすぐに補正できるかに基づいて推定される。例えば、システム６００は、作業指図スケジュール及び／又は技術者のスケジュールを判定して、技術者が故障を補正することができる最も早い時間を判定し得る。更に別の例では、故障コストモデルは、故障の検出と、故障が補正されるか若しくはデバイスがオフになる時間との間の時間期間にわたって分析され得る。

いくつかの実施形態では、故障状態の時間期間にわたって浪費されたエネルギー量は、動作データが受信される速度に基づくなど、規則的な時間間隔で判定される。例えば、故障コストモデルを使用して、新たな動作データが建物デバイスから受信される各時間ステップでのエネルギー浪費を判定し得る。いくつかの実施形態では、故障コストモデルが設備のエネルギー浪費を判定するために使用される速度は、データが受信される速度に一致するように、又は欠落しているデータ点を説明するために、動的に調整される。例えば、エネルギー浪費の判定に必要な単一のデータ点が利用できない場合（例えば、値がキャプチャされていなかった、対応するデバイス又はセンサが他のセンサとは異なる速度で読み取るなど）、エネルギー浪費は、その時間ステップに対して計算されない場合がある。例えば、浪費されたエネルギーの判定に必要な単一のデータ点からのデータが利用できない場合（例えば、値がキャプチャされていなかった、対応するデバイス又はセンサが他のセンサとは異なる速度で読み取るなど）、エネルギー浪費は、その時間ステップに対して計算されない場合がある。他の実施形態では、ＢＭＳは、データ点からのデータが利用できないときに、データ点タイプに基づいてデータを自動的に追加又は補正し得る。例えば、ＢＭＳは、履歴データを使用して、欠損又は誤りの疑いのあるデータ（例えば、最新の測定値、所定の時間期間にわたる平均測定値、前の測定値及び後続の測定値に基づいて補間されたデータなど）を推定し得る。欠損データを計算するために同様に適用することができる、誤りの疑いのあるデータを検出及びクレンジングするための方法は、２０１２年９月２８日に出願された米国特許第９，３５４，９６８号（出願第１３／６３１３０１号）において更に適切に記載されて、更に記載されており、その内容全体が、参照により本明細書に組み込まれる。

ステップ７１２において、浪費されたエネルギー量に基づいて、故障のコストが計算される。上述したように、故障のコストは、故障コストモデルに基づいて、かつ／又は故障コストモデルの出力に基づいて計算され得る。いくつかの実施形態では、故障のコストを計算することは、デバイスによって消費される資源（例えば、電気、水、ガスなど）のコストを判定し、資源のコストに浪費されたエネルギー量を乗算することを含む。いくつかの実施形態では、故障コストは、経時的に変化する消費された資源のレートに基づくなどして、１つ以上の個々の時間ステップで計算され得、個々の時間ステップは、故障コストを判定するために集約され得る。

いくつかの実施形態では、ステップ７１２は、故障コストを計算する前に、現在又は最近の資源コストを取得することを含む。例えば、資源レートは、資源提供者（例えば、電力会社）のためのウェブサイト、サーバ、クラウドホストデータベース、又は他のデータソースにアクセスすることによって取得され得、又は資源レートは、資源提供者から定期的な間隔で受信され得る。この例では、資源提供者は、次に、顧客（例えば、システム６００）にプッシュされる資源レート（すなわち、コスト）を定期的に公開又は更新し得る。したがって、故障コストを計算するときに最新の資源レート及び／又は他の既知の資源レートを利用して、より正確な故障コストを提供し得る。

ステップ７１４において、故障の検出及び／又は計算された故障コストに基づいて、自動応答が開始される。上で考察されたように、自動応答は、検出された故障に関する作業指図を生成し、故障を補正するための技術者からの訪問を自動的にスケジュールすることを含み得る。作業指図は、故障のタイプ、故障が発生しているデバイスのデバイス及び場所、故障が検出された日時、並びに故障を診断及び補正する際に技術者を支援し得る任意の他の関連する故障情報を示し得る。自動応答はまた、各故障の相対コストに基づいて、複数の作業指図の優先順位付けを含み得る。いくつかの実施形態では、作業指図を生成することはまた、修理サービス又は技術者訪問を自動的にスケジュールすることを含んでもよい。例えば、作業指図ログ又は技術者スケジュールは、技術者が故障を補正することができる時間期間を識別及び予約するために参照されてよい。いくつかの実施形態では、作業指図が作成されたという通知もまた、割り当てられた技術者に関連付けられたデバイスに送信され得る。

いくつかの実施形態では、自動応答は、警告を生成することと（例えば、ユーザデバイスに）送信することとを含み、警告は、故障を識別し、故障に関連付けられたコストを示す。例えば、通知は、テキストメッセージ、電子メール、音声呼、プッシュ通知を介して、又は他の方法によって、（例えば、技術者又は建物管理者に関連付けられた）ユーザデバイスに送信され得る。いくつかの実施形態では、自動応答は、故障及び影響を受けたデバイスを識別する情報を表示する１つ以上のユーザインターフェースを生成することと、ステップ７１０及び７１２で計算されたエネルギー及びコスト情報を提示することとを含む。例えば、ユーザインターフェースは、故障情報を提示するためのグラフ、テキスト、画像、及び他の要素を含むユーザデバイス６３２を介して提示することができる。追加のユーザインターフェースは、以下でより詳細に説明される。

図７Ｃは、方法７００を更に示すフローチャート７５０である。故障検出ルール７５２は、例えば、上述したように、定期的な間隔で作成され、繰り返し実行される。故障持続時間７５４は、故障検出ルール７５２がアクティブな故障をどのくらい長く識別し続けるかに基づく。故障コスト方程式７５６は、故障検出ルール、故障持続期間、及び設備に関する情報（例えば、設備仕様７５８、センサ及び他のフィードバック機構からのデータ点７６０、並びに設備に関連する定数７６２）を受信する。故障コスト方程式７５６は、浪費された各タイプのエネルギー７６４（例えば、電気、熱など）の量を識別する。公共料金７６６は、資源提供者によって受信され、浪費されたエネルギーのコスト７６８を計算するために使用される。

ここで図７Ｂを参照すると、いくつかの実施形態による、故障に起因して生成された排出量を判定するための方法７０１が示されている。方法７０１は、例えば、設備の故障を検出し、故障に関連付けられたコストを判定し、故障に基づいて自動応答を開始するために、システム６００によって実装され得る。有利には、故障に起因して生成された排出量を判定することは、より完全な洞察をユーザ（例えば、建物管理者）に提供するだけでなく、高排出量故障状態の優先順位付けを可能にし得る。この点で、高排出量故障は、他のより低排出故障よりも迅速に対処され得、それによって故障に起因する過剰排出を最小限に抑える。方法７０１の特定のステップは任意選択であり得、いくつかの実施形態では、方法７０１は、全てのステップよりも少ないステップを使用して実装され得ることが理解されよう。

ステップ７０３において、１つ以上の故障検出ルールが取得される。いくつかの実施形態では、１つ以上の故障検出ルールは、検索のために事前に定義されデータベースに記憶される。いくつかの実施形態では、１つ以上の故障検出ルールの少なくとも一部は、ユーザ定義である。そのような実施形態では、ユーザ（例えば、建物管理者）は、ユーザインターフェースを介して１つ以上の故障検出ルールのパラメータを入力し得、故障検出ルールは、ユーザの入力に基づいて生成することができる。いずれの場合も、１つ以上の故障検出ルールを取得することは、データベースから１つ以上の故障検出ルールを検索すること、及び／又は新たな故障検出ルールを定義するユーザ入力を受信することを含み得る。いくつかの実施形態では、故障検出ルールの第１のセットは事前に定義され得、故障検出ルールの第２のセットはシステム６００の動作中にユーザによって定義され得る。

ステップ７０５において、１つ以上の故障検出ルールの各々は、１つ以上の建物デバイスにマッピングされる。上述したように、故障検出ルールを建物デバイスにマッピングすることは、概して、建物デバイスを故障検出ルールに関連付けること、又はその逆を含み、その結果、建物デバイスに関連付けられた動作データを、マッピングされた故障検出ルールに従って分析することができる。いくつかの実施形態では、故障検出ルールは、建物デバイスへの参照、又は建物デバイスを表すＢＭＳ内のオブジェクト（例えば、ソフトウェアオブジェクト）への参照を含む。そのようないくつかの実施形態では、マッピングすることは、タグ又はポインタを生成し、故障検出ルール及び／又は建物デバイスのいずれかに関連付けられたデータオブジェクトにタグ又はポインタを記憶することを含む。例えば、建物デバイスを表すオブジェクトへのポインタは、故障検出ルールを含むデータ構造に記憶されてよい。故障検出ルールを建物デバイス又は複数の建物デバイスにマッピングする他の方法もまた利用されてよく、したがって本明細書で企図されることが理解されるであろう。

方法７００のステップ７０４を参照して上述したように、故障検出ルールは、例えば、デジタルツイン内の仮想データ点又は仮想メータにマッピングされ得る。

ステップ７０７において、１つ以上の建物デバイス及び／又は１つ以上の仮想データ点の各々から動作データが取得される。いくつかの実施形態では、動作データは、建物デバイス又は建物デバイスコントローラに照会することなどによって、１つ以上の建物デバイスに要求及び／又はそれから検索される。いくつかの実施形態では、動作データは、１つ以上の建物デバイスから自動的に受信される。いずれの場合も、動作データは、規則的又は不規則な時間間隔（例えば、毎秒複数回、毎分、毎日、毎月、断続的に、需要に応じてなど）で取得され得る。例えば、システム６００は、規則的な時間間隔で各建物デバイスに動作データを要求してよく、かつ／又は１つ以上の建物デバイスは、規則的な時間間隔で動作データを送信してよい。有利には、各建物デバイスについての動作データは、データの不一致を防止するために、又は異なるデバイスから異なる時間にデータが受信されることを防止するために、同じ時間間隔で取得されてよい。

いくつかの実施形態では、規則的な時間間隔は、事前に定義されている。例えば、時間間隔は、システム６００の処理速度に基づいて設定され得る。しかしながら、他の実施形態では、動作データを取得するための時間間隔は、ユーザによって定義される。例えば、建物管理者は、３０秒ごとに動作データを取得し、次に、３０秒ごとに各建物デバイスの故障チェックを実施することを選択し得る。

ステップ７０９において、動作データに基づいて故障状態が検出される。いくつかの実施形態では、動作データは、１つ以上の故障検出ルールと比較されるか、又はそれに基づいて分析される。そのような実施形態では、動作データのセットは、動作データを送信及び／又は収集した関連付けられた建物デバイスを示し得、次いで、これを使用して、デバイスに関連付けられた１つ以上の故障検出ルールを判定することができる。次いで、故障検出ルールは、動作データに基づいて評価され得、故障検出ルールのいずれかが満たされているかどうかを判定する（例えば、「真」として評価される）。例えば、建物デバイスに関する特定のパラメータの値は、故障検出ルールの要件が満たされているかどうかを判定するために、故障検出ルールと比較されてよい。故障検出ルールが真であると判定された場合、そのルールは満たされているとみなされ、故障を示し得る。

いくつかの実施形態では、ステップ７０９は、故障検出ルールを分析する前に、故障検出ルール又は動作データのうちの１つを修正することを含むことができる。そのような実施形態では、故障検出ルール及び／又は動作データは、動作データのフォーマット若しくは測定単位に基づいて、及び／又は表示のための好適な測定単位（例えば、ユーザ定義の測定単位）に基づいて、修正されてよい。例えば、第１のチラーは摂氏で水温を測定し得、第２のチラーは華氏で水温を測定し得る。したがって、チラーに適用される動作データ及び／又は故障検出ルールは、異なる測定単位に対応するように修正され得る。例えば、故障検出ルールは、摂氏及び華氏に関して自動的に修正されてよく、又は測定単位のうちの１つに基づいて第２の故障検出ルールが自動的に生成されてもよい。代替的に、動作データは、故障検出ルールによって定義された測定単位に変換されてもよい。

ステップ７１１において、故障状態に関連付けられた故障排出モデルに基づいて、故障状態の時間期間にわたって浪費されたエネルギー量が判定される。例えば、建物デバイスは、故障の過程で１０ｋＷｈの電気を浪費し、故障に起因して追加の１０立方フィートの天然ガスを燃焼すると判定され得る。１つ以上の故障コストモデルと同様に、１つ以上の故障排出モデルが生成及び／又は事前定義され、故障排出モデルデータベースに記憶され得る。この点で、検出された故障に関連付けられた故障排出モデルは、故障の検出に応答して、検出された特定の故障の識別情報に基づいて検索され得る。例えば、故障排出モデルデータベースは、各々が特定の故障に対応する多くの異なる故障排出モデルを記憶し得る。ステップ７０９で故障を検出すると、故障を特徴付ける１つ以上の属性（例えば、故障ＩＤ、故障のタイプ、故障が起こったデバイス、トリガされた特定の故障検出ルールのＩＤなど）を使用して、ステップ７１１で対応する故障排出モデルを識別及び検索し得る。上述したように、故障排出モデルは、モデルを定義する式又は方程式を含む複数のパラメータを含み得る。例えば、故障排出モデルは、建物デバイスによって消費されたエネルギーの、少なくとも量、故障の時間期間、及び／又はデバイスによって消費された資源量に関連する、１つ以上の変数を含む式又は方程式を含み得る。

いくつかの実施形態では、故障排出モデルは、動作データのフォーマット若しくは測定単位に基づいて、及び／又は表示のための好適な測定単位（例えば、ユーザ定義の測定単位）に基づいて修正される。そのようないくつかの実施形態では、故障排出モデルは、（例えば、ステップ７０９において）故障検出ルール又は受信した動作データを修正するのではなく、モデルの各項が共通の測定単位によって定義されるように修正される。いくつかの実施形態では、故障排出モデル（例えば、及び／又は故障排出モデル生成器６７６）は、入力動作データに基づくなどして、測定単位を自動的に検出して、故障排出モデル自体を、又は故障排出モデルの出力を調整するように構成されている。例えば、様々な異なるフォーマットの又は測定単位の動作データが故障排出モデルに入力されてよく、故障排出モデルは、異種データを共通のフォーマットに自動的に変換し、結果を共通のフォーマットで出力するように構成されてよい。

いくつかの実施形態では、ステップ７１１はまた、故障状態の時間期間（すなわち、持続時間）を判定すること、及び／又は建物デバイスに故障が発生している時間量を推定することを含む。例えば、故障排出モデルは、現在の瞬間まで（例えば、リアルタイムで）浪費されたエネルギー量を判定するために、故障の検出と現在の時間との間の時間期間にわたって分析され得る。代替的に、故障排出モデルは、浪費されたエネルギー量を推定するために、将来に延びる推定される時間期間にわたって分析され得る。いくつかの実施形態では、故障の推定される時間期間は、履歴データに基づいて、又は技術者がサービスのためにいつデバイスに到達できるかの判定に基づいて、判定され得る。いくつかの実施形態では、仮想メータ又は仮想データ点からのデータのみならず、建物デバイスデータを例えばデジタルツインで使用して、傾向を判定し、将来の故障を予測してもよい。浪費されるエネルギーの予測量、生成された排出量、及び故障の持続時間は、以前のデータ読み取り値からの傾向に基づいて判定することができる。いくつかの故障又は故障のタイプは、典型的には、補正アクションを必要とせずにそれら自体を解決する一時的な故障であり得る。いくつかの実施形態では、建物デバイスに故障が発生するであろう時間量は、過去の故障の履歴と、故障がそれら自体を解決する前に持続した対応する時間期間とに基づいて推定される。他の故障又は故障のタイプは、補正アクションが取られない限り、典型的には自己解決しない永続的な故障であり得る。いくつかの実施形態では、建物デバイスに故障が発生するであろう時間量は、サービス技術者が故障をどのくらいすぐに補正できるかに基づいて推定される。例えば、システム６００は、作業指図スケジュール及び／又は技術者のスケジュールを判定して、技術者が故障を補正することができる最も早い時間を判定し得る。更に別の例では、故障排出モデルは、故障の検出と、故障が補正されるか若しくはデバイスがオフになる時間との間の時間期間にわたって分析され得る。

いくつかの実施形態では、故障状態の時間期間にわたって浪費されたエネルギー量は、動作データが受信される速度に基づくなど、規則的な時間間隔で判定される。例えば、故障排出モデルを使用して、新たな動作データが建物デバイスから受信される各時間ステップでの生成された排出量を判定し得る。いくつかの実施形態では、データは、ユーザ入力によって定義された間隔に基づいて、各データ点から同時に受信され得る。いくつかの実施形態では、故障排出モデルが浪費されたエネルギー量を判定するために使用される速度は、データが受信される速度に一致するように、又は欠落しているデータ点を説明するために、動的に調整される。例えば、浪費されたエネルギーの判定に必要な単一のデータ点からのデータが利用できない場合（例えば、値がキャプチャされていなかった、対応するデバイス又はセンサが他のセンサとは異なる速度で読み取るなど）、エネルギー浪費は、その時間ステップに対して計算されない場合がある。方法７００のステップ７１０を参照して上述したように、ＢＭＳは、データ点からのデータが利用できないときに、データ点タイプに基づいてデータを自動的に追加又は補正し得る。例えば、ＢＭＳは、履歴データを使用して、欠損又は誤りの疑いのあるデータ（例えば、最新の測定値、所定の時間期間にわたる平均測定値、前の測定値及び後続の測定値に基づいて補間されたデータなど）を推定し得る。

ステップ７１３において、浪費されたエネルギー量に基づいて、故障に起因して生成された排出量が判定される。上述したように、故障に起因して生成された排出量は、故障排出モデルに基づいて、かつ／又は故障排出モデルの出力に基づいて計算され得る。いくつかの実施形態では、生成された排出量を計算することは、浪費されたエネルギーを生成するために使用された各電源の単位当たりの排出量を判定することと、資源のコストに浪費されたエネルギー量を乗算することとを含む。いくつかの実施形態では、故障に起因して生成された排出量は、経時的に変化する消費された資源のレートに基づくなどして、１つ以上の個々の時間ステップで計算され得、個々の時間ステップは、生成された排出量を判定するために集計され得る。いくつかの実施形態では、生成された排出量を判定することは、必ずしも特定の数値の排出量を判定することを必要とするわけではないが、バイナリ判定（すなわち、排出量が存在する又は排出量が存在しない）を行うことを含み得る。

いくつかの実施形態では、ステップ７１３は、故障に起因して生成された排出量を計算する前に、資源供給者から現在又は最近のエネルギー混合データを取得することを含む。エネルギー混合データは、再生可能な資源又は化石燃料から生成される、資源供給者によって供給される電力の割合、並びに使用される再生可能なタイプ（例えば、太陽光、風力、水力など）又は化石燃料のタイプ（例えば、石炭、天然ガス、石油など）を含み得る。エネルギー混合データはまた、建物デバイスに直接供給される天然ガスなどの燃料の様々な成分の割合を含み得る。例えば、エネルギー混合データは、天然ガス中のメタン、エタン、プロパン、ブタンなどのパーセンテージを含み得る。このデータは、資源供給者から、又はセンサの読み取り値又は試験データから取得され得る。エネルギー混合データは、資源提供者（例えば、電力会社）のためのウェブサイト、サーバ、クラウドホストデータベース、又は他のデータソースにアクセスすることによって取得され得、又はエネルギー混合データは、資源提供者から規則的な間隔で受信され得る。この例では、資源提供者は、定期的にエネルギー混合データを公開又は更新し得、それらは次いで顧客（例えば、システム６００）にプッシュされる。したがって、最新のエネルギー混合データは、生成された排出量のより正確な計算を提供するために、故障に起因して生成された排出量を計算するときに利用され得る。エネルギー混合データを判定して更新することで、より高排出量の故障をより正確に識別し、優先順位を付けることができる。例えば、日中に、比較的高い割合の電気が太陽光発電を使用して生成されるとき、建物デバイスが過剰な天然ガスを燃焼させることにつながる第１の故障は、建物デバイスが電気を浪費することにつながる第２の故障よりも優先され得る。夜間に、より高いパーセンテージの電気が石炭燃焼によって生成されるとき、第２の故障は、第１の故障よりも優先され得る。

ステップ７１５において、故障の検出及び／又は故障に起因して生成された計算された排出量に基づいて、自動応答が開始される。上で考察されたように、自動応答は、検出された故障に関する作業指図を生成し、故障を補正するための技術者からの訪問を自動的にスケジュールすることを含み得る。作業指図は、故障のタイプ、故障が発生しているデバイスのデバイス及び場所、故障が検出された日時、並びに故障を診断及び補正する際に技術者を支援し得る任意の他の関連する故障情報を示し得る。自動応答はまた、各故障によって生成される排出量の相対量に基づいて、複数の作業指図の優先順位付けを含み得る。いくつかの実施形態では、作業指図を生成することはまた、修理サービス又は技術者訪問を自動的にスケジュールすることを含んでもよい。例えば、作業指図ログ又は技術者スケジュールは、技術者が故障を補正することができる時間期間を識別及び予約するために参照されてよい。いくつかの実施形態では、作業指図が作成されたという通知もまた、割り当てられた技術者に関連付けられたデバイスに送信され得る。

いくつかの実施形態では、自動応答は、警告を生成することと（例えば、ユーザデバイスに）送信することとを含み、警告は、故障を識別し、故障に起因して生成された排出量を示す。例えば、通知は、テキストメッセージ、電子メール、音声呼、プッシュ通知を介して、又は他の方法によって、（例えば、技術者又は建物管理者に関連付けられた）ユーザデバイスに送信され得る。いくつかの実施形態では、自動応答は、故障及び影響を受けたデバイスを識別する情報を表示する１つ以上のユーザインターフェースを生成することと、ステップ７１３で計算された排出情報を提示することとを含む。例えば、ユーザインターフェースは、故障情報を提示するためのグラフ、テキスト、画像、及び他の要素を含むユーザデバイス６３２を介して提示することができる。追加のユーザインターフェースは、以下でより詳細に説明される。

図７Ｄは、方法７００を更に示すフローチャート７７０である。故障検出ルール７７２は、例えば、上述したように、定期的な間隔で作成され、繰り返し実行される。故障持続時間７７４は、故障検出ルールがアクティブな故障をどのくらい長く識別し続けるかに基づく。故障排出方程式７７６は、故障検出ルール、故障持続期間、及び設備に関する情報（例えば、設備仕様７７８、センサ及び他のフィードバック機構からのデータ点７８０、並びに設備に関連する定数７８２）を受信する。故障排出方程式７７６は、浪費された各タイプのエネルギー量７８４（例えば、電気、熱など）を識別する。排出係数７８６（例えば、浪費されたエネルギータイプの単位当たりに生成された排出量）は、資源提供者によって受信され、故障及び炭素排出削減可能性７８８に起因して生成された排出量を計算するために使用される。いくつかの実施形態では、故障排出計算は、各エネルギー源の単位当たりのコストの代わりに、各エネルギー源の単位当たりの排出量が総排出量を計算するために使用されることを除いて、故障コスト計算と実質的に類似している。

ここで図８を参照すると、いくつかの実施形態による、故障検出ルールを確立するための例示的なインターフェース８００が示されている。本明細書で考察される他の例示的なインターフェースと同様に、インターフェース８００は、ＵＩ生成器６２０によって生成され得、ユーザデバイス６３２を介して提示され得る。インターフェース８００は、ユーザが、多数の他の特徴の中で、新たな故障検出ルールを入力し、既存の故障検出ルールを修正し、かつ／又はルールを試験及び検証することを可能にし得る。

インターフェース８００は、様々なタスクを実施するために、様々なページを表示するために選択することができるいくつかのタブを含むように示されている。例えば、ユーザは、新たなシステムレベルの故障ルールを定義する、又は既存のシステムレベルの故障ルールを修正するために、「システム故障ルール」を選択し得る。示される例では、ユーザは、「設備故障ルール」タブ８０２を選択して、設備故障ルールを作成した。インターフェース８００は、新たなルールを定義／作成するときにユーザが投入することができるいくつかのフィールドを含み、「方程式名」（すなわち、故障名）及びルールの説明を含む。

投入のための他のフィールドには、関連する設備カテゴリ（「空気処理ユニット」）、設備タイプ（「混合シングル空気ダクト」）、故障カテゴリ（「動作」）、パラメータ値（「時間後」）、故障検出ステータスの表示（「有効」）、故障のタグ（「カスタム」）、故障バージョン（「ベースライン」）、ルールカテゴリ（「エネルギー」）、ルール機能（「時間遅延ベース」）、時間遅延（「１０分」）、及び故障優先度（「高い」）が含まれる。いくつかの実施形態では、フィールドの少なくとも一部分は、新たな故障検出ルールを作成する前に必要とされ得る。例えば、ユーザは、「設備カテゴリ」フィールドへの投入を要求され得るが、「時間遅延」フィールドへの投入は要求され得ない。

インターフェース８００はまた、「方程式ステートメント」フィールド８０４を含み、ユーザは、故障ルールを定義する方程式又は式（例えば、ブール方程式）を入力し得る。この例では、ユーザは「（供給空気ファンステータス＝＝０）ＡＮＤ（供給空気流量＝０）」と入力している。したがって、指定された空気処理ユニットの供給空気ファンステータス及び供給空気流速の両方がゼロである場合、故障ルールは「真」とみなされる。インターフェース８００はまた、フィールド８０４に方程式を入力又はそれを修正するために選択することができるいくつかの演算子及び／又はアイコンを含み得る。例えば、ユーザは、方程式を定義するために、演算子のセットからＡＮＤ、ＮＯＴ、ＯＲなどを選択することができる。

方程式又は式が入力されると、ユーザは、新たに入力された故障ルールパラメータを使用して様々な動作を実施するために、アイコン８０６のうちの１つを選択してもよい。例えば、ユーザは、新たなルールを追加し得るか、又は既存のルールを更新し得る。ユーザはまた、選択されたルールを削除するか、又は取消を選択して、インターフェース８００のフィールドをクリアすることができる。アイコン８０６はまた、新たな故障検出ルールを試験及び／又は検証するための要素（例えば、ボタン）、設備を新たなルールにマッピングすること、コスト又は排出量の式をルールにマッピングすること、ルールを保存することなどを含む。

ここで図９を参照すると、いくつかの実施形態による、故障データを視認するためのプロセス９００が示されている。インターフェース９００は、システム（例えば、システム６００）で現在アクティブな故障のリスト９０２を含むように示されている。リスト９０２は、設備識別子、設備が位置する空間の識別子、故障名、故障が検出された日時、故障カテゴリ、優先度、故障の持続時間、及び電気エネルギー、熱エネルギー、及び故障が補正された場合、コスト削減可能性若しくは排出低減可能性を示し得る。

第１の故障を例に挙げると、設備ＲＭＵ－Ａ８－ＢＬ－Ｖ０３は、２０２０年３月４日１７：００に検出された「ＶＡＶ低供給空気流量－再加熱」故障が発生していることが示されている。この故障は快適性に関連しており、中程度の優先度の故障として識別されている。いくつかの実施形態では、ユーザは、ハイパーリンクを含み得る故障名（すなわち、識別子）をクリックし得、それによって、故障に関連する追加の情報を表示する第２のユーザインターフェースにナビゲートし得る。例えば、第２のユーザインターフェースは、ユーザが、作業指図を生成することによって、故障を認識する、かつ／又は故障に応答することを可能にし得る。

ここで図１０を参照すると、いくつかの実施形態による、作業指図管理のための例示的なインターフェース１０００が示されている。インターフェース１０００から、ユーザは、様々なオープン及び／又は履歴作業指図を生成及び／又は視認することができ得る。例えば、インターフェース１０００は、特定のシステム（例えば、システム６００）のための全ての作業指図をリストする作業指図リスト１００２を含む。リスト１００２は、作業指図番号、作業指図に関連付けられたデバイス若しくは建物の場所、建物識別子、設備タイプ及び／又は識別子、要求説明、作成日時、ステータス、並びに任意の利用可能な作業指図文書などの情報を含み得る。ユーザはまた、検索バーに検索用語を入力して、リスト１００２を検索及び／又はフィルタリングすることができ得る。

一例として、リスト１００２の第１の作業指図は、「建物３」の空気処理ユニットに関する作業指図１３７である。リスト１００２から作業指図１３７を選択することによって、追加の作業指図の詳細を表示する二次インターフェース１００４が提示され得る。例えば、インターフェース１００４は、デバイスが位置する場所、建物、フロア、ウィング、及び／又は部屋、並びに作業指図のカテゴリ、設備識別子、要求の説明、及びタスク詳細を表示する。ユーザは、「タスク詳細を追加」ボタンを選択することによってタスク詳細を追加することができ得、かつ／又は「文書を選択」フィールドを介してサポートしている文書をアップロードすることができ得る。ユーザはまた、「作業指図をエクスポート」アイコン１００６を介して、１つ以上の選択された作業指図を（例えば、技術者に関連付けられたユーザデバイス、リモート作業指図システムなどに）エクスポートすることができ得る。

ここで図１１を参照すると、いくつかの実施形態による、データ点の読み取り頻度を設定するための例示的なデータ点設定インターフェース１１００が示されている。データ点は、故障検出ルールが故障を検出したかどうかを判定するために使用することができる。ユーザは、データ点の読み取りが行われるデバイス又はセンサを識別するデータ点名１１０２を入力することができる。ユーザはまた、単位タイプ１１０４及び点の役割１１０６を選択して、行われている測定のタイプを識別することができる。ユーザは、データ点の読み取り頻度１１０８を選択し得、これにより、読み取り値がセンサ又は他のデバイスからどのくらいの頻度で取られるかを判定する。いくつかの実施形態では、システム又はサブシステム内の全てのデータ点は、コスト又は排出量計算が、多量の異なる読み取り頻度を考慮せずに実施され得るように、同じ読み取り頻度を有し得る。ユーザはまた、センサ又はデバイスが出力するユニットタイプ１１１０を選択し得る。データ点には単位タイプが含まれているため、故障コスト又は排出方程式は、同じ単位タイプの全ての読み取り値を同じ単位に容易に変換することができる。代替的に、データ点自体を直ちに共通の単位に変換することができる。例えば、一部のデバイスが圧力をインチ水柱単位で読み取り、他のデバイスは圧力をｐｓｉ単位で読み取る場合、ユーザは、データ点内のセンサ又はデバイスによって出力された単位を識別し得、データ点は、測定値を故障コスト又は排出方程式に報告する前に、インチ水柱単位で取られた測定値を自動的に変換し、それらをｐｓｉに変換し得る。したがって、故障コスト又は排出方程式は、同じ測定単位で所与の単位タイプの全ての読み取り値を受信する。

図１２～図１４は、故障ルール及び故障コスト方程式又は故障排出方程式を設定するためのインターフェース１２００、１３００、１４００を示す。ここで図１２を参照すると、インターフェース１２００は、故障名１２０４及び対応する故障説明１２０６を含む故障リスト１２０２を含む。リスト内の各故障は、エントリを編集するための対応する編集ボタン、例えば、故障情報編集ボタン１２０８、建物設備を対応する故障ルールにマッピングするためのエントリフォームにリンクする設備マッピングボタン１２１０、電気コスト方程式を設定するためのエントリフォームにリンクする電気コストボタン１２１２、及び熱コスト方程式を設定するためのエントリフォームにリンクする熱コストボタン１２１４を有する。いくつかの実施形態では、各エントリはまた、排出方程式ボタンを含み得る。他の実施形態では、排出量計算は、電気及び熱コスト方程式エントリフォームに含まれ得る。

ここで図１３を参照すると、インターフェース１３００は、故障コスト又は排出方程式を入力するためのエントリフォームであり、図８と実質的に類似している。インターフェース１３００には、例えば、リスト１２０２から故障のうちの１つの熱コストボタン１２１４を選択することによってアクセスすることができる。いくつかの実施形態では、故障コスト又は排出方程式に送信されたデータ点は、方程式に送信される前にデータ点関数によって変換されるので、全て同じである。これらの実施形態では、ユニットドロップダウン１３０２は、設備カテゴリ、故障検出のタイプ、及び／又はルールタイプに基づいて特定のユニットにデフォルト設定され得、インターフェース１３００内でユーザが選択可能でない場合がある。

ここで図１４を参照すると、インターフェース１４００は、実行された故障検出並びにコスト方程式及び排出方程式によって生成された故障のリストである。インターフェースは、インターフェース９００と実質的に類似しているが、各故障の計算された炭素排出コスト１４０２も含む。

ここで、図１５Ａ～図１５Ｄを参照すると、いくつかの電気コストルール及び熱コストルールを識別する表１５００が示されている。行１は、高静圧故障が発生している空気処理ユニットの電気コストルールと熱コストルールとを含む。電気コストルールは、次の方程式に従って、故障に起因して浪費されたｋＷｈの量を判定する。
供給空気流量＊（供給空気静圧－供給空気圧設定値）／（６３５６＊０．７５））＊０．７４６））
行１の電気コストルールは、供給空気流量、及び供給空気圧設定値と測定された静的空気圧との差に依存する。計算された電気浪費の調整は、ファン効率と圧力センサ及び流量センサで使用される測定単位とに基づいて行うことができ、並びに馬力からキロワット時単位の総電気エネルギー浪費を出力するように変換することもできる。

熱コストルールは、次の方程式に従って、故障に起因して浪費されたｋＢＴＵの量を判定する。
（０．３＊１．０８＊（加熱出力／１００）＊供給空気流量＊（供給空気温度－混合空気温度）／１０００））
行１の熱コストルールは、供給空気流量、加熱出力パーセンテージ、及び供給空気温度と空気処理ユニット内の混合空気温度との差に依存する。計算された熱浪費の調整は、総熱エネルギー浪費量をｋＢＴＵで出力するために、空気流センサで使用される測定単位と想定される浪費のパーセンテージとに基づいて行うことができる。

行２は、エネルギー削減経済サイクルで動作しない故障が発生している空気処理ユニットの電気コストルールを含む。電気コストルールは、次の方程式に従って、故障に起因して浪費されたｋＷｈの量を判定する。
（（（４．５＊外気流量＊外気エンタルピー）／１２０００）＊０．８５）
行２の電気コストルールは、外気流量及び外気エンタルピーに依存する。計算された電気浪費の調整は、総電気エネルギーの浪費をキロワット時単位で出力するために、空気流センサ及びエンタルピーセンサによって使用される測定単位に基づいて行われる。

行３は、全負荷で恒久的に動作する故障が発生している空気処理ユニットの電気コストルールと熱コストルールとを含む。電気コストルールは、次の方程式に従って、故障に起因して浪費されたｋＷｈの量を判定する。
（（（供給空気流量＊（供給空気静圧－供給空気圧力設定値）／（６３５６＊０．７５））＊０．７４６）＋（（供給空気流量／４００）＊０．０３＊０．８５））
行３の電気コストルールは、供給空気流量、及び供給空気圧設定値と測定された静的空気圧との差に依存する。計算された電気浪費の調整は、チラープラント効率と圧力センサ及び流量センサで使用される測定単位とに基づいて行うことができ、並びに馬力からキロワット時単位の総電気エネルギー浪費を出力するように変換することもできる。

熱コストルールは、次の方程式に従って、故障に起因して浪費されたｋＢＴＵの量を判定する。
（（０．３＊１．０８＊（加熱出力／１００）＊供給空気流量＊（供給空気温度－混合空気温度））／１０００）
行３の熱コストルールは、供給空気流量、加熱出力パーセンテージ、及び供給空気温度と空気処理ユニット内の混合空気温度との差に依存する。計算された熱浪費の調整は、総熱エネルギー浪費量をｋＢＴＵで出力するために、空気流センサで使用される測定単位と想定される浪費のパーセンテージとに基づいて行うことができる。

行４は、低ゾーン温度故障が発生している空気処理ユニットの電気コストルールを含む。電気コストルールは、次の方程式に従って、故障に起因して浪費されたｋＷｈの量を判定する。
（（（（１．０８＊供給空気流量＊（空間温度設定値－空間温度））／１２０００）＊０．８５）＊（冷却出力／冷却出力））
行４の電気コストルールは、供給空気流量、及び空間温度設定値と測定された空間温度との間の差に依存する。計算された電気浪費への調整は、総電気エネルギーの浪費をキロワット時単位で出力するために、空気流センサによって使用される測定単位、チラープラント効率、及び空気処理ユニットの冷却出力パーセンテージに基づいて行われる。

行５は、同時に加熱及び冷却の故障が発生している空気処理ユニットの電気コストルールと熱コストルールとを含む。電気コストルールは、次の方程式に従って、故障に起因して浪費されたｋＷｈの量を判定する。
（（供給空気流量／４００）＊（冷却出力／１００）＊０．８５＊０．８）
行５の電気コストルールは、供給空気流量及び冷却出力パーセンテージに依存する。計算された電気浪費の調整は、チラープラント効率、空気流センサによって使用される測定単位、及び信頼係数に基づいて行うことができ、総電気エネルギー浪費はキロワット時単位で出力される。

熱コストルールは、次の方程式に従って、故障に起因して浪費されたｋＢＴＵの量を判定する。
（（（加熱出力／１００）＊Ｃｏｎｓｔ（加熱容量（ＭＢＨ）））＊０．８５＊０．８）
行５の熱コストルールは、加熱出力パーセンテージ及び加熱容量定数に依存する。計算された熱浪費の調整は、ボイラ効率及び信頼係数に基づいて行うことができ、総熱エネルギー浪費量はｋＢＴＵで出力される。

行６は、低二酸化炭素故障が発生している空気処理ユニットの電気コストルールと熱コストルールとを含む。電気コストルールは、次の方程式に従って、故障に起因して浪費されたｋＷｈの量を判定する。
（（１．０８＊（供給空気流量＊（（外気ダンパ出力－２０）／１００））＊（外気温度－供給空気温度）／１２０００）＊０．８５）
熱コストルールは、次の方程式に従って、故障に起因して浪費されたｋＢＴＵの量を判定する。
（（１．０８＊（供給空気流量＊（外気ダンパ出力－２０））＊（供給空気温度－外気温度））／１０００）
行６の電気及び熱コストルールは、供給空気流量、外気ダンパ出力パーセンテージ－２０パーセント、及び外気温度と供給空気温度との間の差に依存する。計算された電気浪費及び熱浪費の調整は、空気流センサ及び温度センサによって使用される測定単位に基づいて行うことができる。総電気エネルギー浪費量はキロワット時単位で出力され、総熱エネルギー浪費量はｋＢＴＵ単位で出力される。

行７は、低ゾーン温度故障が発生しているファンコイルユニットの電気コストルールを含む。電気コストルールは、次の方程式に従って、故障に起因して浪費されたｋＷｈの量を判定する。
（（（１．０８＊Ｃｏｎｓｔ（ＦＣＵＤＥＳＩＧＮＦＬＯＷ）＊（ゾーン温度設定値－ゾーン温度））／１２０００）＊０．８５）＊（冷却出力／冷却出力））
行７の電気コストルールは、設計フロー定数、ゾーン温度設定値と測定ゾーン温度との間の差、及び冷却出力パーセンテージに依存する。計算された電気浪費の調整は、総電気エネルギー浪費量をキロワット時単位で出力するために、チラープラント効率と、温度センサによって使用される測定単位とに基づいて行われる。

行８は、外気及び戻り空気の両方がオープンである故障が発生している屋上ユニットの電気コストルールと熱コストルールとを含む。電気コストルールは、次の方程式に従って、故障に起因して浪費されたｋＷｈの量を判定する。
（（（１．０８＊（供給空気流量＊（外気ダンパ出力－２０））＊（外気温度－供給空気温度））／１２０００）＊０．８５））
熱コストルールは、次の方程式に従って、故障に起因して浪費されたｋＢＴＵの量を判定する。
（（１．０８＊（供給空気流量＊（外気ダンパ出力－２０））＊（供給空気温度－外気温度））／１０００）
行８の電気及び熱コストルールは、供給空気流量、外気ダンパ出力パーセンテージ－２０パーセント、及び外気温度と供給空気温度との間の差に依存する。計算された電気浪費及び熱浪費の調整は、空気流センサ及び温度センサによって使用される測定単位に基づいて行うことができる。総電気エネルギー浪費量はキロワット時単位で出力され、総熱エネルギー浪費量はｋＢＴＵ単位で出力される。

行９は、低ゾーン温度故障が発生している屋上ユニットの電気コストルールを含む。電気コストルールは、次の方程式に従って、故障に起因して浪費されたｋＷｈの量を判定する。
（（（１．０８＊供給空気流量＊（ゾーン平均温度設定値－ゾーン平均温度）））／１２０００）＊１．２）
行９の電気コストルールは、供給空気流量、ゾーン温度設定値と測定されたゾーン温度との間の差、及び冷却出力パーセンテージに依存する。計算された電気浪費の調整は、総電気エネルギー浪費量をキロワット時単位で出力するために、屋上ユニット効率と、温度センサ及び空気流センサによって使用される測定単位とに基づいて行われる。

行１０は、ポンプ動作が高速である故障が発生している冷却水ポンプの電気コストルールを含む。電気コストルールは、次の方程式に従って、故障に起因して浪費されたｋＷｈの量を判定する。
（ポンプＶＳＤ電力）－（ポンプＶＳＤ電力／（（（ポンプ速度駆動出力／Ｃｏｎｓｔ（高速閾値））＊（ポンプ速度駆動出力／Ｃｏｎｓｔ（高速閾値））＊（ポンプ速度駆動出力／Ｃｏｎｓｔ（高速閾値）））））
行１０の電気コストルールは、可変速駆動電力、可変速駆動出力、及び高速閾値定数に依存する。計算された電気浪費の調整は、総電気エネルギーの浪費をキロワット時単位で出力するために、ワットメータによって使用される測定単位に基づいて行われる。

行１１は、プラント効率の悪い故障が発生しているチラーの電気コストルールを含む。電気コストルールは、次の方程式に従って、故障に起因して浪費されたｋＷｈの量を判定する。
（（総プラントルームシステム効率－（Ｃｏｎｓｔ（ＣＨＷプラントシステム効率－設計）＊Ｃｏｎｓｔ（設計効率乗数）））＊総チラー負荷））
行１１の電気コストルールは、総プラントルームシステム効率、プラントルームシステム効率定数、及び設計効率乗数定数に依存する。総電気エネルギー浪費量は、キロワット時単位で出力される。

行１２は、復水器水ヘッダ供給温度が高い故障が発生しているチラーの電気コストルールを含む。電気コストルールは、次の方程式に従って、故障に起因して浪費されたｋＷｈの量を判定する。
（（復水器水ヘッダ供給温度－２９．５）＊０．０３＊総チラー電力）
行１２の電気コストルールは、復水器水ヘッダ供給温度及び総チラー電力に依存し、温度センサの測定単位に基づいて調整される。総電気エネルギー浪費量は、キロワット時単位で出力される。

行１３は、空気処理ユニットの戻り空気温度が低すぎる故障が発生しているチラーの電気コストルールを含む。電気コストルールは、次の方程式に従って、故障に起因して浪費されたｋＷｈの量を判定する。
（０．０００２＊（Ｃｏｎｓｔ（ＲＡＴ下限）－戻り空気温度）＊（（４０／５０）＊Ｃｏｎｓｔ（ＡＨＵ設計空気流）））

行１３の電気コストルールは、戻り空気温度、下限温度定数、及び設計空気流定数に依存する。計算された電気浪費の調整は、総電気エネルギーの浪費をキロワット時単位で出力するために、温度センサによって使用される測定単位に基づいて行われる。

電気コストルール及び熱コストルールのいずれかは、浪費されたエネルギーの正の値を返す動作条件のみが故障として識別されるように、ＭＡＸ関数を含み得る。

いくつかの実施形態では、故障排出方程式は、上記の電気コストルール及び熱コストルールによって判定された値を使用することができる。例えば、総電気エネルギー浪費量は、生成された電力のｋＷｈ当たりの炭素排出量によって判定される第１の炭素排出係数によって乗算することができる。総熱エネルギー浪費量は、熱エネルギーのｋＢＴＵ当たりに生成される炭素排出量によって判定される第２の炭素排出係数によって乗算することができる。いくつかの実施形態では、故障排出方程式は、浪費されたエネルギー量を最初に計算し、浪費されたエネルギー量を追加の方程式に入力することなく、生成された排出量を直接判定することができる。いくつかの実施形態では、故障排出モデルは、生成された排出量を予測するために、将来に延びる推定される時間期間にわたって分析され得る。いくつかの実施形態では、仮想メータ又は仮想データ点からのデータのみならず、建物デバイスデータを例えばデジタルツインで使用して、傾向を判定し、将来の故障、並びに将来の故障から予想される排出量を予測するために使用してもよい。予測された故障に起因する予測される排出量は、以前のデータ読み取り値からの傾向に基づいて判定することができる。予測された故障及び現在の故障には、予想されるかつ／又は実際の排出量に基づいて優先度値が割り当てられ得る。例えば、大量の排出量を生成することが予想される予測される故障は、比較的低量の排出量を生成している現在の故障よりも優先されてよい。現在の故障を改善するために修理が実施される前に、予測された故障を防止するための予防保守点検が実施されてもよい。

ここで図１６を参照すると、いくつかの実施形態による、エネルギー源のコスト及び炭素排出量を入力するための商品レート設定インターフェース１６００が示されている。ユーザは、様々な燃料源の測定単位、各エネルギー源の単位当たりのコスト、及び各燃料源の単位当たりの排出量（図示せず）を入力することができる。ユーザは、電力単位当たりの排出係数を入力することができ、これは、電力浪費に起因して生成された炭素排出量を判定するために使用することができる。いくつかの実施形態では、各エネルギー源の単位当たりのコスト及び排出量は、資源提供者から手動で又は定期的に自動的に検索することができる。例えば、電気の単位当たりのコスト及び生成された排出量は、時刻、季節、エネルギーｍｘなどに応じて変化し得る。

ここで図１７を参照すると、いくつかの実施形態による、故障情報を視認するためのインターフェース１７００が示されている。故障検出ルールは、空気処理ユニット（ＡＨＵ）がエネルギー削減経済サイクルで稼働していないＡＨＵの故障を検出することに関している。上部のグラフ１７０２は、ＡＨＵによってサービス提供される空間が占有されないことが予想されるときに、ＡＨＵが定期的にオフになって電気を保存するようにプログラムされていることを示す。ＡＨＵ出力グラフ１７０４及びＡＨＵステータスグラフ１７０６は、ＡＨＵが電源を切るようにスケジュールされた期間中、アクティブなままであったことを示す。例えば、上部のグラフ１７０２によれば、ＡＨＵは、３月７日の１０：００ＡＭの前、並びに３月８日の６：００ＡＭ～９：００ＡＭ、及び９：３０ＰＭの後に電源がオンにされた。

故障検出インターフェース１７００はまた、異なる建築設備間の関係が識別される関係ウィンドウ７０８を含む。関係には、ＡＨＵにサービスを提供する設備、ＡＨＵ自体がサービスを提供する設備、ＡＨＵがサービスを提供する建物空間、及びこれも同じ建物空間にサービスを提供する他のデバイスが含まれ得る。いくつかの実施形態では、故障コスト及び排出方程式は、故障に起因して生成されたコスト及び排出量を判定する際に、これらの関係を考慮に入れる。例えば、故障検出インターフェース１７００は、３月７日の約９：３０ＰＭ～約１０：００ＰＭにＡＨＵがオンになるようにスケジュールされたときに、ＡＨＵが電源オフされたことを示している。ＡＨＵの電源がオフになっているため、この故障は理論的には、その時間期間中にＡＨＵによって生成されたコストと排出量とを低減する可能性がある。しかしながら、ＡＨＵ及び第２のＡＨＵが同じ建物空間にサービスを提供する場合、第２のＡＨＵは、第１のＡＨＵの故障を補完するために追加の電気を使用し得る。したがって、故障コスト及び排出方程式は、コストと故障に起因して生成された排出量とを判定するときに、第２のＡＨＵ上の増加した負荷を考慮に入れることができる。

ここで図１８を参照すると、インターフェース１８００は、様々な統計的故障データを示すビューのセットである。ビュー１８０２は、レベルごとの故障数及び持続時間を視覚的に表現したものである。各レベルについて、ボックスのサイズは故障の数を表し、ボックスの色は故障の平均持続時間を表す。ビュー１８０４は、設備カテゴリ（例えば、空気処理ユニット、チラー、供給ファンなど）ごとの各故障のパーセンテージを示す円グラフである。ビュー１８０６は、１日当たりの故障の総数を示す故障傾向グラフである。ビュー１８０８は、選択した時間期間内の上位５つの故障をリストしている。ユーザは、コスト、持続時間、又は数によって上位５つの故障を表示するかどうかを選択することができる。

ここで図１９を参照すると、インターフェース１９００は、様々な統計的故障データを示すビューのセットである。ビュー１９０２は、故障のタイプ（例えば、快適性故障、エネルギー故障、保守点検故障、及びその他の故障）によって故障のセットを分類する。ビュー１９０４は、様々な場所の集合的な故障コストをリストしている。ビュー１９０６及び１９０８は、建物及び敷地ごとの集合的な故障コストと故障数とをそれぞれリストしている。

例示的な実施形態の構成
様々な例示的な実施形態に示されるシステム及び方法の構築及び配設は、単なる例示である。本開示では、いくつかの実施形態のみが詳細に説明されてきたが、多くの修正が可能である（例えば、様々な要素のサイズ、寸法、構造、形状、及び割合、パラメータの値、取り付け構成、材料の使用、色、配向などの差異）。例えば、要素の位置は、反転させることができ、又は別様に変化させ得、個別要素の性質若しくは数、又は位置は、変更すること、又は変化させ得る。したがって、そのような全ての修正は、本開示の範囲内に含まれることが意図される。任意のプロセス又は方法ステップの順番又はシーケンスは、代替実施形態に従って、変更又は再順序付けされ得る。他の置換、修正、変更、及び省略は、本開示の範囲から逸脱することなく、例示的な実施形態の設計、動作条件、及び配置において行われ得る。

本開示は、様々な動作を達成するための任意の機械可読媒体上の方法、システム、及びプログラム製品を企図する。本開示の実施形態は、既存のコンピュータプロセッサを使用して、又はこの目的若しくは別の目的のために組み込まれた適切なシステムのための専用コンピュータプロセッサによって、又は配線接続されたシステムによって実装され得る。本開示の範囲内の実施形態は、その上に記憶された機械実行可能命令又はデータ構造を搬送するか又は有するための機械可読媒体を含むプログラム製品を含む。そのような機械可読媒体は、プロセッサを備えた汎用若しくは専用のコンピュータ又は他の機械によってアクセス可能な任意の利用可能な媒体であり得る。例として、そのような機械可読媒体は、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＣＤ－ＲＯＭ、若しくは他の光ディスク記憶装置、磁気ディスク記憶装置若しくは他の磁気記憶デバイス、又は所望のプログラムコードを機械実行可能命令若しくはデータ構造の形態で搬送又は記憶するために使用でき、かつプロセッサを備えた汎用若しくは専用コンピュータ若しくは他の機械によってアクセスできる任意の他の媒体を含むことができる。情報がネットワーク又は別の通信接続（有線、無線、又は有線若しくは無線の組み合わせのいずれか）を介して機械に伝送又は提供されるとき、機械は、接続を機械可読媒体として適切にみなす。したがって、このような接続部は、適切に機械可読媒体と称される。上記の組み合わせも、機械可読媒体の範囲内に含まれる。機械実行可能命令は、例えば、汎用コンピュータ、専用コンピュータ、又は専用処理機械に、特定の機能又は機能群を実行させる命令及びデータを含む。

図は、方法ステップの特定の順序を示しているが、ステップの順序は、描写されたものとは異なってもよい。また、２つ以上のステップを同時に、又は部分的に同時に実行され得る。このような変形形態は、選択されたソフトウェア及びハードウェアシステム、並びに設計者の選択に依存する。全てのそのような変形形態は、本開示の範囲内である。同様に、ソフトウェアの実装は、様々な接続ステップ、処理ステップ、比較ステップ、及び判定ステップを達成するために、ルールベースのロジック及び他のロジックを有する標準的なプログラミング技術によって達成され得る。

Claims (19)

1. 建物管理システム（ＢＭＳ）であって、
   命令が記憶された１つ以上のメモリデバイスを備え、
   前記命令は、１つ以上のプロセッサによって実行されたときに、前記１つ以上のプロセッサに、
   複数の建物デバイスから動作データを取得することと、
   前記動作データを使用して１つ以上の故障検出ルールを評価して、前記複数の建物デバイスのうちの少なくとも１つの建物デバイスに故障状態が発生しているかどうかを判定することと、
   前記複数の建物デバイスのうちの少なくとも１つの建物デバイスに前記故障状態が発生していると判定することに応答して、前記故障状態に関連付けられた故障排出モデルに基づいて、前記故障状態に起因して生成された炭素排出量を判定することと、
   前記故障状態に関連付けられた前記炭素排出量に基づいて、自動応答を開始することと
   を含む動作を実施させ、
   前記故障状態に起因して生成された炭素排出量を判定することは、第１の建物デバイスにおける故障状態を補償するべく第２の建物デバイスを動作させることによって生成された追加の炭素排出を予測することを含み、
   前記自動応答は、前記第１の建物デバイスにおける故障状態を補償するべく前記第２の建物デバイスを動作させることを含む、ＢＭＳ。
2. 前記動作は、
   ユーザ入力に基づいて、前記１つ以上の故障検出ルールのうちの少なくとも１つの故障検出ルールを取得することと、
   前記１つ以上の故障検出ルールを前記複数の建物デバイスにマッピングすることと
   を更に含む、請求項１のＢＭＳ。
3. 前記ユーザ入力は、
   前記１つ以上の故障検出ルールのうちのある故障検出ルールに関連付けられた故障の説明と、
   前記故障の優先度と、
   前記故障検出ルールを定義する方程式と
   を含む、請求項２のＢＭＳ。
4. 前記動作は、前記動作データに関連付けられた測定単位に基づいて前記故障排出モデルを修正することを更に含み、
   前記故障排出モデルは、前記故障排出モデルの各項が共通の測定単位によって定義されるように修正される、請求項１のＢＭＳ。
5. 前記動作は、前記故障状態に関連付けられた前記故障排出モデルに基づいて、前記故障状態に起因して浪費されたエネルギー量を計算することを更に含み、
   前記生成された炭素排出量は、前記浪費されたエネルギー量と、前記浪費されたエネルギーを生成するために使用されたエネルギー源を含むエネルギー混合情報とに基づいて判定される、請求項１のＢＭＳ。
6. 前記自動応答はさらに、前記故障状態を補正するための作業指図を生成することを含み、
   前記作業指図は、前記複数の建物デバイスのうちの前記少なくとも１つの建物デバイスに前記故障状態が発生していることを識別し、かつ、前記故障の説明と、前記複数の建物デバイスのうちの前記少なくとも１つの建物デバイスの場所とを含む、請求項３のＢＭＳ。
7. 前記自動応答はさらに、
   前記故障状態に基づいてグラフィカルユーザインターフェースを生成することであって、前記グラフィカルユーザインターフェースは、前記故障状態の指標と、前記複数の建物デバイスのうちの前記少なくとも１つの建物デバイスに前記故障状態が発生していることの指標と、前記生成された炭素排出の指標とを含むことと、
   ユーザデバイスを介して前記グラフィカルユーザインターフェースを表示することと
   を含む、請求項１のＢＭＳ。
8. 前記自動応答はさらに、
   前記故障状態の検出に基づいて警告を生成することであって、前記警告は、前記故障状態の優先度の指標を含み、前記優先度は、前記故障状態に起因して生成された前記炭素排出量に基づいて判定されることと、
   前記警告をユーザデバイスに送信することと
   を含む、請求項１のＢＭＳ。
9. 建物管理システム（ＢＭＳ）における故障状態に起因する炭素排出量を判定する方法であって、
   １つ以上のプロセッサが、複数の建物デバイスから動作データを取得することと、
   １つ以上のプロセッサが、前記動作データを使用して１つ以上の故障検出ルールで評価して、前記複数の建物デバイスのうちの少なくとも１つの建物デバイスに前記故障状態が発生しているかどうかを判定することと、
   １つ以上のプロセッサが、前記複数の建物デバイスのうちの少なくとも１つの建物デバイスに前記故障状態が発生していると判定することに応答して、前記故障状態に関連付けられた故障排出モデルに基づいて、前記故障状態に起因して生成された炭素排出量を判定することと、
   １つ以上のプロセッサが、前記故障状態に関連付けられた前記炭素排出量に基づいて自動応答を開始することと
   を含み、
   前記故障状態に起因して生成された炭素排出量を判定することは、第１の建物デバイスにおける故障状態を補償するべく第２の建物デバイスを動作させることによって生成された追加の炭素排出を予測することを含み、
   前記自動応答は、前記第１の建物デバイスにおける故障状態を補償するべく前記第２の建物デバイスを動作させることを含む、方法。
10. １つ以上のプロセッサが、ユーザデバイスへのユーザ入力を介して、前記１つ以上の故障検出ルールのうちの少なくとも１つの故障検出ルールを受信することと、
    １つ以上のプロセッサが、前記１つ以上の故障検出ルールを前記複数の建物デバイスにマッピングすることと
    を更に含む、請求項９の方法。
11. 前記ユーザ入力は、
    前記１つ以上の故障検出ルールのうちのある故障検出ルールに関連付けられた故障の説明と、
    前記故障の優先度と、
    前記故障検出ルールを定義する方程式と
    を含む、請求項１０の方法。
12. １つ以上のプロセッサが、前記動作データに関連付けられた測定単位に基づいて前記故障排出モデルを修正することを更に含み、
    前記故障排出モデルは、前記故障排出モデルの各項が共通の測定単位によって定義されるように修正される、請求項９の方法。
13. １つ以上のプロセッサが、前記故障状態及びエネルギー混合情報に関連付けられた前記故障排出モデルに基づいて、前記故障状態に起因して浪費されたエネルギー量を計算することを更に含み、
    前記浪費されたエネルギー量は、前記故障状態の時間期間にわたって前記複数の建物デバイスのうちの前記少なくとも１つの建物デバイスによって消費された第１のエネルギー量と、通常動作の時間期間中に前記複数の建物デバイスのうちの前記少なくとも１つの建物デバイスによって消費された第２のエネルギー量とを比較することによって１つ以上のプロセッサにより判定され、
    前記生成された炭素排出量は、前記浪費されたエネルギー量と、前記浪費されたエネルギーを生成するために使用されたエネルギー源を含むエネルギー混合情報とに基づいて１つ以上のプロセッサにより判定される、請求項９の方法。
14. 前記第１の建物デバイスにおける故障状態に起因して浪費された前記エネルギー量は、前記第１の建物デバイスにおける故障のために前記第２の建物デバイスによって消費された追加のエネルギーを含む、請求項１３の方法。
15. 前記自動応答はさらに、１つ以上のプロセッサが前記故障状態を補正するための作業指図を生成することを含み、
    前記作業指図は、前記複数の建物デバイスのうちの前記少なくとも１つの建物デバイスに前記故障状態が発生していることを識別し、かつ、前記故障状態の説明と、前記複数の建物デバイスのうちの前記少なくとも１つの建物デバイスの場所とを含む、請求項９の方法。
16. 前記自動応答はさらに、
    １つ以上のプロセッサが前記故障状態に基づいてグラフィカルユーザインターフェースを生成することであって、前記グラフィカルユーザインターフェースは、前記故障状態の指標と、前記複数の建物デバイスのうちの前記少なくとも１つの建物デバイスに前記故障状態が発生していることの指標と、前記生成された排出の指標とを含むことと、
    １つ以上のプロセッサがユーザデバイスを介して前記グラフィカルユーザインターフェースを表示することと
    を含む、請求項９の方法。
17. 前記自動応答はさらに、
    １つ以上のプロセッサが前記故障状態の検出に基づいて警告を生成することであって、前記警告は、前記故障状態の優先度の指標を含み、前記優先度は、前記故障状態に起因して生成された前記炭素排出量に基づいて判定されることと、
    １つ以上のプロセッサが前記警告をユーザデバイスに送信することと
    を含む、請求項９の方法。
18. 故障検出のシステムであって、
    命令が記憶された１つ以上のメモリデバイスを備え、
    前記命令は、１つ以上のプロセッサによって実行されたときに、前記１つ以上のプロセッサに、
    ユーザ入力を介して少なくとも１つの故障検出ルールを受信することであって、前記少なくとも１つの故障検出ルールは、前記少なくとも１つの故障検出ルールを定義する方程式を含むことと、
    前記少なくとも１つの故障検出ルールを、１つ以上の建物デバイスにマッピングすることと、
    前記１つ以上の建物デバイスから動作データを取得することと、
    前記動作データを使用して前記少なくとも１つの故障検出ルールを評価して、前記１つ以上の建物デバイスのうちのある建物デバイスに故障状態が発生していることを判定することと、
    前記故障状態に関連付けられた故障排出モデルに基づいて、前記故障状態に起因して生成された炭素排出量を判定することと、
    前記故障状態に関連付けられた前記炭素排出量に基づいて、自動応答を開始することと
    を含む動作を実施させ、
    前記故障状態に起因して生成された炭素排出量を判定することは、第１の建物デバイスにおける故障状態を補償するべく第２の建物デバイスを動作させることによって生成された追加の炭素排出を予測することを含み、
    前記自動応答は、前記第１の建物デバイスにおける故障状態を補償するべく前記第２の建物デバイスを動作させることを含む、システム。
19. 前記自動応答はさらに、前記故障状態を補正するための作業指図を生成することを含み、
    前記作業指図は、前記建物デバイスに前記故障状態が発生していることを識別し、かつ、前記故障状態の説明と、前記建物デバイスの場所とを含む、請求項１８のシステム。