Elektronische Baugruppenfertigung – Test Resources as a Service

Jede neu entwickelte, elektronische Baugruppe bringt eigene Anforderung an ein zuverlässiges Test- und Prüfsystem mit sich. Die Zielstellung lautet stets, eine möglichst hohe Testabdeckung zu erreichen und damit alle potentiellen Fertigungsfehler möglichst frühzeitig zu erkennen. Je nach verwendeten Bauteilen und Schnittstellen sind verschiedene Prüftechnologien und Test-Ressourcen notwendig, die für bestimmte Anwendungsfälle optimiert wurden.

Je nach Anbieter solcher Lösungen kann es vorkommen, dass die Test-Ressourcen proprietär mit der hauseigenen Software verknüpft sind – sie lassen sich also nur damit bedienen. Das wiederum kann dazu führen, dass Test-Ressourcen, die eigentlich vielseitig einsetzbar wären, aufgrund der festen Kopplung an eine bestimmte Software auf einen einzelnen, dedizierten Anwendungsfall beschränkt werden. Und selbst wenn eine freie Nutzung der Ressource zugelassen wird, ist es stets notwendig, zuerst die gesamte Software zu starten, bevor eine einzelne Funktion genutzt werden kann.

Diese Einschränkung stellt einen Hersteller elektronischer Baugruppen vor eine besondere Herausforderung. Denn er muss eine Testumgebung definieren, die so flexibel ist, dass sie auf unterschiedliche Produkte angewendet und bei Bedarf einfach erweitert werden kann. Sie soll sich aber auch einfach bedienen lassen, so dass der Initialaufwand zur Erstellung eines neuen Testfalls überschaubar bleibt. Normalerweise sind diese beiden Anforderungen gegenläufig: Je flexibler ein System aufgebaut werden kann, umso aufwändiger ist die Konfiguration/Programmierung einer konkreten Testanwendung. Je starrer ein System vorgegeben ist, umso einfacher lässt es sich bedienen, weil nicht so viele Optionen existieren.

Am Beispiel eines elektrischen Tests wird gezeigt wie Test-Ressourcen als Service angeboten werden können und somit neue Möglichkeiten zum Aufbau eines flexiblen Test- und Prüfplatzes bieten. Der Begriff „Service“ kann dabei wortwörtlich als Dienstleistung verstanden werden, aber er steht auch für das zugrunde liegende Kommunikationsverfahren (Webservice).

 

Dienstleistung

Eine Test-Ressource muss ihre eigenen Funktionen kennen und mit einfachen Kommandos nach außen geben. Die gesamte Logik zur Verarbeitung steckt innerhalb der Ressource, so dass auf Nutzerebene keine spezielle Software benötigt wird, welche komplexe Treiberaufrufe generiert und interpretiert. Jede Funktion der Ressource wird als einfach verständliches Kommando bereitgestellt, damit die „Dienstleistung“ in Anspruch genommen werden kann. Ein analoges Messinstrument soll beispielsweise eine klar definierte Funktion zum Messen eines Pegels an einem bestimmten Kanal besitzen. Als Antwort erhält der Nutzer den gewünschten Messwert in einer vorgegebenen Einheit.

Webservice

Für die Kommunikation empfiehlt sich eine netzwerkbasierte Variante, da hierbei sowohl eine große Verbreitung und Akzeptanz als auch ein hoher Stan­dar­di­sie­rungs­grad gegeben ist. Auf Netzwerkebene ist der notwendige Datendurchsatz gewährleistet und je nach Konfiguration kann eine angeschlossene Test-Ressource sogar zwischen mehreren Stationen geteilt werden. Somit wäre auch der Aufbau eines zentralen Test-Racks möglich, auf das von mehreren Seiten gleichzeitig zugegriffen werden kann. Für die Datenübertragung wird das Simple Object Access Protocol (SOAP) genutzt, welches auf XML-Nachrichten basiert. Dieser Standard wird durch die Beschreibungssprache WSDL beispielsweise von .NET-Umgebungen nativ unterstützt, so dass für die Entwicklung einer kundenspezifischen Test-Applikation keine zusätzlichen Dateien oder Bibliotheken benötigt werden. Die Test-Ressource gibt von sich aus alle ihre Funktionen nach außen bekannt. Durch die Implemen­tierung eines Web-Interfaces können über einen einfachen Web-Browser die Basis-Konfiguration angepasst, die Dokumentation eingesehen oder bereits Funktionen ausgeführt werden. Zusätzliche Handbücher oder Konfigurations-Tools gehören der Vergangenheit an.

