JP7478792B2 - ビルディング機器のためのモデル予測的メンテナンスシステム、同メンテナンスを実施する方法及び非一時的コンピュータ可読媒体 - Google Patents

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

概要

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

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

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

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

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

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

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

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

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

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

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

いくつかの実施形態では、目的関数Ｊは、ビルディング機器の故障に関連するリスクコ
ストを組み込む。ビルディング機器のビルディングデバイスが故障した場合、ビルディン
グデバイスのメンテナンス／交換コストを超えるコストが生じることがある。特に、ビル
ディング機器の故障は、ビルディング機器のメンテナンス／交換に関連するコストと、未
対処の負荷又は失われた生産量などの様々な機会コストに関連するコストとの両方を生じ
る。リスクコストを目的関数Ｊに組み込むために、機器の故障が最適化期間中の全体的な
コストにどのように影響を及ぼし得るかを考慮に入れるリスクコスト項を含むように目的
関数Ｊを拡張することができる。リスクコスト項を含む目的関数Ｊは、以下の式で示され
る。
ここで、Ｃ_{ｆａｉｌ，ｉ}は、最適化期間の時間ステップｉにおけるビルディング機器の故
障のコストであり、Ｐ_{ｆａｉｌ，ｉ}（δ_ｉ）は、時間ステップｉにおけるビルディングデ
バイスの劣化状態δ_ｉに基づく、時間ステップｉにおけるビルディング機器のビルディン
グデバイスの故障の確率である。特に、リスクコスト項
は、各ビルディングデバイスの故障の確率を考慮に入れることにより、最適化期間にわた
るメンテナンス／交換の全体的なコストに影響を及ぼす。一般に、ビルディングデバイス
の故障の確率が上昇するにつれて、リスクコスト項が目的関数Ｊに影響を及ぼす量が増加
する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エアサイドシステム

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

いくつかの実施形態では、電力消費量Ｐ_ｏｐ，ｉは、ビルディング１０の加熱又は冷却
負荷に基づく。加熱又は冷却負荷は、ビルディング占有、時刻、曜日、現在の季節又は加
熱若しくは冷却負荷に影響を与え得る他の因子に応じて、ＭＰＭシステム６０２によって
予測することができる。いくつかの実施形態では、ＭＰＭシステム６０２は、気象サービ
ス６０４からの天気予報を使用して加熱又は冷却負荷を予測する。電力消費量Ｐ_ｏｐ，ｉ
は、接続された機器６１０の効率η_ｉにも依存する。例えば、高い効率で動作する接続さ
れた機器６１０は、低い効率で動作する接続された機器６１０に比べて、同じ加熱又は冷
却負荷を満たすために消費する電力Ｐ_ｏｐ，ｉが少ないことがある。一般に、接続された
機器６１０の特定のデバイスの電力消費量Ｐ_ｏｐ，ｉは、次式を使用してモデル化するこ
とができる。
ここで、Ｌｏａｄ_ｉは、時間ステップｉにおけるデバイスに対する加熱又は冷却負荷（例
えば、トン単位での冷却負荷、ｋＷ単位での加熱負荷など）であり、Ｐ_{ｉｄｅａｌ，ｉ}は
、対応する負荷点Ｌｏａｄ_ｉでのデバイスに関する機器性能曲線の値（例えば、トン単位
での冷却負荷、ｋＷ単位での加熱負荷など）であり、η_ｉは、時間ステップｉにおけるデ
バイスの動作効率である（例えば、０≦η_ｉ≦１）。関数ｆ（Ｌｏａｄ_ｉ）は、性能曲線
によって表されるデバイス又はデバイスのセットの機器性能曲線によって定義することが
できる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

いくつかの実施形態では、負荷／料金予測器８２２は、測定された電気負荷及び／又は
以前に測定された負荷データをＢＭＳ６０６から（例えば、機器性能モニタ８２４を介し
て）受信する。負荷／料金予測器８２２は、所与の天気予報
、日付け（日）、時刻（ｔ）及び以前に測定された負荷データ（Ｙ_ｉ－１）に応じて負荷
Ｌｏａｄ_ｉを予測することがある。そのような関係は、次式で表される。

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

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

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

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

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

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

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

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

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

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

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

高レベルオプティマイザ

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

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

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

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

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

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

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

