Volle Flexibilität erhalten

Auf der Hardware-Seite lassen sich Testsysteme in vielen Fällen mit relativ einfachen Mitteln vereinheitlichen, beispielsweise mit einer offenen, modularen Architektur. Deutlich mühsamer wird es auf der Software-Seite, denn hier kommen Unterschiede im Fertigungsumfeld zum Tragen. Zwei wesentliche Beispiele für diese Unterschiede sind:

• Ablaufsteuerung: Diese erfolgt manchmal manuell (über das User Interface), manchmal komplett automatisiert (über eine SPS, beziehungsweise ein automatisiertes Handler-System), manchmal aber auch semiautomatisch (zum Beispieel automatischer Start beim Schließen eines manuellen Testadapters).
• User Interface: Hier gibt es meist spezifische Anforderungen an die darzustellenden Informationen. Aber auch die Konfiguration des Systems ist immer wieder unterschiedlich. Werden Fertigungsauftragsnummern zum Beispiel eingegeben, gescannt oder von einem übergeordneten Produktionsplanungssystem entnommen?

Die Unterschiede in den Anforderungen zwischen den einzelnen Testsystemen sind so gravierend, dass oft der erwähnte Schwarz-Weiß-Ansatz gewählt wird: Rund um die Testexekutive wird für fast jedes System eine individuelle Anpassungsschicht erstellt. So kommt es bald zu einer Ansammlung von Einzellösungen, die zwar auf gemeinsamen Komponenten wie der Testexekutive beruhen, aber doch Einzellösungen bleiben.

Vor allem das Fertigungsmanagement wünscht sich jedoch eine weitergehende Standardisierung mit folgenden Vorteilen:

• Reduzierte Kosten durch Wiederverwendung bei der Umsetzung neuer Systeme, bei der Schulung der Mitarbeiter und im Bereich Wartung.
• Ein einheitlicher Look and Feel in der Fertigung, was nicht zuletzt auch bei Audits oder Kundenbesuchen immer gerne gesehen wird.
• Eine übergeordnete, zentrale Verwaltung von Stammdaten wie Produktdaten, Benutzerdaten, Testparameter und so weiter.
• Einheitliche Testdatenspeicherung, -weiterbearbeitung und -analyse.

Standardisierung ist also wichtig und sinnvoll, aber wie lässt sie sich im Fertigungsumfeld erreichen? Der Schlüssel ist, wie auf der Hardware-Seite, eine offene, modulare Architektur, die Lösungswege und Konventionen vorgibt, dabei aber gleichzeitig die nötigen Anpassungen zulässt. Worauf kommt es also bei der Definition einer solchen Architektur an?

Maßnahme 1: Standardisierung in der Ablaufsteuerung

LXinstruments bietet mit dem Testsystem Operator Environment (TSCOE) eine einheitliche Benutzerschnittstelle und Ablaufsteuerung an, die den erwähnten Ansatz von Offenheit und modularem Aufbau konsequent verfolgt. TSCOE setzt dort an, wo eine Testexekutive aufhört und ergänzt diese. Damit lässt sich ein erheblich höherer Grad an Standardisierung erreichen. Ein zentrales Element von TSCOE ist dabei eine State Machine, die den Ablauf kontrolliert (Bild 1).

Der Ablauf (Zustandskontrolle) ist klar definiert und standardisiert. Die orange gekennzeichneten Zustände beziehungsweise das Verhalten in diesen Zuständen werden in Form von Plug-Ins umgesetzt, die sich dynamisch austauschen lassen. Damit kann der Ablauf an die jeweiligen Bedürfnisse der Anwendung angepasst werden, ohne den Kern der Anwendung und die gewählten Paradigmen insgesamt zu berühren. Einige Beispiele dazu:

• Im Zustand Configuration wird ermittelt, welches Produkt mit welchem Prüfplan getestet werden soll. Hier sind häufig Anpassungen nötig, denn diese Informationen werden teils manuell eingegeben, teils von einem anderen System übergeben.
• Im Zustand Testing läuft die eigentliche Testschleife ab. Hier wird für jedes Produkt eine Seriennummer eingelesen oder erzeugt. Dann wird für diese Seriennummer die eigentliche Prüfung gestartet. Der Prüfablauf obliegt der Steuerung durch die Testexekutive.

Im Detail besteht der eigentliche Testablauf wieder aus einer einfachen State Machine (Bild 2), die die Vor- und Nachbereitung des Testablaufs regelt, wie zum Beispiel (De-) Kontaktierung, und  die Testresultate verarbeitet sowie speichert.

Bilder 1 und 2 zeigen deutlich, dass die Bereiche, in denen Anpassungen möglich beziehungsweise nötig sind, reduziert werden auf klar definierte Funktionen wie Konfiguration oder Behandlung der Seriennummern. Gleichzeitig bleiben aber der grundsätzliche Ablauf und das Verhalten in den blau markierten Zuständen unverändert. Neue Anwendungen können mit dieser klaren Trennung durch die reduzierte Komplexität effizient umgesetzt werden. Mit diesem Modell lassen sich sehr unterschiedliche Anwendungen realisieren:

