Solch unmittelbarer 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, denn 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 Potential 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.
Automatisierung für mehr Qualität
Abhilfe schafft hier 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 auf Hardware-Seite bestimmte RS-232-Befehlssätze oder spezielle Instrumenten-Treiber und auf Software-Seite 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, der unter Verwendung der jeweiligen API die festgelegten Prüfungen durchführt. 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.
Fortschrittliche Programmierschnittstelle
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.
Während diese Neuerungen stets darauf ausgelegt waren, die Einbindung in eine Steuer-Software und den Zugriff auf die einzelnen Funktionen zu vereinfachen, 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 aufwändiger, die Rechner-Belastung steigt und die vielen Systemeingriffe gefährden schlussendlich auch die Stabilität. Ausfälle oder Verzögerungen sollen jedoch in der Produktion vermieden werden. Hinzu kommt, dass für jeden weiteren Testplatz der komplette Prüfrechner dupliziert werden muss und dass auch die Betriebssystemarchitektur eine Rolle spielt – so muss jedes Prüfprogramm und jeder Gerätetreiber überhaupt erst mit dem Prüfrechner kompatibel sein.
Um diesen Punkten entgegen zu wirken, wird diese kombinierte Verwaltung aller Komponenten auf einem System aufgelöst. Aus Sicht der Hardware ist das in vielen Bereichen bereits durch die Implementierung einer Ethernet-Schnittstelle erfolgt. Anstelle von USB oder auch Einsteckkarten im PCIe-Format, für die ein Gerätetreiber installiert werden muss, erfolgt der Anschluss über eine Netzwerkverbindung, die unmittelbar einsatzbereit ist. Um nun auch die Software zu entkoppeln, wird eine API benötigt, die entsprechende Netzwerktechnologien unterstützt und somit die Verteilung der Systeme ermöglicht.
Wandel erfordert Überarbeitung
Einen solchen Strukturwandel hat die Firma Phytec Messtechnik GmbH durchlaufen. Dort wurde ein Prüfkonzept entwickelt, mit dem unterschiedliche System on Module (SOM) Baugruppen am Ende der Produktionslinie getestet werden. Als Teststrategien kommen JTAG / Boundary Scan der Firma Göpel electronic GmbH und Funktionstest zum Einsatz. Am Ende der Prüfung werden die Baugruppen mit einem Bootloader programmiert und mit einer Seriennummer versehen. Die aktuelle Systemkonfiguration ist seit 10 Jahren im Einsatz und besteht aus einem Prüfrechner, einer Master-Einheit mit Adaption für den speziellen Prüfling sowie einem JTAG Controller.
Als Betriebssystem des Testplatzes kommt Microsoft Windows zum Einsatz. Die Ablaufsteuerung wird als VBA Script unter Microsoft Access ausgeführt. Die 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 des Unternehmens für Embedded Systeme ist Windows als grafisches Betriebssystem für eine automatisierte Ablaufsteuerung ungeeignet, VBA schwer zu verwalten und das Gesamtsystem sehr pflegeaufwändig bei Updates. Daraus ergab sich die Notwendigkeit einer Umgestaltung der Software-Landschaft mit folgenden Anforderungen:
- Betriebssystem Linux
- Ablaufsteuerung mit der Scriptsprache Python
- Auslagerung von System CASCON auf einen Server und Steuerung per Netzwerk-API
- Verbindung des JTAG Controllers über Ethernet.
In diesem neuen Konzept wurde der Prüfrechner aus Sicht des Boundary Scan Tests auf einen Thin Client reduziert, der keine Ressourcen mehr bereitstellen muss, sondern lediglich mit dem zentral organisierten Server-Rechner kommuniziert. Eine solche Verwaltung setzt eine entsprechende API voraus, die durch einen SOAP Webservice 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 selbst dafür entscheidende Vorteile. Der Prüfrechner wird nicht durch zusätzliche Software belastet und ist dementsprechend weniger störanfällig. Zudem ist die Inbetriebnahme und Wartung von zwei getrennten, dedizierten Rechnern deutlich einfacher als bei einem kombinierten System mit allen Komponenten.
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 Webservice-Steuerung umgestellt wurden. Mit der Einführung neuer Produkte werden weitere dezentrale Testplätze in die Netzwerkstruktur aufgenommen. 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 bestehend aus der Mastereinheit und dem JTAG Controller dupliziert. Auch andere Formen der Skalierung wie beispielsweise die Steuerung mehrerer JTAG-Controller über einen Prüfrechner sind auf diese Weise realisierbar und bieten somit 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 einen erheblichen Einfluss auf die Konzeptionierung des gesamten Prüfaufbaus und der damit zusammenhängenden Infrastruktur. Das Angebot der verfügbaren Schnittstellen sowohl in der Hardware als auch in der Software entscheiden 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.
www.goepel.com | www.phytec.de
