Verifikation vs. Validierung in der Hardwareentwicklung: Was ist der Unterschied?

Manchmal kann ein Hardware-Design auf dem Prüfstand völlig korrekt aussehen: Der MCU läuft stabil mit 160 MHz, Sensoren kommunizieren über I²C, und die Stromversorgung hält unter Volllast 12 V. Doch selbst ein Produkt, das jede Anforderung erfüllt, kann dennoch unzureichend sein, sobald es beim Anwender ankommt.

Verifizierung und Validierung (V&V) schließen die Lücke zwischen dem Erfüllen von Anforderungen und dem Erfüllen des tatsächlichen Bedarfs in der Praxis. Manche Hardware-Teams verwechseln diese beiden Begriffe. Teams, die V&V als einen einzigen Schritt behandeln oder einen davon auslassen, weil der Prototyp scheinbar funktioniert, stoßen oft erst spät auf Probleme: während eines Audits oder wenn das Produkt bereits im Einsatz ist.

In diesem Artikel erklären wir, was Verifizierung und Validierung in der Hardwareentwicklung bedeuten und worin sie sich unterscheiden. Außerdem behandeln wir, wie V&V über das V-Modell mit Anforderungen verknüpft sind, wie man einen V&V-Plan erstellt und wie sich häufige Fehler vermeiden lassen.

Wichtige Erkenntnisse

• Verifizierung prüft, ob die Hardware die definierten technischen Anforderungen erfüllt. 
• Validierung prüft, ob das vollständige Produkt die Anforderungen des vorgesehenen Einsatzzwecks erfüllt.
• V&V sollte früh beginnen und Anforderungen während der gesamten Hardwareentwicklung mit geplanten Aktivitäten, Abnahmekriterien, Ergebnissen und unterstützenden Nachweisen verknüpfen.

Was ist Verifizierung?

Verifizierung ist der Prozess, mit dem geprüft wird, ob die Hardware den definierten Anforderungen und technischen Spezifikationen entspricht. Sie beantwortet die Frage: Bauen wir das Produkt richtig?

Der Zweck der Verifizierung besteht darin, Annahmen durch Nachweise zu ersetzen. Anstatt anzunehmen, dass eine Schaltung funktioniert, vergleicht das Team das Design oder den physischen Prototyp mit den definierten Anforderungen und dokumentiert Nachweise dafür, ob diese erfüllt werden.

Verifizierung kann Aktivitäten umfassen wie:

• Anforderungsprüfung: Prüfen, ob Anforderungen klar, konsistent, erreichbar, rückverfolgbar und verifizierbar sind.
• Design-Review: Vergleich von Schaltplänen, PCB-Layouts, mechanischen Zeichnungen und Schnittstellen mit den definierten Anforderungen und Designregeln.
• Analyse und Simulation: Einsatz von Berechnungen oder Modellen zur Prüfung von Parametern wie thermischen Reserven, Signalintegrität, Timing oder Leistungsaufnahme.
• Inspektion: Prüfung der physischen Hardware, Abmessungen, Montage, Komponenten oder Verbindungen anhand der Konstruktionsdokumentation.
• Tests und Messungen: Messen der Hardware und Vergleichen der Ergebnisse mit den geforderten Grenzwerten oder dem erwarteten Designverhalten.

Was ist Validierung?

Validierung ist der Prozess, mit dem geprüft wird, ob die Hardware für ihren vorgesehenen Einsatzzweck, ihre Benutzer und ihre Betriebsumgebung tatsächlich geeignet ist. Sie beantwortet die Frage: Bauen wir das richtige Produkt?

Der Hauptzweck der Validierung besteht darin, nachzuweisen, dass das Produkt tatsächlich das Problem löst, für das es entwickelt wurde. Ein Design kann jede technische Anforderung erfüllen und dennoch unzureichend sein, wenn es unter realen Einsatzbedingungen nicht wie erwartet funktioniert. Validierung gibt Ihnen die Sicherheit, dass das Gesamtsystem für die Aufgabe geeignet ist, die die Stakeholder tatsächlich von ihm erwarten.

Validierung kann Aktivitäten umfassen wie:

