SysMLで空調制御仕様書を作成する際の注意点

この記事で分かること

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

空調制御仕様書は、要求、運転状態、センサ、アクチュエータ、保護、通信、ログ、<u>試験条件</u>をつなぐ重要な文書です。従来はExcelや文章で管理されることが多いですが、AI制御、BEMS連携、予兆診断、低GWP冷媒対応が入ると、項目の関係が複雑になります。SysMLを使うと、要求、状態、構造、処理、タイミング、故障モードをモデルとしてつなぎ、仕様書の抜け漏れを見つけやすくなります。

一方で、SysMLを使えば制御仕様書が自動的に良くなるわけではありません。図を増やしても、要求ID、条件、単位、優先順位、異常時動作、検証方法が曖昧なら、実装や試験で解釈が分かれます。SysMLは、仕様書の代替ではなく、仕様書の構造と根拠を明確にする道具として使うのが現実的です。

SysMLで空調制御仕様書を作る目的は、図を添えることではなく、要求・状態・制御・安全・検証の関係を追跡できるようにすることです。

目次

• 結論：仕様書項目をモデル要素へ対応付ける
• 要求を曖昧な言葉で残さない
• 運転状態と制御処理を分ける
• センサとデータ要件を明示する
• フェイルセーフと優先順位を書く
• AI制御を入れるときの注意点
• 検証条件までつなぐ
• よくある失敗

• まとめ

結論：仕様書項目をモデル要素へ対応付ける

SysMLを使った制御仕様書では、文章項目とモデル要素を対応付けます。たとえば「冷房運転時に室温が設定値を上回る場合、能力を増加させる」という文章だけでは、対象状態、入力データ、制御対象、制限条件、保護条件、検証方法が曖昧です。これを要求ID、状態機械図、アクティビティ図、IBD、シーケンス図、試験項目へ分けて追跡します。

要求を曖昧な言葉で残さない

空調制御仕様書では、「快適性を保つ」「省エネを優先する」「異常時は安全側に制御する」といった表現がよく使われます。これらは方向性としては有用ですが、そのままでは実装できません。SysML要求図では、要求を条件、対象、単位、優先順位、検証方法へ分解します。

たとえば「省エネを優先する」は、COP、年間消費電力量、ピーク電力、室温偏差、除霜頻度、騒音、復帰時間などのどれを指すのかで制御方針が変わります。AI制御を使う場合は、快適性や安全要求より省エネ指令が優先されないように、要求の優先順位を明記します。

運転状態と制御処理を分ける

制御仕様書で混乱しやすいのは、運転状態と処理手順が混ざることです。「冷房運転」「除霜運転」「異常停止」は状態です。一方、センサ取得、能力演算、指令出力、ログ記録は処理です。状態機械図とアクティビティ図を分けることで、状態遷移の抜け漏れと処理順序の抜け漏れを別々に確認できます。

運転状態には、通常運転だけでなく、準備、待機、能力制限、保護停止、復帰待ち、点検モードを入れます。特に空調機では、除霜準備、除霜実行、除霜復帰を一つの「除霜」にまとめると、制御切替のタイミングが曖昧になります。

センサとデータ要件を明示する

空調制御仕様書では、センサ名だけでは不十分です。どの状態量を、どの位置で、どの周期で、どの精度で、どの異常判定付きで取得するかを書きます。AI制御や予兆診断では、データの意味、欠測、タイムスタンプ、ログ保存期間も重要になります。

たとえば外気温センサは、能力演算、除霜判定、保護、AI推論に使われる可能性があります。同じセンサでも、用途によって必要な精度や更新周期が違います。SysMLでは、センサブロック、信号、要求、制御処理をつなぎ、どの用途で使うかを明確にします。

フェイルセーフと優先順位を書く

制御仕様書では、正常系より異常系の方が曖昧になりやすいです。AI制御やBEMS指令が省エネを狙って能力を制限しているときでも、保護要求、快適性、凍結防止、法規制、ユーザー操作の優先順位を明確にします。

