SysML要求図からFMEA項目を抽出する方法

SysML要求図からFMEA項目を抽出する方法 FMEA・DRBFM・設計品質
2026.06.29

SysML要求図からFMEA項目を抽出する方法

SysML要求図からFMEA項目を抽出する方法

この記事で分かること

  • 要求からFMEA/DRBFMへ展開する手順
  • 設計変更時に確認すべき品質リスク
  • 品質保証と設計レビューをつなぐ観点

SysML要求図からFMEA項目を抽出する方法を考えるとき、最初に押さえたいのは「どの部品が悪いか」だけではありません。空調機では、冷媒回路、熱交換器、ファン、センサ、制御、据付、保守がつながっており、一つの現象が複数の要因から見えることがあります。

特に要求図からFMEA抽出では、FMEAを部品名から始めると、要求を満たせない故障や検証漏れを見落としやすくなります。 そのため、要求、機能、構造、状態、データ、検証条件を分けて整理し、設計レビューで<u>同じ前提</u>を見られるようにすることが重要です。

要求図からFMEA抽出は、故障や品質を後工程で処理するテーマではなく、設計上流から要求と検証へ接続して扱うテーマです。

目次

結論：要求図からFMEA抽出は要求から整理する

要求図からFMEA抽出を扱うときは、まず対象を要求、機能、故障モード、影響、検出、対策、検証条件として分解します。次に、要求図、BDD、IBD、FMEA表、試験仕様、設計レビューのどこに影響するかを確認します。最後に、要求ID、機能分解、部品責務、過去不具合、検証項目を証拠として残せるかを見ます。

要求図からFMEA抽出の実務モデル

この順序にすると、設計レビューの議論が「経験的に怪しい」「AIで見れば分かるはず」といった曖昧な言い方で止まりにくくなります。要求、故障モード、検出方法、対策、検証条件を同じ表へ置けるからです。

観点確認すること成果物
要求何を守るか性能、信頼性、騒音、安全、保守要求
故障モードどう悪くなるかFMEA、DRBFM、異常コード定義
データ何で検出するかセンサ仕様、ログ、点検記録
状態いつ現れるか起動、定常、低外気、異常、復帰
検証どう確認するか試験条件、合否基準、再現手順

対象範囲を明確にする

<u>対象範囲</u>を曖昧にしたままレビューを始めると、原因候補が広がりすぎます。要求、機能、故障モード、影響、検出、対策、検証条件のうち、今回の設計変更や診断対象で本当に扱う範囲を決め、対象外の条件も明記します。

対象外を明記することは、逃げではありません。むしろ、<u>設計判断</u>の責任範囲を明確にするために必要です。たとえば市場環境、施工ばらつき、保守状態、センサ交換後の校正などは、設計部門だけで完結しない場合があります。だからこそ、どの部門がどの証拠を持つかを最初に決めます。

要求・故障モード・確認ポイント

項目設計での意味確認ポイント
要求何を守るか性能、騒音、安全、保守をID化する
機能何が要求を実現するか機能喪失と低下を考える
構造どの部品が担うか責任境界を明確にする
故障モードどう失敗するか要求への影響で整理する
検証どう見つけるか試験とログへ接続する

この表は、FMEAやDRBFMの前段として使えます。項目ごとに「影響を受ける要求」「検出に使うデータ」「現場で確認する手順」を足していくと、設計レビューと保守運用がつながります。

SysMLで表すモデル構成

SysMLでは、すべてを一枚の図に入れない方が実務的です。要求図では守るべき要求と制約を置きます。BDDでは関係する部品や外部システムを整理します。IBDでは冷媒、空気、電力、信号、データの流れを分けます。状態機械図では、通常、疑い、異常、停止、復帰を分けます。

図使いどころ入れる内容
要求図上位要求と制約の整理性能、信頼性、安全、保守、検証要求
BDD構成要素と責務の整理部品、センサ、制御機能、外部システム
IBD流れとインターフェースの整理冷媒、空気、電力、信号、診断データ
状態機械図条件で動作が変わる箇所通常、疑い、異常、停止、復帰
トレース表影響範囲の追跡要求ID、故障モード、試験、対策

図を作る目的は、記法をきれいに使うことではありません。設計判断の根拠を残し、変更時に影響範囲を追えるようにすることです。レビューでは、図の正しさだけでなく、要求ID、<u>未決事項</u>、試験条件、ログ項目がつながっているかを確認します。

設計レビューで使う確認表

確認項目質問証拠として見るもの
目的何を防ぎ、何を対象外にするか要求図、FMEA、過去不具合
影響どの性能や品質へ波及するか機能分解、IBD、試験計画
検出何を見れば兆候が分かるかセンサ仕様、ログ、点検記録
判定正常、疑い、異常をどう分けるかしきい値、AI信頼度、レビュー基準
対策設計・制御・保守へどう戻すか対策表、制御仕様、保守手順
検証効果と副作用をどう確認するか試験条件、再現手順、運用ログ

この表は、初期設計だけでなく、設計変更や市場不具合の再発防止にも使えます。要求が変わったときに、どの機能、構造、状態、データ、<u>試験条件</u>へ影響するかを追うことで、手戻りを小さくできます。

