Legacy-Testsysteme Worauf es bei der Teststrategie und Testplattform ankommt

Autor / Redakteur: Hans Baka* / Dipl.-Ing. (FH) Hendrik Härter

Zwischen den Fertigungsstrategien für Militär- sowie Luft- und Raumfahrt-Elektronik und Unterhaltungselektronik gibt es entscheidende Unterschiede. Ein Wesentlicher ist die Lebensdauer, denn militärische Projekte müssen Jahrzehnte fehlerfrei funktionieren, während ein Konsumgerät schon zum Elektronikschrott gehört. Wie kann mit einer seit fünf Jahren nicht mehr unterstützten Testplattform eine elektronische Baugruppe getestet werden, die zwei Jahre alt ist?

Anbieter zum Thema

Bei militärischen Projekten wird eine gemeinsame Plattform für den Produktionstest und für den Einsatz in den Test- und Reparaturdepots der zweiten und dritten Stufe vorgeschrieben. Damit soll zumindest ein Teil der möglichen künftigen Legacy-Testprobleme gelöst werden.

Angenommen der Anbieter der Testlösung ist zum entsprechenden Zeitpunkt immer noch im Geschäft und auch das ursprüngliche Software-Betriebssystem funktioniert noch. Dann können für die verschiedenen Projekte immer noch unterschiedliche Plattformen notwendig sein, die zudem in den jeweiligen Serviceorganisationen und Ländern variieren können. Auf Grund künftiger und aktueller Gegebenheiten führt kein Weg an einer einheitlichen Legacy-Plattform vorbei. Es sollte eine einheitliche Plattform sein, die für Testpakete aus unterschiedlichen Quellen und Projekten geeignet ist.

Schwachpunkte bei den Legacy-Testsystemen

Wie anfällig Legacy-Plattformen sind, zeigen die Reparaturzentren, wo die Produkte über lange Zeit unterstützt und instandgesetzt werden müssen. An diesen Standorten stehen meist viele alte Plattformen von unterschiedlichen Anbietern mit zahlreichen Testadaptern, die Test und Diagnose für Feldrückläufer ermöglichen sollen. Aber diese Strategie hat einige grundlegende Schwachpunkte:

  • Produktionstestprozesse wurden entwickelt, um Produktionsfehler zu finden und sind nicht unbedingt für die Fehlersuche bei Feldausfällen geeignet. Durch das unterschiedliche Fehlerspektrum ist meist zusätzliche Nacharbeit notwendig,
  • Irrglaube ist, dass die aus der Produktion übernommenen Plattformen und Vorrichtungen ausreichend funktionieren und sofort einsetzbar sind,
  • dass die übernommenen Plattformen immer noch von den ursprünglichen Anbietern unterstützt werden. Besonders seit dem Markteinbruch im Jahr 2000 werden viele der älteren Plattformen nicht mehr unterstützt und
  • dass innerhalb des Reparaturzentrums keine entsprechende Fertigkeiten vorhanden sind, um die unterschiedlichen Plattformen zu unterstützen und die Entwicklungsumgebungen zu testen. Ältere Testplattformen verwenden oftmals Unix und spezielle Testsprachen, die nicht nur einzigartige Entwicklungsumgebungen, sondern auch immer seltener verfügbare Programmierfertigkeiten erfordern können.

Das Ergebnis dieser Problematik ist, dass der andauernde Support der vielen alten Testplattformen immer mehr Zeit und Kenntnisse erfordert.

Testsysteme zu rationalisieren ist ein komplizierter Prozess

Die Teststrategien für Reparaturzentren und neu zusammengelegte Organisationen zu rationalisieren, die mit einer großen Basis von vorhandenen Testplattformen und Testvorrichtungen konfrontiert sind, kann kompliziert werden. Solange aber keine Maßnahmen ergriffen werden, um den Unterstützungsaufwand für die Plattformen zu reduzieren, werden die Ingenieure durch die Forderung nach internem Testsupport ständig von ihrer eigentlichen Aufgabe abgehalten.

  • Kritische Funktionen abdecken:

Als erster Schritt sollte eine allgemeine Teststrategie implementiert werden, die für die Mehrheit der Testaufgaben geeignet ist. Eine vorhandene Plattform kann verwendet werden, eine höhere Produktivität lässt sich aber nur mit einer Testplattform erreichen, die speziell konzipiert wurde. Der MTS300 wurde so entwickelt, dass alle für eine Migration von Testanwendungen erforderlichen kritischen Funktionen abgedeckt werden.

  • Eine nicht-gemultiplexte Testpin-Architektur:

Es muss sichergestellt werden, dass die bestehenden Pin-Multiplex-Anforderungen berücksichtigt werden. Zum Multiplexing ist dabei folgendes anzumerken: Viele Testplattformen, darunter die von HP/Agilent und GenRad/Teradyne, nutzen Testarchitekturen mit Multiplexing. Durch das Multiplexen kostspieliger Ressourcen lassen sich die Kosten pro Pin senken, da jeder echte Pin mit vollen analogen, sowie digitalen Treiber- und Sensorfunktionen mit mehreren Testpins geteilt wird. Der Testingenieur muss sicherstellen, dass für jeden Test eine richtige Zuordnung der Testpins über die verfügbaren echten Pin erfolgt. Leider gibt es keinen Standard für das Multiplexen von Testpins. Das bedeutet, dass die meisten Testanwendungen nicht einfach auf eine andere Testplattform übertragen werden können, die ebenfalls eine multiplexte Architektur nutzt.

  • Eine universelle Schnittstelle:

Eine universelle Schnittstelle, die für Adapterkonverter aller führenden ICT-Plattformen geeignet ist und sicherstellt, dass die Investition in die vorhandenen kostspieligen Testadapter für künftige Teststrategien geschützt und wieder verwendet werden kann.

  • Tools zur Software-Umstellung:

Es ist wünschenswert, einen automatisierten und konsistenten Umwandlungsprozess für Testanwendungen zu haben. Das MTS300 verhält sich wie eine neutrale Plattform, die bestehende Testprogramme emulieren kann.

  • Künftige Unterstützung:

Die ausgewählte Plattform sollte in jedem Fall von einem führenden Anbieter geliefert werden, der nachweisbare Erfolge im Hinblick auf eine Unterstützung über eine erweiterte Lebensdauer vorweisen kann.

Nach der Auswahl der Testplattform sollte als nächster Schritt die Umstellung der Testprogramme erfolgen, und zwar nach Prioritäten. Die Prioritäten ergeben sich durch:

  • Fragilität der vorhandenen Testplattform (Alter, Ersatzteile, Unterstützung),
  • Kosten für die Unterstützung der vorhandenen Testplattform,
  • künftige Nachfrage der jeweiligen Produkttypen,
  • Qualität der vorhandenen Testanwendung (sind Verbesserungen im Zuge der Umstellung möglich?),
  • einfache Umstellung und
  • verfügbare Entwicklungs-Ressourcen

Durch diese Maßnahmen und eine sorgfältige Planung sollten bald nach Implementierung messbar bessere Ergebnisse erkennbar sein. Damit kann sichergestellt werden, dass die aktuelle Situation mit mehreren und obsoleten Testplattformen auf einen nachhaltigen Zustand rationalisiert werden kann, mit dem die beträchtlichen Investitionen in Testadapter und Anwendungen geschützt werden können.

*Hans Baka ist Geschäftsführer bei Digitaltest in Stutensee.

(ID:262369)