CEA気候制御 — 温湿度・センサー・応答遅れ・結合制御

二つのブラウザ実験

上のパネルは冷房応答です。応答の時定数・照明の顕熱・冷房能力を変更し、室温と指令／実出力を別々に表示します。0／300／900／1800秒のプリセットは、他の入力を公開済みの基準値に戻します。Pythonのインストールは不要で、本文のローカル再現手順は任意です。

結合制御は入力を変えるたびに同じ条件でON/OFFとPIを計算します。温湿度の範囲外時間・冷房と除湿指令の重なり・除熱量・除湿量・操作量の変動を、単位と尺度が異なる六つの棒グラフで比較します。A/Bは両制御器の結果一組を保存するため、条件変更と制御器比較を区別できます。両実験で指標・数値表・ダウンロード・条件共有が使えます。

冷房応答は元の12時間モデル、室温の10秒刻み陽解法、一次遅れの厳密な区間平均出力を保持します。照明は2–8時、初期／目標24°C、外気22°C、基礎発熱800 W、熱容量12 MJ/K、UA 300 W/K、PIゲイン0.6／0.0004で固定。最終行の保持指令を含む全標本を表示します。評価範囲は23–25°C。誤差と範囲外時間は区間開始時、極値は端点も含めます。湿度やセンサー遅れは含みません。

結合制御は24時間・60秒刻み陽解法、照明08–24時、初期24°C／RH70%、300 m³、12 MJ/K、UA 450 W/K、換気0.05 m³/s。外気21±6°C／RH60%、明暗の蒸散2／0.35 kg/hは指定入力です。ON/OFF閾値23.5／24.5°C・RH65／75%、PI目標24°C／RH70%と元のゲイン・条件付き積分を保持します。範囲外時間は更新後の状態を23–25°C・RH60–80%で判定。総変動量は操作量の絶対変化の合計で、切替回数ではありません。同時稼働の元指標は冷房・除湿指令が共に正の時間を数えるため、再熱能力0でも集計されます。

結合モデルは温度更新前の飽和量で水を制限し、冷却後の再平衡や凝縮熱の回収は計算しません。冷房は顕熱のみ、除湿は指定した水分除去と独立した再熱です。コイル・機器遅れ・センサー・CO₂の結合はありません。二つは異なる合成実験で、同じモデルの設定違いではありません。熱量kWhは電気使用量ではなく、操作範囲は教材上の仮定です。栽培設定や機器選定を示しません。元のカーネル・設定・ZIP・基準結果は保持しています。

cooling: experiment.py · cooling_kernel.py · config.json

coupled: experiment.py · coupled_kernel.py · config.json

CEAの温度・湿度制御 — 冷却・除湿・換気が干渉する理由

温度とRHには別々の設定値を置けるが、設備は一つの量だけを変えるとは限らない。冷却coilは顕熱を除き、表面が露点より低ければ水も凝縮させる。除湿機は水を回収しながら室内へ顕熱を戻す構成があり、換気は外気条件に応じて温度・水蒸気・CO₂を同時に運ぶ。そのため「温度controller」と「湿度controller」を独立にON/OFFすると、互いの操作を打ち消すことがある。

図1 · ボタンで表示を切り替え

図: Duskcoil作成。設備構成を指定しない制御責務の模式図。

状態と操作を分ける

前の記事では熱収支の状態を室温T、湿度収支の状態を水蒸気質量m_vとした。結合制御でもRHを独立した保存量にはしない。

米国DOEのHVAC技術資料は顕熱と潜熱の制御を区別し、冷却除湿が過冷却と再熱を伴う場合を説明している。Oklahoma State University Extensionも、温室の換気を温度と湿度の両方へ関わる設備として扱う。

優先順位がないと制御が競合する

例えばRH上限超過で冷却除湿を始め、温度下限を下回ったためheaterをONにすると、同じ時間帯に冷却と加熱が動く。これを常に誤りとは言えない。再熱を使って湿度だけを下げる構成もある。しかし意図、許容時間、energy costを記録しなければ、制御の成功と設備の打ち消しを区別できない。

