Die Software macht´s

National Instruments, München

Entwickler von Prüfsystemen standen in der Vergangenheit oft vor dem Problem, entweder eine Prüfplattform von Grund auf selber programmieren zu müssen oder eine handelsübliche Plattform einzusetzen. Eine selbstentwickelte Prüfplattform konnte an die ganz speziellen Bedürfnisse des Anwenders angepasst werden, was jedoch mit einem sehr hohen Kosten-, Entwicklungs- und Wartungsaufwand verbunden war. Herkömmliche Prüfplattformen waren für spezielle Kundenwünsche oft zu unflexibel und konnten häufig auch nicht die nötige Ablaufgeschwindigkeit bieten. Teststand 2.0 verbindet die Vorteile selbstentwickelter Prüfplattformen mit denen von Standard-Plattformen. Als vollständige Prüfplattform kann sie an die speziellen Bedürfnisse jedes einzelnen Anwenders angepasst werden, d. h. es lassen sich sehr komplexe Prüfsysteme erstellen, die verkürzte Prüfzeiten durch Geschwindigkeitssteigerung sicherstellen. Zu den wesentlichen Neuerungen der Version 2.0 zählen:

• paralleles Prüfen für gesteigerten Durchsatz,

• direkte und vereinfachte Kommunikation mit Messgeräten für mühelosere Prüfschritt-Entwicklung,

• bessere Projektübersicht und Quellcode-Verwaltung dank neuer Projektübersichten und Quellcode-Verwaltungsmechanismen,

• Schnittstellen zu weiteren Prüfentwicklungsumgebungen (Lab-View, Lab-Windows/CVI, Visual-Basic, C/C++ über DLLs oder Active-X),

• erweiterte Programmierschnittstelle (API)zur Erstellung von kundenspezifischen Werkzeugen und Editoren,

• Unterstützung der XML-Technologie für flexible web-basierte Berichte,

• erweiterte Möglichkeiten zur Integration von Datenbanken und

• deutliche Leistungssteigerung und erweiterte Benutzeroberflächen.

Das Ziel der meisten Prüfsysteme für den Herstellungsprozess ist die Reduzierung der Kosten durch schnellstmögliches und effektives Testen der Prüflinge. In der Vergangenheit wurden Prüfungen sequenziell abgearbeitet, d.h. eine Prüfsequenz konnte erst dann starten, wenn die vorhergehende Prüfung vollständig abgeschlossen war. Für einige Prüfszenarien war dies sicherlich ausreichend, nicht jedoch für sehr komplexe oder zeitraubende Prüfungen, da sich hier viele Messgeräte während der Prüfung im Ruhezustand befanden, während andere dauernd belegt waren.

Da Teststand 2.0 parallele Prüfungen erlaubt, wird dieses Problem auf einfache Weise gelöst. Unterkomponenten oderauch ganze Produkte können hier simultan geprüft werden. Durch die Abarbeitung im so genannten Parallelmodus werden auch die Kosten für die Instrumentierung reduziert, da die Messgeräte von mehreren Anwendern gleichzeitig genutzt werden können und so besser ausgelastet sind. Kostenintensive GSM- oder W-CDMA-Messgeräte, die in der Telekommunikation verwendet werden, können z. B. auf mehrere Prüfer aufgeteilt werden. Andererseits können einfachere Geräte wie z. B. Multimeter (DMMs) oder einfache Oszilloskope parallel arbeiten und sorgen so für einen kontinuierlichen Testfluss.

Das Prozessmodell, das das Grundgerüst für den Ablauf einer Prüfsequenz bildet, kann vom Prüfingenieur an die speziellen Anforderungen der Kunden angepasst werden. Sowohl das parallele als auch das sequenzielle Prüfverfahren (Parallel-Mo-del bzw. Batch-Model) liegen bereits als vorgefertigte Prozessmodelle in Teststand vor (Bild 1).

Bei der sequenziellen Prüfung (Batch-Test) durchlaufen die Prüflinge identische Prüfszenarien parallel z. B. bei der Prüfung von Leiterplatten-Nutzen vor deren Aufteilung in einzelne Platten. Das Batch-Model wird dort eingesetzt, wo die einzelnen Prüfungen für alle Prüflinge simultan ablaufen sollen. Der Prüfbericht wird hier erst erstellt, nachdem jeder Prüfling getestet wurde. Überwacht wird der Prüfvorgang durch neu eingeführte Synchronisierungsmechanismen (Synchronization-Steps).

