Print
PDFTable of Contents
Parallele Prüftechnologien können die Leistung von Prüfsystemen verbessern, indem sie die Verarbeitungszeit reduzieren und die Geräte effizienter nutzen.
Mit Multicore-Prozessoren lässt sich die Prüfzeit verkürzen, weil prozessorintensive Aufgaben verteilt ausgeführt werden. Geräteintensive Aufgaben erfordern dagegen Techniken wie etwa „Autoscheduling“. Dabei wird die Testausführung überwacht, um dann die Prüfzeit durch Optimierung der Geräteauslastung zu verkürzen.
Damit eine Anwendung von Multicore-Prozessoren profitieren kann, muss ihre gesamte Software Multithreading-fähig sein. Die drei gängigsten Softwarekomponenten eines automatisierten Prüfsystems sind die Test Executive, die Anwendungssoftware und die Gerätetreiber.
Abbildung 1: NI TestStand führt mithilfe seiner parallelen Prozessmodelle eine Sequenz automatisch parallel aus.
Test Executive
Eine Test Executive ist die übergeordnete Anwendung, die alle Komponenten eines Prüfsystems verwaltet und die Ausführung steuert. Ist sie nicht Multithreading-fähig, läuft das gesamte Prüfsystem nur auf einem einzigen Prozessor, auch wenn mehrere Prüflinge getestet werden. Multithreading-fähige Test Executives, die etwa mit der Testmanagementsoftware NI TestStand
TestStand entwickelt wurden, können dagegen einen separaten Thread für jeden Prüfling erzeugen. Jeder dieser Threads kann auf einem eigenen Prozessorkern (Core) ausgeführt werden (s. Abb. 1).
Die Erstellung einer Multithreading-fähigen Test Executive führt jedoch nicht automatisch zu höherer Leistung. Die Test Executive muss auch verschiedene Operationen gleichzeitig ausführen können. In der Grafik zum sequenziellen Test in Abbildung 2 führt eine Multithreading-fähige Anwendung Tests von vier Prüflingen in verschiedenen Threads nacheinander durch. Diese Ausführung profitiert nicht vom parallelen Multicore-Prozessor. Die Operationen werden nicht parallel ausgeführt.
Die Entwicklung Multithreading-fähiger Test Executives, die Aufgaben parallel abarbeiten, kann problematisch sein, da sich verschiedene Threads Ressourcen wie etwa Messgeräte oder die Materialflusssteuerung teilen müssen. Zwei Threads können so nicht gleichzeitig auf dieselbe Ressource zugreifen. Eine Methode, eine Test Executive mehrere Operationen parallel ausführen zu lassen, ist das sogenannte „Pipelining“. Wie der parallele Test in Abbildung 2 zeigt, beginnt die Ausführung der Threads jeweils um einen Test zeitversetzt. Aufgrund dessen können Prüfsequenzen gleichzeitig laufen und die Prüfzeit wird insgesamt um mehr als die Hälfte verringert. Am meisten verkürzt Pipelining die Prüfzeit in Sequenzen, in denen alle Tests ungefähr gleich lang dauern und jeweils eine eigene Ressource benötigen. NI TestStand umfasst Prozessmodelle, die Pipelining für Prüfsequenzen automatisch implementieren und Prüflinge parallel testen.
Anwendungs Software
Auch die Anwendungssoftware muss Multithreading-fähig sein, um sich Multicore-Prozessoren zunutze zu machen. Mit den meisten modernen Programmiersprachen lassen sich Multithreading-fähige Anwendungen implementieren, wobei der Aufwand je nach Sprache recht unterschiedlich sein kann. Grafische Programmiersprachen wie etwa NI LabVIEW sind beispielsweise von Natur aus parallel und generieren abhängig von der jeweiligen Anwendungsarchitektur automatisch mehrere Threads. Im Gegensatz dazu müssen Threads bei textbasierten Programmiersprachen wie C ausdrücklich erstellt, verwaltet und gesteuert werden. Dies wird mit zunehmender Komplexität der Anwendung immer schwieriger und bietet mehr Fehlerpotenzial.
Abbildung 2: NI TestStand führt eine Prüfsequenz automatisch parallel aus oder verwendet Autoscheduling, um mehrere Prüflinge gleichzeitig zu testen.
Geräte Treiber
Damit ein Treiber in einer Multithreading-fähigen Anwendung verwendet werden kann, muss er Thread-sicher und ablaufinvariant sein. Thread-Sicherheit bedeutet, dass der Treiber auch dann richtig arbeitet, wenn er von zwei Threads zur selben Zeit aufgerufen wird. Außerdem muss der Treiber ablaufinvariant sein. Ist er Thread-sicher, aber nicht ablaufinvariant, wird er zum Engpass in der Anwendung, da nur ein Thread auf einmal den Treiber nutzen kann. Ablaufinvariante und Thread-sichere Treiber können dagegen mehrere Instanzen (Datenbereiche) eines Treibers erstellen und ermöglichen so eine parallele Ausführung.
Abbildung 3: Die Prüfsequenz mit Autoscheduling ist auf die Ausführung von drei Tests eingestellt.
Und die Messgeräte?
Während automatisierter Tests wird die meiste Zeit für Messungen, Kommunikation und andere geräteintensive Aufgaben aufgewendet. Zwar verbessert die Nutzung von Multicore-Prozessoren die Prozessorauslastung, optimiert aber nicht immer auch geräteintensive Aufgaben. Um dies zu erreichen, muss außerdem die Auslastung der verfügbaren Ressourcen erhöht werden, indem Tests auf ungenutzten Testressourcen ausgeführt werden. So könnte beispielsweise der parallele Test in Abbildung 2 weiter optimiert werden, wenn auch während der ungenutzten Zeit zu Beginn jeder Ausführung ein Test durchgeführt würde. Werden die Tests neu angeordnet, um freie Ressourcen zu nutzen, wie beim Autoscheduling in Abbildung 2 dargestellt, lässt sich die Prüfzeit im Vergleich zur sequenziellen Ausführung um 60 bis 75 % reduzieren. Beim Autoscheduling müssen Tests in jeder beliebigen Reihenfolge ausgeführt werden können und von früheren Prüfergebnissen unabhängig sein. NI TestStand unterstützt das Autoscheduling durch Entwicklungskomponenten, die Prüfsequenzen hinzugefügt werden können. Abbildung 3 zeigt eine Prüfsequenz, die das Autoscheduling-Beispiel aus Abbildung 2 implementiert.
Die Sequenz besteht aus einer Hauptgruppe „Auto Schedule“, die drei verschiedene Gruppen „Use Auto Schedule Resource“ umfasst. Jede dieser drei Untergruppen definiert eine andere Geräteressource, welche sich verschiedene Prüflinge teilen müssen. Innerhalb der Gruppe „Use Auto Schedule Resource“ ruft die Sequenz ein LabVIEW-VI auf, das jeden Test durchführt. Bei der Ausführung erstellt NI TestStand vier verschiedene Instanzen derselben Sequenz, eine für jeden Prüfling, und ordnet die Ausführung der Tests so an, dass die Messgeräte optimal genutzt und die Prüfzeiten reduziert werden.
Santiago Delgado ist Product Manager für NI TestStand und NI Requirements Gateway. Er hat einen Abschluss als Bachelor of Science im Fach Management-Informationssysteme von der University of Nebraska in Lincoln.
Dieser Artikel erschien erstmals im NI Instrumentation Newsletter, Ausgabe Q1 2008.
Legal
This material is protected under the copyright laws of the U.S. and other countries and any uses not in conformity with the copyright laws are prohibited, including but not limited to reproduction, DOWNLOADING, duplication, adaptation and transmission or broadcast by any media, devices or processes.