除霜運転の設計課題をSysML状態遷移で整理する
この記事で分かること
- 空調機をシステムとして分解する視点
- 冷媒・空気・電力・信号の関係
- 性能、騒音、保護、保守へ波及する確認点
暖房運転中の除霜は、空調設計で見落とされやすい重要テーマです。定格暖房能力やCOPだけを見ていると、実際の低外気・高湿度条件で、着霜、除霜開始、暖房停止感、復帰遅れ、ドレン凍結、ファン騒音、圧縮機負荷が問題になることがあります。
除霜運転は一つの制御ロジックではなく、複数の状態の連鎖です。通常暖房、着霜判定、除霜準備、除霜実行、排水確認、暖房復帰、再着霜監視、異常停止を状態として整理すると、どの条件で遷移し、どの機能が責任を持つのかが見えます。SysMLの状態機械図は、この整理に向いています。
除霜設計は「霜を溶かす制御」ではなく、暖房能力、快適性、排水、保護、復帰時間を同時に扱う状態遷移設計です。
目次
結論：除霜を状態として分けて設計する
除霜運転を設計するときは、状態を分けることから始めます。暖房中に霜が付く、霜付きの兆候を検出する、除霜へ入る準備をする、四方弁や圧縮機やファンを切り替える、霜を溶かす、ドレンを排出する、暖房へ復帰する、復帰後の安定を確認する、という流れです。この流れを文章だけで管理すると、遷移条件や責務が曖昧になります。
| 状態 | 主な目的 | 見落としやすい論点 |
|---|---|---|
| 通常暖房 | 暖房能力と快適性を維持 | 着霜兆候、センサ信頼性 |
| 着霜判定 | 除霜要否を判断 | 誤判定、過剰除霜、不足除霜 |
| 除霜準備 | 切替前の安全確認 | 圧力、弁位置、ファン停止条件 |
| 除霜実行 | 霜を溶かす | 室内快適性、消費電力、騒音 |
| 排水確認 | 溶けた水を処理 | ドレン凍結、底板氷結 |
| 暖房復帰 | 能力を戻す | 復帰遅れ、過渡音、圧力変動 |
| 異常退避 | 安全側へ移る | センサ異常、除霜未完了、保護停止 |
状態を分けると、設計レビューで確認する質問も具体的になります。除霜開始条件は何か。除霜を開始しない上限時間はあるか。除霜中に室内快適性をどう扱うか。除霜完了を何で判断するか。ドレンが排出されない場合はどうするか。復帰時に圧縮機やファンをどの勾配で戻すか。これらは状態遷移図に入れるべき論点です。
除霜運転で扱う状態
状態機械図では、状態名だけでなく、各状態の入口処理、内部処理、出口条件を整理します。通常暖房では、熱交換器温度、外気温、湿度、運転時間、圧力、ファン回転数から着霜兆候を監視します。着霜判定では、しきい値、継続時間、過去履歴を使って除霜要否を決めます。除霜準備では、圧縮機、四方弁、膨張弁、ファンの切替順序を確認します。
| 状態 | 入口処理 | 出口条件 |
|---|---|---|
| 通常暖房 | 暖房制御を開始し着霜監視を有効化 | 着霜兆候、時間上限、保護条件 |
| 着霜判定 | センサ値と運転履歴を評価 | 除霜開始、監視継続、異常退避 |
| 除霜準備 | 切替前の圧力・弁状態を確認 | 安全条件成立、タイムアウト |
| 除霜実行 | 除霜用の冷媒回路と制御へ切替 | 完了判定、上限時間、異常 |
| 排水確認 | 底板温度や経過時間を確認 | 排水完了推定、凍結疑い |
| 暖房復帰 | 圧縮機・ファン・弁を段階復帰 | 安定運転、再着霜、異常 |
この表を作ると、制御仕様書に書くべき内容が見えてきます。入口処理が曖昧だと、除霜へ入る前の準備不足が起きます。出口条件が曖昧だと、除霜不足や過剰除霜が起きます。タイムアウトや異常退避がないと、センサ異常やドレン凍結時に制御が不安定になります。
遷移条件を要求へ落とす
状態遷移図で最も重要なのは、遷移条件です。除霜開始、除霜継続、除霜完了、暖房復帰、異常退避の条件を、要求として管理します。条件には、しきい値だけでなく、継続時間、センサの有効性、運転モード、外気条件、保護優先順位を含めます。
| 遷移 | 条件例 | レビュー観点 |
|---|---|---|
| 通常暖房から着霜判定 | 熱交換器温度低下、運転時間、外気湿度 | 誤判定を避けるための継続時間 |
| 着霜判定から除霜準備 | 着霜可能性が高く能力低下あり | 快適性と過剰除霜のバランス |
| 除霜準備から除霜実行 | 圧力、弁、ファンの切替条件成立 | 切替順序と保護条件 |
| 除霜実行から排水確認 | 熱交換器温度上昇、時間、圧力 | 霜残りと過剰加熱の防止 |
| 排水確認から暖房復帰 | 排水時間確保、凍結疑いなし | 底板氷結、再凍結リスク |
| 任意状態から異常退避 | センサ異常、タイムアウト、保護 | 安全側動作とログ |
要求IDを付けると、試験項目へつなげやすくなります。たとえば「DEF-03 除霜完了条件」は、熱交換器温度、除霜時間、圧力、ファン停止状態、復帰条件を含む要求として置き、低外気高湿度試験で確認します。
状態ごとの責務を整理する
除霜は、冷凍サイクル、制御、構造、排水、騒音、快適性が関係します。状態ごとの責務を整理しないと、制御担当は「除霜は動く」と考え、構造担当は「水は流れるはず」と考え、評価担当は「どの条件で見るべきか分からない」となりがちです。
| 責務 | 関係する状態 | 確認内容 |
|---|---|---|
| 冷凍サイクル | 準備、実行、復帰 | 圧力、冷媒流量、四方弁、膨張弁 |
| 制御 | 全状態 | 遷移条件、タイムアウト、保護優先 |
| 構造 | 実行、排水、復帰 | 熱交換器、底板、ドレン、ファン |
| 快適性 | 実行、復帰 | 室温低下、吹出温度、復帰時間 |
| 騒音 | 準備、実行、復帰 | 弁切替音、ファン音、過渡音 |
| 保守 | 異常退避 | ログ、エラー表示、点検導線 |
SysMLでは、状態機械図を単独で置くのではなく、要求図とブロック定義図に接続します。除霜状態の責務が、どのブロックのどの機能に割り付いているかを見せることで、設計レビューが具体的になります。
快適性と保護のトレードオフ
除霜で難しいのは、霜を確実に溶かすことと、室内快適性を維持することが衝突する点です。除霜時間を短くすると霜が残り、暖房能力が回復しにくくなります。除霜時間を長くすると、室内温度低下や消費電力増加が問題になります。復帰を急ぐと圧力変動や騒音が出ることもあります。
| 設計判断 | 良い点 | 注意点 |
|---|---|---|
| 早めに除霜する | 能力低下を予防しやすい | 過剰除霜で快適性と効率が落ちる |
| 除霜を粘る | 暖房継続時間を伸ばせる | 霜が増えすぎると復帰が遅れる |
| 復帰を急ぐ | 室温低下を短くできる | 圧力変動、騒音、保護停止リスク |
| 復帰を緩やかにする | 安定しやすい | 暖房能力回復が遅い |
| AI判定を使う | 条件に応じた除霜が可能 | 説明性、欠測、誤判定への退避が必要 |
このトレードオフは、制御ロジックだけで決まりません。熱交換器形状、フィンピッチ、ドレン経路、底板ヒータ、ファン配置、センサ位置が関係します。状態遷移図は、構造と制御の接点を見せるための図として使います。
センサデータとAI判定の扱い
AIやデータ駆動の着霜判定を使う場合でも、状態遷移の基本は変わりません。AI判定は、着霜判定状態の中の判断ロジックとして扱います。入力データ、推論周期、信頼度、欠測時動作、従来判定への退避条件を要求として置きます。
| データ | 使い方 | 注意点 |
|---|---|---|
| 熱交換器温度 | 着霜兆候、除霜完了 | センサ位置で見え方が変わる |
| 外気温・湿度 | 着霜しやすさの推定 | 湿度センサの有無と精度 |
| 圧力 | 冷媒状態と異常判定 | 過渡時の誤判定 |
| ファン回転数 | 風量と着霜進行の推定 | 汚れや風路抵抗の影響 |
| 運転履歴 | 除霜間隔、再着霜 | 市場条件の偏り |
| AI信頼度 | 退避判断 | 説明ログが必要 |
AI判定を採用する場合は、「AIが除霜を判断する」とだけ書くのは危険です。どの状態でAIが使われ、どの状態では保護ロジックが優先され、AIが失敗した場合にどの遷移へ戻るのかを明確にします。
試験条件とログ項目
除霜設計は、<u>試験条件</u>とログが重要です。外気温、湿度、風量、室内負荷、運転時間、熱交換器温度、圧力、圧縮機周波数、ファン回転数、膨張弁開度、四方弁動作、ドレン状態を記録します。状態遷移の時刻をログに残すと、除霜が遅いのか、除霜実行が足りないのか、復帰が遅いのかを分けられます。
| ログ項目 | 目的 |
|---|---|
| 状態名と遷移時刻 | 除霜シーケンスの実績確認 |
| センサ値 | 着霜判定と完了判定の妥当性確認 |
| 圧縮機・ファン・弁指令 | 制御応答と過渡音の確認 |
| 圧力・温度 | 保護余裕と冷媒状態の確認 |
| ドレン・底板温度 | 排水と凍結リスク確認 |
| 異常退避理由 | 保守診断と再現試験 |
状態遷移図を作る段階で、どのログが必要かを決めておくと、試作評価後の解析が速くなります。ログがなければ、除霜問題は「なんとなく復帰が遅い」「たまに霜が残る」という曖昧な議論になりやすいです。
要求IDとして管理する例
状態遷移図を実務で使うには、状態名を描くだけでなく、要求IDとして管理できる粒度に落とします。要求IDがあると、制御仕様書、FMEA、試験仕様書、ログ設計をつなげられます。除霜は条件分岐が多いため、要求IDなしで文章だけにすると、試作評価や不具合解析で「どの仕様を確認しているのか」が曖昧になりがちです。
| 要求ID | 要求内容 | 関係状態 | 検証観点 |
|---|---|---|---|
| DEF-01 | 着霜兆候を継続時間付きで判定する | 通常暖房、着霜判定 | 誤判定、判定遅れ |
| DEF-02 | 除霜開始前に圧力と弁状態を確認する | 除霜準備 | 切替時の保護余裕 |
| DEF-03 | 除霜完了条件を温度と時間で管理する | 除霜実行 | 霜残り、過剰除霜 |
| DEF-04 | 排水時間を確保してから暖房復帰する | 排水確認 | 底板氷結、再凍結 |
| DEF-05 | 復帰時の圧縮機とファンを段階制御する | 暖房復帰 | 過渡音、圧力変動 |
| DEF-06 | センサ異常時は安全側へ退避し理由を記録する | 任意状態、異常退避 | 保守診断、再現試験 |
このように要求IDを置くと、設計レビューで担当境界も確認できます。DEF-02は冷凍サイクルと制御、DEF-04は構造と制御、DEF-06は制御と保守診断にまたがります。担当がまたがる要求ほど、状態遷移図に残す価値があります。
よくある失敗
一つ目の失敗は、除霜を一つの処理として書いてしまうことです。除霜準備、実行、排水、復帰、異常退避を分けないと、設計レビューで抜けが出ます。
二つ目の失敗は、除霜開始条件だけを重視することです。実務では、除霜完了条件、復帰条件、再着霜監視、タイムアウトも同じくらい重要です。開始だけ賢くしても、復帰が悪ければ快適性は改善しません。
三つ目の失敗は、構造要因を制御だけで解こうとすることです。着霜や排水は、熱交換器、ドレン経路、底板、風路、センサ位置にも依存します。状態遷移図から構造ブロックへ戻る線を残します。
次に読むなら
次に読むなら、圧縮機・熱交換器・膨張弁・ファンの関係をモデル化する方法 がおすすめです。このテーマの全体像を整理する柱記事です。
関連記事
- 空調室外機の主要構成要素をSysMLブロックで整理する: このテーマの全体像を整理する柱記事です。
- 冷凍サイクルをSysMLで表現する方法：要求・機能・構造の整理手法: このテーマの全体像を整理する柱記事です。
- 空調機の騒音要求を構造設計へ落とし込む方法: 次に読むと、要求から構造・制御・検証へ論点を進めやすくなります。
- 室外機ファン制御と熱交換効率の関係をモデル化する: 次に読むと、要求から構造・制御・検証へ論点を進めやすくなります。
まとめ
除霜運転は、暖房中に霜を溶かすだけの処理ではありません。通常暖房、着霜判定、除霜準備、除霜実行、排水確認、暖房復帰、異常退避という状態の連鎖です。
SysML状態機械図を使うと、遷移条件、責務、検証条件、<u>ログ項目</u>を整理できます。除霜設計で重要なのは、賢い判定だけでなく、快適性、保護、排水、復帰時間を含めて状態ごとに要求を管理することです。
コメント