最小のsupervisorは次の順序を明示する。

1. sensor異常、結露、設備保護などの安全制約
2. 温度・絶対水分量のhard limit
3. 通常の設定帯とヒステリシス
4. 同時運転禁止または許可条件
5. 電力上限、換気によるCO₂損失などの最適化

比較実験の受入条件

On/Off、rule-based、PIを比較する前に、同じ外気・蒸散source・LED schedule・初期状態を使う。actuatorごとに能力、最小ON/OFF時間、遅延、飽和、消費電力または回収水量を固定する。比較指標は温度帯外時間、RH帯外時間、凝縮量、切替回数、同時冷暖房時間、電力量を分ける。一つの平均誤差だけで順位を決めない。

また、sensor値のclip、欠測時の最後値保持、未来の外気をcontrollerだけが知る条件を禁止する。基準となる保存式のenergy residualとwater residualが壊れたrunは制御比較から除外する。

この記事は制御設計の入口であり、作物別設定値や実設備の性能を推奨しない。次の実装では熱・湿度の二状態だけを同一simulationへ結合し、CO₂は別の監視制約として残す。

参考資料

• Grid-interactive Efficient Buildings: HVAC（U.S. DOE）
• The Hobby Greenhouse（Oklahoma State University Extension）
• Assessing the Risk of Disease in Greenhouses（Penn State Extension）

温湿度センサー — 配置・応答遅れ・校正から制御値を確かめる

制御器が見ている温度は、どこの温度か

前回の冷却応答遅れLabは、指令値と実際の冷却量を分けた。一方、制御器へ戻す室温はその時点の真値として扱っていた。現場へ進むには、空間の状態、センサーの測定値、制御器へ渡す値も分ける必要がある。

たとえば空気温度が24°Cから26°Cへ瞬時に変わり、測定系を時定数60秒の一次遅れと仮定すると、30秒後の表示は 24.787°Cである。表示だけを25°Cと比較すると、実際には超過しているのに超過を検出しない。この数値は説明用の解析計算で、栽培施設の実測や特定製品の性能ではない。

本記事は計測設計のガイドである。既存Labの制御性能を再評価したものではなく、センサー選定の順位や作物の推奨設定値も扱わない。

測定点ごとに用途を決める

栽培棚の周囲、給気、還気を同じ「室温」として平均すると、どの場所で起きた変化なのかを失う。まず「何を制御・検出したいか」を決め、その目的に対応する位置を記録する。以下は本記事で提案する調査の分け方であり、施設共通の必要台数を示すものではない。

Sensirionの設計ガイドは、設置場所の代表性、筐体の空気交換、周辺からの熱の影響が測定系の性能を左右すると説明する。データシートの精度だけで設置後の性能は決まらない。

実際の調査では点灯・消灯、送風の運転状態、植物の成長段階を記録し、同じ条件の時間帯で位置差を比較する。可搬センサーを順に移す場合は固定の参照点も残す。移動中に室全体が変化すると、時間変化を位置差と取り違えるためである。二つのセンサーを入れ替える比較も役立つが、入れ替え前後の環境が同じとは限らない。並置と位置交換を組み合わせて原因を絞る。

応答時間と記録間隔を分ける

1秒ごとに数値を読めても、測定系が1秒で追従するとは限らない。温度とRHの応答も同じとは限らず、筐体を含めた確認が必要になる。応答時間の定義は製品資料で確認する。設計ガイドでは、ステップ変化の約63%へ到達する時間を用いた説明がある。

ここでは測定対象を T、測定値を T_m、時定数を \tau_s とする単純な一次遅れを仮定する。

24°Cで平衡だった測定系に26°Cの一定入力を与えると、T_m(t)=26-2\exp(-t/60) になる。

