Überprüfung und Validierung mit TestStand

Überblick

Eine ständige Herausforderung bei Produkttests besteht darin, dafür zu sorgen, dass die Testsysteme korrekt ausgelegt sind und durchgängig ordnungsgemäß funktionieren. Während der Entwicklung eines Testsystems erarbeiten die Techniker Testverfahren und legen Messgrenzen fest, um fehlerhafte Produkte korrekt zu erkennen. Sobald die Testmethoden festgelegt wurden, muss das Testsystem selbst daraufhin getestet werden, ob die Software und Hardware die Aufgaben korrekt ausführen. Die Prozesse zur Überprüfung und Validierung (Verification and Validation, V&V) stellen formal sicher, dass das Testsystem korrekt entwickelt wurde und seinen beabsichtigten Zweck erfüllt.

V&V betrifft in erster Linie Unternehmen, die ISO- oder FDA-Verfahren unterliegen, z. B. Unternehmen, die Arzneimittel, medizinische Geräte oder Produkte für die Automobil- und Luftfahrtbranche herstellen. Da solche Produkte für den Arbeitsschutz von entscheidender Bedeutung sind, unterliegen diese Branchen einer formellen Aufsicht und es gelten genau definierte V&V-Prozesse. Einige Unternehmen investieren freiwillig in formelle V&V-Prozesse, etwa zur Kostensenkung oder aus Wettbewerbsgründen. Wenn die Wettbewerbsfähigkeit eines Unternehmens auf Qualität oder Zuverlässigkeit basiert, machen sich die Investition in einen strengen V&V-Prozess unter Umständen komplett bezahlt.

Die TestStand-Software von NI unterstützt Ingenieure bei der Entwicklung effektiver Testsysteme, denn sie stellt eine modulare Architektur mit genau definierten Komponenten bereit, die den verschiedenen Anforderungen eines Testsystems gerecht werden. Diese Trennung der TestStand-Komponenten unterstützt die V&V-Bemühungen, da Sie die Anforderungen für jede Komponente einzeln definieren können.

In diesem Dokument wird V&V für Testsysteme erläutert, die mit TestStand entwickelt wurden. In diesem Dokument werden die folgenden Themen behandelt:

• Definition der Konzepte für die Überprüfung, Validierung und Auswirkungsanalyse für TestStand

• Untersuchung der Komponenten von TestStand und ihres Beitrags zur Optimierung der V&V-Bemühungen

• Einführung allgemeiner Best Practices für V&V

Inhalt

Validierung, Überprüfung und Auswirkungsanalyse

Bevor Sie Best Practices für die Überprüfung und Validierung erörtern, müssen Sie zunächst den Unterschied zwischen diesen Konzepten und deren Anwendung auf ein Testsystem verstehen.


Validierung

Der erste Schritt bei der Entwicklung eines Testsystems besteht darin, die Anforderungen des Tests zu verstehen und zu dokumentieren. Zur Definition dieser Anforderungen gehen Sie von den Spezifikationen für das Bauteil bzw. den Prüfling aus und entwickeln Prüfanforderungen, mit denen Mängel am Prüfling erkannt werden. Zu diesem Zeitpunkt in der Entwicklung müssen die Anforderungen sämtliche Fehlerbedingungen für den Prüfling vollständig definieren. Der Prozess, mit dem geprüft wird, ob das Testsystem die ursprüngliche Absicht erfüllt, wird als Validierung bezeichnet.

Bei der Validierung wird bewertet, ob ein System seinen Zweck oder seine Absicht tatsächlich erfüllt.

Die Validierung muss während des gesamten Testentwicklungsprozesses erfolgen, sollte jedoch in der Phase der Anforderungserfassung beginnen, da etwaige Mängel zu Beginn des Projektlebenszyklus deutlich einfacher zu beheben sind. Die Validierung kann ein formelles Testverfahren auf „Bestanden/Fehlerhaft“ umfassen oder eine subjektive Form einer Studie zur Benutzerfreundlichkeit mit Auftraggebern, Benutzern oder Patienten sein. Die Validierung beinhaltet häufig einige subjektive Anforderungen, z. B. „lehnt fehlerhafte Produkte ab“ oder „hat eine einfache Benutzeroberfläche“. Wenn möglich, sollten Sie detailliertere Anforderungen auf niedrigerer Ebene für diese subjektiven Aussagen definieren und dafür sorgen, dass sich alle Beteiligten auf die beabsichtigten Ziele einigen.

 

Überprüfung

Sobald detaillierte Testanforderungen formuliert wurden, können die Testentwickler ein Testsystem entwerfen und implementieren, das die Anforderungen abdeckt. Die Abdeckung aller definierten Anforderungen wird anschließend überprüft. Der Prozess, bei dem geprüft wird, ob das Testsystem die angegebenen Anforderungen korrekt erfüllt, wird als Überprüfung bezeichnet.

