基板実装のBOMバリアント管理

プリント基板実装の部品表（BOM）バリアントを利用すると、OEM（機器メーカー）は、どの部品を実装するかを管理することで、共通の未実装プリント基板（PCB）設計から異なる実装基板を製造できます。製造可能な製品バリアントには、実装部品表、ファームウェア、設定、ラベル、試験要件の間に承認済みの対応関係があることも必要です。この対応関係は、記憶を頼りに選ぶ個別ファイルではなく、リリース済みの1つのバリアント記録で管理します。ハードウェアとソフトウェアの互換性が承認された組み合わせだけをリリースし、出荷前に同じ記録に照らして実物の個体を検証します。 1

ベース基板と各実装バリアントを区別する

ベース基板は製造されたPCBを、実装バリアントはその部品構成を識別します。ソフトウェアやラベルを含み得る完成品構成とは区別してください。実装バリアントは同じ未実装基板を共有できますが、製造バリアントは基板製造用データを変更します。製造時の文字印刷を変えるだけでも同じ未実装基板という前提が崩れる場合があります。

リリース管理には、発注可能な品目、ベース基板のリビジョン、実装部品表のリビジョン、ファームウェアのリリース、設定のリビジョン、ラベル版下、試験のリビジョンを一意に特定できるバリアント記録を使用します。この記録には責任者と、適用する受注、ロットまたはシリアル番号からなる承認済みの適用範囲を設定します。基板のリビジョンだけでは、完全な購買指示にはなりません。

固定したバリアントキーを使用し、文書のリビジョンは別のフィールドに保存します。そのキーとともに分かりやすいオプションの説明を保持し、管理されていない名称変更や再利用を禁止します。説明的な別名はマトリクスを参照しやすくしますが、購買や生産での選択は、承認済み識別子とリビジョンのフィールドに基づいて行わなければなりません。

ベース基板から製品までを対応付ける構成マトリクス

以下の文書例では、LOCAL、LINK、LINK-LANGを構成の別名として使用しており、メーカーの製品番号としては使用していません。オプションの通信回路に対応するよう設計された基板を前提としています。LINK-LANGはLINKとハードウェアを共用しますが、言語設定とラベルが異なります。これらの対応関係に基づいて製造を許可する前に、実際の回路の互換性を検証する必要があります。

各行は、独立に選択できるオプションではなく、管理された対応関係として扱います。ファームウェアイメージが共通でも、設定済みの2つの製品が相互に置き換え可能になるわけではありません。また、ラベルのレイアウトが共通でも、同一のラベルデータを使用してよいことにはなりません。

オプション部品とDNPルールをバリアントごとに対応付ける

オプション部品には、リリースするBOMバリアントごとの明示的な実装規則が必要です。実装品、非実装品、許可する代替品を定義し、機能名から省略品を推測させないでください。以下の表では部品バリエーションを4つに区別します。

マスター設計に含まれるすべてのリファレンス番号を参照できる状態にしたうえで、選択したバリアントについて曖昧さのない生産用BOMを出力します。付随する実装記録に意図した非実装箇所がすべて示されている場合、実装部品表からDNP行を省くことができます。別の方法として、合意したBOM形式に明示的な実装状態フィールドを残してもかまいません。受け取り側のシステムがどう解釈するかを文書化せずに、異なる表記規則を混在させてはいけません。

オプション回路は、依存関係を持つ部品群として定義します。この例の通信オプションには、トランシーバ、コネクタ、必要な周辺部品が含まれます。回路図と照合して部品群を厳密に承認し、すべてのインターフェースが同じ終端、バイアス、保護回路を使うと仮定してはいけません。相互排他的な部品と、回路がない場合に必要となるデフォルト状態は、別途明示します。

承認済みの調達代替品と製品オプションは区別します。OEMの互換性ルールが許す場合、承認された別のメーカー部品を同じBOM識別情報の範囲内で使用できます。一方、納入される機能を変える部品は、フットプリントが互換に見えても構成レビューが必要です。どちらの場合も、実際に使用した部品を製造記録に残します。

データを受け取る実装業者に向けて、リファレンス番号を基準にBOMと部品配置データの整合を確認します。参照先のサプライヤーは、BOMを部品識別の記録、部品配置リスト（CPL）を位置、回転角、基板面の記録と説明しています。どちらのファイルも、それ単独では製品バリアント全体を定義できません。 3

ファームウェアと設定を正しいBOMに紐付ける

