Die PCB-Validierung ist am besten als eine Abfolge von Stage Gates (EVT, DVT, PVT) zu verstehen, nicht als ein einzelner Moment des Bestehens oder Nichtbestehens.
Der Begriff "Software Validation PCB" ist für sich genommen irreführend; das eigentliche Thema ist die Hardware-Validierung, wobei das Firmware-Bring-up auf einer Platine aufsetzt, die bereits überprüft wurde.
Jedes Gate stellt eine andere Frage, und im Voranschreiten, bevor das aktuelle Gate zufriedenstellend passiert wurde, verstecken sich die meisten Validierungskosten.
Das Bring-up von Firmware und Software hängt davon ab, dass Stromversorgung (power), Signalintegrität (signal integrity) und thermisches Verhalten (thermal behavior) zuerst validiert werden, andernfalls debuggt das Softwareteam Hardwarefehler, die als Code-Bugs getarnt sind.
Belassen Sie Validierungsaussagen auf der Stufenebene (stage level). Ein Gate bestätigt die Bereitschaft zum Fortfahren; es verspricht keine Zertifizierung, keine finale Freigabeautorität und keine feste Ausbeute (yield).

Kurze Antwort Die PCB-Validierung ist die stufenweise Bestätigung, dass eine Platine das tut, was das Design vorgesehen hat, bevor sie in Serie geht. EVT, DVT und PVT sind die üblichen Gates, jedes mit seinen eigenen Eintritts- und Austrittsbedingungen. Wenn Leute von einem software validation PCB sprechen, ist die nützliche Lesart: eine Platine, deren Hardware so weit validiert wurde, dass beim Firmware-Bring-up der Code getestet wird und nicht die Platine. Die praktische Freigabefrage (release question) lautet nicht Hat sie einmal gebootet?. Sie lautet Hat jedes Gate das Energie-, Signal-, thermische und Montageverhalten bestätigt, bevor die nächste Stufe und der Software-Stack (software stack) sich darauf verlassen?

Inhaltsverzeichnis

Was PCB-Validierung eigentlich bedeutet (und was "Software-Validierung" hier bedeuten sollte)
Die Stufentore (Stage Gates) EVT / DVT / PVT
Warum die Hardware-Validierung dem Firmware-Bring-up vorausgehen muss
Eine Validierungs-Checkliste vor den Stufen
Welches Paket die jeweilige Validierungsstufe unterstützt
FAQ
Öffentliche Referenzen
Autoren- und Revisionsinformationen

Was PCB-Validierung eigentlich bedeutet (und was "Software-Validierung" hier bedeuten sollte)

Beginnen Sie damit, zwei Konzepte zu trennen, die oft zu einem Satz zusammengefasst werden.

"PCB-Validierung" ist der Prozess der Bestätigung, dass sich eine hergestellte Platine so verhält, wie es das Design vorgesehen hat: Stromschienen (rails) fahren in der richtigen Reihenfolge hoch, Hochgeschwindigkeitsnetze (high-speed nets) erreichen ihre Integritätsziele, der Wärmepfad leitet die Wärme ab, und die Montage (assembly) führt keine Defekte ein, die statische Prüfungen (static checks) übersehen. Dies ist Hardwarearbeit und erfolgt in Stufen (staged).

"Software-Validierung" ist eine separate Aktivität, die auf validierter Hardware läuft. Ein Board wird nicht einfach durch Kategorisierung zu einem "Software-Validation-PCB". Was die Leute normalerweise meinen, ist ein Board, das so weit validiert wurde, dass das Bring-up von Firmware und Anwendungen auf einer stabilen Plattform fortgesetzt werden kann. Wenn die zugrunde liegende Hardware ihre Gates nicht passiert hat, dann validiert das Laden von Software darauf nicht die Software. Es mischt lediglich zwei Unbekannte.

Die ehrliche Umformulierung lautet also: Es gibt keine spezielle Produktklasse namens Software-Validation-PCB. Es gibt eine Platine, die durch EVT, DVT und PVT läuft, und es gibt einen Punkt in dieser Abfolge, an dem die Hardware stabil genug ist, damit ein Firmware-Bring-up eine Bedeutung hat. Die Aufgabe der Validierung besteht darin, diesen Punkt ganz bewusst, Gate für Gate, zu erreichen und ihn nicht einfach vorauszusetzen.

Für den breiteren Konstruktionskontext, der diese Gates speist, ist die nächste Support-Seite PCB Stack-Up, und für den frühen Build-Kontext PCB Prototype.

Die Stufentore (Stage Gates) EVT / DVT / PVT