Bei der Überprüfung wird festgestellt, ob ein Testsystem gemäß den in einem Entwurf, einer Zeichnung, einer Arbeitserklärung oder einer anderen ähnlichen Richtlinie angegebenen Spezifikationen gefertigt wurde.

Überprüfungstests sollten an mehreren Meilensteinen einer Produktentwicklung durchgeführt werden. Die Überprüfung kann für das System als Ganzes oder für kleinere Komponenten des Testsystems durchgeführt werden.

Was genau ist der Unterschied zwischen Überprüfung und Validierung? Das lässt sich an einem Beispiel illustrieren: Eine Testabteilung baut eine einfache Testvorrichtung zur Messung des Stromverbrauchs eines Prüflings. Das Testsystem muss die Strommessung für die Stromkontakte des Prüflings mit den Testgrenzen vergleichen. Denen zufolge muss die Stromstärke am Prüfling bei unter 500 mA liegen. Hierfür definieren Testentwickler die Anforderung, dass „der Prüflingsstrom 500 mA bei voller Leistung nicht überschreiten darf“. Die Entwickler entwerfen und implementieren dann ein Testgerät mit der erforderlichen Hardware, um diese Messung durchzuführen, und erstellen einen Testfall, um den Strom des Prüflings nach Lieferung der vollen Leistung zu überprüfen.

Um eine Überprüfung des Testsystems durchzuführen, überprüfen die Entwickler, ob das System die Messung korrekt und mit akzeptabler Wiederholbarkeit durchführt und einen Fehler meldet, wenn die Stromstärke einen Wert von 500 mA überschreitet. Wenn das Verhalten des Testsystems den Anforderungen entspricht, besteht das System die Überprüfung.

Bei der Herstellung gibt es jedoch einen Fehlermodus. Eine falsch herum installierte Diode kann dazu führen, dass einige Teile der Schaltung nicht aktiviert werden, was zu einer extrem niedrigen Stromstärke von 150 mA führt. Dieses Problem wird von den Testsystemen nicht als Fehler gemeldet, da nur ein oberer Grenzwert getestet wird. In diesem könnte es passieren, dass fehlerhafte Einheiten ausgeliefert werden. Obwohl das Testsystem gemäß den Spezifikationen korrekt gebaut wurde, erfüllt es nicht den geforderten Zweck und scheitert an der Validierung. Die Spezifikation und das Testsystem müssen so geändert werden, dass sie eine obere und eine untere Messgrenze enthalten, z. B. 400 und 500 mA.

Die Durchführung einer Systemüberprüfung kann relativ einfach sein, wenn sie auf einer guten Spezifikation, Zeichnung oder Leistungsbeschreibung basiert. Die Testmethoden können ziemlich unkompliziert sein, d. h., Fehler sind unter Umständen leicht zu finden. Schwieriger ist es bei der Validierung, wie das vorherige Beispiel zeigt.


Auswirkungsanalyse

Nachdem die Validierung und Überprüfung eines Testsystems abgeschlossen und das System in Betrieb genommen wurde, müssen Sie wahrscheinlich Änderungen oder Aktualisierungen am System vornehmen. Diese Aktualisierungen können auf Wartung, Reparatur oder den Versuch zurückzuführen sein, die Leistung des Systems zu verbessern oder zu korrigieren, z. B. auf das Ersetzen eines fehlerhaften Geräts oder das Ändern eines Algorithmus oder einer Einstellung. Wenn Sie Änderungen an einem System vornehmen, ist es wichtig zu verstehen, welche Teile des Testsystems erneut validiert werden müssen, damit die Änderungen keine Fehler verursachen. Dies wird als Auswirkungsanalyse bezeichnet. 

Bei der Auswirkungsanalyse wird ermittelt, welche Komponenten eines Testsystems von einer Reihe von Änderungen, die Sie vornehmen, betroffen sind.

Die Durchführung einer detaillierten Auswirkungsanalyse ist wichtig, da eine Änderung dazu führen kann, dass das System unbemerkt nicht ordnungsgemäß funktioniert und es potenziell zu Produktrückrufen, Produktionsstillständen oder anderen geschäftlichen Störungen kommen kann. Eine Änderung kann auch dazu führen, dass das System zwar ordnungsgemäß funktioniert, die Änderung sich jedoch auf das Ergebnis bzw. die Testergebnisse auswirkt und zu falschen Entscheidungen über getestete Produkte führt. Die Kosten für eine verpasste Änderung oder eine falsche Validierung können äußerst hoch sein. In einigen Branchen kann der Versand fehlerhafter Produkte zu einem Produktrückruf führen. Die FDA behält sich das Recht vor, in solchen Fällen Maßnahmen zu ergreifen. 

