パラメトリック図で熱収支・電力・COPを表現する方法
この記事で分かること
- SysML図を実務で使い分ける判断基準
- 要求図、BDD、IBD、状態機械図の役割
- モデルを設計レビューへ接続する手順
空調機の性能議論では、冷房能力、暖房能力、消費電力、COP、外気温、室内条件、風量、冷媒状態が同時に登場します。ところが仕様書やExcelだけで管理していると、どの前提条件で計算した値なのか、どの部品変更がCOPに効いたのか、<u>試験条件</u>と設計値が一致しているのかを追いにくくなります。
SysMLのパラメトリック図は、ブロックの値プロパティと制約式を結び、設計値、計算式、要求値、検証条件の関係を見える化する図です。詳細な熱流体シミュレーションを置き換えるものではありません。むしろ、専門計算や1Dシミュレーションに入る前に、どの変数を管理し、どの式が要求検証に関係するかを部門横断で確認するために使います。
この記事では、熱収支、電力、COPを例に、空調設計で使えるパラメトリック図の作り方を解説します。
パラメトリック図では、数式より先に関係の方向を押さえることが重要です。
結論：パラメトリック図は計算式ではなく前提条件の合意に使う
パラメトリック図で大切なのは、複雑な式をきれいに描くことではありません。設計レビューで合意すべき前提条件、変数、制約、要求値、検証方法を同じ図に置くことです。空調機のCOPは、単純には能力を消費電力で割った値ですが、実務では能力の定義、運転条件、補機電力、除霜、部分負荷、制御状態が絡みます。
| 観点 | 文章仕様だけで起きやすい問題 | パラメトリック図で確認すること |
|---|---|---|
| 熱収支 | 能力と損失の境界が曖昧 | 室内側能力、室外側放熱、損失を分ける |
| 電力 | 圧縮機電力だけで評価する | ファン、制御基板、ヒータなども明示する |
| COP | 条件違いの値を比較する | 外気温、室内条件、風量、運転状態を固定する |
| 検証 | 試験条件と設計値がずれる | 要求、計算、試験ケースをひも付ける |
この図があると、熱設計、電装、制御、試験、品質保証が<u>同じ前提</u>で議論できます。
最初に性能要求と境界条件を分ける
パラメトリック図を作る前に、性能要求と境界条件を分けます。性能要求は「冷房能力3.6 kW以上」「定格COP 4.0以上」のように達成すべき値です。境界条件は「外気温35度、室内27度、相対湿度、定格風量、運転モード」のように、値を評価するための前提です。
| 分類 | 例 | レビュー観点 |
|---|---|---|
| 性能要求 | 冷房能力、暖房能力、COP、消費電力 | 要求値、許容差、試験規格との対応 |
| 境界条件 | 外気温、室内温湿度、風量、電源電圧 | 値の出所、試験条件、適用範囲 |
| 設計変数 | 圧縮機回転数、弁開度、熱交換器面積 | 部品変更時の影響 |
| 制約式 | 熱収支、電力和、COP計算 | 単位、符号、丸め、対象範囲 |
| 検証項目 | 性能試験、部分負荷試験、除霜評価 | 要求へのトレース |
要求値と境界条件を混ぜると、後で「そのCOPはどの条件の値か」という確認に時間を使います。パラメトリック図では、要求ブロック、対象システム、制約ブロック、試験ケースを明示して、値の意味を固定します。
熱収支を値プロパティとして整理する
熱収支は、空調機の性能を説明する中心です。ただし、冷媒回路、空気側、筐体損失、霜付き、除霜、配管損失などをすべて一度に細かく描くと、レビューで使いにくくなります。最初のモデルでは、値プロパティを粗く分け、必要に応じて分解します。
| 値プロパティ | 意味 | 単位 | 注意点 |
|---|---|---|---|
| Q_indoor | 室内側で処理する熱量 | kW | 冷房と暖房で符号や呼び方を統一する |
| Q_outdoor | 室外側で放出または吸収する熱量 | kW | 外気条件、霜付きの影響を受ける |
| Q_loss | 配管、筐体、補助加熱などの損失 | kW | 初期モデルでは見落としやすい |
| m_air | 空気流量 | kg/s | 風量と密度の条件を明記する |
| deltaT_air | 空気側温度差 | K | センサ位置の違いに注意する |
熱収支の式は、図の中では簡潔に表します。たとえば `Q_indoor = m_air * Cp_air * deltaT_air` のような式を置き、詳細な熱交換器モデルは別のシミュレーションや設計資料に任せます。パラメトリック図の役割は、式の正確な実装よりも、どの値がどの要求検証に使われるかを明確にすることです。
消費電力を部品ごとに分解する
COPを議論するとき、圧縮機電力だけを見てしまうと判断を誤ります。室外ファン、室内ファン、電動弁、制御基板、クランクケースヒータ、ドレンヒータ、通信機器など、製品仕様や運転モードによって含めるべき電力が変わります。
| 電力項目 | 例 | モデル化のポイント |
|---|---|---|
| P_comp | 圧縮機入力 | 周波数、圧力比、吐出温度と関係付ける |
| P_fan_out | 室外ファン入力 | 風量、騒音、熱交換性能とのトレードオフ |
| P_fan_in | 室内ファン入力 | 快適性、騒音、風量要求と接続する |
| P_aux | 補助電力 | ヒータ、制御、待機電力を分ける |
| P_total | 総消費電力 | COP計算に含める範囲を明記する |
パラメトリック図では、`P_total = P_comp + P_fan_out + P_fan_in + P_aux` のように構成します。設計レビューでは、どの電力をCOP計算に含めるか、カタログ値、社内評価値、制御評価値で定義が違わないかを確認します。
COP式を要求検証へつなげる
COPは `COP = Q_capacity / P_total` と表せます。しかし、この式だけでは不十分です。Q_capacity が冷房能力なのか暖房能力なのか、P_total に何を含むのか、定格条件か部分負荷か、除霜を含む期間平均かを明確にする必要があります。
| COPの種類 | 使いどころ | 注意点 |
|---|---|---|
| 定格COP | カタログ性能、設計初期の目標 | 試験条件を固定する |
| 部分負荷COP | 実使用に近い省エネ評価 | 制御状態と負荷率を明示する |
| 期間平均COP | 運用改善、BEMS連携 | ログ品質と欠損処理が効く |
| 除霜込みCOP | 暖房実力の評価 | 除霜頻度と外気条件を分ける |
要求図では「定格COP 4.0以上」のように書き、パラメトリック図では、その要求を検証する式、値、条件を結びます。さらに試験ケースとつなげることで、計算上の達成と実測での達成を比較できます。
AI制御とパラメトリック図を接続する
AI制御を使う場合、パラメトリック図はAIの入力と出力を検討する土台になります。AIが熱負荷を予測し、圧縮機周波数やファン回転数を補正するなら、どの値が予測入力で、どの値が制御出力で、どの制約を超えてはいけないかを明確にします。
| AIが扱う値 | 例 | パラメトリック図での扱い |
|---|---|---|
| 入力 | 外気温、室温、湿度、人流、過去電力 | 欠損時の代替値と品質条件を付ける |
| 予測値 | 熱負荷、ピーク電力、霜付きリスク | 信頼区間や有効範囲を置く |
| 出力 | 圧縮機周波数、設定温度補正、風量 | 上下限と保護制約を接続する |
| 評価値 | COP、快適性、ピーク抑制量 | 要求値と検証ケースへつなげる |
重要なのは、AIがCOP向上を提案しても、保護要求、快適性、騒音、寿命要求を上回って判断しないことです。パラメトリック図では、AI出力を制約式の入力にするだけでなく、上位制約として安全要求や制御限界を置きます。
設計レビューで使うチェックリスト
パラメトリック図を設計レビューで使うときは、図の見た目よりも確認項目を揃えることが重要です。
| チェック項目 | 確認内容 |
|---|---|
| 単位 | kW、W、K、kg/s、m3/minが混在していないか |
| 符号 | 冷房と暖房で熱量の向きが逆になっても混乱しないか |
| 境界 | 室内側、室外側、システム全体の境界が明確か |
| 電力範囲 | COP計算に含める補機電力が定義されているか |
| 条件 | 外気温、室内温湿度、風量、運転モードが固定されているか |
| トレース | 要求、式、値、試験ケースがつながっているか |
| AI制約 | AI出力が保護要求や制御限界を超えないか |
このチェックリストをレビュー前に配るだけでも、性能担当、制御担当、試験担当の会話がそろいやすくなります。
よくある失敗
よくある失敗は、Excelで使っている式をそのままパラメトリック図へ移すことです。式が多すぎると、図は読めなくなります。パラメトリック図では、<u>設計判断</u>に効く式だけを置き、詳細計算は参照先に分ける方が実務的です。
| 失敗 | 起きる問題 | 対策 |
|---|---|---|
| 式を詰め込みすぎる | 誰もレビューできない | 要求検証に効く式だけ残す |
| 単位を書かない | WとkWの誤解が起きる | 値プロパティに単位を持たせる |
| 条件を省く | COP比較が成立しない | 境界条件ブロックを必ず置く |
| 補機電力を忘れる | 実機との差が広がる | 電力項目を部品別に分解する |
| AI出力を無制限に扱う | 保護や快適性を壊す | 上下限、フェイルセーフを明示する |
実務例：要求図からIBDまでを一つの要求でつなぐ
COP要求を例にすると、要求図で評価条件を明確にし、BDDで圧縮機・熱交換器・ファンを整理し、IBDで冷媒・空気・電力の流れを分けます。最後にパラメトリック図で能力、消費電力、COPの関係を確認します。
| 確認項目 | レビューで見ること |
|---|---|
| 上位要求を検証できる単位へ分ける | レビュー時に証拠資料や担当部門を確認する |
| 部品表ではなく責務でブロックを切る | レビュー時に証拠資料や担当部門を確認する |
| 冷媒・空気・電力・信号を混ぜない | レビュー時に証拠資料や担当部門を確認する |
| 図ごとにレビューの問いを決める | レビュー時に証拠資料や担当部門を確認する |
この実務例では、結論を急がず、まず前提条件、対象範囲、検証方法をそろえます。AdSense審査や検索流入の観点でも、一般論だけでなく、現場で使う判断手順を示すことで、記事の独自性と読者価値が高まります。
参考資料・確認先
- 自社の設計標準、試験標準、品質保証基準
- 対象機種の仕様書、制御仕様書、FMEA、DRBFM、保守記録
- 法規制や規格に関わるテーマでは、必ず最新の一次資料と社内確認ルートを参照する
次に読むなら
次に読むなら、空調システムの要求図を作成する方法：COP、騒音、重量、信頼性の整理 がおすすめです。このテーマの全体像を整理する柱記事です。
関連記事
- 内部ブロック図で冷媒・空気・電力・信号の流れを整理する方法: このテーマの全体像を整理する柱記事です。
- 空調設計で活用するSysML図の優先順位：最初に習得すべき5種類: このテーマの全体像を整理する柱記事です。
- 冷凍サイクルをSysMLで表現する方法：要求・機能・構造の整理手法: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
- 状態機械図で冷房・暖房・除霜・異常停止をモデル化する: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
まとめ
パラメトリック図は、空調機の熱収支、消費電力、COPを要求、前提条件、計算式、試験条件へつなげるためのSysML図です。高度な熱流体計算を置き換えるのではなく、性能値の意味と使い方を合意するために使います。
最初に、性能要求と境界条件を分けます。次に、熱量、電力、COPを値プロパティとして定義し、どの式がどの要求検証に関係するかを明確にします。消費電力は圧縮機だけでなく、ファン、補助電力、制御電力まで含める範囲を決めます。AI制御を接続する場合は、予測値や出力値だけでなく、保護要求、上下限、欠損時処理を必ず置きます。
パラメトリック図を使うと、性能担当、制御担当、試験担当、品質保証が同じ前提条件でCOPを議論できます。設計レビューでは、式の美しさよりも、単位、境界、電力範囲、試験条件、トレースの明確さを重視してください。
次に読む記事としては、次の3本が自然です。
- 圧縮機・熱交換器・膨張弁・ファンの関係をモデル化する方法
- 冷媒回路の設計変更がシステム全体へ与える影響をSysMLで追跡する
- SysMLパラメトリック図とModelicaモデルの役割分担
コメント