• Verschiedene Automatisierungsgrade,
• Einzeltest oder Test im Nutzen,
• paralleler, asynchroner Test – mehrere parallele Testabläufe (Bild 2), die sich den Basisablauf (Bild 1) teilen.

Maßnahme 2: Standardisierung im Bereich User Interface

Die Benutzerschnittstelle ist ein weiterer Bereich, in dem es oft schwerfällt, Standardisierung einerseits und sinnvolle Anpassungen andererseits gleichwertig zu kombinieren. LXinstruments löst diesen Konflikt durch eine klare Trennung von unveränderbaren Bereichen, die zum Kern der Applikation gehören und solchen, in denen eine Anpassung möglich ist (Bild 3).

Im Wesentlichen ist der orange markierte Bereich reserviert für lösungsspezifische Anzeigen beziehungsweise Eingabefelder. Der Inhalt dieses Bereichs wird definiert und verwaltet vom Plug-In des Configuration-Zustands (siehe oben). Auch aus Sicht der Bedienerschnittstelle lassen sich so verschiedene Automatisierungsgrade und Testsituationen (Einfachtest, Paralleltest, Nutzentest) umsetzen.

Wiederverwendbarkeit zum Preis erhöhter Komplexität?

Natürlich birgt der Ansatz, sehr verschiedene Situationen bedienen zu können, immer die Gefahr erhöhter Komplexität. Auch in diesem Fall ist eine gewisse Grundkomplexität in der Architektur nötig, um zum Beispiel den asynchronen, parallelen Test durchführen zu können.

LXinstruments hat folgenden Weg gewählt, um die Komplexität für den Integrator zu reduzieren. Eine umfangreiche Programmierschnittstelle (API) steht zur Verfügung, um typische Plug-In-Aufgaben zu erledigen. So lässt sich mit einfachen Aufrufen eine Seriennummer erzeugen, eine Auswahlliste auf dem Bildschirm platzieren oder die Testkonfiguration ändern. Für alle Zustände, die angepasst werden können, werden lauffähige Beispiele im Quellformat geliefert und können als Template direkt verändert oder erweitert werden.

In Kombination von modularer Architektur und diesen Maßnahmen lässt sich ein Großteil der Komplexität verringern, obwohl Anpassungen effizient durchgeführt werden können.

Viele Fertiger archivieren ihre Testdaten lückenlos, haben aber Mühe mit dem Zugriff darauf. Die Daten werden daher nur im Notfall sinnvoll genutzt. Hier liegt ein weiterer, wesentlicher Vorteil der Standardisierung. Bei einheitlicher Speicherung der Daten können durch gezielte Analysen Aussagen über Prozessfähigkeit oder Messmittelfähigkeit getroffen und damit Probleme proaktiv in der Entstehung erkannt werden, bei Bedarf auch über Produkte oder Testsysteme hinweg. LXinstruments bietet dazu als Teil der Tool-Chain folgende Werkzeuge an:

• Eine SQL-basierte Datenbank, welche sowohl Fertigungsdaten als auch Testergebnisse lückenlos speichert. Eine professionelle Datenbank ist der Königsweg, um die anfallenden Datenmengen über einen längeren Zeitraum hinweg zu verwalten.
• Eine Client-Applikation (Magpie), die die gezielte Suche/Filterung der Daten erlaubt. Mit den herausgefilterten Daten können anschließend Reports oder Analysen erstellt werden.

Ein Beispiel dazu: Magpie hilft mit seiner statistischen Analyse Probleme in der Fertigung zu erkennen. So lassen sich unter anderem Testergebnisse als Histogramme darstellen (Bild 4).

Ein stabiler Prozess wird typischerweise Verteilungen zeigen, die in etwa einer Gauss-Kurve entsprechen. Perfekte Gauss-Kurven kommen in der Praxis selten vor, gravierende Abweichungen sind aber ein Grund, die Daten näher zu untersuchen und nach der Quelle der ungewöhnlichen Verteilung zu suchen.

Bild 5 zeigt ein solches Beispiel; hier sind zwei Gauss-Verteilungen überlagert, was bei einer plötzlichen Änderung im System, beispielsweise einem Komponentenwechsel im Prüfling oder einer Reparatur am Testsystem selbst passieren kann. Durch Anpassen der Suchkriterien lässt sich dann im nächsten Schritt herausfinden, welche Prüflinge von der Änderung betroffen sind. Für solche, gezielte Analysen stellt Magpie eine Vielzahl von Suchkriterien zur Verfügung, die sich beliebig kombinieren lassen, zum Beispiel:

• Zeitraumsuche,
• Suche nach Testsystem,
• Suche nach Produkt/Revision,
• Suche nach Bediener,
• Seriennummern- oder Auftragsnummernsuche.

Die von Magpie erzeugten Reports können zwar die eigentliche Problemursache nicht erkennen, helfen aber dabei, in den riesigen Datenmengen verborgene Probleme zu finden und zu qualifizieren. Sie lenken mit wenig Aufwand die Aufmerksamkeit auf die Bereiche, in denen sich eine genauere Untersuchung lohnt.

(ah)