ファームウェアは、単なる基板名や入手可能な最新ソフトウェア版ではなく、承認済みのハードウェア構成を対象にリリースしなければなりません。アプリケーションイメージ、関連するブートローダの依存関係、対象ハードウェア、設定データセットを指定します。書き込みによって個々の実装基板に属する情報が上書きされないよう、個体固有の校正データと識別データは、共通の設定から分離します。

ビルド対象に基板改訂と修飾情報を組み込み、ハード差を明示できます。しかし選択だけでOEMの任意回路を適格化できず、承認構成には該当証拠が必要です。

独立した選択肢ではなく、完全な組み合わせを承認する

次の互換性マトリクスを、前述の文書例と併せて使用します。「候補として適格」とは、プロジェクトでの妥当性確認後に、その組み合わせをリリース手続きに進められることを意味します。実際の設計がすでに試験に合格したという意味ではありません。

この表は、許可された組み合わせだけを列挙するモデルです。OEMが承認済みの対応関係を追加するまで、記載されていない組み合わせはすべて禁止します。汎用イメージを使用できるのは、プロジェクトが意図するすべての実装構成を明示的にサポートし、ハードウェアの識別情報に基づいて安全な動作を選択する仕組みを検証している場合に限られます。

リリースマニフェストには、変更不能なイメージ識別子と暗号学的ハッシュ値を記録します。書き込みに使用する入力をそのマニフェストと照合し、承認済みの書き込み検証と機能確認を実施します。画面などに表示されるバージョン文字列はトレーサビリティ情報として有用ですが、どのバイナリを書き込んだかを確認する唯一の手段にしてはいけません。メモリ保護により読み戻しができない場合は、承認済みの書き込み検証方法とアプリケーション識別情報の確認を使用します。比較するためだけに保護を無効にしてはいけません。

ハードウェアの識別情報は、実装状態を示す独立した証拠と照合して検証します。設定コードを書き込んで読み戻せても、証明できるのはコードが保存されたことだけであり、オプション回路が存在することではありません。ファイルのハッシュ値は同一性の確認として扱い、リリースマニフェストの真正性は承認済みのリリースプロセスを通じて確認します。

イメージ識別、真正性、互換性を分けます。版、依存関係、署名は異なる承認項目です。有効署名でも任意回路の実装や電気互換は証明できません。別途ハード互換を判断し、該当生産試験を実施します。

製品ラベルと発注可能な品番を割り当てる

製品ラベルと発注用識別子は、購入者が区別する必要のあるソフトウェア制御上の違いも含め、納入される構成を一意に特定できなければなりません。OEMの品目マスターを正式な基準とします。前述の構成の別名は対応関係を説明するためのものであり、実際に承認された購買用識別子の代わりにしてはいけません。

未実装基板の識別子、実装済みハードウェアの識別子、完成品の識別子は分離します。OEMの採番方針によっては、LINKとLINK-LANGが中間段階の実装基板（PCBA）品目を共用し、後工程で異なる設定済み品目になる場合もあります。どの時点でその区別を導入し、どの工程が責任を持つのかを正確に記録します。

顧客が構成を個別に選択する必要がある場合や、承認済みの供給契約上、選択肢同士が相互に置き換えられない場合は、発注可能な識別情報を別に設けます。一方、互換性のある保守用ファームウェアリリースは、既存品目のまま、リビジョンまたは適用範囲の管理で扱える場合があります。すべてのソフトウェアパッチに対して、標準的に新しい取引用品番を割り当ててはいけません。

ラベル版下のリビジョン、承認済みの内容、貼付位置、可変データの取得元を指定します。必要な書き込みと試験が終わった後、その個体のリリース済み構成記録からラベルを生成します。出荷梱包時には、実物の個体識別情報、試験記録、貼付ラベル、受注明細を照合します。個体との対応関係を確認せずにラベルをスキャンするだけでは不十分です。

再印刷とラベルの貼り替えは、例外処理として管理します。ラベルを変更した理由、承認者、旧ラベルをどのように除去または無効化したかを記録します。ラベルの修正だけで、誤った構成の個体を、記録に残さず注文どおりの製品として扱ってはいけません。

部品配置、検査、試験のプログラムをバリアントに対応させる

部品配置、検査、試験の指示は、BOMと同じリリース済みバリアントを参照しなければなりません。形状が共通であることは、検証済みのプログラム要素を再利用する理由にはなりますが、すべての実装基板に対して未確認の単一プログラムを選ぶ理由にはなりません。

