JP2021009694A

JP2021009694A - 予算制約を伴うモデル予測的メンテナンスシステム

Info

Publication number: JP2021009694A
Application number: JP2020109855A
Authority: JP
Inventors: ロバートディー．ターニー、; D Turney Robert; スディアール．シンハ、; R Sinha Sudhi; マイケルジェイ．ウェンゼル、; j wenzel Michael; モハマッドエヌ．エルブサット; N Elbsat Mohammad
Original assignee: Johnson Controls Technology Co
Current assignee: Johnson Controls Technology Co
Priority date: 2019-06-28
Filing date: 2020-06-25
Publication date: 2021-01-28
Also published as: JP7478792B2; JP2022188183A

Abstract

【課題】予算制約を伴うモデル予測的メンテナンスシステムを提供する。【解決手段】ビルディング機器のためのモデル予測的メンテナンス（ＭＰＭ）システム６０２は、ビルディング管理システム６０６から送信された情報を使用して、接続された機器６１０の性能を監視することと、気象サービス６０４からの天気予報を使用して、ビルディングの熱エネルギー負荷を予測することと、公益企業６０８から送信された価格データを使用して、電気又は他の資源のコストを予測することと、接続された機器６１０の動作、メンテナンス及び購入の経済的価値を最適化する最適化結果を生成することと、を実施する。【選択図】図８

Description

関連出願の相互参照
本出願は、２０１９年６月２８日出願の米国特許出願第１６／４５７，３１４号の利益及び優先権を主張する。米国特許出願第１６／４４９，１９８号は、２０１８年２月１３日出願の米国特許出願第１５／８９５，８３６号の一部継続出願であり、米国特許出願第１５／８９５，８３６号は、２０１７年５月２５日出願の米国仮特許出願第６２／５１１，１１３号の利益及び優先権を主張する。これらすべての特許出願の内容全体が参照により本明細書に組み入れられる。

本開示は、概して、ビルディング機器のためのメンテナンスシステムに関し、詳細には、予測最適化技法を使用してビルディング機器のための最適なメンテナンス戦略を決定するメンテナンスシステムに関する。

ビルディング機器は通常、ビルディング機器のためのメンテナンス戦略に従ってメンテナンスされる。メンテナンス戦略の１つのタイプは、ランツーフェール（ｒｕｎ−ｔｏ−ｆａｉｌ）である。ランツーフェール戦略は、故障が発生するまでビルディング機器が稼働できるようにする。この稼働期間中、ビルディング機器をメンテナンスするために、簡単な動作メンテナンスタスク（例えば、オイル交換）のみが実施される。

別のタイプのメンテナンス戦略は、予防的メンテナンスである。通常、予防的メンテナンス戦略は、製造された機器によって推奨される予防的メンテナンスタスクの組の実施を含む。予防的メンテナンスタスクは、通常、定期的な間隔（例えば、毎月、毎年など）で実施され、間隔は、動作の経過時間及び／又はビルディング機器の稼働時間に応じ得る。

本開示の一実装形態は、いくつかの実施形態によれば、ビルディング機器のためのモデル予測的メンテナンス（ＭＰＭ）システムである。ＭＰＭシステムは、いくつかの実施形態によれば、ビルディングでの可変の状態又は条件に影響を及ぼすようにビルディング機器を動作させるように構成された機器コントローラを含む。ＭＰＭシステムは、いくつかの実施形態によれば、最適化期間の継続期間にわたってビルディング機器を動作させるコストを予測するように構成された動作コスト予測器を含む。ＭＰＭシステムは、いくつかの実施形態によれば、１つ又は複数の予算制約を生成するように構成された予算マネージャを含む。ＭＰＭシステムは、いくつかの実施形態によれば、ビルディング機器に関するメンテナンス及び交換スケジュールを決定するために、１つ又は複数の予算制約を受ける目的関数を最適化するように構成された目的関数オプティマイザを含む。目的関数は、いくつかの実施形態によれば、ビルディング機器のメンテナンス及び交換コストと、ビルディング機器を動作させる予測されたコストとを含む。

いくつかの実施形態では、予算マネージャは、ペナルティコスト項を生成するように構成される。目的関数は、いくつかの実施形態によれば、ペナルティコスト項を含む。

いくつかの実施形態では、目的関数は、ペナルティコストを含む。１つ又は複数の予算制約は、いくつかの実施形態によれば、ペナルティコストが、（１）メンテナンス及び交換予算を超える支出に関連する第１のペナルティレートと、（２）ビルディング機器を保守及び交換することに費やされた額とメンテナンス及び交換予算との間の差との積以上であること、又は（１）メンテナンス及び交換予算未満の支出に関連する第２のペナルティレートと、（２）ビルディング機器を保守及び交換することに費やされた額とメンテナンス及び交換予算との間の差との積以上であることの少なくとも一方であることを必要とする。

いくつかの実施形態では、ＭＰＭシステムは、ビルディング機器からの閉ループフィードバックに基づいてリアルタイムで目的関数を動的に更新するように構成された目的関数生成器を含む。

いくつかの実施形態では、１つ又は複数の予算制約は、１つ又は複数の予算期間と、１つ又は複数の予算期間に関連するそれぞれの１つ又は複数のメンテナンス及び交換予算とに基づいて生成される。

いくつかの実施形態では、１つ又は複数の予算制約は、１つ又は複数の予算期間のそれぞれにわたるメンテナンス及び交換コストが、１つ又は複数の予算期間のそれぞれに関連するメンテナンス及び交換予算を超えることができないことを示す。

いくつかの実施形態では、予算マネージャは、１つ又は複数の予算期間の１つ又は複数が部分的に最適化期間外で生じるか否かを判断するように構成される。予算マネージャは、いくつかの実施形態によれば、１つ又は複数の予算期間の１つ又は複数が部分的に最適化期間外で生じるという判断に応答して、部分的に最適化期間外で生じる１つ又は複数の予算期間の１つ又は複数のそれぞれに関して、１つ又は複数の低減されたメンテナンス及び交換予算を決定するように構成される。

本開示の別の実装形態は、いくつかの実施形態によるビルディング機器のためのモデル予測的メンテナンス（ＭＰＭ）システムである。ＭＰＭは、いくつかの実施形態によれば、１つ又は複数のプロセッサを含む。ＭＰＭシステムは、いくつかの実施形態によれば、１つ又は複数のプロセッサによって実行されると、１つ又は複数のプロセッサに動作を実施させる命令を記憶する１つ又は複数の非一時的コンピュータ可読媒体を含む。動作は、いくつかの実施形態によれば、最適化期間にわたる利用可能な予算を受信することを含む。動作は、いくつかの実施形態によれば、最適化期間の継続期間にわたってビルディング機器を動作させるコストを予測することを含む。動作は、いくつかの実施形態によれば、ビルディング機器の１つ又は複数の劣化モデルに基づいて、最適化期間にわたるビルディング機器の劣化の量を推定することを含む。動作は、いくつかの実施形態によれば、ビルディング機器を動作させる予測されたコストと、ビルディング機器の劣化の量とに基づいて、利用可能な予算の一部をビルディング機器のメンテナンス及び交換に割り振ることを含む。動作は、いくつかの実施形態によれば、ビルディング機器のメンテナンス及び交換に割り振られた利用可能な予算の一部に基づく制御決定に従い、最適化期間の継続期間にわたってビルディング機器を動作させることを含む。

いくつかの実施形態では、動作は、ビルディング機器からのフィードバックとして受信された機器性能情報を使用して、最適化期間の各時間ステップでのビルディング機器の信頼性を決定することをさらに含む。ビルディング機器の劣化の量を推定することは、いくつかの実施形態によれば、ビルディング機器の信頼性にさらに基づく。

いくつかの実施形態では、動作は、利用可能な予算の割り振られた一部に基づいて目的関数を最適化して、ビルディング機器に関するメンテナンス及び交換スケジュールを決定することを含む。

いくつかの実施形態では、動作は、最適化期間の各時間ステップでのビルディング機器の動作効率を決定することを含む。ビルディング機器の劣化の量を推定することは、いくつかの実施形態によれば、ビルディング機器の動作効率にさらに基づく。

いくつかの実施形態では、動作は、オフラインで実施される。

いくつかの実施形態では、動作は、利用可能な予算の割り振られた一部と等しくない合計支出に関連するペナルティコストを決定することを含む。

いくつかの実施形態では、動作は、ペナルティコストが、（１）利用可能な予算を超える支出に関連する第１のペナルティレートと、（２）ビルディング機器を保守及び交換することに費やされた額と利用可能な予算との間の差との積以上であること、又は（１）利用可能な予算未満の支出に関連する第２のペナルティレートと、（２）ビルディング機器を保守及び交換することに費やされた額と利用可能な予算との間の差との積以上であることの少なくとも一方であることを必要とする１つ又は複数の予算制約を生成することを含む。

本開示の別の実装形態は、いくつかの実施形態によれば、ビルディング機器のモデル予測的メンテナンスを実施するための方法である。方法は、いくつかの実施形態によれば、ビルディングでの可変の状態又は条件に影響を及ぼすようにビルディング機器を動作させるステップを含む。方法は、いくつかの実施形態によれば、最適化期間の継続期間にわたってビルディング機器を動作させるコストを予測するステップを含む。方法は、いくつかの実施形態によれば、１つ又は複数の予算制約を生成するステップを含む。方法は、ビルディング機器に関するメンテナンス及び交換スケジュールを決定するために、１つ又は複数の予算制約を受ける目的関数を最適化するステップを含む。目的関数は、いくつかの実施形態によれば、ビルディング機器のメンテナンス及び交換コストと、ビルディング機器を動作させる予測されたコストとを含む。

いくつかの実施形態では、方法は、ペナルティコスト項を生成するステップを含む。目的関数は、いくつかの実施形態によれば、ペナルティコスト項を含む。

いくつかの実施形態では、目的関数は、ペナルティコストを含み、及び１つ又は複数の予算制約は、ペナルティコストが、（１）利用可能な予算を超える支出に関連する第１のペナルティレートと、（２）ビルディング機器を保守及び交換することに費やされた額と利用可能な予算との間の差との積以上であること、又は（１）利用可能な予算未満の支出に関連する第２のペナルティレートと、（２）ビルディング機器を保守及び交換することに費やされた額と利用可能な予算との間の差との積以上であることの少なくとも一方であることを必要とする。

いくつかの実施形態では、方法は、ビルディング機器からの閉ループフィードバックに基づいてリアルタイムで目的関数を動的に更新するステップを含む。

上記の概要は、単に例示にすぎず、何ら限定を意図するものではないことを当業者は理解するであろう。特許請求の範囲によってのみ定義される、本明細書で述べるデバイス及び／又はプロセスの他の態様、進歩性のある特徴及び利点は、本明細書で述べる詳細な説明を添付図面と併せて読むことで明らかになるであろう。

いくつかの実施形態による、ＨＶＡＣシステムを備えたビルディングを示す図である。いくつかの実施形態による、図１のビルディングの加熱又は冷却負荷をサービス提供するために使用することができるウォーターサイドシステムのブロック図である。いくつかの実施形態による、図１のビルディングの加熱又は冷却負荷をサービス提供するために使用することができるエアサイドシステムのブロック図である。いくつかの実施形態による、図１のビルディングを監視及び制御するために使用することができるビルディング管理システム（ＢＭＳ）のブロック図である。いくつかの実施形態による、図１のビルディングを監視及び制御するために使用することができる別のＢＭＳのブロック図である。いくつかの実施形態による、ビルディングに設置された接続された機器からの機器性能情報を監視するモデル予測的メンテナンス（ＭＰＭ）システムを含むビルディングシステムのブロック図である。いくつかの実施形態による、図６のＭＰＭシステムに機器性能情報を提供する１タイプの接続された機器であり得る冷却器の概略図である。いくつかの実施形態による、図６のＭＰＭシステムをより詳細に示すブロック図である。いくつかの実施形態による、図６のＭＰＭシステムの高レベルオプティマイザをより詳細に示すブロック図である。いくつかの実施形態による、図６のＭＰＭシステムを動作させるプロセスのフローチャートである。いくつかの実施形態による、最大予算のハード予算制約によって制約された状態で活動支出の増加による複合コストを最適化することを示すグラフである。いくつかの実施形態による、ペナルティコストのソフト予算制約によって制約された状態で活動支出の増加による複合コストを最適化することを示すグラフである。いくつかの実施形態による、ユーザインターフェースに接続された図８のＭＰＭシステムを例示するブロック図である。いくつかの実施形態による、追加の制約マネージャを備える図９の高レベルオプティマイザを例示するブロック図である。いくつかの実施形態による、故障リスク予測器を含む図９の高レベルオプティマイザを例示するブロック図である。いくつかの実施形態による、ハード予算制約下での最適化期間にわたる累積メンテナンス支出を例示するグラフである。いくつかの実施形態による、ソフト予算制約下での最適化期間にわたる累積メンテナンス支出を例示するグラフである。いくつかの実施形態による、複数の予算期間を有する最適化期間にわたる累積メンテナンスコストを例示するグラフである。いくつかの実施形態による、部分的に最適化期間外に及ぶメンテナンス予算期間を伴う最適化期間にわたる累積メンテナンスコストを例示するグラフである。いくつかの実施形態による、メンテナンス予算と推定メンテナンス支出との間の差に基づく関数としてペナルティコストを例示するグラフである。いくつかの実施形態による、ビルディング機器の劣化に基づくビルディング機器の故障確率分布を例示するグラフである。いくつかの実施形態による、ビルディング機器の劣化を低減するために実施されたメンテナンスに基づいて合計コストがどのように影響を及ぼされるかを例示するグラフである。いくつかの実施形態による、１つ又は複数のハード予算制約を受ける図１３のＭＰＭシステムを動作させるためのプロセスのフローチャートである。いくつかの実施形態による、ソフト予算制約を受ける図１３のＭＰＭシステムを動作させるためのプロセスのフローチャートである。いくつかの実施形態による、ビルディング機器の故障リスクを受ける図１３のＭＰＭシステムを動作させるためのプロセスのフローチャートである。いくつかの実施形態による、１つ又は複数の屋外ＶＲＦユニット及び複数の屋内ＶＲＦユニットを有する可変冷媒流量（ＶＲＦ）システムの図である。

概要

図面を全体として参照すると、様々な例示的実施形態によるモデル予測的メンテナンス（ＭＰＭ）システム及びその構成要素が示されている。ＭＰＭシステムは、ビルディング機器に関する最適なメンテナンス戦略を決定するように構成することができる。いくつかの実施形態では、最適なメンテナンス戦略は、最適化期間（例えば、３０週、５２週、１０年、３０年など）の継続期間にわたるビルディング機器の購入、メンテナンス及び動作に関連する総コストを最適化する決定事項の組である。これらの決定事項は、例えば、機器の購入の決定、機器のメンテナンスの決定及び機器の動作の決定を含むことができる。ＭＰＭシステムは、モデル予測制御技法を使用して、これらの決定事項の関数として総コストを表す目的関数を定式化することができる。決定事項は、決定変数として目的関数に含めることができる。ＭＰＭシステムは、様々な最適化技法のいずれかを使用して目的関数を最適化（例えば、最小化）して、各決定変数に関する最適値を識別することができる。

ＭＰＭシステムによって最適化することができる目的関数の一例は、次式で示される。

ここで、Ｃ_ｏｐ，ｉは、最適化期間の時間ステップｉにおいてビルディング機器が消費する単位エネルギーあたりのコスト（例えば、ドル／ｋＷｈ）であり、Ｐ_ｏｐ，ｉは、時間ステップｉにおけるビルディング機器の電力消費量（例えば、ｋＷ）であり、Δｔは、各時間ステップｉの継続時間であり、Ｃ_{ｍａｉｎ，ｉ}は、時間ステップｉにおいてビルディング機器に対して実施されるメンテナンスのコストであり、Ｂ_{ｍａｉｎ，ｉ}は、メンテナンスが実施されるか否かを示すバイナリ変数であり、Ｃ_{ｃａｐ，ｉ}は、時間ステップｉにおいてビルディング機器の新たなデバイスを購入する資本コストであり、Ｂ_{ｃａｐ，ｉ}は、新たなデバイスが購入されるか否かを示すバイナリ変数であり、ｈは、最適化が実施されるホライズン又は最適化期間の継続時間である。

目的関数Ｊの第１項は、最適化期間の継続期間にわたるビルディング機器の動作コストを表す。いくつかの実施形態では、単位エネルギーあたりのコストＣ_ｏｐ，ｉは、エネルギー価格データとして公益企業から受信される。コストＣ_ｏｐ，ｉは、時刻、曜日（例えば、平日か週末か）、現在の季節（例えば、夏か冬か）又は他の時間ベースの因子に依存する時変コストであり得る。例えば、コストＣ_ｏｐ，ｉは、ピークエネルギー消費期間中にはより高く、オフピーク又は部分ピークエネルギー消費期間中にはより低いことがある。

いくつかの実施形態では、電力消費量Ｐ_ｏｐ，ｉは、ビルディングの加熱又は冷却負荷に基づく。加熱又は冷却負荷は、ビルディング占有、時刻、曜日、現在の季節又は加熱若しくは冷却負荷に影響を与え得る他の因子に応じて、ＭＰＭシステムによって予測することができる。いくつかの実施形態では、ＭＰＭシステムは、気象サービスからの天気予報を使用して加熱又は冷却負荷を予測する。電力消費量Ｐ_ｏｐ，ｉは、ビルディング機器の効率η_ｉにも依存する。例えば、高い効率で動作するビルディング機器は、低い効率で動作するビルディング機器に比べて、同じ加熱又は冷却負荷を満たすために消費する電力Ｐ_ｏｐ，ｉが少ないことがある。

有利には、ＭＰＭシステムは、メンテナンス決定Ｂ_{ｍａｉｎ，ｉ}及び機器購入決定Ｂ_{ｃａｐ，ｉ}の関数として、各時間ステップｉにおけるビルディング機器の効率η_ｉをモデル化することができる。例えば、特定のデバイスに関する効率η_ｉは、デバイスが購入されたときに初期値η_０で始まることがあり、時間と共に低下し、連続する各時間ステップｉと共に効率η_ｉが低下することがある。デバイスに対するメンテナンスを実施することで、メンテナンスが実施された直後に効率η_ｉをより高い値にリセットすることができる。同様に、新たなデバイスを購入して既存のデバイスと交換することで、新たなデバイスが購入された直後に効率η_ｉをより高い値にリセットすることができる。リセット後、効率η_ｉは、メンテナンスが実施されるか又は新たなデバイスが購入される次の時点まで、時間と共に低下し続けることがある。

メンテナンスの実施又は新たなデバイスの購入により、動作中の電力消費量Ｐ_ｏｐ，ｉが比較的低くなり、したがって、メンテナンスが実施された後又は新たなデバイスが購入された後に各時間ステップｉにおける動作コストがより低くなることがある。言い換えると、メンテナンスの実施又は新たなデバイスの購入により、目的関数Ｊの第１項によって表される動作コストを低減することができる。しかし、メンテナンスの実施により、目的関数Ｊの第２項が増加することがあり、新たなデバイスの購入により、目的関数Ｊの第３項が増加することがある。目的関数Ｊは、これらの各コストを捕捉し、ＭＰＭシステムによって最適化して、最適化期間の継続期間にわたるメンテナンス及び機器購入決定の最適な組（すなわちバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}に関する最適値）を決定することができる。

いくつかの実施形態では、ＭＰＭシステムは、ビルディング機器からのフィードバックとして受信された機器性能情報を使用して、ビルディング機器の効率及び／又は信頼性を推定する。効率は、ビルディング機器での加熱又は冷却負荷とビルディング機器の電力消費量との関係を示すことがある。ＭＰＭシステムは、効率を使用して、Ｐ_ｏｐ，ｉの対応する値を計算することができる。信頼性は、ビルディング機器がその現在の動作条件下で障害なく動作し続ける尤度の統計的尺度であり得る。より過酷な条件下（例えば、高負荷、高温など）での動作は、信頼性をより低くすることがあり、より過酷でない条件下（例えば、低負荷、中程度の温度など）での動作は、信頼性をより高くすることがある。いくつかの実施形態では、信頼性は、ビルディング機器が最後にメンテナンスを受けてから経過した時間量及び／又はビルディング機器が購入若しくは設置されてから経過した時間量に基づく。

いくつかの実施形態では、ＭＰＭシステムは、機器購入及びメンテナンスの推奨を生成及び提供する。機器購入及びメンテナンスの推奨は、目的関数Ｊを最適化することによって決定されるバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}に関する最適値に基づくことがある。例えば、ビルディング機器の特定のデバイスに関するＢ_{ｍａｉｎ，２５}＝１の値は、最適化期間の第２５の時間ステップにおいてそのデバイスに対してメンテナンスが実施されるべきであることを示すことがあり、Ｂ_{ｍａｉｎ，２５}＝０の値は、その時間ステップにおいてメンテナンスを実施すべきでないことを示すことがある。同様に、Ｂ_{ｃａｐ，２５}＝１の値は、最適化期間の第２５の時間ステップにおいて、ビルディング機器の新たなデバイスを購入すべきであることを示すことがあり、Ｂ_{ｃａｐ，２５}＝０の値は、その時間ステップにおいて新たなデバイスを購入すべきでないことを示すことがある。

有利には、ＭＰＭシステムによって生成される機器購入及びメンテナンスの推奨は、ビルディング機器の実際の動作条件及び実際の性能に基づく予測的な推奨である。ＭＰＭシステムによって実施される最適化は、メンテナンスを実施するコスト及び新たな機器を購入するコストを、そのようなメンテナンス又は購入の決定により生じる動作コストの低減に対して重み付けして、総複合コストＪを最小化する最適なメンテナンス戦略を決定する。このようにして、ＭＰＭシステムによって生成される機器購入及びメンテナンスの推奨は、各グループのビルディング機器に特有のものとなり、特定のグループのビルディング機器に関する最適なコストＪを実現することができる。機器に特有の推奨は、いくつかのグループの接続された機器６１０及び／又はいくつかの動作条件に関しては最適でないことがある機器製造業者によって提供される一般的な予防的メンテナンスの推奨（例えば、毎年の機器の整備）に比べ、全体的なコストＪを低くすることができる。

いくつかの実施形態では、ＭＰＭシステムは、目的関数Ｊの最適化に対して様々な予算制約を課す。予算制約は、最適化中に決定された決定事項が、存在する任意の経済的制限又は他の制限を遵守することを保証することができる。特に、ＭＰＭシステムは、ハード予算制約、ソフト予算制約及び／又はそれらの何らかの組合せを目的関数Ｊに課すことがある。ハード予算制約は、遵守しなければならない制約を表すことがある。例えば、ハード予算制約は、最適化期間にわたるメンテナンス／交換のための最大許容予算であり得、すべてのメンテナンス／交換の合計コストが最大許容予算を超過することはできない。ハード予算制約と異なり、ソフト予算制約は、超過され得るか又は遵守されなくてもよいが、追加のペナルティが課せられる。例えば、ソフト予算制約が予算の上限を示している場合、メンテナンス／交換の合計コストは、上限を超え得るが、（例えば、超過量のパーセンテージとして）追加のペナルティコストが生じる。ソフト予算制約は、ソフト予算制約を遵守する決定変数を決定するために最適化を奨励することができるが、最適な解がソフト予算制約を遵守しない場合には柔軟性を与える。

いくつかの実施形態では、ペナルティコストは、予算制約を上回る又は下回る場合の両方に適用される。最適化期間にわたるメンテナンス／交換の合計コストが予算制約にできるだけ近いことは、価値があり得る。例えば、会計期間中にビルディングに関する予算の特定の額（例えば、ドル）がメンテナンス／交換に割り振られている場合、割り振られていたが、費やされなかったいかなる額も予算の異なる部分に移され、メンテナンス／交換の観点から未使用の額を実質的になくすことができる。したがって、目的関数Ｊの最適化中にペナルティコストを課して、最適化期間中に費やされる合計額ができるだけ予算制約に近づくようにする決定変数の値を決定することができる。具体的には、予算制約と推定される合計コストとの間の差の大きさが増加するにつれて、最適化中に追加されるペナルティコストも増加する。

いくつかの実施形態では、目的関数Ｊは、ビルディング機器の故障に関連するリスクコストを組み込む。ビルディング機器のビルディングデバイスが故障した場合、ビルディングデバイスのメンテナンス／交換コストを超えるコストが生じることがある。特に、ビルディング機器の故障は、ビルディング機器のメンテナンス／交換に関連するコストと、未対処の負荷又は失われた生産量などの様々な機会コストに関連するコストとの両方を生じる。リスクコストを目的関数Ｊに組み込むために、機器の故障が最適化期間中の全体的なコストにどのように影響を及ぼし得るかを考慮に入れるリスクコスト項を含むように目的関数Ｊを拡張することができる。リスクコスト項を含む目的関数Ｊは、以下の式で示される。

ここで、Ｃ_{ｆａｉｌ，ｉ}は、最適化期間の時間ステップｉにおけるビルディング機器の故障のコストであり、Ｐ_{ｆａｉｌ，ｉ}（δ_ｉ）は、時間ステップｉにおけるビルディングデバイスの劣化状態δ_ｉに基づく、時間ステップｉにおけるビルディング機器のビルディングデバイスの故障の確率である。特に、リスクコスト項

は、各ビルディングデバイスの故障の確率を考慮に入れることにより、最適化期間にわたるメンテナンス／交換の全体的なコストに影響を及ぼす。一般に、ビルディングデバイスの故障の確率が上昇するにつれて、リスクコスト項が目的関数Ｊに影響を及ぼす量が増加する。

リスクコスト項に基づいて、目的関数Ｊの最適化は、リスクコスト項が目的関数Ｊに含まれていない場合と異なる時点において、特定のビルディングデバイスがメンテナンスを実施され且つ／又は交換されるべきであると決定することがある。特に、リスクコスト項により、最適化プロセスは、特定のビルディングデバイスの故障確率を低く保つためにメンテナンス／交換を頻繁に実施すべき特定のビルディングデバイスを識別することが可能になり得る。例えば、可変冷媒流量（ＶＲＦ）システムの特定の屋内ユニット（ＩＤＵ）は、その特定のＩＤＵが故障した場合に居住者の安全性のためにビルディングのスペースを一時的に閉鎖する必要があるとき、故障に関連する大きい機会コストを伴うことがある。高い機会コストにより、最適化は、その特定のＩＤＵのメンテナンス／交換を、故障に関連するコストが最小である他のビルディングデバイスよりも優先することがある。

いくつかの実施形態では、目的関数Ｊは、メンテナンス／交換に関連する雑費を考慮に入れるために雑費項を組み込む。雑費は、動作コスト項、メンテナンスコスト項及び／又は資本コスト項において計上されない様々な出費を表すことができる。いくつかの実施形態では、雑費は、ビルディング機器の信頼性に影響を及ぼすが、ビルディング機器の効率に影響を及ぼさない。例えば、雑費には、ＨＶＡＣシステムの通気孔のねじを新しいねじに交換することが含まれ得る。上記の雑費を考慮に入れることは、最適化期間にわたる合計コストを正確に決定するのに有用であり得る。また、リスクコスト項が目的関数Ｊに組み込まれる場合、目的関数Ｊに雑費項を追加することが有用であり得る。リスクコスト項が組み込まれる場合、雑費項は、ビルディング機器の信頼性を高めるために実施することができる雑多なメンテナンス活動を提供し、それにより上記ビルディング機器の故障確率を低減することができる。さらに、予算制約が最適化に課せられる場合、予算制約が確実に遵守されるように雑費を考慮に入れることが重要であり得る。

最適化中、目的関数Ｊは、追加の因子として雑費を考慮に入れることができる。例えば、目的関数Ｊは、以下の形式を有することがある。

ここで、Ｃｏｓｔ_{ｍｉｓｃ，ｉ}は、時間ステップｉに関する雑多な活動のコストであり、Ｂ_{ｍｉｓｃ，ｉ}は、時間ステップｉにおいて雑多な活動が行われるか否かを示すバイナリ変数である。いくつかの実施形態では、雑費は、目的関数Ｊの他の項（例えば、メンテナンスコスト項、資本コスト項、リスクコスト項など）に計上される。Ｃ_{ｍｉｓｃ，ｉ}の値を決定するために、雑費は、雑費のユーザ入力、雑費を示す請求書の追跡、最適化期間の時間ステップに関して予想される何らかの平均雑費の推定などによって収集することができる。ＭＰＭシステムのこれら及び他の特徴を以下で詳細に述べる。

ビルディングＨＶＡＣシステム及びビルディング管理システム

ここで、図１〜図５を参照すると、いくつかの実施形態による、本開示のシステム及び方法を実施することができるいくつかのビルディング管理システム（ＢＭＳ）及びＨＶＡＣシステムが示されている。簡単な概要として、図１は、ＨＶＡＣシステム１００を備えたビルディング１０を示す。図２は、ビルディング１０にサービス提供するために使用することができるウォーターサイドシステム２００のブロック図である。図３は、ビルディング１０にサービス提供するために使用することができるエアサイドシステム３００のブロック図である。図４は、ビルディング１０を監視及び制御するために使用することができるＢＭＳのブロック図である。図５は、ビルディング１０を監視及び制御するために使用することができる別のＢＭＳのブロック図である。

ビルディング及びＨＶＡＣシステム

特に図１を参照すると、ビルディング１０の斜視図が示されている。ビルディング１０は、ＢＭＳによってサービス提供される。ＢＭＳは、一般に、ビルディング又はビルディングエリアの内部又は周辺の機器を制御、監視及び管理するように構成されたデバイスのシステムである。ＢＭＳは、例えば、ＨＶＡＣシステム、セキュリティシステム、照明システム、火災警報システム、ビルディングの機能若しくはデバイスを管理することが可能な任意の他のシステム又はそれらの任意の組合せを含むことができる。

ビルディング１０にサービス提供するＢＭＳは、ＨＶＡＣシステム１００を含む。ＨＶＡＣシステム１００は、ビルディング１０のための暖房、冷房、換気又は他のサービスを提供するように構成された複数のＨＶＡＣデバイス（例えば、加熱器、冷却器、エアハンドリングユニット、ポンプ、ファン、熱エネルギー貯蔵装置など）を含み得る。例えば、ＨＶＡＣシステム１００は、ウォーターサイドシステム１２０及びエアサイドシステム１３０を含むものとして示されている。ウォーターサイドシステム１２０は、加熱又は冷却された流体をエアサイドシステム１３０のエアハンドリングユニットに提供し得る。エアサイドシステム１３０は、加熱又は冷却された流体を使用して、ビルディング１０に提供される気流を加熱又は冷却し得る。ＨＶＡＣシステム１００で使用され得る例示的なウォーターサイドシステム及びエアサイドシステムについては、図２〜３を参照してより詳細に述べる。

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

ＡＨＵ１０６は、（例えば、冷却コイル及び／又は加熱コイルの１つ又は複数のステージを通って）ＡＨＵ１０６を通過する気流と作動流体を熱交換関係にすることができる。気流は、例えば、外気、ビルディング１０内からの還気又はそれら両方の組合せであり得る。ＡＨＵ１０６は、気流と作動流体との間で熱を伝達して、気流を加熱又は冷却し得る。例えば、ＡＨＵ１０６は、１つ又は複数のファン又は送風機を含み得、ファン又は送風機は、作動流体を含む熱交換器の上に又は熱交換器を通して空気を流すように構成される。次いで、作動流体は、配管１１０を通って冷却器１０２又はボイラ１０４に戻り得る。

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

ウォーターサイドシステム

次に、図２を参照すると、いくつかの実施形態によるウォーターサイドシステム２００のブロック図が示されている。様々な実施形態において、ウォーターサイドシステム２００は、ＨＶＡＣシステム１００内のウォーターサイドシステム１２０を補助するか若しくはそれに置き代わり得るか、又はＨＶＡＣシステム１００とは別個に実装され得る。ＨＶＡＣシステム１００に実装されるとき、ウォーターサイドシステム２００は、ＨＶＡＣシステム１００内のＨＶＡＣデバイスのサブセット（例えば、ボイラ１０４、冷却器１０２、ポンプ、弁など）を含み得、加熱又は冷却された流体をＡＨＵ１０６に供給するように動作し得る。ウォーターサイドシステム２００のＨＶＡＣデバイスは、ビルディング１０内に（例えば、ウォーターサイドシステム１２０の構成要素として）位置しても、中央プラントなど場外の位置に位置し得る。

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

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

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

サブプラント２０２〜２１２は、サブプラントの機能を実現しやすくするように構成された様々な機器をそれぞれ含み得る。例えば、加熱器サブプラント２０２は、温水ループ２１４内の温水に熱を加えるように構成された複数の加熱要素２２０（例えば、ボイラや電気加熱器など）を含むものとして示されている。また、加熱器サブプラント２０２は、いくつかのポンプ２２２及び２２４を含むものとして示されており、これらのポンプ２２２及び２２４は、温水ループ２１４内で温水を循環させ、個々の加熱要素２２０を通る温水の流量を制御するように構成される。冷却器サブプラント２０６は、冷水ループ２１６内の冷水から熱を除去するように構成された複数の冷却器２３２を含むものとして示されている。また、冷却器サブプラント２０６は、いくつかのポンプ２３４及び２３６を含むものとして示されており、ポンプ２３４及び２３６は、冷水ループ２１６内で冷水を循環させ、個々の冷却器２３２を通る冷水の流量を制御するように構成される。

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

高温ＴＥＳサブプラント２１０は、後の使用のために温水を貯蔵するように構成された高温ＴＥＳタンク２４２を含むものとして示されている。また、高温ＴＥＳサブプラント２１０は、１つ又は複数のポンプ又は弁を含み得、これらのポンプ又は弁は、高温ＴＥＳタンク２４２の内外への温水の流量を制御するように構成される。低温ＴＥＳサブプラント２１２は、後の使用のために冷水を貯蔵するように構成された低温ＴＥＳタンク２４４を含むものとして示されている。また、低温ＴＥＳサブプラント２１２は、１つ又は複数のポンプ又は弁を含むこともあり、これらのポンプ又は弁は、低温ＴＥＳタンク２４４の内外への冷水の流量を制御するように構成される。

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

エアサイドシステム

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

図３に、エアサイドシステム３００が、エコノマイザ型エアハンドリングユニット（ＡＨＵ）３０２を含むものとして示されている。エコノマイザ型ＡＨＵは、加熱又は冷却のためにエアハンドリングユニットによって使用される外気及び還気の量を変える。例えば、ＡＨＵ３０２は、ビルディング区域３０６から還気ダクト３０８を通して還気３０４を受け取り得、給気ダクト３１２を通してビルディング区域３０６に給気３１０を送給し得る。いくつかの実施形態では、ＡＨＵ３０２は、ビルディング１０の屋根に位置する屋上ユニット（例えば、図１に示されるＡＨＵ１０６）又は還気３０４と外気３１４との両方を受け取るように他の場所に位置決めされた屋上ユニットである。ＡＨＵ３０２は、混ざり合って給気３１０を生成する外気３１４と還気３０４との量を制御するために、排気ダンパ３１６、混合ダンパ３１８及び外気ダンパ３２０を動作させるように構成され得る。混合ダンパ３１８を通過しない還気３０４は、ＡＨＵ３０２から排気ダンパ３１６を通して排気３２２として排出され得る。

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

引き続き図３を参照すると、ＡＨＵ３０２は、給気ダクト３１２内に位置決めされた冷却コイル３３４、加熱コイル３３６及びファン３３８を含むものとして示されている。ファン３３８は、給気３１０を冷却コイル３３４及び／又は加熱コイル３３６に通し、さらに給気３１０をビルディング区域３０６に提供するように構成され得る。ＡＨＵ制御装置３３０は、通信リンク３４０を介してファン３３８と通信して、給気３１０の流量を制御し得る。いくつかの実施形態では、ＡＨＵ制御装置３３０は、ファン３３８の速度を調整することにより、給気３１０に加えられる加熱又は冷却の量を制御する。

冷却コイル３３４は、冷却された流体を、配管３４２を通してウォーターサイドシステム２００から（例えば、冷水ループ２１６から）受け取ることができ、また、冷却された流体を、配管３４４を通してウォーターサイドシステム２００に戻すことができる。冷却コイル３３４を通る冷却流体の流量を制御するために、配管３４２又は配管３４４に沿って弁３４６が位置決めされ得る。いくつかの実施形態では、冷却コイル３３４は、給気３１０に加えられる冷却量を調整するために、（例えば、ＡＨＵ制御装置３３０やＢＭＳ制御装置３６６などによって）独立して作動及び作動停止され得る複数ステージの冷却コイルを含む。

加熱コイル３３６は、加熱された流体を、配管３４８を通してウォーターサイドシステム２００から（例えば、温水ループ２１４から）受け取ることができ、また、加熱された流体を、配管３５０を通してウォーターサイドシステム２００に戻すことができる。加熱コイル３３６を通る加熱流体の流量を制御するために、配管３４８又は配管３５０に沿って弁３５２が位置決めされ得る。いくつかの実施形態では、加熱コイル３３６は、給気３１０に加えられる加熱量を調整するために、（例えば、ＡＨＵ制御装置３３０やＢＭＳ制御装置３６６などによって）独立して作動及び作動停止され得る複数ステージの加熱コイルを含む。

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

いくつかの実施形態では、ＡＨＵ制御装置３３０は、アクチュエータ３５４〜３５６によって弁３４６及び３５２を操作して、（例えば、給気３１０の設定値温度を実現するため又は設定値温度範囲内で給気３１０の温度を維持するために）給気３１０に提供される加熱又は冷却の量を調整する。弁３４６及び３５２の位置は、冷却コイル３３４又は加熱コイル３３６によって給気３１０に提供される加熱又は冷却の量に影響を及ぼし、所望の給気温度を実現するために消費されるエネルギーの量と相関し得る。ＡＨＵ３３０は、コイル３３４〜３３６を作動若しくは作動停止させること、ファン３３８の速度を調節すること又はそれら両方の組合せにより、給気３１０及び／又はビルディング区域３０６の温度を制御し得る。

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

いくつかの実施形態では、ＡＨＵ制御装置３３０は、ＢＭＳ制御装置３６６から情報（例えば、コマンド、設定値、動作境界など）を受信し、ＢＭＳ制御装置３６６に情報（例えば、温度測定値、弁又はアクチュエータ位置、動作ステータス、診断など）を提供する。例えば、ＡＨＵ制御装置３３０は、温度センサ３６２〜３６４からの温度測定値、機器のオン／オフ状態、機器の動作能力及び／又は任意の他の情報をＢＭＳ制御装置３６６に提供することができ、これらの情報をＢＭＳ制御装置３６６が使用して、ビルディング区域３０６内の変動する状態又は条件を監視又は制御することができる。

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

ビルディング管理システム

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

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

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

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

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

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

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

引き続き図４を参照すると、メモリ４０８は、企業統合層４１０、自動測定及び検証（ＡＭ＆Ｖ）層４１２、要求応答（ＤＲ）層４１４、故障検出及び診断（ＦＤＤ）層４１６、統合制御層４１８並びにビルディングサブシステム統合層４２０を含むものとして示されている。層４１０〜４２０は、ビルディングサブシステム４２８及び他のデータ源から入力を受信し、入力に基づいてビルディングサブシステム４２８のための最適な制御アクションを決定し、最適な制御アクションに基づいて制御信号を生成し、生成された制御信号をビルディングサブシステム４２８に提供するように構成され得る。以下の段落では、ＢＭＳ４００での各層４１０〜４２０によって実施される全般的な機能のいくつかを述べる。

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

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

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

