PCBA製造リリースパッケージとは、メーカーが何を製造し、書き込み、検査し、納入してよいかを定義する、承認済みのファイルと指示書の一式です。承認された変更によってその定義が変わる場合は、管理対象のベースラインを更新します。図面の訂正では、物理的な基板のリビジョンを変えずに文書の改訂が必要になることがあります。また、ファームウェアや試験の変更では、PCB自体が変わらなくても新しいリリースが必要になることがあります。ファイルをリリースする前に、自社の文書管理規則と契約上の要求事項に従い、影響を受ける項目、承認された組合せ、製造への適用条件を決定してください。
- リビジョンに関する曖昧な判断が製造リスクを生む理由
- PCBAリリースパッケージの管理対象を定義する
- 製造する内容を明確にする
- リリースの識別情報と製品の識別情報を分ける
- 編集上の訂正と製造変更を区別する
- BOM、レイアウト、ファームウェア、試験要求事項の変更を評価する
- 部品だけでなく、承認の範囲を確認する
- 在庫、仕掛品、新規受注への適用条件を定める
- 封じ込めと最終処置を分ける
- 承認、旧版ファイル、許可された組合せを記録する
- 許可された組合せと過去の版へのアクセスを管理する
- 10の基準でリリースパッケージを評価する
- 6段階で変更をレビューし、引き継ぐ
- ステップ1:提案された変更を登録する
- ステップ2:項目と製造対象群を対応付ける
- ステップ3:技術的な処置を承認する
- ステップ4:適用条件と責任事項に合意する
- ステップ5:管理されたリリースを発行する
- ステップ6:実施を検証し、変更を完了する
- メーカーが確認できるリリースマニフェストを発行する
- 記入済みマニフェストの例
- 実行内容に即した確認を求める
- リリースを保留または上位判断に回す8つの理由
- よくある質問
- 図面を訂正するたびに、PCBAの新しいリビジョンが必要ですか?
- 基板のリビジョンを変えずにファームウェアを変更できますか?
- 既に進行中の作業には、技術変更をどのように適用しますか?
- リリースパッケージのマニフェストには何を含めますか?
- 旧版ファイルが使われていないことを、サプライヤーはどう確認できますか?
- 既に承認されている代替部品でも、追加の改訂が必要ですか?
- 試験限界値を変更しても、ハードウェアのリビジョンを維持できますか?
- リリースパッケージ内のすべてのファイルは、同じリビジョンでなければなりませんか?
- 一時的な逸脱許可は、恒久的なリリース変更と同じですか?
- 次の製造引継ぎを準備する
リビジョンに関する曖昧な判断が製造リスクを生む理由
リビジョンに関する判断が曖昧だと、購買、製造、品質の各部門が、同じ実装基板について異なる定義に基づいて作業することになります。直接のリスクは、フォルダーが整理されていないことではありません。製造で使えない材料を購入すること、互換性のないイメージを書き込むこと、あるいは誤った要求事項に基づいて基板を合格と判定することです。
銅箔レイアウトは同一のまま、ファームウェアだけが変わるコントローラーを考えてみてください。未実装のプリント基板のリビジョンを維持することには合理性がありますが、メーカーに「何も変わっていない」と伝えることには合理性がありません。書き込み用イメージ、互換性の記録、影響を受ける試験指示は、引き続き確認が必要です。逆に、新しいリビジョン記号にそろえるためだけに、変更のないファイルをすべて改訂すると、実際の技術変更が見えにくくなることがあります。
リリースのレビューは、ファイル名ではなく、製造を何について許可するかの判断として扱います。誰が変更を承認できるのか、どの証拠が変更を裏付けるのか、どの製品に影響するのか、既存在庫をどうするのかを確認してください。部品を交換する費用だけを比較するのではなく、材料の発注・確保に伴う義務、治工具、手直し、検証、納入への影響を併せて評価します。
PCBAリリースパッケージの管理対象を定義する
PCBA製造リリースパッケージでは、承認済みの製造ベースラインと、合意した製造範囲に必要なすべての参照項目を特定する必要があります。未実装のプリント基板、実装済み製品、個々の文書、ファームウェア、試験リソース、リリースマニフェストには、それぞれ別の識別情報を持たせます。これらのリビジョン識別子を一致させる必要はありません。
参照先のサプライヤーは、PCB製造データ、部品表(BOM)、部品配置リスト(CPL)を区別しています。BOMは部品をリファレンス番号に対応付け、部品配置リストは位置、回転角度、基板面を定義します。 変更が実際に何に影響するかを判断する際は、この区別を用いてください。
製造する内容を明確にする
合意した基板製造データと製造要求事項、BOMと承認済み代替品、部品配置データ、さらに向き、未実装とする位置、特殊作業を扱う実装図を含めます。メーカーがフォルダー名から製品を推測しなくて済むように、実装基板の品番とバリエーションを明記してください。
書き込みまたは試験を行う実装基板では、承認済みファームウェアイメージ、書き込み指示書、設定データ、受入要求事項、試験手順、および該当する治具や試験ソフトウェアのリビジョンを含めるか、参照先を示します。ラベル表示、梱包、組込みに関する要求事項が契約範囲に含まれる場合は、それらも追加します。該当しない作業は、理由の分からないファイル欠落として残すのではなく、対象外であることを範囲の記述で明示してください。
リリースの識別情報と製品の識別情報を分ける
パッケージ識別子を用いて、管理対象項目の特定の組合せをひも付けます。例えば、1つのリリースにPCBリビジョンB、実装基板リビジョンD、ファームウェア2.4.1、試験手順07が含まれる場合があります。この組合せが有効なのは、互換性に関する判断によって承認されている場合だけです。リビジョン記号が一致していることは、受入基準ではありません。
編集可能な設計ソースは設計管理下に置き、実作業の正式な基準となる製造用出力データを特定します。ソース管理のコミットは設計のスナップショットを識別できますが、メーカーにはリリース済みの出力データと、その承認状態も必要です。これらの出力データから変換された機械プログラムや、派生したサプライヤーの作業指示書については、管理責任を持つ組織と元のベースラインを併せて記録してください。
編集上の訂正と製造変更を区別する
編集上の訂正とは、製品定義、製造上の解釈、受入判定を変えずに表現を変更することです。製造変更は、製造してよい内容、または適合性をどのように確認するかを変えます。承認権限者は実際の影響を分類しなければならず、「誤字」や「軽微」という説明だけを十分な根拠として受け入れてはなりません。
NASAの構成管理ガイダンスは、重大な技術変更と軽微な技術変更を区別し、承認された適用免除をベースライン変更とは別に扱っています。 これらの区別は参考になる考え方ですが、PCBAに共通するリビジョン記号のルールでも、自社が採用している要求事項の代わりでもありません。
技術的な意味を持たない見出しの綴りを訂正する場合、実装基板のリビジョンは変更しないことがあります。それでも、訂正した文書は、自社システムで認められたリビジョン、バージョン、または管理された訂正の仕組みによって識別してください。契約や図面管理規則によっては、リリース済み文書の変更ごとに図面改訂が必要です。発行済みファイルを黙って上書きしてはいけません。
「上面」を「下面」に変更する、極性の注記を逆にする、部品定数を訂正する、抜けていた受入条件を追加するといった変更は、作成者が訂正と呼んでいても、製造での作業を変える可能性があります。影響を受ける製造状況を確認し、差替え指示を発行する前に保留が必要かを判断してください。
恒久的な変更と一時的な例外を分けます。逸脱許可では、対象の要求事項、認める差異、数量または製造範囲、有効期限の条件、承認、検証を定める必要があります。逸脱許可が暗黙のうちに次の恒久的なベースラインになることはありません。同様に、要求事項を変更しても、不適合在庫の出荷が自動的に許可されるわけではありません。
組織によっては、管理対象に応じて技術変更指示(ECO)、製造変更指示(MCO)、文書変更指示(DCO)を使い分けます。Arenaは、これらを選択可能な変更管理の仕組みとして説明しています。 自社が承認した仕組みを使用してください。相互交換性や製品の識別が変わる場合は、単にリビジョンを進めるのではなく、実装基板に新しい品番が必要かを設計権限者に確認します。
BOM、レイアウト、ファームウェア、試験要求事項の変更を評価する
BOM、レイアウト、ファームウェア、試験の変更では、編集したファイルが1つだけでも、リリースパッケージ全体への影響を確認する必要があります。以下のマトリクスをレビューに使用し、その後、影響を受ける項目のうち何を変更し、何を引き続き有効とするかを、根拠とともに記録してください。
| 変更の種類 | 影響を受けるリリース項目 | 技術レビュー | 適用条件に関する確認事項 | 必要な記録 |
|---|---|---|---|---|
| BOM上の部品代替 | BOM、承認部品リスト。影響がある場合は実装、書き込み、試験の文書 | 正確な部品、電気的動作、フットプリント、熱的限界、互換性を比較し、適格性確認の証拠を定める | その代替品は、この構成で既に承認されているか。それとも承認は特定のロットだけに適用されるか | 代替承認、適格性確認の参照記録、改訂BOMまたは範囲を限定した逸脱許可、材料の処置 |
| レイアウト更新 | PCBデータ、基板製造図、部品配置ファイル。影響がある場合はメタルマスク、実装図、治具 | 接続、形状、インターフェース、製造用出力データ、検証範囲を確認する | どの未実装基板ロットと実装指図で新しいレイアウトを使えるか。旧基板はどう処置するか | 設計承認、影響を受ける出力データ一覧、治工具に関する判断、検証記録、切替境界 |
| 実装注記の変更 | 実装図、および派生する作業指示書や検査指示書 | 文言によって実際の作業、向き、材料、受入れの解釈が変わるかを判断する | 旧指示に従って、対象工程を既に通過した製品はあるか | 変更箇所を明示した資料、分類の根拠、承認、指示書の差替え、仕掛品(WIP)の処置 |
| ファームウェア更新 | バイナリ、書き込み指示書、設定対応表、リリースノート、影響を受ける試験 | ハードウェア互換性、初期化、保持されるデータ、機能変更、検証を確認する | 未書き込み、書き込み済み、完成済み、出荷済みのどの製品に対応が必要か | 承認済みイメージの識別情報、互換性の判断、書き込みと検証の記録 |
| 試験限界値の変更 | 受入仕様、試験手順、限界値ファイル、試験ソフトウェア、報告書 | 限界値を決める設計権限を確認し、方法、条件、影響を受ける受入判定を評価する | 過去の製品を再確認または再試験する必要があるか。元の測定値は再評価の根拠になるか | 要求事項の承認、妥当性確認済みの試験リビジョン、遡及評価、処置 |
| バリエーション追加 | バリエーション別BOM、実装基板の識別情報、実装・未実装の指示、ファームウェア、ラベル、試験 | 基本製品の承認がそのまま適用されると考えず、構成全体と除外事項を承認する | どの受注明細と識別子で、新しいバリエーションを既存在庫から区別するか | バリエーションの承認、許可された組合せの記録、表示規則、マニフェスト更新 |
部品だけでなく、承認の範囲を確認する
リリース済みBOMで既に使用が認められている部品の購入は、必ずしも技術変更にはなりません。その承認範囲に新しい代替品を追加することは別です。製品リビジョンが変わらない場合でも、合意した製造トレーサビリティの仕組みで、実際に実装した材料を記録してください。
レイアウト変更では、どの出力データと製造リソースを再作成または再度妥当性確認する必要があるかを判断します。パッケージ番号が変わったという理由だけで、新しいメタルマスクを要求してはいけません。試験変更では、製品要求事項の変更と、試験実施方法の訂正を区別します。原因不明の不合格を合格に変えるためだけに、限界値を緩めてはいけません。元の測定値を保存し、その後の再評価は別に識別します。過去のデータを再利用できるのは、その測定条件と範囲が新しい判断を裏付ける場合だけです。報告書を改訂しても、実施していない試験を実施済みにすることはできません。
在庫、仕掛品、新規受注への適用条件を定める
適用条件は、リリースされた構成をどの製品または製造上のイベントに適用するかを示します。それだけで、既存材料を使用、手直し、出荷してよいかが決まるわけではありません。切替境界と、影響を受ける各対象群の処置の両方を明記してください。
適用範囲は、追跡システムの構成に応じて日付、ロット、シリアル番号、製造順序、ブロックで定義できます。工場が実行・照合できる方法を選定してください。これらは実装方法の選択肢であり、PCBAの必須品質等級ではありません。
| 適用条件の種類 | 有用な製造上の境界 | 必要な管理 |
|---|---|---|
| 日付 | 特定した製造イベントで行う、明確に定義された切替え | イベント、タイムゾーン、境界をまたぐ作業の扱いを指定する |
| ロット番号 | 特定されたロットを、その内部で管理された状態に保つ | 製品とロットの識別子を定義し、構成を混在させる前にロットを分割するか、ラベルを付け直す |
| シリアル番号 | 個々の製品に異なる構成や改修判断が必要な場合 | 両端を含む範囲、除外対象、対象の実装基板または最終製品を指定する |
| 製造シーケンス番号 | 計画システムが管理された製造順序を割り当てる場合 | シーケンスが実際の製品に対応することを確認し、時系列順に完成するとは考えない |
| ブロック番号 | あるプログラムが製品群を管理対象のブロックとして定義する場合 | ブロックに含まれる製品と製造記録との対応を定義する |
適用境界を明記してください。個別値、閉じた範囲、分離した範囲、終端未定の範囲を使う場合があります。計画上の適用と実際の量産切替えを別々に記録します。承認日だけでは、資材払出し、組立開始、書込み、最終受入れのどこで切り替えるか決まりません。購買・製造指図の明細を選定仕様に紐付けてください。「新規注文すべて」では、既存の未着手注文を判断できません。
封じ込めと最終処置を分ける
まず、購入済み部品、未実装基板、キット、部分実装品、書き込み済み製品、完成品、関連する出荷済み製品を特定します。扱いが不明確な対象群は保留にします。その後、該当する処置として、旧構成での継続使用、手直しと再検証、サプライヤーへの返品、廃棄を承認します。保留は封じ込めであり、最終処置ではありません。
具体例として、120台からなる架空のロットL061を考えます。24台は書き込み済み、36台は実装済みで未書き込み、60台は未着手です。L061全体に適用するファームウェアの切替えでは、この3つの群すべてを扱わなければなりません。最初の24台には承認済みの更新・検証手順が必要で、次の36台には新しいイメージが必要です。残りの60台には、新しい製造指示一式が必要です。それ以前の完成済みロットを引き続き納入できるかどうかは、別に判断してください。
承認、旧版ファイル、許可された組合せを記録する
承認記録では、承認した変更を、技術的証拠、実施範囲、許可された構成にひも付ける必要があります。メーカーの受領確認は、設計権限者による技術変更の承認と同じではありません。また、そのどちらも、製造で変更が実施された証拠にはなりません。
影響に応じてレビュー担当を割り当てます。回路と材料はハードウェア技術、実行時の動作はファームウェア技術、受入れは試験技術と品質、実施と各種の確約事項は製造と購買が担当します。適用される合意で要求される場合は、顧客やその他の必要な承認を追加してください。すべてのレビュアーに製造を許可する権限があると考えず、リリース権限者を特定します。
変更履歴には、旧項目と置換項目の識別情報、理由、影響を受ける製品、レビューの証拠、承認、適用条件、実際の実施状況を残します。NASAの構成状態に関するガイダンスでは、現在と過去の構成識別情報、および実施までの変更状態を重視しています。
許可された組合せと過去の版へのアクセスを管理する
架空のコントローラーでは、実装基板A100-STDリビジョンDと、PCB B、BOM D、ファームウェア2.4.1、機能試験手順07の組合せを承認します。旧ロットについては、明示的に承認された場合、実装基板リビジョンCと、PCB B、BOM C、ファームウェア2.4.0、手順06の組合せを維持できます。各ファイルが個別にリリースされていても、一覧にない組合せが承認されたことにはなりません。
置き換えられた旧版ファイルは、製造で通常選択する対象から外す一方、トレーサビリティと承認済みの旧構成作業のため、管理されたアーカイブに保管します。メーカーに、差し替えた作業端末上のファイル、オフラインコピー、印刷指示書、派生する機械プログラムを特定してもらってください。対象の製造指図で実際に選択されているものを検証し、旧構成の例外を記録します。履歴の削除は、意図しない使用を防ぐための確実な代替策にはなりません。
10の基準でリリースパッケージを評価する
リリースパッケージのレビューでは、メーカーが文書化されていない技術判断を行わずに、承認済み構成を特定して実行できるかを確認します。以下の10の基準は、引継ぎの評価に使用してください。裏付けのない主張を基にサプライヤーを順位付けするためのものではありません。
| 評価基準 | 良好な兆候 | 警戒すべき兆候 |
|---|---|---|
| 1. 製品の識別情報 | 実装基板、未実装基板、バリエーションが明確に区別されている | 1つのリビジョン表示ですべてを表せると考えている |
| 2. 管理対象の内容 | 必要なすべてのファイルまたは管理された参照先をマニフェストが特定している | 受領者がメール履歴からベースラインを組み立てなければならない |
| 3. 変更の分類 | 実際の影響と承認経路が記録に説明されている | 「軽微な訂正」だけが根拠になっている |
| 4. 依存関係の確認 | 変更する項目と維持する項目の判断が文書化されている | 編集したファイルしか検討していない |
| 5. 互換性 | ハードウェア、BOM、ファームウェア、試験の組合せが承認されている | 個別にリリースされたファイルを、レビューせずに組み合わせている |
| 6. 製造への適用条件 | 境界によって製品と実行イベントが特定されている | 「直ちに使用」しか指示されていない |
| 7. 既存材料の処置 | 在庫とWIPの対象群に担当者と判断が設定されている | 旧在庫は使用可能、または自動的に廃棄対象だと考えている |
| 8. 受入れの証拠 | 必要な検証と記録が変更に対応している | 検証計画なしで新しい要求事項が承認されている |
| 9. 旧版ファイルの管理 | 現行使用の管理と旧構成の例外が示されている | 「メールを削除した」ことしか証拠がない |
| 10. 実施の完了 | 対象の製造指図で、承認された段取りと構成を確認できる | ZIPの受領を、実施完了として扱っている |
6段階で変更をレビューし、引き継ぐ
変更レビューのワークフローでは、承認されたベースライン、実行可能な切替え、その切替えが行われた証拠を整える必要があります。以下の6段階は、既存の承認システムに合わせて調整してください。そのシステムを迂回する並行プロセスを作ってはいけません。
ステップ1:提案された変更を登録する
現行リリース、対象製品、理由を特定します。提案する差異と、直ちに行う封じ込めを記録してください。変更責任者は、影響を評価している間、購買、製造、出荷を停止する必要があるかを明示します。
ステップ2:項目と製造対象群を対応付ける
提案は、最新の作業フォルダーではなく、実際にリリースされたベースラインと比較します。変更マトリクスを使って、依存するファイル、工具、試験リソースを特定してください。適用条件を選ぶ前に、製造部門から在庫とWIPの状況を入手します。
ステップ3:技術的な処置を承認する
互換性、必要な検証、維持する項目の根拠を記録します。文書改訂、実装基板のリビジョン変更、新しい品番、一時的な逸脱許可のどれが適切かを判断してください。変更後の製造を許可する前に、指定された権限者を通じて技術的な疑問を解決します。
ステップ4:適用条件と責任事項に合意する
切替境界と、既存の各対象群の処置を指定します。手直し、交換材料、検証、費用や日程の変更について、責任を割り当ててください。商取引上の確認が、適格性未確認の代替品を使う承認と誤認されないようにします。
ステップ5:管理されたリリースを発行する
承認済み出力データを凍結し、マニフェストを発行して、どのリリースを置き換えるかを特定します。管理されたパッケージ一式、または曖昧さのない管理された参照先を送付してください。メーカーには、対象リリースを正確に特定した確認と、未解決の実施条件の確認を求めます。
ステップ6:実施を検証し、変更を完了する
最初の対象製造指図を、プログラムと試験の選択を含めて、マニフェストと照合します。対象数量、維持する例外、実際の切替記録を突き合わせてください。指定した実施の証拠と処置がすべて整うまで、変更を未完了のまま管理します。
メーカーが確認できるリリースマニフェストを発行する
リリースマニフェストは、製品の識別情報、承認済みファイルの版、変更の承認権限、適用条件、実行条件を、1つの識別可能な引継ぎにまとめるものです。これは索引と承認参照であり、記載した技術ファイルの代わりではありません。
記入済みマニフェストの例
以下は、架空のコントローラーのリリース例です。ECO-017では、元の部品を維持しながら承認済みのU3代替品を追加し、関連する書き込み、試験、ラベル表示の更新とともにファームウェア2.4.1を導入します。PCBの形状は変更しません。識別子と承認は、プロジェクト固有の仕組みを説明するためのものであり、JASPERの実際の製造記録ではありません。
| マニフェスト項目 | 記入例 |
|---|---|
| パッケージと製品 | REL-A100-013、実装基板A100-STDリビジョンD、標準バリエーション |
| 変更と承認 | ECO-017。設計、ファームウェア、試験、品質、製造運営の承認を記録済み。構成管理責任者がリリースを許可 |
| 管理されたソース | 管理保管庫の変更不能なスナップショットREL-A100-013。以下の製造用出力データを実行ベースラインとする |
| 変更のない基板と配置 | PCB-B-fabrication.zip、PCB-B-placement.csv。ECO-017のレビューに基づき維持 |
| BOMと実装図 | BOM-A100-D.xlsx、ASSY-A100-D.pdf。U3代替品の適格性確認Q-U3-02 |
| ファームウェアと書き込み | A100-2.4.1.bin、PROGRAM-A100-03.pdf |
| 受入れと試験リソース | FCT-A100-07.pdf、TEST-RUNNER-A100-07.zip、治具FT-A100-02 |
| ラベルと互換性の記録 | LABEL-A100-04.pdf、CONFIG-A100-04.xlsx |
| 適用条件 | ロットL061全体、製造指図WO-061、数量120。このリリースは後続の指図を自動的に許可するものではない |
| WIPの処置 | 書き込み済み24台を更新・検証、実装済み36台を書き込み・試験、未着手60台をリリース013に従って製造 |
| 旧構成の使用許可 | 完成済みロットL060はECO-017に基づきリリース012を維持。それ以外の旧構成の使用は許可しない |
| 置き換えられるリリース | REL-A100-012をL061では使用不可とする。アーカイブに保管し、承認済みのL060関連作業に限りアクセス可能 |
| メーカーの確認 | ACK-A100-013。受領者ME-01、製造技術。2026-09-21の10:00 UTCに受諾。L061の再開前に段取りの検証が必要 |
| 実施完了の条件 | ECO-017を完了する前に、IMPL-A100-013で承認済み段取りを記録し、120台すべてを照合すること |
パッケージ欄は引継ぎを識別し、ファイル欄は実行する内容を識別します。適用条件は対象群を選び、処置は実施する行為を許可し、完了参照は証拠の所在を示します。既存のU3部品を維持できるのは、引き続き有効なBOMの承認条件に適合することを確認した後だけです。この例を自社に適用する際は、例示の識別子や許可内容をコピーするのではなく、自社の管理記録から各欄を記入してください。
実行内容に即した確認を求める
この例について、実用的な記入済み確認文は次のようになります。「ME-01、製造技術、2026-09-21、10:00 UTC:WO-061/L061、120台に対するリリースREL-A100-013を受諾します。記載されたファイルにアクセスでき、書き込み済みWIPの更新手順を受け入れ、当該製造指図ではリリース012を使用不可にしています。ロットL060は別管理を維持します。L061を再開する前に、段取りの検証をIMPL-A100-013に記録します。」
この確認とともに、受領者の識別情報、受諾日、例外事項を求めてください。「ファイルを受け取りました」だけの返信は、転送ができたことを確認するものです。適用条件、WIPの扱い、リリースの実行準備について合意したことにはなりません。
リリースを保留または上位判断に回す8つの理由
未解決の問題により、メーカーが製品定義や受入基準を選ばなければならなくなるおそれがある場合は、リリースを保留するか、上位判断に回してください。不確実性のため対象範囲自体を特定できない場合を除き、保留は影響範囲に限定します。
- 2つのファイルが同じ管理識別情報を持ちながら、異なる製造指示を含んでいる。
- 訂正した注記が、影響に関する判断なしに、極性、基板面、受入れの解釈を変えている。
- 新しい代替部品について、実際のハードウェアとファームウェアの組合せでの承認がない。
- 提案された試験変更が、技術的説明と承認された要求事項の判断なしに、不合格を減らしている。
- どの在庫やWIPが適用境界の内側に入るのかを、製造側が特定できない。
- ファームウェア更新について、既存製品向けの承認済み書き込み、互換性確認、検証の手順がない。
- 管理された旧構成の例外がないのに、対象の製造指図で旧版ファイルを引き続き選択できる。
- 必要な承認や実施条件が欠けているのに、指図が製造準備完了とされている。
技術的な不確実性は担当の技術権限者へ、受入れの不確実性は品質と試験の責任者へ、材料や日程の対立は製造運営と購買へ回します。誰が保留を解除できるか、どの証拠が必要かを記録してください。
よくある質問
以下のリリースパッケージに関する質問では、リビジョンの識別、製造への切替え、メーカーの確認を扱います。回答は、適用される社内手順と、対象の実装基板について合意した要求事項を通じて適用してください。
図面を訂正するたびに、PCBAの新しいリビジョンが必要ですか?
いいえ、すべての図面訂正で、実装基板や未実装基板の新しいリビジョンが必要になるわけではありません。表現だけの訂正であれば製品は変わらないことがありますが、訂正した文書には、手順や契約が要求する管理上の処置が引き続き必要です。製造上の解釈、受入れ、相互交換性に影響する変更には、技術的影響に関する判断が必要です。
基板のリビジョンを変えずにファームウェアを変更できますか?
はい、物理的なPCBのリビジョンを維持したまま、ファームウェアを変更できます。承認済みイメージを、その書き込み指示、互換性のあるハードウェア、該当する試験リビジョンとともにリリースしてください。実装基板の識別情報も変更するかどうかは、自社の製品管理規則によって決まります。更新が、書き込み済み、未書き込み、完成済みのどの製品に影響するかを記録します。
既に進行中の作業には、技術変更をどのように適用しますか?
メールの日付だけではなく、承認された適用条件と処置の判断を通じて変更を適用します。対象となる各製造指図、ロット、またはシリアル番号で特定される対象群と、完了済み工程を特定してください。何を継続できるか、何を保留するか、何に手直しや検証が必要かを判断します。変更後の構成と併せて、元の記録も保存してください。
リリースパッケージのマニフェストには何を含めますか?
マニフェストには、パッケージと製品の識別情報、管理されたファイルのリビジョン、バリエーション、承認参照、適用条件、既存材料の処置が必要です。該当する場合は、ファームウェア、試験リソース、ラベル表示に加え、旧リリースの扱いと確認要求も含めてください。変更のない項目を管理された参照によって維持する場合でも、実行可能なベースライン全体を特定する必要があります。
旧版ファイルが使われていないことを、サプライヤーはどう確認できますか?
サプライヤーは、対象の製造指図で旧版ファイルが通常の選択対象から除外され、作業端末、オフライン、印刷物の各コピーが管理されていることを示す必要があります。実際の対象段取りで、置換後のベースラインを確認してください。過去のファイルはアーカイブに保管し、承認された旧構成の使用は、明記された対象群に限定します。
既に承認されている代替部品でも、追加の改訂が必要ですか?
その正確な代替品が、対象の実装基板、バリエーション、適用条件ですでに許可されている場合は、必ずしも必要ではありません。以前のプロジェクトの承認が引き継がれると考えず、承認範囲を確認してください。実装した材料は、要求に従って記録します。代替品の追加、条件の変更、適用範囲の拡大には、新たな承認判断が必要です。
試験限界値を変更しても、ハードウェアのリビジョンを維持できますか?
はい、試験限界値の変更で物理的なハードウェアが変わらない場合もあります。ただし、受入れの定義と影響を受ける試験リソースは、引き続き管理が必要です。要求事項の技術承認を得て、過去の判定を評価してください。保存された測定値が再評価を裏付けるか、再試験が必要かを判断します。元の結果を書き換えてはいけません。
リリースパッケージ内のすべてのファイルは、同じリビジョンでなければなりませんか?
いいえ、別々に管理する項目は、異なるリビジョン識別子を持つことができます。リリースマニフェストは、承認された正確な組合せを特定し、どの項目を変更または維持したかを説明する必要があります。文書管理システムで要求されない限り、見た目をそろえるためだけに、変更のないファイルのリビジョンを進めてはいけません。また、記号の一致を互換性の証拠として扱ってはいけません。
一時的な逸脱許可は、恒久的なリリース変更と同じですか?
いいえ、一時的な逸脱許可は、定められた限界内で特定の例外を認めるものであり、恒久的なベースラインを自動的に改訂するものではありません。対象の要求事項、許可する差異、製造範囲、有効期限、承認、検証を特定してください。恒久的な変更は、該当するリリース手順に従う必要があります。また、逸脱許可の対象製品は、引き続き追跡可能でなければなりません。
次の製造引継ぎを準備する
次のPCBA引継ぎの前に、現行マニフェスト、提案変更の要約、影響項目マトリクス、在庫とWIPの状況、互換性の判断、必要な承認記録を用意します。変更後の製造を許可する前に、リリースの識別情報、切替境界、処置責任者、メーカーの確認について合意してください。
JASPERのプリント基板実装サービスに問い合わせる際は、この管理されたパッケージと、希望する実装、書き込み、検査、試験の範囲を提示してください。ファイルをアップロードしただけで製造が許可されると考えず、レビューを通じて、承認された製造構成と未決事項を明確にします。
プロジェクトを始めませんか?
メンブレンスイッチ、キーパッド、グラフィックオーバーレイの要件をお知らせください。当社の技術チームが仕様を確認し、詳細な見積もりを提示します。