引き続き図９を参照すると、動作コスト予測器９１０が、効率アップデータ９１１及び
効率デグレーダ９１３を含むものとして示されている。効率アップデータ９１１は、実際
の動作条件下での接続された機器６１０の効率ηを決定するように構成することができる
。いくつかの実施形態では、効率η_ｉは、次式で示されるように、接続された機器の理想
的な電力消費量Ｐ_{ｉｄｅａｌ}と、接続された機器６１０の実際の電力消費量Ｐ_{ａｃｔｕａ
ｌ}との比を表す。
ここで、Ｐ_{ｉｄｅａｌ}は、接続された機器６１０に関する性能曲線によって定義される接
続された機器６１０の理想的な電力消費量であり、Ｐ_{ａｃｔｕａｌ}は、接続された機器６
１０の実際の電力消費量である。いくつかの実施形態では、効率アップデータ９１１は、
接続された機器６１０から収集された機器性能情報を使用して、実際の電力消費量値Ｐ_{ａ
ｃｔｕａｌ}を識別する。効率アップデータ９１１は、実際の電力消費量Ｐ_{ａｃｔｕａｌ}を
理想的な電力消費量Ｐ_{ｉｄｅａｌ}と組み合わせて使用して、効率ηを計算することができ
る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

いくつかの実施形態では、メンテナンス推定器９２２は、バイナリメンテナンス決定変
数の行列Ｂ_ｍａｉｎを生成する。行列Ｂ_ｍａｉｎは、最適化期間の各時間ステップにおい
て実施することができる様々なメンテナンス活動それぞれに関するバイナリ決定変数を含
むことがある。例えば、メンテナンス推定器９２２は、以下の行列を生成することができ
る。
ここで、行列Ｂ_ｍａｉｎは、サイズがｍ×ｈであり、行列Ｂ_ｍａｉｎの各要素は、最適化
期間の特定の時間ステップにおける特定のメンテナンス活動に関するバイナリ決定変数を
含む。例えば、バイナリ決定変数Ｂ_{ｍａｉｎ，ｊ，ｉ}の値は、第ｊのメンテナンス活動が
最適化期間の第ｉの時間ステップ中に実施されるか否かを示す。

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

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

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

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

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

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

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

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

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

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

いくつかの実施形態では、購入推定器９３２は、バイナリ資本決定変数の行列Ｂ_ｃａｐ
を生成する。行列Ｂ_ｃａｐは、最適化期間の各時間ステップにおいて行うことができる様
々な資本購入それぞれに関するバイナリ決定変数を含むことができる。例えば、購入推定
器９３２は、以下の行列を生成することができる。
ここで、行列Ｂ_ｃａｐは、サイズがｐ×ｈであり、行列Ｂ_ｃａｐの各要素は、最適化期間
の特定の時間ステップにおける特定の資本購入に関するバイナリ決定変数を含む。例えば
、バイナリ決定変数Ｂ_{ｃａｐ，ｋ，ｉ}の値は、最適化期間の第ｉの時間ステップ中に第ｋ
の資本購入が行われるか否かを示す。

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

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

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

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

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

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

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

目的関数オプティマイザ

引き続き図９を参照すると、高レベルオプティマイザ８３２は、目的関数生成器９３５
及び目的関数オプティマイザ９４０を含むものとして示されている。目的関数生成器９３
５は、コスト予測器９１０、９２０及び９３０によって定式化された動作コスト項、メン
テナンスコスト項及び資本コスト項を合計することによって目的関数Ｊを生成するように
構成することができる。目的関数生成器９３５によって生成することができる目的関数の
一例は、次式で示される。
ここで、Ｃ_ｏｐ，ｉは、最適化期間の時間ステップｉにおいて接続された機器６１０が消
費する単位エネルギーあたりのコスト（例えば、ドル／ｋＷｈ）であり、Ｐ_ｏｐ，ｉは、
時間ステップｉにおける接続された機器６１０の電力消費量（例えば、ｋＷ）であり、Δ
ｔは、各時間ステップｉの継続時間であり、Ｃ_{ｍａｉｎ，ｉ}は、時間ステップｉにおいて
接続された機器６１０に対して実施されるメンテナンスのコストであり、Ｂ_{ｍａｉｎ，ｉ}
は、メンテナンスが実施されるか否かを示すバイナリ変数であり、Ｃ_{ｃａｐ，ｉ}は、時間
ステップｉにおいて接続された機器６１０の新たなデバイスを購入する資本コストであり
、Ｂ_{ｃａｐ，ｉ}は、新たなデバイスが購入されるか否かを示すバイナリ変数であり、ｈは
、最適化が実施されるホライズン又は最適化期間の継続時間である。