25°Cを超えるのは約41.6秒後で、離散的に記録する場合は次の記録時刻まで検出が遅れる。25°Cは説明用の閾値である。このモデルでは入力が変わった直後から測定値も動く。一定時間まったく反応しない純むだ時間とは異なる。

次の標準ライブラリだけのPythonコードで表と閾値到達時間を再計算できる。保存して python3 sensor_example.py で実行する。外部ファイルの読み書きはしない。

from math import exp, log

initial, final, tau = 24.0, 26.0, 60.0
for seconds in (30, 60, 180):
    measured = final + (initial - final) * exp(-seconds / tau)
    print(f"{seconds:3d} s: {measured:.3f} C, gap {final-measured:.3f} C")
threshold = 25.0
crossing = -tau * log((final - threshold) / (final - initial))
print(f"threshold crossing: {crossing:.1f} s")

実際の室温はステップ状とは限らず、測定系が一つの時定数で表せるとも限らない。現場ログから応答を調べるときは、参照器自身の応答と時刻同期を確認する。空調指令から表示変化までの時間だけを測っても、冷却機器・空気輸送・センサーの遅れを分離できない。

平滑化した値だけを残さない

センサーから取得した値へ移動平均などを適用するなら、取得値と制御に使った処理後の値を両方保存する。ここでいう取得値は機器が出力した値であり、内部で未処理の値とは限らない。フィルター設定も記録する。

前のLabへ測定遅れを追加するなら、PIの誤差は T_m-T_{sp} に変更し、評価にはモデルの真の温度 T も残す。「測定値が評価帯を外れた時間」と「真の温度が外れた時間」を別に集計する設計になる。本記事の計算例は閉ループを計算していないので、遅れによる振動や温度超過量の増加はここでは数値として主張しない。

実施設では真値を直接取得できない。独立した参照測定にも不確かさがあるため、比較結果には参照器、設置位置、校正情報を添える。

RHと温度は組として扱う

相対湿度は水蒸気分圧をその温度の飽和水蒸気圧で割った量である。VPDの計算へ渡すときは、同じ空気を代表する温度とRHを、時刻をそろえて使う。棚の温度と給気のRHを組み合わせても、棚のVPDを測ったことにはならない。

結露対策として加温するプローブでは、加温された測定部の温度と周囲の空気温度を区別する。Vaisalaの加温プローブ資料は、周囲のRHを得るために別の周囲温度測定を使う構成を説明している。加温中の出力を無条件に栽培域の温湿度として扱わず、選んだ機器の出力仕様に従う。

VPD Labへ測定値を渡す場合も、空気温度から求めるVPDと葉温を使う葉面側の差を区別する。葉温を測定していないときに、空気温度からの計算を葉面の実測値とは呼ばない。

校正・調整・位置調査を別の記録にする

Vaisalaの校正資料では、校正は基準との比較、調整は基準に合うよう機器へ変更を加えることとして区別される。一点で一致しても使用範囲全体の一致は確認できない。確認点と許容差は、使う温湿度範囲と参照器の不確かさを踏まえて決める。

運用記録には、センサーID、比較前の値、参照値、安定を判断した条件、実施日を残す。調整した場合は調整後の比較値と設定変更も追加する。調整前の差を消してしまうと、それ以前の栽培ログをどこまで信頼できるか判断しにくくなる。

二台が同じ値を示すことは、共通の偏りがない証拠にはならない。また、校正で機器差を確認しても、設置位置が栽培域を代表するとは限らない。機器の比較と位置の調査を別々に完了させる。

制御へ渡すログと異常時の扱い

以下は本記事で提案する記録項目である。実測データの例ではない。

通信が止まった際に直前値を保持すると、表示は安定して見える。値とともに経過時間と有効フラグを渡し、古いデータを正常扱いしない設計にする。何秒で無効とするか、無効時にどの操作へ切り替えるかは設備と作物の条件に応じて決め、試運転で確認する。