Behandeln Sie EVT, DVT und PVT als Checkpoints (Prüfpunkte), die jeweils eine Eintrittsbedingung (was zutreffen muss, um zu beginnen) und eine Austrittsbedingung (was bestätigt werden muss, um fortzufahren) haben. Die spezifischen Exit-Kriterien (exit criteria) werden pro Programm definiert, aber die Absicht (intent) jedes Gates ist stabil.

Stufentor (Stage Gate)	Was es prüft	Eintrittsbedingung (Entry condition)	Austrittsbedingung (Exit condition)
EVT (Engineering Validation Test)	Funktioniert das Design im Prinzip? Power-up-Sequencing, grundlegende Funktionsblöcke, erstes Bring-up wichtiger Schnittstellen	Erster Prototypen-Build verfügbar; Schaltplan- und Stackup-Absicht ausreichend eingefroren zum Testen	Kernfunktionen demonstriert; wesentliche Hardwarerisiken identifiziert oder beseitigt; Firmware kann in einen bekannten Zustand booten
DVT (Design Validation Test)	Erreicht das auf Produktion ausgelegte Design seine Ziele im gesamten Betriebsbereich? Signalintegrität, thermisches Verhalten, Margen (margin), vollständiger Funktionsumfang	EVT-Probleme adressiert; Design spiegelt Produktionsabsicht wider; DFM- und DFT-Review abgeschlossen	Leistung (Performance) bestätigt unter den für das Programm definierten Bedingungen; Designänderungen konvergieren (nehmen ab), nicht expandieren
PVT (Production Validation Test)	Kann dieses Design wiederholbar mit dem vorgesehenen Prozess gebaut werden? Ausbeuteverhalten (Yield behavior), Montagestabilität (assembly stability), Bereitschaft der Testlinie	DVT-Exit erfüllt; Prozess und Vorrichtungen (fixtures) definiert; Erstmusterprüfung (first-article inspection) geplant	Build-Prozess als wiederholbar gemäß Programmkriterien demonstriert; bereit für die Freigabeentscheidung (release decision)

Ein paar Dinge halten diese Gates ehrlich. EVT darf hässlich sein. Seine Aufgabe ist es, Unbekanntes an die Oberfläche zu bringen, nicht wie ein Produkt auszusehen. Bei DVT hört das Design auf, sich zu verändern, und beginnt gemessen zu werden; weshalb es eine Verschwendung der Phase ist, mit einem instabilen Schaltplan in DVT einzutreten. Bei PVT geht es mehr um den Prozess als um die Platine, deshalb stützt es sich auf First Article Inspection und NPI Assembly, um zu bestätigen, dass das, was DVT bestanden hat, wieder gebaut werden kann.

Keines dieser Gates ist eine Zertifizierung oder eine finale Freigabeautorität (final-release authority). Ein bestandenes Gate bestätigt die Bereitschaft, mit dem nächsten fortzufahren. Zuverlässigkeit, Konformität (compliance) und Qualifikation sind separate Programme, die parallel laufen und pro Programm bestätigt werden, anstatt durch eine Stufe versprochen zu werden.

Warum die Hardware-Validierung dem Firmware-Bring-up vorausgehen muss

Dies ist der Teil, der am direktesten mit der "Software-Validierung"-Rahmung verbunden ist, und es ist wert, klar ausgesprochen zu werden.

Wenn das Firmware- oder Software-Bring-up auf einer Platine beginnt, deren Hardware EVT nicht bestanden hat, erbt das Softwareteam jeden ungelösten Hardwarefehler als Software-Symptom. Eine Stromschiene (rail), die unter Last einbricht, sieht aus wie ein Watchdog-Reset. Ein Problem der Signalintegrität auf einem Speicherbus sieht aus wie eine Datenkorruption. Ein grenzwertiger Wärmepfad (marginal thermal path) sieht aus wie ein intermittierender (gelegentlicher) Absturz bei anhaltender Aktivität. Die Ingenieure jagen diesen Fehlern im Code nach, weil der Code das ist, was sie berühren können.

Die Fehlerkette verläuft so. Das Firmware-Bring-up beginnt auf einer Platine, deren Strom-, Signalintegritäts- und thermisches Verhalten das EVT-Gate noch nicht passiert hat. Das Softwareteam beginnt mit der Fehlersuche (debugging) von Problemen, die eigentlich Hardwarefehler sind. Es werden Zyklen damit verbracht, Treiber neu zu schreiben und Retries hinzuzufügen, die die eigentliche Ursache übertünchen, was ein falsches Gefühl von Fortschritt erzeugt, weil einige Symptome tatsächlich verstummen. Dann erreicht das Programm DVT oder PVT, der zugrunde liegende Hardwarefehler wird schließlich isoliert, und der Terminverzug (schedule slip) tritt spät zutage, nachdem wochenlange Softwareanstrengungen für ein Hardwareproblem aufgewendet wurden. Die Kosten sind nicht ein einzelner Bug. Es ist die falsche Zuordnung (misattribution), die den Bug verbarg, und die Zeit, die gebraucht wurde, um ihn zu entwirren.