Um die Auswirkungen von Änderungen an einem System zu verringern, ist es wichtig, das Testsystem modular zu gestalten, sodass sich Änderungen an einer Komponente nicht auf andere Komponenten auswirken. Daher muss dafür gesorgt werden, dass jede Komponente vollständig von anderen Komponenten entkoppelt ist und über unabhängige Validierungsverfahren verfügt. Beispielsweise können Sie eine Hardware-Abstraktionsschicht (Hardware Abstraction Layer, HAL) einführen, die einen Standardsatz von Funktionen für die Schnittstelle mit Hardware bereitstellt. Die von der HAL definierten Funktionen können unabhängig vom verbleibenden Testsystem validiert werden. Wenn Sie eine Hardwareänderung vornehmen, wirkt sich dies nur auf die HAL-Ebene aus, da Sie überprüfen können, ob die HAL-Funktionen nach der Änderung noch dasselbe Verhalten aufweisen.

 

Industriestandards für Validierung und Überprüfung

Die maßgeblichen Prinzipien von V&V sind für viele Branchen klar definiert und werden durch Disziplinen wie Good Manufacturing Practices (GMP) oder durch Vorschriften wie ISO-9000, CFR-Titel 21 (FDA) oder IEEE-Normen festgelegt. Die V&V-Systeme sind ähnlich, basieren jedoch auf leicht unterschiedlichen Terminologien zur Erläuterung der allgemeinen Anforderungen der beiden Prozesse. Konkrete Anforderungen sind normalerweise nicht definiert. In diesem Dokument werden V&V-Prozesse für automatisierte Testsysteme erläutert.

Die Validierungsanforderungen, die sich speziell auf Medizingeräte in CFR-Titel 21 für die FDA beziehen, sind vage. Dies betrifft auch Festlegungen, dass ein Medizinprodukt validiert werden muss, um den Benutzeranforderungen und Verwendungszwecken zu entsprechen. Daher müssen die Verantwortlichen für das Qualitätssystem die Anforderungen definieren und die Validierungstests überwachen. Bei Testsystemen kann eine Methode zum Definieren eines Validierungstests recht einfach ausfallen: Bekannte Fehlermodi verfolgen und über gute und schlechte Produktstichproben verfügen, damit das System bekannte Fehler erkennt. Bei einer anderen Methode kommt möglicherweise ein vertrauenswürdiges manuelles Testverfahren oder ein anderes automatisiertes System zum Einsatz, mit dem die Ergebnisse des neuen Testsystems validiert werden. 

Einige Validierungen müssen außerordentlich gründlich durchgeführt werden, beispielsweise in der Luftfahrt-, Pharma- und Medizinproduktebranche, da es bei den Validierungsprozessen um extreme Fälle von Sicherheit, Qualität oder Kosten geht. Die Definition und Durchführung einer gründlichen Systemvalidierung kann Wochen oder Monate dauern. Wenn ein Testsystem beispielsweise eine Schaltmatrix in einer 16x32-Konfiguration verwendet, können die Tester jede mögliche Kombination von Verbindungen mit einem Durchgangsprüfer testen und dafür sorgen, dass niemals eingeschränkte Verbindungen hergestellt werden. Ein anderes Beispiel könnte darin bestehen, ein Kommunikationssystem zu validieren, in dem jeder mögliche Befehl und jede mögliche Befehlsfolge getestet und validiert werden müssen. Derartige Validierungsprozesse wirken übertrieben, aber es dürfen unter keinen Umständen Schäden, Verletzungen oder falsche Ergebnisse auftreten.

 

Dokumentieren und Sammeln von Anforderungen

V&V-Prozesse konzentrieren sich auf genau definierte Spezifikationen. Die Validierung kann auch einigen objektiven Problemen unterliegen, z. B. lose definierten Anforderungen des Marktes oder der Endnutzer. Der wichtigste erste Schritt für jedes Testsystem besteht darin, eine gute Arbeitsspezifikation und V&V-Anforderungen zu recherchieren und zu dokumentieren. Die Vollständigkeit des Testsystems lässt sich nur schwer sicherstellen, wenn die Spezifikationen nicht konkret genug sind oder Raum für Interpretationen oder Unklarheiten lassen. Der Test kann abgebrochen werden, wenn Prüfer oder Beobachter feststellen, dass eine Einstellung nicht dokumentiert oder falsch implementiert ist. Eine gut verfasste Spezifikation, die mit Sorgfalt und Aufmerksamkeit implementiert wird, kann zu einem schmerzlosen V&V-Prozess beitragen.

Für die Überprüfung sind ein oder mehrere Entwurfsdokumente oder Zeichnungen erforderlich, aus denen hervorgeht, was das System leisten muss.  Die Dokumente und Zeichnungen decken unter Umständen eine Komponente, eine Baugruppe oder ein gesamtes System ab. Die Spezifikation und Testmethode für die Überprüfung muss ein vollständig detailliertes Dokument mit so vielen Informationen sein, wie sie zur Erstellung eines korrekten Testsystems erforderlich sind.

