Automatisiertes Validierungs-System Die nächste Ebene der MCU-Validierung

Abstraktion der DUV-Spezifika

Um einen Test für nur einen spezifischen Mikrokontroller zu schreiben, muss der Anwender sich nur mit der zu testenden MCU und dem verwendeten Test Setup auskennen. Soll jedoch der Test für mehrere unterschiedliche MCUs verwendet werden, so muss bei der Testrealisierung auf mehr geachtet werden. Hierbei muss sich der Anwender zuerst Gedanken dazu machen, welche Elemente des Tests spezifisch für das DUV sind und welche generisch, das heißt immer gelten, egal welches DUV getestet wird. So ist zum Beispiel die Reihenfolge der einzelnen Testschritte immer generisch, während die verwendeten DUV-Pins und Speicheradressen unterschiedlich sein können. Auch können zusätzlich benötigte DUV-Ressourcen für einen Test unterschiedlich sein, abhängig vom DUV, zum Beispiel kann das Triggersignal für ein zu testendes DUV-Modul unterschiedliche Quellen haben. Dies muss beim Realisieren eines Tests im AVS-System beachtet werden, sowohl bei der optionalen Firmware als auch beim benötigten Testskript.

Bei der Firmware lässt sich das dadurch erreichen, dass im Quellcode alle DUV-spezifischen Bestandteile in separate Funktionen ausgegliedert werden, die dann an zentraler Stelle zusammengefasst werden. Soll nun existierender Firmware-Code einem neuen DUV angepasst werden, so muss nur der Code an dieser zentralen Stelle angepasst werden und alle Tests können an das neue Bauteil angeglichen werden. Dies erfordert meistens keinen großen Aufwand, da diese Regel für viele Software-Projekte im Embedded-Bereich schon üblich ist.

Bei einem Testskript sind die spezifischen Elemente meistens die unterschiedlichen Pinouts der verwendeten MCUs und damit eine unterschiedliche Verbindung zwischen Instrumenten und DUV. Da diese Verbindungen über das verwendete PCB realisiert werden, müssen diese Information in einem Testskript abstrahiert werden und die detaillierte Anweisung, wie die Verbindung für das aktuell verwendete DUV hergestellt werden soll, ebenfalls an zentraler Stelle abgelegt werden. Dadurch lässt sich der Aufwand zur Portierung eines Testskripts auf ein neues MCU-Derivat durch das Anpassen dieser zentralen Stelle reduzieren. Im realisierten AVS-System wird dies in zwei Stufen realisiert.

Im Testskript wird nur die gewünschte Signalfunktion referenziert, hier als Beispiel ein generisches digitales Portsignal „P1.0“. Dieses Signal kann auf unterschiedlichen DUV-Pins liegen, abhängig vom verwendeten Derivat. Dies führt dazu, dass dieses Signal auf unterschiedlichen Messkanälen auf dem PCB liegt. Im ersten Schritt sucht das AVS-System in einer zentralen Übersetzungstabelle danach, welcher DUV-Pin diese Funktion hat und welcher PCB-Messkanal an diesem Pin angeschlossen ist. Nun muss dieser Messkanal auf einen Kanal eines Digital-IO-Messgeräts geschaltet werden. Da dies meistens über Multiplexer auf dem PCB realisiert wird, um die Anzahl der benötigten Instrumente gering zu halten, schaut im zweiten Schritt das AVS-System nach, welcher Kanal des verwendeten IO-Instruments (zum Beispiel PXI-6551) für diesen PCB-Messkanal zuständig ist und wie die Multiplexerkonfiguration dafür lautet.

Abstraktion der Hardware-Spezifika

Um den Austausch von Tests auch zwischen komplett unterschiedlichen MCU-Familien zu ermöglichen, ist es wichtig, dass das AVS-System mit unterschiedlichen Instrumenten/Hardware-Aufbauten für die gleichen Testfunktionen umgehen kann. Das folgt daraus, dass zwar gleiche DUV-Module und daher auch die gleichen Tests verwendet werden, aber die zu testenden Bauteile ganz unterschiedliche Anwendungsbereiche adressieren und dadurch der Hardware-Aufbau für die Validierung sehr unterschiedlich sein kann. Zusätzlich ergibt sich dadurch auch die Anforderung, dass neue Instrumente und Funktionen in das System leicht zu integrieren sein müssen, um das System für zukünftige neue Anforderungen flexibel zu halten. Auch hier bietet sich eine Abstraktion wie bei den DUV-Spezifika an. Dazu werden die verwendeten Befehle in den Testskripten zuerst in Funktionsgruppen zusammengefasst, sogenannte Klassen, die den Anwendungszweck der Befehle definieren. Zum Beispiel werden alle Befehle zur Interaktion mit einem Digital-IO-Instrument unter der Klasse „DigitalIO“ zusammengefasst. Ebenfalls werden die Befehlsnamen nach der beabsichtigten Funktion ausgewählt ohne einen direkten Bezug zu einem spezifischen In¬strument. Ein Befehlsaufruf in einem Testskript hat dadurch folgenden Aufbau: „<Klasse>.<Befehlname>(<parameterliste>)“. Dadurch sind Testskripte generisch ohne Bezug zu einem konkreten Instrument. Zusätzlich erlaubt diese Regelung, dass ein Testskript leicht zu verstehen und erstellbar ist, ohne dass ein Anwender das System im Detail begreifen muss.

Bei der Ausführung eines solchen Befehls in einem Testskript greift nun das AVS auf das entsprechende LabView-VI zu, das die Funktion auf dem Instrument ausführt. Dazu wird wieder eine zentrale Tabelle verwendet, in der die Zuordnung eines Befehls in einer Klasse zu einem konkreten VI definiert wird. Mit dieser Zuordnungstabelle kann einfach ein anderes Instrument mit der gleichen Funktion in einem System eingesetzt werden, ohne dass Skripte angepasst werden müssen. Es muss nur das entsprechende VI vorhanden sein oder notfalls einmal erstellt werden. Da diese VIs separat sind und nicht direkt im AVS-Programm referenziert werden, sind sie leicht zu erstellen und können direkt genutzt werden, ohne den Code des AVS-Systems selbst zu verändern. Lediglich müssen die entsprechenden VIs im System abgelegt und in die Zuordnungstabelle eingetragen werden.

Einsatz bei Texas Instruments

Das vorgestellte AVS erlaubt es den unterschiedlichen MCU-Teams innerhalb von Texas Instruments, schnell und einfach ein Validierungssystem zu realisieren. Das System wird inzwischen in mehreren Teams produktiv eingesetzt und befindet sich in anderen Teams im Ramp-up. Damit konnte ein erheblicher Effizienzgewinn erreicht werden, da die aufgewendete Arbeitszeit für das Erstellen von neuen Tests verwendet werden kann. Auch wurde die Qualität der Validierung erhöht, da die Tests den Validierungsraum besser abdecken können.

Unterlagen nach Markus Kösler (Texas Instruments