Die Disziplin, die dies verhindert, ist Reihenfolge (ordering), keine Heldentaten. Bestätigen Sie bei EVT, dass das Board in einen bekannten, stabilen Hardwarezustand bootet, bevor der Software-Stack sich darauf stützt. Das ist es, was ein Board für ein sinnvolles Firmware-Bring-up tauglich macht. Validierungsschritte wie ICT Test und FCT Test existieren teilweise, um diese Linie zu ziehen: Sie bestätigen, dass das Board elektrisch und funktional einwandfrei ist, so dass spätere Ausfälle auf die Software hindeuten, nicht auf die darunter liegende Hardware.

Eine Validierungs-Checkliste vor den Stufen

Bevor Sie in eine Stufe eintreten oder zwischen Stufen wechseln, bestätigen Sie eine kleine Gruppe von Bedingungen, anstatt davon auszugehen, dass der vorherige Build diese geklärt hat. Die Schwellenwerte (thresholds) werden pro Programm festgelegt; die Punkte sind allgemein.

Checkpoint	Was zu bestätigen ist	Warum es die Stufe kontrolliert (gates)
Design Freeze Level	Schaltplan und Stackup sind stabil genug für die Stufe, in die Sie eintreten	Das Messen eines sich bewegenden Designs liefert Ergebnisse, die ablaufen, bevor sie nützlich sind
Power-up Verhalten	Stromschienen (Rails) sequenzieren und halten sich innerhalb des für das Programm definierten Bandes	Ein Board, das nicht sauber hochfahren kann, kann kein vertrauenswürdiges Firmware-Bring-up hosten
Signalintegritätsziele	Hochgeschwindigkeitsnetze (High-speed nets) erfüllen die für das Design festgelegte Integritätsabsicht	Grenzwertige Signale tauchen später als Datenfehler (data faults) auf, die als Softwaredefekte fehlinterpretiert werden
Kontinuität des Wärmepfads	Wärme verlässt die heißen Bauteile (hot devices) über den vorgesehenen Pfad unter Last	Thermische Marginalität zeigt sich als intermittierendes Verhalten genau in der falschen Phase
Testzugriff (DFT)	Testpunkte und Zugriff für ICT/FCT sind vorhanden und erreichbar	Das frühe Entfernen des Zugriffs blendet spätere Gates und das Softwareteam gleichermaßen
Inspektionsplan	AOI, Röntgen (X-ray) für BGAs und Erstmusterprüfungen (first-article checks) werden vor dem Build definiert	Montagefehler (Assembly defects), die statische Prüfungen übersehen, werden durch Inspektion und nicht durch Raten (guessing) gefunden
Validierungssprache (Validation language)	Ansprüche (Claims) bleiben auf der Stufenebene (stage level), nicht "produktionsbereit" (production-ready) oder "qualifiziert"	Ein Gate bestätigt die Bereitschaft zum Fortfahren, nicht die endgültige Freigabeautorität (final release authority)

Wenn das Paket vor einer Stufe noch einen Abgleich der Fertigungshinweise (manufacturing-note alignment) oder eine Stackup-Bereinigung benötigt, können Sie dieses Gespräch über die DFM Guidelines eröffnen. Für die PCBA-seitige Validierungs- und Inspektionssprache ist die nächste Support-Seite Testing & Quality.

Welches Paket die jeweilige Validierungsstufe unterstützt

Die Eingaben (inputs), die ein Stage Gate nützlich machen, ändern sich mit der Reifung des Boards.

Für EVT betont das nützliche Paket Fertigungsdaten (fabrication data) mit Stackup-Absicht (stackup intent), eine Platzierung, die Hauptblöcke (major blocks) lesbar macht, und Stücklistenkontext (BOM context) für die risikoreichen Komponenten. Das Ziel ist es, Funktionen in Betrieb zu nehmen und Unbekanntes ans Licht zu bringen.
Für DVT sollte das Paket die Produktionsabsicht (production intent) widerspiegeln: ein stabiles Stackup, die Definition von kontrollierter Impedanz (controlled-impedance), wo sie wichtig ist, DFT-Abdeckung (DFT coverage), damit ICT und FCT ausgeführt werden können, und die thermischen und mechanischen Referenzen, die es ermöglichen, das Design über seinen gesamten Bereich zu messen und nicht nur einzuschalten.
Für PVT neigt sich das Paket in Richtung Prozess: Erwartungen an das Erstmuster (first-article expectations), Inspektionskriterien (inspection criteria) sowie die Definition der Montage- und Testlinie, die beweisen, dass das Design wiederholbar gebaut werden kann.

