ホーム » 空調MBSE入門 » SysMLで空調システム設計を始める方法：初心者向けに要求・機能・構造を解説

SysMLで空調システム設計を始める方法：初心者向けに要求・機能・構造を解説

SysMLで空調システムを設計するとは何か 空調MBSE入門
2026.06.04

SysMLで空調システムを設計するとは何か

この記事で先に決めること

  • SysMLと空調システム設計の関係
  • 要求図・BDD・IBD・状態機械図の役割
  • 初心者が設計レビューへ持ち込める最小モデル

目次

  • 結論：SysMLは設計情報の関係を表す言語
  • 空調システムでSysMLが効く理由
  • 最初に整理する5つの要素
  • 空調機をSysMLで見る具体例
  • 図法より先に決めるべきこと
  • 初心者がつまずきやすいポイント
  • 設計レビューでの使い方
  • 実務例：室外機の仕様変更を小さくモデル化する
  • 参考資料・まとめ

SysMLで空調システムを設計するときは、いきなり図法を選ぶのではなく、まず満たす要求とシステム境界を定め、機能・構造・状態・検証へ順に分解します。

SysMLで空調システムを設計すると聞くと、「専用ツールで複雑な図を描くこと」と考えてしまう人が多いかもしれません。実際には、SysMLの本質は図を増やすことではありません。空調機に求められる要求、機能、構造、運転状態、検証方法をつなぎ、設計判断を説明できる状態にすることです。

SysMLで空調システムを設計する目的は、図を増やすことではなく、要求・構造・制御・検証の関係を追えるようにすることです。

空調機は、圧縮機、熱交換器、膨張弁、ファン、センサ、制御基板、筐体、冷媒配管、通信機能などが組み合わさって性能を出します。どれか一つの部品だけを最適化しても、冷暖房能力、COP、騒音、信頼性、快適性、保守性、安全性が同時に満たされるとは限りません。 特にAI省エネ制御や異常診断を扱う場合、データ要件やフェイルセーフも設計対象になります。

この記事では、SysMLを初めて学ぶ空調設計者、制御設計者、品質保証担当、MBSE導入担当者に向けて、「SysMLで設計する」とは何を意味するのかを実務目線で整理します。

結論：SysMLは設計情報の関係を表す言語

SysMLは、Systems Modeling Languageの略です。複数の要素が関係し合う製品や仕組みを、要求、構造、振る舞い、制約、検証の観点から表すための言語です。

空調設計で重要なのは、SysMLを「清書用の図」として扱わないことです。設計レビューで役立つSysMLモデルは、きれいな図よりも、次の問いに答えられるモデルです。

  • この要求は、どの機能で実現するのか
  • その機能は、どの部品や制御ロジックが担うのか
  • 運転状態が変わったとき、どの条件で切り替わるのか
  • 異常時やセンサ故障時は、どの安全側動作に落とすのか
  • 要求を満たしたことを、どの試験や解析で確認するのか

例えば「暖房運転中の快適性を維持する」という要求があるとします。この要求だけでは、設計者ごとに解釈が変わります。SysMLでは、これを暖房能力、除霜復帰時間、室温低下許容、圧縮機保護、ファン制御、センサ要件、試験条件へ分解し、関係をたどれるようにします。

つまり、SysMLで設計するとは、空調機の設計情報を「文章のまとまり」ではなく「関係のネットワーク」として扱うことです。これにより、変更影響を追いやすくなり、部門間の認識齟齬を減らせます。

なお、OMGの現行正式仕様はSysML 2.0です。一方、要求図、BDD、IBDなど本記事で使う呼び方はSysML v1系の実務で広く使われてきたものです。OMGもv1からv2への移行期間を想定しています。プロジェクト開始時に「採用する仕様版、ツール版、交換形式」を構成管理項目として固定し、v1とv2の要素名や意味を無意識に混在させないでください。

SysMLは設計情報の関係を表す

空調システムでSysMLが効く理由

空調機は、物理現象と制御ロジックが強く結びついたシステムです。冷媒の圧力、温度、流量、熱交換、風量、霜付き、騒音、振動、電力、センサ応答は、それぞれ別々に見えても運転結果では一体になります。

例えば、室外機ファンの回転数を下げれば騒音は下がるかもしれません。しかし熱交換性能が落ち、圧縮機の運転点が変わり、消費電力や保護制御に影響する可能性があります。除霜制御を短くすれば快適性は上がるように見えても、霜の残り方によって暖房能力や長期信頼性に影響することがあります。