Beim Parallelmodell werden die Prüflinge ebenfalls parallel getestet. Der Prüfungsablauf jeder Einheit ist hier jedoch unabhängig. Wenn zum Beispiel bei einer Prüfung ein Fehler gemeldet wird, werden automatisch Fehlerdiagnose-Routinen durchgeführt oder die entsprechende Einheit wird sofort aus dem Produktionsprozess entfernt, ohne dass andere Prüfungen davon beeinflusst würden. Das Parallelmodell stellt somit sicher, dass die Ressourcen optimal ausgelastet werden und dadurch die Prüfzeit reduziert wird. Bild 2 zeigt, wie die Benutzer-Oberfläche einer Parallelprüfung aussehen kann.

Wie bereits erwähnt, wurden zur genauen Überwachung und Steuerung der parallelen Prüfungen in Teststand 2.0 neue Synchronisierungsmechanismen eingeführt, mit denen eine kundenspezifische Synchronisierung, zwischen den parallel ablaufenden Prüfsequenzen ausgeführt werden kann. Der Anwender kann unter folgenden Synchronisierungs-Schritttypen wählen:

• Mutex (Mutually exclusive = gegenseitig ausschließen) – Entwickler können diesen Schritttyp zum Sperren einer Ressource verwenden. Damit wird sichergestellt, dass z. B. ein Messgerät für einen bestimmten Prüfschritt reserviert wird. Andere Prüfungen warten währenddessen bis der Mutex wieder freigegeben wird. Dabei wird auch eine serielle Ablauf-Reihenfolge der Prüfschritte erzwungen.

• Semaphore – Dieser Schritttyp synchronisiert zwei oder mehrere unterschiedliche, parallel ablaufende Prüfschritte, so dass immer nur ein Prüfschritt den Zugriff auf die durch die Semaphore gemeinsam genutzte Ressource (z. B. ein Oszilloskop) hat.

• Rendezvous – Diese Art der Synchronisierung wird dazu verwendet, um zwei oder mehrere unterschiedliche, parallel ablaufende Aufgaben an einer bestimmten Stelle im Prüfungsablauf zu synchronisieren. Jeder Prüfungsablauf, der das Rendezvous erreicht, wartet somit so lange, bis alle anderen für das Rendezvous vorkonfigurierten Aufgaben ebenfalls an diesem Punkt angelangt sind. Erst dann wird die Ausführung fortgesetzt.

• Queue – Mit diesem Schritttyp wird eine bestimmte Anzahl von Datenelementen von einer Aufgabe an eine andere, parallel ablaufende Aufgabe übergeben. Diese Art der Synchronisation wird angewendet, wenn eine Aufgabe so lange warten soll, bis die Daten von einer parallel ablaufenden Aufgabe übermittelt werden.

• Notification – Dieser Schritttyp übergibt Daten von einer Aufgabe an eine oder mehrere parallel ablaufende Aufgaben. Damit warten eine oder mehrere Tasks auf das Zusenden von Daten einer anderen Task. Die Daten werden dabei im Gegensatz zur Queue nicht zwischengepuffert. Wenn also keine Aufgabe auf eine Mitteilung wartet, sind die Daten, sobald eine weitere Mitteilung gesendet wird, nicht mehr verfügbar.

• Wait – Dieser Schritttyp sorgt dafür, dass sich eine Aufgabe an einer bestimmten Stelle, in einem bestimmten Zeitrahmen oder bis eine andere Aufgabe abgearbeitet ist im Leerlauf befindet.

• Threadpriority – Damit kann die Threadpriorität der einzelnen Tasks verändert werden. Zum Beispiel ist das Warten auf Daten von einem Messgerät wichtiger als die Berechnung des Amplitudenspektrums eines Signals. Dies hat direkten Einfluss auf die Ausführungsgeschwindigkeit der unterschiedlichen Threads.

• Batch Synchronization – Die Batch-Synchronisation wird in Verbindung mit dem Batch-Model verwendet. Damit wird der Ein- bzw. Austritt von Batch-Bereichen konfiguriert.

All diese Schritttypen bieten dem Entwickler maximalen Komfort bei der Erstellung parallel ablaufender Prüfsysteme aller Art und Komplexität.

