空調設計における要求定義の失敗事例とSysMLによる防止策

この記事で分かること

• 空調設計でMBSE/SysMLを使う目的
• 要求・構造・制御・検証をつなぐ考え方
• 設計レビューで最初に確認すべき論点

空調設計の手戻りは、詳細設計や試験だけで発生するわけではありません。多くは要求定義の段階で、性能、騒音、快適性、制御、安全、保守、法規制の前提が曖昧なまま進むことで起きます。後工程で「その条件ではCOPを満たせない」「除霜時の快適性が想定外だった」「AI制御の停止条件が決まっていない」と分かると、部品選定、制御仕様、試験計画まで戻ることになります。

SysML要求図は、要求を文章から図に置き換えるためだけのものではありません。要求の親子関係、派生、検証方法、制約、構造要素との関係を見えるようにし、曖昧な要求を<u>設計判断</u>に使える単位へ分解するための道具です。

要求定義の失敗は、要求が少ないことより、条件・単位・検証方法・責任範囲が曖昧なまま合意されることで起きます。

目次

• 結論：要求は性能値だけでなく前提条件まで定義する
• 失敗事例1：COP要求の条件が曖昧
• 失敗事例2：騒音要求が構造設計へ落ちない
• 失敗事例3：除霜や異常停止が後回しになる
• 失敗事例4：AI制御の責任範囲が決まらない
• SysMLで防ぐ要求分解の手順
• 要求レビュー用チェックリスト
• 要求定義を設計レビューへ接続する運用
• まとめ

結論：要求は性能値だけでなく前提条件まで定義する

空調設計で要求定義を安定させるには、要求を「<u>何を満たすか</u>」だけでなく、「どの条件で、どの単位で、どう確認し、誰が責任を持つか」まで分解します。たとえばCOP要求であれば、目標値だけでなく、外気温、室内条件、運転モード、定格か中間負荷か、測定方法、評価対象範囲を明確にします。

SysML要求図では、これらを要求属性として扱い、構造要素、状態機械図、FMEA、試験項目へつなぎます。

失敗事例1：COP要求の条件が曖昧

COP要求は、空調設計で最も分かりやすいようで、実は失敗しやすい要求です。「COPを高める」「省エネ性能を向上する」といった表現だけでは、設計者は何を優先すべきか判断できません。定格条件を優先するのか、中間負荷での実使用効率を重視するのか、低外気暖房や高外気冷房まで含めるのかで、設計解は変わります。

SysMLでは、上位要求「省エネルギー性能」から、定格COP、中間負荷効率、制御応答、センサデータ、検証条件へ分解します。さらに、圧縮機、熱交換器、膨張弁、ファン、制御基板へ割り当てます。

失敗事例2：騒音要求が構造設計へ落ちない

騒音要求は、数値だけでは設計に落ちません。測定距離、運転条件、周波数帯、音質、筐体振動、ファン回転数、配管共振などが関係します。要求定義でこれらを分けていないと、試験で騒音NGになった後に、ファン、筐体、圧縮機マウント、制御回転数のどれを修正すべきか判断しにくくなります。

SysML要求図からBDDやIBDへつなぐことで、騒音要求がどの構造要素に影響するかを可視化できます。騒音は機械設計だけの問題ではなく、制御仕様とも密接に関係します。

失敗事例3：除霜や異常停止が後回しになる

冷房定格や暖房定格は初期から議論されやすい一方、除霜、異常停止、復帰、保守中の扱いは後回しになりがちです。しかし実機では、これらの状態が快適性、信頼性、サービス性に大きく影響します。除霜開始条件が曖昧だと、暖房能力の低下やユーザー不満につながります。異常停止の復帰条件が曖昧だと、安全側に倒せない可能性があります。

要求図だけでなく、状態機械図を早期に作ると、抜けやすい状態が見えます。要求定義段階で状態名をそろえることが、制御仕様とFMEAの品質を上げます。

失敗事例4：AI制御の責任範囲が決まらない

AI省エネ制御では、要求定義の曖昧さがさらに大きな問題になります。AIが何を入力し、何を出力し、どの範囲まで指令でき、どの条件で停止するのかを決めないままPoCを始めると、現場導入時に安全、説明責任、保守対応で詰まります。

SysMLでは、AI制御を単独の箱にせず、従来制御、保護ロジック、状態機械、センサデータと接続します。AIの自由度を定義することが、導入の現実性を高めます。

SysMLで防ぐ要求分解の手順

要求定義の失敗を防ぐには、次の順に進めます。

最初から完全なモデルを作る必要はありません。COP、騒音、除霜、安全停止、AI制御停止など、手戻りになりやすい要求から始める方が実務では定着しやすくなります。

要求レビュー用チェックリスト

• 要求に条件、単位、目標値、検証方法があるか
• 「高効率」「静音」「快適」などの曖昧語を分解したか
• 要求が構造要素や制御要素へ割り当てられているか
• 除霜、異常停止、保守中、手動運転の要求があるか
• AI制御の入力、出力、制約、停止条件が明確か
• 法規制や安全に関わる要求の適用範囲を確認したか
• FMEA、試験計画、運転ログと接続できるIDがあるか
• 既存機種との差分が要求へ反映されているか

要求定義を設計レビューへ接続する運用

要求定義は、仕様書を完成させた時点で終わりではありません。要求がレビューで使われ、設計変更時に更新され、試験結果で妥当性を確認される状態にしておく必要があります。空調設計では、要求、制御仕様、FMEA、試験表が別々に管理されやすいため、最初に接続ルールを決めます。

特に有効なのは、要求レビューで「この要求はどの図、どの部品、どの状態、どの試験で確認するのか」と質問することです。答えられない要求は、まだ設計判断に使える粒度ではありません。逆に、構造や制御側から見て「この部品変更はどの要求を変えるのか」と戻れる状態なら、要求定義は後工程でも機能します。

要求定義の運用を始めるときは、全要求を一気に厳密化する必要はありません。まずはCOP、騒音、除霜、安全停止、冷媒漏えい、AI制御停止など、手戻りや安全影響が大きい要求を優先します。そこからID体系、属性、検証対応表を広げていくと、現場負荷を抑えながら定着させられます。

次に読むなら

次に読むなら、空調設計にMBSEが必要になる理由：メカ設計だけでは解決できない時代へ がおすすめです。このテーマの全体像を整理する柱記事です。

関連記事

• SysMLで空調システムを設計するとは何か？初心者向けに実務視点で解説: このテーマの全体像を整理する柱記事です。
• 空調メーカーにおけるMBSE導入の第一歩: このテーマの全体像を整理する柱記事です。
• 空調室外機をSysMLでモデル化する基本手順: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
• CAD中心設計とSysML中心設計の違いを実務視点で比較する: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。

まとめ

空調設計における要求定義の失敗は、要求の数が不足していることより、要求の前提が曖昧なまま合意されることで起きます。COP、騒音、除霜、異常停止、AI制御、保守性は、数値だけでなく条件、単位、検証方法、<u>責任範囲</u>まで分解する必要があります。

SysML要求図を使うと、上位要求から構造、状態、制御、センサ、FMEA、試験計画までつなげられます。要求定義の段階でこのつながりを作っておくことで、後工程の手戻りを減らし、設計レビューの議論を具体化できます。