Testautomatisierung Der Strukturwandel der API in der Prüftechnik

Anbieter zum Thema

GÖPEL electronic GmbH

MicroConsult Academy GmbH

Heitec AG

Eurocircuits GmbH

Von lokal hin zu vernetzt: Moderne Prüftechnik erfordert flexible und skalierbare Architekturen. Ein Beispiel aus der Praxis zeigt, wie netzwerkbasierte APIs dabei helfen und welche Vorteile sie bieten.

Ein vollumfängliches Prüfkonzept für komplexe elektronische Baugruppen enthält in der Regel verschiedene Test- und Messverfahren. Schließlich sollen alle Verbindungen und Funktionen einer Leiterplatte für ihren späteren Einsatz sichergestellt werden.

Jede Prüftechnologie und jedes Messinstrument bietet dafür eine eigene Bedienoberfläche. Sie besteht aus Software-Tools oder Steuerelementen direkt am Gerät, die eine autonome Steuerung ermöglichen. Dieser unmittelbare Zugriff mag in der Entwicklungs- oder Debug-Phase durchaus praktikabel sein, um die Ressourcen manuell zu verwenden und Ergebnisse sofort einsehen zu können.

Für den Einsatz im Fertigungsbereich ist dies jedoch nicht geeignet. Hier geht es darum, große Mengen an Prüflingen einem definierten Testplan zu unterziehen und die Ergebnisse strukturiert zu protokollieren. Dieser sich ständig wiederholende und aus vielen Einzelschritten bestehende Vorgang birgt ein erhebliches Potenzial für Bedienfehler und kann zudem sehr langwierig sein. Nachlässige Ausführung oder falsch abgelegte Testergebnisse stellen Risiken für die Qualität des Endprodukts dar.

Testschritte automatisiert steuern

Abhilfe schafft eine automatisierte Steuerung der Testschritte durch Nutzung einer entsprechenden API. Die Abkürzung API steht für Application Programming Interface und wird häufig mit umständlicher Programmierung assoziiert, für die erfahrene Entwickler benötigt werden. In der Praxis bedeutet es jedoch nichts anderes als eine Möglichkeit, eine Software oder ein Instrument fernzusteuern, also die Funktionen von außen aufrufen zu können. Wie umständlich diese Aufrufe tatsächlich sind, liegt im Wesentlichen am Anbieter selbst.

Beispiele sind vielfältig: Auf Hardware-Seite finden sich bestimmte RS-232-Befehlssätze oder spezielle Instrumenten-Treiber. Auf Software-Seite gibt es DLL-Schnittstellen oder verschiedene Varianten der Interprozesskommunikation. So unterschiedlich diese Methoden auch sind, haben sie den Grundgedanken gemeinsam, dass Funktionen aufgerufen und Ergebnisse abgeholt werden sollen.

Mit einer geeigneten Steuer-Software, die auch als Sequencer bezeichnet wird, können einzelne Testschritte und ein gesamter Testplan erstellt werden. Dieser führt unter Verwendung der jeweiligen API die festgelegten Prüfungen durch. Diese Form der Automatisierung ist längst zum Standard geworden, um zuverlässige Testergebnisse zu erhalten und einen bestimmten Linientakt sicherzustellen. Das Personal in der Fertigung benötigt nur noch eine Bedienoberfläche und muss sich nicht um die Details der einzelnen Ressourcen kümmern.

Die Evolution der API-Architekturen

Die Architektur der API hat sich dabei im Laufe der Zeit weiterentwickelt. Neue Schnittstellen wurden eingeführt, Standards definiert und teilweise ganze Befehlssätze für bestimmte Geräteklassen vereinheitlicht. Der Fokus verlagerte sich immer mehr von der ursprünglichen Offline-Kommunikation innerhalb eines Rechners hin zu netzwerkbasierten Technologien.

Diese Neuerungen waren stets darauf ausgelegt, die Einbindung in eine Steuer-Software und den Zugriff auf die einzelnen Funktionen zu vereinfachen. Dennoch blieb eine dezentrale Grundstruktur des Gesamtsystems lange Zeit bestehen: Ein Prüfrechner wird eingerichtet, indem die Steuer-Software sowie sämtliche weitere Prüfprogramme und Gerätetreiber installiert und konfiguriert werden. Mit diesem in sich geschlossenen, stationären System wird die Prüfaufgabe gemäß der Spezifikationen ausgeführt.

Dieser Aufbau wirkt auf den ersten Blick schlüssig und war ursprünglich auch der API und den Hardwareschnittstellen geschuldet, die eine andere Organisation schlicht unmöglich machten. Daraus ergeben sich jedoch einige Nachteile, die mit steigender Anzahl an Komponenten immer deutlicher hervortreten:

• Die Inbetriebnahme und Wartung des Prüfrechners wird aufwendiger,

• die Rechner-Belastung steigt,

• viele Systemeingriffe gefährden die Stabilität,

• für jeden weiteren Testplatz muss der komplette Prüfrechner dupliziert werden und

• die Betriebssystemarchitektur limitiert die Kompatibilität.

Ausfälle oder Verzögerungen sollen jedoch in der Produktion vermieden werden.

Der Weg zur verteilten Architektur

Um diesen Punkten entgegenzuwirken, wird diese kombinierte Verwaltung aller Komponenten auf einem System aufgelöst. Aus Hardware-Sicht ist das in vielen Bereichen bereits durch die Implementierung einer Ethernet-Schnittstelle erfolgt. Anstelle von USB- oder PCIe-Einsteckkarten, für die ein Gerätetreiber installiert werden muss, erfolgt der Anschluss über eine Netzwerkverbindung, die unmittelbar einsatzbereit ist. Für die Software-Entkopplung wird eine API benötigt, die entsprechende Netzwerktechnologien unterstützt und somit die Verteilung der Systeme ermöglicht.

