空調機の仕様書をSysML要求図へ変換する方法
この記事で分かること
- SysML図を実務で使い分ける判断基準
- 要求図、BDD、IBD、状態機械図の役割
- モデルを設計レビューへ接続する手順
空調機の仕様書には、冷房能力、暖房能力、COP、騒音、外形、重量、電源、保護機能、点検、据付条件など、多くの要求が文章で書かれています。しかし文章仕様のままでは、要求の重複、条件の不足、検証方法の未定義、部門間の解釈違いが起きやすくなります。
SysML要求図へ変換する目的は、仕様書を図に置き換えることではありません。要求を分解し、条件、根拠、関係する構造、状態、検証方法を追えるようにすることです。特に空調機では、同じ「能力要求」でも、定格条件、中間負荷、低外気、除霜復帰、異常時で意味が変わります。
この記事では、既存の空調機仕様書をSysML要求図へ変換する手順を、実務レビューで使える粒度で整理します。
仕様書は、数値を写すだけでなく条件と検証方法まで分解してから図にします。
結論：仕様書は要求ID、条件、検証方法に分解してから図にする
仕様書をSysML要求図へ変換するときは、文章をそのまま箱に入れてはいけません。まず、要求ID、要求文、条件、根拠、関連ブロック、関連状態、検証方法に分解します。そのうえで、上位要求と下位要求の関係を図にします。
| 変換前の仕様書 | 変換後の要求情報 | 確認すること |
|---|---|---|
| 定格冷房能力を満たすこと | REQ-PERF-001、条件、判定基準 | 外気温、室内条件、電源条件 |
| 低騒音であること | REQ-NOISE-001、運転状態、測定方法 | 定格、夜間、起動停止を分ける |
| 異常時は安全に停止すること | REQ-SAFE-001、停止条件、復帰条件 | センサ異常、圧力異常、過電流 |
| 保守しやすいこと | REQ-MAINT-001、点検作業、アクセス性 | 現場作業、記録、法定点検 |
要求図は、変換作業の最後に描くと失敗しにくくなります。先に要求の粒度と属性を整え、その結果を図に展開する方が、レビューで使えるモデルになります。
手順1：仕様書を要求候補として抽出する
最初に、仕様書の文章をすべて要求候補として拾います。この時点では、完全な要求に直そうとしなくて構いません。性能、制御、構造、法規制、信頼性、施工、保守、表示、試験など、要求らしい文を抜き出します。
抽出時に重要なのは、「数値がある文だけを要求と見なさない」ことです。空調機では、異常時の保護、点検性、冷媒漏えい管理、施工条件、騒音、振動、AI制御のデータ要件など、数値化しにくいが重要な要求があります。
| 仕様書の記述 | 要求候補として見る観点 |
|---|---|
| 冷房能力、暖房能力、COP | 性能要求、試験条件、運転範囲 |
| 騒音、振動、外形、重量 | 構造要求、設置要求、輸送要求 |
| 保護停止、異常表示、復帰 | 安全側動作、診断、ユーザー通知 |
| 冷媒、点検、記録 | 法規制、保守、運用要求 |
| 通信、センサ、ログ | AI制御、BEMS連携、保全DX |
抽出した要求候補には、元の仕様書の章番号やページを残しておきます。後で図にしたとき、元文書へ戻れることが重要です。
手順2：要求をカテゴリ別に分ける
要求候補を抽出したら、カテゴリで分けます。カテゴリを先に決めると、要求漏れを見つけやすくなります。空調機では、少なくとも性能、制御、構造、保護、信頼性、環境、保守、検証に分けると扱いやすくなります。
| カテゴリ | 要求例 | 関係する担当 |
|---|---|---|
| 性能 | 能力、COP、消費電力、運転範囲 | 冷凍サイクル、制御 |
| 制御 | 過熱度制御、除霜、AI予測制御 | 制御、ソフト、データ |
| 構造 | 外形、重量、筐体、配管、熱交換器 | 機械設計、製造 |
| 保護 | 高圧、低圧、過電流、センサ異常 | 制御、品質、安全 |
| 信頼性 | 耐久、腐食、振動、冷媒漏えい | 品質保証、試験 |
| 保守 | 点検、記録、アクセス、交換性 | サービス、設備管理 |
| 検証 | 試験条件、判定、測定方法 | 試験、品質保証 |
カテゴリ分けは、SysML要求図の上位階層にも使えます。ただし、カテゴリを縦割りにしすぎると、COPと騒音、重量と信頼性、AI制御と保護の関係が見えにくくなります。要求図では、階層に加えて依存関係も表します。
手順3：曖昧な表現を設計判断に使える形へ直す
仕様書には、「十分な能力」「低騒音」「適切に制御」「容易に点検」のような曖昧な表現が残りがちです。これらは上位要求として残してもよいですが、下位要求では<u>設計判断</u>に使える形へ直す必要があります。
変換の観点は、条件、対象、判定、検証です。
| 曖昧な表現 | 変換時の問い | 下位要求の例 |
|---|---|---|
| 高効率である | どの条件で、何をもって効率とするか | 定格冷房条件でCOP目標を満たす |
| 静かである | どの運転状態で、どの測定方法か | 夜間モードで騒音上限を満たす |
| 安全に停止する | 何を検知し、どう停止し、どう復帰するか | 高圧検知時に圧縮機を停止し復帰条件を満たすまで再起動しない |
| 保守しやすい | 誰が、何を、何分で確認するか | 点検口から指定センサへアクセスできる |
ここで無理にすべてを数値化する必要はありません。重要なのは、レビューで「これをどう満たすか」「どう確認するか」を議論できる粒度にすることです。
手順4：SysML要求図で階層と関係を表す
要求の属性が整ったら、SysML要求図へ展開します。上位要求、下位要求、派生要求、検証、設計要素との関係を表します。要求図では、階層関係だけでなく、要求同士の衝突や依存を見えるようにすることが重要です。
たとえば、COP要求は熱交換器、圧縮機、ファン、膨張弁制御に関係します。一方で、騒音要求はファン回転数や筐体構造に関係し、COP要求と衝突する場合があります。重量要求は熱交換器や筐体へ影響し、信頼性や振動にも関係します。
| 関係 | SysML上の意味 | 空調機での例 |
|---|---|---|
| containment | 上位要求と下位要求 | 性能要求の下にCOP、能力、消費電力 |
| deriveReqt | 派生要求 | COP要求から熱交換器性能要求を派生 |
| satisfy | 構造が要求を満たす | 室外熱交換器が放熱性能要求を満たす |
| verify | 試験や解析で確認する | 能力試験で冷房能力要求を検証 |
| trace | 根拠や関連を追う | 法規制、顧客要求、FMEA項目へ追跡 |
要求図は、1枚で全要求を表そうとしない方がよいです。性能要求図、保護要求図、保守要求図、AI制御要求図のように分け、上位図で全体を示します。
手順5：構造、状態、検証へつなげる
要求図だけでは、まだ設計判断には不足します。要求がどのブロックで満たされ、どの状態で有効になり、どの検証で確認されるかを接続します。
| 要求ID | 関連ブロック | 関連状態 | 検証方法 | 注意点 |
|---|---|---|---|---|
| REQ-COP-001 | 圧縮機、熱交換器、ファン | 定格、低負荷 | 性能試験、1D解析 | 試験条件を固定する |
| REQ-DEF-001 | 熱交換器、四方弁、制御器 | 除霜、復帰 | 除霜試験 | 快適性と保護を同時に見る |
| REQ-SAFE-001 | センサ、制御器、圧縮機 | 異常停止 | 異常注入試験 | 復帰条件を明記する |
| REQ-MAINT-001 | 筐体、点検口、センサ | 停止、点検 | 作業確認 | 現場条件を考慮する |
この表を作ると、仕様書の要求が図だけで終わらず、BDD、IBD、状態機械図、試験計画、FMEAへ接続できます。AI制御を扱う場合は、要求IDに対して必要なセンサデータ、データ品質、欠損時の扱い、フェイルセーフも追加します。
変換レビュー用チェックリスト
- 仕様書の章番号や元文へ戻れるようにしたか。
- 数値要求だけでなく、保護、保守、診断、点検要求も抽出したか。
- 要求ID、条件、判定基準、検証方法を付けたか。
- 曖昧な表現を、設計判断に使える下位要求へ分解したか。
- COP、騒音、重量、信頼性の衝突関係を見たか。
- 要求が関連ブロック、運転状態、検証ケースへつながっているか。
- AI制御で使うデータ要求とフェイルセーフ要求を分けたか。
よくある失敗
仕様書変換でよくある失敗は、既存文書をそのままSysMLツールへ貼り付けることです。これでは要求図が文章の倉庫になり、レビューで使えません。要求は短く、条件と属性は表で補い、関係を図で示す方が実務向きです。
| 失敗 | 起きること | 対策 |
|---|---|---|
| 文章をそのまま要求にする | 図が読みにくく、粒度がそろわない | 要求ID、条件、検証に分解する |
| 性能要求だけを抽出する | 保護、保守、品質が抜ける | カテゴリ別に抽出する |
| 検証を後で決める | 試験計画と要求が切れる | 要求作成時点でverify関係を置く |
| 1枚の図に全要求を入れる | レビューで使えない | 目的別の要求図に分ける |
| AI制御を通常制御と混ぜる | データ要求と安全要求が曖昧になる | データ、判断、制限、停止を分ける |
次に読むなら
次に読むなら、空調システムの要求図を作成する方法：COP、騒音、重量、信頼性の整理 がおすすめです。このテーマの全体像を整理する柱記事です。
関連記事
- 空調設計で活用するSysML図の優先順位：最初に習得すべき5種類: このテーマの全体像を整理する柱記事です。
- 内部ブロック図で冷媒・空気・電力・信号の流れを整理する方法: このテーマの全体像を整理する柱記事です。
- 冷凍サイクルをSysMLで表現する方法：要求・機能・構造の整理手法: 次に読むと、要求から構造・制御・検証へ論点を進めやすくなります。
- 状態機械図で冷房・暖房・除霜・異常停止をモデル化する: 次に読むと、要求から構造・制御・検証へ論点を進めやすくなります。
まとめ
空調機の仕様書をSysML要求図へ変換するには、文章をそのまま図にするのではなく、要求ID、条件、根拠、関連ブロック、関連状態、検証方法へ分解することが重要です。要求候補を抽出し、性能、制御、構造、保護、信頼性、保守、検証のカテゴリへ分けると、漏れを見つけやすくなります。
曖昧な表現は、設計判断に使える下位要求へ直します。COP、騒音、重量、信頼性のような要求は互いに衝突するため、階層だけでなく依存関係も表します。要求図を作ったら、BDD、IBD、状態機械図、検証ケース、FMEAへ接続します。
この変換ができると、仕様書は単なる文書ではなく、設計レビュー、試験計画、AI制御データ要件、品質保証へつながるモデルになります。SysML要求図は、仕様書を置き換えるためではなく、仕様書の要求を設計判断に使える形へ整理するために使うのが現実的です。
次に読む記事としては、次の3本が自然です。
- 空調システムの要求図を作成する方法：COP、騒音、重量、信頼性の整理
- 内部ブロック図で冷媒・空気・電力・信号の流れを整理する方法
- SysML要求図からFMEA項目を抽出する方法
コメント