従来の設計では、こうした関係がExcel仕様書、CAD図面、制御仕様書、試験報告書、FMEA、議事録に分散しがちです。設計変更、担当交代、量産移行、市場不具合対応の場面では、なぜその判断に至ったのかを追うのが難しくなります。

SysMLは、この分散した設計情報を一つの巨大な図にまとめるためのものではありません。観点ごとに図を分けながら、同じ要求や構成要素を参照できるようにするためのものです。

場面従来起きやすい問題SysMLでできること
要求定義COPや騒音などの数値要求だけが先行する要求を機能、構造、検証へつなげる
制御設計例外条件が後から増える状態と遷移条件を早期に整理する
設計変更影響範囲を経験者が探す変更対象から関連要求を追跡する
FMEA帳票作成が後工程になる機能と構造から故障モードを抽出する
AI制御PoC精度だけで議論されるデータ要件と安全要求を明確にする

最初に整理する5つの要素

初心者がSysMLを始めるときは、すべての図法を覚えるよりも、何をつなぐのかを先に理解する方が実務に役立ちます。空調システムでは、まず次の5つを整理します。

要素空調での例確認したいこと
要求冷房能力、暖房能力、COP、騒音、信頼性何を満たす必要があるか
機能圧縮する、熱交換する、送風する、検知する要求を実現する働きは何か
構造圧縮機、熱交換器、膨張弁、ファン、センサ機能を担う要素は何か
振る舞い冷房、暖房、除霜、保護停止、復帰状態と切替条件は何か
検証性能試験、騒音試験、異常注入試験要求を満たした根拠は何か

この5つをつなぐだけでも、設計レビューの質は変わります。「この部品で大丈夫か」ではなく、「この要求に対して、この機能分担で足りるか」「この状態遷移で異常時の逃げ道があるか」と議論できるからです。

要求は「高効率」「静か」「すぐ復帰」のような形容詞で止めず、少なくとも対象、運転条件、判定量、単位、許容値、検証方法を一組にします。数値は製品仕様・適用規格・試験標準により異なるため、次表の値は規格値ではなく書式例です。

要求ID曖昧な表現検証可能な書き方の例証拠
`REQ-H-01`低外気温でも暖かい対象機種・定格電圧・外気乾球温度・室内条件を固定し、暖房能力を`kW`で判定する校正記録付き能力試験ログ
`REQ-D-02`除霜後すぐ戻る除霜終了イベントから室内吹出温度が社内閾値へ復帰するまでを`s`または`min`で判定する状態遷移ログと温度時系列
`REQ-N-03`騒音を抑える運転モード、測定点、暗騒音補正、評価量を固定し、`dB`で判定する試験条件表、測定器校正記録
`REQ-F-04`センサ故障でも安全対象故障を断線・短絡・固着・偏差に分け、検出時間`s`、退避状態、復帰条件を定義する故障注入結果とイベントログ

ISO/IEC/IEEE 29148は要求工学のプロセスと情報項目を扱いますが、個別空調機の性能値を決める規格ではありません。値そのものは、対象市場の法規・製品規格・顧客仕様・社内試験標準から導きます。

空調SysMLで最初に整理する5つの要素

空調機をSysMLで見る具体例

ここでは、寒冷地向け空調機の暖房運転を例にします。上位要求を「低外気温でも暖房性能と快適性を維持する」と置くと、SysMLでは次のように分解できます。

上位要求下位要求関係する機能関係する構造検証方法
低外気温でも暖房性能を維持する所定条件で暖房能力を満たす冷媒を圧縮する、熱交換する圧縮機、室外熱交換器、室内熱交換器低外気温暖房試験
低外気温でも快適性を維持する除霜後の復帰時間を抑える霜を検知する、除霜へ切り替えるセンサ、四方弁、制御基板除霜復帰試験
機器を保護する過電流や高圧異常を防ぐ異常を検知する、安全側へ停止するインバータ、圧力センサ、制御基板異常注入試験
省エネ運転を行う負荷に応じて能力を調整する回転数を制御する、風量を調整する圧縮機、ファン、温度センサ部分負荷試験

この表をSysMLの図に置き換えると、要求図では上位要求と下位要求を整理し、ブロック定義図では圧縮機や熱交換器などの構成要素を整理します。内部ブロック図では冷媒、空気、電力、信号の流れを分けて表し、状態機械図では暖房、除霜、復帰、異常停止の条件を表します。