次の実験へ進む前に、並置で機器差を調べ、複数位置で空間差を調べ、取得から制御入力までの遅れを記録する。この三つがそろうと、制御を変更すべきなのか、測定の方法を直すべきなのかを検討できる。

冷却応答遅れLab — PIの指令値と実際の冷却量を分ける

冷却能力が同じでも、応答は同じにならない

前回の温湿度制御比較では、操作量を変更すると冷却・除湿の能力がその時刻から出ると仮定した。今回は冷却だけを切り出し、指令値に対して実際の冷却量がゆっくり追従する場合を調べる。対象は合成の一室モデルで、栽培施設の実測結果ではない。

同じ12時間で冷却器の時定数を0秒から900秒へ変えると、温度偏差の積分は 2.287から4.351 K·h、最低室温は 23.419から23.044°Cへ変わった。設定した23–25°Cの帯はどちらも守るが、「帯に入ったか」だけでは応答の違いが見えない。

図2 · ボタンで表示を切り替え

図: Duskcoil。配布Pythonが生成した合成時系列。赤線の1800秒は追加の厳しい条件。帯域は作物の推奨値ではなく比較用の仮定。

前回から残すもの、今回切り出すもの

これは前回の数値結果へ一項だけ加えた追試ではなく、冷却器の応答を見分けるための小さな別実験である。湿度・蒸散・除湿再熱・CO₂は計算しない。外気温22°C、その他の発熱800 W、2–8時間に加わる照明由来の顕熱負荷8,000 Wを全ケースで共通にする。8,000 Wは照明設備の電力を推定した値ではない。

DOEの顕熱・潜熱分離に関する資料は、温度と除湿の負荷を分けて扱う技術を説明している。本記事の一室モデルはその装置を再現したものではなく、湿度制御と消費電力の評価は別に必要となる。

指令と実出力を二つの変数にする

温度が設定値より高いと冷却を増やす向きに誤差を定義する。PIの未制限出力を0–1へ制限したものが指令値 u、実際に出ている冷却能力の比率が a である。

これは一次遅れである。指令を一定にすると、時定数が一つ経過した時点で変化幅の約63.2%まで応答する。「900秒間まったく動かず、その後に動く」という純むだ時間ではない。初期実出力は0、時定数0秒のケースだけは指令に瞬時追従する。

室温には次の顕熱収支を使う。

配布コードでは10秒間の指令を固定し、冷却器の区間終端値と区間平均を一次遅れの解析解で求める。熱収支には区間平均の冷却量を入れ、室温は前進Euler法で更新する。終端の冷却能力を区間全体で出ていたと数える誤りを避けるためである。

PIは積分の条件付き停止を使う。未制限出力が上限を超え、誤差もさらに冷却を増やす向きなら積分を進めず、飽和から戻す向きなら積分する。MathWorksの解説でも条件付き積分と実アクチュエータ出力を使う追従方式は区別される。ここでは前者だけを実装しているため、積分停止を入れただけで機器の遅れまで補償できるとは考えない。

指標を同じ期間で比較する

温度偏差積分は |T-T_{sp}| の時間積分で、暖かすぎる時間と冷えすぎる時間を相殺しない。帯域外時間と偏差積分は各区間の開始温度から計算するため、10秒刻みの近似である。最低・最高温度は初期・終端を含む格子点で評価する。

消灯時は照明由来の顕熱負荷がなくなる一方、冷却器の出力はすぐには下がらない。図の下段で指令が低下しても実出力が残る区間と、上段の低温側への振れを対応付けて読む。冷却除去熱の増加を消費電力や電気料金の増加へ直接換算することはできない。冷却COP、ポンプ、ファンなどをこのモデルは持たない。

実行して一つの条件を変える

再現用ZIPを空のディレクトリへ展開する。Python 3.12で検証済み。計算とテストは標準ライブラリだけで動く。

python3 reproduce.py
python3 -m unittest -v
python3 experiment.py config.json --tau 900 --csv trace-local.csv
python3 experiment.py config.json --tau 1800