• Validierung der Anforderungen:  Prüfen, ob die Anforderungen die Bedürfnisse der Stakeholder und die Bedingungen erfassen, denen das Produkt im Einsatz ausgesetzt sein wird.
• Tests auf Systemebene: Bewertung des vollständigen Produkts, um zu bestätigen, dass alles wie vorgesehen zusammenarbeitet.
• Anwendungsfalltests: Prüfen, ob das Produkt die Aufgaben und Szenarien ausführen kann, für die es entwickelt wurde.
• Umgebungstests: Bewertung des Produkts unter realistischen Temperatur-, Feuchtigkeits-, Vibrations-, Last- oder anderen Betriebsbedingungen.
• Feldtests: Betrieb der Hardware in ihrer vorgesehenen Umgebung, um Probleme aufzudecken, die im Labor möglicherweise nicht auftreten.
• Benutzerbewertung: Repräsentative Anwender mit dem Produkt arbeiten lassen und prüfen, ob es deren tatsächliche Arbeitsabläufe und Anforderungen unterstützt.

Verifizierung und Validierung im Hardwareentwicklungsprozess.

Unterschied zwischen Verifizierung und Validierung

V&V verwenden oft dieselben Engineering-Werkzeuge wie Tests, Messungen, Inspektionen und Analysen. Der Unterschied liegt darin, was mit dem Ergebnis nachgewiesen werden soll.

Beispielsweise kann ein Test in der Klimakammer verifizieren, dass ein Produkt über einen spezifizierten Bereich von −20 °C bis 60 °C funktioniert. Bei der Validierung wird gefragt, ob dieser Bereich dem tatsächlichen Bedarf entspricht. Wenn das Produkt in einem sonnenexponierten Gehäuse installiert wird, das 75 °C erreicht, kann es die Verifizierung bestehen und dennoch im Einsatz versagen. Dieselbe Klimakammer kann die Validierung unterstützen, wenn sie mit dem Temperaturprofil betrieben wird, dem das vollständige Produkt im Feldeinsatz voraussichtlich ausgesetzt ist.

Verifizierung liefert in der Regel ein direkteres Bestanden-/Nicht-bestanden-Ergebnis gegenüber einer definierten Anforderung und kann auf einzelne Anforderungen, Designs oder Hardwareelemente angewendet werden. Validierung betrachtet umfassender das integrierte System und ob dessen Gesamtverhalten für den vorgesehenen Einsatz akzeptabel ist.

In einem anforderungsgetriebenen Prozess schafft die Verifizierung Nachweise dafür, dass einzelne technische Anforderungen erfüllt wurden. Die Validierung prüft anschließend, ob das vollständige Produkt den Stakeholder-Bedarf unter realen Betriebsbedingungen erfüllt, und kann aufzeigen, dass eine Anforderung unvollständig oder falsch war.

Wie V&V in das V-Modell passen

Das V-Modell zeigt, wie sich V&V über ein Hardwareentwicklungsprojekt hinweg organisieren lassen.

Das V-Modell stellt den Systemlebenszyklus als ein V dar. Die linke Seite beginnt mit den Bedürfnissen und Erwartungen der Stakeholder, überführt diese in System- und Subsystemanforderungen und verfeinert sie zu Architektur und Detaildesign. Der untere Punkt des V ist die Implementierung. Die rechte Seite führt über die Integration wieder nach oben, mit Tests auf Komponenten-, Subsystem- und Gesamtproduktebene.

Das V-Modell des Systems-Engineering-Prozesses.

Jede Ebene auf der linken Seite ist einer Testebene auf der rechten Seite zugeordnet, und diese Zuordnungen schaffen Rückverfolgbarkeit. Jede Anforderung ist mit der V&V-Aktivität und den Nachweisen verknüpft, die sie prüfen, und Teams planen diese Aktivität, während das Design noch in Arbeit ist. 

Beispielsweise kann eine Anforderung, dass der 12-V-Eingang unter Volllast innerhalb von ±5 % bleiben muss, auf mehreren Ebenen geprüft werden: Bauteilkennwerte im Schaltplan, eine Leistungssimulation der Leiterplatte und eine Messung am montierten Produkt.

Innerhalb dieser Struktur haben V&V unterschiedliche Rollen:

• Die Verifizierung bestätigt auf jeder Ebene, dass das Gebaute den entsprechenden Anforderungen und dem Design von der linken Seite entspricht. Reviews, Analysen und Simulationen beginnen auf der linken Seite, Tests und Messungen laufen auf der rechten Seite nach oben.
• Die Validierung prüft gegen die Stakeholder-Bedürfnisse oben links. Sie beginnt mit der Validierung der Anforderungen gegen diese Bedürfnisse und kehrt oben rechts als Prüfung auf Systemebene zurück: Erfüllt das vollständige Produkt die Stakeholder-Bedürfnisse und den vorgesehenen Einsatzzweck?