いくつかの実施形態によれば、要求応答層４１４は、受信したデータ及び信号に応答するための制御論理を含む。これらの応答は、統合制御層４１８内の制御アルゴリズムと通信すること、制御戦略を変更すること、設定値を変更すること又は制御下でビルディング機器若しくはサブシステムを作動／作動停止することを含むことができる。また、要求応答層４１４は、貯蔵されているエネルギーを利用すべきときを決定するように構成された制御論理を含むこともある。例えば、要求応答層４１４は、ピーク使用時間の開始直前にエネルギー貯蔵装置４２７からのエネルギーの使用を開始することを決定し得る。

いくつかの実施形態では、要求応答層４１４は、要求（例えば、価格、削減信号、要求レベルなど）を表す１つ又は複数の入力に基づいて又は要求に基づいて、エネルギーコストを最小にする（例えば、自動的に設定値を変更する）制御アクションを能動的に開始するように構成された制御モジュールを含む。いくつかの実施形態では、要求応答層４１４は、機器モデルを使用して、最適な制御アクションの組を決定する。機器モデルは、例えば、様々な組のビルディング機器によって実施される入力、出力及び／又は機能を記述する熱力学モデルを含むことができる。機器モデルは、ビルディング機器の集合体（例えば、サブプラント、冷却器アレイなど）又は個々のデバイス（例えば、個々の冷却器、ヒータ、ポンプなど）を表すことがある。

さらに、要求応答層４１４は、１つ又は複数の要求応答ポリシー定義（例えば、データベースやＸＭＬファイルなど）を含むか又はそれを利用し得る。ポリシー定義は、（例えば、グラフィカルユーザインターフェースを介して）ユーザによって編集又は調節することができ、それにより、要求入力に応答して開始される制御アクションは、ユーザの用途に合わせて、所望の快適性レベルに合わせて、特定のビルディング機器に合わせて又は他の事項に基づいて調整され得る。例えば、要求応答ポリシー定義は、特定の要求入力に応答してどの機器がオン又はオフにされ得るか、システム又は機器をどの程度長くオフにすべきか、どの設定値を変更できるか、許容できる設定値調節範囲はどの程度か、通常通り予定された設定値に戻るまでに高い要求設定値をどの程度長く保つか、能力の限界にどの程度近付くか、どの機器モードを利用するか、エネルギー貯蔵デバイス（例えば、熱貯蔵タンクやバッテリバンクなど）の内外へのエネルギー伝達速度（例えば、最高速度、アラーム速度、他の速度限度情報など）及び（例えば、燃料電池や電動発電機セットなどを介して）現場でのエネルギー発生を送出するときを指定することができる。

統合制御層４１８は、ビルディングサブシステム統合層４２０及び／又は要求応答層４１４のデータ入力又は出力を使用して制御決定を行うように構成され得る。ビルディングサブシステム統合層４２０によって実現されるサブシステムの統合により、統合制御層４１８は、サブシステム４２８の制御活動を統合することができ、それにより、サブシステム４２８が単一の統合型スーパーシステムとして挙動する。いくつかの実施形態では、統合制御層４１８は、複数のビルディングサブシステムからの入力及び出力を使用する制御論理を含み、個々のサブシステムが単独で提供することができる快適性及びエネルギー節約よりも大きい快適性及びエネルギー節約を提供する。例えば、統合制御層４１８は、第１のサブシステムからの入力を使用して、第２のサブシステムに関するエネルギー節約制御決定を行うように構成され得る。これらの決定の結果は、ビルディングサブシステム統合層４２０に通信し返すことができる。

統合制御層４１８は、論理的に要求応答層４１４の下位にあるものとして示されている。統合制御層４１８は、ビルディングサブシステム４２８及びそれらそれぞれの制御ループを要求応答層４１４と共同で制御できるようにすることにより、要求応答層４１４の有効性を高めるように構成され得る。この構成は、有利には、従来のシステムに比べて、破壊的な要求応答挙動を減少し得る。例えば、統合制御層４１８は、冷却される水の温度の設定値（又は温度に直接若しくは間接的に影響を及ぼす別の成分）に対する要求応答に基づく上方修正が、ファンエネルギー（又は空間を冷却するために使用される他のエネルギー）の増加をもたらさないことを保証するように構成され得る。そのようなファンエネルギーの増加は、ビルディング総エネルギー使用量を、冷却器で保存されているエネルギーよりも大きくしてしまう。

統合制御層４１８は、要求応答層４１４にフィードバックを提供するように構成され得、それにより、要求応答層４１４は、要求された部分的送電停止が行われている間であっても制約（例えば、温度や照明レベルなど）が適切に維持されていることをチェックする。制約には、安全性、機器動作限界及びパフォーマンス、快適性、火災コード、電気コード、エネルギーコードなどに関係する設定値又は検知境界が含まれることもある。また、統合制御層４１８は、論理的に、故障検出及び診断層４１６並びに自動測定及び検証層４１２の下位にある。統合制御層４１８は、複数のビルディングサブシステムからの出力に基づいて、計算された入力（例えば、集約）をこれらのより高いレベルの層に提供するように構成され得る。

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

故障検出及び診断（ＦＤＤ）層４１６は、ビルディングサブシステム４２８及びビルディングサブシステムデバイス（すなわちビルディング機器）に関する継続的な故障検出機能を提供し、要求応答層４１４及び統合制御層４１８によって使用されるアルゴリズムを制御するように構成され得る。ＦＤＤ層４１６は、統合制御層４１８から、直接的に１つ若しくは複数のビルディングサブシステム若しくはデバイスから又は別のデータ源からデータ入力を受信し得る。ＦＤＤ層４１６は、検出された故障を自動的に診断して応答し得る。検出又は診断された故障に対する応答は、ユーザ、メンテナンススケジューリングシステム又は故障を修理する若しくは故障に対処することを試みるように構成された制御アルゴリズムに警報メッセージを提供することを含み得る。

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

ＦＤＤ層４１６は、様々な異なるシステムデータストア（又はライブデータに関するデータポイント）を記憶するか又はそこにアクセスするように構成され得る。ＦＤＤ層４１６は、データストアのうち、あるコンテンツを、機器レベル（例えば、特定の冷却器、特定のＡＨＵ、特定の端末ユニットなど）での故障を識別するために使用し、他のコンテンツを、構成要素又はサブシステムレベルでの故障を識別するために使用し得る。例えば、ビルディングサブシステム４２８は、ＢＭＳ４００及びその様々な構成要素のパフォーマンスを示す時間的（すなわち時系列）データを生成し得る。ビルディングサブシステム４２８によって生成されるデータは、測定値又は計算値を含むことがあり、それらの測定値又は計算値は、統計的特性を示し、対応するシステム又はプロセス（例えば、温度制御プロセスや流量制御プロセスなど）がその設定値からの誤差に対してどのように挙動しているかに関する情報を提供する。これらのプロセスは、ＦＤＤ層４１６によって検査することができ、システムのパフォーマンスが低下し始めたときを明らかにし、より深刻になる前に故障を修理するようにユーザに警報する。

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

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

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

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

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

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

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

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

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

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

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

モデル予測的メンテナンスシステム

次に、図６を参照すると、例示的実施形態によるビルディングシステム６００のブロック図が示されている。システム６００は、図４〜５を参照して述べたＢＭＳ４００及びＢＭＳ５００と同じ構成要素の多くを含むことができる。例えば、システム６００は、ビルディング１０、ネットワーク４４６及びクライアントデバイス４４８を含むものとして示されている。ビルディング１０は、接続された機器６１０を含むものとして示されており、機器６１０は、ビルディング１０を監視及び／又は制御するために使用される任意のタイプの機器を含むことができる。接続された機器６１０は、接続された冷却器６１２、接続されたＡＨＵ６１４、接続されたボイラ６１６、接続されたバッテリ６１８又はビルディングシステム内の任意の他のタイプの機器（例えば、ヒータ、エコノマイザ、バルブ、アクチュエータ、ダンパ、冷却塔、ファン、ポンプなど）若しくはビルディング管理システム内の任意の他のタイプの機器（例えば、照明機器、セキュリティ機器、冷凍機器など）を含むことができる。接続された機器６１０は、図１〜５を参照して述べたＨＶＡＣシステム１００、ウォーターサイドシステム２００、エアサイドシステム３００、ＢＭＳ４００及び／又はＢＭＳ５００の機器のいずれを含むこともできる。

接続された機器６１０には、接続された機器６１０の様々な状態（例えば、電力消費量、オン／オフ状態、動作効率など）を監視するためのセンサを装備することができる。例えば、冷却器６１２は、冷凍回路内の様々な位置での冷却水温度、凝縮水温度及び冷媒特性（例えば、冷媒圧力、冷媒温度など）などの冷却器変数を監視するように構成されたセンサを含むことができる。冷却器６１２の１つとして使用することができる冷却器７００の一例が図７に示されている。冷却器７００は、凝縮器７０２、膨張弁７０４、蒸発器７０６、圧縮機７０８及び制御パネル７１０を有する冷凍回路を含むものとして示されている。いくつかの実施形態では、冷却器７００は、冷凍回路に沿った様々な位置での監視される変数の組を測定するセンサを含む。同様に、ＡＨＵ６１４には、給気温度及び湿度、外気温度及び湿度、還気温度及び湿度、冷却された流体の温度、加熱された流体の温度、ダンパ位置などのＡＨＵ変数を監視するためのセンサを装備することができる。一般に、接続された機器６１０は、接続された機器６１０の性能を特徴付ける変数を監視及び報告することができる。監視された各変数は、ポイントＩＤ及びポイント値を含むデータポイントとしてビルディング管理システム６０６に転送することができる。

監視される変数は、接続された機器６１０及び／又はその構成要素の性能を示す任意の測定された値又は計算された値を含むことができる。例えば、監視される変数は、１つ又は複数の測定又は計算された温度（例えば、冷媒温度、冷水供給温度、温水供給温度、給気温度、ゾーン温度など）、圧力（例えば、蒸発器圧力、凝縮器圧力、供給空気圧力など）、流量（例えば、冷水流量、温水流量、冷媒流量、供給空気流量など）、バルブ位置、資源消費（例えば、電力消費量、水消費量、電気消費量など）、制御設定点、モデルパラメータ（例えば、回帰モデル係数）又は対応するシステム、デバイス若しくはプロセスがどのように動作しているかに関する情報を提供する任意の他の時系列値を含むことができる。監視される変数は、接続された機器６１０及び／又はその様々な構成要素から受信することができる。例えば、監視される変数は、１つ又は複数のコントローラ（例えば、ＢＭＳコントローラ、サブシステムコントローラ、ＨＶＡＣコントローラ、サブプラントコントローラ、ＡＨＵコントローラ、デバイスコントローラなど）、ＢＭＳデバイス（例えば、冷却器、冷却塔、ポンプ、加熱素子など）又はＢＭＳデバイスの集合体から受信することができる。

接続された機器６１０は、機器ステータス情報を報告することもできる。機器ステータス情報は、例えば、機器の動作ステータス、動作モード（例えば、低負荷、中負荷、高負荷など）、機器が正常な状態で稼働しているか異常な状態で稼働しているかの標示、機器が稼働している時間、安全障害コード又は接続された機器６１０の現在のステータスを示す任意の他の情報を含むことができる。いくつかの実施形態において、接続された機器６１０の各デバイスは、制御パネル（例えば、図７に示される制御パネル７１０）を含む。制御パネル７１０は、接続された機器６１０から監視される変数及び機器ステータス情報を収集し、収集されたデータをＢＭＳ６０６に提供するように構成することができる。例えば、制御パネル７１０は、センサデータ（又はセンサデータから導出された値）を所定の閾値と比較することができる。センサデータ又は計算された値が安全閾値を超える場合、制御パネル７１０は、デバイスをシャットダウンすることができる。制御パネル７１０は、安全シャットダウンが起きたときにデータポイントを生成することができる。データポイントは、シャットダウンをトリガした理由又は状態を示す安全障害コードを含むことができる。

接続された機器６１０は、監視される変数及び機器ステータス情報をＢＭＳ６０６に提供することができる。ＢＭＳ６０６は、ビルディングコントローラ（例えば、ＢＭＳコントローラ３６６）、システムマネージャ（例えば、システムマネージャ５０３）、ネットワーク自動化エンジン（例えば、ＮＡＥ５２０）又は接続された機器６１０と通信するように構成されたビルディング１０の任意の他のシステム若しくはデバイスを含むことができる。ＢＭＳ６０６は、図４〜５を参照して述べたＢＭＳ４００又はＢＭＳ５００の構成要素のいくつか又はすべてを含むことがある。いくつかの実施形態では、監視される変数及び機器ステータス情報は、データポイントとしてＢＭＳ６０６に提供される。各データポイントは、ポイントＩＤ及びポイント値を含むことができる。ポイントＩＤは、データポイントのタイプ又はデータポイントによって測定される変数（例えば、凝縮器圧力、冷媒温度、電力消費量など）を識別することができる。監視される変数は、名前又は英数字コード（例えば、Ｃｈｉｌｌｅｄ＿Ｗａｔｅｒ＿Ｔｅｍｐ、７６９４など）によって識別することができる。ポイント値は、データポイントの現在の値を示す英数字値を含むことができる。

ＢＭＳ６０６は、監視される変数及び機器ステータス情報をモデル予測的メンテナンスシステム６０２にブロードキャストすることができる。いくつかの実施形態では、モデル予測的メンテナンスシステム６０２は、ＢＭＳ６０６の構成要素である。例えば、モデル予測的メンテナンスシステム６０２は、ＪｏｈｎｓｏｎＣｏｎｔｒｏｌｓＩｎｃ．が販売しているＭＥＴＡＳＹＳ（登録商標）ブランドのビルディング自動化システムの一部として実装することができる。他の実施形態では、モデル予測的メンテナンスシステム６０２は、ネットワーク４４６を介して１つ又は複数のビルディング管理システムからのデータを受信及び処理するように構成された遠隔コンピューティングシステム又はクラウドベースのコンピューティングシステムの構成要素であり得る。例えば、モデル予測的メンテナンスシステム６０２は、ＪｏｈｎｓｏｎＣｏｎｔｒｏｌｓＩｎｃ．が販売しているＰＡＮＯＰＴＩＸ（登録商標）ブランドのビルディング効率プラットフォームの一部として実装することができる。他の実施形態では、モデル予測的メンテナンスシステム６０２は、サブシステムレベルコントローラ（例えば、ＨＶＡＣコントローラ）、サブプラントコントローラ、デバイスコントローラ（例えば、ＡＨＵコントローラ３３０、冷却器コントローラなど）、フィールドコントローラ、コンピュータワークステーション、クライアントデバイス又は接続された機器６１０から監視される変数を受信して処理する任意の他のシステム若しくはデバイスの構成要素であり得る。

モデル予測的メンテナンス（ＭＰＭ）システム６０２は、監視される変数及び／又は機器ステータス情報を使用して、接続された機器６１０の現在の動作条件を識別することができる。ＭＰＭシステム６０２によって現在の動作条件を検査して、接続された機器６１０の性能が低下し始めるときを明らかにし、且つ／又は障害が発生するときを予測することができる。いくつかの実施形態では、ＭＰＭシステム６０２は、接続された機器６１０から収集された情報を使用して、接続された機器６１０の信頼性を推定する。例えば、ＭＰＭシステム６０２は、接続された機器６１０の現在の動作条件と、接続された機器６１０が設置されてから及び／又はメンテナンスが最後に実施されてから経過した時間量とに基づいて、発生する可能性があり得る様々なタイプの故障の尤度を推定することができる。いくつかの実施形態では、ＭＰＭシステム６０２は、各故障が発生すると予測されるまでの時間量を推定し、各故障に関連する経済的コスト（例えば、メンテナンスコスト、増加される動作コスト、交換コストなど）を識別する。ＭＰＭシステム６０２は、信頼性情報及び潜在的な故障の尤度を使用して、メンテナンスが必要とされるときを予測し、所定の期間にわたってそのようなメンテナンスを実施するコストを推定することができる。

ＭＰＭシステム６０２は、接続された機器６１０に関する最適なメンテナンス戦略を決定するように構成することができる。いくつかの実施形態では、最適なメンテナンス戦略は、最適化期間（例えば、３０週、５２週、１０年、３０年など）の継続期間にわたる接続された機器６１０の購入、メンテナンス及び動作に関連する総コストを最適化する決定事項の組である。これらの決定事項は、例えば、機器の購入の決定、機器のメンテナンスの決定及び機器の動作の決定を含むことができる。ＭＰＭシステム６０２は、モデル予測制御技法を使用して、これらの決定事項の関数として総コストを表す目的関数を定式化することができる。決定事項は、決定変数として目的関数に含めることができる。ＭＰＭシステム６０２は、様々な最適化技法のいずれかを使用して目的関数を最適化（例えば、最小化）して、各決定変数に関する最適値を識別することができる。

ＭＰＭシステム６０２によって最適化することができる目的関数の一例は、次式で示される。

ここで、Ｃ_ｏｐ，ｉは、最適化期間の時間ステップｉにおいて接続された機器６１０が消費する単位エネルギーあたりのコスト（例えば、ドル／ｋＷｈ）であり、Ｐ_ｏｐ，ｉは、時間ステップｉにおける接続された機器６１０の電力消費量（例えば、ｋＷ）であり、Δｔは、各時間ステップｉの継続時間であり、Ｃ_{ｍａｉｎ，ｉ}は、時間ステップｉにおいて接続された機器６１０に対して実施されるメンテナンスのコストであり、Ｂ_{ｍａｉｎ，ｉ}は、メンテナンスが実施されるか否かを示すバイナリ変数であり、Ｃ_{ｃａｐ，ｉ}は、時間ステップｉにおいて接続された機器６１０の新たなデバイスを購入する資本コストであり、Ｂ_{ｃａｐ，ｉ}は、新たなデバイスが購入されるか否かを示すバイナリ変数であり、ｈは、最適化が実施されるホライズン又は最適化期間の継続時間である。

目的関数Ｊの第１項は、最適化期間の継続期間にわたる接続された機器６１０の動作コストを表す。いくつかの実施形態では、単位エネルギーあたりのコストＣ_ｏｐ，ｉは、エネルギー価格データとして公益企業６０８から受信される。コストＣ_ｏｐ，ｉは、時刻、曜日（例えば、平日か週末か）、現在の季節（例えば、夏か冬か）又は他の時間ベースの因子に依存する時変コストであり得る。例えば、コストＣ_ｏｐ，ｉは、ピークエネルギー消費期間中にはより高く、オフピーク又は部分ピークエネルギー消費期間中にはより低いことがある。

いくつかの実施形態では、電力消費量Ｐ_ｏｐ，ｉは、ビルディング１０の加熱又は冷却負荷に基づく。加熱又は冷却負荷は、ビルディング占有、時刻、曜日、現在の季節又は加熱若しくは冷却負荷に影響を与え得る他の因子に応じて、ＭＰＭシステム６０２によって予測することができる。いくつかの実施形態では、ＭＰＭシステム６０２は、気象サービス６０４からの天気予報を使用して加熱又は冷却負荷を予測する。電力消費量Ｐ_ｏｐ，ｉは、接続された機器６１０の効率η_ｉにも依存する。例えば、高い効率で動作する接続された機器６１０は、低い効率で動作する接続された機器６１０に比べて、同じ加熱又は冷却負荷を満たすために消費する電力Ｐ_ｏｐ，ｉが少ないことがある。一般に、接続された機器６１０の特定のデバイスの電力消費量Ｐ_ｏｐ，ｉは、次式を使用してモデル化することができる。

ここで、Ｌｏａｄ_ｉは、時間ステップｉにおけるデバイスに対する加熱又は冷却負荷（例えば、トン単位での冷却負荷、ｋＷ単位での加熱負荷など）であり、Ｐ_{ｉｄｅａｌ，ｉ}は、対応する負荷点Ｌｏａｄ_ｉでのデバイスに関する機器性能曲線の値（例えば、トン単位での冷却負荷、ｋＷ単位での加熱負荷など）であり、η_ｉは、時間ステップｉにおけるデバイスの動作効率である（例えば、０≦η_ｉ≦１）。関数ｆ（Ｌｏａｄ_ｉ）は、性能曲線によって表されるデバイス又はデバイスのセットの機器性能曲線によって定義することができる。

いくつかの実施形態では、機器性能曲線は、理想的な動作条件下でのデバイスに関する製造業者仕様に基づいている。例えば、機器性能曲線は、接続された機器６１０の各デバイスに関する電力消費量と加熱／冷却負荷との関係を定義することがある。しかし、デバイスの実際の性能は、実際の動作条件に応じて異なることがある。ＭＰＭシステム６０２は、接続された機器６１０によって提供される機器性能情報を分析して、接続された機器６１０の各デバイスに関する動作効率η_ｉを決定することができる。いくつかの実施形態では、ＭＰＭシステム６０２は、接続された機器６１０からの機器性能情報を使用して、接続された機器６１０の各デバイスに関する実際の動作効率η_ｉを決定する。ＭＰＭシステム６０２は、動作効率η_ｉを目的関数Ｊへの入力として使用すること及び／又は対応するＰ_ｏｐ，ｉ値を計算することができる。

有利には、ＭＰＭシステム６０２は、各時間ステップｉにおける接続された機器６１０の効率η_ｉを、メンテナンス決定Ｂ_{ｍａｉｎ，ｉ}及び機器購入決定Ｂ_{ｃａｐ，ｉ}の関数としてモデル化することができる。例えば、特定のデバイスに関する効率η_ｉは、デバイスが購入されたときに初期値η_０で始まることがあり、時間と共に低下し、連続する各時間ステップｉと共に効率η_ｉが低下することがある。デバイスに対するメンテナンスを実施することで、メンテナンスが実施された直後に効率η_ｉをより高い値にリセットすることができる。同様に、新たなデバイスを購入して既存のデバイスと交換することで、新たなデバイスが購入された直後に効率η_ｉをより高い値にリセットすることができる。リセット後、効率η_ｉは、メンテナンスが実施されるか又は新たなデバイスが購入される次の時点まで、時間と共に低下し続けることがある。

メンテナンスの実施又は新たなデバイスの購入により、動作中の電力消費量Ｐ_ｏｐ，ｉが比較的低くなり、したがって、メンテナンスが実施された後又は新たなデバイスが購入された後に各時間ステップｉにおける動作コストがより低くなることがある。言い換えると、メンテナンスの実施又は新たなデバイスの購入により、目的関数Ｊの第１項によって表される動作コストを低減することができる。しかし、メンテナンスの実施により、目的関数Ｊの第２項が増加することがあり、新たなデバイスの購入により、目的関数Ｊの第３項が増加することがある。目的関数Ｊは、これらの各コストを捕捉し、ＭＰＭシステム６０２によって最適化して、最適化期間の継続期間にわたるメンテナンス及び機器購入決定の最適な組（すなわちバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}に関する最適値）を決定することができる。

いくつかの実施形態では、ＭＰＭシステム６０２は、接続された機器６１０からの機器性能情報を使用して、接続された機器６１０の信頼性を推定する。信頼性は、接続された機器６１０がその現在の動作条件下で障害なく動作し続ける尤度の統計的尺度であり得る。より過酷な条件下（例えば、高負荷、高温など）での動作は、信頼性をより低くすることがあり、より過酷でない条件下（例えば、低負荷、中程度の温度など）での動作は、信頼性をより高くすることがある。いくつかの実施形態では、信頼性は、接続された機器６１０が最後にメンテナンスを受けてから経過した時間量に基づく。

ＭＰＭシステム６０２は、複数のビルディングに分散された接続された機器６１０の複数のデバイスから動作データを受信することがあり、動作データのセット（例えば、動作条件、障害標示、故障時間など）を使用して、各タイプの機器に関する信頼性モデルを生成することができる。ＭＰＭシステム６０２が信頼性モデルを使用して、接続された機器６１０の任意の所与のデバイスの信頼性を、その現在の動作条件及び／又は他の外的要因（例えば、メンテナンスが最後に実施されてからの時間、地理的位置、水質など）に応じて推定することができる。いくつかの実施形態では、ＭＰＭシステム６０２は、接続された機器６１０の各デバイスの推定された信頼性を使用して、最適化期間の各時間ステップにおいてデバイスがメンテナンス及び／又は交換を必要とする確率を決定する。ＭＰＭシステム６０２は、これらの確率を使用して、最適化期間の継続期間にわたるメンテナンス及び機器購入決定の最適な組（すなわちバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}に関する最適値）を決定することができる。

いくつかの実施形態では、ＭＰＭシステム６０２は、機器購入及びメンテナンスの推奨を生成及び提供する。機器購入及びメンテナンスの推奨は、目的関数Ｊを最適化することによって決定されるバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}に関する最適値に基づくことがある。例えば、接続された機器６１０の特定のデバイスに関するＢ_{ｍａｉｎ，２５}＝１の値は、最適化期間の第２５の時間ステップにおいてそのデバイスに対してメンテナンスが実施されるべきであることを示すことがあり、Ｂ_{ｍａｉｎ，２５}＝０の値は、その時間ステップにおいてメンテナンスを実施すべきでないことを示すことがある。同様に、Ｂ_{ｃａｐ，２５}＝１の値は、最適化期間の第２５の時間ステップにおいて、接続された機器６１０の新たなデバイスを購入すべきであることを示すことがあり、Ｂ_{ｃａｐ，２５}＝０の値は、その時間ステップにおいて新たなデバイスを購入すべきでないことを示すことがある。

有利には、ＭＰＭシステム６０２によって生成される機器購入及びメンテナンスの推奨は、接続された機器６１０の実際の動作条件及び実際の性能に基づく予測的な推奨である。ＭＰＭシステム６０２によって実施される最適化は、メンテナンスを実施するコスト及び新たな機器を購入するコストを、そのようなメンテナンス又は購入の決定により生じる動作コストの低減に対して重み付けして、総複合コストＪを最小化する最適なメンテナンス戦略を決定する。このようにして、ＭＰＭシステム６０２によって生成される機器購入及びメンテナンスの推奨は、各グループの接続された機器６１０に特有のものとなり、特定のグループの接続された機器６１０に関する最適なコストＪを実現することができる。機器に特有の推奨は、いくつかのグループの接続された機器６１０及び／又はいくつかの動作条件に関しては最適でないことがある機器製造業者によって提供される一般的な予防的メンテナンスの推奨（例えば、毎年の機器の整備）に比べ、全体的なコストＪを低くすることができる。

いくつかの実施形態では、機器購入及びメンテナンスの推奨は、ビルディング１０（例えば、ＢＭＳ６０６）及び／又はクライアントデバイス４４８に提供される。操作者又はビルディングの所有者は、機器購入及びメンテナンスの推奨を使用して、メンテナンスの実施及び新たなデバイスの購入のコスト及び利益を評価することができる。いくつかの実施形態では、機器購入及びメンテナンスの推奨が整備士６２０に提供される。整備士６２０は、機器購入及びメンテナンスの推奨を使用して、整備の実施又は機器の交換のために顧客に連絡すべきときを決定することができる。

いくつかの実施形態では、ＭＰＭシステム６０２は、データ分析及び視覚化プラットフォームを含む。ＭＰＭシステム６０２は、整備士６２０、クライアントデバイス４４８及び他のシステム又はデバイスがアクセスすることができるウェブインターフェースを提供することがある。ウェブインターフェースを使用して、機器性能情報にアクセスし、最適化の結果を閲覧し、メンテナンスが必要な機器を識別し、さもなければＭＰＭシステム６０２と対話することができる。整備士６２０は、ウェブインターフェースにアクセスして、ＭＰＭシステム６０２によってメンテナンスが推奨される機器のリストを閲覧することができる。整備士６２０は、機器購入及びメンテナンスの推奨を使用して、接続された機器６１０を早期に修理又は交換し、目的関数Ｊによって予測される最適なコストを実現することができる。ＭＰＭシステム６０２のこれら及び他の特徴は、以下でより詳細に述べる。

次に、図８を参照すると、例示的実施形態に従って、ＭＰＭシステム６０２をより詳細に例示するブロック図が示されている。ＭＰＭシステム６０２は、最適化結果をビルディング管理システム（ＢＭＳ）６０６に提供するものとして示されている。ＢＭＳ６０６は、図４〜５を参照して述べたＢＭＳ４００及び／又はＢＭＳ５００の特徴のいくつか又はすべてを含むことがある。ＢＭＳ６０６に提供される最適化結果は、最適化期間内の時間ステップｉごとに目的関数Ｊの決定変数の最適値を含むことがある。いくつかの実施形態では、最適化結果は、接続された機器６１０のデバイスごとの機器購入及びメンテナンスの推奨を含む。

ＢＭＳ６０６は、接続された機器６１０の動作及び性能を監視するように構成されることがある。ＢＭＳ６０６は、接続された機器６１０から監視される変数を受信することができる。監視される変数は、接続された機器６１０及び／又はその構成要素の性能を示す任意の測定された値又は計算された値を含むことができる。例えば、監視される変数は、１つ又は複数の測定又は計算された温度、圧力、流量、バルブ位置、資源消費（例えば、電力消費量、水消費量、電気消費量など）、制御設定点、モデルパラメータ（例えば、機器モデル係数）又は対応するシステム、デバイス若しくはプロセスがどのように動作しているかに関する情報を提供する任意の他の変数を含むことができる。

いくつかの実施形態では、監視される変数が、接続された機器６１０の各デバイスの動作効率η_ｉを示すか、又は監視される変数を使用して動作効率η_ｉを計算することができる。例えば、冷却器によって出力される冷却された水の温度及び流量を使用して、冷却器によってサービス提供される冷却負荷（例えば、トン単位での冷却負荷）を計算することができる。冷却負荷を冷却器の電力消費量と組み合わせて使用して、動作効率η_ｉ（例えば、消費される電気１ｋＷあたりのトン単位での冷却負荷）を計算することができる。ＢＭＳ６０６は、接続された機器６１０の各デバイスの動作効率η_ｉを計算する際に使用するために、監視される変数をＭＰＭシステム６０２に報告することができる。

いくつかの実施形態では、ＢＭＳ６０６は、接続された機器６１０の稼働時間を監視する。稼働時間は、接続された機器６１０の各デバイスがアクティブである所与の期間内の時間を示し得る。例えば、冷却器に関する稼働時間は、冷却器が１日に約８時間アクティブであることを示すことがある。稼働時間を、アクティブ時の冷却器の平均電力消費量と組み合わせて使用して、各時間ステップｉにおける接続された機器６１０の総電力消費量Ｐ_ｏｐ，ｉを推定することができる。

いくつかの実施形態では、ＢＭＳ６０６は、接続された機器６１０によって報告される機器故障及び障害標示を監視する。ＢＭＳ６０６は、各故障又は障害が発生する時間及び障害又は故障が発生した際の接続された機器６１０の動作条件を記録することができる。ＢＭＳ６０６及び／又はＭＰＭシステム６０２が、接続された機器６１０から収集された動作データを使用して、接続された機器６１０のデバイスごとの信頼性モデルを作成することができる。ＢＭＳ６０６は、監視される変数、機器稼働時間、動作条件並びに機器故障及び障害標示を機器性能情報としてＭＰＭシステム６０２に提供することができる。

ＢＭＳ６０６は、制御されているビルディング又はビルディング区域内部の状態を監視するように構成することができる。例えば、ＢＭＳ６０６は、ビルディング全体にわたって分散された様々なセンサ（例えば、温度センサ、湿度センサ、気流センサ、電圧センサなど）からの入力を受信することがあり、ビルディングの状態をＭＰＭシステム６０２に報告することがある。ビルディングの状態は、例えば、ビルディング又はビルディングのゾーンの温度、ビルディングの電力消費量（例えば、電気負荷）、ビルディング内部の制御されている状態に影響を与えるように構成された１つ又は複数のアクチュエータの状態又は制御されているビルディングに関係する他のタイプの情報を含むことがある。ＢＭＳ６０６は、接続された機器６１０を動作させて、ビルディング内部の監視されている状態に影響を与え、ビルディングの熱エネルギー負荷を提供することができる。

ＢＭＳ６０６は、接続された機器６１０に制御信号を提供し、接続された機器６１０に関するオン／オフ状態、充電／放電速度及び／又は設定点を指定することができる。ＢＭＳ６０６は、制御信号に従って（例えば、アクチュエータ、継電器などを介して）機器を制御して、接続された機器６１０の様々なビルディング区域及び／又はデバイスに関する設定点を実現することができる。様々な実施形態において、ＢＭＳ６０６は、ＭＰＭシステム６０２と組み合わされ得るか、又は別個のビルディング管理システムの一部であり得る。例示的実施形態によれば、ＢＭＳ６０６は、ＪｏｈｎｓｏｎＣｏｎｔｒｏｌｓ，Ｉｎｃ．が販売しているＭＥＴＡＳＹＳ（登録商標）ブランドのビルディング管理システムである。

ＭＰＭシステム６０２は、ＢＭＳ６０６から受信された情報を使用して、接続された機器６１０の性能を監視することができる。ＭＰＭシステム６０２は、（例えば、気象サービス６０４からの天気予報を使用して）最適化期間内の複数の時間ステップに関してビルディングの熱エネルギー負荷（例えば、加熱負荷、冷却負荷など）を予測するように構成されることがある。ＭＰＭシステム６０２は、公益企業６０８から受信された価格データを使用して、電気又は他の資源（例えば、水、天然ガスなど）のコストを予測することもある。ＭＰＭシステム６０２は、最適化プロセスに対する制約（例えば、負荷制約、決定変数制約など）を受ける最適化期間の継続期間にわたって、接続された機器６１０の動作、メンテナンス及び購入の経済的価値を最適化する最適化結果を生成することができる。ＭＰＭシステム６０２によって実施される最適化プロセスを以下でより詳細に述べる。

例示的実施形態によれば、ＭＰＭシステム６０２は、単一のコンピュータ（例えば、１つのサーバ、１つのハウジングなど）の内部に統合することができる。様々な他の例示的実施形態では、ＭＰＭシステム６０２を複数のサーバ又はコンピュータ（例えば、分散された場所に存在し得る）にわたって分散させることができる。別の例示的実施形態では、ＭＰＭシステム６０２は、複数のビルディングシステムを管理するスマートビルディングマネージャと統合し、且つ／又はＢＭＳ６０６と組み合わせることができる。

ＭＰＭシステム６０２は、通信インターフェース８０４及び処理回路８０６を含むものとして示されている。通信インターフェース８０４は、様々なシステム、デバイス又はネットワークとのデータ通信を行うための有線又は無線インターフェース（例えば、ジャック、アンテナ、送信機、受信機、送受信機、有線端末など）を含むことがある。例えば、通信インターフェース８０４は、イーサネットベースの通信ネットワークを介してデータを送受信するためのイーサネットカード及びポート及び／又は無線通信ネットワークを介して通信するためのＷｉＦｉ送受信機を含むことがある。通信インターフェース８０４は、ローカルエリアネットワーク又はワイドエリアネットワーク（例えば、インターネット、ビルディングＷＡＮなど）を介して通信するように構成されることがあり、様々な通信プロトコル（例えば、ＢＡＣｎｅｔ、ＩＰ、ＬＯＮなど）を使用し得る。

通信インターフェース８０４は、ＭＰＭシステム６０２と様々な外部システム又はデバイス（例えば、ＢＭＳ６０６、接続された機器６１０、公益企業５１０など）との間の電子データ通信を容易にするように構成されたネットワークインターフェースであり得る。例えば、ＭＰＭシステム６０２は、ＢＭＳ６０６から、制御されているビルディングの１つ又は複数の測定された状態（例えば、温度、湿度、電気負荷など）及び接続された機器６１０に関する機器性能情報（例えば、稼働時間、電力消費量、動作効率など）を示す情報を受信することがある。通信インターフェース８０４は、ＢＭＳ６０６及び／又は接続された機器６１０から入力を受信することができ、ＢＭＳ６０６及び／又は他の外部システム若しくはデバイスに最適化結果を提供することができる。最適化結果により、ＢＭＳ６０６は、接続された機器６１０に関する設定点をアクティブ化、非アクティブ化又は調整して、最適化結果で指定された決定変数の最適値を実現することができる。

引き続き図８を参照すると、処理回路８０６は、プロセッサ８０８及びメモリ８１０を含むものとして示されている。プロセッサ８０８は、汎用若しくは特定用途向けプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、１つ若しくは複数のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）、処理構成要素のグループ又は他の適切な処理構成要素であり得る。プロセッサ８０８は、メモリ８１０に記憶されたか又は他のコンピュータ可読媒体（例えば、ＣＤＲＯＭ、ネットワークストレージ、リモートサーバなど）から受信されたコンピュータコード又は命令を実行するように構成され得る。

メモリ８１０は、本開示で述べる様々なプロセスを完遂及び／又は容易化するためのデータ及び／又はコンピュータコードを記憶するための１つ又は複数のデバイス（例えば、メモリユニット、メモリデバイス、記憶デバイスなど）を含み得る。メモリ８１０は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードドライブ記憶装置、一時記憶装置、不揮発性メモリ、フラッシュメモリ、光学メモリ又はソフトウェアオブジェクト及び／又はコンピュータ命令を記憶するための任意の他の適切なメモリを含み得る。メモリ８１０は、データベースコンポーネント、オブジェクトコードコンポーネント、スクリプトコンポーネント又は本開示で述べる様々な活動及び情報構造をサポートするための任意の他のタイプの情報構造を含み得る。メモリ８１０は、処理回路８０６を介してプロセッサ８０８に通信可能に接続され得、本明細書で述べる１つ又は複数のプロセスを（例えば、プロセッサ８０８によって）実行するためのコンピュータコードを含み得る。

ＭＰＭシステム６０２は、機器性能モニタ８２４を含むものとして示されている。機器性能モニタ８２４は、ＢＭＳ６０６及び／又は接続された機器６１０から機器性能情報を受信することができる。機器性能情報は、監視される変数のサンプル（例えば、測定された温度、測定された圧力、測定された流量、電力消費量など）、現在の動作条件（例えば、加熱又は冷却負荷、現在の動作条件など）、障害標示又は接続された機器６１０の性能を特徴付ける他のタイプの情報を含むことができる。いくつかの実施形態では、機器性能モニタ８２４は、機器性能情報を使用して、接続された機器６１０の各デバイスの現在の効率η_ｉ及び信頼性を計算する。機器性能モニタ８２４は、目的関数Ｊの最適化に使用するために、効率η_ｉ及び信頼性値をモデル予測オプティマイザ８３０に提供することができる。