ファイル名とともに出力設定も確認してください。配置データ出力には座標、回転、面のほか、バリアントやフィルタの設定が含まれる場合があります。設計画面の状態が全出力を正しく決めると想定せず、生成ファイルを検査します。

文書に記載された手実装部品や部品以外の品目を考慮し、実際の部品配置対象を選択したBOMと比較します。選択した実装構成に照らして、フィーダの割り当て、代替部品、コネクタ固有の取り扱いをレビューします。はんだペーストの塗布を共通化できるか、別のステンシルやディスペンスプログラムが必要かを確認します。未実装基板が共通であっても、この工程上の判断が自動的に決まるわけではありません。

自動光学検査（AOI）では、バリアントごとに期待される部品の有無を使用します。承認済みのDNP位置を部品欠品と判定しないようにしますが、同じ位置について、本来ないはずの部品が実装されていないかを確認する必要がある場合があります。隣接する接合部に引き続き検査が必要な場合、不要な警報を消すために検査領域全体を無効にしてはいけません。

機能試験は、共通の検証範囲にバリアント固有の確認項目を加えて定義します。LOCALでは意図したローカル機能の検証が必要です。LINKには通信確認も必要で、LINK-LANGには設定された言語とインターフェースの確認が追加されます。搭載されない機能に関係する試験をすべて黙って削除するのではなく、その機能がない場合に期待される動作を定義します。

該当する場合は、インサーキット試験でも同じ管理を適用します。選択したハードウェアに対して、必要な試験、意図的に非適用とする試験、禁止する試験を承認します。合格記録から実際に何を試験したかが分かるよう、選択した試験レシピとリビジョンを結果とともに保存します。

構成を混在させずにバリアントをリリースし、検証する

発注可能な識別情報から整合した構成を一意に特定でき、生産経路でその構成を検証できる場合にのみ、バリアントをリリースします。このワークフローでは、ファイルの不整合を最終目視確認で見つけることに頼らず、明示的な保留判定点を設けます。

管理の流れは、発注可能な品目と適用範囲 → 承認済みバリアント記録 → 一意に特定されたBOMと製造用出力データ → 実装状態の検証 → 承認済みの書き込みと設定 → バリアント固有の試験 → ラベルと出荷識別情報の検証、となります。不一致があれば、個体またはリリースパッケージを管理下の保留状態に戻します。

リリース内容を一意に特定してレビューする

OEMの構成管理責任者が、許可する組み合わせを承認します。ハードウェア設計部門は実装部品の依存関係を承認し、ファームウェア設計部門はイメージと設定の互換性を承認します。製造技術部門は工程で使用可能な出力データを受け入れ、品質部門は検証範囲を承認します。複数の役割を同じ人が担当する場合でも、各判断には責任を負う担当者が必要です。

生産前に、すべてのファイルを同じリリース記録と比較します。この段階で、リファレンス番号の相違、互換性のないリビジョン、不足しているラベルルール、曖昧なソフトウェア選択を解決します。承認された変更が進行中の作業を意図せず変えてしまわないよう、パッケージの識別情報と適用範囲を記録します。承認済みの出力ファイルを一括して固定し、製造のたびにパッケージマニフェストを照合します。共通であるはずの基板製造用出力データが引き続き同一であることを確認します。銅箔、穴あけ、基板表記に予期しない相違がある場合は、実装だけが異なるバリアントという前提から切り離して解決する必要があります。

生産経路が誤った構成を排除できるか検証する

異なる実装経路または設定済み製品の経路ごとに適格性を確認し、技術部門が共通性の根拠を示した範囲でのみ証拠を再利用します。誤構成の排除を確認するための管理された検証用記録、または安全な試験条件を用いて、誤ったファームウェア、設定、検査レシピ、ラベルが拒否されることを確認します。管理機能の不備を示すためだけに、互換性のないハードウェアの組み合わせに通電してはいけません。

段取り替え時には、前のバリアントの部品キットとラベル在庫を撤去し、残っている仕掛品の扱いを確定させ、新しいレシピの選択を確認します。異なるバリアントが同じパネルや治具を共用する場合、混在処理を行う前に、個体とその位置を確実に識別できること、および工程振り分け方法の適格性が確認されていることを必須とします。

実際に製造した構成を保存する

実際の製造状態を示す記録は、最新の設計記録とは別に保持します。追跡対象の各個体またはロットに、製造に使用したBOM、実際に使用した承認済み代替部品、書き込んだイメージ、設定、試験結果、ラベル識別情報を紐付けます。必要に応じて校正の参照情報を記録しますが、通常の出荷書類に生産上の機密情報を開示しないようにします。