Ein wesentlicher Bestandteil von Teststand war schon immer die Möglichkeit der problemlosen Integration von Prüfschritten, die in den unterschiedlichsten Entwicklungsumgebungen erstellt wurden. Bei Version 2.0 wurde nun auch die Steuerung von Messgeräten vereinfacht. Standardfunktionen wie die Konfiguration bzw. Initialisierung oder das Lesen und Schreiben von Daten von Instrumenten können nun über die benutzerfreundliche Oberfläche des Teststand-Sequenzeditors ausgeführt werden. Der IVI-Schritttyp (IVI = Interchangeable Virtual Instrument) z. B. beschleunigt zum einen die Entwicklung und vereinfacht zum anderen die Wartung. Mit dem IVI-Instrumententreiber können Sequenzen auch dann erstellt werden, wenn keine realen Messgeräte vorhanden sind, da durch die IVI-Architektur die Daten vom Instrument simuliert werden können. Außerdem kann mit der IVI-Treiberarchitektur ein Messgerät durch ein anderes mit ähnlichen Eigenschaften ersetzt werden. So können z. B. Multimeter von unterschiedlichen Herstellern mit IVI-Support in der Produktionslinie z. B. wegen Kalibrierarbeiten ausgetauscht werden. Um die Übertragungsgeschwindigkeit zu steigern, kann ein externes Instrument mühelos durch ein PC-basiertes, z. B. im PXI-Formfaktor, ersetzt werden. Folgende neue Schritttypen zur Kommunikation von IVI-kompatiblen Instrumenten sind nun in Teststand enthalten (Bild 3):

• Multimeter (DMM),

• Oszilloskope,

• Funktionsgeneratoren und

• Stromversorgung.

Durch die steigende Komplexität und den Umfang moderner Prüfsysteme arbeiten immer mehr Entwickler zusammen an einem Projekt. Dabei wird es immer wichtiger, dass alle Entwickler eines Teams während der Entwicklungsphase Zugriff auf die aktuellen Sequenzen oder einzelnen Schritte haben. Quellcode-Verwaltungsprogramme (Source-Code-Control) wie z. B. Microsoft-Source-Safe, Perforce oder Clear-Case vereinfachen die Teamarbeit durch kontrolliertes Abspeichern beispielsweise der Änderungen in einer Sequenz. Teststand 2.0 unterstützt nicht nur die unterschiedlichsten Quellcode-Verwaltungsprogramme, sondern verfügt auch über übersichtlichere Projekt-Verwaltungshilfen wie Projektübersichts- und Verwaltungsfenster. Über die Projektübersicht hat man direkten Zugang zu allen Sequenzeinzelheiten und verknüpften Dateien des jeweiligen Projekts (Bild 4). Zusätzlich zum Projekt-Übersichtsfenster können sich Entwickler die Unterschiede zweier Prüfsequenzdateien anzeigen lassen. Sobald ein Entwickler die Unterschiede kennt, kann er diese korrigieren bzw. anpassen.

In vielen Fällen sind bereits Quellcodes vorhanden, die in unterschiedlichsten Programmiersprachen erstellt wurden. Bestehenden Quellcode neu zu schreiben, ist zum einen sehr zeitaufwändig und oft auch äußerst schwierig, zum anderen relativ kostenintensiv. In Teststand 2.0 kann nun auch Quellcode von HT Basic, HP Basic für Windows oder HP VEE integriert werden. Mit dem HT-Basic-Adapter lassen sich HT Basic aufrufen, Daten mit HT-Basic-Code austauschen und sogar die HT-Basic-Code-Debug-Funktion direkt aus Teststand heraus verwenden (Bild 5).

Mit der erweiterten API (Application Programming Interface) können kundenspezifische Benutzer-Schnittstellen und zusätzliche Werkzeuge für die unterschiedlichsten Prüfapplikationen erstellt werden. Durch den programmatischen Zugriff auf interne Daten von Teststand und der Erstellung bzw. Steuerung von Teststand-Sequenzen können auch Sequenz-Editoren, die den ganz speziellen Bedürfnissen des Anwenders entsprechen, erstellt werden. Vor allem OEM-Kunden benötigen entweder angepasste Benutzer-Schnittstellen oder spezielle Funktionen.

Die einfache und übersichtliche Verteilung der aus den Prüfungen im Herstellungsprozess gewonnenen Daten wird durch die Globalisierung der Firmen immer wichtiger. Die Entwicklungsabteilungen vieler Unternehmen sind heute oft auf unterschiedliche Standorte verteilt. In den meisten Fällen müssen Prüfdaten der Produktionslinie im gesamten Unternehmen je nach Anwender (Operator, Entwickler oder Manager) unterschiedlich aufbereitet und visualisiert werden können. Ein allgemeiner Prüfbericht in Papierform kann diese Forderungen nicht mehr in der entsprechenden Zeit erfüllen. Die Lösung hierfür ist der Einsatz des Intra- bzw. Internets. Teststand 2.0 unterstützt daher XML-Berichte (Bild 6). XML ist die neue Technik für den Datenaustausch über Intra- oder Internet. Im Gegensatz zu HTML ist XML keine Programmiersprache, sondern eine Erweiterung von HTML. HTML ist für die Darstellung von Daten im Web-Browser verantwortlich, während XML den Datenaustausch regelt. XML bietet ein Standardformat zur Beschreibung verschiedener Datentypen (wie z. B. Prüf- oder Datenbankdatensätze) für die konsistente und ordnungsgemäße Entschlüsselung, Manipulation und Anzeige von Informationen. XML bietet ein Dateiformat zur Darstellung von Daten, ein Schema zur Beschreibung der Datenstruktur sowie einen Mechanismus zur HTML-Erweiterung. Mit XML können Dokumente in jedem beliebigen Format angezeigt werden, wobei die Struktur dynamisch angepasst werden kann oder nur bestimmte Abschnitte mit den gewünschten Informationen angezeigt werden. So können von jedem Anwender mühelos unterschiedliche Internet-Berichte erstellt werden, die dem einen Anwender z. B. nur die Information Pass oder Fail liefern, während andere sich zusätzliche Daten wie lokale oder globale Prüfvariablen anzeigen lassen können. Außerdem können mit Hilfe der XML-Technik Arrays, Tabellen und Grafen in HTML-Dokumente aufgenommen werden.