目的関数生成器９３５によって生成することができる目的関数の別の例は、次式で示さ
れる。
ここで、アレイＣ_ｏｐは、最適化期間の特定の時間ステップｉ＝１．．．ｈに関するエネ
ルギーコスト値Ｃ_ｏｐ，ｉを含み、アレイＰ_ｏｐは、最適化期間の特定の時間ステップｉ
＝１．．．ｈに関する電力消費量値Ｐ_ｏｐ，ｉを含み、アレイＣ_ｍａｉｎの各要素は、特
定のメンテナンス活動ｊ＝１．．．ｍに関するメンテナンスコスト値Ｃ_{ｍａｉｎ，ｊ}を含
み、行列Ｂ_ｍａｉｎの各要素は、最適化期間の特定の時間ステップｉ＝１．．．ｈにおけ
る特定のメンテナンス活動ｊ＝１．．．ｍに関するバイナリ決定変数を含み、アレイＣ_ｃ
ａｐの各要素は、特定の資本購入ｋ＝１．．．ｐに関する資本コスト値Ｃ_{ｃａｐ，ｋ}を含
み、行列Ｂ_ｃａｐの各要素は、最適化期間の特定の時間ステップｉ＝１．．．ｈにおける
特定の資本購入ｋ＝１．．．ｐに関するバイナリ決定変数を含む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

いくつかの実施形態では、ステップ１００８は、理想的な電力消費量Ｐ_{ｉｄｅａｌ，ｉ}
及びビルディング機器の効率η_ｉの関数として電力消費量Ｐ_ｏｐ，ｉを推定することを含
む。例えば、ステップ１００８は、次式を使用して電力消費量Ｐ_ｏｐ，ｉを計算すること
を含むことができる。
ここで、Ｐ_{ｉｄｅａｌ，ｉ}は、対応する負荷点Ｌｏａｄ_ｉでのビルディング機器に関する
機器性能曲線に基づく電力消費量であり、η_ｉは、時間ステップｉにおけるビルディング
機器の動作効率である。

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

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

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

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

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

他の実施形態では、ステップ１０１２は、次式に示されるように、メンテナンスコスト
アレイＣ_ｍａｉｎにバイナリ決定変数の行列Ｂ_ｍａｉｎを乗算することによってメンテナ
ンスコストＣｏｓｔ_ｍａｉｎを推定することを含む。
ここで、アレイＣ_ｍａｉｎの各要素は、特定のメンテナンス活動ｊ＝１．．．ｍに関する
メンテナンスコスト値Ｃ_{ｍａｉｎ，ｊ}を含み、行列Ｂ_ｍａｉｎの各要素は、最適化期間の
特定の時間ステップｉ＝１．．．ｈにおける特定のメンテナンス活動ｊ＝１．．．ｍに関
するバイナリ決定変数を含む。

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

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

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

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

他の実施形態では、ステップ１０１４は、次式に示されるように、資本コストアレイＣ
_ｃａｐにバイナリ決定変数の行列Ｂ_ｃａｐを乗算することによって資本コストＣｏｓｔ_ｃ
ａｐを推定することを含む。
ここで、アレイＣ_ｃａｐの各要素は、特定の資本購入ｋ＝１．．．ｐに関する資本コスト
値Ｃ_{ｃａｐ，ｋ}を含み、行列Ｂ_ｃａｐの各要素は、最適化期間の特定の時間ステップｉ＝
１．．．ｈにおける特定の資本購入ｋ＝１．．．ｐに関するバイナリ決定変数を含む。