修理、部品の代替、再書き込みの後は、影響を受ける検証と、必要な回帰確認を再実施します。以前の識別情報は履歴に残します。現在の実物の状態とその記録が受注内容に一致するまで、個体をリリースしてはいけません。

インターフェースと受入文書を規定する

バリアント仕様では、情報を受け取る各工程がリリース済み構成をどう解釈するかを定義する必要があります。パッケージの承認前に、識別子の形式、リビジョンのフィールド、BOMの実装状態の表記規則、部品配置の単位と座標原点、基板面の表記規則、書き込み用アクセス、治具インターフェース、ラベルデータの取得元、試験の判定限界値を合意します。これらはプロジェクト固有のインターフェース要件であり、普遍的な数値しきい値ではありません。

組立・接合の仕上がり品質の受入判定と、構成の受入判定は分離します。IPCが公開しているJ-STD-001プログラムの説明では、はんだ接続の受入基準と組立要件を扱っています。契約では適用する規格リビジョンと合意した追加事項を明記する必要があります。一方、バリアント記録では、顧客が発注したハードウェアとソフトウェアを別途特定しなければなりません。一般的な仕上がり品質の合格を、設定済み製品のリリース判断の代わりにしてはいけません。 7

サプライヤーとの契約で、文書の優先順位と不整合時の処理を定義します。BOM、図面、ソフトウェアマニフェストが一致しない場合は、対象の製造を保留し、承認済みの解決策を得ます。最も新しく見える文書を選ぶよう、生産担当者に求めてはいけません。

一般的なOEM業務にバリアントモデルを適用する

共通のハードウェアプラットフォームで、個別に発注できる異なる機能に対応する場合、バリアントモデルが役立ちます。以下は構成管理を計画するための適用シナリオであり、完了した顧客案件についての実績説明ではありません。

通信機能をオプションとする産業用制御

ローカルコントローラとネットワーク対応コントローラでは、通信機能に必要なすべての実装部品を、正しいアプリケーションおよびコネクタラベルに紐付けます。有効なインターフェースを試験し、インターフェースがない場合の定義済み動作も検証します。必要な周辺回路がないのにコネクタだけを実装した状態を、そのオプションの中間的な解釈として認めてはいけません。

照明をオプションとするヒューマンマシンインターフェース（HMI）

照明付きと照明なしのインターフェースでは、LEDの実装、電流制御部品、ファームウェアの動作、前面パネルの版下をまとめてレビューします。電気的要件と光学的要件を検証した後にのみ、照明付きの組み合わせをリリースします。共通のスイッチ機能は、両方の構成で試験範囲に含めます。

センシング用ハードウェアを選択できる計測器

異なるセンサや測定用部品の実装構成では、承認済みの部品選択を、入力設定、校正手順、試験の判定限界値に紐付けます。未実装基板の識別子が一致するという理由だけで、校正データを再利用してはいけません。どの校正データセットがどの実物の個体に属するかを記録します。

電子回路を共用し、操作言語をローカライズする製品

言語別の製品では、版下だけが変わるのか、ファームウェアのリソースや実行時設定も変わるのかを明確にします。LINKとLINK-LANGは、ハードウェアを共用する例です。工場出荷時設定へのリセット後の動作も含め、表示される指示と実物の表記が、注文された言語と一致することを確認します。

保守交換と改修

交換用実装基板については、対応が認められる設置済み機器の構成を指定します。発送前に、承認済みのコネクタ、ファームウェア、設定の対応関係を確認します。後の基板リビジョンなら以前のすべてのバリアントを置き換えられると仮定せず、必要な変換や再書き込みは管理された作業として扱います。

よくある質問

JASPER向けのバリアントパッケージを準備する

発注可能な各品目を、共通基板、実装部品表、オプション、ファームウェア、設定、ラベル、試験要件に紐付ける構成マトリクスを1つ用意します。承認済みの組み合わせ、禁止する組み合わせ、バリアント別数量、各リリース判断の責任者を含めます。

JASPERのプリント基板実装サービスのレビューには、基板製造パッケージ、バリアント別の実装用出力データ、書き込み要件、受入基準をまとめて提示してください。設定とラベル貼付をPCBA実装段階で行うのか、その後の製品統合段階で行うのかを明示します。

最後に、実務上の1つの問いを確認してレビューを締めくくります。サプライヤーは、文書化されていない構成判断を行わずに、注文されたバリアントを選択、製造、試験、識別できるでしょうか。答えが「はい」である場合にのみ、生産を許可します。