Halten Sie sämtliche Änderungen an den Spezifikationen fest, die von einem Auftraggeber, von Technikern oder als Ergebnis von Lern- und Entdeckungsprozessen entwickelt wurden. Zeichnen Sie die Änderung und den Grund mithilfe eines Änderungsauftragsprozesses auf, damit die Änderung offiziell wird. Die Überprüfung ist nur dann erfolgreich, wenn Sie Anweisungen, Einstellungen und Testgrenzen mit dem richtigen Dokument abgleichen. 

Der Entwurf eines Validierungstests ist oft subjektiv und hat bisweilen eher den Anschein einer Kunst als einer Wissenschaft. Auch wenn Weisheit und Erfahrung die einzigen Werkzeuge für das Validierungsdesign zu sein scheinen, denken Sie daran, dass das Sammeln von Anforderungen aufschlussreich und nützlich sein kann. Zu den Techniken gehören die Überprüfung der bisherigen Leistung anderer Testvorrichtungen oder Produkte, die Befragung von Bedienern und ihren Vorgesetzten sowie die Untersuchung früherer Messdaten. Ein Unternehmen, das Aufgaben üblicherweise an Systemintegratoren auslagert, führt eine detaillierte Überprüfung jedes Projekts durch, um herauszufinden, wie das nächste Projekt noch besser ablaufen könnte, und stellt diese Ideen in einer Checkliste für das nächste Projekt zusammen.

 

Bewältigung von V&V-Herausforderungen mit TestStand

TestStand basiert auf einer modularen Architektur mit vielen entkoppelten Komponenten wie der TestStand-Engine, den Prozessmodellen, dem Testcode und der Benutzeroberfläche. Diese Architektur ist für V&V von Vorteil, da die einzelnen Komponenten einfacher unabhängig voneinander analysiert werden können. Darüber hinaus erfordern Änderungen an vorhandenen Testsystemen weniger erneute Validierung, da die Auswirkungen häufig auf eine einzelne Komponente beschränkt sind.

Die modulare Architektur von TestStand ermöglicht die unabhängige Überprüfung und Validierung jeder Komponente und reduziert die Auswirkungen von Änderungen auf das gesamte Testsystem.

Beim Entwerfen eines Testsystems müssen die Überprüfung und Validierung ebenso wie die Frage berücksichtigt werden, wie Sie die Systemarchitektur so gestalten können, dass diese Bemühungen einfacher werden. In den folgenden Abschnitten finden Sie bewährte Methoden zum Entwerfen von Komponenten Ihres Testsystems unter Berücksichtigung von V&V.

 

Entwurf von Sequenzdateien

Behalten Sie bei der Entwicklung von Testsequenzen die folgenden Ziele im Hinterkopf:

  • Unterteilen Sie die Funktionalität in mehrere Bausteine, indem Sie Untersequenzen für logische Funktionsblöcke einrichten.
  • Reduzieren Sie die Interaktion zwischen den Schritten. Dadurch werden die Auswirkungen von Änderungen an einzelnen Schritten auf das Testsystem verringert.

Wenn Sie sich auf diese Ziele konzentrieren, können Sie besser verfolgen, wie die Anforderungen im Testcode abgedeckt sind, und die Auswirkungen von Änderungen an einzelnen Schritten reduzieren.  

 

Separate Schritte und Schritteinstellungen im Vergleich

Überlegen Sie beim Definieren einer Bedingung für einen Schritt, ob die Bedingung jemals für mehrere Schritte gelten wird. „If/Else“- oder „Case“-Schritte zur Implementierung von Logik sind in der TestStand-Umgebung besser sichtbar, erweiterbar und können so geändert werden, dass verschiedene Optionen ausgeführt werden und mehr als ein Schritt pro Bedingung enthalten ist. Sie definieren jedoch ein Verhältnis zwischen den Testschritten und der Ablaufsteuerung ein. Bei Logik, die immer für einen einzelnen Schritt gilt, können Sie mithilfe einer Vorbedingung die Logik und den Schritt in einer einzelnen Komponente unterbringen.
Gehen Sie auf ähnliche Weise vor, wenn Sie das Umschalten in Ihrem Testcode implementieren. Bei Routen, die für einen einzelnen Test gelten, können Sie mithilfe der Umschalteinstellungen eines Schritts die Umschaltfunktion mit dem Testcode in Bausteine aufteilen. Wenn sich das Umschalten auf mehrere Schritte auswirkt, sind Umschaltschritte in einer Sequenz besser sichtbar und tragen dazu bei, dass die Sequenz sich selbst dokumentiert.


