空調室外機のブロック定義図を作成する具体例

この記事で分かること

• 具体的なSysML図の作り方
• 空調設計で見落としやすい接続・状態・制約
• 仕様書、試験、レビューへ展開する方法

空調室外機をSysMLでモデル化するとき、最初に悩みやすいのがブロック定義図です。圧縮機、熱交換器、膨張弁、ファン、インバータ、制御基板、センサ、筐体をどの粒度で分ければよいのか。部品表のように細かく書けばよいのか。あるいは機能ブロックとして抽象化すればよいのか。この判断を誤ると、図は詳しいのに設計レビューで使いにくいモデルになります。

ブロック定義図の目的は、部品を並べることではありません。室外機がどの構成要素で成立し、それぞれがどの要求、機能、流れ、状態、故障モード、検証項目と関係するかを整理することです。空調設計では、冷媒回路と空気流路だけでなく、電力、信号、制御、据付、保守、法規制も同時に扱います。ブロック定義図は、その入口になる図です。

空調室外機のブロック定義図は、部品リストではなく「責務と関係」を表す設計レビュー用の骨格として作ります。

目次

• 結論：最初は5つのサブシステムに分ける
• 対象範囲を決める
• 第一階層のブロック例
• 部品名ではなく責務を添える
• 要求・故障・検証とのつなぎ方
• レビューで使うチェックリスト
• よくある失敗

• まとめ

結論：最初は5つのサブシステムに分ける

室外機のブロック定義図は、最初から部品単位で細かく分解しない方が実務で使いやすくなります。初回モデルでは、室外機全体を「冷媒回路」「空気流路」「電力変換」「制御・通信」「筐体・保守」の5つに分けるのが現実的です。この5分類にすると、機械、制御、電気、品質、保守の担当者が自分の論点を見つけやすくなります。

この分け方は唯一の正解ではありません。目的が騒音低減なら空気流路と筐体を細かくし、目的がAI制御なら制御・通信とセンサを細かくします。重要なのは、モデルの粒度を設計課題に合わせることです。

対象範囲を決める

ブロック定義図を作る前に、<u>対象範囲</u>を明文化します。たとえば「業務用空調室外機の冷房運転における省エネ設計レビュー」を対象にするのか、「低GWP冷媒への変更影響」を対象にするのかで、必要なブロックは変わります。範囲を決めずに図を描くと、担当者ごとに期待する詳細度がずれます。

対象範囲は、要求、運転状態、境界、除外範囲の4点で書くと扱いやすくなります。要求はCOP、騒音、信頼性、点検性などです。運転状態は冷房、暖房、除霜、異常停止などです。境界は室外機単体なのか、室内機、リモコン、BEMSまで含めるのかです。除外範囲は、今回のレビューでは扱わない部品や現象です。

第一階層のブロック例

第一階層では、室外機を構成する大きな責務を表します。ここで「圧縮機」「熱交換器」だけを並べると、制御や保守の論点が見えにくくなります。逆に「冷媒回路」「空気流路」「制御・通信」のように責務で分けると、部品単位の検討に入る前にシステムとしての関係を確認できます。

たとえば冷媒回路ブロックは、圧縮機、熱交換器、膨張弁、配管を含みます。ただし、単に所有関係を書くのではなく、冷媒を圧縮する、放熱する、減圧する、蒸発させる、過熱度を維持する、保護停止条件へ影響する、といった責務をメモします。これにより、後で要求図やFMEAと接続しやすくなります。

空気流路ブロックでは、ファン、ベルマウス、熱交換器通風面、吹出口、据付周辺空間を扱います。ここで据付周辺空間を完全に外部扱いにすると、ショートサーキットや騒音反射の要求がモデルから抜けやすくなります。室外機そのものではない要素でも、性能に強く影響する外部条件は境界ブロックとして残します。

部品名ではなく責務を添える

ブロック名だけでは、設計意図は伝わりません。ブロック定義図には、各ブロックの責務、主要入力、主要出力、関係する要求を添えます。SysMLツール上ではプロパティ、ステレオタイプ、ノート、要求トレースとして管理できます。紙やホワイトボードで始める場合でも、責務を一文で書くだけでレビュー品質が上がります。

責務を書くときは、性能値を断定しすぎないことも大切です。詳細な数値は要求図や検証条件へ置き、ブロック定義図では「何に責任を持つか」「どの要求に関係するか」を示します。

要求・故障・検証とのつなぎ方