引き続き図８を参照すると、ＭＰＭシステム６０２は、負荷／料金予測器８２２を含むものとして示されている。負荷／料金予測器８２２は、最適化期間の時間ステップｉごとに、ビルディング又は構内のエネルギー負荷（Ｌｏａｄ_ｉ）（例えば、加熱負荷、冷却負荷、電気負荷など）を予測するように構成されることがある。負荷／料金予測器８２２は、気象サービス６０４から天気予報を受信するものとして示されている。いくつかの実施形態では、負荷／料金予測器８２２は、天気予報に応じてエネルギー負荷Ｌｏａｄ_ｉを予測する。いくつかの実施形態では、負荷／料金予測器８２２は、ＢＭＳ６０６からのフィードバックを使用して、負荷Ｌｏａｄ_ｉを予測する。ＢＭＳ６０６からのフィードバックは、様々なタイプの感覚入力（例えば、温度、流量、湿度、エンタルピーなど）又は制御されているビルディングに関係する他のデータ（例えば、ＨＶＡＣシステム、照明制御システム、セキュリティシステム、給水システムなどからの入力）を含むことがある。

いくつかの実施形態では、負荷／料金予測器８２２は、測定された電気負荷及び／又は以前に測定された負荷データをＢＭＳ６０６から（例えば、機器性能モニタ８２４を介して）受信する。負荷／料金予測器８２２は、所与の天気予報

、日付け（日）、時刻（ｔ）及び以前に測定された負荷データ（Ｙ_ｉ−１）に応じて負荷Ｌｏａｄ_ｉを予測することがある。そのような関係は、次式で表される。

いくつかの実施形態では、負荷／料金予測器８２２は、履歴負荷データから訓練された決定論的＋確率モデルを使用して負荷Ｌｏａｄ_ｉを予測する。負荷／料金予測器８２２は、様々な予測法の任意のものを使用して負荷Ｌｏａｄ_ｉを予測することができる（例えば、決定論的部分に関しては線形回帰及び確率的部分に関してはＡＲモデル）。負荷／料金予測器８２２は、ビルディング又は構内に関する１つ又は複数の異なるタイプの負荷を予測することがある。例えば、負荷／料金予測器８２２は、最適化期間内の時間ステップｉごとに、温水負荷Ｌｏａｄ_{Ｈｏｔ，ｉ}、冷水負荷Ｌｏａｄ_{Ｃｏｌｄ，ｉ}及び電気負荷Ｌｏａｄ_{Ｅｌｅｃ，ｉ}を予測することがある。予測される負荷値Ｌｏａｄ_ｉは、これらのタイプの負荷のいくつか又はすべてを含むことができる。いくつかの実施形態では、負荷／料金予測器８２２は、米国特許出願第１４／７１７，５９３号に記載されている技法を使用して負荷／料金予測を行う。

負荷／料金予測器８２２は、公益企業６０８から公共料金を受信するものとして示されている。公共料金は、最適化期間内の各時間ステップｉにおいて公益企業６０８によって提供される資源（例えば、電気、天然ガス、水など）の単位あたりのコスト又は価格を示すことがある。いくつかの実施形態では、公共料金は時変料金である。例えば、電気の価格は、特定の時間帯又は曜日（例えば、高需要の期間中）にはより高く、他の時間帯又は曜日（例えば、低需要の期間中）にはより低くなることがある。公共料金は、様々な期間と、各期間中の資源の１単位あたりのコストとを定義することがある。公共料金は、公益企業６０８から受信された実際の料金又は負荷／料金予測器８２２によって推定された予測公共料金であり得る。

いくつかの実施形態では、公共料金は、公益企業６０８によって提供される１つ又は複数の資源に関する需要料金を含む。需要料金は、需要料金期間中の特定の資源の最大使用量（例えば、最大エネルギー消費）に基づいて、公益企業６０８によって課される個別のコストを定義することがある。公共料金は、様々な需要料金期間と、各需要料金期間に関連付けられた１つ又は複数の需要料金とを定義することがある。いくつかの場合、需要料金期間は、互いに及び／又は予測窓と部分的又は完全に重なることがある。モデル予測オプティマイザ８３０は、高レベルオプティマイザ８３２によって実施される高レベル最適化プロセスにおける需要料金を考慮に入れるように構成されることがある。公益企業６０８は、時変（例えば、１時間ごと）の価格、最大サービスレベル（例えば、物理的インフラストラクチャによって又は契約によって許可される最大消費レート）及び電気の場合、需要料金又は特定の期間内の消費量のピークレートに関する料金によって定義されることがある。負荷／料金予測器８２２は、予測される負荷Ｌｏａｄ_ｉ及び公共料金をメモリ８１０に記憶することができ、且つ／又は予測された負荷Ｌｏａｄ_ｉ及び公共料金をモデル予測オプティマイザ８３０に提供することができる。

引き続き図８を参照すると、ＭＰＭシステム６０２は、モデル予測オプティマイザ８３０を含むものとして示されている。モデル予測オプティマイザ８３０は、マルチレベル最適化プロセスを実施して、接続された機器６１０の購入、メンテナンス及び動作に関連付けられた総コストを最適化するように構成することができる。いくつかの実施形態では、モデル予測オプティマイザ８３０は、高レベルオプティマイザ８３２及び低レベルオプティマイザ８３４を含む。高レベルオプティマイザ８３２は、接続された機器６１０のセット全体（例えば、ビルディング内部のすべてのデバイス）又は接続された機器６１０のサブセット（例えば、単一のデバイス、サブプラント又はビルディングサブシステムのすべてのデバイスなど）に関して目的関数Ｊを最適化して、目的関数Ｊでの各決定変数（例えば、Ｐ_ｏｐ，ｉ、Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}）に関する最適値を決定することができる。高レベルオプティマイザ８３２によって実施される最適化を、図９を参照してより詳細に述べる。

いくつかの実施形態では、低レベルオプティマイザ８３４は、高レベルオプティマイザ８３２から最適化結果を受信する。最適化結果は、最適化期間内の各時間ステップｉにおける接続された機器の各デバイス又はデバイスのセットに関する最適な電力消費量値Ｐ_ｏｐ，ｉ及び／又は負荷値Ｌｏａｄ_ｉを含むことがある。低レベルオプティマイザ８３４は、高レベルオプティマイザ８３２によって決定された負荷値で各デバイス又はデバイスのセットを最適に稼働する方法を決定することがある。例えば、低レベルオプティマイザ８３４は、接続された機器６１０の電力消費量を最適化（例えば、最小化）して対応する負荷値Ｌｏａｄ_ｉを満たすために、接続された機器６１０の様々なデバイスに関するオン／オフ状態及び／又は動作設定点を決定することがある。

低レベルオプティマイザ８３４は、接続された機器６１０の各デバイス又はデバイスのセットに関する機器性能曲線を生成するように構成されることがある。各性能曲線は、接続された機器６１０の特定のデバイス又はデバイスのセットによる資源消費量（例えば、ｋＷ単位で測定される電気使用量、Ｌ／ｓで測定される水使用量など）を、デバイス又はデバイスのセットに対する負荷の関数として示すことがある。いくつかの実施形態において、低レベルオプティマイザ８３４は、負荷点（例えば、Ｌｏａｄ_ｉの様々な値）及び気象条件の様々な組合せで低レベル最適化プロセスを実施して複数のデータポイントを生成することによって性能曲線を生成する。低レベル最適化を使用して、対応する加熱又は冷却負荷を満たすために必要とされる最小の資源消費量を決定することができる。低レベルオプティマイザ８３４によって実施することができる低レベル最適化プロセスの例は、２０１５年２月２７日出願の「ＬｏｗＬｅｖｅｌＣｅｎｔｒａｌＰｌａｎｔＯｐｔｉｍｉｚａｔｉｏｎ」という名称の米国特許出願第１４／６３４，６１５号に詳細に述べられており、その特許出願の開示全体が参照により本明細書に組み入れられる。低レベルオプティマイザ８３４は、データポイントに曲線を当てはめて、性能曲線を生成することがある。

いくつかの実施形態では、低レベルオプティマイザ８３４は、接続された機器６１０の個々のデバイスの効率曲線を組み合わせることにより、接続された機器６１０のセット（例えば、冷却器サブプラント、ヒータサブプラントなど）に関する機器性能曲線を生成する。デバイス効率曲線は、負荷の関数としてデバイスによる資源消費量を示すことがある。デバイス効率曲線は、デバイス製造業者によって提供されることがあるか、又は実験データを使用して生成されることもある。いくつかの実施形態において、デバイス効率曲線は、デバイス製造業者によって提供され、実験データを使用して更新された初期効率曲線に基づく。デバイス効率曲線は、機器モデル８１８に記憶され得る。いくつかのデバイスでは、デバイス効率曲線は、資源消費が負荷のＵ字関数であることを示すことがある。したがって、複数のデバイス効率曲線が組み合わされて複数のデバイスに関する性能曲線になるとき、得られる性能曲線は波状の曲線になり得る。これらの波は、単一のデバイスが負荷を上げることによって引き起こされ、その後、サブプラント負荷を満たすための別のデバイスの起動がより効率的になる。低レベルオプティマイザ８３４は、高レベル最適化プロセスで使用するために機器性能曲線を高レベルオプティマイザ８３２に提供することがある。

引き続き図８を参照すると、ＭＰＭシステム６０２が、機器コントローラ８２８を含むものとして示されている。機器コントローラ８２８は、接続された機器６１０を制御して、ビルディング１０での可変状態又は状況（例えば、温度、湿度など）に影響を与えるように構成することができる。いくつかの実施形態では、機器コントローラ８２８は、モデル予測オプティマイザ８３０によって実施された最適化の結果に基づいて、接続された機器６１０を制御する。いくつかの実施形態では、機器コントローラ８２８は、接続された機器６１０に通信インターフェース８０４及び／又はＢＭＳ６０６を介して提供することができる制御信号を生成する。制御信号は、目的関数Ｊでの決定変数の最適値に基づくことがある。例えば、機器コントローラ８２８は、接続された機器６１０に、最適化期間内の時間ステップｉごとの最適な電力消費量値Ｐ_ｏｐ，ｉを実現させる制御信号を生成することがある。

モデル予測オプティマイザ８３０、機器コントローラ８２８又はＭＰＭシステム６０２の他のモジュールからのデータ及び処理結果は、監視及び報告アプリケーション８２６によってアクセス（又は監視及び報告アプリケーション８２６にプッシュ）されることがある。監視及び報告アプリケーション８２６は、ユーザ（例えば、システムエンジニア）が閲覧及びナビゲートすることができるリアルタイム「システムヘルス」ダッシュボードを生成するように構成されることがある。例えば、監視及び報告アプリケーション８２６は、ＧＵＩのユーザに重要業績評価指標（ＫＰＩ）又は他の情報を表示するためのいくつかのグラフィカルユーザインターフェース（ＧＵＩ）要素（例えば、ウィジェット、ダッシュボードコントロール、ウィンドウなど）を有するウェブベースの監視アプリケーションを含むことがある。さらに、ＧＵＩ要素は、（実際の又はモデル化された）異なるビルディングや異なる構内などでのビルディング管理システムにわたる相対的なエネルギー使用量及び強度を要約することができる。他のＧＵＩ要素又はレポートは、利用可能なデータに基づいて生成されて示されることがあり、ユーザが、１つ又は複数のエネルギー貯蔵システムにわたる性能を１つの画面から評価できるようにする。ユーザインターフェース又はレポート（又は元のデータエンジン）は、ビルディング、ビルディングのタイプ、機器のタイプなどによって動作条件を集計及び分類するように構成されることがある。ＧＵＩ要素は、ビルディングシステムのデバイスに関する動作パラメータ及び電力消費量をユーザが視覚的に分析できるようにするチャート又はヒストグラムを含むことがある。

引き続き図８を参照すると、ＭＰＭシステム６０２は、監視及び報告アプリケーション８２６をサポートするために、１つ又は複数のＧＵＩサーバ、ウェブサービス８１２又はＧＵＩエンジン８１４を含むことがある。様々な実施形態において、アプリケーション８２６、ウェブサービス８１２及びＧＵＩエンジン８１４は、ＭＰＭシステム６０２の外部の別個の構成要素として（例えば、スマートビルディングマネージャの一部として）提供され得る。ＭＰＭシステム６０２は、関連データの詳細な履歴データベース（例えば、リレーショナルデータベース、ＸＭＬデータベースなど）を維持するように構成されることがあり、詳細なデータベースに維持されているデータに対して継続的に、頻繁に又は低頻度でクエリ、集約、変換、検索又は他の処理を行うコンピュータコードモジュールを含む。ＭＰＭシステム６０２は、任意のそのような処理の結果を、例えば外部監視及び報告アプリケーションによるさらなるクエリ、計算若しくはアクセスのために、他のデータベース、テーブル、ＸＭＬファイル又は他のデータ構造に提供するように構成されることがある。

ＭＰＭシステム６０２は、構成ツール８１６を含むものとして示されている。構成ツール８１６により、ＭＰＭシステム６０２がＢＭＳ６０６及び／又は接続された機器６１０での変化する条件にどのように応答するかをユーザが（例えば、グラフィカルユーザインターフェースを介して、プロンプト方式の「ウィザード」を介してなど）定義できるようにし得る。例示的実施形態では、構成ツール８１６により、接続された機器６１０の複数のデバイス、複数のビルディングシステム及び複数のエンタープライズ制御アプリケーション（例えば、作業指示管理システムアプリケーション、エンティティ資源プランニングアプリケーションなど）に及び得る条件応答シナリオをユーザが構築して記憶することができるようにする。例えば、構成ツール８１６は、様々な条件論理を使用して（例えば、サブシステムからの、イベント履歴からの）データを組み合わせる機能をユーザに提供することができる。様々な例示的実施形態では、条件論理は、条件間の単純な論理演算子（例えば、ＡＮＤ、ＯＲ、ＸＯＲなど）から、擬似コード構造又は複雑なプログラミング言語関数（より複雑な対話、条件文、ループなどを可能にする）まで含むことができる。構成ツール８１６は、そのような条件論理を構築するためのユーザインターフェースを提示することができる。ユーザインターフェースは、ユーザがグラフィックでポリシー及び応答を定義できるようにすることがある。いくつかの実施形態では、ユーザインターフェースは、ユーザが、予め記憶又は予め構成されたポリシーを選択し、そのポリシーを適合させるか、又はそのユーザのシステムと共に使用できるようにし得る。

高レベルオプティマイザ

次に、図９を参照すると、例示的実施形態に従って、高レベルオプティマイザ８３２をより詳細に示すブロック図が示されている。高レベルオプティマイザ８３２は、接続された機器６１０に関する最適なメンテナンス戦略を決定するように構成することができる。いくつかの実施形態では、最適なメンテナンス戦略は、最適化期間（例えば、３０週、５２週、１０年、３０年など）の継続期間にわたる接続された機器６１０の購入、メンテナンス及び動作に関連する総コストを最適化する決定事項の組である。これらの決定事項は、例えば、機器の購入の決定、機器のメンテナンスの決定及び機器の動作の決定を含むことができる。

高レベルオプティマイザ８３２は、動作コスト予測器９１０、メンテナンスコスト予測器９２０、資本コスト予測器９３０、目的関数生成器９３５及び目的関数オプティマイザ９４０を含むものとして示されている。コスト予測器９１０、９２０及び９３０は、モデル予測制御技法を使用して、いくつかの決定変数（例えば、メンテナンス決定、機器購入決定など）及び入力パラメータ（例えば、エネルギーコスト、デバイス効率、デバイス信頼性）の関数として総コストを表す目的関数を定式化することができる。動作コスト予測器９１０は、目的関数での動作コスト項を定式化するように構成することができる。同様に、メンテナンスコスト予測器９２０は、目的関数でのメンテナンスコスト項を定式化するように構成することができ、資本コスト予測器９３０は、目的関数での資本コスト項を定式化するように構成することができる。目的関数オプティマイザ９４０は、様々な最適化技法のいずれかを使用して目的関数を最適化（例えば、最小化）して、各決定変数に関する最適値を識別することができる。

高レベルオプティマイザ８３２によって生成することができる目的関数の一例は、次式で示される。

動作コスト予測器
動作コスト予測器９１０は、目的関数Ｊでの第１項を定式化するように構成することができる。目的関数Ｊの第１項は、最適化期間の継続期間にわたる接続された機器６１０の動作コストを表し、３つの変数又はパラメータ（すなわちＣ_ｏｐ，ｉ、Ｐ_ｏｐ，ｉ及びΔｔ）を含むものとして示されている。いくつかの実施形態では、単位エネルギーあたりのコストＣ_ｏｐ，ｉは、エネルギーコストモジュール９１５によって決定される。エネルギーコストモジュール９１５は、エネルギー価格データとして、公益企業６０８からエネルギー価格のセットを受信することができる。いくつかの実施形態では、エネルギー価格は、時刻、曜日（例えば、平日か週末か）、現在の季節（例えば、夏か冬か）又は他の時間ベースの因子に依存する時変コストであり得る。例えば、電気のコストは、ピークエネルギー消費期間中にはより高く、オフピーク又は部分ピークエネルギー消費期間中にはより低いことがある。

エネルギーコストモジュール９１５は、エネルギーコストを使用して、最適化期間内の時間ステップｉごとにＣ_ｏｐ，ｉの値を定義することができる。いくつかの実施形態において、エネルギーコストモジュール９１５は、最適化期間内のｈ個の時間ステップそれぞれに関するコスト要素を含むアレイＣ_ｏｐとしてエネルギーコストを記憶する。例えば、エネルギーコストモジュール９１５は、以下のアレイを生成することができる。
Ｃ_ｏｐ＝［Ｃ_ｏｐ，１Ｃ_ｏｐ，２ … Ｃ_ｏｐ，ｈ］
ここで、アレイＣ_ｏｐは、１×ｈのサイズを有し、アレイＣ_ｏｐの各要素は、最適化期間の特定の時間ステップｉ＝１．．．ｈに関するエネルギーコスト値Ｃ_ｏｐ，ｉを含む。

さらに図９を参照すると、動作コスト予測器９１０は、理想性能計算機９１２を含むものとして示されている。理想性能計算機９１２は、負荷／料金予測器８２２から負荷予測Ｌｏａｄ_ｉを受信することがあり、低レベルオプティマイザ８３４から性能曲線を受信することがある。上で論じたように、性能曲線は、接続された機器６１０のデバイス又はデバイスのセットの理想的な電力消費量Ｐ_{ｉｄｅａｌ}を、デバイス又はデバイスのセットに対する加熱又は冷却負荷の関数として定義することがある。例えば、接続された機器６１０の１つ又は複数のデバイスの性能曲線は、次式によって定義することができる。
Ｐ_{ｉｄｅａｌ，ｉ}＝ｆ（Ｌｏａｄ_ｉ）
ここで、Ｐ_{ｉｄｅａｌ，ｉ}は、時間ステップｉにおける接続された機器６１０の理想的な電力消費量（例えば、ｋＷ）であり、Ｌｏａｄ_ｉは、時間ステップにおける接続された機器６１０に対する負荷（例えば、トン単位での冷却負荷、ｋＷ単位での加熱負荷など）である。理想的な電力消費量Ｐ_{ｉｄｅａｌ，ｉ}は、接続された機器６１０の１つ又は複数のデバイスが完璧な効率で動作すると仮定したそれらの電力消費量を表すことがある。

理想性能計算機９１２は、接続された機器６１０のデバイス又はデバイスのセットに関する性能曲線を使用して、Ｐ_{ｉｄｅａｌ，ｉ}の値を識別することができ、この値は、最適化期間の各時間ステップにおけるデバイス又はデバイスのセットに関する負荷点Ｌｏａｄ_ｉに対応する。いくつかの実施形態では、理想性能計算機９１２は、最適化期間内のｈ個の時間ステップそれぞれに関する要素を含むアレイＰ_{ｉｄｅａｌ}として、理想的な負荷値を記憶する。例えば、理想性能計算機９１２は、以下のアレイを生成することができる。
Ｐ_{ｉｄｅａｌ}＝［Ｐ_{ｉｄｅａｌ，１} Ｐ_{ｉｄｅａｌ，２} … Ｐ_{ｉｄｅａｌ，ｈ}］^Ｔ
ここで、アレイＰ_{ｉｄｅａｌ}は、ｈ×１のサイズを有し、アレイＰ_{ｉｄｅａｌ}の各要素は、最適化期間の特定の時間ステップｉ＝１．．．ｈに関する理想的な電力消費量値Ｐ_{ｉｄｅａｌ，ｉ}を含む。

引き続き図９を参照すると、動作コスト予測器９１０が、効率アップデータ９１１及び効率デグレーダ９１３を含むものとして示されている。効率アップデータ９１１は、実際の動作条件下での接続された機器６１０の効率ηを決定するように構成することができる。いくつかの実施形態では、効率η_ｉは、次式で示されるように、接続された機器の理想的な電力消費量Ｐ_{ｉｄｅａｌ}と、接続された機器６１０の実際の電力消費量Ｐ_{ａｃｔｕａｌ}との比を表す。

ここで、Ｐ_{ｉｄｅａｌ}は、接続された機器６１０に関する性能曲線によって定義される接続された機器６１０の理想的な電力消費量であり、Ｐ_{ａｃｔｕａｌ}は、接続された機器６１０の実際の電力消費量である。いくつかの実施形態では、効率アップデータ９１１は、接続された機器６１０から収集された機器性能情報を使用して、実際の電力消費量値Ｐ_{ａｃｔｕａｌ}を識別する。効率アップデータ９１１は、実際の電力消費量Ｐ_{ａｃｔｕａｌ}を理想的な電力消費量Ｐ_{ｉｄｅａｌ}と組み合わせて使用して、効率ηを計算することができる。

効率アップデータ９１１は、接続された機器６１０の現在の動作効率を反映するために効率ηを定期的に更新するように構成することができる。例えば、効率アップデータ９１１は、接続された機器６１０の効率ηを、１日に１回、１週間に１回、１年に１回又は時間と共に効率ηの変化を捕捉するのに適切であり得る任意の他の間隔で計算することができる。効率ηの各値は、効率ηが計算される時点でのＰ_{ｉｄｅａｌ}及びＰ_{ａｃｔｕａｌ}の対応する値に基づき得る。いくつかの実施形態では、効率アップデータ９１１は、高レベル最適化プロセスが実施されるたびに（すなわち目的関数Ｊが最適化されるたびに）効率ηを更新する。効率アップデータ９１１によって計算された効率値は、初期効率値η_０としてメモリ８１０に記憶されることがあり、ここで、下付き数字０は、最適化期間の開始時又は開始前（例えば、時間ステップ０で）の効率ηの値を表す。

いくつかの実施形態では、効率アップデータ９１１は、接続された機器６１０に対するメンテナンスの実施又は接続された機器６１０の１つ若しくは複数のデバイスを交換若しくは補完するための新たな機器の購入により生じる接続された機器６１０の効率ηの上昇を考慮に入れるために、最適化期間中の１つ又は複数の時間ステップに関する効率η_ｉを更新する。効率η_ｉが更新される時間ステップｉは、メンテナンスが実施されることになるか、又は機器が交換されることになる予測時間ステップに対応することがある。接続された機器６１０に対してメンテナンスが実施されることになる予測時間ステップは、目的関数Ｊでのバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}の値によって定義することができる。同様に、機器が交換されることになる予測時間ステップは、目的関数Ｊでのバイナリ決定変数Ｂ_{ｃａｐ，ｉ}の値によって定義することができる。

効率アップデータ９１１は、その時間ステップにおいてメンテナンスが実施されること及び／又はその時間ステップにおいて新たな機器が購入されることをバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}が示す場合（すなわちＢ_{ｍａｉｎ，ｉ}＝１及び／又はＢ_{ｃａｐ，ｉ}＝１）、所与の時間ステップｉに関する効率η_ｉをリセットするように構成することができる。例えば、Ｂ_{ｍａｉｎ，ｉ}＝１の場合、効率アップデータ９１１は、η_ｉの値をη_ｍａｉｎにリセットするように構成することができ、ここで、η_ｍａｉｎは、時間ステップｉにおいて実施されるメンテナンスにより得られると期待される効率値である。同様に、Ｂ_{ｃａｐ，ｉ}＝１の場合、効率アップデータ９１１は、η_ｉの値をη_ｃａｐにリセットするように構成することができ、ここで、η_ｃａｐは、時間ステップｉにおいて実施される接続された機器６１０の１つ又は複数のデバイスを補完又は交換するために新たなデバイスを購入することにより得られると期待される効率値である。効率アップデータ９１１は、１つ又は複数の時間ステップに関して効率η_ｉを動的にリセットすることができ、（例えば、最適化の各反復によって）バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}の値に基づいて最適化が実施される。

効率デグレーダ９１３は、最適化期間の各時間ステップｉにおける接続された機器６１０の効率η_ｉを予測するように構成することができる。最適化期間の開始時の初期効率η_０は、接続された機器６１０の性能が低下するにつれて、時間と共に低下することがある。例えば、冷却器の効率は、冷却水管が汚れて冷却器の熱伝達率が低下した結果、時間と共に低下することがある。同様に、バッテリの物理的又は化学的構成要素の劣化により、バッテリの効率は、時間と共に低下することがある。効率デグレーダ９１３は、そのような低下を、最適化期間の継続時間にわたって効率η_ｉを段階的に低下させることによって考慮に入れるように構成することができる。

いくつかの実施形態では、初期効率値η_０は、各最適化期間の開始時に更新される。しかし、効率ηは、最適化期間中に低下することがあり、初期効率値η_０は、最適化期間の継続期間にわたって次第に不正確になる。最適化期間中の効率低下を考慮に入れるために、効率デグレーダ９１３は、連続する各時間ステップにおいて効率ηを所定量だけ低下させることができる。例えば、効率デグレーダ９１３は、各時間ステップｉ＝１．．．ｈでの効率を以下のように定義することができる。
η_ｉ＝η_ｉ−１−Δη
ここで、η_ｉは、時間ステップｉにおける効率であり、η_ｉ−１は、時間ステップｉ−１での効率であり、Δηは、連続する時間ステップ間での効率の低下である。いくつかの実施形態では、η_ｉのこの定義は、Ｂ_{ｍａｉｎ，ｉ}＝０及びＢ_{ｃａｐ，ｉ}＝０である各時間ステップに適用される。しかし、Ｂ_{ｍａｉｎ，ｉ}＝１又はＢ_{ｃａｐ，ｉ}＝１である場合、η_ｉの値は、前述したようにη_ｍａｉｎ又はη_ｃａｐにリセットされ得る。

いくつかの実施形態では、Δηの値は、効率アップデータ９１１によって計算された効率値の時系列に基づいている。例えば、効率デグレーダ９１３は、効率アップデータ９１１によって計算された初期効率値η_０の時系列を記録することがあり、ここで、各初期効率値η_０は、特定の時点における接続された機器６１０の経験的に計算された効率を表す。効率デグレーダ９１３は、初期効率値η_０の時系列を検査して、効率が低下する率を決定することができる。例えば、時点ｔ_１での初期効率η_０がη_０，１であり、時点ｔ_２での初期効率がη_０，２である場合、効率デグレーダ９１３は、効率低下率を以下のように計算することができる。

ここで、

は、効率低下率である。効率デグレーダ９１３は、

に、各時間ステップの継続時間Δｔを乗算して、Δηの値を計算することができる（すなわち、

）。

いくつかの実施形態では、効率デグレーダ９１３は、最適化期間内のｈ個の時間ステップそれぞれに関する要素を含むアレイηに、最適化期間の継続期間にわたる効率値を記憶する。例えば、効率デグレーダ９１３は、以下のアレイを生成することができる。
η＝［η_１ η_２ … η_ｈ］
ここで、アレイηは、ｈ×１のサイズを有し、アレイηの各要素は、最適化期間の特定の時間ステップｉ＝１．．．ｈに関する効率値η_ｉを含む。アレイηの各要素ｉは、前の要素の値とΔηの値とに基づいて計算されることがある（例えば、Ｂ_{ｍａｉｎ，ｉ}＝０及びＢ_{ｃａｐ，ｉ}＝０の場合）か、又はη_ｍａｉｎ又はη_ｃａｐに動的にリセットされることがある（例えば、Ｂ_{ｍａｉｎ，ｉ}＝１又はＢ_{ｃａｐ，ｉ}＝１の場合）。

効率アップデータ９１１及び効率デグレーダ９１３によって実施される効率更新及びリセット動作を特徴付ける論理は、次式で要約することができる。
Ｂ_{ｍａｉｎ，ｉ}＝１の場合 → η_ｉ＝η_ｍａｉｎ
Ｂ_{ｃａｐ，ｉ}＝１の場合 → η_ｉ＝η_ｃａｐ
Ｂ_{ｍａｉｎ，ｉ}＝０及びＢ_{ｃａｐ，ｉ}＝０の場合 → η_ｉ＝η_ｉ−１−Δη
これは、目的関数オプティマイザ９４０によって実施される高レベル最適化に対する制約として適用することができる。

有利には、効率アップデータ９１１及び効率デグレーダ９１３は、各時間ステップｉにおける接続された機器６１０の効率η_ｉを、メンテナンス決定Ｂ_{ｍａｉｎ，ｉ}及び機器購入決定Ｂ_{ｃａｐ，ｉ}の関数としてモデル化することができる。例えば、特定のデバイスに関する効率η_ｉは、最適化期間の開始時に初期値η_０で始まることがあり、時間と共に低下し、連続する各時間ステップｉと共に効率η_ｉが低下することがある。デバイスに対するメンテナンスを実施することで、メンテナンスが実施された直後に効率η_ｉをより高い値にリセットすることができる。同様に、新たなデバイスを購入して既存のデバイスと交換することで、新たなデバイスが購入された直後に効率η_ｉをより高い値にリセットすることができる。リセット後、効率η_ｉは、メンテナンスが実施されるか又は新たなデバイスが購入される次の時点まで、時間と共に低下し続けることがある。

引き続き図９を参照すると、動作コスト予測器９１０は、電力消費量推定器９１４及び動作コスト計算機９１６を含むものとして示されている。電力消費量推定器９１４は、最適化期間の各時間ステップｉにおける接続された機器６１０の電力消費量Ｐ_ｏｐ，ｉを推定するように構成することができる。いくつかの実施形態では、電力消費量推定器９１４は、理想性能計算機９１２によって計算された理想電力消費量Ｐ_{ｉｄｅａｌ，ｉ}と、効率デグレーダ９１３及び／又は効率アップデータ９１１によって決定された効率η_ｉとの関数として、電力消費量Ｐ_ｏｐ，ｉを推定する。例えば、電力消費量推定器９１４は、次式を使用して電力消費量Ｐ_ｏｐ，ｉを計算することができる。

ここで、Ｐ_{ｉｄｅａｌ，ｉ}は、対応する負荷点Ｌｏａｄ_ｉでのデバイスに関する機器性能曲線に基づいて理想性能計算機９１２によって計算された電力消費量であり、η_ｉは、時間ステップｉにおけるデバイスの動作効率である。

いくつかの実施形態では、電力消費量推定器９１４は、最適化期間内のｈ個の時間ステップそれぞれに関する要素を含むアレイＰ_ｏｐとして電力消費量値を記憶する。例えば、電力消費量推定器９１４は、以下のアレイを生成することができる。
Ｐ_ｏｐ＝［Ｐ_ｏｐ，１Ｐ_ｏｐ，２ … Ｐ_ｏｐ，ｈ］^Ｔ
ここで、アレイＰ_ｏｐは、ｈ×１のサイズを有し、アレイＰ_ｏｐの各要素は、最適化期間の特定の時間ステップｉ＝１．．．ｈに関する理想的な電力消費量値Ｐ_ｏｐ，ｉを含む。

動作コスト計算機９１６は、最適化期間の継続期間にわたる接続された機器６１０の動作コストを推定するように構成することができる。いくつかの実施形態では、動作コスト計算機９１６は、次式を使用して各時間ステップｉ中の動作コストを計算する。
Ｃｏｓｔ_ｏｐ，ｉ＝Ｃ_ｏｐ，ｉＰ_ｏｐ，ｉΔｔ
ここで、Ｐ_ｏｐ，ｉは、電力消費量推定器９１４によって決定される時間ステップｉにおける予測電力消費量であり、Ｃ_ｏｐ，ｉは、エネルギーコストモジュール９１５によって決定される時間ステップｉにおける単位エネルギーあたりのコストであり、Δｔは、各時間ステップの継続期間である。動作コスト計算機９１６は、以下のように、最適化期間の継続期間にわたる動作コストを合計することができる。

ここで、Ｃｏｓｔ_ｏｐは、目的関数Ｊの動作コスト項である。

他の実施形態では、動作コスト計算機９１６は、次式で示されるように、コストアレイＣ_ｏｐに電力消費量アレイＰ_ｏｐ及び各時間ステップの継続時間Δｔを乗算することにより、動作コストＣｏｓｔ_ｏｐを推定する。
Ｃｏｓｔ_ｏｐ＝Ｃ_ｏｐＰ_ｏｐΔｔ
Ｃｏｓｔ_ｏｐ＝［Ｃ_ｏｐ，１Ｃ_ｏｐ，２ … Ｃ_ｏｐ，ｈ］［Ｐ_ｏｐ，１Ｐ_ｏｐ，２ … Ｐ_ｏｐ，ｈ］^ＴΔｔ

メンテナンスコスト予測器

メンテナンスコスト予測器９２０は、目的関数Ｊでの第２項を定式化するように構成することができる。目的関数Ｊでの第２項は、最適化期間の継続期間にわたる、接続された機器６１０に対するメンテナンスを実施するコストを表し、２つの変数又はパラメータ（すなわちＣ_{ｍａｉｎ，ｉ}及びＢ_{ｍａｉｎ，ｉ}）を含むものとして示されている。メンテナンスコスト予測器９２０は、メンテナンス推定器９２２、信頼性推定器９２４、メンテナンスコスト計算機９２６及びメンテナンスコストモジュール９２８を含むものとして示されている。

信頼性推定器９２４は、接続された機器６１０から受信された機器性能情報に基づいて、接続された機器６１０の信頼性を推定するように構成することができる。信頼性は、接続された機器６１０がその現在の動作条件下で障害なく動作し続ける尤度の統計的尺度であり得る。より過酷な条件下（例えば、高負荷、高温など）での動作は、信頼性をより低くすることがあり、より過酷でない条件下（例えば、低負荷、中程度の温度など）での動作は、信頼性をより高くすることがある。いくつかの実施形態では、信頼性は、接続された機器６１０が最後にメンテナンスを受けてから経過した時間量及び／又は接続された機器６１０が購入若しくは設置されてから経過した時間量に基づく。

いくつかの実施形態では、信頼性推定器９２４は、機器性能情報を使用して、接続された機器６１０の現在の動作条件を識別する。信頼性推定器９２４によって現在の動作条件を検査して、接続された機器６１０の性能が低下し始めるときを明らかにし、及び／又は障害が発生するときを予測することができる。いくつかの実施形態では、信頼性推定器９２４は、接続された機器６１０で潜在的に発生し得る様々なタイプの故障の尤度を推定する。各故障の尤度は、接続された機器６１０の現在の動作条件、接続された機器６１０が設置されてから経過した時間量及び／又はメンテナンスが最後に実施されてから経過した時間量に基づくことがある。いくつかの実施形態では、信頼性推定器９２４は、２０１６年６月２１日出願の「ＢｕｉｌｄｉｎｇＭａｎａｇｅｍｅｎｔＳｙｓｔｅｍＷｉｔｈＰｒｅｄｉｃｔｉｖｅＤｉａｇｎｏｓｔｉｃｓ」という名称の米国特許出願第１５／１８８，８２４号に記載のシステム及び方法を使用して、動作条件を識別し、様々な故障の尤度を予測する。上記特許出願の開示全体が参照により本明細書に組み入れられる。

いくつかの実施形態では、信頼性推定器９２４は、複数のビルディングにわたって分散された接続された機器６１０の複数のデバイスから動作データを受信する。動作データは、例えば、現在の動作条件、障害標示、故障時間又は接続された機器６１０の動作及び性能を特徴付ける他のデータを含むことができる。信頼性推定器９２４は、動作データのセットを使用して、各タイプの機器に関する信頼性モデルを作成することができる。信頼性推定器９２４が信頼性モデルを使用して、接続された機器６１０の任意の所与のデバイスの信頼性を、その現在の動作条件及び／又は他の外的要因（例えば、メンテナンスが最後に実施されてからの時間、設置又は購入からの時間、地理的位置、水質など）に応じて推定することができる。

信頼性推定器９２４が使用することができる信頼性モデルの一例は、次式で示される。
Ｒｅｌｉａｂｉｌｉｔｙ_ｉ＝ｆ（ＯｐＣｏｎｄ_ｉ，Δｔ_{ｍａｉｎ，ｉ}，Δｔ_{ｃａｐ，ｉ}）
ここで、Ｒｅｌｉａｂｉｌｉｔｙ_ｉは、時間ステップｉにおける接続された機器６１０の信頼性であり、ＯｐＣｏｎｄ_ｉは、時間ステップｉにおける動作条件であり、Δｔ_{ｍａｉｎ，ｉ}は、メンテナンスが最後に行われた時点と時間ステップｉとの間で経過した時間量であり、Δｔ_{ｃａｐ，ｉ}は、接続された機器６１０が購入又は設置された時点と時間ステップｉとの間で経過した時間量である。信頼性推定器９２４は、接続された機器６１０からフィードバックとして受信された機器性能情報に基づいて現在の動作条件ＯｐＣｏｎｄ_ｉを識別するように構成することができる。より過酷な条件下（例えば、高負荷、極端な温度など）での動作は、信頼性をより低くすることがあり、より過酷でない条件下（例えば、低負荷、中程度の温度など）での動作は、信頼性をより高くすることがある。

信頼性推定器９２４は、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}の値に基づいて、接続された機器６１０に対してメンテナンスが最後に実施されてから経過した時間量Δｔ_{ｍａｉｎ，ｉ}を決定することがある。各時間ステップｉに関して、信頼性推定器９２４は、時間ステップｉ及び前の各時間ステップ（例えば、時間ステップｉ−１、ｉ−２、．．．、１）におけるＢ_ｍａｉｎの対応する値を検査することができる。信頼性推定器９２４は、メンテナンスが最後に実施された時点（すなわちＢ_{ｍａｉｎ，ｉ}＝１である直近の時点）を、時間ステップｉに関連する時点から引くことにより、Δｔ_{ｍａｉｎ，ｉ}の値を計算することができる。メンテナンスが最後に実施されてからの時間量Δｔ_{ｍａｉｎ，ｉ}が長いと、信頼性がより低くなることがあり、メンテナンスが最後に実施されてからの時間量が短いと、信頼性がより高くなることがある。

同様に、信頼性推定器９２４は、バイナリ決定変数Ｂ_{ｃａｐ，ｉ}の値に基づいて、接続された機器６１０が購入又は設置されてから経過した時間量Δｔ_{ｃａｐ，ｉ}を決定することがある。各時間ステップｉに関して、信頼性推定器９２４は、時間ステップｉ及び前の各時間ステップ（例えば、時間ステップｉ−１、ｉ−２、．．．、１）におけるＢ_ｃａｐの対応する値を検査することができる。信頼性推定器９２４は、接続された機器６１０が購入又は設置された時点（すなわちＢ_{ｃａｐ，ｉ}＝１である直近の時点）を、時間ステップｉに関連する時点から引くことにより、Δｔ_{ｃａｐ，ｉ}の値を計算することができる。接続された機器６１０が購入又は設置されてからの時間量Δｔ_{ｃａｐ，ｉ}が長いと、信頼性がより低くなることがあり、接続された機器６１０が購入又は設置されてからの時間量が短いと、信頼性がより高くなることがある。