引き続き図１０を参照すると、プロセス１０００は、コストＣｏｓｔ_ｏｐ、Ｃｏｓｔ_{ｍ
ａｉｎ}及びＣｏｓｔ_ｃａｐを含む目的関数を最適化して、ビルディング機器に関する最適
なメンテナンス戦略を決定すること（ステップ１０１６）を含むものとして示されている
。ステップ１０１６は、ステップ１０１０～１０１４で定式化された動作コスト項、メン
テナンスコスト項及び資本コスト項を合計することによって目的関数Ｊを生成することを
含むことができる。ステップ１０１６で生成することができる目的関数の一例は、次式で
示される。
ここで、Ｃ_ｏｐ，ｉは、最適化期間の時間ステップｉにおいて接続された機器６１０が消
費する単位エネルギーあたりのコスト（例えば、ドル／ｋＷｈ）であり、Ｐ_ｏｐ，ｉは、
時間ステップｉにおける接続された機器６１０の電力消費量（例えば、ｋＷ）であり、Δ
ｔは、各時間ステップｉの継続時間であり、Ｃ_{ｍａｉｎ，ｉ}は、時間ステップｉにおいて
接続された機器６１０に対して実施されるメンテナンスのコストであり、Ｂ_{ｍａｉｎ，ｉ}
は、メンテナンスが実施されるか否かを示すバイナリ変数であり、Ｃ_{ｃａｐ，ｉ}は、時間
ステップｉにおいて接続された機器６１０の新たなデバイスを購入する資本コストであり
、Ｂ_{ｃａｐ，ｉ}は、新たなデバイスが購入されるか否かを示すバイナリ変数であり、ｈは
、最適化が実施されるホライズン又は最適化期間の継続時間である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

概要

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

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

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

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

最適な複合コスト曲線

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

いくつかの実施形態では、リスクコスト項を組み込む目的関数生成器９３５によって生
成された目的関数は、以下の形式を有する。
ここで、Ｃ_{ｆａｉｌ，ｉ}は、最適化期間の時間ステップｉでのビルディング機器の故障の
コストであり、Ｐ_{ｆａｉｌ，ｉ}（δ_ｉ）は、時間ステップｉでの劣化の状態δ_ｉに基づく
時間ステップｉでの故障の確率であり、すべての他の変数は、上述したものである。

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

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

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

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

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

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

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

いくつかの実施形態では、雑費予測器９４８によって生成された雑費項を含む目的関数
Ｊは、以下によって示すことができる。
ここで、Ｃ_{ｍｉｓｃ，ｉ}は、時間ステップｉでの雑多なメンテナンス出費であり、Ｂ_{ｍｉ
ｓｃ，ｉ}は、時間ステップｉで雑多な出費が生じるか否かを示すバイナリ変数である。

目的関数生成器９３５によって生成することができる目的関数の別の例は、以下の式で
示される。
ここで、アレイＣ_ｍｉｓｃは、最適化期間の特定の雑多な出費ｌ＝１．．．ｓに関する雑
費値Ｃ_{ｍｉｓｃ，ｉ}を含み、アレイＢ_ｍｉｓｃは、最適化期間の特定の時間ステップｉ＝
１．．．ｈでの特定の雑多な出費ｌ＝１．．．ｓに関するバイナリ決定変数を含む。

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

故障リスク予測器９４６によって生成されるリスクコスト項と、雑費予測器９４８によ
って生成される雑多なコスト項との両方が目的関数Ｊに組み込まれる場合、目的関数生成
器９３５によって生成される目的関数Ｊの一例は、次の式によって示される。
上記の目的関数に基づいて、目的関数オプティマイザ９４０は、全体的なコストが最適化
（例えば、最小化）されるように決定変数の値を決定することができる。各ビルディング
デバイスの故障コストに応じて、目的関数オプティマイザ９４０は、上記ビルディングデ
バイスの故障確率を低く保つために、高い故障コストを有するビルディングデバイスに対
して追加のメンテナンス、交換及び／又は雑多な修理活動を実施すべきであると判断する
ことがある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例示的実施形態の構成

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

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

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

Claims (20)

1. ビルディング機器のためのモデル予測的メンテナンスシステムであって、
   前記モデル予測的メンテナンスシステムは、
   ビルディングでの可変の状態又は条件に影響を及ぼすように前記ビルディング機器を動作させることと、
   最適化期間の継続期間にわたって前記ビルディング機器を動作させるコストを予測することと、
   メンテナンス予算を画定する１つ以上の予算制約を生成することと、
   前記ビルディング機器に関するメンテナンススケジュールを決定するために目的関数を最適化することと
   を行うべく構成される処理回路を含み、
   前記目的関数は、
   前記ビルディング機器のメンテナンスコストと、
   前記ビルディング機器を動作させる前記予測されたコストと、
   前記メンテナンス予算に対する前記ビルディング機器のメンテナンスコストに基づくペナルティコスト項と
   を含む、モデル予測的メンテナンスシステム。