実務で価値が出るブロック定義図は、要求図、内部ブロック図、状態機械図、FMEA、検証計画へ接続されています。たとえば「騒音要求」は、ファン、筐体、熱交換器通風抵抗、制御回転数と関係します。「冷媒漏えい」は、配管、接合部、圧力センサ、保守点検、法規制要求と関係します。

ブロックから要求へ線を引くだけでは足りません。要求を満たすために、そのブロックがどの機能を担うのか、どの状態で問題になりやすいのか、どの故障モードを持つのか、どの試験で確認するのかをセットで整理します。

レビューで使うチェックリスト

ブロック定義図をレビューに出すときは、図の見た目よりも確認質問を用意します。以下のチェックは、初回モデルの品質確認に使えます。

• 室外機全体の境界が明確か
• 冷媒、空気、電力、信号、保守の流れが抜けていないか
• 主要ブロックに責務が書かれているか
• 要求IDと関係するブロックが追跡できるか
• 故障モードを持つブロックがFMEAへ接続されているか
• 運転状態によって責務が変わるブロックが見えているか
• センサと制御対象の関係が曖昧でないか
• 据付条件や保守作業など外部条件を無視していないか
• 詳細化が必要なブロックと、今は粗くてよいブロックを分けているか

レビューでは、全員が同じ粒度で図を読めるとは限りません。機械設計者は部品構造、制御設計者は信号と状態、品質保証は故障モード、保守担当は点検性を見ます。ブロック定義図は、その視点差を消すためではなく、視点差を並べて議論するために使います。

よくある失敗

一つ目の失敗は、部品表をそのままブロック定義図にすることです。部品表は購買、製造、管理には有効ですが、要求や故障との関係を表すには粒度が細かすぎることがあります。SysMLでは、<u>設計判断</u>に必要な責務でまとめる発想が必要です。

二つ目の失敗は、抽象化しすぎることです。「熱交換機能」「送風機能」「制御機能」だけを置くと、具体的な部品変更や故障モードへ落とし込めません。抽象ブロックと具体ブロックを分け、どちらの議論をしているのか明示します。

三つ目の失敗は、制御やセンサを後付けにすることです。空調室外機では、機械構造と制御は分離できません。除霜、保護停止、AI省エネ制御、BEMS連携は、センサ配置や冷媒回路の設計と結びついています。制御・通信ブロックを第一階層から置くことで、後工程の手戻りを減らせます。

モデルを更新し続ける運用

ブロック定義図は、初回レビューで作って終わりではありません。空調室外機では、冷媒変更、熱交換器変更、ファン仕様変更、インバータ変更、センサ追加、通信仕様変更、点検要求の変更が繰り返し発生します。変更のたびに部品表だけを更新し、ブロック定義図が古いまま残ると、モデルは設計判断の根拠として使えなくなります。

更新運用では、変更要求が出た時点で、影響するブロック、要求、状態、故障モード、検証項目を確認します。たとえばファンを変更する場合、空気流路ブロックだけでなく、騒音要求、消費電力、熱交換性能、ファンロック検出、制御回転数、据付条件、<u>試験条件</u>を見ます。冷媒を変更する場合は、冷媒回路、圧縮機、膨張弁、センサ、保護停止、法規制、保守点検を同時に見ます。

モデル更新の担当者も明確にします。機械設計が構造ブロックを更新し、制御設計が信号と状態を更新し、品質保証が故障モードと検証項目を確認する、という役割分担が必要です。更新責任が曖昧なモデルは、最初はきれいでもすぐに現実から離れます。

次に読むなら

次に読むなら、SysMLモデルとExcel仕様書をどのように使い分けるべきか がおすすめです。このテーマの全体像を整理する柱記事です。

関連記事

• 空調設計で活用するSysML図の優先順位：最初に習得すべき5種類: このテーマの全体像を整理する柱記事です。
• 空調機の仕様書をSysML要求図へ変換する方法: このテーマの全体像を整理する柱記事です。
• アクティビティ図で空調運転モードを表現する方法: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
• 空調室外機の主要構成要素をSysMLブロックで整理する: 隣接領域の記事として、部門間の影響やデータ要件までつなげて読めます。

まとめ

空調室外機のブロック定義図は、圧縮機や熱交換器を並べるだけの図ではありません。冷媒回路、空気流路、電力変換、制御・通信、筐体・保守という責務を整理し、要求、状態、故障、検証へつなぐための骨格です。

最初から完璧なモデルを作る必要はありません。まず対象範囲を決め、第一階層を5つ程度に分け、各ブロックに責務を添えます。その上で、要求図、IBD、状態機械図、FMEA、検証計画へつなげていくと、設計レビューで使えるSysMLモデルになります。