信頼性推定器９２４は、その時間ステップにおいてメンテナンスが実施されること及び／又はその時間ステップにおいて新たな機器が購入されることをバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}が示す場合（すなわちＢ_{ｍａｉｎ，ｉ}＝１及び／又はＢ_{ｃａｐ，ｉ}＝１）、所与の時間ステップｉに関する信頼性をリセットするように構成することができる。例えば、Ｂ_{ｍａｉｎ，ｉ}＝１の場合、信頼性推定器９２４は、Ｒｅｌｉａｂｉｌｉｔｙ_ｉの値をＲｅｌｉａｂｉｌｉｔｙ_ｍａｉｎにリセットするように構成することができ、ここで、Ｒｅｌｉａｂｉｌｉｔｙ_ｍａｉｎは、時間ステップｉにおいて実施されるメンテナンスにより得られると期待される信頼性値である。同様に、Ｂ_{ｃａｐ，ｉ}＝１の場合、信頼性推定器９２４は、Ｒｅｌｉａｂｉｌｉｔｙ_ｉの値をＲｅｌｉａｂｉｌｉｔｙ_ｃａｐにリセットするように構成することができ、ここで、Ｒｅｌｉａｂｉｌｉｔｙ_ｃａｐは、時間ステップｉにおいて実施される接続された機器６１０の１つ又は複数のデバイスを補完又は交換するために新たなデバイスを購入することにより得られると期待される信頼性値である。信頼性推定器９２４は、１つ又は複数の時間ステップに関して信頼性を動的にリセットすることができ、（例えば、最適化の各反復によって）バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}の値に基づいて最適化が実施される。

メンテナンス推定器９２２は、最適化期間の継続期間にわたる接続された機器６１０の推定された信頼性を使用して、最適化期間の各時間ステップにおいて接続された機器６１０がメンテナンス及び／又は交換を必要とする確率を決定するように構成することができる。いくつかの実施形態では、メンテナンス推定器９２２は、接続された機器６１０が所与の時間ステップにおいてメンテナンスを必要とする確率を臨界値と比較するように構成される。メンテナンス推定器９２２は、時間ステップｉにおいて接続された機器６１０がメンテナンスを必要とする確率が臨界値を超えるという決定に応答して、Ｂ_{ｍａｉｎ，ｉ}＝１の値を設定するように構成することができる。同様に、メンテナンス推定器９２２は、接続された機器６１０が所与の時間ステップにおいて交換を必要とする確率を臨界値と比較するように構成することができる。メンテナンス推定器９２２は、時間ステップｉにおいて接続された機器６１０が交換を必要とする確率が臨界値を超えるという決定に応答して、Ｂ_{ｃａｐ，ｉ}＝１の値を設定するように構成することができる。

いくつかの実施形態では、接続された機器６１０の信頼性とバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}の値とに相互関係がある。言い換えると、接続された機器６１０の信頼性は、最適化で選択されるバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}の値に影響を与えることができ、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}の値は、接続された機器６１０の信頼性に影響を与えることができる。有利には、目的関数オプティマイザ９４０によって実施される最適化は、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}と接続された機器６１０の信頼性との相互関係を考慮に入れながら、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}の最適値を識別することができる。

いくつかの実施形態では、メンテナンス推定器９２２は、バイナリメンテナンス決定変数の行列Ｂ_ｍａｉｎを生成する。行列Ｂ_ｍａｉｎは、最適化期間の各時間ステップにおいて実施することができる様々なメンテナンス活動それぞれに関するバイナリ決定変数を含むことがある。例えば、メンテナンス推定器９２２は、以下の行列を生成することができる。

ここで、行列Ｂ_ｍａｉｎは、サイズがｍ×ｈであり、行列Ｂ_ｍａｉｎの各要素は、最適化期間の特定の時間ステップにおける特定のメンテナンス活動に関するバイナリ決定変数を含む。例えば、バイナリ決定変数Ｂ_{ｍａｉｎ，ｊ，ｉ}の値は、第ｊのメンテナンス活動が最適化期間の第ｉの時間ステップ中に実施されるか否かを示す。

引き続き図９を参照すると、メンテナンスコスト予測器９２０は、メンテナンスコストモジュール９２８及びメンテナンスコスト計算機９２６を含むものとして示されている。メンテナンスコストモジュール９２８は、接続された機器６１０の様々なタイプのメンテナンスの実施に関連するコストＣ_{ｍａｉｎ，ｉ}を決定するように構成することができる。メンテナンスコストモジュール９２８は、外部システム又はデバイス（例えば、データベース、ユーザデバイスなど）からメンテナンスコストのセットを受信することができる。いくつかの実施形態では、メンテナンスコストは、様々なタイプのメンテナンスを実施する経済的コスト（例えば、ドル）を定義する。各タイプのメンテナンス活動は、それに関連する異なる経済的コストを有することがある。例えば、冷却器圧縮機内のオイルを交換するメンテナンス活動にかかる経済的コストは、比較的小さいことがあり、冷却器を完全に分解してすべての冷却水管を洗浄するメンテナンス活動にかかる経済的コストは、かなり大きいことがある。

メンテナンスコストモジュール９２８は、メンテナンスコストを使用して、目的関数ＪでのＣ_{ｍａｉｎ，ｉ}の値を定義することができる。いくつかの実施形態では、メンテナンスコストモジュール９２８は、実施することができるメンテナンス活動それぞれに関するコスト要素を含むアレイＣ_ｍａｉｎとしてメンテナンスコストを記憶する。例えば、メンテナンスコストモジュール９２８は、以下のアレイを生成することができる。
Ｃ_ｍａｉｎ＝［Ｃ_{ｍａｉｎ，１} Ｃ_{ｍａｉｎ，２} … Ｃ_{ｍａｉｎ，ｍ}］
ここで、アレイＣ_ｍａｉｎは、サイズが１×ｍであり、アレイＣ_ｍａｉｎの各要素は、特定のメンテナンス活動ｊ＝１．．．ｍに関するメンテナンスコスト値Ｃ_{ｍａｉｎ，ｊ}を含む。

いくつかのメンテナンス活動は、他よりもコストがかかることがある。しかし、異なるタイプのメンテナンス活動が、接続された機器６１０の効率η及び／又は信頼性に対する異なるレベルの改良をもたらすことがある。例えば、冷却器内のオイルの単なる交換は、効率ηのわずかな改良及び／又は信頼性のわずかな改良をもたらすことがあり、冷却器の完全な分解及びすべての冷却水管の洗浄は、接続された機器６１０の効率η及び／又は信頼性のかなり大きい改良をもたらすことがある。したがって、複数の異なるレベルのメンテナンス後の効率（すなわちη_ｍａｉｎ）及びメンテナンス後の信頼性（すなわちＲｅｌｉａｂｉｌｉｔｙ_ｍａｉｎ）が存在し得る。η_ｍａｉｎ及びＲｅｌｉａｂｉｌｉｔｙ_ｍａｉｎの各レベルは、異なるタイプのメンテナンス活動に対応することがある。

いくつかの実施形態では、メンテナンス推定器９２２は、異なるレベルのη_ｍａｉｎ及びＲｅｌｉａｂｉｌｉｔｙ_ｍａｉｎそれぞれを、対応するアレイに記憶する。例えば、パラメータη_ｍａｉｎは、ｍ個の異なるタイプのメンテナンス活動それぞれに関する要素を有するアレイη_ｍａｉｎとして定義することができる。同様に、パラメータＲｅｌｉａｂｉｌｉｔｙ_ｍａｉｎは、ｍ個の異なるタイプのメンテナンス活動それぞれに関する要素を有するアレイＲｅｌｉａｂｉｌｉｔｙ_ｍａｉｎとして定義することができる。これらのアレイの例は、次式で示される。
η_ｍａｉｎ＝［η_{ｍａｉｎ，１} η_{ｍａｉｎ，２} … η_{ｍａｉｎ，ｍ}］
Ｒｅｌｉａｂｉｌｉｔｙ_ｍａｉｎ＝［Ｒｅｌｉａｂｉｌｉｔｙ_{ｍａｉｎ，１} Ｒｅｌｉａｂｉｌｉｔｙ_{ｍａｉｎ，２} … Ｒｅｌｉａｂｉｌｉｔｙ_{ｍａｉｎ，ｍ}］
ここで、アレイη_ｍａｉｎは、サイズが１×ｍであり、アレイη_ｍａｉｎの各要素は、特定のメンテナンス活動に関するメンテナンス後の効率値η_{ｍａｉｎ，ｊ}を含む。同様に、アレイＲｅｌｉａｂｉｌｉｔｙ_ｍａｉｎは、サイズが１×ｍであり、アレイＲｅｌｉａｂｉｌｉｔｙ_ｍａｉｎの各要素は、特定のメンテナンス活動に関するメンテナンス後の信頼性値Ｒｅｌｉａｂｉｌｉｔｙ_{ｍａｉｎ，ｊ}を含む。

いくつかの実施形態では、効率アップデータ９１１は、各バイナリ決定変数Ｂ_{ｍａｉｎ，ｊ，ｉ}に関連するメンテナンス活動を識別し、Ｂ_{ｍａｉｎ，ｊ，ｉ}＝１の場合、効率ηを、対応するメンテナンス後の効率レベルη_{ｍａｉｎ，ｊ}にリセットする。同様に、信頼性推定器９２４は、各バイナリ決定変数Ｂ_{ｍａｉｎ，ｊ，ｉ}に関連するメンテナンス活動を識別することができ、Ｂ_{ｍａｉｎ，ｊ，ｉ}＝１の場合、信頼性を、対応するメンテナンス後の信頼性レベルＲｅｌｉａｂｉｌｉｔｙ_{ｍａｉｎ，ｊ}にリセットすることができる。

メンテナンスコスト計算機９２６は、最適化期間の継続期間にわたる接続された機器６１０のメンテナンスコストを推定するように構成することができる。いくつかの実施形態では、メンテナンスコスト計算機９２６は、次式を使用して各時間ステップｉ中のメンテナンスコストを計算する。
Ｃｏｓｔ_{ｍａｉｎ，ｉ}＝Ｃ_{ｍａｉｎ，ｉ}Ｂ_{ｍａｉｎ，ｉ}
ここで、Ｃ_{ｍａｉｎ，ｉ}は、時間ステップｉにおいて実施することができるｍ個の異なるタイプのメンテナンス活動それぞれに関する要素を含むメンテナンスコストのアレイであり、Ｂ_{ｍａｉｎ，ｉ}は、ｍ個のメンテナンス活動それぞれが時間ステップｉにおいて実施されるか否かを示すバイナリ決定変数のアレイである。メンテナンスコスト計算機９２６は、以下のように、最適化期間の継続期間にわたってメンテナンスコストを合計することができる。

ここで、Ｃｏｓｔ_ｍａｉｎは、目的関数Ｊのメンテナンスコスト項である。

他の実施形態では、メンテナンスコスト計算機９２６は、次式に示されるように、メンテナンスコストアレイＣ_ｍａｉｎにバイナリ決定変数の行列Ｂ_ｍａｉｎを乗算することによってメンテナンスコストＣｏｓｔ_ｍａｉｎを推定する。

資本コスト予測器
資本コスト予測器９３０は、目的関数Ｊでの第３項を定式化するように構成することができる。目的関数Ｊでの第３項は、最適化期間の継続期間にわたる接続された機器６１０の新しいデバイスを購入するコストを表し、２つの変数又はパラメータ（すなわちＣ_{ｃａｐ，ｉ}及びＢ_{ｃａｐ，ｉ}）を含むものとして示されている。資本コスト予測器９３０は、購入推定器９３２、信頼性推定器９３４、資本コスト計算機９３６及び資本コストモジュール９３８を含むものとして示されている。

信頼性推定器９３４は、メンテナンスコスト予測器９２０を参照して述べたように、信頼性推定器９２４の特徴のいくつか又はすべてを含むことができる。例えば、信頼性推定器９３４は、接続された機器６１０から受信された機器性能情報に基づいて、接続された機器６１０の信頼性を推定するように構成することができる。信頼性は、接続された機器６１０がその現在の動作条件下で障害なく動作し続ける尤度の統計的尺度であり得る。より過酷な条件下（例えば、高負荷、高温など）での動作は、信頼性をより低くすることがあり、より過酷でない条件下（例えば、低負荷、中程度の温度など）での動作は、信頼性をより高くすることがある。いくつかの実施形態では、信頼性は、接続された機器６１０が最後にメンテナンスを受けてから経過した時間量及び／又は接続された機器６１０が購入若しくは設置されてから経過した時間量に基づく。信頼性推定器９３４は、前述したように、信頼性推定器９２４の特徴及び／又は機能のいくつか又はすべてを含むことができる。

購入推定器９３２は、最適化期間の継続期間にわたる接続された機器６１０の推定された信頼性を使用して、最適化期間の各時間ステップにおいて接続された機器６１０の新たなデバイスが購入される確率を決定するように構成することができる。いくつかの実施形態では、購入推定器９３２は、所与の時間ステップにおいて接続された機器６１０の新たなデバイスが購入される確率を臨界値と比較するように構成される。購入推定器９３２は、時間ステップｉにおいて接続された機器６１０が購入される確率が臨界値を超えるという決定に応答して、Ｂ_{ｃａｐ，ｉ}＝１の値を設定するように構成することができる。

いくつかの実施形態では、購入推定器９３２は、バイナリ資本決定変数の行列Ｂ_ｃａｐを生成する。行列Ｂ_ｃａｐは、最適化期間の各時間ステップにおいて行うことができる様々な資本購入それぞれに関するバイナリ決定変数を含むことができる。例えば、購入推定器９３２は、以下の行列を生成することができる。

ここで、行列Ｂ_ｃａｐは、サイズがｐ×ｈであり、行列Ｂ_ｃａｐの各要素は、最適化期間の特定の時間ステップにおける特定の資本購入に関するバイナリ決定変数を含む。例えば、バイナリ決定変数Ｂ_{ｃａｐ，ｋ，ｉ}の値は、最適化期間の第ｉの時間ステップ中に第ｋの資本購入が行われるか否かを示す。

引き続き図９を参照すると、資本コスト予測器９３０は、資本コストモジュール９３８及び資本コスト計算機９３６を含むものとして示されている。資本コストモジュール９３８は、様々な資本購入（すなわち接続された機器６１０の１つ又は複数の新たなデバイスの購入）に関連するコストＣ_{ｃａｐ，ｉ}を決定するように構成することができる。資本コストモジュール９３８は、外部システム又はデバイス（例えば、データベース、ユーザデバイスなど）から資本コストのセットを受信することができる。いくつかの実施形態では、資本コストは、様々な資本購入を行う経済的コスト（例えば、ドル）を定義する。各タイプの資本購入は、それに関連する異なる経済的コストを有することがある。例えば、新たな温度センサの購入にかかる経済的コストは比較的小さいことがあり、新たな冷却器の購入にかかる経済的コストはかなり大きいことがある。

資本コストモジュール９３８は、購入コストを使用して、目的関数ＪでのＣ_{ｃａｐ，ｉ}の値を定義することができる。いくつかの実施形態では、資本コストモジュール９３８は、行うことができる資本購入それぞれに関するコスト要素を含むアレイＣ_ｃａｐとして資本コストを記憶する。例えば、資本コストモジュール９３８は、以下のアレイを生成することができる。
Ｃ_ｃａｐ＝［Ｃ_{ｃａｐ，１} Ｃ_{ｃａｐ，２} … Ｃ_{ｃａｐ，ｐ}］
ここで、アレイＣ_ｃａｐは、サイズが１×ｐであり、アレイＣ_ｃａｐの各要素は、特定の資本購入ｋ＝１．．．ｐに関するコスト値Ｃ_{ｃａｐ，ｋ}を含む。

いくつかの資本購入は、他のものよりも高価であり得る。しかし、異なるタイプの資本購入が、接続された機器６１０の効率η及び／又は信頼性に対する異なるレベルの改良をもたらすことがある。例えば、既存のセンサの交換のために新たなセンサを購入することで、効率ηがわずかに向上し、且つ／又は信頼性がわずかに向上することがあり、新たな冷却器及び制御システムを購入することで、接続された機器６１０の効率η及び／又は信頼性がかなり大きく向上することがある。したがって、複数の異なるレベルの購入後の効率（すなわちη_ｃａｐ）及び購入後の信頼性（すなわちＲｅｌｉａｂｉｌｉｔｙ_ｃａｐ）があり得る。η_ｃａｐ及びＲｅｌｉａｂｉｌｉｔｙ_ｃａｐの各レベルは、異なるタイプの資本購入に対応することがある。

いくつかの実施形態では、購入推定器９３２は、異なるレベルのη_ｃａｐ及びＲｅｌｉａｂｉｌｉｔｙ_ｃａｐそれぞれを、対応するアレイに記憶する。例えば、パラメータη_ｃａｐは、行うことができるｐ個の異なるタイプの資本購入それぞれに関する要素を有するアレイη_ｃａｐとして定義することができる。同様に、パラメータＲｅｌｉａｂｉｌｉｔｙ_ｃａｐは、行うことができるｐ個の異なるタイプの資本購入それぞれに関する要素を有するアレイＲｅｌｉａｂｉｌｉｔｙ_ｃａｐとして定義することができる。これらのアレイの例は、次式で示される。
η_ｃａｐ＝［η_{ｃａｐ，１} η_{ｃａｐ，２} … η_{ｃａｐ，ｐ}］
Ｒｅｌｉａｂｉｌｉｔｙ_ｃａｐ＝［Ｒｅｌｉａｂｉｌｉｔｙ_{ｃａｐ，１} Ｒｅｌｉａｂｉｌｉｔｙ_{ｃａｐ，２} … Ｒｅｌｉａｂｉｌｉｔｙ_{ｃａｐ，ｐ}］
ここで、アレイη_ｃａｐは、サイズが１×ｐであり、アレイη_ｃａｐの各要素は、特定の資本購入ｋに関する購入後効率値η_{ｃａｐ，ｋ}を含む。同様に、アレイＲｅｌｉａｂｉｌｉｔｙ_ｃａｐは、サイズが１×ｐであり、アレイＲｅｌｉａｂｉｌｉｔｙ_ｃａｐの各要素は、特定の資本購入ｋに関する購入後信頼性値Ｒｅｌｉａｂｉｌｉｔｙ_{ｃａｐ，ｋ}を含む。

いくつかの実施形態では、効率アップデータ９１１は、各バイナリ決定変数Ｂ_{ｍａｉｎ，ｋ，ｉ}に関連する資本購入を識別し、Ｂ_{ｃａｐ，ｋ，ｉ}＝１の場合、効率ηを、対応する購入後効率レベルη_{ｃａｐ，ｋ}にリセットする。同様に、信頼性推定器９２４は、各バイナリ決定変数Ｂ_{ｃａｐ，ｋ，ｉ}に関連する資本購入を識別することができ、Ｂ_{ｍａｉｎ，ｋ，ｉ}＝１の場合、信頼性を、対応する購入後信頼性レベルＲｅｌｉａｂｉｌｉｔｙ_{ｃａｐ，ｋ}にリセットすることができる。

資本コスト計算機９３６は、最適化期間の継続期間にわたる接続された機器６１０の資本コストを推定するように構成することができる。いくつかの実施形態では、資本コスト計算機９３６は、次式を使用して各時間ステップｉ中の資本コストを計算する。
Ｃｏｓｔ_{ｃａｐ，ｉ}＝Ｃ_{ｃａｐ，ｉ}Ｂ_{ｃａｐ，ｉ}
ここで、Ｃ_{ｃａｐ，ｉ}は、時間ステップｉにおいて行うことができるｐ個の異なる資本購入それぞれに関する要素を含む資本購入コストのアレイであり、Ｂ_{ｃａｐ，ｉ}は、ｐ個の資本購入それぞれが時間ステップｉにおいて行われるか否かを示すバイナリ決定変数のアレイである。資本コスト計算機９３６は、以下のように、最適化期間中の継続期間にわたって資本コストを合計することができる。

ここで、Ｃｏｓｔ_ｃａｐは、目的関数Ｊの資本コスト項である。

他の実施形態では、資本コスト計算機９３６は、次式に示されるように、資本コストアレイＣ_ｃａｐにバイナリ決定変数の行列Ｂ_ｃａｐを乗算することによって資本コストＣｏｓｔ_ｃａｐを推定する。

目的関数オプティマイザ

引き続き図９を参照すると、高レベルオプティマイザ８３２は、目的関数生成器９３５及び目的関数オプティマイザ９４０を含むものとして示されている。目的関数生成器９３５は、コスト予測器９１０、９２０及び９３０によって定式化された動作コスト項、メンテナンスコスト項及び資本コスト項を合計することによって目的関数Ｊを生成するように構成することができる。目的関数生成器９３５によって生成することができる目的関数の一例は、次式で示される。

目的関数生成器９３５によって生成することができる目的関数の別の例は、次式で示される。

ここで、アレイＣ_ｏｐは、最適化期間の特定の時間ステップｉ＝１．．．ｈに関するエネルギーコスト値Ｃ_ｏｐ，ｉを含み、アレイＰ_ｏｐは、最適化期間の特定の時間ステップｉ＝１．．．ｈに関する電力消費量値Ｐ_ｏｐ，ｉを含み、アレイＣ_ｍａｉｎの各要素は、特定のメンテナンス活動ｊ＝１．．．ｍに関するメンテナンスコスト値Ｃ_{ｍａｉｎ，ｊ}を含み、行列Ｂ_ｍａｉｎの各要素は、最適化期間の特定の時間ステップｉ＝１．．．ｈにおける特定のメンテナンス活動ｊ＝１．．．ｍに関するバイナリ決定変数を含み、アレイＣ_ｃａｐの各要素は、特定の資本購入ｋ＝１．．．ｐに関する資本コスト値Ｃ_{ｃａｐ，ｋ}を含み、行列Ｂ_ｃａｐの各要素は、最適化期間の特定の時間ステップｉ＝１．．．ｈにおける特定の資本購入ｋ＝１．．．ｐに関するバイナリ決定変数を含む。

目的関数生成器９３５は、目的関数Ｊでの１つ又は複数の変数又はパラメータに制約を課すように構成することができる。制約は、動作コスト予測器９１０、メンテナンスコスト予測器９２０及び資本コスト予測器９３０を参照して述べた式又は関係のいずれを含むこともできる。例えば、目的関数生成器９３５は、接続された機器６１０の１つ又は複数のデバイスに関する電力消費量値Ｐ_ｏｐ，ｉを、理想電力消費量Ｐ_{ｉｄｅａｌ，ｉ}及び効率η_ｉの関数として定義する制約を課すことができる（例えば、Ｐ_ｏｐ，ｉ＝Ｐ_{ｉｄｅａｌ，ｉ}／η_ｉ）。目的関数生成器９３５は、効率アップデータ９１１及び効率デグレーダ９１３を参照して述べたのと同様に、効率η_ｉをバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}の関数として定義する制約を課すことができる。目的関数生成器９３５は、メンテナンス推定器９２２及び購入推定器９３２を参照して述べたのと同様に、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}を０又は１のいずれかの値に制約し、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}を、接続された機器６１０の信頼性Ｒｅｌｉａｂｉｌｉｔｙ_ｉの関数として定義する制約を課すことができる。目的関数生成器９３５は、信頼性推定器９２４及び９３４を参照して述べたのと同様に、接続された機器６１０の信頼性Ｒｅｌｉａｂｉｌｉｔｙ_ｉを機器性能情報（例えば、動作条件、稼働時間など）の関数として定義する制約を課すことができる。

目的関数オプティマイザ９４０は、目的関数Ｊを最適化して、最適化期間の継続時間にわたるバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}の最適値を決定することができる。目的関数オプティマイザ９４０は、様々な最適化技法の任意のものを使用して、目的関数Ｊを定式化及び最適化することができる。例えば、目的関数オプティマイザ９４０は、整数計画法、混合整数線形計画法、確率的最適化、凸最適化、動的計画法又は任意の他の最適化技法を使用して、目的関数Ｊを定式化し、制約を定義し、最適化を実施することができる。これら及び他の最適化技法は当技術分野で知られており、本明細書で詳細には述べない。

いくつかの実施形態では、目的関数オプティマイザ９４０は、混合整数確率的最適化を使用して目的関数Ｊを最適化する。混合整数確率的最適化では、目的関数Ｊでの変数のいくつかを、ランダム変数又は確率変数の関数として定義することができる。例えば、決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}は、接続された機器６１０の信頼性に基づいた確率値を有するバイナリ変数として定義することができる。低い信頼性値は、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}が値１を有する確率を高めることがあり（例えば、Ｂ_{ｍａｉｎ，ｉ}＝１及びＢ_{ｃａｐ，ｉ}＝１）、高い信頼性値は、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}が値０を有する確率を高めることがある（例えば、Ｂ_{ｍａｉｎ，ｉ}＝０及びＢ_{ｃａｐ，ｉ}＝０）。いくつかの実施形態では、メンテナンス推定器９２２及び購入推定器９３２は、混合整数確率的技法を使用して、接続された機器６１０の信頼性の確率関数としてバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}の値を定義する。

上で論じたように、目的関数Ｊは、最適化期間の継続期間にわたって接続された機器６１０の１つ又は複数のデバイスを動作、メンテナンス及び購入する予測コストを表すこともある。いくつかの実施形態では、目的関数オプティマイザ９４０は、これらのコストを特定の時点（例えば、現時点）に投影し、特定の時点での接続された機器６１０の１つ又は複数のデバイスの正味現在価値（ＮＰＶ）を決定するように構成される。例えば、目的関数オプティマイザ９４０は、次式を使用して、目的関数Ｊでの各コストを現時点に投影することができる。

ここで、ｒは利率であり、Ｃｏｓｔ_ｉは、最適化期間の時間ステップｉ中にかかったコストであり、ＮＰＶ_ｃｏｓｔは、最適化期間の継続期間にわたってかかった総コストの正味現在価値（すなわち現在のコスト）である。いくつかの実施形態では、目的関数オプティマイザ９４０は、正味現在価値ＮＰＶ_ｃｏｓｔを最適化して、特定の時点における接続された機器６１０の１つ又は複数のデバイスのＮＰＶを決定する。

上で論じたように、目的関数Ｊでの１つ又は複数の変数又はパラメータは、接続された機器６１０からの閉ループフィードバックに基づいて動的に更新することができる。例えば、接続された機器６１０から受信された機器性能情報を使用して、接続された機器６１０の信頼性及び／又は効率を更新することができる。目的関数オプティマイザ９４０は、目的関数Ｊを定期的に（例えば、１日に１回、１週間に１回、１か月に１回など）最適化して、接続された機器６１０からの閉ループフィードバックに基づいて予測コスト及び／又は正味現在価値ＮＰＶ_ｃｏｓｔを動的に更新するように構成することができる。

いくつかの実施形態では、目的関数オプティマイザ９４０は、最適化結果を生成する。最適化結果は、最適化期間内の時間ステップｉごとに目的関数Ｊの決定変数の最適値を含むことがある。最適化結果は、接続された機器６１０の各デバイスに関する動作決定、機器メンテナンス決定及び／又は機器購入決定を含む。いくつかの実施形態では、最適化結果は、最適化期間の継続期間にわたって接続された機器６１０を動作、メンテナンス及び購入する経済的価値を最適化する。いくつかの実施形態では、最適化結果は、特定の時点における接続された機器６１０の１つ又は複数のデバイスの正味現在価値を最適化する。最適化結果により、ＢＭＳ６０６は、接続された機器６１０に関する設定点をアクティブ化、非アクティブ化又は調整して、最適化結果で指定された決定変数の最適値を実現することができる。

いくつかの実施形態では、ＭＰＭシステム６０２は、最適化結果を使用して、機器購入及びメンテナンスの推奨を生成する。機器購入及びメンテナンスの推奨は、目的関数Ｊを最適化することによって決定されるバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}に関する最適値に基づくことがある。例えば、接続された機器６１０の特定のデバイスに関するＢ_{ｍａｉｎ，２５}＝１の値は、最適化期間の第２５の時間ステップにおいてそのデバイスに対してメンテナンスが実施されるべきであることを示すことがあり、Ｂ_{ｍａｉｎ，２５}＝０の値は、その時間ステップにおいてメンテナンスを実施すべきでないことを示すことがある。同様に、Ｂ_{ｃａｐ，２５}＝１の値は、最適化期間の第２５の時間ステップにおいて、接続された機器６１０の新たなデバイスを購入すべきであることを示すことがあり、Ｂ_{ｃａｐ，２５}＝０の値は、その時間ステップにおいて新たなデバイスを購入すべきでないことを示すことがある。

モデル予測的メンテナンスプロセス

次に、図１０を参照すると、例示的実施形態に従って、モデル予測的メンテナンスプロセス１０００のフローチャートが示されている。プロセス１０００は、ビルディングシステム６００の１つ又は複数の構成要素によって実施することができる。いくつかの実施形態において、プロセス１０００は、図６〜９を参照して述べたようにＭＰＭシステム６０２によって実施される。

プロセス１０００は、ビルディングの可変状態又は状況に影響を与えるためにビルディング機器を動作させること（ステップ１００２）及びビルディング機器からのフィードバックとして機器性能情報を受信すること（ステップ１００４）を含むものとして示されている。ビルディング機器は、ビルディングを監視及び／又は制御するために使用することができる機器のタイプを含むことができる（例えば、接続された機器６１０）。例えば、ビルディング機器は、冷却器、ＡＨＵ、ボイラ、バッテリ、ヒータ、エコノマイザ、バルブ、アクチュエータ、ダンパ、冷却塔、ファン、ポンプ、照明機器、セキュリティ機器、冷凍機器又はビルディングシステム若しくはビルディング管理システム内の任意の他のタイプの機器を含むことができる。ビルディング機器は、図１〜５を参照して述べたＨＶＡＣシステム１００、ウォーターサイドシステム２００、エアサイドシステム３００、ＢＭＳ４００及び／又はＢＭＳ５００の機器のいずれを含むこともできる。機器性能情報は、監視される変数のサンプル（例えば、測定された温度、測定された圧力、測定された流量、電力消費量など）、現在の動作条件（例えば、加熱又は冷却負荷、現在の動作条件など）、障害標示又はビルディング機器の性能を特徴付ける他のタイプの情報を含むことができる。

プロセス１０００は、機器性能情報に応じてビルディング機器の効率及び信頼性を推定すること（ステップ１００６）を含むものとして示されている。いくつかの実施形態では、ステップ１００６は、図９を参照して述べた効率アップデータ９１１及び信頼性推定器９２４、９２６によって実施される。ステップ１００６は、機器性能情報を使用して、実際の動作条件下でのビルディング機器の効率ηを決定することを含むことができる。いくつかの実施形態では、効率η_ｉは、次式で示されるように、ビルディング機器の理想的な電力消費量Ｐ_{ｉｄｅａｌ}と、ビルディング機器の実際の電力消費量Ｐ_{ａｃｔｕａｌ}との比を表す。

ここで、Ｐ_{ｉｄｅａｌ}は、ビルディング機器に関する性能曲線によって定義されるビルディング機器の理想的な電力消費量であり、Ｐ_{ａｃｔｕａｌ}は、ビルディング機器の実際の電力消費量である。いくつかの実施形態では、ステップ１００６は、ステップ１００２で収集された機器性能情報を使用して、実際の電力消費量値Ｐ_{ａｃｔｕａｌ}を識別することを含む。ステップ１００６は、実際の電力消費量Ｐ_{ａｃｔｕａｌ}を理想的な電力消費量Ｐ_{ｉｄｅａｌ}と組み合わせて使用して効率ηを計算することを含むことができる。

ステップ１００６は、効率ηを定期的に更新して、ビルディング機器の現在の動作効率を反映することを含むことができる。例えば、ステップ１００６は、ビルディング機器の効率ηを、１日に１回、１週間に１回、１年に１回又は時間と共に効率ηの変化を捕捉するのに適切であり得る任意の他の間隔で計算することを含むことができる。効率ηの各値は、効率ηが計算される時点でのＰ_{ｉｄｅａｌ}及びＰ_{ａｃｔｕａｌ}の対応する値に基づき得る。いくつかの実施形態では、ステップ１００６は、高レベル最適化プロセスが実施されるたびに（すなわち目的関数Ｊが最適化されるたびに）効率ηを更新することを含む。ステップ１００６で計算された効率値は、初期効率値η_０としてメモリ８１０に記憶されることがあり、ここで、下付き数字０は、最適化期間の開始時又は開始前（例えば、時間ステップ０で）の効率ηの値を表す。

ステップ１００６は、最適化期間の各時間ステップｉにおけるビルディング機器の効率η_ｉを予測することを含むことができる。最適化期間の開始時の初期効率η_０は、ビルディング機器の性能が低下するにつれて、時間と共に低下することがある。例えば、冷却器の効率は、冷却水管が汚れて冷却器の熱伝達率が低下した結果、時間と共に低下することがある。同様に、バッテリの物理的又は化学的構成要素の劣化により、バッテリの効率は、時間と共に低下することがある。ステップ１００６は、そのような低下を、最適化期間の継続時間にわたって効率η_ｉを増分的に低下させることによって考慮に入れることができる。

いくつかの実施形態では、初期効率値η_０は、各最適化期間の開始時に更新される。しかし、効率ηは、最適化期間中に低下することがあり、初期効率値η_０は、最適化期間の継続期間にわたって次第に不正確になる。最適化期間中の効率低下を考慮に入れるために、ステップ１００６は、連続する各時間ステップにおいて効率ηを所定量だけ低下させることを含むことができる。例えば、ステップ１００６は、各時間ステップｉ＝１．．．ｈでの効率を以下のように定義することを含むことができる。
η_ｉ＝η_ｉ−１−Δη
ここで、η_ｉは、時間ステップｉにおける効率であり、η_ｉ−１は、時間ステップｉ−１における効率であり、Δηは、連続する時間ステップ間の効率の低下である。いくつかの実施形態では、η_ｉのこの定義は、Ｂ_{ｍａｉｎ，ｉ}＝０及びＢ_{ｃａｐ，ｉ}＝０である各時間ステップに適用される。しかし、Ｂ_{ｍａｉｎ，ｉ}＝１又はＢ_{ｃａｐ，ｉ}＝１の場合、ステップ１０１８で、η_ｉの値をη_ｍａｉｎ又はη_ｃａｐにリセットすることができる。

いくつかの実施形態では、Δηの値は、効率値の時系列に基づいている。例えば、ステップ１００６は、初期効率値η_０の時系列を記録することを含むことがあり、各初期効率値η_０は、特定の時点におけるビルディング機器の経験的に計算された効率を表す。ステップ１００６は、初期効率値η_０の時系列を検査して、効率が低下する率を決定することを含むことができる。例えば、時刻ｔ_１での初期効率η_０がη_０，１であり、時刻ｔ_２での初期効率がη_０，２である場合、効率低下率は、以下のように計算することができる。

ここで、

は、効率低下率である。ステップ１００６は、

に各時間ステップの継続時間Δｔを乗算して、Δηの値を計算することを含むことができる（すなわち、

）。

ステップ１００６は、ステップ１００４で受信された機器性能情報に基づいてビルディング機器の信頼性を推定することを含むことができる。信頼性は、ビルディング機器がその現在の動作条件下で障害なく動作し続ける尤度の統計的尺度であり得る。より過酷な条件下（例えば、高負荷、高温など）での動作は、信頼性をより低くすることがあり、より過酷でない条件下（例えば、低負荷、中程度の温度など）での動作は、信頼性をより高くすることがある。いくつかの実施形態では、信頼性は、ビルディング機器が最後にメンテナンスを受けてから経過した時間量及び／又はビルディング機器が購入若しくは設置されてから経過した時間量に基づく。

いくつかの実施形態では、ステップ１００６は、機器性能情報を使用して、ビルディング機器の現在の動作条件を識別することを含む。現在の動作条件を検査して、ビルディング機器の性能が低下し始めるときを明らかにし、且つ／又は障害が発生するときを予測することができる。いくつかの実施形態では、ステップ１００６は、ビルディング機器で潜在的に発生し得る様々なタイプの故障の尤度を推定することを含む。各故障の尤度は、ビルディング機器の現在の動作条件、ビルディング機器が設置されてから経過した時間量及び／又はメンテナンスが最後に実施されてから経過した時間量に基づくことがある。いくつかの実施形態では、ステップ１００６は、２０１６年６月２１日出願の「ＢｕｉｌｄｉｎｇＭａｎａｇｅｍｅｎｔＳｙｓｔｅｍＷｉｔｈＰｒｅｄｉｃｔｉｖｅＤｉａｇｎｏｓｔｉｃｓ」という名称の（特許文献３）に記載のシステム及び方法を使用して、動作条件を識別し、様々な故障の尤度を予測することを含む。上記特許出願の開示全体が参照により本明細書に組み入れられる。

いくつかの実施形態では、ステップ１００６は、複数のビルディングにわたって分散されたビルディング機器から動作データを受信することを含む。動作データは、例えば、現在の動作条件、障害標示、故障時間又はビルディング機器の動作及び性能を特徴付ける他のデータを含むことができる。ステップ１００６は、動作データのセットを使用して、各タイプの機器の信頼性モデルを作成することを含むことができる。ステップ１００６で信頼性モデルを使用して、ビルディング機器の任意の所与のデバイスの信頼性を、その現在の動作条件及び／又は他の外的要因（例えば、メンテナンスが最後に実施されてからの時間、設置又は購入からの時間、地理的位置、水質など）に応じて推定することができる。

ステップ１００６で使用することができる信頼性モデルの一例は、次式で示される。
Ｒｅｌｉａｂｉｌｉｔｙ_ｉ＝ｆ（ＯｐＣｏｎｄ_ｉ，Δｔ_{ｍａｉｎ，ｉ}，Δｔ_{ｃａｐ，ｉ}）
ここで、Ｒｅｌｉａｂｉｌｉｔｙ_ｉは、時間ステップｉにおけるビルディング機器の信頼性であり、ＯｐＣｏｎｄ_ｉは、時間ステップｉにおける動作条件であり、Δｔ_{ｍａｉｎ，ｉ}は、メンテナンスが最後に行われた時点と時間ステップｉとの間で経過した時間量であり、Δｔ_{ｃａｐ，ｉ}は、ビルディング機器が購入又は設置された時点と時間ステップｉとの間で経過した時間量である。ステップ１００６は、ビルディング機器からフィードバックとして受信された機器性能情報に基づいて現在の動作条件ＯｐＣｏｎｄ_ｉを識別することを含むことができる。より過酷な条件下（例えば、高負荷、極端な温度など）での動作は、信頼性をより低くすることがあり、より過酷でない条件下（例えば、低負荷、中程度の温度など）での動作は、信頼性をより高くすることがある。