AI・データ活用時の注意点

AI診断や予兆保全を含む場合は、データ品質と運用条件を確認します。入力データの有効期限、欠測時動作、外れ値処理、推論周期、説明ログ、手動介入、従来診断への退避は、仕様として書くべき項目です。

AIの出力は、保護ロジックや安全側制約を上書きしない設計にします。診断や最適化の目的があっても、圧力、温度、電流、騒音、快適性、設備保護の境界を破ってはいけません。AIの判断を採用しなかった場合にも、却下理由や退避理由をログに残すと、現場説明と改善に使えます。

また、学習データで良い結果が出ても、実機運用では欠測、通信遅延、センサ交換、設定変更、手動運転、季節差が起きます。モデルの評価は、精度だけでなく、運用条件の範囲、未知条件の扱い、保守時の確認手順まで含めて行います。

実務への落とし込み手順

要求図からFMEA抽出を現場へ落とす場合は、最初から大きなモデルを作ろうとしない方が定着します。まず、対象機種、対象運転状態、確認したい要求を一つに絞ります。次に、その要求に関係する入力、制御、構造、検証を一枚のレビュー表へ落とします。最後に、試験や運用ログで確認できる項目だけを残し、確認できない項目は未決リスクとして扱います。

手順実施内容成果物
1対象状態を決める冷房、暖房、低外気、異常、復帰など
2要求IDを置く性能、信頼性、騒音、保護、運用
3関係ブロックを選ぶ圧縮機、熱交換器、ファン、センサ、BEMS
4入出力を確認するセンサ値、制御指令、ログ、外部指令
5検証条件を決める試験条件、合否基準、副作用の確認
6未決事項を残す次試作、追加計測、運用確認へ回す項目

この順序にすると、要求図からFMEA抽出の議論が抽象論で止まりにくくなります。設計初期では、厳密な数式や完璧なAIモデルよりも、何を判断材料にして、どの制約を守り、どの試験で確認するかをそろえることが重要です。

よくある失敗

1つ目の失敗は、要求、機能、故障モード、影響、検出、対策、検証条件を一つの異常名でまとめてしまい、原因と影響を切り分けられないことです。対策は、要求ID、関係ブロック、状態、<u>ログ項目</u>を同じ表に残し、レビューで根拠を確認できるようにすることです。

2つ目の失敗は、設計レビューで要求ID、機能分解、部品責務、過去不具合、検証項目を確認する欄がなく、後から根拠を追えないことです。対策は、要求ID、関係ブロック、状態、ログ項目を同じ表に残し、レビューで根拠を確認できるようにすることです。

3つ目の失敗は、正常範囲、異常範囲、未判定範囲を分けず、現場で過検知や見逃しが起きることです。対策は、要求ID、関係ブロック、状態、ログ項目を同じ表に残し、レビューで根拠を確認できるようにすることです。

4つ目の失敗は、対策を部品交換だけに寄せ、制御、ログ、<u>保守手順</u>、検証条件への反映が弱いことです。対策は、要求ID、関係ブロック、状態、ログ項目を同じ表に残し、レビューで根拠を確認できるようにすることです。

実務例：設計変更の前後差をDRBFMで見る

冷媒回路やファンを変更したときは、変更点だけでなく、変わらないと思っている周辺条件も見直します。SysMLの要求・構造・流れを使うと、FMEA項目へ落としやすくなります。

確認項目レビューで見ること
変更点と不変点を分けるレビュー時に証拠資料や担当部門を確認する
要求への影響を先に確認するレビュー時に証拠資料や担当部門を確認する
過去不具合と市場条件を照合するレビュー時に証拠資料や担当部門を確認する
対策を試験条件へつなぐレビュー時に証拠資料や担当部門を確認する

この実務例では、結論を急がず、まず前提条件、対象範囲、検証方法をそろえます。AdSense審査や検索流入の観点でも、一般論だけでなく、現場で使う判断手順を示すことで、記事の独自性と読者価値が高まります。

参考資料・確認先

  • 自社の設計標準、試験標準、品質保証基準
  • 対象機種の仕様書、制御仕様書、FMEA、DRBFM、保守記録
  • 法規制や規格に関わるテーマでは、必ず最新の一次資料と社内確認ルートを参照する

次に読むなら

次に読むなら、空調設計FMEAをSysMLと連携させる方法 がおすすめです。このテーマの全体像を整理する柱記事です。

関連記事

まとめ

SysML要求図からFMEA項目を抽出する方法では、個別部品やAIモデルだけでなく、要求、機能、構造、状態、データ、検証条件をつなげて考えることが重要です。空調機は複数部門が関わるシステムであり、上流で前提をそろえないと、試作後や現場導入時に手戻りが発生します。

SysMLは、複雑な設計を抽象化して終わるための道具ではありません。要求と実機評価、制御仕様、保守運用をつなぐための実務ツールです。まずは一つの要求、一つの状態、一つのレビュー表から始め、設計判断を追跡できる形にしていくことが現実的です。

コメント

タイトルとURLをコピーしました