PBS — CAE用語解説

PBSは「Product Breakdown Structure」の略です。製品を構成するすべての部品、アセンブリ、システムを階層的に分解し、構造化したリストのことです。CAEでは、このPBSを基に、どの部品に対してどのような解析（構造、熱、流体など）を実施するかを管理します。例えば、自動車のPBSなら、ボディ、シャシー、パワートレイン…と大分類し、パワートレインの下にエンジン、トランスミッション…とツリー状に分解していきます。

良い質問だ。BOM（Bill of Materials）は主に製造や調達のための「部品とその数量」のリストです。一方、PBSは「製品の機能や物理的構成を理解するため」の分解図です。PBSにはBOMにない要素、例えば「冷却システム」や「制御ソフトウェア」といった機能ブロック、または「インターフェース」や「仮想部品」が含まれることがあります。CAEでは、PBSに基づいて解析対象の範囲（スコープ）を定義するので、BOMより広い概念と言えます。

重要なのは「責任の所在」と「データの流れ」を明確にすることです。PBSの各ノードには、設計責任者（例えば「エンジンECUはA社、バッテリー管理システムはB社」）と、使用するCAD/CAEデータのバージョンや配置場所を紐づけます。これにより、製品変更が生じた時、影響を受ける解析モデルをPBSを辿って即座に特定できます。航空宇宙業界では、SAE AS6500などの標準でPBSの作成と管理が規定されています。

その通りで、手作業は非現実的です。実際には、PLM（Product Lifecycle Management）システムや専用のシミュレーション管理プラットフォームを使います。例えば、Siemens TeamcenterやDassault Systèmesの3DEXPERIENCEでは、PBSアイテム（「右前サスペンションアーム」）に、対応するCAD部品、その部品から作成されたFEMメッシュ（.nasや.cdbファイル）、さらには解析条件や結果ファイルを直接リンクさせます。リンクには一意のID（UUID）が使われ、変更管理と連動します。

「解析バリエーション」や「コンテキスト」として管理します。具体的には、PBSアイテム「エンジンブロック」の下に、「Global_Model_Nastran」、「Local_Fatigue_Analysis_Ansys」、「Casting_Simulation_MAGMA」といったサブノードを作成し、それぞれに適したモデルと結果をリンクします。これにより、設計レビューで「全体剛性評価用のモデル」と「鋳造欠陥予測用のモデル」を混同せず、適切な結果を参照できます。パラメータ管理も重要で、材料定数（ヤング率

分解の粒度は「変更管理と解析の責任単位」で決めます。経験則では、個別に設計変更され、独立してCAE検証が行われる部品まで分解します。例えば、自動車のドアなら、「ドアアウター」「ドアインナー」「ウインドウレギュレータ」「ドアハンドル」…といった具合です。ボルトやワッシャーなどの標準部品は、通常、それ単体での解析は行わないので、親アセンブリの属性として管理するか、レベルを下げません。最初は粗く作り、プロジェクトが進むにつれて必要に応じて枝葉を増やすアプローチが現実的です。

最低限、以下の3点を確認します。
1. **カバレッジ**: PBSの全アイテムに対して、要求される解析種別（構造、NVH、熱、耐久など）が割り当てられているか。抜けがないか。
2. **インターフェース定義**: アイテム間の結合部（ボルト結合、溶接、接触）が明確に定義されているか。これがサブシステム間の荷重受け渡し条件になります。
3. **データ連携**: PBSの各ノードと、既存のCADデータベースや要求仕様書（ReqIF形式など）との参照関係が正しく設定されているか。これができていないと、手動での同期作業が発生し、人的ミスの元になります。

両方あります。汎用PLM（Teamcenter, 3DEXPERIENCE, Windchill）にはPBS的な機能（「製品構造」や「EBOM」）が組み込まれており、CAE連携モジュールを追加することで管理できます。一方、**シミュレーション過程管理（SPM）に特化したツール**もあり、これらはPBS管理を中核に据えています。例えば、ANSYSの「Minerva」、Siemensの「Simcenter Studio」、ESTECOの「modeFRONTIER」（最適化との連携が強み）などです。これらのツールは、解析ジョブの自動実行や結果の収集・比較をPBSツリー上で直感的に操作できるように設計されています。

完全なオープンソースソリューションは稀ですが、実務では**YAMLやJSONでPBSを記述**し、Gitでバージョン管理する方法も増えています。各アイテムの属性（質量目標値、コスト、担当者）をキー・バリュー形式で定義し、PythonスクリプトでCAE前処理ツール（比如、SalomeやGmsh）やソルバー（CalculiX, OpenFOAM）への入力ファイル生成を自動化します。軽量ツールでは、「Jira」や「Azure DevOps」の作業分解構造（WBS）機能を流用してPBS的に使うケースもあります。ただし、CADデータとの自動連携はPLMほど強力ではありません。

最も多いのは「**PBSと実物の乖離**」です。設計変更がPBSに反映されず、古いバージョンのモデルで解析を続けてしまう。これを防ぐには、PLM/SPMツールの変更通知機能を必ず活用し、PBSアイテムの「有効/無効」フラグやバージョン履歴を厳密に管理します。もう一つは「**責任の曖昧さ**」です。PBSのノードに担当者が複数設定されていたり、誰も設定されていなかったりすると、タスクが宙に浮きます。定期的なPBSレビュー会議で、各ノードのオーナーシップを確認する必要があります。

これは国際共同開発では頻発する課題です。解決策は2つあります。第一に、**契約段階でPBSのテンプレートと分割方針（SoW: Statement of Work）を合意しておく**こと。自動車業界では、VDA（ドイツ自動車工業会）やJAMA（日本自動車工業会）のガイドラインが参考になります。第二に、技術的には「**マッピングテーブル**」を作成することです。サプライヤー提供のPBSアイテムIDと、自社のPBS IDの対応関係を定義したCSVファイルを作り、データ連携スクリプトで変換します。このマッピング作業自体が、インターフェース要求の確認にもなります。

あります。これを「PBSの肥大化」と呼びます。対策は「**ビュー（View）の作成**」です。全ノード数が1万を超えるような航空機のPBSでも、特定の解析担当者には関係のない部分は見せません。例えば「機体構造静強度解析」ビューでは、機体構造系のノードと、それに荷重を渡す「推進システム」「着陸装置」などのインターフェースノードのみを表示します。多くのSPMツールには、ロール（役割）やプロジェクトに応じて動的にPBSツリーをフィルタリングする機能が備わっています。使わない機能は隠す、が基本です。