Der Unterschied zwischen einer generischen Build-Anfrage und einem nützlichen Validierungs-Review besteht darin, ob diese Inputs sowohl die elektrische Absicht als auch die physikalischen Schnittstellen (physical interfaces) zum richtigen Zeitpunkt aufdecken. Ohne sie kann ein Build-Team zwar die generelle Herstellbarkeit kommentieren, aber nicht dabei helfen, die eigentliche Validierungsfrage zu bestätigen: ob das Board stabil genug für das nächste Gate und für die Software ist, die davon abhängen wird. Wenn ein Programm bereit ist, vom Review in einen Build überzugehen, erfolgt diese Aufnahme über die Angebotsseite (quote page).

FAQ

Gibt es wirklich so etwas wie eine "Software Validation PCB"?

Nicht als Produktkategorie. Die nützliche Lesart ist ein Board, das durch seine Hardware-Gates so weit validiert wurde, dass beim Firmware-Bring-up die Software getestet wird und nicht das Board darunter.

Was ist der Unterschied zwischen EVT, DVT und PVT?

EVT fragt, ob das Design im Prinzip funktioniert. DVT fragt, ob das für die Produktion vorgesehene Design seine Ziele im gesamten Betriebsbereich (operating envelope) erreicht. PVT fragt, ob das Design mit dem vorgesehenen Prozess wiederholbar (repeatably) gebaut werden kann. Jedes Gate hat seine eigenen Eintritts- und Austrittsbedingungen (entry and exit conditions), die pro Programm definiert sind.

Warum sollte die Hardware-Validierung vor dem Firmware-Bring-up erfolgen?

Weil Firmware, die auf nicht validierter Hardware läuft, Hardwarefehler als Software-Symptome (software symptoms) erbt. Das Team kann Zyklen damit verbringen, Code neu zu schreiben, um einem Energie-, Signal- oder Wärmeproblem hinterherzujagen, das keine noch so große Menge an Code beheben wird.

Bedeutet das Passieren eines Stage Gates, dass das Board zertifiziert oder produktionsbereit (production-ready) ist?

Nein. Ein bestandenes Gate bestätigt die Bereitschaft, mit der nächsten Stufe fortzufahren. Zuverlässigkeit (Reliability), Compliance und Qualifikation (qualification) sind separate Programme, die pro Programm bestätigt werden und nicht durch ein einzelnes Gate versprochen werden.

Kann eine Platine frühe elektrische Prüfungen bestehen und trotzdem bei einem späteren Gate durchfallen?

Ja. Elektrische Prüfungen (electrical checks) bei Raumtemperatur können bestanden werden, während ein grenzwertiger Wärmepfad (marginal thermal path), ein Problem der Signalintegrität oder ein Montagefehler noch vorhanden ist. Diese neigen dazu, unter Last oder über den gesamten Betriebsbereich (operating envelope) bei DVT oder PVT an die Oberfläche zu kommen.

Was sollten wir vor dem Eintritt in DVT bestätigen?

Dass EVT-Probleme adressiert sind, das Design die Produktionsabsicht (production intent) widerspiegelt und ausreichend eingefroren ist, um es zu messen, dass DFM- und DFT-Reviews abgeschlossen sind und dass Testzugriff vorhanden ist, so dass ICT und FCT sinnvoll ausgeführt werden können.

Öffentliche Referenzen

PCB Stack-Up Support-Seiten-Kontext für Stackup-Definition und kontrollierte Konstruktionsplanung.
PCB Prototype Support-Seiten-Kontext für Early-Build-Hardware, die bei der Engineering-Validierung (engineering validation) eingesetzt wird.
Testing & Quality Support-Seiten-Kontext für Inspektions-, Validierungs- und Testplanungs-Sprache (test-planning language) auf Platinenebene.
DFM Guidelines Support-Seiten-Kontext für Manufacturing Review Intake und Pre-Stage-Klärung.
First Article Inspection Support-Seiten-Kontext zur Bestätigung der Wiederholbarkeit von Builds (build repeatability) vor der Freigabeentscheidung.

Autoren- und Revisionsinformationen

Autor: APTPCB Redaktionsteam
Technische Prüfung (Technical review): NPI / Validation PCB Engineering Review-Team
Prüfungsumfang (Review scope): Stage-Gate-Validierungslogik (EVT, DVT, PVT), Reihenfolge "Hardware vor Firmware" (hardware-before-firmware), Herstellbarkeit und Grenzen von Validierungsansprüchen (validation-claim boundaries)