Modularisieren mithilfe von Untersequenzen

Um die Vorteile der Aufteilung integrierter Schritteinstellungen auf einzelne Bausteine mit der Erweiterbarkeit der Verwendung separater Schritte zu kombinieren, können Sie Untersequenzen erstellen, in denen verwandte Sätze von Schritten zusammengefasst werden. Durch die Aufbewahrung von Sätzen solcher Sequenzen in einer separaten Sequenzdatei können Sie effektiv eine Sequenzdatei erstellen, bei der es sich um eine Funktionsbibliothek handelt, die unabhängig validiert und von mehreren Testanwendungen gemeinsam genutzt werden kann.
Darüber hinaus sollte die Testsequenz fast ausschließlich aus Sequenzaufrufschritten bestehen, die jeweils eine logische Gruppierung von Tests implementieren. Die Organisation von Untersequenzen sollte mit den Testspezifikationen übereinstimmen, wobei Anforderungen auf hoher Ebene, wie z. B. „Das System muss die Audiofunktionen des Geräts testen“, einer Sequenz im Test zugeordnet werden sollten, während unterstützende Anforderungen auf niedrigerer Ebene, wie z. B. „Die maximale Lautstärke darf 80 dB nicht überschreiten“, Schritten innerhalb der Sequenz zugeordnet werden sollten.


Reduzierung der Abhängigkeiten zwischen mehreren Schritten

Sie können auch Abhängigkeiten zwischen Schritten festlegen, wenn für einen Schritt Daten erforderlich sind, die im vorherigen Schritt abgerufen wurden. Vermeiden Sie die Verwendung der Eigenschaft „PreviousStep“ für den direkten Zugriff auf Daten aus einem anderen Schritt. Speichern Sie die Daten aus dem ersten Schritt stattdessen in einer lokalen Variable, auf die Sie dann im späteren Schritt zugreifen können.

Sie sollten auch dafür sorgen, dass bei jedem Schritt vor der Ausführung des Tests unabhängig die erforderlichen Bedingungen festgelegt oder überprüft werden. Wenn ein Schritt für den Audio-Lautstärketest beispielsweise einen Lautstärketest bei niedriger, mittlerer und hoher Lautstärke umfasst und in einem nachfolgenden Schritt Audioqualitätstests durchgeführt werden, die bei mittlerer Lautstärke durchgeführt werden müssen, müssen Sie vor dem Test darauf achten, dass die Lautstärke vor der Durchführung auf „mittel“ eingestellt ist. So sind die beiden Tests voneinander unabhängig: Änderungen am Audio-Lautstärketest wirken sich nicht auf den Audioqualitätstest aus.


Dokumentieren von Testsequenzen

Eine klare Dokumentation Ihrer Sequenzdateien ist ein wichtiger Aspekt bei der Prüfung, ob alle Anforderungen in der Spezifikation ausreichend abgedeckt sind. Sie sollten jedoch vermeiden, Informationen in der Dokumentation, wie beispielsweis Grenzwerte oder Testparameter, zu wiederholen. 

Sie können den Zweck eines Schritts mit dem Schrittnamen und der Beschreibung dokumentieren. Aus dem Schrittnamen sollte hervorgehen, was der Schritt leistet und warum eine bestimmte Aktion ausgeführt wird. Er sollte jedoch keine im Schritt definierten Parameterwerte enthalten. Nennen Sie beispielsweise einen Schritt nicht einfach „Warten“, sondern „Warten auf Systemstart“. Wenn für den Namen weitere Informationen erforderlich sind, geben Sie über die Eigenschaft „Description“ (Beschreibung) des Schritts zusätzliche Details an.

Sie können auch über die TestStand-Integration in NI Requirements Gateway effektiv verfolgen, wo Anforderungen im tatsächlichen Testcode abgedeckt sind. Mit NI Requirements Gateway können Sie schnell sehen, welche Anforderungen abgedeckt sind, und Sie können zu dem Schritt navigieren, der die Anforderungen abdeckt. Das beschleunigt den Überprüfungsprozess.

Mit NI Requirements Gateway können Sie Verknüpfungen zwischen Ihren Anforderungsdokumenten, Testsequenzen und Testberichten erstellen und damit sicherstellen, dass alle Anforderungen abgedeckt sind.

 

Im Feld „Requirements“ (Anforderungen), das für Schritte, Sequenzen und Sequenzdateien verfügbar ist, werden Informationen zu den abgedeckten Anforderungen bereitgestellt. Sie können mit diesen Feldern in NI Requirements Gateway eine Zuordnung zwischen Ihrem Anforderungsdokument und Ihrem Testcode erstellen und schnell feststellen, wo Anforderungen abgedeckt sind. 


