Der Übergang von der Baugruppen-Entwicklung zur -Produktion ist oft schwierig. Zu verschieden sind die Anforderungen und Herangehensweisen. Für eine reibungslose Synchronisation zwischen Design und Fertigung bieten sich durchgängige Prüfkonzepte auf Basis eingebetteter Testfunktionen an.
Die kontinuierlichen Fortschritte in der Mikroelektronik und Halbleitertechnologie ermöglichen immer leistungsfähigere und kleinere Komponenten. Dadurch lassen sich mehr Funktionen auf begrenztem Raum integrieren, was die Komplexität der elektronischen Baugruppen deutlich erhöht. Künstliche Intelligenz und maschinelles Lernen eröffnen zwar neue Möglichkeiten und Anwendungen, erfordern aber auch leistungsstarke Prozessoren und aufwendige Algorithmen – was die Komplexität der elektronischen Baugruppen noch weiter steigert.
Entsprechend stellen sich in der Elektronikfertigung immer wieder knifflige Aufgaben. Besonders zwei Prozesse scheinen dabei häufig dem typischen Henne-Ei-Problem zu unterliegen: Entwicklung und Produktion. Bei der Entwicklung neuer Produkte sind zahlreiche Faktoren zu berücksichtigen, darunter Design, Materialauswahl oder diverse Leistungsparameter. Gleichzeitig müssen Produktionsanlagen und -prozesse auf die spezifischen Anforderungen des Produkts abgestimmt sein, um eine effiziente und qualitativ hochwertige Fertigung zu ermöglichen.
Oft stehen sich die Optimierungsziele oder Anforderungen beider Seiten konträr gegenüber. Oder es sind Daten erforderlich, ohne die eine weitere Entwicklung des Produktes oder des Fertigungsprozesses nicht möglich ist. Doch woher sollen diese Daten kommen, wenn weder das Design des Produkts noch Produktionsprozesse final definiert sind?
Nachfolgend geht es um die zentralen Herausforderungen, die bei der Überführung aus der Entwicklung in die Produktion auftreten, und es werden bewährte Strategien und Werkzeuge vorgestellt, die eine reibungslose Synchronisation beider Prozesse ermöglichen.
Das erste typische Henne-Ei-Problem betrifft das grundlegende Design des Produkts. Zu Beginn des Entwicklungsprozesses spielt vor allem die Materialauswahl eine große Rolle. Neben Faktoren der Leistungsfähigkeit verwendeter Komponenten ist deren Verfügbarkeit, aber natürlich auch der Preis ausschlaggebend. Allerdings sollte schon bereits während der Auswahl der zu verwendenden Komponenten auf eine geeignete Testbarkeit geachtet werden.
Die meisten Microcontroller, FPGAs (Field Programmable Gate Array) oder CPLDs (Complex Programmable Logic Device), die das Herzstück eines jeden Elektronikdesigns darstellen, unterstützen den sogenannten IEEE1149.1-Teststandard, der besser unter dem Namen Boundary Scan bekannt ist.
Dieser ermöglicht mit nur wenigen Zugriffspunkten, den typischen JTAG-Signalen (Joint Test Action Group), umfangreiche Testmöglichkeiten. Neben der grundlegenden Möglichkeit, Signale zu setzen und zu messen, lassen sich auch funktionale Testfunktionen, wie etwa das Auswerten einer Bauteilkennung oder die Ansteuerung verschiedener Sensorik realisieren. Grundlegende Testfunktionen werden dadurch integraler Bestandteil des Produktdesigns, wodurch externes Testequipment und komplexe Adaptionen erheblich reduziert werden (Bild 1).
Neben den klassischen Testmöglichkeiten des Boundary Scans, die in der Regel für statische Verbindungs- und einfache Funktionstests zum Einsatz kommen, können diese Zugriffe auch für zusätzliche Emulationstechnologien verwendet werden. Über die gleichen JTAG-Signale oder andere Debug-Schnittstellen können zum Beispiel Instrumente des Microcontrollers angesprochen, parametrisiert und für Testzwecke verwendet werden. Spezielle FPGA-Designs bieten sich für komplexe Testaufgaben wie etwa eine Frequenzmessung oder Bit-Error-Rate(BER)-Tests an.
Die Verwendung von nativ im Design eingebetteten Testfunktionen nennt Göpel Electronic Embedded JTAG Solutions (EJS). Unter diesem Begriff werden alle Instrumente sowie deren Einsatzmöglichkeiten zum Testen und Programmieren zusammengefasst. Mithilfe der gemeinsamen Softwareplattform »System Cascon« lassen sich sämtliche Zugriffe realisieren. Speziell an die Anforderungen aus Entwicklung und Produktion angepasste Hardware (z. B. Scanflex II Cube) ermöglicht eine nahtlose Verwendung von erstellten Prozeduren in beiden Anwendungsgebieten. Produktion und Entwicklung nutzen die gleichen Werkzeuge für Prototypentests, Erstinbetriebnahmen und Fertigungstests
Elektronikentwickler sehen sich oft mit Optimierungsprozessen konfrontiert. Besonders die Minimalisierung von elektronischen Designs steht dabei im Fokus. Speziell eine Reduzierung von Testpunkten ist dabei unerlässlich. Testingenieure auf der anderen Seite benötigen Zugriffspunkte, um kritische Bauteilgrößen, Signale oder Funktionen zu verifizieren. Dieses Dilemma führt zu Iterationen des Designs. Entwickler sind auf entsprechende Zuarbeiten seitens der Produktion angewiesen, um zu erfahren, wo das Design reduziert werden kann, ohne jedoch die Testabdeckung zu reduzieren. Testingenieure benötigen für diese Analyse allerdings detaillierte Designdaten aus der Entwicklung.
Der Test Coverage Analyzer in System Cascon ermöglicht eine frühzeitige Ab- schätzung der erreichbaren Testtiefe und liefert damit nützliche Daten für die Entwicklung. Dabei werden keine fertig designten Layouts oder sogar fertig produzierte Baugruppen benötigt. Für eine erste Evaluierung des Designs reicht eine Netz- und Bauteilliste bereits aus. Die Software berechnet nach entsprechender Modellierung bereits mögliche Testfunktionen und ermittelt auf dieser Basis eine Testabdeckung. In diesem frühen Stadium erlauben diese Daten eine tiefgreifende Analyse und geben somit Anhaltspunkte für Optimierungsmöglichkeiten.
Ein Beispiel ist die Reduktion von Testpunkten. Mittels der erstellten Testabdeckungsanalyse kann der Anwender bereits auf Signalebene betrachten, ob Testmöglichkeiten gegeben sind.
Im Grunde geht das System nur von den eingebetteten Instrumenten aus und ignoriert zunächst mögliche Zugriffe über Testpunkte. Wird das Signal als getestet markiert, kann ein entsprechender Testpunkt wahrscheinlich eingespart werden (Bild 2). Alle Elemente des Signals BSN6 wurden als getestet markiert (grün). Nur der Testpunkt TP1 wird nicht verwendet (rot). Er kann demnach bedenkenlos entfernt werden. Beim Signal BSN12 kann allerdings der Widerstand R16 nicht geprüft werden. Durch eine externe Adaption TP3 wäre dieser Test jedoch möglich. Eine Entfernung des Testpunkts würde also die Testabdeckung reduzieren.
Diese Analyse- und Optimierungsmöglichkeiten betreffen allerdings nicht nur die Reduzierung von Testpunkten, sondern auch das grundlegende Design. Verhindert ein Pull-Widerstand vielleicht schon die Aktivierung der eingebetteten Testfunktion? Kann eine alternative Bestückung einer Komponente aufgrund besser geeigneter Testinstrumente die Produktionsprozesse erheblich verbessern? Viele dieser Fragen lassen sich mithilfe des Test Coverage Analyzer frühzeitig beantworten.