Wie sieht eine solche Test-Ressource in der Praxis aus? Für die Inbetriebnahme sollte eine Stromversorgung und ein Netzwerkkabel genügen. Durch Eingabe der IP-Adresse in einem Web-Browser können alle Funktionen eingesehen werden. Bei Bedarf kann hier die Netzwerk­konfiguration entsprechend den eigenen Vorgaben angepasst werden. Am Beispiel der Erweiterungs­module SFX/VPC-TPC128 und SFX/VPC-AMC128 der Firma Göpel electronic soll das Gesamtkonzept verdeutlicht werden. Bei diesen beiden Modulen handelt es sich um ein digitales I/O-Modul und um ein analoges Messmodul zur Spannungsmessung mit jeweils 128 Kanälen. Beide Module sind im Bereich Embedded JTAG Solutions angesiedelt und wurden ursprünglich zur Erweiterung von Boundary Scan Tests konzipiert. Dementsprechend sind beide Module fest in die hauseigene Software integriert und können dort auf die vom Anwender gewohnte Weise genutzt werden. Da allerdings die Hauptfunktionen keineswegs auf diesen speziellen Anwendungsfall beschränkt sind, sondern ebenso in anderen Testanwendungen nützlich sein können, lassen sich die Module auch eigenständig einsetzen. Wer also beispielsweise nur ein digitales I/O-Modul für die Reaslisierung seiner Testaufgabe benötigt, kann dieses Modul einzeln nehmen und die Funktionen über den Webservice aufrufen.

Die Diskrepanz zwischen der gewünschten Flexibilität einer Ressource und dem daraus resultierenden Entwicklungsaufwand wird auf diese Art eliminiert. Sowohl der Einsatz innerhalb der hauseigenen Software als auch die flexible Nutzung als eigenständige Module basieren auf derselben Webservice-Schnittstelle. Die Bedienung ist in beiden Fällen sehr intuitiv und lässt sich gut für den jeweiligen Anwendungsfall adaptieren.

In diesem konkreten Fall wurde auch in anderen Punkten auf einheitliche Schnittstellen und Standardisierung gesetzt. Die I/O- bzw. Messkanäle sind auf einen VPC-Steckverbinder (Virginia Panel Corporation) geführt, der ein gängiges Format für Adaptersysteme darstellt. Damit wird die Integration in beliebige Testsysteme vereinfacht. Intern wurde außerdem auf eine Trennung zwischen Funktion und Kommunikation geachtet. So enthält die Trägerkarte lediglich den funktionalen Anteil (CION-LX™-ICs bzw. A/D-Wandler), während eine zusätzliche Aufsatzplatine das Betriebssystem inklusive der Webservice-Schnittstelle bereithält. Diese Aufsatzplatine ist funktionsunabhängig und kann somit auch zwischen verschiedenen Trägerkarten getauscht werden. Dies vereinfacht die Herstellungsprozesse, sorgt für kürzere Entwicklungszeiten der internen Logik und stellt sicher, dass die Bedienung durch den Anwender stets gleich bleibt.