引き続き図１０を参照すると、プロセス１０００は、推定された効率の関数として最適化期間にわたるビルディング機器のエネルギー消費を予測すること（ステップ１００８）を含むものとして示されている。いくつかの実施形態では、ステップ１００８は、図９を参照して述べたように理想性能計算機９１２及び／又は電力消費量推定器によって実施される。ステップ１００８は、負荷／料金予測器８２２から負荷予測Ｌｏａｄ_ｉを受信し、低レベルオプティマイザ８３４から性能曲線を受信することを含むことができる。上で論じたように、性能曲線は、ビルディング機器の理想的な電力消費量Ｐ_{ｉｄｅａｌ}を、デバイス又はデバイスのセットに対する加熱又は冷却負荷の関数として定義することができる。例えば、ビルディング機器に関する性能曲線は、次式によって定義することができる。
Ｐ_{ｉｄｅａｌ，ｉ}＝ｆ（Ｌｏａｄ_ｉ）
ここで、Ｐ_{ｉｄｅａｌ，ｉ}は、時間ステップｉにおけるビルディング機器の理想的な電力消費量（例えば、ｋＷ）であり、Ｌｏａｄ_ｉは、時間ステップｉにおけるビルディング機器に対する負荷（例えば、トン単位での冷却負荷、ｋＷ単位での加熱負荷など）である。理想的な電力消費量Ｐ_{ｉｄｅａｌ，ｉ}は、ビルディング機器が完璧な効率で動作すると仮定したそれらの電力消費量を表すことがある。ステップ１００８は、ビルディング機器に関する性能曲線を使用して、最適化期間の各時間ステップにおけるビルディング機器に関する負荷点Ｌｏａｄ_ｉに対応するＰ_{ｉｄｅａｌ，ｉ}の値を識別することを含むことができる。

いくつかの実施形態では、ステップ１００８は、理想的な電力消費量Ｐ_{ｉｄｅａｌ，ｉ}及びビルディング機器の効率η_ｉの関数として電力消費量Ｐ_ｏｐ，ｉを推定することを含む。例えば、ステップ１００８は、次式を使用して電力消費量Ｐ_ｏｐ，ｉを計算することを含むことができる。

ここで、Ｐ_{ｉｄｅａｌ，ｉ}は、対応する負荷点Ｌｏａｄ_ｉでのビルディング機器に関する機器性能曲線に基づく電力消費量であり、η_ｉは、時間ステップｉにおけるビルディング機器の動作効率である。

引き続き図１０を参照すると、プロセス１０００は、予測されたエネルギー消費量の関数として、最適化期間にわたってビルディング機器を動作させるコストＣｏｓｔ_ｏｐを定義すること（ステップ１０１０）を含むものとして示されている。いくつかの実施形態において、ステップ１０１０は、図９を参照して述べたように動作コスト計算機９１６によって実施される。ステップ１０１０は、次式を使用して各時間ステップｉ中の動作コストを計算することを含むことができる。
Ｃｏｓｔ_ｏｐ，ｉ＝Ｃ_ｏｐ，ｉＰ_ｏｐ，ｉΔｔ
ここで、Ｐ_ｏｐ，ｉは、ステップ１００８で決定される時間ステップｉにおける予測電力消費量であり、Ｃ_ｏｐ，ｉは、時間ステップｉにおける単位エネルギーあたりのコストであり、Δｔは、各時間ステップの継続期間である。ステップ１０１０は、以下のように、最適化期間の継続期間にわたって動作コストを合計することを含むことができる。

他の実施形態では、ステップ１０１０は、次式で示されるように、コストアレイＣ_ｏｐに電力消費量アレイＰ_ｏｐ及び各時間ステップの継続時間Δｔを乗算することにより、動作コストＣｏｓｔ_ｏｐを計算することを含むことができる。
Ｃｏｓｔ_ｏｐ＝Ｃ_ｏｐＰ_ｏｐΔｔ
Ｃｏｓｔ_ｏｐ＝［Ｃ_ｏｐ，１Ｃ_ｏｐ，２ … Ｃ_ｏｐ，ｈ］［Ｐ_ｏｐ，１Ｐ_ｏｐ，２ … Ｐ_ｏｐ，ｈ］^ＴΔｔ
ここで、アレイＣ_ｏｐは、最適化期間の特定の時間ステップｉ＝１．．．ｈに関するエネルギーコスト値Ｃ_ｏｐ，ｉを含み、アレイＰ_ｏｐは、最適化期間の特定の時間ステップｉ＝１．．．ｈに関する電力消費量値Ｐ_ｏｐ，ｉを含む。

引き続き図１０を参照すると、プロセス１０００は、推定された信頼性の関数として、最適化期間にわたってビルディング機器に対してメンテナンスを実施するコストを定義すること（ステップ１０１２）を含むものとして示されている。ステップ１０１２は、図９を参照して述べたようにメンテナンスコスト予測器９２０によって実施することができる。ステップ１０１２は、最適化期間の継続時間にわたるビルディング機器の推定された信頼性を使用して、最適化期間の各時間ステップにおいてビルディング機器がメンテナンス及び／又は交換を必要とする確率を決定することを含むことができる。いくつかの実施形態では、ステップ１０１２は、ビルディング機器が所定の時間ステップにおいてメンテナンスを必要とする確率を臨界値と比較することを含む。ステップ１０１２は、時間ステップｉにおいてビルディング機器がメンテナンスを必要とする確率が臨界値を超えるという決定に応答して、Ｂ_{ｍａｉｎ，ｉ}＝１の値を設定することを含むことができる。同様に、ステップ１０１２は、所与の時間ステップにおいてビルディング機器が交換を必要とする確率を臨界値と比較することを含むことができる。ステップ１０１２は、時間ステップｉにおいてビルディング機器が交換を必要とする確率が臨界値を超えるという決定に応答して、Ｂ_{ｃａｐ，ｉ}＝１の値を設定することを含むことができる。

ステップ１０１２は、ビルディング機器に対する様々なタイプのメンテナンスの実施に関連するコストＣ_{ｍａｉｎ，ｉ}を決定することを含むことができる。ステップ１０１２は、外部システム又はデバイス（例えば、データベース、ユーザデバイスなど）からメンテナンスコストのセットを受信することを含むことができる。いくつかの実施形態では、メンテナンスコストは、様々なタイプのメンテナンスを実施する経済的コスト（例えば、ドル）を定義する。各タイプのメンテナンス活動は、それに関連する異なる経済的コストを有することがある。例えば、冷却器圧縮機内のオイルを交換するメンテナンス活動にかかる経済的コストは、比較的小さいことがあり、冷却器を完全に分解してすべての冷却水管を洗浄するメンテナンス活動にかかる経済的コストは、かなり大きいことがある。ステップ１０１２は、メンテナンスコストを使用して目的関数ＪでのＣ_{ｍａｉｎ，ｉ}の値を定義することを含むことができる。

ステップ１０１２は、最適化期間の継続期間にわたるビルディング機器のメンテナンスコストを推定することを含むことができる。いくつかの実施形態では、ステップ１０１２は、次式を使用して各時間ステップｉ中のメンテナンスコストを計算することを含む。
Ｃｏｓｔ_{ｍａｉｎ，ｉ}＝Ｃ_{ｍａｉｎ，ｉ}Ｂ_{ｍａｉｎ，ｉ}
ここで、Ｃ_{ｍａｉｎ，ｉ}は、時間ステップｉにおいて実施することができるｍ個の異なるタイプのメンテナンス活動それぞれに関する要素を含むメンテナンスコストのアレイであり、Ｂ_{ｍａｉｎ，ｉ}は、ｍ個のメンテナンス活動それぞれが時間ステップｉにおいて実施されるか否かを示すバイナリ決定変数のアレイである。ステップ１０１２は、以下のように、最適化期間の継続期間にわたってメンテナンスコストを合計することを含むことができる。

他の実施形態では、ステップ１０１２は、次式に示されるように、メンテナンスコストアレイＣ_ｍａｉｎにバイナリ決定変数の行列Ｂ_ｍａｉｎを乗算することによってメンテナンスコストＣｏｓｔ_ｍａｉｎを推定することを含む。

ここで、アレイＣ_ｍａｉｎの各要素は、特定のメンテナンス活動ｊ＝１．．．ｍに関するメンテナンスコスト値Ｃ_{ｍａｉｎ，ｊ}を含み、行列Ｂ_ｍａｉｎの各要素は、最適化期間の特定の時間ステップｉ＝１．．．ｈにおける特定のメンテナンス活動ｊ＝１．．．ｍに関するバイナリ決定変数を含む。

引き続き図１０を参照すると、プロセス１０００は、推定された信頼性の関数として、最適化期間にわたってビルディング機器を購入又は交換するコストＣｏｓｔ_ｃａｐを定義すること（ステップ１０１４）を含むものとして示されている。ステップ１０１４は、図９を参照して述べたように資本コスト予測器９３０によって実施することができる。いくつかの実施形態では、ステップ１０１４は、最適化期間の継続時間にわたるビルディング機器の推定された信頼性を使用して、最適化期間の各時間ステップにおいてビルディング機器の新たなデバイスが購入される確率を決定することを含む。いくつかの実施形態では、ステップ１０１４は、所与の時間ステップにおいてビルディング機器の新たなデバイスが購入される確率を臨界値と比較することを含む。ステップ１０１４は、時間ステップｉにおいてビルディング機器が購入される確率が臨界値を超えるという決定に応答して、Ｂ_{ｃａｐ，ｉ}＝１の値を設定することを含むことができる。

ステップ１０１４は、様々な資本購入（すなわちビルディング機器の１つ又は複数の新たなデバイスを購入すること）に関連するコストＣ_{ｃａｐ，ｉ}を決定することを含むことができる。ステップ１０１４は、外部システム又はデバイス（例えば、データベース、ユーザデバイスなど）から資本コストのセットを受信することを含むことができる。いくつかの実施形態では、資本コストは、様々な資本購入を行う経済的コスト（例えば、ドル）を定義する。各タイプの資本購入は、それに関連する異なる経済的コストを有することがある。例えば、新たな温度センサの購入にかかる経済的コストは比較的小さいことがあり、新たな冷却器の購入にかかる経済的コストはかなり大きいことがある。ステップ１０１４は、購入コストを使用して、目的関数ＪでのＣ_{ｃａｐ，ｉ}の値を定義することを含むことができる。

いくつかの資本購入は、他のものよりも高価であり得る。しかし、異なるタイプの資本購入は、効率η及び／又はビルディング機器の信頼性に対して異なるレベルでの向上をもたらすことがある。例えば、既存のセンサの交換のために新たなセンサを購入することで、効率ηがわずかに向上し、且つ／又は信頼性がわずかに向上することがあり、新たな冷却器及び制御システムを購入することで、ビルディング機器の効率η及び／又は信頼性がかなり大きく向上することがある。したがって、複数の異なるレベルの購入後の効率（すなわちη_ｃａｐ）及び購入後の信頼性（すなわちＲｅｌｉａｂｉｌｉｔｙ_ｃａｐ）があり得る。η_ｃａｐ及びＲｅｌｉａｂｉｌｉｔｙ_ｃａｐの各レベルは、異なるタイプの資本購入に対応することがある。

ステップ１０１４は、最適化期間の継続期間にわたるビルディング機器の資本コストを推定することを含むことができる。いくつかの実施形態では、ステップ１０１４は、次式を使用して各時間ステップｉ中の資本コストを計算することを含む。
Ｃｏｓｔ_{ｃａｐ，ｉ}＝Ｃ_{ｃａｐ，ｉ}Ｂ_{ｃａｐ，ｉ}
ここで、Ｃ_{ｃａｐ，ｉ}は、時間ステップｉにおいて行うことができるｐ個の異なる資本購入それぞれに関する要素を含む資本購入コストのアレイであり、Ｂ_{ｃａｐ，ｉ}は、ｐ個の資本購入それぞれが時間ステップｉにおいて行われるか否かを示すバイナリ決定変数のアレイである。ステップ１０１４は、以下のように、最適化期間中の継続期間にわたって資本コストを合計することを含むことができる。

他の実施形態では、ステップ１０１４は、次式に示されるように、資本コストアレイＣ_ｃａｐにバイナリ決定変数の行列Ｂ_ｃａｐを乗算することによって資本コストＣｏｓｔ_ｃａｐを推定することを含む。

ここで、アレイＣ_ｃａｐの各要素は、特定の資本購入ｋ＝１．．．ｐに関する資本コスト値Ｃ_{ｃａｐ，ｋ}を含み、行列Ｂ_ｃａｐの各要素は、最適化期間の特定の時間ステップｉ＝１．．．ｈにおける特定の資本購入ｋ＝１．．．ｐに関するバイナリ決定変数を含む。

引き続き図１０を参照すると、プロセス１０００は、コストＣｏｓｔ_ｏｐ、Ｃｏｓｔ_ｍａｉｎ及びＣｏｓｔ_ｃａｐを含む目的関数を最適化して、ビルディング機器に関する最適なメンテナンス戦略を決定すること（ステップ１０１６）を含むものとして示されている。ステップ１０１６は、ステップ１０１０〜１０１４で定式化された動作コスト項、メンテナンスコスト項及び資本コスト項を合計することによって目的関数Ｊを生成することを含むことができる。ステップ１０１６で生成することができる目的関数の一例は、次式で示される。

ステップ１０１６で生成することができる目的関数の別の例は、次式で示される。

ステップ１０１６は、目的関数Ｊでの１つ又は複数の変数又はパラメータに制約を課すことを含むことができる。制約は、動作コスト予測器９１０、メンテナンスコスト予測器９２０及び資本コスト予測器９３０を参照して述べた式又は関係のいずれを含むこともできる。例えば、ステップ１０１６は、ビルディング機器の１つ又は複数のデバイスに関する電力消費量値Ｐ_ｏｐ，ｉを、理想電力消費量Ｐ_{ｉｄｅａｌ，ｉ}及び効率η_ｉの関数として定義する制約を課すことを含むことができる（例えば、Ｐ_ｏｐ，ｉ＝Ｐ_{ｉｄｅａｌ，ｉ}／η_ｉ）。ステップ１０１６は、効率アップデータ９１１及び効率デグレーダ９１３を参照して述べたのと同様に、効率η_ｉをバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}の関数として定義する制約を課すことを含むことができる。ステップ１０１６は、メンテナンス推定器９２２及び購入推定器９３２を参照して述べたのと同様に、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}を０又は１のいずれかの値に制約し、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}を、接続された機器６１０の信頼性Ｒｅｌｉａｂｉｌｉｔｙ_ｉの関数として定義する制約を課すことを含むことができる。ステップ１０１６は、信頼性推定器９２４及び９３４を参照して述べたのと同様に、接続された機器６１０の信頼性Ｒｅｌｉａｂｉｌｉｔｙ_ｉを機器性能情報（例えば、動作条件、稼働時間など）の関数として定義する制約を課すことを含むことができる。

ステップ１０１６は、目的関数Ｊを最適化して、最適化期間の継続時間にわたるバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}の最適値を決定することを含むことができる。ステップ１０１６は、様々な最適化技法の任意のものを使用して目的関数Ｊを定式化及び最適化することを含むことができる。例えば、ステップ１０１６は、整数計画法、混合整数線形計画法、確率的最適化、凸最適化、動的計画法又は任意の他の最適化技法を使用して、目的関数Ｊを定式化し、制約を定義し、最適化を実施することを含むことができる。これら及び他の最適化技法は当技術分野で知られており、本明細書で詳細には述べない。

いくつかの実施形態では、ステップ１０１６は、混合整数確率的最適化を使用して目的関数Ｊを最適化することを含む。混合整数確率的最適化では、目的関数Ｊでの変数のいくつかを、ランダム変数又は確率変数の関数として定義することができる。例えば、決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}は、ビルディング機器の信頼性に基づいた確率値を有するバイナリ変数として定義することができる。低い信頼性値は、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}が値１を有する確率を高めることがあり（例えば、Ｂ_{ｍａｉｎ，ｉ}＝１及びＢ_{ｃａｐ，ｉ}＝１）、高い信頼性値は、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}が値０を有する確率を高めることがある（例えば、Ｂ_{ｍａｉｎ，ｉ}＝０及びＢ_{ｃａｐ，ｉ}＝０）。いくつかの実施形態では、ステップ１０１６は、混合整数確率的技法を使用して、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}の値をビルディング機器の信頼性の確率関数として定義することを含む。

上で論じたように、目的関数Ｊは、最適化期間の継続期間にわたってビルディング機器の１つ又は複数のデバイスを動作、メンテナンス及び購入する予測コストを表すこともある。いくつかの実施形態では、ステップ１０１６は、これらのコストを特定の時点（例えば、現時点）に投影し、特定の時点でのビルディング機器の１つ又は複数のデバイスの正味現在価値（ＮＰＶ）を決定することを含む。例えば、ステップ１０１６は、次式を使用して、目的関数Ｊでの各コストを現時点に投影することを含むことができる。

ここで、ｒは利率であり、Ｃｏｓｔ_ｉは、最適化期間の時間ステップｉ中にかかったコストであり、ＮＰＶ_ｃｏｓｔは、最適化期間の継続期間にわたってかかった総コストの正味現在価値（すなわち現在のコスト）である。いくつかの実施形態では、ステップ１０１６は、正味現在価値ＮＰＶ_ｃｏｓｔを最適化して、特定の時点でのビルディング機器のＮＰＶを決定することを含む。

上で論じたように、目的関数Ｊでの１つ又は複数の変数又はパラメータは、ビルディング機器からの閉ループフィードバックに基づいて動的に更新することができる。例えば、ビルディング機器から受信された機器性能情報を使用して、ビルディング機器の信頼性及び／又は効率を更新することができる。ステップ１０１６は、目的関数Ｊを定期的に（例えば、１日に１回、１週間に１回、１か月に１回など）最適化して、ビルディング機器からの閉ループフィードバックに基づいて予測コスト及び／又は正味現在価値ＮＰＶ_ｃｏｓｔを動的に更新することを含むことができる。

いくつかの実施形態では、ステップ１０１６は、最適化結果を生成することを含む。最適化結果は、最適化期間内の時間ステップｉごとに目的関数Ｊの決定変数の最適値を含むことがある。最適化結果は、ビルディング機器の各デバイスに関する動作決定、機器メンテナンス決定及び／又は機器購入決定を含む。いくつかの実施形態では、最適化結果は、最適化期間の継続期間にわたってビルディング機器を動作、メンテナンス及び購入する経済的価値を最適化する。いくつかの実施形態では、最適化結果は、特定の時点におけるビルディング機器の１つ又は複数のデバイスの正味現在価値を最適化する。最適化結果により、ＢＭＳ６０６は、ビルディング機器に関する設定点をアクティブ化、非アクティブ化又は調整して、最適化結果で指定された決定変数の最適値を実現することができる。

いくつかの実施形態では、プロセス１０００は、最適化結果を使用して、機器購入及びメンテナンスの推奨を生成することを含む。機器購入及びメンテナンスの推奨は、目的関数Ｊを最適化することによって決定されるバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}に関する最適値に基づくことがある。例えば、ビルディング機器の特定のデバイスに関するＢ_{ｍａｉｎ，２５}＝１の値は、最適化期間の第２５の時間ステップにおいてそのデバイスに対してメンテナンスが実施されるべきであることを示すことがあり、Ｂ_{ｍａｉｎ，２５}＝０の値は、その時間ステップにおいてメンテナンスを実施すべきでないことを示すことがある。同様に、Ｂ_{ｃａｐ，２５}＝１の値は、最適化期間の第２５の時間ステップにおいて、ビルディング機器の新たなデバイスを購入すべきであることを示すことがあり、Ｂ_{ｃａｐ，２５}＝０の値は、その時間ステップにおいて新たなデバイスを購入すべきでないことを示すことがある。

引き続き図１０を参照すると、プロセス１０００は、最適なメンテナンス戦略に基づいてビルディング機器の効率及び信頼性を更新すること（ステップ１０１８）を含むものとして示されている。いくつかの実施形態では、ステップ１０１８は、ビルディング機器に対するメンテナンスの実施又はビルディング機器の１つ若しくは複数のデバイスを交換若しくは補完するための新たな機器の購入により生じるビルディング機器の効率ηの上昇を考慮に入れるために、最適化期間中の１つ又は複数の時間ステップに関する効率η_ｉを更新することを含む。効率η_ｉが更新される時間ステップｉは、メンテナンスが実施されることになるか、又は機器が交換されることになる予測時間ステップに対応することがある。ビルディング機器に対してメンテナンスが実施されることになる予測時間ステップは、目的関数Ｊでのバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}の値によって定義することができる。同様に、ビルディング機器が交換されることになる予測時間ステップは、目的関数Ｊでのバイナリ決定変数Ｂ_{ｃａｐ，ｉ}の値によって定義することができる。

ステップ１０１８は、その時間ステップにおいてメンテナンスが実施されること及び／又はその時間ステップにおいて新たな機器が購入されることをバイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}が示す場合（すなわちＢ_{ｍａｉｎ，ｉ}＝１及び／又はＢ_{ｃａｐ，ｉ}＝１）、所与の時間ステップｉに関する効率η_ｉをリセットすることを含むことができる。例えば、Ｂ_{ｍａｉｎ，ｉ}＝１の場合、ステップ１０１８は、η_ｉの値をη_ｍａｉｎにリセットすることを含むことができ、ここで、η_ｍａｉｎは、時間ステップｉにおいて実施されるメンテナンスにより得られると期待される効率値である。同様に、Ｂ_{ｃａｐ，ｉ}＝１の場合、ステップ１０１８は、η_ｉの値をη_ｃａｐにリセットすることを含むことができ、ここで、η_ｃａｐは、時間ステップｉにおいて実施されるビルディング機器の１つ又は複数のデバイスを補完又は交換するために新たなデバイスを購入することにより得られると期待される効率値である。ステップ１０１８は、１つ又は複数の時間ステップに関して効率η_ｉをリセットすることを含むことができ、（例えば、最適化の各反復によって）バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}及びＢ_{ｃａｐ，ｉ}の値に基づいて最適化が実施される。

ステップ１０１８は、バイナリ決定変数Ｂ_{ｍａｉｎ，ｉ}の値に基づいて、ビルディング機器に対してメンテナンスが最後に実施されてから経過した時間量Δｔ_{ｍａｉｎ，ｉ}を決定することを含むことがある。各時間ステップｉに関して、ステップ１０１８は、時間ステップｉ及び前の各時間ステップ（例えば、時間ステップｉ−１、ｉ−２、．．．、１）におけるＢ_ｍａｉｎの対応する値を検査することができる。ステップ１０１８は、メンテナンスが最後に実施された時点（すなわちＢ_{ｍａｉｎ，ｉ}＝１である直近の時点）を、時間ステップｉに関連する時点から引くことにより、Δｔ_{ｍａｉｎ，ｉ}の値を計算することを含むことができる。メンテナンスが最後に実施されてからの時間量Δｔ_{ｍａｉｎ，ｉ}が長いと、信頼性がより低くなることがあり、メンテナンスが最後に実施されてからの時間量が短いと、信頼性がより高くなることがある。

同様に、ステップ１０１８は、バイナリ決定変数Ｂ_{ｃａｐ，ｉ}の値に基づいて、ビルディング機器が購入又は設置されてから経過した時間量Δｔ_{ｃａｐ，ｉ}を決定することを含むことがある。各時間ステップｉに関して、ステップ１０１８は、時間ステップｉ及び前の各時間ステップ（例えば、時間ステップｉ−１、ｉ−２、．．．、１）におけるＢ_ｃａｐの対応する値を検査することができる。ステップ１０１８は、ビルディング機器が購入又は設置された時点（すなわちＢ_{ｃａｐ，ｉ}＝１である直近の時点）を、時間ステップｉに関連する時点から引くことにより、Δｔ_{ｃａｐ，ｉ}の値を計算することを含むことができる。ビルディング機器が購入又は設置されてからの時間量Δｔ_{ｃａｐ，ｉ}が長いと、信頼性がより低くなることがあり、ビルディング機器が購入又は設置されてからの時間量が短いと、信頼性がより高くなることがある。

いくつかのメンテナンス活動は、他よりもコストがかかることがある。しかし、異なるタイプのメンテナンス活動が、ビルディング機器の効率η及び／又は信頼性に対する異なるレベルの改良をもたらすことがある。例えば、冷却器内のオイルの単なる交換は、効率ηのわずかな改良及び／又は信頼性のわずかな改良をもたらすことがあり、冷却器の完全な分解及びすべての冷却水管の洗浄は、ビルディング機器の効率η及び／又は信頼性のかなり大きい改良をもたらすことがある。したがって、複数の異なるレベルのメンテナンス後の効率（すなわちη_ｍａｉｎ）及びメンテナンス後の信頼性（すなわちＲｅｌｉａｂｉｌｉｔｙ_ｍａｉｎ）が存在し得る。η_ｍａｉｎ及びＲｅｌｉａｂｉｌｉｔｙ_ｍａｉｎの各レベルは、異なるタイプのメンテナンス活動に対応することがある。

いくつかの実施形態では、ステップ１０１８は、各バイナリ決定変数Ｂ_{ｍａｉｎ，ｊ，ｉ}に関連するメンテナンス活動を識別することを含み、Ｂ_{ｍａｉｎ，ｊ，ｉ}＝１の場合、効率ηを、対応するメンテナンス後の効率レベルη_{ｍａｉｎ，ｊ}にリセットする。同様に、ステップ１０１８は、各バイナリ決定変数Ｂ_{ｍａｉｎ，ｊ，ｉ}に関連するメンテナンス活動を識別することを含むことができ、Ｂ_{ｍａｉｎ，ｊ，ｉ}＝１の場合、信頼性を、対応するメンテナンス後の信頼性レベルＲｅｌｉａｂｉｌｉｔｙ_{ｍａｉｎ，ｊ}にリセットすることができる。

いくつかの実施形態では、ステップ１０１８は、各バイナリ決定変数Ｂ_{ｍａｉｎ，ｋ，ｉ}に関連する資本購入を識別し、Ｂ_{ｃａｐ，ｋ，ｉ}＝１の場合、効率ηを、対応する購入後効率レベルη_{ｃａｐ，ｋ}にリセットすることを含む。同様に、ステップ１０１８は、各バイナリ決定変数Ｂ_{ｃａｐ，ｋ，ｉ}に関連する資本購入を識別することを含むことがあり、Ｂ_{ｍａｉｎ，ｋ，ｉ}＝１の場合、信頼性を、対応する購入後信頼性レベルＲｅｌｉａｂｉｌｉｔｙ_{ｃａｐ，ｋ}にリセットすることができる。

予算制約及び故障リスクを伴うモデル予測的メンテナンス

概要

全体として図１１〜２２を参照すると、いくつかの実施形態による、予算制約、リスクコスト及び／又は雑費を考慮に入れるモデル予測的メンテナンス（ＭＰＭ）システムに関するシステム及び方法が示されている。いくつかの実施形態では、図１１〜２２を参照して以下でより詳細に述べるシステム及び方法のいずれかは、図６〜１０を参照して上でより詳細に述べたＭＰＭシステム６０２に組み込まれる。例えば、図８〜９を参照して上でより詳細に述べたモデル予測的メンテナンスシステム６０２の高レベルオプティマイザ８３２は、本明細書で以下に述べるシステム及び方法（例えば、ハード予算制約）のいずれかを含むことができる。

いくつかの実施形態では、ＭＰＭシステム６０２は、１つ又は複数の予算制約を生成し、１つ又は複数の予算制約を受ける目的関数Ｊを最適化して、１つ又は複数の最適化制約を遵守しながらコストを最小化する決定変数の最適値を決定するように構成される。いくつかの実施形態では、図１１〜２３Ｂを参照して述べるメンテナンス活動に関連する任意の記載は、資本購入活動と同様及び／又は同一に適用することができる。いくつかの実施形態では、ＭＰＭシステム６０２は、図１１〜２３Ｂを参照して以下に述べるメンテナンス活動を説明するために、ＭＰＭ６０２が述べられるのと同様及び／又は同一に予算制約下で資本購入活動を説明することができる。図１０を参照して上でより詳細に述べた資本購入は、ビルディング管理システム（ＢＭＳ）における１つ又は複数の構成要素の交換（例えば、可変冷媒流量（ＶＲＦ）システムの屋外凝縮ユニットの交換、ＢＭＳでの換気ユニットの交換）を含むことができる。

いくつかの実施形態では、ＭＰＭシステム６０２は、ビルディング機器に関連するリスクコストを組み込む。リスクコストは、ビルディング機器の故障に関連するコストを定義することができる。ビルディング機器の故障は、ある閾値を超えたビルディング機器の劣化状態、ビルディング機器の作動不能などに基づいて決定することができる。ビルディング機器が故障した場合、複数のコストが生じる可能性がある。いくつかの実施形態では、ビルディング機器の故障により、ビルディング機器を補修するための様々な修理（例えば、メンテナンス及び／又は交換）コストが生じる。故障によりさらなる複雑な問題が生じることがあるため、ビルディング機器が故障した後、故障前に修理が実施される場合に比べて修理コストが高くなる可能性がある。例えば、電気デバイスでの配線が故障すると、電気デバイスの他の構成要素が配線の故障により電気的損傷を受けることがある。いくつかの実施形態では、ビルディング機器の故障により、様々な機会コストが生じる。機会コストには、一般的な修理コスト以外の、ビルディング機器の故障により生じる様々なコストが含まれることがある。例えば、冬にビルディングのスペースでヒータが故障した場合、そのスペースは、居住者が使用できないほど冷えることがある。したがって、居住者の移転に関連するコスト、スペースの閉鎖によるビジネスチャンスの喪失などが機会コストの形態で生じ得る。いくつかの実施形態では、ユーザは、ビルディング機器の故障に関連する機会コストを定義する。いくつかの実施形態では、機会コストは、ビルディング機器が関連のビルディングにどのように影響を及ぼすかに関する知識に基づいて、ＭＰＭシステム６０２によって推定される。

いくつかの実施形態では、ＭＰＭシステム６０２は、雑費を組み込む。雑費は、ビルディング機器の信頼性に影響を及ぼすが、ビルディング機器の効率に影響を及ぼさないことがある雑多な活動（例えば、メンテナンス及び／又は交換活動）から生じ得る。いくつかの実施形態では、雑費は、ＭＰＭシステム６０２によって解が与えられるコスト関数（例えば、目的関数Ｊ）にメンテナンスコストと共に組み込まれる。いくつかの実施形態では、雑費は、コスト関数でのメンテナンスコストとは別である。雑費の例として、雑多な活動は、錆びによる配管の亀裂の可能性を低減するための換気システムの配管の交換を含むことがある。配管を交換しても換気システムの効率に影響を及ぼさないことがあるが、新しい配管に亀裂が生じにくくなり得るため、換気システムの信頼性を高めることができる。いくつかの実施形態では、雑多な活動がビルディング機器の故障の可能性を低減し、それによりリスクコスト項を減少させることができるため、リスクコスト項が組み込まれている場合、雑多な活動を組み込むことが有益である。

最適な複合コスト曲線

ここで、図１１を参照すると、いくつかの実施形態による、メンテナンス支出の関数として複合コストを示すグラフ１１００が示されている。いくつかの実施形態では、複合コストは、目的関数Ｊに関連する３つのコスト、すなわち図１０を参照して上述したメンテナンスコスト、資本コスト及び動作コストを含むことができる。いくつかの実施形態では、メンテナンス支出の増加により、複合コストを低減することができる。例えば、ＶＲＦシステムの屋外凝縮ユニットが通常動作に関して大量の電力を使用していることがある。屋外凝縮ユニットに対するメンテナンスを実施することにより、メンテナンスコストが生じることがあるが、動作コストに関して節約される額（例えば、電力消費に関連するコスト）を大幅に削減することができる。いくつかの実施形態では、ハード予算制約は、メンテナンス予算期間にわたる最大許容メンテナンス支出を示す最大メンテナンス予算１１０４である。ハード予算制約は、目的関数Ｊにおいてペナルティコストとして実装することができるソフト予算制約（図１２を参照してより詳細に述べる）とは区別される。

グラフ１１００は、いくつかの実施形態によれば、メンテナンス支出（Ｘ軸）に対する最適な複合コスト（Ｙ軸）を例示する曲線１１０２を含むものとして示されている。曲線１１０２は、様々なメンテナンス支出を仮定して、最適な複合コストがどのように変動し得るかを例示する。ビルディング管理システム（ＢＭＳ）では、機器をある効率レベルで動作させ続けるために、機器に対してメンテナンスを実施する必要があり得る。機器のメンテナンスは、請負業者の手数料、交換部品に関するコスト又は機器がメンテナンスのために一時的にオフラインになることにより生じるコストなど、追加コストを生じることがある。しかし、機器のメンテナンスは、機器の動作効率を高め、例えば電気消費又は燃料消費などの動作コストを削減することができる。

最適点１１０８が曲線１１０２上に示されている。最適点１１０８は、合計の複合コストを最小化するメンテナンス支出の額を示す。最適点１１０８の左側の曲線１１０２の区間は、メンテナンスに十分な額が費やされておらず、複合の出費が最適よりも高い場合を表す。最適点１１０８の右側の曲線１１０２の区間は、最適な額よりも多くメンテナンスに費やされている場合を表す。

グラフ１１００は、いくつかの実施形態によれば、予算限度点１１０６として示される曲線１１０２上の最大メンテナンス予算点も含むものとして示されている。予算限度点１１０６は、いくつかの実施形態によれば、最大メンテナンス予算１１０４と曲線１１０２との交点によって定義される。いくつかの実施形態では、最大メンテナンス予算１１０４は、メンテナンス予算期間にわたってメンテナンスに費やすことができる最大額である。例えば、ビルディングは、１０，０００ドルのメンテナンス予算を有することがある。１０，０００ドルのメンテナンス予算は、メンテナンス予算期間にわたってより多くの額をメンテナンスに費やすことによって合計の複合コストを下げることができたとしても、メンテナンス予算期間にわたって１０，０００ドル以下をメンテナンスに費やすべきであることを示す。いくつかの実施形態では、予算限度点１１０６は、最大メンテナンス予算１１０４により、最適点１１０８よりも低いメンテナンス支出になり得る。これは、最適な複合コストを実現するためにメンテナンスに十分な額が費やされていないことを示すことがある。他の実施形態では、最大メンテナンス予算１１０４が最適メンテナンス支出１１１２以上である場合、最適点１１０８を実現することができる。最大メンテナンス予算１１０４が最適なメンテナンス支出１１１２の右側にあることは、メンテナンス予算により、複合コストに関して費やされる額をビルディングが完全に最適化（すなわち最小化）することができることを示すことがある。

グラフ１１００は、コスト差１１１０も含むものとして示されている。いくつかの実施形態では、コスト差１１１０は、最大メンテナンス予算１１０４が最適メンテナンス支出１１１２未満であるときに（最適な複合コスト値を超えて）生じる追加コストを表す。例えば、予算限度点１１０６のＸ値（すなわちメンテナンス支出値）が最適点１１０８のＸ値以上である場合、コスト差１１１０は、０になることがあり、複合コストを完全に最適化するためにメンテナンス支出に十分な額を費やすことができることを示す。別の例として、最大メンテナンス予算１１０４が最適メンテナンス支出１１１２未満である場合、コスト差１１１０は、０よりも大きくなることがあり、複合コストを完全に最適化するためにメンテナンスに十分な額を費やすことができないことを示す。いくつかの実施形態では、コスト差１１１０は、より低い複合コストを生じるためにユーザがメンテナンス予算を増加することによってお金を節約できるというユーザへの指標としての役割を果たす。

いくつかの実施形態では、資本支出は、複合コストに対して、メンテナンス支出と同様及び／又は同一の結果を有することがある。いくつかの実施形態では、予算制約をメンテナンス支出と共に資本支出に適用することができる。予算制約が資本支出に適用される場合、目的関数Ｊは、予算制約を遵守しながら合計コストを最小化するように最適化することができる。

ここで、図１２を参照すると、いくつかの実施形態による、ソフト予算制約を受けた状態での目的関数Ｊの最適化に起因するメンテナンス支出の増加による複合コストの最適化を示すグラフ１２００が示されている。いくつかの実施形態では、複合コストは、目的関数Ｊに関連する３つのコスト、すなわち図１０を参照して上で述べたメンテナンスコスト、資本コスト及び動作コストを含むことができる。図１２において、ソフト予算制約は、複合コストに含まれていない。いくつかの実施形態によれば、ソフト予算制約が複合コストに含まれる場合、グラフ１２００は、グラフ１１００と非常に異なる可能性がある。いくつかの実施形態では、ソフト予算制約は、図１９Ａを参照して以下でより詳細に述べるように、ペナルティコストであり得る。いくつかの実施形態では、ペナルティコストは、メンテナンスに費やされる合計額が目標メンテナンスコスト１２１６から逸脱することを可能にするように生じる追加コストである。いくつかの実施形態では、ペナルティコストは、目標メンテナンスコスト１２１６とメンテナンスに費やされた合計額との間の差に基づく。いくつかの実施形態では、ペナルティコストは、無駄な予算を最小限に抑えるために、目標メンテナンスコスト１２１６に近い額をメンテナンスに費やすことを奨励する。いくつかの実施形態では、企業は、毎年のメンテナンス予算を割り振るためのフレームワークを実践することができる。いくつかの実施形態では、企業は、「それを使用するか又はそれを失うか」のポリシーを実践して、翌年のためのメンテナンス予算を前年の未使用額分だけ減らすことがある。例えば、目標メンテナンスコスト１２１６は、メンテナンス予算期間に関して決定されることがある。メンテナンス予算期間中に費やされなかった目標メンテナンスコスト１２１６の額は、その後、メンテナンス以外の別の予算に割り振ることができ、メンテナンスの観点から目標メンテナンスコスト１２１６の未使用部分をなくす。したがって、ペナルティコストは、目標メンテナンスコスト１２１６の未使用部分を最小限に抑えるように目的関数Ｊの最適化を奨励することができる。

グラフ１２００は、グラフ１１００に示されているのと同じ項目の多くを含むものとして示されている。図１２に示される項目のいくつか又はすべては、図１１での同じ参照番号を有する項目と同様及び／又は同一であり得る。図１２は、不感帯１２１４も含むものとして示されている。いくつかの実施形態では、不感帯１２１４は、ペナルティコストを生じることなくメンテナンスに費やすことができる目標メンテナンスコスト１２１６よりも上及び／又は下の範囲であり得る。いくつかの実施形態では、目標メンテナンスコスト１２１６に正確に等しい額を費やすことが非常に難しいことがあるため、不感帯１２１４は、メンテナンスに費やされる額を決定するときにある程度の柔軟性を与えられるように実装することができる。例えば、目標メンテナンスコスト１２１６をわずかに超えると、通常、非常に高いペナルティコストが生じることがあるため、目的関数オプティマイザ９４０は、すべてのメンテナンス支出の合計コストが目標メンテナンスコスト１２１６を超える目的関数Ｊの解を決定しない。しかし、不感帯１２１４の右側境界により、ペナルティコストを生じることなく目的関数オプティマイザ９４０が目標メンテナンスコスト１２１６をわずかに超えることが可能になり得る。同様に、目標メンテナンスコスト１２１６をわずかに下回ると、通常、比較的小さいペナルティコストが生じることがあるが、目的関数オプティマイザ９４０が不感帯１２１４の左側境界よりも大きい目的関数Ｊの解を決定することができる場合、不感帯１２１４の左側境界は、比較的小さいペナルティコストをなくすことがある。ペナルティコストについては、いくつかの実施形態に従って図１９Ａを参照して以下でより詳細に述べる。

予算制約を伴うモデル予測的メンテナンス