Einen solchen Strukturwandel hat die Firma Phytec Messtechnik durchlaufen. Dort wurde ein Prüfkonzept entwickelt, mit dem unterschiedliche System-on-Module- (SOM-)Baugruppen am Ende der Produktionslinie getestet werden. Als Teststrategien kommen der JTAG/Boundary Scan von Göpel electronic sowie ein Funktionstest zum Einsatz. Am Ende der Prüfung werden die Baugruppen mit einem Bootloader programmiert und mit einer Seriennummer versehen. Die bisherige Systemkonfiguration ist seit zehn Jahren im Einsatz und besteht aus einem Prüfrechner, einer Master-Einheit mit Adaption für den speziellen Prüfling sowie einem JTAG Controller.

Überblick der Hauptverbesserungen:

• Aufteilung in thematische Unterabschnitte,

• Aufzählungen für bessere Übersichtlichkeit,

• klarere Strukturierung mit Zwischenüberschriften und

• Trennung von Hardware- und Software-Aspekten.

Ein traditioneller Testaufbau

Als Betriebssystem des Testplatzes kommt Microsoft Windows zum Einsatz. Die Ablaufsteuerung wird als VBA-Script unter Microsoft Access ausgeführt. Das Boundary-Scan-Software-System CASCON wird lokal auf dem Prüfrechner installiert und greift auf den über USB angeschlossenen JTAG Controller zu. Zur Steuerung wird eine DLL-API eingebunden, mit der das Projekt und die einzelnen Testschritte oder kompletten Batches ausgewählt und gestartet werden. Anhand der Rückgabewerte wird das Testergebnis generiert und zur Dokumentation in der Datenbank gespeichert.

Für den anschließenden Funktionstest werden die Dienste eines Linux-Betriebssystems benötigt, welches als Gast-System in einer virtuellen Maschine eingerichtet und über Telnet von der Ablaufsteuerung angesprochen wird. Nach den bisherigen Erfahrungen der Firma Phytec Messtechnik ergaben sich folgende Probleme:

• Windows ist als grafisches Betriebssystem für eine automatisierte Ablaufsteuerung ungeeignet,

• VBA ist schwer zu verwalten und

• das Gesamtsystem ist sehr pflegeaufwendig bei Updates.

Daraus ergab sich die Notwendigkeit einer Umgestaltung der Software-Landschaft mit folgenden Anforderungen:

• Betriebssystem Linux,

• Ablaufsteuerung mit der Script-Sprache Python,

• Auslagerung von System CASCON auf einen Server und Steuerung per Netzwerk-API und

• Verbindung des JTAG Controllers über Ethernet.

Neue Architektur mit Web-Service-API

In diesem neuen Konzept wurde der Prüfrechner aus Sicht des Boundary-Scan-Tests auf einen Thin Client reduziert. Dieser muss keine Ressourcen mehr bereitstellen, sondern kommuniziert lediglich mit dem zentral organisierten Server-Rechner.

Eine solche Verwaltung setzt eine entsprechende API voraus, die durch einen SOAP-Web-Service zur Verfügung steht. SOAP steht für Simple Object Access Protocol und ist ein auf XML-Nachrichten basierendes Netzwerkprotokoll, welches als industrieller Standard des W3C gilt. Was für einen einzelnen Testplatz als übermäßiger Overhead erscheinen mag, bietet dennoch entscheidende Vorteile:

• Der Prüfrechner wird nicht durch zusätzliche Software belastet und ist entsprechend weniger störanfällig und

• die Inbetriebnahme und Wartung von zwei getrennten, dedizierten Rechnern ist deutlich einfacher als bei einem kombinierten System.

Skalierbarkeit und Flexibilität

Weitere Vorteile ergeben sich bei der Einrichtung zusätzlicher Testplätze. In der hier beschriebenen Umgebung werden aktuell 18 JTAG Controller eingesetzt, von denen drei bereits auf die Web-Service-Steuerung umgestellt wurden.

Da ein CASCON-Server mehrere JTAG Controller verwalten kann, ist dort lediglich die interne Konfiguration anzupassen. Somit wird nur der schlanke Prüfrechner sowie der eigentliche Prüfaufbau dupliziert - bestehend aus der Mastereinheit und dem JTAG Controller. Auch andere Skalierungsformen, wie die Steuerung mehrerer JTAG-Controller über einen Prüfrechner, sind realisierbar und bieten weitere Freiheitsgrade.

Eine API ist wesentlicher Bestandteil in der Prüftechnik und ermöglicht zuverlässige, automatisierte Abläufe, die für die Qualitätssicherung von elektronischen Baugruppen zwingend notwendig sind. Dabei dient sie nicht nur als Steuereinheit für die jeweiligen Prüftechnologien und Messinstrumente, sondern hat auch erheblichen Einfluss auf die Konzeptionierung des gesamten Prüfaufbaus und der damit zusammenhängenden Infrastruktur.

Das Angebot der verfügbaren Schnittstellen, das betrifft sowohl in der Hardware als auch in der Software, entscheidet darüber, wie die Ressourcen verwaltet und miteinander vernetzt werden können. Es lohnt sich, diese Möglichkeiten in Betracht zu ziehen und der API mehr Bedeutung zuzumessen. (heh)

* David Werner ist Softwareentwickler im Team Integration bei Göpel electronic in Jena.

(ID:50694413)