アクティビティ図で空調運転モードを表現する方法
この記事で分かること
- 具体的なSysML図の作り方
- 空調設計で見落としやすい接続・状態・制約
- 仕様書、試験、レビューへ展開する方法
空調制御をSysMLで表現するとき、状態機械図だけを使うと「冷房」「暖房」「除霜」「異常停止」の切り替わりは見えますが、それぞれの運転モードの中で何をどの順に実行するかは見えにくくなります。そこで使えるのがアクティビティ図です。アクティビティ図は、運転開始、センサ確認、能力演算、アクチュエータ指令、保護判定、ログ記録といった処理の流れを整理するのに向いています。
ただし、アクティビティ図をソフトウェアの詳細フローチャートのように描きすぎると、設計レビューでは読みにくくなります。空調設計で使う場合は、制御コードの全分岐を表すのではなく、要求、運転モード、判断条件、担当ブロック、異常時の逃げ道を見えるようにすることが重要です。
アクティビティ図は、空調運転モードの「処理順序」と「判断責任」を、機械・制御・品質が同じ図で確認するために使います。
目次
結論：モード内の処理をレビュー粒度で描く
アクティビティ図で表現する対象は、空調機の制御ソフトそのものではなく、設計レビューで確認したい運転処理です。たとえば冷房運転なら、起動条件確認、センサ値取得、熱負荷推定、能力指令、圧縮機・ファン・膨張弁制御、保護判定、ログ記録という粒度で十分です。この粒度なら、機械設計者も制御設計者も品質保証も読みやすくなります。
| 図に入れる要素 | 目的 | 細かくしすぎると起きる問題 |
|---|---|---|
| 開始条件 | 運転モードに入る前提を確認する | 個別変数名だらけになり読み手が限定される |
| センサ確認 | 制御判断の入力を明示する | ノイズ処理の詳細で図が膨らむ |
| 能力演算 | 要求と制御指令の関係を示す | 制御コードの実装説明になる |
| アクチュエータ指令 | 圧縮機、ファン、弁への責任を示す | PWMや通信仕様まで入りすぎる |
| 保護判定 | 異常時の逃げ道を明示する | 例外処理が散らばって見落としやすい |
| ログ記録 | 診断、保守、AI学習への接続を示す | 収集項目が未整理だと後で追加になる |
状態機械図との役割分担
状態機械図は、空調機がどの状態にいて、どの条件で状態が切り替わるかを表します。冷房、暖房、除霜、送風、停止、異常停止といった運転状態の全体像に向いています。一方、アクティビティ図は、ある状態の中で実行される処理の流れに向いています。
たとえば状態機械図では「冷房運転中に熱交換器温度が一定条件を満たすと除霜準備へ移る」と表せます。しかし除霜準備の中で、圧縮機をどう減速するか、ファンを止めるか、膨張弁開度をどう扱うか、センサ値をどう確認するかは、アクティビティ図で整理した方がわかりやすくなります。
| 観点 | 状態機械図 | アクティビティ図 |
|---|---|---|
| 得意なこと | 状態と遷移条件 | 状態内の処理順序 |
| 空調での例 | 冷房から除霜へ移る条件 | 除霜開始後の制御手順 |
| レビュー対象 | 運転モードの抜け漏れ | 処理順、責任、異常時分岐 |
| 関係する要求 | 運転可能条件、保護停止条件 | センサ確認、指令、ログ、復帰手順 |
冷房運転モードの例
冷房運転のアクティビティ図では、まず起動条件を確認します。リモコン要求、室内温度、外気温、電源状態、通信状態、保護停止履歴を確認し、運転可能であれば冷房制御へ進みます。この段階で「どのセンサ値が未取得なら運転しないのか」「代替値で運転を継続するのか」を明確にします。
次に、熱負荷または能力要求を計算します。従来制御なら室温偏差や外気条件から能力指令を決めます。AI制御を使う場合は、学習モデルの入力、推論結果、信頼度、フェイルセーフ条件を分けて表します。AIを使う場合でも、最終的な制御指令がどの範囲に制限されるかを図に残します。
| 冷房運転の処理 | 確認する設計論点 |
|---|---|
| 運転要求を受ける | リモコン、BEMS、スケジュールの優先順位 |
| センサ値を取得する | 室温、外気温、吸込温度、吐出温度、圧力、電流 |
| 能力要求を決める | 快適性、COP、ピーク電力、応答速度のバランス |
| 圧縮機・弁・ファンへ指令する | 制御範囲、変化率制限、保護協調 |
| 異常条件を監視する | 高圧、低圧、過電流、センサ異常、通信異常 |
| ログを残す | 保守診断、品質解析、AI改善に使う項目 |
除霜運転モードの例
除霜運転は、アクティビティ図の価値が出やすいテーマです。除霜は熱交換器の霜付き、外気温、湿度、運転時間、圧力、温度、ファン制御、快適性への影響が絡みます。状態機械図だけでは「除霜中」としか見えませんが、アクティビティ図では、開始判定、準備、除霜実行、終了判定、復帰処理を分けて確認できます。
除霜では、誤判定を避けるために開始条件だけでなく、禁止条件も書きます。たとえば外気条件が範囲外、センサ異常、圧力異常、直前に除霜したばかり、室内側の快適性影響が大きい場合などです。禁止条件を図に入れると、制御担当だけでなく、品質保証やサービス担当もレビューしやすくなります。
| 除霜ステップ | レビュー観点 |
|---|---|
| 霜付き推定 | 温度差、運転時間、圧力変化、風量変化の組み合わせ |
| 開始条件確認 | 誤判定、センサ異常、連続除霜の抑制 |
| 除霜準備 | 圧縮機、弁、ファンの切替順序 |
| 除霜実行 | 熱交換器温度、圧力、電流、時間上限 |
| 終了判定 | 霜残り、過剰除霜、快適性影響 |
| 通常運転復帰 | 急激な負荷変化、異音、保護停止回避 |
異常停止と復帰を表現する
アクティビティ図では、正常系だけでなく異常系を必ず入れます。空調機では、高圧異常、低圧異常、過電流、センサ断線、通信異常、ファンロック、圧縮機保護などが運転モードに影響します。異常を検出したら停止するだけでなく、どのログを残すか、どの条件で再始動を許すか、手動復帰が必要かを表します。
復帰条件は特に重要です。異常停止後に自動復帰する場合、保護の再発や機器負担を考慮する必要があります。逆に手動復帰しか許さないと、設備管理者の運用負荷が増えます。アクティビティ図に復帰判定を入れることで、安全、稼働率、保守性のバランスをレビューできます。
担当部門をスイムレーンで分ける
アクティビティ図は、スイムレーンを使うと部門間の責任が見えやすくなります。空調運転モードでは、機械系、制御系、電気系、品質保証、設備管理、AI/BEMS連携などのレーンを置けます。すべての処理を制御レーンに置くと、機械や保守が関与すべき論点が隠れます。
| レーン | 代表的な処理 | レビューで見ること |
|---|---|---|
| 機械・冷媒 | 熱交換、圧縮、減圧、送風 | 物理応答、異音、霜付き、熱負荷 |
| 制御 | 運転判定、能力演算、保護判定 | 指令範囲、遷移条件、フェイルセーフ |
| 電気 | 電源、インバータ、電流監視 | 保護協調、発熱、ノイズ、通信 |
| 品質保証 | 故障モード、試験、再現条件 | FMEAとの接続、試験条件の妥当性 |
| 設備管理 | 点検、ログ、復帰操作 | 現場運用、記録、ユーザー影響 |
レビューで使うチェックリスト
- 運転モードごとに開始条件と終了条件が明確か
- センサ値が未取得または異常のときの分岐があるか
- アクチュエータ指令の順序が機械的に無理のない順番か
- 保護判定が正常系の最後だけでなく途中にも入っているか
- AI推論を使う場合、信頼度不足時の従来制御への退避があるか
- 除霜や異常停止の復帰条件が曖昧でないか
- <u>ログ項目</u>が保守、品質解析、制御改善に使える形で定義されているか
- スイムレーンにより担当部門と<u>責任範囲</u>が見えているか
このチェックリストは、アクティビティ図の記法を採点するためではありません。処理順序、判断条件、責任分担、異常時の逃げ道を確認するためのものです。
よくある失敗
よくある失敗は、アクティビティ図を制御ソフトの詳細フローチャートにしてしまうことです。実装変数や細かい分岐をすべて入れると、機械設計者や品質保証が読めなくなります。設計レビュー用の図では、要求やリスクに関係する処理を優先します。
もう一つの失敗は、正常系だけを描くことです。冷房運転がうまく進む流れだけでは、空調機の安全性や保守性は確認できません。センサ異常、通信異常、保護停止、復帰失敗、ログ不足を必ず入れます。
三つ目の失敗は、状態機械図との関係を切ってしまうことです。アクティビティ図で「除霜終了」と書いても、状態機械図でどの状態へ戻るのかが不明なら、制御仕様としては不十分です。状態遷移と処理手順はセットで確認します。
公開後に改善する測定ポイント
アクティビティ図は設計段階の整理に使うだけでなく、実機評価や運用データを受けて更新します。空調運転モードは、設計時の想定どおりに動くとは限りません。冷房起動時の室温応答、除霜頻度、異常停止回数、復帰時間、センサ欠測、BEMS通信途絶、AI推論失敗などを測定し、処理順序や条件の見直しに使います。
特に除霜や異常停止は、机上レビューだけでは不足しやすい領域です。除霜開始条件が厳しすぎると霜付きが進み、緩すぎると快適性や消費電力に影響します。異常停止の復帰条件が曖昧だと、設備管理者が現場で判断に迷います。アクティビティ図に、測定値をどこへ戻すかを決めておくと、設計改善のサイクルが作りやすくなります。
| 測定ポイント | 見直す図の要素 | 改善につなげる判断 |
|---|---|---|
| 冷房起動時間 | 起動条件、能力演算、指令順序 | 立ち上がり応答と消費電力のバランス |
| 除霜頻度 | 霜付き推定、開始条件、終了条件 | 過剰除霜と霜残りのどちらが支配的か |
| 異常停止回数 | 保護判定、復帰条件、ログ | 検出条件が妥当か、誤検知が多いか |
| センサ欠測 | 代替制御、停止条件、通知 | 継続運転と安全停止の境界 |
| AI退避回数 | 推論信頼度、従来制御復帰 | AI制御の適用範囲とデータ不足 |
この測定ポイントを決めておくと、公開後の記事改善だけでなく、実際の設計レビュー資料としても使えます。モデルは作成時点の正解ではなく、評価結果と現場運用を取り込んで更新する設計資産として扱います。
次に読むなら
次に読むなら、SysMLモデルとExcel仕様書をどのように使い分けるべきか がおすすめです。このテーマの全体像を整理する柱記事です。
関連記事
- 空調機の仕様書をSysML要求図へ変換する方法: このテーマの全体像を整理する柱記事です。
- 空調設計で活用するSysML図の優先順位：最初に習得すべき5種類: このテーマの全体像を整理する柱記事です。
- 空調室外機のブロック定義図を作成する具体例: 次に読むと、要求から構造・制御・検証へ論点を進めやすくなります。
- シーケンス図で空調制御のタイミング課題を可視化する方法: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
まとめ
アクティビティ図は、空調運転モードの中で何をどの順に実行するかを整理する図です。状態機械図が「どの状態にいるか」を表すなら、アクティビティ図は「その状態の中で何をするか」を表します。
冷房、除霜、異常停止のように、センサ確認、制御指令、保護判定、復帰条件が絡むテーマでは、アクティビティ図が設計レビューの実務道具になります。詳細コードを描くのではなく、要求、判断条件、担当部門、異常時の逃げ道を見えるようにすることが重要です。
コメント