Im Anforderungsfeld können Sie Schritte, Sequenzen oder Sequenzdateien bestimmten Anforderungen in Ihren Spezifikationsdokumenten zuordnen.

 

Weitere Informationen zum Einsatz von NI Requirements Gateway mit TestStand zum Verfolgen von Anforderungen finden Sie im Tutorial Coupling NI Requirements Gateway with NI TestStand (Koppeln von NI Requirements Gateway mit NI TestStand).

 

Entwicklung unabhängiger Codemodule

TestStand-Schritte rufen Codemodule für die Kommunikation mit Instrumentierungs- und Automatisierungshardware auf. Codemodule können in einer Reihe von Sprachen wie LabVIEW, C ++ oder C # implementiert werden. Da TestStand eine natürliche Grenze zwischen Schritten und Codemodulen bereitstellt, ist es vorteilhaft, Codemodule zu schreiben, die unabhängig von der TestStand-Sequenz getestet und validiert werden können. 
Damit Codemodule außerhalb der Testsequenz getestet werden können, vermeiden Sie den SequenceContext oder andere TestStand-Referenzen für den Direktzugriff auf Daten, und übergeben Sie stattdessen Daten über Parameter an das Codemodul. In Fällen, in denen der SequenceContext erforderlich ist, z. B. die Implementierung einer Abschlussüberwachung, entwerfen Sie das Codemodul so, dass es ohne den TestStand-spezifischen Code funktionieren kann. In einem LabVIEW-Codemodul können Sie mit der Funktion „not a reference“ (Keine Referenz) vor der Verwendung überprüfen, ob der SequenceContext gültig ist.

Mit unabhängig ausführbaren Codemodulen können Sie Testvorrichtungen entwerfen, die das Codemodul in einer Schleife durchlaufen, und alle Permutationen von Eingabeparametern übergeben. Die Testvorrichtung kann dann die Ergebnisse mit bekannten korrekten Ergebnissen vergleichen und überprüfen, ob sich die Codemodule wie erwartet verhalten.

Änderungen an Prozessmodellen mithilfe von Plugins

TestStand-Prozessmodelle verarbeiten Testfunktionen, die nicht spezifisch für einen Prüfling sind, einschließlich Prüflingsverfolgung, Berichterstellung, Datenbankprotokollierung sowie Stapel- oder Paralleltests. Die im Lieferumfang von TestStand enthaltenen Prozessmodelle sind komplex, sodass Änderungen an diesen Modellen einen erheblichen Validierungsaufwand erfordern. 

Die Prozessmodelle basieren auf einer Plugin-Architektur, die die Standardfunktionen zur Berichterstellung und Datenbankprotokollierung implementiert. Sie können mit dieser Architektur die Funktionalität der vorhandenen Prozessmodelle erweitern, ohne Änderungen an den Prozessmodellsequenzdateien selbst vorzunehmen. Dazu erstellen Sie ein benutzerdefiniertes Plugin, das in einer separaten Plugin-Sequenzdatei implementiert ist. Sie können das Verhalten dieses Plugins unabhängig überprüfen.


Prozessmodell-Plugins sind separate Komponenten aus den Prozessmodelldateien, die einzeln validiert werden können.

 

Wenn Sie Änderungen an der Funktionalität direkt in den Prozessmodellen selbst vornehmen müssen, z. B. Änderungen an der Erfassung der Seriennummer des Prüflings durch das Modell, sollten Sie die Schritte im Prozessmodell deaktivieren, mit denen die vorhandene Funktionalität implementiert wird, und anschließend ein separates Plugin für die neue Funktionalität erstellen. Auf diese Weise können zukünftige Änderungen, die Sie am benutzerdefinierten Verhalten vornehmen, auf das Plugin beschränkt werden, das leichter erneut validiert werden kann. 

Weitere Informationen zur Anpassung der Prozessmodelle und Plugins finden Sie im Dokument Best Practices for TestStand Process Model Development and Customization (Empfohlene Methoden für die Entwicklung und Anpassung von NI TestStand-Prozessmodellen).

Verwalten von Testeinstellungen und -konfiguration

Bei der Entwicklung eines Testsystems müssen Sie unbedingt dafür sorgen, dass alle TestStand-Einstellungen für alle Stationen des Tests identisch sind und niemals ohne ordnungsgemäße Validierung der Änderung geändert werden. Da jedoch viele TestStand-Komponenten individuelle Einstellungen aufweisen, kann es schwierig sein, Änderungen auszuschließen. Zusätzlich zu den TestStand-Einstellungen müssen Sie dafür sorgen, dass die Geräteeinstellungen für alle Testsysteme einheitlich sind. Die Geräteeinstellungen können NI-DAQmx-Einstellungen, die im NI Measurement & Automation Explorer (MAX) vorgenommen wurden, oder GPIB- und COM-Einstellungen für ein Gerät umfassen. Es kann zahlreiche derartige Einstellungen geben, für die sich Validierungstests nur mit Schwierigkeiten entwerfen lassen.