So erstellen Sie einen V&V-Plan

Wenn die Hardware die Testphase erreicht, sollte das Team bereits wissen, was zu prüfen ist, mit welchen Anforderungen dies zusammenhängt, wie das Ergebnis bewertet wird und welche Nachweise erfasst werden müssen. Der V&V-Plan fasst diese Entscheidungen in einem Dokument zusammen.

Ein V&V-Plan umfasst typischerweise sechs Entscheidungen:

• Den Umfang festlegen: Festlegen, welches Produkt, welche Subsysteme oder Hardwarefunktionen der Plan abdeckt, was außerhalb seines Geltungsbereichs liegt und worauf sich der V&V-Aufwand risikobasiert zuerst konzentriert.
• V&V-Aktivitäten mit Anforderungen verknüpfen: Technische Anforderungen mit Verifizierungsaktivitäten und Stakeholder-Bedürfnisse mit Validierungsaktivitäten verknüpfen. So erhält jedes Element einen klaren Pfad zu den Nachweisen.
• Methoden auswählen: Festlegen, wie jede Anforderung verifiziert wird – durch Inspektion, Analyse, Demonstration, Tests oder eine andere geeignete Methode – und wie jedes Stakeholder-Bedürfnis validiert wird – durch Anwendungsfalltests, Umgebungstests, Benutzerbewertung oder Feldtests.
• Bedingungen und Abnahmekriterien definieren: Die Hardwarekonfiguration, Betriebsbedingungen, Ausrüstung und das messbare Ergebnis festlegen, das bestimmt, ob die Aktivität bestanden oder nicht bestanden ist.
• Planen, wer was wann macht: Verantwortlichkeiten, erforderliche Ressourcen und Zeitplanung zuweisen und jede Aktivität mit der passenden Phase der Hardwareentwicklung abstimmen, etwa mit Prototyp-, EVT-, DVT- oder PVT-Builds.
• Festlegen, wie Ergebnisse und Nachweise erfasst werden: Definieren, wie jedes Ergebnis dokumentiert und mit unterstützenden Nachweisen verknüpft wird und welche Aktivitäten nach Designänderungen wiederholt werden müssen.

Häufige Fallstricke und wie man sie vermeidet

Während sich ein Softwarefehler oft mit einem Update beheben lässt, ist ein Problem im Hardwaredesign am einfachsten zu korrigieren, bevor die Leiterplatten gefertigt werden. Viele dieser Probleme beginnen bei der Formulierung der Anforderungen und bei der Planung von V&V.

Die folgende Tabelle zeigt häufige V&V-Fallstricke und bewährte Praktiken, mit denen sie sich vermeiden lassen.

Vorteile von V&V

Hardwareänderungen spät in der Entwicklung sind in der Regel teurer als Softwareänderungen. Ein neues Board-Layout, eine Werkzeugänderung oder ein fehlgeschlagener Zertifizierungslauf kosten reale Zeit und Budget, und die Hardware in einem ausgelieferten Gerät lässt sich nur schwer nachträglich anpassen. Deshalb haben Verifizierung und Validierung in der Hardwareentwicklung ein besonderes Gewicht. Zusammen eingesetzt bieten sie Teams vier wesentliche Vorteile:

• Frühere Problemerkennung: Reviews, Simulation und frühe Prototypen decken Lücken in Anforderungen, Designfehler und Versäumnisse auf. In diesem Stadium besteht die Korrektur meist in einer Änderung der Spezifikation oder des Schaltplans.
• Nachweise für jede Anforderung: Die Verifizierung verknüpft jede Anforderung mit einem Ergebnis, sodass das Team zeigen kann, was geprüft wurde, wie geprüft wurde und zu welchem Ergebnis. Diese Nachweise unterstützen auch die Compliance, und regulierte Hardware wie Medizinprodukte erfordert sie typischerweise als Teil der Design Controls.
• Eignung für die reale Nutzung: Die Validierung prüft das vollständige Produkt in Bezug auf seine Umgebung, seine Benutzer und seine Aufgaben. Dadurch werden Probleme erfasst, die eine Prüfung Anforderung für Anforderung übersehen kann, etwa Sensordrift oder Blendung eines Displays bei Sonnenlicht.
• Input für den nächsten Zyklus: Gemessene Margen und Erkenntnisse aus Fehlerfällen steuern Designänderungen, zukünftige Revisionen und spätere Produktgenerationen. Sie zeigen auch, wo eine Anforderung strenger oder lockerer gefasst werden muss.