重要なのは、図を別々に描いて終わりにしないことです。要求図にある「除霜後の復帰時間」は、状態機械図の「除霜から暖房への復帰条件」と関係します。内部ブロック図にある温度センサは、除霜判定や異常検知の入力になります。

この関係が見えると、設計変更の影響も追いやすくなります。例えば温度センサの位置を変える場合、部品配置だけでなく、除霜判定、異常検知、試験条件まで確認する必要があると分かります。

図法より先に決めるべきこと

SysMLを学び始めると、図法の多さに圧倒されます。しかし実務導入では、図法の暗記よりも先に決めるべきことがあります。

第一に、モデル化する目的です。設計変更の影響を見たいのか、要求定義を強くしたいのか、制御仕様の抜け漏れを減らしたいのか、FMEAとつなげたいのかで、必要な図は変わります。

第二に、対象範囲です。室外機全体をいきなり対象にすると、モデルが大きくなりすぎます。初心者は、除霜制御、騒音要求、AI省エネ制御など、手戻りが多いテーマを一つ選ぶのが現実的です。

第三に、粒度です。部品表の細かさで全要素を入れると、図は読みにくくなります。一方で粗すぎると、設計レビューに使えません。最初は「設計判断に必要な粒度」を基準にします。

第四に、更新責任です。SysMLモデルは作って終わりではありません。仕様変更、試験結果、FMEA更新に合わせて直す必要があります。誰が、どのレビューで更新するかを決めないと、モデルはすぐに古くなります。

初心者がつまずきやすいポイント

SysML初心者が最初につまずくのは、記法そのものではなく、設計情報をどう抽象化するかです。

つまずき起きること対策
図をきれいに描くことが目的になるレビューで使われない資料になる判断したい問いを先に書く
部品表をそのまま写す機能や要求との関係が見えない部品名の前に機能を洗い出す
すべてを一枚に入れる図が複雑で読まれない要求、構造、状態で図を分ける
制御例外を後回しにする異常時の仕様が抜けるセンサ異常、通信断、停電復帰を入れる
検証とつながらないモデルが説明資料で止まる要求ごとに確認方法を紐づける

特に空調設計では、正常運転だけをモデル化すると不十分です。除霜、保護停止、センサ異常、通信異常、停電復帰、AI制御無効時のフォールバックまで、品質に効く状態を入れる必要があります。

また、SysMLを専門担当だけの活動にしないことも大切です。メカ設計者だけでは制御の例外条件が抜け、制御担当だけでは熱交換や冷媒回路の制約が薄くなります。SysMLは、各専門の判断をつなぐ場として使う方が効果的です。

設計レビューでの使い方

SysMLモデルは、完成後に見せる資料ではなく、設計レビューの議論を整えるために使うと効果があります。レビューでは、次の順番で確認します。

SysMLモデルを使った設計レビューの流れ

1. 上位要求は具体的な下位要求へ分解されているか 2. 各要求に対応する機能が抜けていないか 3. 機能を担う構造要素が明確か 4. 冷媒、空気、電力、信号の流れに矛盾がないか 5. 正常状態だけでなく異常状態も整理されているか 6. 要求ごとに検証方法があるか 7. 設計変更時に影響を受ける範囲が追えるか

例えば、AI省エネ制御を追加するレビューでは、AIモデルの精度だけを見ても不十分です。入力データのセンサ位置、データ周期、欠損時の扱い、従来制御へのフォールバック、異常時の責任分界を確認します。

設計レビューの最後には、「この要求に検証方法がない」「この状態遷移の条件が曖昧」「このセンサ異常時の動作が未定」といった未決事項を、次のアクションに落とします。

最小モデルを「一本の証拠鎖」にする

初心者が最初に完成させるべき成果物は、図のセットではなく、重要要求1件を端から端まで追える証拠鎖です。例えば除霜復帰なら、次の順で同じIDを参照できるようにします。

`利用者期待 → REQ-D-02 → 霜検知・除霜・復帰機能 → 温度センサ・四方弁・圧縮機・ファン → 暖房/除霜/復帰/保護状態 → センサ故障モード → 取得データ → 試験ケース → 判定結果`