ここで、図１３を参照すると、いくつかの実施形態による、ユーザインターフェース８３６に接続された（図６〜９を参照して上でより詳細に述べた）モデル予測的メンテナンス（ＭＰＭ）システム６０２を例示するブロック図が示されている。いくつかの実施形態では、ユーザインターフェース８３６は、メンテナンス予算及び／又はメンテナンス予算に関連するメンテナンス予算期間を高レベルオプティマイザ８３２に通信することができる。いくつかの実施形態では、高レベルオプティマイザ８３２は、メンテナンス予算及び／又はメンテナンス予算期間を使用して、メンテナンス予算制約及び／又はペナルティコストを決定することができる。

ユーザインターフェース８３６は、いくつかの実施形態によれば、ユーザからメンテナンス予算及び／又はメンテナンス予算期間を受信し、ＭＰＭシステム６０２と通信するように構成された任意のインターフェースであり得る。いくつかの実施形態では、ユーザインターフェース８３６は、ユーザから資本予算及び／又は資本購入期間を受信し、それをＭＰＭシステム６０２に通信するように構成することができる。例えば、ユーザインターフェース８３６は、モバイルデバイスアプリケーション、ビルディングでのコマンドライン端末、ウェブサイトアプリケーション、ディスプレイデバイス、タッチスクリーン、サーモスタットなどとして実装することができる。いくつかの実施形態では、ユーザインターフェース８３６は、直接接続（例えば、ローカル有線又は無線通信）を介して、通信インターフェース８０４を介して又は通信ネットワーク４４６（例えば、ＷＡＮ、インターネット、セルラネットワークなど）を介して高レベルオプティマイザ８３２と通信するように構成される。

いくつかの実施形態では、ユーザインターフェース８３６は、１つ又は複数のメンテナンス予算及び／又はメンテナンス予算期間を高レベルオプティマイザ８３２に通信するように構成される。いくつかの実施形態では、ユーザインターフェース８３６は、資本予算及び／又は資本購入期間を高レベルオプティマイザ８３２に通信するように構成される。メンテナンス予算は、いくつかの実施形態によれば、メンテナンス予算期間及び／又は最適化期間にわたってメンテナンスに費やすことができる最大額を示すことがある。同様に、資本予算は、いくつかの実施形態によれば、資本購入期間及び／又は最適化期間にわたって資本購入に費やすことができる最大額を示すことがある。いくつかの実施形態では、予算（すなわちメンテナンス予算及び／又は資本予算）及び／又は期間（すなわちメンテナンス予算期間及び／又は資本購入期間）の受信に応答して、高レベルオプティマイザ８３２は、目的関数Ｊに含めることができる制約を決定することができる。

例えば、目的関数Ｊは、対称的な制約又は非対称的な制約のいずれかとして実装されたソフト予算制約を含むことがある。いくつかの実施形態では、対称的なソフト制約に関して、補助変数δは、修理（例えば、メンテナンス、交換など）活動に費やされた額と、修理活動に費やす目標額（例えば、予算）との間の差の大きさ以上であるものとして制約される。コスト関数（例えば、目的関数Ｊ）では、δにペナルティレートを乗算してコスト関数に追加することができる。例えば、混合整数線形計画法（ＭＩＬＰ）の実装では、対称的なソフト制約は、以下の形式を有することができる。
｜Ｃ_ａｃｔ−Ｂｕｄ_ａｃｔ｜≦δ
ここで、Ｃ_ａｃｔは、修理活動（例えば、メンテナンス、交換など）に費やされた合計額であり、Ｂｕｄ_ａｃｔは、修理活動に費やす予算であり、δは、修理活動に関するペナルティコストを決定するためのレートを乗算される補助変数である。いくつかの実施形態では、対称的なソフト制約は、複数の修理活動に関して決定される。δが０に近づくとき、目的関数Ｊに課される追加のペナルティコストが減少することがある。目的関数Ｊでは、対称的なソフト制約による追加のペナルティコストを以下のように含むことができる。

ここで、ｒは、目的関数Ｊに対する対称的なソフト予算制約の影響を低減／増加するように調整することができるペナルティレートである。したがって、ｒが増加するにつれて、目的関数オプティマイザ９４０は、全体的なコストを最適化（例えば、低減）するためにδの値を減少することを試みることができる。

いくつかの実施形態では、ソフト制約は、非対称的なソフト制約として実装される。非対称的なソフト制約は、合計コストが目標予算を下回る場合と合計コストが目標予算を上回る場合とで異なるペナルティレートを有することを可能にすることができる。例えば、目的関数Ｊが非対称的なソフト制約を受けて最適化される場合、修理活動に関するペナルティコストｐを目的関数Ｊに追加することができ、ここで、ｐは、以下の制約を受ける。
ｐ≧ｒ_ｏｖｅｒ（Ｃ_ａｃｔ−Ｂｕｄ_ａｃｔ）
ｐ≧−ｒ_{ｕｎｄｅｒ}（Ｃ_ａｃｔ−Ｂｕｄ_ａｃｔ）
ここで、Ｃ_ａｃｔは、修理活動（例えば、メンテナンス、交換など）からの合計コストであり、Ｂｕｄ_ａｃｔは、修理活動に関する予算であり、ｒ_ｏｖｅｒは、予算を上回るコストに関するペナルティレートであり、ｒ_{ｕｎｄｅｒ}は、予算を下回るコストに関するペナルティレートである。目的関数Ｊには、非対称的なソフト制約による追加のペナルティコストを以下のように含むことができる。

ここで、ｐは、上記の制約を受ける。ソフト制約については、図１９Ａを参照して以下でより詳細に述べる。

いくつかの実施形態では、目的関数オプティマイザ９４０は、これらの制約を使用して、最適化期間にわたって目的関数Ｊを最適化する。例えば、ユーザは、次のメンテナンス予算期間にわたってメンテナンスに費やすことができるのが１０，０００ドル以下であることを示すメンテナンス予算を高レベルオプティマイザ８３２に通信することができる。メンテナンス予算の受信に応答して、高レベルオプティマイザ８３２は、目的関数Ｊに制約を生成し、次のメンテナンス予算期間にわたってメンテナンスに１０，０００ドル以下を割り振ることができるようにする。したがって、目的関数オプティマイザ９４０は、最適化期間中のすべてのメンテナンスに関する合計メンテナンス支出が１０，０００ドル以下になるように目的関数Ｊの最適解を決定することができる。別の例として、ユーザは、ユーザインターフェース８３６を介して高レベルオプティマイザ８３２に第１のメンテナンス予算期間を通信することができ、第１のメンテナンス予算期間が生じる時間間隔を示す。例えば、メンテナンス予算期間は、開始時（例えば、月、日、年）及び終了時（例えば、月、日、年）を含むことがある。いくつかの実施形態では、第１のメンテナンス予算期間は、最適化期間内に完全に入ることがある。いくつかの実施形態では、第１のメンテナンス予算期間は、部分的にのみ最適化期間内に入ることがある。第１のメンテナンス予算期間の受信に応答して、高レベルオプティマイザ８３２は、最適化問題に追加の制約を生成することができる。追加の制約は、合計メンテナンス及び／又は資本コストを目標予算（例えば、期間に関する最大メンテナンス及び交換予算）未満にすべきであることを示すことができる。いくつかの実施形態によれば、これにより、第１のメンテナンス予算を超えないように異なる決定変数を設定することができる。

ここで、図１４Ａを参照すると、いくつかの実施形態による高レベルオプティマイザ８３２をさらに例示するブロック図が示されている。いくつかの実施形態では、高レベルオプティマイザ８３２は、目的関数Ｊに関する制約を決定し、制約に基づいて目的関数Ｊを最適化するように構成することができる。いくつかの実施形態では、高レベルオプティマイザ８３２は、予算制約を生成し、予算制約を目的関数生成器９３５及び／又は目的関数オプティマイザ９４０に提供するように構成された予算マネージャ９４２を含む。いくつかの実施形態では、高レベルオプティマイザ８３２は、ペナルティコスト項を生成し、ペナルティコスト項を目的関数生成器９３５に提供するように構成されたペナルティコストマネージャ９４４を含む。いくつかの実施形態では、高レベルオプティマイザ８３２は、予算マネージャ９４２及びペナルティコストマネージャ９４４の少なくとも一方を使用して、それぞれ目的関数生成器９３５及び／又は目的関数オプティマイザ９４０のための予算制約及びペナルティコスト項を生成する。いくつかの実施形態では、高レベルオプティマイザ８３２の特定の構成要素は、単一の構成要素の一部である。しかし、説明を簡単にするために、図１４Ａでは各構成要素が個別に示されている。

いくつかの実施形態では、予算マネージャ９４２は、受信された最大予算及び／又は受信された予算期間に基づいて、目的関数生成器９３５及び／又は目的関数オプティマイザ９４０に予算制約を提供する。いくつかの実施形態では、最大予算は、対応する予算期間に関する最大メンテナンス予算及び／又は最大資本購入予算であり得る。同様に、予算期間は、いくつかの実施形態によれば、メンテナンス予算期間及び／又は資本購入期間であり得る。いくつかの実施形態では、予算制約は、予算期間を最大予算に関連付けることができる（すなわち予算期間に関する最大予算がある）。いくつかの実施形態では、予算制約は、ハード予算制約としての役割を果たすことがあり、目的関数オプティマイザ９４０は、メンテナンス及び／又は資本購入に費やされる額（例えば、ドル）が各予算期間に関する最大予算以下になるように、目的関数生成器９３５によって生成される目的関数Ｊを最適化する。

いくつかの実施形態では、予算マネージャ９４２に通信される最大予算及び／又は予算期間は、前の予算期間に基づいて決定される。いくつかの実施形態では、図６を参照して述べたＭＰＭシステム６０２は、前の予算期間からの結果を使用して、今後の予算期間を計画するように構成することができる。例えば、前の予算期間が過剰に高い最大予算を有していた場合、ＭＰＭシステム６０２は、今後の予算期間のための最大予算を下げることがある。同様に、ＭＰＭシステム６０２は、いくつかの実施形態によれば、将来の予測に基づいて、今後の予算期間のための最大予算を推定することが可能であり得る。将来の予測は、機器の劣化モデル、ビルディングの今後の改修、将来の予算制限などに基づくことがある。例えば、各構成要素の劣化モデルに基づいて、ＭＰＭシステム６０２の多くの構成要素の劣化状態が同じ予算期間中に臨界レベルに達すると推定される場合、ＭＰＭシステム６０２は、その予算期間に対して高い最大予算が必要とされ得ることを推定することがある。いくつかの実施形態では、ビルディング機器の設置中、ビルディング機器の劣化モデルが提供される。いくつかの実施形態では、ビルディング機器の劣化モデルは、経時的なビルディング機器の測定された性能変数に基づいてＭＰＭシステム６０２によって生成される。

いくつかの実施形態では、メンテナンスコスト予測器９２０及び／又は資本コスト予測器９３０は、メンテナンスコスト項又は資本コスト項を提供して、第ｊの予算期間に関する合計活動支出Ｃｏｓｔ_{ａｃｔ，ｊ}と、最適化期間に関する合計活動支出Ｃｏｓｔ_ａｃｔとを決定することができる。一般に、第ｊの予算期間に関する合計活動支出は、以下の式によって計算することができる。

ここで、Ｃｏｓｔ_{ａｃｔ，ｊ}は、第ｊの予算期間に関する合計活動支出（例えば、メンテナンスコスト項及び／又は資本コスト項）であり、Ｃ_{ａｃｔ，ｉ}は、それぞれ時間ステップｉで実施することができる様々なメンテナンス又は交換活動のコストを表すメンテナンス又は交換コスト（例えば、Ｃ_{ｍａｉｎ，ｉ}又はＣ_{ｃａｐ，ｉ}）のアレイであり、Ｂ_{ａｃｔ，ｉ}は、異なるタイプの活動（例えば、Ｂ_{ｍａｉｎ，ｉ}又はＰ_{ｃａｐ，ｉ}）のそれぞれが時間ステップｉで実施されるか否かを示すバイナリ決定変数のアレイであり、ｈは、最適化が実施されるホライズン又は最適化期間（例えば、最適化期間での時間ステップｉの総数）の継続期間であり、Ｍａｓｋ_ｊ，ｉは、時間ステップｉが第ｊの予算期間中に生じるか否かを示すバイナリ変数（例えば、０又は１）である。

さらに、最適化期間に関する合計活動支出は、以下の式によって計算することができる。

ここで、Ｃｏｓｔ_ａｃｔは、最適化期間に関する合計活動支出である。いくつかの実施形態では、Ｍａｓｋ_ｊ，ｉは、時間ステップｉが予算期間（例えば、メンテナンス予算期間又は資本コスト予算期間）中に生じるか否かを示すことができる。例えば、Ｍａｓｋ_ｊ，ｉ＝０は、第ｊの予算期間中に現在の時間ステップｉが生じないことを示すことがあり、したがって時間ステップｉでＣｏｓｔ_{ａｃｔ，ｊ}について支出が生じることはない。一般に、Ｍａｓｋ_ｊ，ｉは、以下の形式を有する行列Ｍａｓｋの要素であり得る。

ここで、ｈは、最適化期間での最後の時間ステップ（すなわちｉ＝ｈ）であり、ｎは、最適化期間中の予算期間の総数（すなわちメンテナンス予算期間の総数及び／又は資本コスト予算期間の総数）であり、Ｍａｓｋ_ｊ，ｉは、時間ステップｉが第ｊの予算期間中に生じるか否かを示すバイナリ決定変数である。

例えば、最適化期間中に２つの予算期間及び合計３つの時間ステップがある実施形態では、Ｍａｓｋは以下の形式を有することがある。

ここで、Ｍａｓｋ_１，１は、時間ステップ１が予算期間１中に生じるか否かを示すバイナリ変数であり、Ｍａｓｋ_２，１は、時間ステップ１が予算期間２中に生じるか否かを示すバイナリ変数であるなどである。さらに、上記の例のＭａｓｋは、以下のように示すこともできる。

ここで、Ｍａｓｋ_１，１＝０は、時間ステップｉ＝１が予算期間ｊ＝１中に生じないことを示し、Ｍａｓｋ_１，２＝０は、時間ステップｉ＝２が予算期間ｊ＝１中に生じないことを示し、Ｍａｓｋ_１，３＝１は、時間ステップｉ＝３が予算期間ｊ＝１中に生じることを示し、Ｍａｓｋ_２，１＝１、Ｍａｓｋ_２，２＝１及びＭａｓｋ_２，３＝０は、時間ステップｉ＝１〜ｉ＝２にわたって予算期間ｊ＝２が生じることを示す。いくつかの実施形態では、図１５及び図１６を参照して以下で述べるグラフ１５００及びグラフ１６００は、それぞれ第ｊのメンテナンス予算期間に関する合計活動支出及び／又は最適化期間に関する合計活動支出をどのように使用することができるかをさらに詳述することができる。

いくつかの実施形態では、目的関数生成器９３５は、最適化期間中に複数の予算期間が生じる場合に関する目的コスト関数を生成することができる。例えば、目的関数生成器９３５は、以下のような目的関数を生成することができる。

いくつかの実施形態では、高レベルオプティマイザ８３２は、最適化期間にわたる各予算期間のための最大予算を含む最大予算ベクトルＢｕｄ_ｍａｘを定義することができる。一般に、Ｂｕｄ_ｍａｘは、以下の形式を有することができる。

ここで、ｎは、最適化期間中に生じる予算期間の数（例えば、メンテナンス予算期間の数）であり、Ｂｕｄ_{ｍａｘ，ｊ}は、第ｊの予算期間に関する最大予算を示す。いくつかの実施形態では、予算マネージャ９４２は、目的関数Ｊに関する制約を生成することができる。

ここで、Ｃ_{ａｃｔ，ｉ}は、時間ステップｉで実施することができる可能なメンテナンス／交換活動のそれぞれに関する要素を有するコストのアレイであり、Ｂ_{ａｃｔ，ｉ}は、可能なメンテナンス／交換活動のそれぞれが時間ステップｉで実施されるか否かを示すバイナリ決定変数の列ベクトルであり、Ｍａｓｋ_ｉは、列ベクトル（すなわち時間ステップｉに対応するＭａｓｋ行列の列）であり、各予算期間ｊに関する要素を有し、Ｍａｓｋ_ｉベクトルの各要素が、時間ステップｉが対応する予算期間ｊ内にあるか否かを示し、Ｂｕｄ_ｍａｘは、Ｂｕｄ_ｍａｘの各要素が対応する予算期間ｊに関するメンテナンス／交換活動予算を定義するように各予算期間ｊに関する要素を有する列ベクトルである。例えば、Ｂｕｄ_{ｍａｘ，１}＝１００である場合、目的関数オプティマイザ９４０は、ｊ＝１の予算期間が１００（例えば、１００ドル）を超える累積メンテナンス／交換支出を有さないように目的関数Ｊを最適化（例えば、最小化）する。

いくつかの実施形態では、Ｂｕｄ_ｍａｘの値は、各予算期間及びビルディング機器の劣化に関するすべての出費（例えば、動作、メンテナンス、交換、従業員の給与など）を含む利用可能な最大予算に基づいて決定される。ビルディング機器が劣化するにつれて、最大利用可能予算のより多くがビルディング機器のメンテナンス及び交換に割り振られることが必要とされ得る。例えば、ビルディング機器のすべてのビルディングデバイスの劣化状態が低い場合、いくつかのビルディングデバイスの劣化状態が大きい場合よりもＢｕｄ_ｍａｘの値が小さいことがある。換言すると、ビルディング機器の劣化状態に基づいて、各予算期間のためのメンテナンス／交換に関する予算を各予算期間に関する最大利用可能予算から割り振ることができる。いくつかの実施形態では、図１７及び図１８を参照して以下で述べるグラフ１７００及びグラフ１８００は、それぞれ最大予算ベクトルＢｕｄ_ｍａｘの利用をさらに例示する。

いくつかの実施形態では、予算マネージャ９４２は、目的関数Ｊに関する制約を最適化問題の追加の状態として生成する。その状態は、例えば、予算の残額及び／又はメンテナンス／交換に既に費やされた額であり得る。状態を最適化期間全体にわたって追跡して、目的関数Ｊの最適化を制約して、特定のパラメータ範囲内に状態を保つことができる。例えば、状態が予算の残額を含む場合、状態の値は、最適化期間の開始時のメンテナンス／交換予算と等しくなることがあり、実施される各メンテナンス／交換ごとに減少することがある。最適化を実施し、状態がハード制約を示している場合、最適化は、状態の値を０以上に維持する解を決定することを必要とされることがある。最適化を実施し、状態がソフト制約を示している場合、最適化は、状態の値を０未満に低下させることがあるが、追加のペナルティコストが生じる可能性がある。有利には、状態として予算制約を実装することで、動的プログラミングフレームワークを使用して最適化問題を解決することが可能になり得る。

ここで、図１４Ａ及び１８を参照すると、予算期間の一部のみが最適化期間中に生じる場合、高レベルオプティマイザ８３２は、部分的にのみ最適化期間中に生じる予算期間に割り振られるメンテナンス及び交換予算を調整すべきである。図１８のグラフ１８００は、いずれも部分的に最適化期間１８０２中に生じる第１のメンテナンス予算期間１８０４及び第３のメンテナンス予算期間１８１６を示す。予算期間が部分的にのみ最適化期間中に生じる場合、予算マネージャ９４２は、その最適化期間のための利用可能な予算を、過去及び／又は将来の最適化期間を妨害しないように決定することを必要とされ得る。

例えば、図１８に示されるように、第１のメンテナンス予算期間１８０４は、ｉ＝１での最適化期間１８０２の開始前に始まるものとして示されている。第１のメンテナンス予算期間１８０４は、部分的にのみ最適化期間１８０２内で生じるため、予算マネージャ９４２は、最大予算ベクトルＢｕｄ_ｍａｘの第１のメンテナンス予算期間１８０４のための最大予算であるＢｕｄ_{ｍａｘ，１}を第１のメンテナンス予算期間１８０４のために利用可能な資産残額に設定することができる。特に、図１８のグラフ１８００に示されるように、第１のメンテナンス予算期間１８０４は、最適化期間１８０２の開始前に（例えば、ｉ＝１の前の３つの時間ステップで）支出を含む。予算マネージャ９４２は、Ｂｕｄ_{ｍａｘ，１}の値を第１のメンテナンス予算期間１８０４の資産残額に設定することにより、最適化期間１８０２前に生じた支出（例えば、メンテナンス支出又は資本コスト支出）を考慮に入れることができる。図１８に示されるように、第１のメンテナンス予算期間１８０４は、Ｂｕｄ_{ｍａｘ，１}から差し引くことができる単一の出費を含む。例えば、Ｂｕｄ_{ｍａｘ，１}に１，０００ドルが割り振られているが、最適化期間１８０２が始まる前に２００ドルが費やされた場合、予算マネージャ９４２は、最適化期間１８０２にＢｕｄ_{ｍａｘ，１}＝８００ドルを設定することができる。

いくつかの実施形態では、予算期間の一部のみが最適化期間中に生じる場合、予算マネージャ９４２は、低減された予算値を決定する。一般に、低減された予算値は、以下の式によってモデル化することができる。
Ｂｕｄ_{ｒｅｄｕｃｅｄ}＝Ｐ×Ｂｕｄ_ｍａｘ
ここで、Ｂｕｄ_{ｒｅｄｕｃｅｄ}は、低減された予算であり、Ｂｕｄ_ｍａｘは、最適化期間にわたって部分的に生じる予算期間（例えば、第１のメンテナンス予算期間１８０４）のための最大予算であり、Ｐは、最適化期間中に生じる予算期間の一部を示す正規化された値（すなわち０≦Ｐ≦１）である。例えば、予算期間が最適化期間内で完全に生じる場合（例えば、図１８に示されるように、第２のメンテナンス予算期間１８０６が最適化期間１８０２内で完全に生じる場合）、Ｐの値は、１となることがあり、Ｂｕｄ_{ｒｅｄｕｃｅｄ}＝Ｂｕｄ_ｍａｘである。予算期間が部分的にのみ最適化期間中に生じる（例えば、第１のメンテナンス予算期間１８０４及び第３のメンテナンス予算期間１８１６が部分的に最適化期間１８０２内で生じる）場合、Ｐは、最適化期間中に生じる予算期間の量（例えば、１／２、１／３、１／４など）を示すことがある。例えば、予算期間の５０％が最適化期間中に生じる場合、Ｐ＝０．５である。いくつかの実施形態では、低減された予算は、最適化期間中に始まるが、最適化期間の終了後に終了する予算期間に関して計算される（例えば、第３のメンテナンス予算期間１８１６は、最適化期間１８０２中に始まるが、最適化期間１８０２の終了後に終了する）。

第ｎの予算期間が部分的に最適化期間内で生じる（例えば、図１８に示されるように、第３のメンテナンス予算期間１８１６が部分的に最適化期間１８０２内で生じる）場合、予算マネージャ９４２は、いくつかの実施形態によれば、第ｎの予算を以下のように決定する。
Ｂｕｄ_{ｒｅｄｕｃｅｄ，ｎ}＝Ｐ×Ｂｕｄ_{ｍａｘ，ｎ}
予算マネージャ９４２は、最大予算ベクトルＢｕｄ_ｍａｘの第ｎの値をＢｕｄ_{ｒｅｄｕｃｅｄ，ｎ}として更新し、更新された最大予算ベクトルＢｕｄ_ｍａｘを目的関数生成器９３５及び／又は目的関数オプティマイザ９４０に制約として提供することができる。

再び図１４を参照すると、ペナルティコストマネージャ９４４は、目的関数生成器９３５にペナルティコスト項を提供することができる。いくつかの実施形態では、ペナルティコスト項は、目的関数オプティマイザ９４０によって計算された、予算期間に関する最大予算と推定支出（例えば、推定されるメンテナンス支出又は推定される資本購入支出）との間の差に基づくペナルティコストを定義する。いくつかの実施形態では、ペナルティコストは、目的関数Ｊを最適化するときに目的関数オプティマイザ９４０によって考慮される追加コストである。いくつかの実施形態では、修正された目的関数Ｊ_ｍｏｄは、目的関数Ｊの解とペナルティコストとの両方を含む。一般に、Ｊ_ｍｏｄは、以下の式によってモデル化することができる。

ここで、Ｊは、目的関数Ｊであり、ｗ_ｊは、ｐ_ｋ，ｊの値を増加又は減少する重みであり、ｐ_ｋ，ｊは、第ｊの予算期間にわたって生じたペナルティコストである。いくつかの実施形態では、ｗ_ｊは、値１を有し、追加の重みがｐ_ｋ，ｊに起因しないことを示すことができる。いくつかの実施形態では、ｗ_ｊは、ｐ_ｋ，ｊの効果を増加させる（目的関数オプティマイザ９４０に、予算期間に関する最大予算と推定支出とが実質的に等しくなるようにする解を実現させる）ように調整すること又はｐ_ｋ，ｊの効果を低減するように減少することができる正規化された値である。いくつかの実施形態では、ペナルティコストは、区分的関数によってモデル化することができる。一般に、ペナルティコストをモデル化する区分的関数は、以下の形式を有することができる。

ここで、ｐｋは、ペナルティコストであり、Ａは、Ｂｕｄ_{ｍａｘ，ｊ}−Ｃｏｓｔ_{ｅｓｔ，ｊ}＜０に関する勾配であり、Ｂは、Ｂｕｄ_{ｍａｘ，ｊ}−Ｃｏｓｔ_{ｅｓｔ，ｊ}＞０に関する勾配であり、Ｂｕｄ_{ｍａｘ，ｊ}は、予算期間ｊにわたる最大予算（例えば、最大予算ベクトルＢｕｄ_ｍａｘの第ｊの値）であり、Ｃｏｓｔ_{ｅｓｔ，ｊ}は、予算期間ｊにわたる推定支出である。いくつかの実施形態では、Ａ及び／又はＢを増加又は減少させて、より大きい重みをペナルティコストに加えることができる。例えば、Ｂｕｄ_{ｍａｘ，ｊ}−Ｃｏｓｔ_{ｅｓｔ，ｊ}＜０であるとき、Ａを増加させることにより、ｐ_ｋ，ｊの値が増加することがある。いくつかの実施形態では、Ａ及び／又はＢの増加は、ｐ_ｋ，ｊが実質的にゼロに等しくなるように、Ｂｕｄ_{ｍａｘ，ｊ}とＣｏｓｔ_{ｅｓｔ，ｊ}との間の差を低下させる目的関数Ｊの解を決定することを奨励することができる。いくつかの実施形態では、Ａ及びＢは、図１９Ａを参照して以下でさらに詳細に述べる。いくつかの実施形態では、第ｊの予算期間に関するＣｏｓｔ_{ｅｓｔ，ｊ}は、以下の式によってモデル化することができる。
Ｃｏｓｔ_{ｅｓｔ，ｊ}＝Ｃｏｓｔ_{ｍａｉｎ，ｊ}＋Ｃｏｓｔ_{ｃａｐ，ｊ}、又は
Ｃｏｓｔ_{ｅｓｔ，ｊ}＝Ｃｏｓｔ_{ｃａｐ，ｊ}、又は
Ｃｏｓｔ_{ｅｓｔ，ｊ}＝Ｃｏｓｔ_{ｍａｉｎ，ｊ}
ここで、Ｃｏｓｔ_{ｍａｉｎ，ｊ}は、第ｊの予算期間に関するメンテナンスコスト項であり、Ｃｏｓｔ_{ｃａｐ，ｊ}は、第ｊの予算期間に関する目的関数Ｊの資本コスト項である。いくつかの実施形態では、ｐ_ｋ，ｊを計算するとき、Ａは、Ｂよりも大きくなることがあり、これは、推定支出が最大予算を超える場合、より高いペナルティコストが生じ得ることを示すことができる。Ａ及びＢの値に基づいて、目的関数オプティマイザ９４０は、例えば、Ａ及びＢの値に対して生じるペナルティコストを最小化する決定変数の最適値を決定することができる。いくつかの実施形態では、目的関数オプティマイザ９４０が、メンテナンス活動と資本購入との両方を含むことができる最適なメンテナンススケジュールを決定するとき、目的関数オプティマイザ９４０は、最大予算と推定支出との間の差を最小化してペナルティコストを低減するように構成することができる。いくつかの実施形態では、ペナルティコストの値は、最大予算と推定支出との間の差に関連し、最大予算と推定支出との間の差の増加は、ペナルティコストのより高い値に対応する（例えば、結果としてもたらす）。いくつかの実施形態では、推定支出が最大予算を下回るときではなく、推定支出が最大予算を上回るとき、ペナルティコストがより高い割合で増加することがある。いくつかの実施形態では、目的関数オプティマイザ９４０は、ペナルティコストを最小化するように、最大予算と推定支出との間の差を減少するように機能することができる。

いくつかの実施形態では、高レベルオプティマイザ８３２は、支出の差を予算期間にわたる最大予算と推定支出との間の差として定義することができる。一般に、支出の差は、次の式を使用してモデル化することができる。
Ｊ_{ｇａｐ，ｊ}＝Ｂｕｄ_{ｍａｘ，ｊ}−Ｃｏｓｔ_{ｅｓｔ，ｊ}
ここで、Ｊ_{ｇａｐ，ｊ}は、第ｊの予算期間に関する支出の差であり、Ｂｕｄ_{ｍａｘ，ｊ}は、第ｊの予算期間の最大予算であり、Ｃｏｓｔ_{ｅｓｔ，ｊ}は、予算期間ｊにわたる推定支出である。いくつかの実施形態では、支出の差を目的関数オプティマイザ９４０が使用して、ハード予算制約が遵守されるか否かを推定することができる。いくつかの実施形態では、Ｊ_{ｇａｐ，ｊ}は、正であり得、累積支出の最終値が予算期間に関する最大予算よりも小さいと推定されることを示す。いくつかの実施形態では、Ｊ_{ｇａｐ，ｊ}は、０に等しいことがあり得、第ｊの予算期間にわたって正確に最大予算がコストに累積されると推定されることを示す。いくつかの実施形態では、Ｊ_{ｇａｐ，ｊ}は、負であり得、最大予算よりも大きい額が予算期間にわたってコストに累積されると推定されることを示す。いくつかの実施形態では、ハード予算制約により、目的関数Ｊを解くことができなくなることがある。いくつかの実施形態では、目的関数Ｊを解くことができない場合、目的関数オプティマイザ９４０は、エラーを返すことができる。いくつかの実施形態では、目的関数オプティマイザ９４０によって支出の差を使用して、予算期間に関するペナルティコストを決定することができる。一般に、支出の差が大きいほど、ペナルティコストも大きくなり得る。ペナルティコストについては、図１９Ａを参照して以下でより詳細に述べる。

故障リスクを伴うモデル予測的メンテナンス

ここで、図１４Ｂを参照すると、いくつかの実施形態による高レベルオプティマイザ８３２をさらに例示するブロック図が示されている。いくつかの実施形態では、高レベルオプティマイザ８３２は、ビルディング機器の故障リスクを目的関数Ｊに組み込み、故障リスクに基づいて目的関数Ｊを最適化する。いくつかの実施形態では、図１４Ｂに示されるような高レベルオプティマイザ８３２は、図１４Ａを参照して上述したように予算マネージャ９４２及び／又はペナルティコストマネージャ９４４を組み込む。いくつかの実施形態では、図１４Ｂに示されるような高レベルオプティマイザ８３２は、別個の使用ケースを示し、目的関数生成器９３５によって生成される目的関数がリスクコスト項を組み込み、且つ予算制約／ペナルティコスト項を組み込むことも組み込まないこともある。

いくつかの実施形態では、高レベルオプティマイザ８３２は、リスクコスト項を生成し、リスクコスト項を目的関数生成器９３５に提供するための故障リスク予測器９４６を含む。ビルディング機器は、時間と共に劣化するため、ビルディング機器が故障する確率は、高まることがある。具体的には、ビルディング機器のメンテナンス／交換が実施されない場合、ビルディング機器が将来の時間ステップで故障し得る確率は、ビルディング機器が現在の時間ステップで故障し得る確率以上であり得る。ビルディング機器の故障は、ＢＭＳ６０６が、未対処の負荷又は失われた生産量などの様々な機会コストと共に、ビルディング機器のメンテナンス及び／又は交換に関連するコストを生じることを必要とすることがある。例えば、ＶＲＦシステムの屋内ユニット（ＩＤＵ）が故障し、故障により部屋の居住者に安全上の問題が発生した場合、ＩＤＵのメンテナンス／交換の実施に関連するコストと、部屋の閉鎖（例えば、居住者のための新たな部屋の賃借、部屋での会議のキャンセル、生産の損失など）に関連するコストとが生じることがある。

故障リスク予測器９４６によって生成されるリスクコスト項は、最適化期間の時間ステップに関する追跡されるビルディング機器の故障の確率を、追跡されるビルディング機器の故障のコストと共に組み込むことができる。上述したように、追跡されるビルディング機器は、劣化状態及び／又は他の性能情報が観察される任意のビルディング機器を含むことができる。

故障リスク予測器９４６によって提供されるリスクコスト項に基づいて、目的関数生成器９３５は、予測器９１０〜９３０によって提供されるコスト項と共にリスクコスト項を組み込む目的関数（例えば、目的関数Ｊ）を生成することができる。例えば、目的関数生成器９３５によって生成される目的関数は、以下の形式を有することができる。

ここで、Ｃ_ｏｐ，ｋ（δ_ｋ）は、劣化状態δ_ｋに依存する動作コストであり、Ｃ_{ｍａｉｎ，ｋ}は、最適化期間の時間ステップｋでのメンテナンスのコストであり、Ｃ_{ｒｅｐｌａｃｅ，ｋ}は、時間ステップｋでの交換のコストであり、ｍ_ｋは、時間ステップｋにおいていずれのメンテナンスアクションが行われるかを表すバイナリベクトルであり、Ｐ_{ｆａｉｌ，ｋ}（δ_ｋ）は、劣化状態δ_ｋに依存する追跡されるビルディング機器の各構成要素（例えば、ＢＭＳ６０６の各追跡される構成要素）に関する故障確率のベクトルであり、Ｃ_{ｆａｉｌ，ｋ}は、追跡されるビルディング機器の故障のコストであり、ｈは、最適化期間の時間ステップの総数である。上記の目的関数では、上付きのＴは、関連する行列の転置行列を示す。Ｃ_{ｆａｉｌ，ｋ}の値は、追跡されるビルディング機器を修理／交換するためのコスト及び／又は追跡されるビルディング機器の故障に関連する任意の機会コストを含むことができる。メンテナンスベクトルの第１のブロックは、メンテナンスオプションを含み、メンテナンスベクトルの第２のブロックは、交換オプションを含むことを理解すべきである。第１のブロックと第２のブロックとは、メンテナンスと新たなビルディング機器への交換との両方がどのように考慮されるかを示すために分けられている。いくつかの実施形態では、それぞれメンテナンス及び交換オプションを示す第１及び第２のブロックは、単一のブロックに組み合わされる。さらに、Ｃ_{ｆａｉｌ，ｋ} ^ＴＰ_{ｆａｉｌ，ｋ}（δ_ｋ）が目的関数のリスクコスト項を示していることを理解すべきである。

いくつかの実施形態では、リスクコスト項を組み込む目的関数生成器９３５によって生成された目的関数は、以下の形式を有する。

ここで、Ｃ_{ｆａｉｌ，ｉ}は、最適化期間の時間ステップｉでのビルディング機器の故障のコストであり、Ｐ_{ｆａｉｌ，ｉ}（δ_ｉ）は、時間ステップｉでの劣化の状態δ_ｉに基づく時間ステップｉでの故障の確率であり、すべての他の変数は、上述したものである。

リスクコスト項を含む目的関数に基づいて、目的関数オプティマイザ９４０は、全体的なコストが最適化（例えば、最小化）されるように決定変数の最適値を決定することができる。リスクコスト項により、リスクコスト項が目的関数に含まれなかった場合よりも早い／遅い時間ステップで特定のメンテナンス及び／又は交換が行われることがある。特に、リスクコスト項は、コストが最適化されるように、ビルディング機器の任意のビルディングデバイスに関する故障の確率が十分に低く保たれるように目的関数オプティマイザ９４０によって管理することができる。いくつかの実施形態では、リスクコスト項は、ビルディングデバイスが故障しやすい臨界レベルにビルディングデバイスの劣化状態が達しないように、リスクコスト項が目的関数に含まれなかった場合よりも頻繁にビルディング機器のビルディングデバイスがメンテナンス／交換を実施されることを目的関数オプティマイザ９４０が保証することを必要とすることがある。

いくつかの実施形態では、δ_ｉの値がランダムに分散された閾値を超える場合、ビルディング機器の故障が生じたとみなされる。いくつかの実施形態では、ビルディング機器の各ビルディングデバイスに関する故障の閾値は、特定のビルディングデバイスに応じて異なる。例えば、設置時の信頼性と比較した信頼性のパーセンテージとして劣化が測定される場合、特定のＩＤＵは、設置時の信頼性の３０％を下回る場合に故障したとみなされることがある一方、ＨＶＡＣシステムのファンは、設置時の信頼性の２０％を下回る場合に故障したとみなされることがある。いくつかの実施形態では、ビルディング機器の各ビルディングデバイスに関する故障の閾値は、同じである。例えば、設置時の信頼性のパーセンテージに基づいて劣化が測定される場合、任意のビルディングデバイスが設置時の信頼性の１５％を下回る場合、そのビルディングデバイスが故障したとみなされることがある。いくつかの実施形態では、例えば、ビルディング機器が始動できない場合やビルディング機器が居住者にとって危険な出力（例えば、煙、有害ガス）を生成している場合など、ビルディング機器の故障が生じたとみなされる。したがって、リスクコスト項を含む目的関数を最適化する場合、目的関数オプティマイザ９４０は、ビルディングデバイスが故障する確率を減少させる決定変数の値を決定することができる。

いくつかの実施形態では、目的関数オプティマイザ９４０は、ビルディング機器のいくつかのビルディングデバイスが高い故障確率（例えば、５０％超、６０％超など）を有して、他のビルディングデバイスのメンテナンス／交換を優先できるようにする。例えば、コストを最適化するために、目的関数オプティマイザ９４０は、高い故障確率を有するファンがより早い時間ステップで換気シャフトのメンテナンス／交換を実施されるようにする決定変数の値を決定することができる。一時的にファンが高い故障確率を有するようにする決定は、換気シャフトが故障した場合と比較して、コストに対する（例えば、追加のメンテナンス及び／又は機会コストによる）影響がより小さいことがある。したがって、全体的なコストをさらに最適化（例えば、削減）するために、換気シャフトのメンテナンス／交換をファンのメンテナンス／交換よりも優先することができる。故障確率の分布により目的関数オプティマイザ９４０によって成される決定は、図１９Ｂ及び１９Ｃを参照して以下でより詳細に示す。