フェイルセーフは「停止する」とだけ書くのでは不十分です。能力制限、従来制御への退避、外部指令無効化、手動復帰、再始動禁止、ログ記録、通知を分けて定義します。SysML要求図で優先順位を定義し、状態機械図とアクティビティ図で動作へ落とします。

AI制御を入れるときの注意点

AI制御を仕様書に入れる場合、モデル名やアルゴリズムだけを書いても不十分です。入力データ、推論周期、出力範囲、制限条件、説明ログ、フェイルセーフ、再学習方針を定義します。AIの判断は制御指令そのものではなく、制御判断に使う情報の一つとして扱う方が設計レビューしやすくなります。

AI制御では、学習データと実運用データの違いも問題になります。設計時に想定した外気条件、使用時間帯、建物負荷、在室人数と、実際の現場が違う場合、推論結果が期待どおりにならないことがあります。仕様書には、適用範囲、監視項目、退避条件、改善サイクルを入れます。

検証条件までつなぐ

SysMLで仕様書を作る最大の価値は、検証まで追跡できることです。要求だけ、状態だけ、制御だけを整理しても、試験条件につながらなければ設計品質は上がりません。各制御要求には、試験条件、合否基準、測定値、<u>ログ項目</u>、再現手順を紐づけます。

よくある失敗

一つ目の失敗は、SysML図を仕様書の飾りにしてしまうことです。図があっても、仕様書項目と要求ID、状態、処理、検証が対応していなければ、実務では追跡できません。

二つ目の失敗は、Excel仕様書をすべてSysMLに置き換えようとすることです。数値一覧、パラメータ、機種差分、試験結果はExcelや表形式の方が扱いやすい場合があります。SysMLは関係と構造を示し、Excelは詳細値を管理するという役割分担が現実的です。

三つ目の失敗は、AI制御を特別扱いしすぎることです。AIも制御システムの一部であり、入力、出力、制限、異常時動作、検証条件を持ちます。AIだからブラックボックスでよい、という扱いにすると、品質保証や保守で説明できなくなります。

仕様変更時に確認する影響範囲

制御仕様書は、初版より変更時の扱いで品質差が出ます。空調機では、圧縮機変更、センサ追加、冷媒変更、BEMS連携追加、AIモデル更新、保護しきい値変更などが起こります。変更項目だけをExcelで書き換えると、運転状態、データ要件、フェイルセーフ、検証条件との整合が崩れることがあります。

SysMLを使う場合は、変更要求から<u>影響範囲</u>をたどります。たとえば外気温センサの仕様を変えるなら、能力演算、除霜判定、AI推論、保護、ログ、試験条件に影響します。圧縮機の制御範囲を変えるなら、電流制限、騒音、COP、起動シーケンス、異常停止、再始動禁止時間を確認します。

変更レビューでは、変更前後の差分だけでなく「変えなかった理由」も残します。たとえばAI制御の入力を増やしたが保護判定は従来どおりにする、BEMS指令を追加したが高圧保護の優先順位は変えない、といった判断です。この記録があると、後工程でなぜその仕様になったのかを説明しやすくなります。

次に読むなら

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

関連記事

• シーケンス図で空調制御のタイミング課題を可視化する方法: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
• 空調機の仕様書をSysML要求図へ変換する方法: このテーマの全体像を整理する柱記事です。
• 空調AI制御を導入する前に整理すべき要求仕様: チェックリストやテンプレート化の入口として使いやすい記事です。
• 空調設計で活用するSysML図の優先順位：最初に習得すべき5種類: このテーマの全体像を整理する柱記事です。

まとめ

SysMLで空調制御仕様書を作る際の注意点は、図を増やすことではなく、仕様書項目とモデル要素を対応付けることです。要求、運転状態、処理手順、信号、タイミング、故障時動作、検証条件をつなぐことで、設計レビューで抜け漏れを見つけやすくなります。

Excelや文章仕様書は不要になりません。むしろ、SysMLで関係を整理し、Excelで詳細値を管理し、試験計画で検証するという組み合わせが実務的です。空調制御がAI、BEMS、予兆診断へ広がるほど、この追跡性が重要になります。