2. 前記メンテナンス予算は、前記ビルディング機器を整備することと、前記ビルディング機器を修理することと、前記ビルディング機器を交換することとのうち少なくとも一つに対する予算を含み、
   前記メンテナンススケジュールは、前記ビルディング機器を整備することと、前記ビルディング機器を修理することと、前記ビルディング機器を交換することとのうち少なくとも一つに対するスケジュールを含み、
   前記メンテナンスコストは、前記ビルディング機器を整備することと、前記ビルディング機器を修理することと、前記ビルディング機器を交換することとのうち少なくとも一つに対する予測コストを含む、請求項１のモデル予測的メンテナンスシステム。
3. 前記１つ以上の予算制約は、前記ペナルティコスト項が、
   （１）前記メンテナンス予算を超える支出に関連する第１のペナルティレートと、
   （２）前記ビルディング機器を保守することに費やされた額と前記メンテナンス予算との差と
   の積以上であること、又は
   （１）前記メンテナンス予算未満の支出に関連する第２のペナルティレートと、
   （２）前記ビルディング機器を保守することに費やされた額と前記メンテナンス予算との差と
   の積以上であること
   の少なくとも一方であることを必要とする、請求項１のモデル予測的メンテナンスシステム。
4. 前記処理回路はさらに、前記ビルディング機器からの閉ループフィードバックに基づいてリアルタイムで前記目的関数を動的に更新するべく構成される、請求項１のモデル予測的メンテナンスシステム。
5. 前記１つ以上の予算制約は、
   １つ以上の予算期間と、
   前記１つ以上の予算期間に関連する１つ以上のメンテナンス予算のそれぞれと
   に基づいて生成される、請求項１のモデル予測的メンテナンスシステム。
6. 前記１つ以上の予算制約は、前記１つ以上の予算期間のそれぞれにわたる前記メンテナンスコストが、前記１つ以上の予算期間のそれぞれに関連するメンテナンス予算を超えることができないことを示す、請求項５のモデル予測的メンテナンスシステム。
7. 前記処理回路は、
   前記１つ以上の予算期間の１つ以上が部分的に前記最適化期間の外で生じるか否かを決定することと、
   前記１つ以上の予算期間の１つ以上が部分的に前記最適化期間の外で生じるとの決定に応答して、部分的に前記最適化期間の外で生じる前記１つ以上の予算期間の前記１つ以上のそれぞれに関して、１つ以上の低減されたメンテナンス予算を決定することと
   を行うべく構成される、請求項５のモデル予測的メンテナンスシステム。
8. ビルディング機器のモデル予測的メンテナンスを実施する方法であって、
   １つ以上の処理回路が、ビルディングでの可変の状態又は条件に影響を及ぼすように前記ビルディング機器を動作させるステップと、
   前記１つ以上の処理回路が、最適化期間の継続期間にわたって前記ビルディング機器を動作させるコストを予測するステップと、
   前記１つ以上の処理回路が、メンテナンス予算を画定する１つ以上の予算制約を生成するステップと、
   前記１つ以上の処理回路が、前記ビルディング機器に関するメンテナンススケジュールを決定するために目的関数を最適化するステップと
   を含み、
   前記目的関数は、
   前記ビルディング機器のメンテナンスコストと、
   前記ビルディング機器を動作させる前記予測されたコストと、
   前記メンテナンス予算に対する前記ビルディング機器のメンテナンスコストに基づくペナルティコスト項と
   を含む、方法。
9. 前記メンテナンス予算は、前記ビルディング機器を整備することと、前記ビルディング機器を修理することと、前記ビルディング機器を交換することとのうち少なくとも一つに対する予算を含み、
   前記メンテナンススケジュールは、前記ビルディング機器を整備することと、前記ビルディング機器を修理することと、前記ビルディング機器を交換することとのうち少なくとも一つに対するスケジュールを含み、
   前記メンテナンスコストは、前記ビルディング機器を整備することと、前記ビルディング機器を修理することと、前記ビルディング機器を交換することとのうち少なくとも一つに対する予測コストを含む、請求項８の方法。
10. 前記１つ以上の予算制約は、前記ペナルティコスト項が、
    （１）前記メンテナンス予算を超える支出に関連する第１のペナルティレートと、
    （２）前記ビルディング機器を保守することに費やされた額と前記メンテナンス予算との差と
    の積以上であること、又は
    （１）前記メンテナンス予算未満の支出に関連する第２のペナルティレートと、
    （２）前記ビルディング機器を保守することに費やされた額と前記メンテナンス予算との差と
    の積以上であること
    の少なくとも一方であることを必要とする、請求項８の方法。