接続レビュー質問接続が切れたときの実害
要求→機能この機能がなくても要求を満たせるか不要機能または要求漏れを見逃す
機能→構造誰がその機能を実行するか責任分界とインターフェースが曖昧になる
構造→状態・制御どの状態で、どの入力から、何を指令するか例外遷移や競合指令が抜ける
状態→故障センサ固着、通信断、アクチュエータ不応答をどう検知するか正常系だけのモデルになる
要求→検証合否をどの条件、単位、ログで判定するか「試験したが要求を証明できない」状態になる

NASA Systems Modeling Handbookは、SysMLモデルとステークホルダー期待、技術要求、V&Vの成果物をつなぐ公開例です。航空宇宙向け手引きを空調製品へそのまま適用するものではありませんが、「図ではなくSE成果物をつなぐ」という導入原則は参考になります。

実務例：室外機の仕様変更を小さくモデル化する

たとえば室外機ファンを変更する場合、形状や取付だけでなく、騒音要求、熱交換性能、消費電力、異常時の保護、保守交換性まで影響します。最初はファン、熱交換器、制御基板、騒音要求、性能試験だけを対象にし、要求IDと検証条件を対応させます。

確認項目レビューで見ること
対象機種と対象状態を一つに絞る例：寒冷地向け室外機の暖房・除霜運転
要求IDを付けて設計要素へ接続する`HVAC-REQ-DF-01`をファン、センサ、制御へ追跡する
試験条件とログ項目を同じ表に置く外気温、回転数、吐出温度、復帰時間を対応させる
未決事項を責任部門付きで残す制御、機械、試験、品質の担当と期限を残す

この例のポイントは、SysMLの図法を増やすことではありません。室外機ファンの変更を起点に、要求、状態、センサ、検証ログへ影響をたどれる最小モデルを作ることです。

変更レビューでは、変更前後の値だけでなく、影響先と再検証要否を記録します。

ファン変更の影響先確認する量・条件再検証の判断
熱交換風量`m³/s`、入口出口温度`°C`、能力`kW`風量・熱交換器・制御点のいずれかが変われば実施
騒音・振動回転数`min⁻¹`、評価量`dB`、共振帯域`Hz`翼形状、回転数範囲、支持条件が変われば実施
制御指令上限、ランプ率、停止判定、再起動条件ドライバまたは回転数域が変われば状態遷移を再確認
故障・保護ロック、回転数不一致、過電流、温度上昇検出閾値・検出時間・退避動作が変われば故障注入
保守交換手順、誤組付け防止、部品識別互換性やコネクタが変われば作業検証

設計レビュー用チェックリスト

  • [ ] システム境界と外部アクターが定義されている
  • [ ] 重要要求にID、条件、単位、合否基準、根拠がある
  • [ ] 要求が機能、構造、状態、故障モード、検証へ追跡できる
  • [ ] 冷媒・空気・電力・信号の流れと責任境界が区別されている
  • [ ] 正常、停止、除霜、保護、故障、復帰の遷移条件が相互排他的か確認した
  • [ ] 試験ログの信号名、単位、周期、時刻基準がモデルと一致する
  • [ ] 未決事項に責任者、期限、閉鎖条件がある
  • [ ] 仕様版・ツール版・モデル版が構成管理されている

参考資料・確認先

規格本文の適用可否や合否値は、対象製品、市場、契約、社内標準ごとに確認してください。本記事は規格適合や安全性を保証するものではありません。

次に読むなら

次に読むなら、空調メーカーにおけるMBSE導入の第一歩 がおすすめです。このテーマの全体像を整理する柱記事です。

関連記事

まとめ

SysMLで空調システムを設計するとは、空調機を図としてきれいに描くことではありません。要求、機能、構造、振る舞い、検証をつなぎ、設計判断を説明できる状態にすることです。

空調機は、冷凍サイクル、熱交換、送風、騒音、電力、制御、センサ、異常診断、AI制御、保守が一体になって価値を出します。そのため、部品単体の最適化だけではなく、要求から検証までを一貫して見られる仕組みが必要です。

初心者は、まず全体を完璧にモデル化しようとせず、手戻りが多いテーマを一つ選びましょう。除霜制御、騒音要求、圧縮機保護、AI省エネ制御などを対象に、要求、機能、構造、状態、検証を表でつなぐところから始めると、SysMLの価値を実感しやすくなります。

次に読む記事としては、次の3本が自然です。

  • 空調室外機をSysMLでモデル化する基本手順
  • 空調設計で活用するSysML図の優先順位：最初に習得すべき5種類
  • 空調システムの要求図を作成する方法：COP、騒音、重量、信頼性の整理

コメント

タイトルとURLをコピーしました