reproduce.pyは配布ファイルのハッシュを確認し、0・300・900秒の保存結果を再計算する。CSVの出力先は既存ファイルを上書きしない。最後の行の指令値は直前の保持値であり、終端で新たな制御更新を行った値ではない。

設定JSON、計算コード、基準結果、1800秒の結果、900秒のCSV、マニフェストを個別にも取得できる。

最初はゲインを変えずに1800秒を試す。この条件では帯域外時間が3.650時間となる。ただし、これは設定した帯への不適合であって、発散や実設備の故障を示すものではない。次に時定数を900秒へ戻し、dt_sを5へ変えて刻みの影響を調べる。全条件を同時に変えると、何が結果を改善したか分からなくなる。

数値の正しさと設備への適合を分けて確認する

10テストで、一次遅れの既知解、時間区間の分割、出力制限、積分の停止と復帰、一定発熱の既知解、熱収支残差、保存結果、入力異常、刻み半減、1800秒の帯域違反を確認した。10秒と5秒で、標準3ケースの最低・最高温度、偏差積分、除去熱の差はそれぞれ0.03°C、0.03 K·h、0.03 kWh未満だった。この数値収束の確認は、合成パラメータが実施設を表す証拠ではない。

実設備へつなぐなら、まず指令履歴と実冷却量を推定できる計測をそろえ、機器応答の同定用データと検証用データを分ける。センサ遅延、最低運転時間、段階制御、純むだ時間、湿度との結合は次の拡張になる。作物の推奨温度・病害リスク・省エネルギー率は本実験の出力ではない。

次に読む

温湿度センサーの配置・応答遅れ・校正では、制御器へ戻す測定値の確かめ方を整理する。

温湿度制御比較Lab — On/OffとPIを同じ外乱で試す

結果から見る

同じ合成24時間で、PIはOn/Offより操作量の総変動を 34.0→2.853、冷却除去熱を 182.233→178.854 kWhへ減らした。一方、温度帯外時間は 7.95→10.02 h、冷却と除湿再熱の同時運転は 9.37→14.65 hへ増えた。したがって、このrunから「PIの方が優秀」とは結論できない。

図3 · ボタンで表示を切り替え

図: Duskcoil作成。制御比較の共通system boundary。

比較条件

熱収支Labと湿度収支Labを一つにし、状態は室温Tと水蒸気質量m_vの二つに限定した。外気、LED、合成蒸散、初期状態、60秒刻み、冷却14 kW、除湿2.5 kg/hは両controllerで共通。除湿運転は室内へ1.8 kWの顕熱を戻す仮想構成とした。CO₂は独立収支Labのままで結合していない。

On/Offは温度24±0.5°C、RH 70%を中心とする65/75%で切り替える。PIは出力を0–1へ飽和させ、飽和を悪化させる向きには積分を進めないconditional anti-windupを使う。gainは合成値で、調整済み製品設定ではない。

一つの誤差で順位を決めない

DOE資料が説明するように、顕熱・潜熱制御では過冷却と再熱が相互作用する。energyだけを下げても温度帯外や同時運転が増えれば、別の設計判断になる。

実行する

ZIPを展開して実行する。

python3 experiment.py config.json > result.json
python3 -m unittest -v

config.json、expected.json、experiment.pyを公開する。8テストは両controller、決定性、energy/water residual、入力異常を検査する。

次はgainを変える前に、評価帯、重み、最大同時運転、電力換算、actuator遅延を受入条件として固定する。実施設へ移す場合は、同定用dataと検証用dataを分ける。この記事は作物設定、実設備の省energy率、PIの優位性を保証しない。

続編の冷却応答遅れLabでは、指令値と実冷却量を分け、時定数だけを変えて比較する。

参考資料

• Grid-interactive Efficient Buildings: HVAC（U.S. DOE）
• The Hobby Greenhouse（Oklahoma State University Extension）