Das Ablegen von Prüfergebnissen in Datenbanken war schon immer ein wichtiger Bestandteil von Prüfanwendungen. In Teststand 2.0 wurde durch Einführung einer neuen Datenbankzugriffs-Komponente (Database Logging) zum einen die Implementierung von Datenbank-Zugriffen vereinfacht und zum anderen die Geschwindigkeit der Datenbank-Zugriffe optimiert. Mit der Database-Logging-Komponente können Entwickler durch einfache Konfiguration sowohl das Datenbank-Schema (z. B. Microsoft Access, SQL Server oder Oracle) auswählen als auch das Verzeichnis, in dem sich diese Datenbank befindet. Ein Datenbank-Schema besteht aus einer Liste von Anweisungen, mit denen bestimmt wird, wie die Daten in der Datenbank gespeichert werden (Bild 7). Dadurch können Inhalt und Format der Datenbank auch nachträglich noch durch Konfigu-ration verändert werden.

Vor allem die Reduzierung der Ausführungszeit einzelner Teststand-2.0-Testschritte und der geringere Laufzeit-Speicherbedarf führten zu einer deutlichen Geschwindigkeitssteigerung. Neue Funktionen bei der Prüfanwendungsentwicklung:

• Combined-Property-Loader-Step-Type – Dieser neue Schritttyp kombiniert die Funktionen der bereits vorhandenen Property-Step-Types in einem Schritttyp. Damit können sowohl Werte von Eigenschaften und Variablen als auch von Dateien oder Datenbanken geladen werden.

• Enhanced-Numeric-Limit-Step-Type – Dieser Schritttyp bietet nun auch die Vorgabe von Einheiten und des Datenformats. Dabei erscheinen die eingestellten Einheiten sowohl im Prüfbericht als auch in der Ergebnis-Daten-bank. Mit der zusätzlichen Formatierungsfunktion können zum Beispiel die Anzahl der Stellen vor oder nach dem Komma oder auch der Datentyp (Integer, Real, Binary usw.) eingestellt werden.

• Multiple-Numeric-Limit-Test-Step-Type – Dieser Schritttyp vereinfacht die Grenzwert-Überprüfung von Mehrfachmessungen. Damit können die Grenzwerte für eine vorbestimmbare Anzahl von Messungen überprüft werden, wobei jede Messung unterschiedliche Grenzwerte, Einheiten, Vergleichsoperatoren, Anzeigeformate oder Datenquellen haben kann.

• Erweiterung des Dynamic-Link-Library-Adapter – Der überarbeitete DLL-Adapter ist durch die Unterstützung von Strukturen, Enumeration und vereinfachter Editierung erweitert worden.

• Variablen im Expression-Browser definieren – In Teststand 2.0 können nun lokale und globale Variablen im Expression-Browser definiert werden. Dadurch wird mühsames Wechseln zwischen unterschiedlichen Dialogboxen vermieden.

Teststand 2.0 bietet Entwicklern von Prüfplattformen eindeutige Vorteile. Dank dieser Software können sie ihren Prüfdurchsatz deutlich steigern und die Kosten erheblich senken. Aufgrund vereinfachter Gerätesteuerungs-Funktionen lassen sich damit komplexe Systeme für parallele Prüfungen jetzt schneller und müheloser erstellen. Hinzu kommt, dass jeder beliebige Code in einer Standardumgebung genutzt werden kann. Da Teststand sich auf die neuesten Techniken auf dem Gebiet der Berichterstellung und Datenmanagement stützt, bietet es Ingenieuren und Managern im Bereich Produktion eine einzigartige Grundlage für die Erstellung von Prüfsystemen für den Herstellungsprozess.

EPP 187