いくつかの実施形態では、目的関数オプティマイザ９４０によって実施される最適化は、リスク回避値によって制約される。リスク回避値は、ユーザ及び／又はシステムによって設定することができ、特定のビルディングデバイスに関する最大許容故障確率を示す。例えば、ユーザは、故障コストが５００ドルを超えるビルディングデバイスに関して、リスク回避値を４５％に設定することができる。リスク回避値により、最適化は、５００ドルを超える推定故障コストを有する任意のビルディングデバイスが最適化期間を通して４５％未満の故障確率を有するように、最適なメンテナンス及び交換スケジュールを決定することができる。実質的に、リスク回避値は、特定のビルディングデバイスの故障確率が特定の値未満に保たれることをビルディング機器のメンテナンス及び／又は交換に関連する決定変数が保証するように、最適化に対して制約を課すことができる。いくつかの実施形態では、目的関数オプティマイザ９４０が、特定のビルディングデバイスの故障確率をリスク回避値未満に維持する解を決定することができない場合、特定のビルディングデバイスの故障確率がリスク回避値を超える可能性があることを示すアラートがユーザに提供される。

いくつかの実施形態では、将来の任意の週における故障確率は、週の初めから週の終わりまで密度関数を積分することによって見出される。故障確率に故障コストを乗算して、コスト関数（例えば、目的関数Ｊ）に加えることができる。いくつかの実施形態では、故障コストは、固定変数ではなく、ランダム変数である。いくつかの実施形態では、故障確率は、デバイス（例えば、モバイルデバイス、コンピュータなど）に表示される。例えば、故障確率の累積分布関数（ＣＤＦ）を、故障確率を示す勾配としてデバイスに示すことができる。勾配は、例えば、緑から黄色、さらに赤に遷移することがあり、緑は、故障確率が低いことを示し、黄色は、故障が近づいている可能性が高いことを示し、赤は、近い将来に故障が発生する可能性が高いことを示す。

図１４Ｂの高レベルオプティマイザ８３２は、雑費予測器９４８も含むものとして示されている。雑費予測器９４８は、目的関数生成器９３５に提供するための雑費項を生成することができる。雑費項は、メンテナンス活動、交換活動及び／又は雑費をもたらす他の活動を含むことができる。いくつかの実施形態では、雑費予測器９４８によって考慮に入れられる修理は、ビルディング機器の信頼性に影響を与えるが、効率の変化をもたらさない。雑多な修理活動（例えば、雑多な出費を生じるメンテナンス／交換活動）がビルディング機器の効率に影響を与えない場合、雑多な修理活動は、最適化期間にわたって動作コストに影響を及ぼさないことがある。例えば、雑多な修理活動は、ＶＲＦシステムの屋外ユニット（ＯＤＵ）の重要な構成要素を安定させるために、ビルディングのオペレータがＯＤＵのねじを交換することを含むことができる。いくつかの実施形態では、ＯＤＵのねじを交換することは、ＯＤＵの信頼性に影響を及ぼす（すなわち重要な構成要素の安定性を高めることによって）が、ＯＤＵの効率に影響を与えない。したがって、ねじの交換は、ＯＤＵの信頼性を向上させることができるが、ＯＤＵの動作により生じる動作コストに直接的にいかなる影響も及ぼさないことがある。

いくつかの実施形態では、雑費項により、ユーザは他の雑多な出費を目的関数Ｊと共に組み込んで、最適化期間にわたる合計コストのより正確な決定を提供することができる。例えば、ユーザは、雑費項により、従業員の給与コストを目的関数Ｊに組み込むことができる。給与コストは、メンテナンス／交換費と同じ予算から出ることがあり、ユーザは、ユーザが入力した他の雑多な出費に従って目的関数オプティマイザ９４０が最適解を決定することを望むことがある。いくつかの実施形態では、ユーザは、必須のものとして、特定の雑多な出費にフラグを立てることができ、目的関数オプティマイザ９４０によって実施される最適化が、フラグを立てられた雑多な出費の発生を回避することができないようにする。ユーザが目的関数Ｊに雑多な出費を追加できるようにすることにより、ユーザは、最適化期間にわたる合計コストをより正確に把握することができる。

いくつかの実施形態では、雑費予測器９４８によって生成された雑費項を含む目的関数Ｊは、以下によって示すことができる。

ここで、Ｃ_{ｍｉｓｃ，ｉ}は、時間ステップｉでの雑多なメンテナンス出費であり、Ｂ_{ｍｉｓｃ，ｉ}は、時間ステップｉで雑多な出費が生じるか否かを示すバイナリ変数である。

目的関数生成器９３５によって生成することができる目的関数の別の例は、以下の式で示される。

ここで、アレイＣ_ｍｉｓｃは、最適化期間の特定の雑多な出費ｌ＝１．．．ｓに関する雑費値Ｃ_{ｍｉｓｃ，ｉ}を含み、アレイＢ_ｍｉｓｃは、最適化期間の特定の時間ステップｉ＝１．．．ｈでの特定の雑多な出費ｌ＝１．．．ｓに関するバイナリ決定変数を含む。

いくつかの実施形態では、ユーザは、ビルディング機器の信頼性を向上させるために目的関数Ｊの最適化中に考慮すべき雑多な出費を定義する。いくつかの実施形態では、リスクコスト項は、雑費項と併せて目的関数オプティマイザ９４０によって考慮される。雑費項は、ビルディング機器の信頼性を高めるために目的関数オプティマイザ９４０に追加のオプションを提供することがあるため、目的関数オプティマイザ９４０は、ビルディング機器の故障確率を低減するためにより多くのオプションを有することがある。例えば、ユーザは、配管の亀裂を防止するために、換気システムの配管にシーラントを塗布する雑多な修理活動を定義することがある。シーラントは、配管の効率を高めないことがあるが、亀裂により配管が破損しにくくなり得るため、信頼性を高めることができる。いくつかの実施形態では、ユーザとシステムとの両方は、雑費項に含めるために雑多な修理活動を雑費予測器９４８に与える。各追加の雑多な修理活動は、ビルディング機器の信頼性を高めるために代替オプションを提供することができる。それぞれの雑多な修理活動の信頼性向上に応じて、特定の雑多な修理活動は、ビルディング機器の信頼性と効率との両方に影響を及ぼすことがあるビルディング機器の通常のメンテナンス及び／又は完全な交換の実施よりも安価になり得る。したがって、雑多な修理活動により、目的関数オプティマイザ９４０は、リスクコスト項の値を低減することによって目的関数Ｊをさらに最適化することができる。

故障リスク予測器９４６によって生成されるリスクコスト項と、雑費予測器９４８によって生成される雑多なコスト項との両方が目的関数Ｊに組み込まれる場合、目的関数生成器９３５によって生成される目的関数Ｊの一例は、次の式によって示される。

上記の目的関数に基づいて、目的関数オプティマイザ９４０は、全体的なコストが最適化（例えば、最小化）されるように決定変数の値を決定することができる。各ビルディングデバイスの故障コストに応じて、目的関数オプティマイザ９４０は、上記ビルディングデバイスの故障確率を低く保つために、高い故障コストを有するビルディングデバイスに対して追加のメンテナンス、交換及び／又は雑多な修理活動を実施すべきであると判断することがある。

いくつかの実施形態では、目的関数Ｊは、雑費項、故障コスト項及び予算制約のいくつか及び／又はすべてを含む。目的関数Ｊが雑費項、故障コスト項及び予算制約のすべてを含む場合、目的関数オプティマイザ９４０は、最適化における任意の予算制約に制約されながら、目的関数Ｊの各項により、全体コストを最適化（例えば、最小化）する最適解を決定することができる。

最適化期間にわたる予算期間の最適化

次に、図１５を参照すると、いくつかの実施形態による、ハード予算制約下での最適化期間にわたる累積メンテナンス支出を例示するグラフ１５００が示されている。いくつかの実施形態では、ハード予算制約下での最適化期間にわたる資本購入は、本明細書で述べるメンテナンス支出と同様及び／又は同一に例示することができる。いくつかの実施形態では、ハード予算制約は、メンテナンス予算期間にわたってメンテナンスに費やすことができる最大額（例えば、ドル）を示す最大メンテナンス予算である。グラフ１５００では、最適化期間１５０６が示され、最適化期間１５０６は、メンテナンス予算期間と同じ期間である。図１５では、最適化期間１５０６とメンテナンス予算期間とは、同じであり得、目的関数Ｊが複数のメンテナンス予算期間を含む必要がなく、それにより目的関数Ｊに課される制約の量を低減する。

グラフ１５００は、いくつかの実施形態によれば、最大メンテナンス予算１５０４も含むものとして示されている。いくつかの実施形態では、最大メンテナンス予算１５０４は、最適化期間１５０６にわたってメンテナンスに費やすことができる最大許容額であり得る。いくつかの実施形態では、最大メンテナンス予算１５０４は、図１３を参照して上でより詳細に述べたユーザインターフェース８３６を介してモデル予測的メンテナンスシステム６０２に通信することができる。いくつかの実施形態では、最大メンテナンス予算１５０４は、変数Ｂｕｄ_ｍａｘとして表すことができ、Ｂｕｄ_ｍａｘは、最適化期間１５０６にわたってメンテナンスに費やすことが許される最大額に等しいことがある。

引き続き図１５を参照すると、グラフ１５００は、目的関数オプティマイザ９４０によって最適化期間１５０６にわたってメンテナンス支出がどのように決定され得るかを示している。いくつかの実施形態によれば、時間ステップ６までメンテナンス支出が生じない。いくつかの実施形態によれば、グラフ１５００の時間ステップ６では、第１のメンテナンス支出１５０８が示されている。いくつかの実施形態では、第１のメンテナンス支出１５０８のコストは、Ｃｏｓｔ_{ｍａｉｎ，１}として表すことができる。一般に、メンテナンス支出は、Ｂ_{ｍａｉｎ，ｉ}＝１として時間ステップｉで生じるものとして示すことができる。いくつかの実施形態では、Ｂ_{ｍａｉｎ，ｉ}は、メンテナンス活動に関して図１４Ａを参照して述べたＢ_{ａｃｔ，ｉ}であり得る。例えば、いくつかの実施形態によれば、第１のメンテナンス支出１５０８は、Ｂ_{ｍａｉｎ，６}＝１として時間ステップ６で生じるものとして示されている。同様に、時間ステップｉでメンテナンスが生じない場合、Ｂ_{ｍａｉｎ，ｉ}＝０になる。いくつかの実施形態では、図１４を参照して述べた高レベルオプティマイザ８３２からの、時間ステップ６でメンテナンスが実施されるべきであるという判断により、第１のメンテナンス支出１５０８が生じることがある。第１のメンテナンス支出１５０８が実施された後、累積メンテナンス支出Ｃｏｓｔ_ｍａｉｎは、Ｃｏｓｔ_ｍａｉｎ＝Ｃｏｓｔ_{ｍａｉｎ，１}として記述することができる。

グラフ１５００は、いくつかの実施形態によれば、時間間隔１５０２も含むものとして示されている。いくつかの実施形態では、Ｃｏｓｔ_ｍａｉｎ＝Ｃｏｓｔ_{ｍａｉｎ，１}は、時間間隔１５０２の継続期間全体にわたる累積メンテナンス支出を定義することができる。時間ステップ１６では、第２のメンテナンス支出１５１０が実施されるものとして示されており、したがって、第２のメンテナンス支出１５１０のコストは、Ｃｏｓｔ_{ｍａｉｎ，２}として表すことができる。第１のメンテナンス支出１５０８と同様に、メンテナンスは、Ｂ_{ｍａｉｎ，１６}＝１として時間ステップ１６で生じるものとして示されている。いくつかの実施形態では、第２のメンテナンス支出１５１０は、累積メンテナンス支出Ｃｏｓｔ_ｍａｉｎをＣｏｓｔ_ｍａｉｎ＝Ｃｏｓｔ_{ｍａｉｎ，１}＋Ｃｏｓｔ_{ｍａｉｎ，２}に増加させることができる。最後に、時間ステップ２１では、第３のメンテナンス支出１５１２が生じるものとして示され、したがって、第３のメンテナンス支出１５１２のコストは、Ｃｏｓｔ_{ｍａｉｎ，３}として表すことができる。第１のメンテナンス支出１５０８と同様に、いくつかの実施形態によれば、Ｂ_{ｍａｉｎ，２１}＝１として時間ステップ２１でメンテナンスが生じるものとして示されている。いくつかの実施形態では、第３のメンテナンス支出１５１２は、累積メンテナンス支出Ｃｏｓｔ_ｍａｉｎをＣｏｓｔ_ｍａｉｎ＝Ｃｏｓｔ_{ｍａｉｎ，１}＋Ｃｏｓｔ_{ｍａｉｎ，２}＋Ｃｏｓｔ_{ｍａｉｎ，３}に増加することができる。いくつかの実施形態では、最適化期間１５０６は、時間ステップｉ＝１から時間ステップｉ＝ｈまで示される。最適化期間１５０６中、目的関数オプティマイザ９４０は、いくつかの実施形態によれば、最適なメンテナンス累積コストがＣｏｓｔ_ｍａｉｎ＝Ｃｏｓｔ_{ｍａｉｎ，１}＋Ｃｏｓｔ_{ｍａｉｎ，２}＋Ｃｏｓｔ_{ｍａｉｎ，３}であること並びに上述したように時間ステップ６、１６及び２１でメンテナンスが生じることを示す最適なメンテナンス及び交換スケジュールを決定することができる。いくつかの実施形態では、最適なメンテナンス及び交換スケジュールの決定は、最適化期間１５０６に関する目的関数Ｊが最適化されることを示すことがある。

グラフ１５００は、メンテナンス支出の差１５１４も含むものとして示されている。いくつかの実施形態では、メンテナンス支出の差は、最大メンテナンス予算１５０４と、最適化期間１５０６にわたるすべてのメンテナンス支出の合計コストによって決定される累積メンテナンス支出Ｃｏｓｔ_ｍａｉｎの最終値との間の差として定義される。いくつかの実施形態では、メンテナンス支出の差１５１４は、変数Ｊ_ｇａｐとして表すことができる。一般に、メンテナンス支出の差１５１４は、図１４Ａを参照して上述した目的関数オプティマイザ９４０によって計算されたメンテナンス支出の差と同様及び／又は同一に計算することができる。いくつかの実施形態では、Ｊ_ｇａｐ＜０である（すなわち累積メンテナンス支出の最終値が最大メンテナンス予算１５０４よりも大きい）場合、目的関数オプティマイザは、ハード予算制約が超過されたため、目的関数Ｊの新たな解を決定しなければならない。

ここで、図１６を参照すると、例示的な実施形態による、ソフト予算制約下での最適化期間にわたる累積メンテナンス支出を例示するグラフ１６００が示されている。いくつかの実施形態では、ソフト予算制約下での最適化期間にわたる資本購入は、本明細書で述べたメンテナンス支出と同様及び／又は同一に例示することができる。いくつかの実施形態では、ソフト予算制約は、ペナルティコストであり得、ペナルティコストは、図１４Ａを参照して計算されたペナルティコストと同様及び／又は同一に最大メンテナンス予算１６０４と推定メンテナンス支出との間の差に基づいて決定される。いくつかの実施形態では、グラフ１６００のいくつか及び／又はすべては、図１５を参照して述べたグラフ１５００と同様及び／又は同一であり得る。

グラフ１６００は、いくつかの実施形態によれば、最大メンテナンス予算１６０４を含むものとして示されている。いくつかの実施形態では、最大メンテナンス予算１６０４は、図１５を参照して述べた最大メンテナンス予算１５０４と同様及び／又は同一であり得る。グラフ１６００は、いくつかの実施形態によれば、最適化期間１６０６も含むものとして示されている。いくつかの実施形態では、最適化期間１６０６は、図１５を参照して述べた最適化期間１５０６と同様及び／又は同一である。グラフ１６００は、いくつかの実施形態によれば、第１のメンテナンス支出１６０８、第２のメンテナンス支出１６１０及び第３のメンテナンス支出１６１２も含むものとして示される。いくつかの実施形態では、第１のメンテナンス支出１６０８、第２のメンテナンス支出１６１０及び第３のメンテナンス支出１６１２は、それぞれ図１５を参照して上述した第１のメンテナンス支出１５０８、第２のメンテナンス支出１５１０及び第３のメンテナンス支出１５１２と同様及び／又は同一である。グラフ１６００は、いくつかの実施形態によれば、時間間隔１６０２も含むものとして示され、時間間隔１６０２は、図１５を参照して述べた時間間隔１５０２と同様及び／又は同一であり得る。

いくつかの実施形態では、グラフ１６００は、ハード予算制約ではなくソフト予算制約が使用されるため、図１５を参照して述べたグラフ１５００と異なる。いくつかの実施形態では、グラフ１６００は、時間ステップ２５で生じる第４のメンテナンス支出１６１４を含むものとして示されている。いくつかの実施形態では、第４のメンテナンス支出１６１４は、メンテナンス支出の差１６１６を最小化するための追加のメンテナンス支出であり得る。いくつかの実施形態では、メンテナンス支出の差１６１６は、図１５を参照して述べたメンテナンス支出の差１５１４と同様及び／又は同一に計算することができる（すなわち最大メンテナンス予算１６０４から、最適化期間１６０６にわたる各メンテナンス支出の合計を減算する）。いくつかの実施形態では、第４のメンテナンス支出１６１４は、ソフト予算制約によるメンテナンス支出の差１６１６を最小化するために実施されることがある。いくつかの実施形態では、メンテナンス支出の差１６１６が増加するにつれて、ソフト予算制約によって定義されるペナルティコストが増加する。ペナルティコストマネージャ９４４によって提供されるペナルティコスト項に基づいてペナルティコストを計算することができる。いくつかの実施形態では、目的関数オプティマイザ９４０は、ペナルティコストを最小化するために目的関数Ｊを最適化することができる（すなわちメンテナンス支出の差１６１６を減少させることによって）。いくつかの実施形態では、ペナルティコストは、メンテナンス支出の差１６１６の倍数であり得る。例えば、最適化期間１６０６にわたるすべてのメンテナンス支出が最大メンテナンス予算１６０４を超えた場合、３倍のペナルティがあり得る。例えば、最大メンテナンス予算１６０４が１００ドルだけ超えた場合、３００ドルの追加のペナルティコストが生じることがある。ソフト予算制約に基づいて、目的関数オプティマイザ９４０は、いくつかの実施形態によれば、追加のメンテナンス支出を追加してメンテナンス支出の差１６１６を最小化してペナルティコストを下げることにより、目的関数Ｊを最適化することができる。例えば、時間ステップ２５での第４のメンテナンス支出１６１４は、ソフト予算制約なしでは通常実施されなかった可能性がある。しかし、目的関数Ｊを最適化するために、目的関数オプティマイザ９４０は、第４のメンテナンス支出１６１４により生じた追加のコストが、ペナルティコストを減少させることによって目的関数Ｊを最小化することを決定することができる。

いくつかの実施形態では、最大メンテナンス予算１６０４のほとんど及び／又はすべてが費やされることを奨励するためにソフト予算制約が実装されることがある。例えば、メンテナンス予算は、最適化期間１６０６にわたってメンテナンスに１５，０００ドルを割り振ることがある。したがって、最適化期間１６０６後に最大メンテナンス予算１６０４から費やされていない額は、メンテナンスの観点から実質的に失われる。したがって、いくつかの実施形態によれば、ユーザが最大メンテナンス予算１６０４を使い果たすことを望む場合、ペナルティコスト項は、費やされる最大メンテナンス予算１６０４の最大額に対応する目的関数Ｊの最適解の決定を容易にすることができる。図１９Ａを参照して述べるグラフ１９００は、目的関数Ｊにソフト予算制約をどのように課すことができるかをさらに示している。

ここで、図１７を参照すると、いくつかの実施形態による、複数のメンテナンス予算期間にまたがる最適化期間に関する累積メンテナンスコストを例示するグラフ１７００が示されている。いくつかの実施形態では、複数の資本購入期間にまたがる最適化期間に関する累積資本購入コストは、グラフ１７００での累積メンテナンスコストと同様及び／又は同一に例示することができる。いくつかの実施形態では、最適化期間１７０２は、ビルディング管理システム（ＢＭＳ）に関する個々のメンテナンス予算期間よりも長いことがある。複数のメンテナンス予算期間が最適化期間１７０２内に入るとき、目的関数生成器９３５によって生成される目的関数Ｊは、いくつかの実施形態によれば、各メンテナンス予算期間に関する累積メンテナンス支出がそのメンテナンス予算期間に関する最大メンテナンス予算を超えないように目的関数Ｊを最適化（例えば、最小化）するように、目的関数オプティマイザ９４０によって最適化される必要があり得る。

グラフ１７００は、いくつかの実施形態によれば、時間ステップ１から時間ステップ１５までの第１のメンテナンス予算期間１７０４と、時間ステップ１８から時間ステップ３２までの第２のメンテナンス予算期間１７０６とを含むものとして示されている。いくつかの実施形態では、第１のメンテナンス予算期間１７０４は、第１の最大メンテナンス予算１７０８を有する。いくつかの実施形態では、第２のメンテナンス予算期間１７０６は、第２の最大メンテナンス予算１７１０を有する。いくつかの実施形態では、第１の最大メンテナンス予算１７０８は、第２の最大メンテナンス予算１７１０よりも大きいか又は小さい。いくつかの実施形態では、第１の最大メンテナンス予算１７０８は、第２の最大メンテナンス予算１７１０に等しい。

第１のメンテナンス予算期間１７０４は、いくつかの実施形態によれば、第１のシリーズ１７１６を含む。いくつかの実施形態では、第１のシリーズ１７１６は、第１のメンテナンス予算期間１７０４にわたる一連のメンテナンス支出を表す。第１のシリーズ１７１６は、いくつかの実施形態によれば、時間ステップ４で生じる第１のメンテナンス支出及び時間ステップ１０で生じる第２のメンテナンス支出を示す。同様に、第２のメンテナンス予算期間１７０６は、いくつかの実施形態によれば、第２のシリーズ１７１８を含む。いくつかの実施形態では、第２のシリーズ１７１８は、第２のメンテナンス予算期間１７０６にわたる一連のメンテナンス支出を表す。第２のシリーズ１７１８は、いくつかの実施形態による、時間ステップ１９、２３及び２８で生じる３つのメンテナンス支出を示す。いくつかの実施形態では、合計メンテナンス支出は、図１４Ａを参照して上述したＣｏｓｔ_{ａｃｔ，ｊ}を計算するための式により、目的関数オプティマイザ９４０によって第１のメンテナンス予算期間１７０４及び／又は第２のメンテナンス予算期間１７０６のいずれかに関して計算することができる。

いくつかの実施形態では、Ｃｏｓｔ_{ｍａｉｎ，１}は、第１のメンテナンス予算期間１７０４に関する第１の合計メンテナンス支出１７１２を示す。いくつかの実施形態では、第１の合計メンテナンス支出１７１２は、第１のメンテナンス支出の差１７１４が非ゼロであることを示す第１の最大メンテナンス予算１７０８と異なることがある。いくつかの実施形態では、第１のメンテナンス支出の差１７１４は、図１４Ａを参照して述べたメンテナンス支出の差と同様及び／又は同一に計算することができる。いくつかの実施形態では、図１６を参照して述べたソフト予算制約と同様及び／又は同一のソフト予算制約が適用される場合、第１のメンテナンス支出の差１７１４がどの程度大きいかに基づいて、ペナルティコストが生じることがある。

いくつかの実施形態では、Ｃｏｓｔ_{ｍａｉｎ，２}は、第２の合計メンテナンス支出１７２０を示す。いくつかの実施形態では、第２の合計メンテナンス支出１７２０は、第２の最大メンテナンス予算１７１０に等しいことがある。いくつかの実施形態では、ソフト予算制約が適用され、第２の合計メンテナンス支出１７２０が第２の最大メンテナンス予算１７１０に等しい場合、ペナルティコストが生じないことがある。いくつかの実施形態では、ソフト予算制約が適用され、第２の合計メンテナンス支出１７２０が第２の最大メンテナンス予算１７１０に等しくない場合、ペナルティコストが生じることがある。

引き続き図１７を参照すると、目的関数Ｊは、第１のメンテナンス予算期間１７０４と第２のメンテナンス予算期間１７０６との両方の予算制約を遵守しながら最適化期間１７０２の全継続期間にわたって最適化するように、目的関数オプティマイザ９４０によって最適化される必要があり得る。例えば、その後、グラフ１７００に関する最大予算ベクトルＢｕｄ_ｍａｘは、以下の形式での２×１ベクトルになり得る。

ここで、Ｂｕｄ_ｍａｘ１は、第１の最大メンテナンス予算１７０８を定義することができ、Ｂｕｄ_ｍａｘ２は、第２の最大メンテナンス予算１７１０を定義することができる。いくつかの実施形態では、目的関数オプティマイザ９４０は、目的関数Ｊの最適値を決定するときに最大予算ベクトルＢｕｄ_ｍａｘを利用することができる。いくつかの実施形態では、目的関数Ｊの最適値を決定するとき、目的関数オプティマイザ９４０は、図１４Ａを参照して上で定義された最大予算制約を遵守する。いくつかの実施形態では、最大予算制約を遵守することにより、目的関数Ｊは、最適化期間１７０２内の任意のメンテナンス予算期間に関する最大メンテナンス予算を超えることなく最適化することができる。

いくつかの実施形態では、任意のメンテナンス予算期間中に生じない最適化期間１７０２中の時間ステップ（例えば、グラフ１７００の時間ステップ１４〜１７及び３１〜ｈ）があり得る。いくつかの実施形態では、目的関数Ｊは、任意のメンテナンス予算期間中に生じない各時間ステップに関するハード予算制約を有することがあり、ハード予算制約は、上記時間ステップ中にはメンテナンスについてコストが生じないことがあることを示すことができる。ハード予算制約に基づいて、メンテナンス予算期間中に生じない各時間ステップに関して、目的関数オプティマイザ９４０は、Ｍａｓｋ_ｊ，ｉ＝０を設定して、メンテナンス予算期間ｊ中に時間ステップｉが発生しないことを示すことができる。いくつかの実施形態では、Ｍａｓｋの列のすべての値は、０であり得、列に関連付けられた時間ステップが任意のメンテナンス予算期間中に生じないことを示す。例えば、Ｍａｓｋの値は、以下の値を有することがある。

ここで、第３の列は、すべて０である。いくつかの実施形態では、第３の列がすべて０であることは、時間ステップ３中にメンテナンス予算期間１又はメンテナンス予算期間２のいずれも生じないことを示すことができる。

ここで、図１８を参照すると、いくつかの実施形態による、部分的に最適化期間１８０２外で生じるメンテナンス予算期間を伴う最適化期間１８０２にわたる累積メンテナンスコストを例示するグラフ１８００が示されている。いくつかの実施形態では、部分的に最適化期間外で生じる資本購入期間を伴う最適化期間にわたる累積資本購入コストは、グラフ１８００が累積メンテナンスコストに関するものであるときと同様及び／又は同一に示すことができる。グラフ１８００では、いくつかの実施形態によれば、第１のメンテナンス予算期間１８０４は、最適化期間１８０２が始まる前に始まるものとして示されている。さらに、第２のメンテナンス予算期間１８０６は、いくつかの実施形態によれば、最適化期間１８０２中に生じるものとして示され、第３のメンテナンス予算期間１８１６は、最適化期間１８０２中に始まり、最適化期間１８０２の終了後に継続するものとして示されている。

第１のメンテナンス予算期間１８０４は、いくつかの実施形態によれば、第１の一連のメンテナンス支出１８１０を含むものとして示されている。グラフ１８００に示されているように、いくつかの実施形態によれば、最適化期間１８０２の開始（すなわち時間ステップ１）前に第１のメンテナンス支出が成された。いくつかの実施形態では、図１４Ａを参照して述べた予算マネージャ９４２は、第１のメンテナンス予算期間１８０４に関するハード予算制約を受信することがある。第１のメンテナンス予算期間１８０４に関するハード予算制約は、第１のメンテナンス予算期間１８０４が生じる期間を表す第１の時間スパンと、第１のメンテナンス予算期間１８０４中にメンテナンスに費やすことができる最大額を表す第１の最大メンテナンス予算１８０８と、最適化期間１８０２の開始前（すなわち時間ステップ１前）に第１のメンテナンス予算期間１８０４中にメンテナンスにどの程度の額が費やされているかを表す初期支出とを含むことができる。初期支出及び他のハード予算制約に基づいて、図１４Ａを参照して述べる目的関数オプティマイザ９４０は、いくつかの実施形態によれば、第１の最大メンテナンス予算１８０８を超えない目的関数Ｊに関する最適解を決定するように、目的関数生成器９３５によって生成される目的関数Ｊを最適化（すなわち最小化）することができる。いくつかの実施形態では、目的関数Ｊの最適化を簡略化するために、初期支出によって第１の最大メンテナンス予算１８０８を低減することができる。いくつかの実施形態では、最大メンテナンス予算１８０８は、ペナルティコストに関連付けられたソフト予算制約であり得、その場合、目的関数オプティマイザ９４０は、最適化期間１８０２全体にわたる累積コストを下げるために、最大メンテナンス予算１８０８を超えてペナルティコストを生じる可能性がある。

グラフ１８００は、いくつかの実施形態によれば、第２の一連のメンテナンス支出１８１４及び第２の最大メンテナンス予算１８１２も含むように示される第２のメンテナンス予算期間１８０６を含むものとして示されている。いくつかの実施形態では、第２のメンテナンス予算期間１８０６は、図１７を参照して述べた第２のメンテナンス予算期間１７０６と同様及び／又は同一に目的関数オプティマイザ９４０によって最適化されることがある。

グラフ１８００は、いくつかの実施形態によれば、第３のメンテナンス予算期間１８１６も含むものとして示され、第３のメンテナンス予算期間１８１６は、第３の最大メンテナンス予算１８２０及び第３の組のメンテナンス支出１８１８を含むものとして示されている。第３のメンテナンス予算期間１８１６は、いくつかの実施形態によれば、最適化期間１８０２中に始まるが、最適化期間１８０２の終了後に継続するものとして示されている。いくつかの実施形態では、目的関数Ｊの最適化は、最適化期間１８０２中に生じる第３のメンテナンス予算期間１８１６の時間ステップのみが考慮されるように、第３のメンテナンス予算期間１８１６を、短縮されたメンテナンス予算期間として扱うように構成することができる。短縮されたメンテナンス予算期間中、最適化期間１８０２の終了前に第３の最大メンテナンス予算１８２０の一部及び／又はすべてを使用するように決定変数を最適化することができる。いくつかの他の実施形態では、目的関数Ｊの最適化は、最適化期間１８０２の終了後に生じる第３のメンテナンス予算期間１８１６中の時間ステップを考慮して、次の最適化期間を過度に複雑にしないように構成することができる。いくつかの実施形態では、目的関数Ｊは、最適化期間１８０２中に第３の最大メンテナンス予算１８２０の一部を使用するように制約されることがある。例えば、第３の最大メンテナンス予算１８２０は、第３のメンテナンス予算期間１８１６中に１０，０００ドルであり得るが、第３のメンテナンス予算期間１８１６中に生じる時間ステップの４分の１のみが最適化期間１８０２中に生じることがある。このとき、目的関数Ｊは、第３のメンテナンス予算期間１８１６と最適化期間１８０２とが重なるように、時間ステップ中に使用することができる第３の最大メンテナンス予算１８２０の所定のパーセンテージのみに制約されることもある。これにより、第３の最大メンテナンス予算１８２０の残額を次の最適化期間中に使用することが可能になり得る。いくつかの実施形態では、メンテナンス予算期間が最適化期間１８０２の一部分中に生じるとき、メンテナンス予算期間に関する最大メンテナンス予算の利用可能な額は、最適化期間１８０２中に生じるメンテナンス予算期間の量に直接比例する（例えば、メンテナンス予算期間の５０％が最適化期間１８０２中に生じる場合、メンテナンス予算期間に関する最大メンテナンス予算の５０％が利用可能である）。

次に、図１９Ａを参照すると、いくつかの実施形態による、メンテナンス予算と推定メンテナンス支出との間の差に基づく関数としてペナルティコストを例示するグラフ１９００が示されている。いくつかの実施形態では、資本購入に関するペナルティコストは、グラフ１９００がメンテナンスコストに関するものである場合と同様及び／又は同一に例示することができる。グラフ１９００は、いくつかの実施形態によれば、メンテナンス予算が推定メンテナンス支出よりも大きくなるように正の部分１９０４を含むものとして示されている。グラフ１９００は、いくつかの実施形態によれば、メンテナンス予算が推定メンテナンス支出よりも小さくなるように負の部分１９０２も含むものとして示されている。さらに、グラフ１９００は、いくつかの実施形態によれば、メンテナンス予算が推定メンテナンス支出に等しくなるように平衡点１９１４も含むものとして示されている。グラフ１９００は、いくつかの実施形態によれば、勾配１９１０及び勾配１９１２も含むものとして示される。いくつかの実施形態では、勾配１９１０は、図１４を参照して述べたように、ｐ_ｋ，ｊを計算する区分的関数におけるＢｕｄ_{ｍａｘ，ｊ}−Ｃｏｓｔ_{ｅｓｔ，ｊ}＜０（すなわちＡ）に関する勾配を表すことがある。いくつかの実施形態では、勾配１９１２は、図１４Ａを参照して述べたように、ｐ_ｋ，ｊを計算する区分的関数におけるＢｕｄ_{ｍａｘ，ｊ}−Ｃｏｓｔ_{ｅｓｔ，ｊ}＞０（すなわちＢ）に関する勾配を表すことがある。いくつかの実施形態では、グラフ１９００に示されるＢｕｄ_{ｍａｘ，ｊ}及びＣｏｓｔ_{ｅｓｔ，ｊ}は、図１４を参照して述べたＢｕｄ_{ｍａｘ，ｊ}及びＣｏｓｔ_{ｅｓｔ，ｊ}と同様及び／又は同一であり得る。いくつかの実施形態では、目的関数オプティマイザ９４０は、平衡点１９１４として示されるＢｕｄ_{ｍａｘ，ｊ}がＣｏｓｔ_{ｅｓｔ，ｊ}と等しくなる決定変数の値を決定することが可能であり得、その場合、ペナルティコストは生じ得ない。いくつかの実施形態では、ペナルティコストが減少されるにつれて、図１４Ａを参照して述べた修正された目的関数Ｊ_ｍｏｄも減少される。

いくつかの実施形態では、グラフ１９００は、メンテナンス予算期間における単一のタイプのメンテナンスに関するものであり得る。いくつかの実施形態では、メンテナンス予算期間に関する全体的なメンテナンス予算は、特定のメンテナンスプロジェクトに関するより小さいメンテナンス予算に分解することができる。例えば、メンテナンス予算期間にわたる全体的なメンテナンス予算が２０，０００ドルであることがあり、暖房、換気及び空気調和（ＨＶＡＣ）メンテナンスに５，０００ドルを割り振ることができ、窓のメンテナンスに５，０００ドルを割り振ることができ、他のメンテナンスに１０，０００ドルを割り振ることができる。上記の例では、メンテナンス予算期間中の特定のメンテナンスプロジェクトに関するメンテナンス予算を上回るか又は下回る特定のメンテナンスプロジェクトの推定メンテナンス支出に関して、各タイプのメンテナンスは、異なるペナルティコストを生じることがある（すなわち各タイプのメンテナンスに関してＡとＢの値が異なることがある）。次いで、目的関数オプティマイザ９４０は、各タイプのメンテナンスに関して生じるすべてのペナルティコストの全体的な値によって制約される目的関数Ｊを最適化する決定変数の値を決定することができる。いくつかの実施形態では、メンテナンス予算期間にわたる全体的なメンテナンス予算は、全体的なメンテナンス予算を超えないようにハード予算制約を有することがあるが、全体的なメンテナンス予算を超えない限り、メンテナンスの各タイプに関するメンテナンスを超えることができる。この場合、目的関数オプティマイザ９４０は、それらの決定に基づいて目的関数Ｊがさらに最適化され得る場合、特定のメンテナンスプロジェクトに関するメンテナンス予算を超える決定変数を決定することができる。

勾配１９１０が勾配１９１２と異なる場合、グラフ１９００は、最大予算を超える支出に関連するペナルティコストが最大予算未満の支出と異なるペナルティを課されるように、非対称の予算制約を表すことがある。しかし、勾配１９１０が勾配１９１２と同じである場合、グラフ１９００は、最大予算を超える支出が最大予算未満の支出と同じペナルティを課されるような対称的な予算制約を表すことができる。

ここで、図１９Ｂを参照すると、いくつかの実施形態による、ビルディング機器の劣化に基づくビルディング機器の故障確率分布を例示するグラフ１９２０が示されている。グラフ１９２０は、分布１９２２を含むものとして示されている。分布１９２２は、ビルディング機器のビルディングデバイスの故障確率を示すことができる。分布１９２２に基づいて、最適化期間中の様々な時点に関して、ビルディングデバイスの故障確率を決定することができる。例えば、分布１９２２は、ビルディングデバイスの故障確率が、時点Ｔ_２と比較して時点Ｔ_１においてより小さい値であることを示すことができる。同様に、時点Ｔ_ｎでは、ビルディングデバイスの故障確率は、時点Ｔ_１及びＴ_２におけるよりも大きいものとして示されている。分布１９２２は、標準分布に従うように示されているが、ビルディングデバイスの劣化が故障確率にどのように影響を及ぼすかに応じて、任意の確率分布であり得ることを理解されたい。

グラフ１９２０は、閾値１９２４として示される閾値Ｘ及び複数の臨界点１９２６〜１９３６も含むものとして示されている。グラフ１９２０は、経時的なビルディングデバイスの特定の特性の劣化指標値を示す複数のシリーズ１９３８〜１９４８も含むものとして示されている。各臨界点１９２６〜１９３６において、シリーズ１９３８〜１９４８の１つが、臨界点１９２６〜１９３６の関連する点に等しいものとして示されている。例えば、シリーズ１９３８は、時点Ｔ_１で臨界点１９２６に等しいものとして示されている。グラフ１９２０に示されているように、閾値１９２４を超えるシリーズは、ビルディングデバイスの何らかの側面／構成要素などが何らかの臨界値を超えていることを示すことができる。例えば、ビルディングデバイスがファンであり、シリーズ１９４０が上記ファンの回転数を示す場合、閾値１９２４は、ファンが問題なく動作すると推定される回転数（例えば、ファンを製造した企業によって指定される）であり得る。いくつかの実施形態では、シリーズ１９３８〜１９４８は、それぞれ一意の閾値１９２４を有する。例えば、ビルディングデバイスがファンである場合、シリーズ１９３８がファンの回転数を示すとき、シリーズ１９３８に関する閾値１９２４は、回転数であり得る一方、シリーズ１９４２に関する閾値１９２４は、設置してからファンが動作されている時間量であり得る。

シリーズ１９３８〜１９４８のそれぞれが閾値１９２４に近づき且つ／又は閾値１９２４を超えると、分布１９２２によって示されるように、デバイスの故障確率が上昇することがある。臨界値１９２６〜１９３６でシリーズ１９３８〜１９４８のより多くが閾値１９２４を超えるにつれて、分布１９２２によって示される故障確率が上昇するものとして示されている。例えば、分布１９２２によって示される故障確率は、シリーズ１９３８及びシリーズ１９４０が時点Ｔ_１及びＴ_２で閾値１９２４を超えた後でさえ低い（例えば、３０％未満）ものとして示されている。しかし、シリーズ１９４８が時点Ｔ_ｎで閾値１９２４を超えるときまで、ビルディングデバイスの故障確率は、大きい（例えば、９０％超）ものとして示されている。リスクコスト項が目的関数Ｊに含まれている場合、目的関数オプティマイザ９４０は、分布１９２２を利用して、ビルディング機器の故障確率が期間にわたってどのように変化するかを推定し、目的関数Ｊの最適化の結果に対するリスクコスト項の影響を決定することができる。目的関数オプティマイザ９４０は、分布１９２２を推定故障コストと組み合わせて利用して、最適化期間にわたる様々な時間ステップでのリスクコスト項の値を決定することができる。