Eine Möglichkeit, um dafür zu sorgen, dass die Einstellungen korrekt sind, besteht darin, sie programmgesteuert in Ihrer Testsequenz festzulegen und dann jede Einstellung abzufragen, damit klar ist, dass die Einstellung vom Gerät oder Programm akzeptiert wurde. Wenn die Einstellung nicht abgefragt werden kann, suchen Sie den Speicherort der Einstellung und sehen Sie direkt in der Text-, INI- oder XML-Datei nach. Das System kann den Status von Elementen außerhalb von TestStand überprüfen, aufzeichnen und kontrollieren.

 

Verwalten von Dateien mit Tools zur Quellcodeverwaltung

Eine andere Herangehensweise zum Verwalten von Einstellungen besteht darin, die Dateien mit den Einstellungen streng zu kontrollieren. Konfigurationsdateien, in denen alle TestStand-Einstellungen gespeichert sind, werden im Verzeichnis <TestStand-Anwendungsdaten>\Cfg gespeichert. Informationen zum Speicherort der Einstellungsdateien finden Sie in der produktspezifischen Dokumentation
Die branchenweit anerkannte Methode zur Überwachung, Steuerung und Speicherung von Testsystemdateien sind SCC-Programme (Source Code Control) wie Subversion, Perforce und Microsoft Visual Source Safe. Viele dieser Programme sind konform mit der Microsoft SCC-Oberfläche. Sie können sie in TestStand oder LabVIEW verwenden. In einigen Fällen können Sie eine Datei nur ändern, wenn Sie vorübergehend Eigentümer der Datei werden. Außerdem müssen Sie die vorgenommenen Änderungen dokumentieren, um sie zu speichern. Aus diesen Programmen geht häufig hervor, welche Dateien geändert wurden. Außerdem werden die alten und neuen Dateien analysiert, um die Änderungen hervorzuheben und die Überprüfung zu vereinfachen.

Sie können auch mithilfe von Dateiprüfsummen prüfen, ob sich die Einstellungsdateien gegenüber dem validierten Status geändert haben. Bei dieser Herangehensweise können Sie Schritte hinzufügen, die die Prüfsumme mit einer Prüfsumme vergleichen, die Sie für den validierten Dateiwert berechnet haben, und einen Testfehler generieren, wenn die Summen nicht übereinstimmen.   

 

Validieren von Testsystem-Updates

Zusätzlich zum Testsystem müssen Sie dafür sorgen, dass sich die gesamte Hardware und Software, die den Test unterstützt, in einem bekannten, validierten Zustand befindet. Dieser Abschnitt enthält Techniken zum Beibehalten des Systemstatus und zum Anwenden von Änderungen bei Bedarf.


Verwalten der Hardwarekonfiguration

Sie müssen die Geräte nicht nur für das System, sondern auch für jeden einzelnen Test richtig auswählen, installieren, programmieren und konfigurieren. Beispielsweise verfügt ein Digitalmultimeter (DMM) oder Oszilloskop über mehrere Konfigurationsoptionen für eine ordnungsgemäße Kommunikation und Signalerfassung, die nach Abschluss eines Testsystems und bei zukünftigen Änderungen an der Hardware überprüft und validiert werden müssen.

Das Erstellen einer Hardware-Abstraktionsschicht (HAL) zum Verwalten von Hardware-Interaktionen kann dazu beitragen, den erforderlichen Aufwand für eine erneute Validierung zu reduzieren, wenn Änderungen an der Hardware im Testsystem vorgenommen werden. Anwender können daher für ihre Testsequenz auf gerätespezifische Codemodule verzichten und stattdessen mit einer HAL Messtypen und gerätespezifische Treiber von der Testsequenz entkoppeln. Da Testverfahren in der Regel mit Gerätetypen (z. B. Netzteilen, Digitalmultimetern (DMMs), analogen Ausgängen und Relais) anstelle konkreter Geräte definiert werden, führt die Verwendung von Abstraktionsschichten zu einer Testsequenz, die leichter an neue Geräte und Anforderungen angepasst werden kann. Wenn eine HAL vorhanden ist, können Sie neue Hardware validieren, indem Sie dafür sorgen, dass die HAL-Funktionen in einer Reihe von Testfällen dieselbe Ausgabe wie die vorherige Hardware erzeugen, ohne dass das gesamte Testsystem vollständig getestet werden muss. Weitere Informationen zur Verwendung von HALs finden Sie unter Fundamentals of Building a Test System: Hardware and Measurement Abstraction Layers (Leitfäden für das Erstellen von Prüfsystemen​: Hardware- und Messabstraktionsschichten).

