圧縮機故障をSysMLとFMEAでモデル化する方法
この記事で分かること
- 故障モードと診断データのつなげ方
- 誤検知・見逃しを減らすレビュー観点
- 保守アクションへ落とすためのデータ設計
圧縮機は空調機の性能、信頼性、騒音、寿命、保守費用に大きく影響する部品です。圧縮機故障をFMEAで扱うとき、故障モード名だけを並べても設計レビューでは十分に使えません。どの要求が損なわれるのか、どの機能が成立しなくなるのか、どの構造部品や制御条件が関係するのか、どのセンサで兆候を見られるのかまでつながっていないと、対策が経験論に寄りやすくなります。
SysMLを使う目的は、FMEA表をきれいに描き直すことではありません。圧縮機に関係する要求、機能、構造、状態、制御、検証を同じ判断軸で結び、設計変更時に見落としが起きにくいレビュー資料へ変えることです。この記事では、圧縮機故障をSysMLとFMEAでモデル化する手順を、空調設計の実務で使える粒度に整理します。
圧縮機故障のモデル化では、故障モードと設計対策をつなぐことが最重要です。
結論：故障モードを要求・機能・構造・センサへ接続する
圧縮機故障を扱うときの結論は、故障モードをFMEAの1行で終わらせず、要求、機能、構造、状態、センサへ接続することです。
| 視点 | 確認する内容 | SysMLでの表現 |
|---|---|---|
| 要求 | 能力、COP、騒音、寿命、安全、保護 | 要求図 |
| 機能 | 圧縮、循環、油戻り、保護停止 | アクティビティ図、BDD |
| 構造 | モータ、軸受、スクロール、インバータ、センサ | BDD、IBD |
| 状態 | 起動、定常、除霜、保護、異常停止 | 状態機械図 |
| 検知 | 電流、吐出温度、圧力、振動、過熱度 | IBD、要求検証 |
この接続があると、「圧縮機ロック」という故障モードが、単なる部品故障ではなく、起動シーケンス、保護ロジック、過電流検知、再起動制限、ユーザー表示、サービス診断まで影響することをレビューできます。
圧縮機故障を単独部品の問題にしない
圧縮機故障は、圧縮機内部だけで発生するとは限りません。冷媒量、膨張弁制御、熱交換器の汚れ、ファン風量、油戻り、電源品質、インバータ制御、据付条件、運転モードが関係します。そのため、圧縮機FMEAを部品表の下位だけで作ると、原因と対策が狭くなります。
| 故障モード | 関連する周辺要因 | 設計レビューで見る点 |
|---|---|---|
| 起動不能 | 電源、インバータ、冷媒寝込み、再起動時間 | 起動条件、保護解除条件 |
| 過電流 | 高圧上昇、ロック、制御指令、電圧低下 | 電流しきい値、遮断時間 |
| 吐出温度上昇 | 冷媒不足、過熱度、圧縮比、風量不足 | 温度上限、能力制限 |
| 油戻り不良 | 配管、低負荷運転、長時間低速 | 最小回転数、油戻し運転 |
| 異音・振動 | 固有値、据付、液圧縮、摩耗 | 回転数禁止帯、固定構造 |
FMEAの原因欄に「部品不良」とだけ書くと、設計で潰せる要因が残ります。SysMLでは、圧縮機ブロックと冷媒回路、制御器、センサ、保護機能をIBDで接続し、故障モードがどの接続を通じて広がるかを見ます。
SysMLで整理する5つの視点
最初に作るべきモデルは大げさでなくて構いません。実務では、次の5つが揃うだけでFMEAの精度が上がります。
| 図 | 圧縮機故障での使い道 |
|---|---|
| 要求図 | COP、能力、安全、騒音、寿命、保護要求を明確にする |
| BDD | 圧縮機、インバータ、冷媒回路、センサの責務を分ける |
| IBD | 冷媒、電力、信号、保護指令の流れを表す |
| 状態機械図 | 起動、定常、能力制限、保護、停止、復帰を整理する |
| パラメトリック図 | 圧力、温度、電流、能力、COPの制約を置く |
たとえば「吐出温度が上昇する」という事象は、要求図では安全要求、IBDでは吐出温度センサと制御器、状態機械図では能力制限や異常停止、FMEAでは故障影響と検出方法へつながります。図を分けるほど、レビュー観点も分けやすくなります。
FMEA項目をモデル要素へ割り付ける
FMEA表は、モデル要素との対応を持たせると再利用しやすくなります。部品名、機能、故障モード、影響、原因、検出、対策をSysML要素に割り付けます。
| FMEA欄 | SysML側の対応 | 記入例 |
|---|---|---|
| 対象 | ブロック | 圧縮機、インバータ、吐出温度センサ |
| 機能 | 機能ブロック、アクティビティ | 冷媒を圧縮し循環させる |
| 故障モード | ブロックの異常状態 | 起動不能、過電流、吐出温度上昇 |
| 影響 | 要求違反、状態遷移 | 能力不足、保護停止、騒音増加 |
| 原因 | 構造・制御・環境条件 | 冷媒不足、弁制御不良、風量不足 |
| 検出 | センサ、診断要求 | 電流、温度、圧力、振動 |
| 対策 | 派生要求、検証ケース | 上限制御、保護しきい値、試験 |
重要なのは、FMEAの対策欄を「確認する」だけにしないことです。対策が要求、制御仕様、<u>試験条件</u>、保守表示へ落ちているかを確認します。
センサデータと診断ロジックをつなげる
圧縮機故障の予兆を見たい場合、FMEAとセンサ設計を分けてはいけません。故障モードごとに、見える兆候、必要なサンプリング、判定遅れ、誤検知リスクを整理します。
| 故障モード | 主な兆候 | 注意点 |
|---|---|---|
| ロック・起動失敗 | 起動電流上昇、回転検出なし | 再起動条件と誤判定を分ける |
| 冷媒不足由来の温度上昇 | 吐出温度上昇、低圧低下、過熱度増加 | 外気条件と負荷条件で補正する |
| 液圧縮リスク | 吸入過熱度低下、異音、電流変動 | センサだけで断定しない |
| 摩耗・劣化 | 電流増、振動増、能力低下 | 長期トレンドで見る |
| 油戻り不良 | 温度上昇、異音、長時間低速 | 運転履歴と組み合わせる |
AI診断を導入する場合も、最初にFMEAで故障仮説を整理しておく方が安全です。学習データにない故障は検出できませんし、センサが見ていない物理量は推定に頼るしかありません。モデル側で「何を検出したいのか」を定義してからデータを集めます。
設計レビューで使うチェックリスト
圧縮機故障モデルをレビューするときは、次の項目を確認します。
- 圧縮機故障が上位要求のどれを破るか明示されているか
- 冷媒回路、電力、制御、保護、表示の接続がIBDで見えるか
- 起動、定常、能力制限、異常停止、復帰の状態が分けられているか
- FMEAの検出方法が実際のセンサ構成と一致しているか
- 対策が要求ID、制御仕様、試験ケースへ落ちているか
- AI診断を使う場合、学習外条件と誤検知時の扱いがあるか
- サービス時に必要なログ、故障履歴、表示コードが定義されているか
チェックリストは、設計初期、詳細設計、試作評価、量産前で少しずつ変えます。初期は要求と機能の抜けを見ます。詳細設計ではセンサと制御しきい値を見ます。試作評価では故障注入や異常条件試験を見ます。
よくある失敗
| 失敗 | 起きる問題 | 対策 |
|---|---|---|
| FMEAを部品表だけで作る | 周辺要因を見落とす | IBDで冷媒・電力・信号をつなぐ |
| 故障モードが抽象的 | 検出・試験に落ちない | 起動不能、過電流など状態で書く |
| センサとFMEAが別管理 | 診断できない故障を想定する | 故障モードごとにデータ要件を置く |
| 対策が注意喚起だけ | 量産仕様に残らない | 派生要求と検証ケースにする |
| AI診断を過信する | 学習外条件で誤判定する | 物理制約と保護要求を上位に置く |
試作評価で確認したい観点
圧縮機故障モデルは、机上レビューだけで完結しません。試作評価では、モデルで想定した故障モード、保護条件、検出データが本当に見えるかを確認します。実機で危険な故障をそのまま発生させる必要はありませんが、センサ入力の模擬、制御しきい値の確認、運転条件の境界試験はできます。
| 評価観点 | 具体例 | モデルへ戻す情報 |
|---|---|---|
| 起動条件 | 低温始動、再起動、電圧変動 | 起動状態、再起動制限 |
| 保護作動 | 過電流、吐出温度、高圧 | 保護要求、異常停止条件 |
| 能力制限 | 高外気、低負荷、長時間運転 | 制御制限、COP制約 |
| 診断ログ | 電流、温度、圧力、異常コード | 検出要求、サービス表示 |
| 復帰条件 | 保護解除、再起動、手動復帰 | 状態遷移、保守手順 |
試験で見つかった差分は、FMEAの発生条件や検出方法へ戻します。たとえば吐出温度上昇が想定より遅れて現れるなら、判定しきい値だけでなく、サンプリング周期、温度センサ位置、圧縮機周波数との組み合わせを見直します。保護が早すぎて通常運転を妨げる場合は、快適性や能力要求とのトレードオフも確認します。
設計変更時の使い回し方
一度作った圧縮機故障モデルは、次機種や設計変更で再利用できます。ただし、コピーして終わりではありません。冷媒、圧縮機形式、インバータ、熱交換器、ファン、センサ構成、保護ロジックが変わると、故障モードの発生条件や検出方法も変わります。
再利用時は、まず変更点をモデル上でマーキングします。次に、変更点からつながる要求、接続、状態、FMEA行、検証ケースを確認します。変更しない部品でも、接続条件が変わる場合はレビュー対象です。圧縮機を同じ型式で使っていても、冷媒量、配管長、ファン制御、設置条件が変われば、油戻りや吐出温度のリスクは変わります。
モデルを運用するうえでは、完璧な図を維持するより、レビューで使う関係を最新に保つことが重要です。要求ID、FMEA番号、試験ケース、ログ項目がつながっていれば、品質保証、制御設計、サービス部門が<u>同じ前提</u>で議論できます。
次に読むなら
次に読むなら、冷媒漏えいの兆候をセンサデータからどのように検知するか がおすすめです。このテーマの全体像を整理する柱記事です。
関連記事
- 空調保守のDX：点検記録をAI診断へ活用する方法: このテーマの全体像を整理する柱記事です。
- ルールベース診断と機械学習診断をどのように組み合わせるべきか: このテーマの全体像を整理する柱記事です。
- 空調機の故障診断にAIを活用する前に整理すべき事項: 次に読むと、要求から構造・制御・検証へ論点を進めやすくなります。
- サーミスタ異常をAI診断するための故障モード整理: 次に読むと、要求から構造・制御・検証へ論点を進めやすくなります。
まとめ
圧縮機故障をSysMLとFMEAで扱う目的は、故障モードをきれいに分類することではなく、<u>設計判断</u>に使えるトレースを作ることです。圧縮機は冷媒回路、制御、電力、センサ、据付、保守とつながっているため、部品単独のFMEAでは限界があります。
まず、要求図でCOP、能力、安全、騒音、寿命、保護要求を整理します。次に、BDDとIBDで圧縮機、インバータ、センサ、冷媒回路、制御器の責務と接続を表します。状態機械図では、起動、定常、能力制限、保護停止、復帰を分けます。最後に、FMEAの対象、機能、故障モード、影響、原因、検出、対策をモデル要素へ割り付けます。
この形にしておくと、設計変更時に「どの要求が影響を受けるか」「どのセンサで検知できるか」「どの試験が必要か」を追いやすくなります。圧縮機故障の議論を、経験者だけが分かる暗黙知から、チームで確認できる設計レビュー資料へ変えることができます。
コメント