11. 前記１つ以上の処理回路が、前記ビルディング機器からの閉ループフィードバックに基づいてリアルタイムで前記目的関数を動的に更新するステップをさらに含む、請求項８の方法。
12. 前記１つ以上の予算制約は、
    １つ以上の予算期間と、
    前記１つ以上の予算期間に関連する１つ以上のメンテナンス予算のそれぞれと
    に基づいて生成される、請求項８の方法。
13. 前記１つ以上の予算制約は、前記１つ以上の予算期間のそれぞれにわたる前記メンテナンスコストが、前記１つ以上の予算期間のそれぞれに関連するメンテナンス予算を超えることができないことを示す、請求項１２の方法。
14. コンピュータ実行可能命令が記憶された１つ以上の非一時的コンピュータ可読媒体であって、
    前記コンピュータ実行可能命令は、モデル予測的メンテナンスシステムの１つ以上のプロセッサによって実行されると、前記モデル予測的メンテナンスシステムに、
    ビルディングでの可変の状態又は条件に影響を及ぼすようにビルディング機器を動作させることと、
    最適化期間の継続期間にわたって前記ビルディング機器を動作させるコストを予測することと、
    メンテナンス予算を画定する１つ以上の予算制約を生成することと、
    前記ビルディング機器に関するメンテナンススケジュールを決定するために目的関数を最適化することと
    を含む動作を行わせ、
    前記目的関数は、
    前記ビルディング機器のメンテナンスコストと、
    前記ビルディング機器を動作させる前記予測されたコストと、
    前記メンテナンス予算に対する前記ビルディング機器のメンテナンスコストに基づくペナルティコスト項と
    を含む、非一時的コンピュータ可読媒体。
15. 前記メンテナンス予算は、前記ビルディング機器を整備することと、前記ビルディング機器を修理することと、前記ビルディング機器を交換することとのうち少なくとも一つに対する予算を含み、
    前記メンテナンススケジュールは、前記ビルディング機器を整備することと、前記ビルディング機器を修理することと、前記ビルディング機器を交換することとのうち少なくとも一つに対するスケジュールを含み、
    前記メンテナンスコストは、前記ビルディング機器を整備することと、前記ビルディング機器を修理することと、前記ビルディング機器を交換することとのうち少なくとも一つに対する予測コストを含む、請求項１４の非一時的コンピュータ可読媒体。
16. 前記１つ以上の予算制約は、前記ペナルティコスト項が、
    （１）前記メンテナンス予算を超える支出に関連する第１のペナルティレートと、
    （２）前記ビルディング機器を保守することに費やされた額と前記メンテナンス予算との差と
    の積以上であること、又は
    （１）前記メンテナンス予算未満の支出に関連する第２のペナルティレートと、
    （２）前記ビルディング機器を保守することに費やされた額と前記メンテナンス予算との差と
    の積以上であること
    の少なくとも一方であることを必要とする、請求項１４の非一時的コンピュータ可読媒体。
17. 前記動作はさらに、前記ビルディング機器からの閉ループフィードバックに基づいてリアルタイムで前記目的関数を動的に更新することを含む、請求項１４の非一時的コンピュータ可読媒体。
18. 前記１つ以上の予算制約は、
    １つ以上の予算期間と、
    前記１つ以上の予算期間に関連する１つ以上のメンテナンス予算のそれぞれと
    に基づいて生成される、請求項１４の非一時的コンピュータ可読媒体。
19. 前記１つ以上の予算制約は、前記１つ以上の予算期間のそれぞれにわたる前記メンテナンスコストが、前記１つ以上の予算期間のそれぞれに関連するメンテナンス予算を超えることができないことを示す、請求項１８の非一時的コンピュータ可読媒体。
20. 前記動作はさらに、前記１つ以上の予算期間の１つ以上が部分的に前記最適化期間の外で生じるか否かを決定することと、
    前記１つ以上の予算期間の１つ以上が部分的に前記最適化期間の外で生じるとの決定に応答して、部分的に前記最適化期間の外で生じる前記１つ以上の予算期間の前記１つ以上のそれぞれに関して、１つ以上の低減されたメンテナンス予算を決定することと
    を含む、請求項１８の非一時的コンピュータ可読媒体。