ここで、図１９Ｃを参照すると、いくつかの実施形態による、ビルディング機器の劣化を低減するために実施されたメンテナンスに基づいて合計コストがどのように影響を及ぼされるかを例示するグラフ１９５０である。グラフ１９５０は、メンテナンス活動を含むが、任意のタイプの修理活動（例えば、交換、メンテナンスなど）が同様の効果を有し得ることを理解すべきである。グラフ１９５０は、シリーズ１９５２とシリーズ１９５４とを含むものとして示されている。シリーズ１９５２及びシリーズ１９５４は、ある期間にわたる様々なビルディングデバイスの劣化指標値を例示することができる。例えば、シリーズ１９５２は、その期間にわたるヒータの劣化指標値を例示することができ、シリーズ１９５４は、期間にわたるＩＤＵの劣化指標値を例示することができる。いくつかの実施形態では、シリーズ１９５２及びシリーズ１９５４は、単一のビルディングデバイスの異なる構成要素の劣化指標値を示す。例えば、シリーズ１９５２は、ＯＤＵの凝縮器コイルの劣化指標値を示すことができ、シリーズ１９５４は、ＯＤＵのファンの劣化指標値を示すことができる。

シリーズ１９５２及びシリーズ１９５４の値が増加するにつれて、関連の構成要素の効率の低下により、動作コストが増加することがある。例えば、シリーズ１９５２がＡＨＵの劣化指標値を例示する場合、ＡＨＵの加熱／冷却コイル、ＡＨＵのファンなどの効率低下により、ＡＨＵの動作に関連する動作コストが増加することがある。

メンテナンス／交換が実施されない場合、シリーズ１９５２及びシリーズ１９５４は、故障閾値を超えるまで増加し続けることがあり、シリーズ１９５２及びシリーズ１９５４に関連する構成要素が故障しているとみなされる。構成要素の故障は、例えば、構成要素をアクティブにする／オンにすることができない、構成要素が最適なエネルギー消費量よりも多い特定量のエネルギーを消費する、構成要素の信頼性が何らかの閾値を下回っているなど、様々な状態によって測定することができる。シリーズ１９５２及びシリーズ１９５４の値を減少させるために、ビルディング機器に対するメンテナンスを実施して、ビルディング機器の効率を向上させることができる。グラフ１９５０に示されているように、メンテナンスは、メンテナンス時点１９５６〜１９６２で行われるものとして示されている。特に、シリーズ１９５２に関連する構成要素は、メンテナンス時点１９５６、メンテナンス時点１９６０及びメンテナンス時点１９６２にメンテナンスを受けるものとして示されており、シリーズ１９５４に関連する構成要素は、メンテナンス時点１９５８にメンテナンスを受けるものとして示されている。上述したように、メンテナンス時点１９５６〜１９６２に実施される活動は、簡略化のためにメンテナンス活動として示されているが、任意のメンテナンス活動、交換活動及び／又はビルディング機器の効率及び／又は信頼性を高めることができる任意の他の活動を含むことができる。

メンテナンス時点１９５６〜１９６２のそれぞれでメンテナンスコストが生じるものとして示されている。上述のように、シリーズ１９５２及びシリーズ１９５４の値が増加するにつれて、シリーズ１９５２及びシリーズ１９５４に関連する構成要素を動作させる動作コストも増加する。動作コストを低減するために、メンテナンスを実施して構成要素の効率を高め、それにより動作コストを低減することができる。しかし、メンテナンスを実施すると、メンテナンスコストが生じることがある。したがって、目的関数オプティマイザ９４０は、メンテナンスコストが動作コストの低減よりも大きくならないように、メンテナンスを実施するときを決定する必要があり得る。いくつかの実施形態では、リスクコスト項が目的関数Ｊに組み込まれる場合、メンテナンスを実施してリスクコスト項の影響を低減すると、メンテナンスのコストが動作コストの低減よりも大きい場合でも目的関数Ｊをさらに最適化することができる。

図１９Ｃは、信頼性勾配１９６４及び信頼性勾配１９６６も含むものとして示されている。信頼性勾配１９６４は、修理（例えば、メンテナンス、交換など）が実施されない場合、ビルディング機器の信頼性が時間と共にどのように変化するかを示すことができる。特に、時間の経過と共に、信頼性勾配１９６４は、暗くなるように示されており、これは、ビルディング機器の信頼性が劣化していることを示す。ビルディング機器に対して実施される各修理活動は、ビルディング機器の信頼性を向上させ、それによってビルディング機器の故障確率を低減することができる。例えば、電気機器の配線の修理は、電気接続が安定していることを保証することによって電気機器の信頼性を高めることができる。いくつかの実施形態では、修理が行われない場合、ビルディング機器の信頼性が向上することがあり得ず、ビルディング機器が故障するまで劣化し続ける。

信頼性勾配１９６６は、最適な修理スケジュールが実施された場合、信頼性が時間と共にどのように変化するかを例示することができる。最適な修理スケジュールは、メンテナンス活動、交換活動及び／又はビルディング機器の信頼性を高めることができる他の活動を含むことができる。最適な修理スケジュールは、ビルディング機器の信頼性が維持されることを保証するために修理を実施するのに最適な時点を示すことができる。信頼性勾配１９６６で示されるように、修理が行われない信頼性勾配１９６４と比較して、ビルディング機器の信頼性は、時間にわたって維持される。

最適な修理スケジュールは、いずれの修理を実施すべきか及びいつその修理を行うべきかを決定するために、コスト関数（例えば、目的関数Ｊ）の最適化によって決定することができる。各修理が何らかの関連コスト（例えば、メンテナンスコスト）を有するため、最適化は、最適な修理時間を決定してコストを最適化（例えば、低減）し、且つビルディング機器の信頼性が維持されることを保証することを必要とされることがある。リスクコスト項がコスト関数に組み込まれる場合、リスクコスト項は、高レベルの信頼性を維持するためにビルディング機器に対していずれの修理がいつ実施されるかに影響を及ぼすことがあり、それによりコスト関数に対するリスクコスト項の影響を軽減する。

モデル予測的メンテナンスプロセス

ここで、図２０を参照すると、いくつかの実施形態による、ハード予算制約を受ける図１３を参照して述べたモデル予測的メンテナンス（ＭＰＭ）システム６０２を動作させるためのプロセス２０００のフローチャートが示されている。いくつかの実施形態では、プロセス２０００は、メンテナンスコストについて示したのと同様及び／又は同一に資本購入にも適用することができる。いくつかの実施形態では、プロセス２０００は、ビルディングシステム６００の構成要素によって実施することができる。いくつかの実施形態では、プロセス２０００は、図６〜９を参照して上でより詳細に述べたように、ＭＰＭシステム６０２によって実施することができる。いくつかの実施形態では、プロセス２０００は、図１０を参照して述べたプロセス１０００と同様及び／又は同一であり得る。

プロセス２０００は、いくつかの実施形態によれば、ＭＰＭシステム６０２を介して、メンテナンス予算と、各メンテナンス予算に関するメンテナンス予算期間とを受信すること（ステップ２００２）を含む。いくつかの実施形態では、メンテナンス予算期間は、メンテナンス予算期間が生じる時間間隔であり得る。メンテナンス予算期間が生じる時間間隔は、いくつかの実施形態によれば、最適なメンテナンス戦略の最適化期間中で完全に生じるか、部分的に生じるか又は全く生じないことがある。いくつかの実施形態では、メンテナンス予算期間に関するメンテナンス予算は、メンテナンス予算期間中にメンテナンスに費やされる額がメンテナンス予算を超えてはならないことを示すハード予算制約であり得る。例えば、メンテナンス予算が１０，０００ドルである場合、メンテナンス予算期間にわたってメンテナンスに費やすことができるのは、１０，０００ドル以下である。いくつかの実施形態では、図１４Ａを参照して述べた予算マネージャ９４２は、ステップ２００２を実施するように構成することができる。

プロセス２０００は、いくつかの実施形態によれば、ビルディングでの可変の状態又は条件に影響を及ぼすようにビルディング機器を動作させること（ステップ２００４）も含むものとして示されている。いくつかの実施形態では、ステップ２００４〜ステップ２０１６は、図１０を参照して述べたステップ１００２〜ステップ１０１４と同様及び／又は同一であり得る。

プロセス２０００は、いくつかの実施形態によれば、受信されたメンテナンス予算及びメンテナンス予算期間に基づいて最大予算制約を定義すること（ステップ２０１８）を含む。いくつかの実施形態では、最大予算制約は、最適化期間にわたってメンテナンスに費やすことができる最大額（例えば、ドル）とすることができる。いくつかの実施形態では、第１のメンテナンス予算期間及び／又は最後のメンテナンス予算期間は、最適化期間の一部分中に生じる。第１のメンテナンス予算期間が最適化期間の一部分中で生じた場合、残りの予算（すなわち前の最適化期間で費やされなかった額）は、いくつかの実施形態によれば、第１のメンテナンス予算期間に関する最大予算制約として使用することができる。最後のメンテナンス予算期間が最適化期間の一部分中に生じた場合、いくつかの実施形態によれば、図１４Ａを参照して上で述べたＢｕｄ_{ｒｅｄｕｃｅｄ}に関する式を予算マネージャ９４２によって使用して、最後のメンテナンス予算期間に関する最大予算制約を生成することができる。いくつかの実施形態では、予算マネージャ９４２は、ステップ２０１８を実施するように構成することができる。

プロセス２０００は、いくつかの実施形態によれば、メンテナンス予算期間に関する最大予算制約及び／又は最大メンテナンス予算を受ける目的関数Ｊが最適化されること（ステップ２０２０）を含む。いくつかの実施形態では、ステップ２０２０は、図１０を参照して述べたステップ１０１６と同様及び／又は同一であり得る。いくつかの実施形態では、目的関数Ｊの最適化中、最大予算制約は、特定のメンテナンス／交換活動によって生じるコストにより、最適化期間に関する合計メンテナンス支出が最大予算制約を超える場合、それらのメンテナンス／交換活動が実施されるのを妨げることがある。いくつかの実施形態では、最大予算制約は、最適化期間が単一のメンテナンス予算期間と同じ期間である場合（すなわちステップ２０１８でｎ＝１）にのみ、ステップ２０２０で使用することができる。いくつかの実施形態では、最適化期間が単一のメンテナンス予算期間と同じ期間ではないとき（例えば、単一のメンテナンス予算期間が最適化期間の一部分中にのみ生じ、最適化期間中に生じる２つ以上のメンテナンス予算期間があるなど）、最大予算制約は、ステップ２０２０で使用されないことがあり、代わりに、目的関数Ｊは、ステップ２００２で受信された各メンテナンス予算期間に関する各メンテナンス予算に従って制約することができる。このようにして、目的関数Ｊは、各メンテナンス予算期間に関するメンテナンス予算を超えないように最適化することができる。最適化問題がどのように解かれるかに応じて、予算制約は、最適化期間にわたって追跡される状態（例えば、残りの予算）、目的関数Ｊへの追加の項などとして実装することができる。いずれにせよ、ステップ２０２０は、最適なメンテナンス戦略が、ステップ２０１８で定義された任意の予算制約に準拠していることを保証することができる。いくつかの実施形態では、目的関数オプティマイザ９４０は、ステップ２０２０を実施するように構成することができる。

プロセス２０００は、例示的な実施形態によれば、ＭＰＭシステム６０２が最適なメンテナンス戦略に基づいてビルディング機器の効率及び信頼性を更新すること（ステップ２０２２）を含む。いくつかの実施形態では、ステップ２０２２は、図１８を参照して述べたステップ１０１８と同様及び／又は同一であり得る。ステップ２０２２の完了後、プロセス２０００は、ステップ２０１０に戻ることができる。

ここで、図２１を参照すると、例示的な実施形態による、ソフト予算制約を受ける図１３を参照して述べたＭＰＭシステム６０２によって実施されるプロセス２１００のフローチャートが示されている。いくつかの実施形態では、プロセス２１００は、メンテナンスコストについて示したのと同様及び／又は同一に資本購入にも適用することができる。いくつかの実施形態では、プロセス２１００は、ビルディングシステム６００の構成要素によって実施することができる。いくつかの実施形態では、プロセス２１００は、図６〜９を参照して述べたように、ＭＰＭシステム６０２によって実施することができる。いくつかの実施形態では、プロセス２１００は、図２０を参照して述べたプロセス２０００と同様及び／又は同一であり得る。さらに、ステップ２１０２〜ステップ２１１６は、いくつかの実施形態によれば、図２０を参照して述べたステップ２００２〜ステップ２０１６と同様及び／又は同一であり得る。

プロセス２１００は、いくつかの実施形態によれば、メンテナンス予算期間中の最大メンテナンス予算と合計メンテナンスコストとの間の差に基づいて、各メンテナンス予算期間に関するペナルティコスト項を定義すること（ステップ２１１８）を含む。いくつかの実施形態では、ペナルティコスト項は、ステップ２１０２で受信された各メンテナンス予算期間に関して、さらに定義することができる。各ペナルティコスト項は、目的関数Ｊの最適化を制約し、メンテナンス予算期間中のメンテナンス予算と合計メンテナンスコストとの間の差が増加するにつれて、メンテナンス予算期間に関連するペナルティコストが増加し得る。いくつかの実施形態では、ペナルティコストマネージャ９４４は、ステップ２１１８を実施するように構成することができる。

プロセス２１００は、いくつかの実施形態によれば、ステップ２１１８で定義された各ペナルティコスト項に従って目的関数Ｊが最適化されること（ステップ２１２０）を含む。いくつかの実施形態では、目的関数Ｊが各ペナルティコストを遵守しながら最適化されるように、最適なメンテナンス戦略を生成することができる。いくつかの実施形態では、メンテナンス予算期間の一部及び／又はすべては、いくらかのペナルティコストを生じる（すなわちメンテナンス予算期間に関してｐ_ｋ，ｊ≠０）ことがあるが、生じるペナルティコストは、それでも目的関数Ｊが最適化されるように十分に小さいことがある。いくつかの実施形態では、目的関数オプティマイザ９４０は、ステップ２１２０を実施するように構成することができる。

プロセス２１００は、例示的な実施形態によれば、ＭＰＭシステム６０２が最適なメンテナンス戦略に基づいてビルディング機器の効率及び信頼性を更新すること（ステップ２１２２）を含む。いくつかの実施形態では、ステップ２１２２は、図２０を参照して述べたステップ２０２２と同様及び／又は同一であり得る。ステップ２１２２の完了後、プロセス２１００は、ステップ２１１０に進むことができる。

ここで、図２２を参照すると、いくつかの実施形態による、ビルディング機器の故障リスクを受ける、図１３を参照して述べたＭＰＭシステム６０２を動作させるためのプロセス２２００が示されている。ビルディング機器の故障リスクをＭＰＭに組み込むことにより、コスト関数（例えば、目的関数Ｊ）は、ビルディング機器の故障により生じ得るコストを最適化（例えば、低減）することができる。故障リスクを組み込むことで、ビルディング機器のメンテナンス／交換に関する決定により、コストを最適化しながら、ビルディング機器の予期しない故障の可能性を低減することを保証することができる。ビルディング機器の予期しない故障は、ビルディング機器のメンテナンス／交換を実施してビルディング機器を動作状態に戻すなどの追加コスト及びまた例えば未対処の負荷又は失われた生産量などの機会コストをもたらすことがある。いくつかの実施形態では、プロセス２２００の一部及び／又はすべてのステップは、ＭＰＭシステム６０２によって実施される。

プロセス２２００は、いくつかの実施形態によれば、ビルディングでの可変の状態又は条件に影響を及ぼすようにビルディング機器を動作させること（ステップ２２０２）を含むものとして示されている。いくつかの実施形態では、ステップ２２０２〜２２１４は、図１０を参照して述べたプロセス１０００のステップ１００２〜１０１４と同様及び／又は同一である。いくつかの実施形態では、ステップ２２０２〜２２１４は、ＭＰＭシステム６０２によって実施される。

プロセス２２００は、いくつかの実施形態によれば、推定信頼性の関数として、最適化期間にわたるビルディング機器の故障リスクに関連するコストＣｏｓｔ_ｒｉｓｋを定義すること（ステップ２２１６）を含むものとして示されている。Ｃｏｓｔ_ｒｉｓｋは、最適化期間の各時間ステップｉに関するすべてのリスクコストＣ_{ｒｉｓｋ，ｉ}の合計によって定義することができる。いくつかの実施形態では、ステップ２２１６は、最適化期間にわたるビルディング機器の推定信頼性を使用して、最適化期間の各時間ステップにおけるビルディング機器のデバイスの故障確率を決定することを含む。デバイスの故障確率に基づいて、最適化にわたる合計コストに対する故障の影響を推定することができる。合計コストに対する故障の影響を推定するために、機器故障に関連するコストを決定することができる。特に、ビルディングデバイスのメンテナンス／交換を実施するためのコスト及び／又はビルディングデバイスの故障に関連する機会コストを決定することができる。機会コストは、ビルディングデバイスの故障により生じるメンテナンス／交換コスト以外の任意のコストを含むことができる。例えば、ＨＶＡＣシステムのヒータが故障した場合、ヒータが位置されているスペースを（例えば、居住者の安全のために）一時的に閉鎖する必要があり得る。スペースの閉鎖により、居住者による他のスペースの賃借、貴重な会議のキャンセルなどに関連するコストが発生する可能性があり、それらすべては、最適化期間にわたるビルディングシステムの合計コストに影響を及ぼす可能性がある追加のコスト及び／又は機会の損失につながる。

ステップ２２１６は、時間ステップｉでの様々なリスクコスト（例えば、メンテナンス／交換コストと機会コストとの合計）に関連するコストＣ_{ｒｉｓｋ，ｉ}を決定することを含むことができる。ステップ２２０４及び２２０６でそれぞれ決定／推定されたビルディング機器の機器性能情報及び／又は推定効率及び信頼性に基づいて劣化の状態を推定することができる。推定される劣化状態が増すにつれて、ビルディングデバイスの故障確率も上昇し得る。

すべてのビルディングデバイスの劣化状態を推定するために、ステップ２２１６は、例えば、各ビルディングデバイスの現在の推定信頼性と、各ビルディングデバイスが最初に設置されたときに基づく最適な信頼性とを比較することを含むことができる。Ｃ_{ｒｉｓｋ，ｉ}の値を決定するために、ステップ２２１６は、各時間ステップｉで各ビルディングデバイスに関連する故障コストを推定することも含むことができる。いくつかの実施形態では、ビルディングデバイスの故障コストは、ユーザによって推定される。いくつかの実施形態では、ビルディングデバイスの故障コストは、例えば、ビルディングデバイスの場所、ビルディングデバイスがスペースの状況にどのように影響を及ぼすかなど、様々な情報に基づいてシステム（例えば、ＭＰＭシステム６０２）によって推定される。

時間ステップｉに関する各ビルディングデバイスの故障確率及び故障コストに基づいて、Ｃ_{ｒｉｓｋ，ｉ}は、以下の式によって決定することができる。
Ｃ_{ｒｉｓｋ，ｉ}＝Ｃ_{ｆａｉｌ，ｉ} ^ＴＰ_{ｆａｉｌ，ｉ}（δ_ｉ）
ここで、Ｐ_{ｆａｉｌ，ｉ}（δ_ｉ）は、劣化状態δ_ｉでの、追跡されるビルディング機器の各ビルディングデバイスに関する故障確率のベクトルであり、Ｃ_{ｆａｉｌ，ｉ}は、各ビルディングデバイスの故障のコストを定義する行列である。さらに、Ｃｏｓｔ_ｒｉｓｋ（すなわち最適化期間にわたる合計リスクコスト）の値は、以下の式によって決定することができる。

ここで、ｈは、最適化期間での時間ステップの総数である。いくつかの実施形態では、ステップ２２１６は、故障リスク予測器９４６によって実施される。

プロセス２２００は、いくつかの実施形態によれば、ビルディング機器の信頼性を向上させる雑多な修理に関連するコストｃｏｓｔ_ｍｉｓｃを定義すること（ステップ２２１８）を含むものとして示されている。雑多な修理は、ビルディング機器の信頼性を向上させるために追加の修理オプションを提供する。いくつかの実施形態では、雑多な修理は、ビルディング機器の信頼性を向上させるが、ビルディング機器の効率を改善しない。雑多な修理は、ステップ２２２０で以下に述べる最適化中に特に有用であり、目的関数に対するＣｏｓｔ_ｒｉｓｋの影響を軽減することができる。ビルディング機器の信頼性が低下するにつれてＣｏｓｔ_ｒｉｓｋが増加するため、信頼性を向上させるための雑多な修理は、Ｃｏｓｔ_ｍａｉｎ及びＣｏｓｔ_ｃａｐによって定義されるメンテナンス及び交換活動に対する有利な代替策を提供することができる。いくつかの実施形態では、Ｃｏｓｔ_ｍｉｓｃに関連する雑多な修理がＣｏｓｔ_ｍａｉｎ及び／又はＣｏｓｔ_ｃａｐと共に組み込まれる。いくつかの実施形態では、ステップ２２１８は、雑費予測器９４８によって実施される。

プロセス２２００は、いくつかの実施形態によれば、コストＣｏｓｔ_ｏｐ、Ｃｏｓｔ_ｍａｉｎ、Ｃｏｓｔ_ｃａｐ、Ｃｏｓｔ_ｒｉｓｋ及びＣｏｓｔ_ｍｉｓｃを含む目的関数を最適化して、ビルディング機器のための最適なメンテナンス戦略を決定すること（ステップ２２２０）を含むものとして示されている。いくつかの実施形態では、ステップ２２２０は、図１０を参照して述べたプロセス１０００のステップ１０１６と同様及び／又は同一である。最適なメンテナンス戦略は、ビルディング機器に関するメンテナンス及び／又は交換を含むことができることを理解すべきである。Ｃｏｓｔ_ｒｉｓｋを目的関数に組み込むことにより、故障確率が低く保たれることを保証するために、ビルディング機器の特定のビルディングデバイスのメンテナンス／交換を優先させることができる。目的関数の結果を最適化（例えば、減少）するために、故障に関連する高い機会コストを伴うビルディングデバイスは、高い機会コストを伴うビルディングデバイスの故障確率が低く保たれる（例えば、１％、５％など）ことを保証するために、追加及び／又はより頻繁なメンテナンス／交換を受けるように目的関数によって決定することができる。

Ｃｏｓｔ_ｍｉｓｃが目的関数に含まれており、且つ／又は雑多な修理がＣｏｓｔ_ｍａｉｎ及び／若しくはＣｏｓｔ_ｃａｐに含まれている場合、目的関数の最適化は、目的関数に対するＣｏｓｔ_ｒｉｓｋの影響を低減するために特定の雑多な修理を実施すべきであると判断することがある。それぞれの雑多な修理は、関連のビルディングデバイスの推定信頼性を向上させ、それにより関連のビルディングデバイスに関するＣｏｓｔ_ｒｉｓｋの影響を低減することができる。有利には、雑多な修理は、メンテナンス及び／又は交換活動よりも安価であり得、したがってＣｏｓｔ_ｒｉｓｋを低減するためのより安価な代替策を提供することができる。ステップ２２２０では、最適化は、Ｃｏｓｔ_ｍｉｓｃ、Ｃｏｓｔ_ｍａｉｎ及び／又はＣｏｓｔ_ｃａｐによって定義される各修復活動を考慮に入れて、最適化期間にわたってコストを最小化する最適なメンテナンス及び交換スケジュールを決定することができる。

いくつかの実施形態では、最適化は、リスク回避値によって制約される。リスク回避値は、ユーザ及び／又はシステムによって設定することができ、特定のビルディングデバイスに関する最大許容故障確率を示す。例えば、ユーザは、故障コストが１，０００ドル以上のビルディングデバイスに関して、リスク回避値を２０％に設定することができる。リスク回避値により、最適化は、１，０００ドル以上の推定故障コストを有する任意のビルディングデバイスが最適化期間を通して２０％未満の故障確率を有するように、最適なメンテナンス及び交換スケジュールを決定することができる。実質的に、リスク回避値は、特定のビルディングデバイスの故障確率が特定の値未満に保たれることをビルディング機器のメンテナンス及び／又は交換に関連する決定変数が保証するように、最適化に対して制約を課すことができる。いくつかの実施形態では、ステップ２２２０は、目的関数オプティマイザ９４０によって実施される。

プロセス２２００は、いくつかの実施形態によれば、最適なメンテナンス戦略に基づいてビルディング機器の効率及び信頼性を更新すること（ステップ２２２２）を含むものとして示されている。いくつかの実施形態では、ステップ２２２２は、図１０を参照して述べたプロセス１０００のステップ１０１８と同様及び／又は同一である。いくつかの実施形態では、ステップ２２２２は、ＭＰＭシステム６０２によって実施される。

可変冷媒流量システムのモデル予測的メンテナンス

ここで、図２３Ａ〜２３Ｂを参照すると、いくつかの実施形態によれば、可変冷媒流量（ＶＲＦ）システム２３００が示されている。ＶＲＦシステム２３００は、複数の屋外ＶＲＦユニット２３０２及び複数の屋内ＶＲＦユニット２３０４を含むものとして示されている。屋外ＶＲＦユニット２３０２は、ビルディングの外に位置させることができ、冷媒を加熱又は冷却するように動作することができる。屋外ＶＲＦユニット２３０２は、電気を消費して、冷媒を液相、気相及び／又は過熱気相間で変換することができる。屋内ＶＲＦユニット２３０４は、ビルディング内の様々なビルディングゾーン全体にわたって分散させることができ、加熱又は冷却された冷媒を屋外ＶＲＦユニット２３０２から受け取ることができる。各屋内ＶＲＦユニット２３０４は、屋内ＶＲＦユニットが位置されている特定のビルディングゾーンに関する温度制御を提供することができる。

ＶＲＦシステムの主な利点は、いくつかの屋内ＶＲＦユニット２３０４が冷却モードで動作することができ、他の屋内ＶＲＦユニット２３０４が加熱モードで動作できることである。例えば、屋外ＶＲＦユニット２３０２及び屋内ＶＲＦユニット２３０４は、加熱モード、冷却モード又はオフモードでそれぞれ動作することができる。各ビルディングゾーンは、個別に制御することができ、異なる温度設定値を有することができる。いくつかの実施形態では、各ビルディングは、ビルディングの外（例えば、屋上）に位置された最大３つの屋外ＶＲＦユニット２３０２と、ビルディング全体にわたって（例えば、様々なビルディングゾーン内に）分散された最大１２８個の屋内ＶＲＦユニット２３０４とを有する。

ＶＲＦシステム２３００には多くの異なる構成が存在する。いくつかの実施形態では、ＶＲＦシステム２３００は、各屋外ＶＲＦユニット２３０２が単一の冷媒戻りライン及び単一の冷媒出口ラインに接続する２パイプシステムである。２パイプシステムでは、加熱又は冷却された冷媒の１つのみを、単一の冷媒出口ラインを通して提供することができるため、すべての屋外ＶＲＦユニット２３０２が同じモードで動作する。他の実施形態では、ＶＲＦシステム２３００は、各屋外ＶＲＦユニット２３０２が冷媒戻りライン、高温冷媒出口ライン及び低温冷媒出口ラインに接続する３パイプシステムである。３パイプシステムでは、２つの冷媒出口ラインを通して加熱及び冷却の両方を同時に提供することができる。

いくつかの実施形態では、ＶＲＦシステム２３００は、図６〜９を参照して述べたモデル予測的メンテナンス（ＭＰＭ）システム６０２と統合され得る。いくつかの実施形態では、ＭＰＭシステム６０２は、ＶＲＦシステム２３００及びシステム内の任意の／すべての構成要素に関する最適なメンテナンス戦略を決定するように構成され得る。いくつかの実施形態では、ＭＰＭシステム６０２は、以下と同様及び／又は同一のＶＲＦシステム２３００及びその任意の／すべての構成要素に関する最適な購入／交換戦略を決定するように構成され得る。

いくつかの実施形態では、ＭＰＭシステム６０２は、各構成要素の現在の劣化状態及び使用推定（例えば、負荷予測及び性能曲線）について、ＶＲＦシステム２３００の構成要素の一部及び／又はすべてを監視するように構成され得る。例えば、ＭＰＭシステム６０２は、各屋内ＶＲＦユニット２３０４及び各屋外ＶＲＦユニット２３０２を監視することができる。各ＶＲＦユニットは、様々な要因（例えば、ＶＲＦユニットが設置されたとき、ＶＲＦユニットが使用される頻度、ＶＲＦユニットが実行される電力の平均レベルなど）により、異なる現在の劣化状態を有し得る。現在の劣化状態及び使用推定に基づいて、ＭＰＭシステム６０２は、動作コスト、メンテナンスコスト及び／又は資本コストを予測することが可能であり得る。いくつかの実施形態では、これらの予測は、図１０を参照して述べたプロセス１０００と同様及び／又は同一のプロセスによって行われる。

いくつかの実施形態では、上記の様々なコストが予測された後、最適化期間に関して目的関数Ｊが生成され得る。目的関数Ｊが生成された後、ＭＰＭシステム６０２は、目的関数Ｊを最適化（すなわち最小化）するように構成することができる。いくつかの実施形態では、この最適化は、ＶＲＦシステム２３００の各構成要素について決定変数の最適値を決定することができる。例えば、１つの決定変数は、ビルディングゾーンが適切に冷却されていないことに応答して、屋内ＶＲＦユニット２３０４が最適化期間中の特定の時間ステップにおいてメンテナンスを実施される必要があり得ることを示すことがある。別の決定変数は、屋外ＶＲＦユニット２３０２が設置されたときよりもさらに５０％多くの電力を消費しているという決定に応答して、最適化期間中の特定の時間ステップにおいて屋外ＶＲＦユニット２３０２を交換する必要があり得る（すなわち資本コストが生じる）ことを示すことがある。

いくつかの実施形態では、ＶＲＦシステム２３００のメンテナンスを管理するＭＰＭシステム６０２は、ＶＲＦシステム２３００に関する最適なメンテナンス戦略を決定するときに予算制約を実施するように構成され得る。予算制約は、様々な実施形態によれば、ハード予算制約、ソフト予算制約又はハード予算制約とソフト予算制約との何らかの組合せを含むことがある。いくつかの実施形態では、ハード予算制約は、最適化期間中のある期間（例えば、予算期間）に関するメンテナンス支出が超過されないようにする最大メンテナンス予算であり得る。いくつかの実施形態では、ハード予算制約は、図１４Ａを参照して述べたハード予算制約と同様及び／又は同一であり得る。いくつかの実施形態では、ソフト予算制約は、メンテナンス予算と最適化期間中のある期間に関してメンテナンスに費やされた実際の額との間の差について、目的関数Ｊの最適化中に追加することができるペナルティコストを含むことがある。いくつかの実施形態では、ソフト予算制約は、図１４Ａを参照して述べたソフト予算制約と同様及び／又は同一であり得る。いくつかの実施形態では、ＶＲＦシステム２３００に関する最適なメンテナンス戦略を決定する一方、ハード予算制約及び／又はソフト予算制約は、目的関数Ｊを最適化しながら制約内に収まるように決定変数の値を変えることができる。

例示的実施形態の構成

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

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

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

Claims

ビルディング機器のためのモデル予測的メンテナンスシステムであって、
ビルディングでの可変の状態又は条件に影響を及ぼすように前記ビルディング機器を動作させるべく構成された機器コントローラと、
最適化期間の継続期間にわたって前記ビルディング機器を動作させるコストを予測するべく構成された動作コスト予測器と、
１つ以上の予算制約を生成するように構成された予算マネージャと、
前記ビルディング機器に関するメンテナンス及び交換スケジュールを決定するために、前記１つ以上の予算制約を受ける目的関数を最適化するべく構成された目的関数オプティマイザと
を含み、
前記目的関数は、
前記ビルディング機器のメンテナンス及び交換コストと、
前記ビルディング機器を動作させる前記予測されたコストと
を含む、モデル予測的メンテナンスシステム。
前記予算マネージャは、ペナルティコスト項を生成するべく構成され、
前記目的関数は、前記ペナルティコスト項を含む、請求項１のモデル予測的メンテナンスシステム。
前記目的関数は、ペナルティコストを含み、
前記１つ以上の予算制約は、前記ペナルティコストが、
（１）メンテナンス及び交換予算を超える支出に関連する第１のペナルティレートと、
（２）前記ビルディング機器を保守及び交換することに費やされた額と前記メンテナンス及び交換予算との差と
の積以上であること、又は
（１）前記メンテナンス及び交換予算未満の支出に関連する第２のペナルティレートと、
（２）前記ビルディング機器を保守及び交換することに費やされた額と前記メンテナンス及び交換予算との差と
の積以上であること
の少なくとも一方であることを必要とする、請求項１のモデル予測的メンテナンスシステム。
前記ビルディング機器からの閉ループフィードバックに基づいてリアルタイムで前記目的関数を動的に更新するべく構成された目的関数生成器をさらに含む、請求項１のモデル予測的メンテナンスシステム。
前記１つ以上の予算制約は、
１つ以上の予算期間と、
前記１つ以上の予算期間に関連する１つ以上のメンテナンス及び交換予算のそれぞれと
に基づいて生成される、請求項１のモデル予測的メンテナンスシステム。
前記１つ以上の予算制約は、前記１つ以上の予算期間のそれぞれにわたる前記メンテナンス及び交換コストが、前記１つ以上の予算期間のそれぞれに関連するメンテナンス及び交換予算を超えることができないことを示す、請求項５のモデル予測的メンテナンスシステム。
前記予算マネージャは、
前記１つ以上の予算期間の１つ以上が部分的に前記最適化期間外で生じるか否かを決定することと、
前記１つ以上の予算期間の１つ以上が部分的に前記最適化期間外で生じるとの判断に応答して、部分的に前記最適化期間外で生じる前記１つ以上の予算期間の前記１つ以上のそれぞれに関して、１つ以上の低減されたメンテナンス及び交換予算を決定することと
を行うべく構成される、請求項５のモデル予測的メンテナンスシステム。
ビルディング機器のためのモデル予測的メンテナンスシステムであって、
１つ以上のプロセッサと、
命令を記憶する１つ又は複数の非一時的コンピュータ可読媒体と
を含み、
前記命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
最適化期間にわたる利用可能な予算を受信することと、
前記最適化期間の継続期間にわたって前記ビルディング機器を動作させるコストを予測することと、
前記ビルディング機器の１つ以上の劣化モデルに基づいて、前記最適化期間にわたる前記ビルディング機器の劣化の量を推定することと、
前記ビルディング機器を動作させる前記予測されたコストと、前記ビルディング機器の前記劣化の量とに基づいて、前記利用可能な予算の一部を前記ビルディング機器のメンテナンス及び交換に割り振ることと、
前記ビルディング機器のメンテナンス及び交換に割り振られた前記利用可能な予算の前記一部に基づく制御決定に従い、前記最適化期間の前記継続期間にわたって前記ビルディング機器を動作させることと
を含む動作を実施させる、モデル予測的メンテナンスシステム。
前記動作はさらに、前記ビルディング機器からのフィードバックとして受信された機器性能情報を使用して、前記最適化期間の各時間ステップでの前記ビルディング機器の信頼性を決定することを含み、
前記ビルディング機器の劣化の量を推定することはさらに、前記ビルディング機器の信頼性に基づく、請求項８のモデル予測的メンテナンスシステム。
前記動作はさらに、前記利用可能な予算の前記割り振られた一部に基づいて目的関数を最適化して、前記ビルディング機器に関するメンテナンス及び交換スケジュールを決定することを含む、請求項８のモデル予測的メンテナンスシステム。
前記動作はさらに、前記最適化期間の各時間ステップでの前記ビルディング機器の動作効率を決定することを含み、
前記ビルディング機器の劣化の量を推定することはさらに、前記ビルディング機器の動作効率に基づく、請求項８のモデル予測的メンテナンスシステム。
前記動作は、オフラインで実施される、請求項８のモデル予測的メンテナンスシステム。
前記動作はさらに、前記利用可能な予算の前記割り振られた一部と等しくない合計支出に関連するペナルティコストを決定することを含む、請求項８のモデル予測的メンテナンスシステム。
前記動作はさらに、前記ペナルティコストが、
（１）前記利用可能な予算を超える支出に関連する第１のペナルティレートと、
（２）前記ビルディング機器を保守及び交換することに費やされた額と前記利用可能な予算との差と
の積以上であること、又は
（１）前記利用可能な予算未満の支出に関連する第２のペナルティレートと、
（２）前記ビルディング機器を保守及び交換することに費やされた額と前記利用可能な予算との差と
の積以上であること
の少なくとも一方であることを必要とする１つ以上の予算制約を生成することを含む、請求項１３のモデル予測的メンテナンスシステム。
ビルディング機器のモデル予測的メンテナンスを実施する方法であって、
ビルディングでの可変の状態又は条件に影響を及ぼすように前記ビルディング機器を動作させるステップと、
最適化期間の継続期間にわたって前記ビルディング機器を動作させるコストを予測するステップと、
１つ以上の予算制約を生成するステップと、
前記ビルディング機器に関するメンテナンス及び交換スケジュールを決定するために、前記１つ以上の予算制約を受ける目的関数を最適化するステップと
を含み、
前記目的関数は、
前記ビルディング機器のメンテナンス及び交換コストと、
前記ビルディング機器を動作させる前記予測されたコストと
を含む、方法。
ペナルティコスト項を生成するステップをさらに含み、
前記目的関数は、前記ペナルティコスト項を含む、請求項１５の方法。
前記目的関数は、ペナルティコストを含み、
前記１つ以上の予算制約は、前記ペナルティコストが、
（１）メンテナンス及び交換予算を超える支出に関連する第１のペナルティレートと、
（２）前記ビルディング機器を保守及び交換することに費やされた額と前記メンテナンス及び交換予算との差と
の積以上であること、又は
（１）前記メンテナンス及び交換予算未満の支出に関連する第２のペナルティレートと、
（２）前記ビルディング機器を保守及び交換することに費やされた額と前記メンテナンス及び交換予算との差と
の積以上であること
の少なくとも一方であることを必要とする、請求項１５の方法。
前記ビルディング機器からの閉ループフィードバックに基づいてリアルタイムで前記目的関数を動的に更新するステップをさらに含む、請求項１５の方法。
前記１つ以上の予算制約は、
１つ以上の予算期間と、
前記１つ以上の予算期間に関連する１つ以上のメンテナンス及び交換予算のぞれぞれと
に基づいて生成される、請求項１５の方法。
前記１つ以上の予算制約は、前記１つ以上の予算期間のそれぞれにわたる前記メンテナンス及び交換コストが、前記１つ以上の予算期間のそれぞれに関連するメンテナンス及び交換予算を超えることができないことを示す、請求項１９の方法。