Es ist auch eine gute Idee, Hardware zur Laufzeit zu validieren. Durch Lesen und Speichern von Einstellungen oder anderen Faktoren zur Laufzeit können Sie sicher sein, dass Elemente, die zusammen mit der Software validiert werden müssen, wie vorgesehen konfiguriert sind und funktionieren. Beispielsweise können Ihre TestStand-Schritte die Kalibrierungsdaten eines Geräts abfragen, damit die Kalibrierung aktuell ist, und die Modellnummer und Seriennummer des an einen COM-Anschluss angeschlossenen Geräts überprüfen, um auszuschließen, dass das Gerät ersetzt wurde. Das Entwerfen einer Testsequenz und sogar der Kauf von Geräten unter Berücksichtigung dieser Überlegungen können zur Vereinfachung der V&V-Prozesse beitragen.

Wenn Sie davon ausgehen, dass sich Ihre Hardware ändern muss, müssen Sie die Änderung in einem V&V-Prozess berücksichtigen. Wenn ein Gerät ausfällt und durch ein anderes Gerät der gleichen Marke und des gleichen Modells ersetzt wird, überlegen Sie, wie Sie überprüfen, ob es ordnungsgemäß funktioniert, und entwerfen Sie einen Test, mit dem sichergestellt wird, dass die Änderung erfolgreich war. Der Einsatz von IVI-Treibern (Interchangeable Virtual Instrument) und Schnittstellen zur Geräteeinrichtung kann dazu beitragen, den Wechsel zwischen zwei Geräten desselben Herstellers oder Modells bzw. zwischen zwei Geräten unterschiedlicher Hersteller oder Modelle zu vereinfachen.

Verwalten der Softwarekonfiguration

Wenn Sie ein Testsystem warten, müssen Sie ein Upgrade von LabVIEW, TestStand oder einem anderen Programm in Betracht ziehen, damit Sie neue Funktionen nutzen können, sobald sie verfügbar sind. Ein solches Software-Upgrade ist immer ein Auslöser für eine erneute Validierung und Überprüfung. Behandeln Sie ein potenzielles Upgrade als Übung in Sachen ROI (Return on Investment). Um beispielsweise von einer optimierten Entwicklungsoberfläche zu profitieren, möchten Sie möglicherweise während der Entwicklung, jedoch nicht nach dem System-Deployment ein Upgrade durchführen. Wie bei den letzten TestStand-Upgrades kann eine höhere Ausführungsgeschwindigkeit jedoch zu einer kürzeren Testzeit, einem höheren Durchsatz und höheren Einnahmen führen. In beiden Fällen sind die Kosten für die erneute Validierung der entscheidende Faktor, aber die Kosten können auch zu einem positiven ROI führen und damit die Kosten und den Aufwand wert sein. In der Regel sollten mehrere Software-Upgrades gleichzeitig durchgeführt werden, damit die Software nicht so oft validiert werden muss.

Um einen einheitlichen Satz von Software auf einem Testsystem aufrechtzuerhalten, sollten Sie ein Basis-Image aus einem validierten System erstellen und dieses Image zur Einrichtung neuer Teststationen einsetzen. Auch beim Einsatz von Images müssen Sie jedoch dafür sorgen, dass keine Software-Updates stattfinden. Achten Sie bei der Software von National Instruments darauf, dass der NI-Update-Dienst so konfiguriert ist, dass Aktualisierungen niemals automatisch installiert werden. Standardmäßig werden Microsoft-Updates auf den meisten Computern automatisch ausgeführt. Andere Unternehmen wie Sun, Apple und Adobe setzen ebenfalls webbasierte automatische Updates ein. Sie müssen alle automatischen Änderungen und Upgrades auf jedem System deaktivieren, das V&V-Prozessen unterliegt. Die Änderungen, die durch automatische Updates vorgenommen werden, sind nicht vorhersehbar und können unbekannte Auswirkungen auf den Betrieb und die Einstellungen haben. 

Ihre IT-Abteilung verfügt möglicherweise über eine allgemeine Richtlinie zur Steuerung von Computern im Unternehmen, die unter anderem den Einsatz von Virenscan-Software, die Festlegung von Sicherheitsrichtlinien wie Bildschirmschonern und die Installation von Patches und Upgrades nach Bedarf vorsieht. Eine Fertigungsabteilung muss gemeinsam mit der IT-Abteilung TestStand-Systeme verwalten. Konkret bedeutet das, die Systeme unverändert zu lassen. Sie müssen entscheiden, welche Elemente sich konkret auf Ihre Computer auswirken. Ihre Anforderungen stehen jedoch möglicherweise im Widerspruch zu den IT-Richtlinien, z. B. das Entfernen von Virenscannern, das Deaktivieren von Bildschirmschonern und die Befreiung von unternehmensweiten Upgrades oder Patches.