Das Grundprinzip zur Steuerung von Instrumenten über eine LAN-Verbindung wird auch bereits seit 2005 durch den LXI-Standard angewendet. Die dort definierten Spezifikationen in Bezug auf die reine LAN-Verbindung mit LAN Configuration Initialize und Gigabit-Ethernet, Steckverbinder und Anzeigeelemente wurden auch für den hier beschriebenen Webservice-Ansatz berücksichtigt, da sie logische Voraussetzungen für eine performante Datenübertragung und eine zuverlässige Bedienbarkeit darstellen. Auch das W3C-konforme Web-Interface mit allgemeinen Informationen zum Instrument, Möglichkeiten zur Konfiguration der LAN-Schnittstelle und zur Ausführung von Funktionen ist im LXI-Standard verankert. In diesen Punkten gleichen sich die beiden Ansätze. Der wesentliche Unterschied besteht in der Einbindung in automatisierte Prüfprogramme. Der LXI-Standard verweist auf den IVI-Standard, den jedes Instrument erfüllen muss. Dies entspricht im Wesentlichen einer textbasierten Übertragung von Kommandos, die jedoch durch die Gruppierung gleichartiger Instrumente in Klassen einen Standard-Befehlssatz bereitstellt. Aufgrund identischer Befehle können Instrumente innerhalb einer Klasse problemlos gegeneinander ausgetauscht werden, indem nur der Ressourcen-Name ausgetauscht wird. Das Ziel besteht darin, durch eine IVI-Basisklasse 95% der Instrumente einer Kategorie abzudecken. Wird jedoch ein Instrument mit hochspezialisiertem Befehlssatz entwickelt, kann es nicht (oder nur sehr eingeschränkt) durch eine bestehende Klasse bedient werden. Ein Webservice umgeht dieses Problem, indem die komplette Funktionsschnittstelle im WSDL-Format veröffentlicht wird. Es gibt also keine Basisklassen, die für mehrere Instrumente gelten, sondern jedes Instrument gibt seine eigenen Funktionen bekannt. Die Identifikation erfolgt lediglich über die IP-Adresse. Durch den Import der WSDL-Beschreibung in eine Programmierumgebung kann sofort auf sämtliche Funktionen und Parameter zugegriffen werden. Das zugrunde liegende Simple Object Access Protocol ist ein industrieller Standard des W3C. Die folgende Tabelle zeigt eine kompakte Gegenüberstellung der beiden Ansätze.

 

Fazit: Der Ansatz, Test-Ressourcen eigenständig bereitzustellen, ist sicherlich nicht neu. Gerade bei Anbietern, die sich ausschließlich auf einzelne oder modulare Instrumente spezialisiert haben, steht diese Anforderung auf der Tagesordnung und es wurden bereits Standards entwickelt, die mit einem globalen Befehlssatz eine einheitliche Steuerung verschiedener Instrumente ermöglichen sollen. Die netzwerkbasierte Service-Architektur geht jedoch noch einen Schritt weiter, indem sie auch das Teilen bzw. die zentrale Verwaltung der Ressourcen ermöglicht und durch die Web-Oberfläche den Einstieg für den Anwender erleichtert. Auf diese Art können auch komplexe, modulspezifische Funktionen angeboten werden, die sonst nicht in einen globalen Befehlssatz passen würden.

Für Anbieter von Komplettsystemen kann der gesamte Ansatz völlig neue Einsatzfelder für einzelne Instrumente eröffnen. Wenn die feste Verzahnung von Test-Ressource und Software aufgebrochen wird, erweitern sich plötzlich die Anwendungsfelder. Es kann sich also lohnen, im Vorfeld darüber nachzudenken, ob eine Test-Ressource wirklich exklusiv mit der eigenen Software zusammen­spielen soll oder ob auch der eigenständige Einsatz Sinn machen kann. Bei den oben genannten Erweiterungsmodulen der Firma Göpel electronic war dies eindeutig der Fall. Ein digitales I/O-Modul oder ein analoges Messmodul können durchaus auch unabhängig von einer Boundary Scan Anwendung eingesetzt werden. Und da sich das Service-Konzept und die feste Kopplung an ein Software-Produkt nicht gegenseitig ausschließen, können – wie in diesem Fall umgesetzt – auch beide Varianten unterstützt werden. Eine servicebasierte Test-Ressource nachträglich in eine Software zu integrieren, was jedem Anwender freigestellt ist, ist schließlich deutlich komfortabler als eine proprietäre Test-Ressource nachträglich offenzulegen, was ausschließlich der Anbieter selbst leisten kann.

 

 

 

 

 

 

 

 

Autor: David Werner, GÖPEL electronic GmbH