Software-Tools zur Verwaltung von Verifizierung & Validierung

Die Hardwareentwicklung umfasst viele Anforderungen und Testergebnisse, und deren manuelle Nachverfolgung über ein gesamtes Projekt hinweg kann schwierig sein. Teams arbeiten dann oft mit einer Mischung aus verstreuten Dateien und nicht verbundenen Tools, zum Beispiel:

• Tabellen und Dokumente: Praktisch für kleine Projekte mit begrenzten Anforderungen und Testfällen. Wenn der Umfang von V&V wächst, erfordern Rückverfolgbarkeit und Audit-Bereitschaft oft manuellen Pflegeaufwand, und Aufzeichnungen können auseinanderlaufen.
• Issue-Tracker (z. B. Jira, GitHub): Diese Tools lassen sich anpassen, um V&V-Arbeiten zu organisieren und verwandte Elemente über Links, Felder oder Tags zu verknüpfen. Doch die Pflege der Anforderungsrückverfolgbarkeit und einer vollständigen V&V-Abdeckung erfordert in der Regel zusätzlichen Einrichtungsaufwand und benutzerdefinierte Plugins.
• Spezielle Anforderungsmanagement-Tools: Entwickelt für die Strukturierung von Anforderungen und Rückverfolgbarkeit. Je nach Tool können Testplanung und das Erfassen von Nachweisen jedoch separate Module oder Integrationen mit externen Testwerkzeugen erfordern. 

Für Teams, die V&V-Aktivitäten planen und nachverfolgen möchten – gemeinsam mit Anforderungen in einem gemeinsamen Arbeitsbereich – Requirements Portal verknüpft Anforderungen mit Verifizierungsplänen, Testläufen, Nachweisen und Änderungshistorie. So sehen Teams, was bereits verifiziert wurde und was noch Aufmerksamkeit erfordert.

Fazit & nächste Schritte

Kurz gesagt: Die Verifizierung weist nach, dass Ihre Hardware die Spezifikation erfüllt, während die Validierung nachweist, dass sie für den Benutzer tatsächlich funktioniert. Damit das gelingt, darf V&V keine abschließende Checkliste sein. Es muss von Anfang an in den Produktentwicklungsprozess eingebettet sein.

Wenn Sie Ihr Verständnis von V&V-Frameworks vertiefen möchten, sind diese Materialien für die weitere Beschäftigung nützlich:

• NASA Systems Engineering Handbook bietet praktische Anleitung zur Planung und Durchführung von V&V für Hardwareprodukte auf Weltraumniveau.
• Guide to the Systems Engineering Body of Knowledge (SEBoK) bietet eine breitere systems-engineering-orientierte Sicht auf V&V.
• INCOSE V&V Across Product Lifecycle behandelt V&V über verschiedene Phasen des Lebenszyklus hinweg, das V-Modell, V&V-Methoden, Testfälle und Erfolgskriterien.

Wenn Sie bereit sind, von der Theorie zur Praxis überzugehen, testen Sie Requirements Portal, um Testfälle mit Anforderungen und elektronischen Designs zu verknüpfen, die Abdeckung nachzuverfolgen und technische Nachweise zu erfassen.

Häufig gestellte Fragen

Ist Verifizierung dasselbe wie Validierung?

Nein. Die Verifizierung prüft die Hardware anhand definierter Anforderungen. Die Validierung prüft, ob die Anforderungen und das Produkt die Bedürfnisse der Stakeholder in der realen Nutzung widerspiegeln.

Was kommt zuerst – Verifizierung oder Validierung?

Beides sollte früh geplant werden, und keines von beiden ist nur eine einzelne Phase. Die Verifizierung beginnt mit Reviews, Analysen und Simulationen, während sich das Design entwickelt. Die Validierung beginnt mit der Prüfung der Anforderungen gegen die Bedürfnisse der Stakeholder und gewinnt an Bedeutung, je mehr das integrierte Produkt Gestalt annimmt.

Was sind gängige Arten von V&V-Methoden?

Zu den gängigen V&V-Methoden gehören Reviews, Inspektionen, Analysen, Simulationen, Demonstrationen und Tests. Dieselbe Methode kann entweder die Verifizierung oder die Validierung unterstützen – je nachdem, ob sie eine definierte Anforderung prüft oder das Produkt im Kontext seiner vorgesehenen Nutzung bewertet.