Open-Loop-Tests: Effizientes Testing in der Embedded-Entwicklung

Inhaltsverzeichnis

Das Testen von Software für Embedded-Systeme bringt besondere Herausforderungen mit sich. Ein charakteristisches Merkmal eingebetteter Software besteht darin, dass sie mit der einbettenden Umgebung interagiert, bei Mikrocontrollern etwa über Peripherie-Pins. Beispielsweise schaltet oder liest die GPIO-Peripherie (General Purpose Input/Output) ein elektrisches Signal. Die CAN-Peripherie (Controller Area Network) sendet und empfängt ganze Nachrichten-Frames. Die Software, die diese Peripherie steuert und damit am Übergang zwischen Software und Hardware arbeitet, wird als Treiber bezeichnet. Solche Übergänge sind mit dem herkömmlichen Vorgehen besonders schwer zu testen. Open-Loop-Tests als Vorstufe zum Systemtest bieten dafür eine effiziente Möglichkeit und können daher einen Beitrag leisten, die traditionelle Testpyramide auch bei Embedded-Systemen sinnvoll umzusetzen.

Closed Loop versus Open Loop

Open Loop ist ein Begriff aus der Regelungstechnik, in der es darum geht, durch Beeinflussen eines Prozesses einen gewünschten Zustand am Ausgang herzustellen. Closed-Loop-Regler messen kontinuierlich den Ausgang. Aus der Abweichung zwischen Soll- und Istzustand lässt sich ein Stelleingriff berechnen. Open-Loop-Regler steuern blind einen Prozess und sind somit unabhängig vom aktuellen Systemzustand. Das vereinfacht die Handhabung.

Embedded-Systeme testet man üblicherweise auf mit Closed-Loop-Reglern vergleichbare und entsprechend aufwendige Weise. Mit Open-Loop-Prinzipien lässt sich die Komplexität des Testens deutlich reduzieren. Die Tests sind dadurch kompakt und verständlich.

Als Beispiel dient ein Embedded-System zur Drehzahlregelung eines Motors. Es

• basiert auf einem Mikrocontroller,
• erhält über den CAN-Bus Nachrichten mit einer Soll-Drehzahl,
• steuert durch Pulsweitenmodulation (PWM) eine Leistungselektronik zur Versorgung des externen Motors,
• erhält über einen Drehgeber Impulse, aus denen sich die Ist-Drehzahl errechnen lässt, und
• enthält einen internen Temperatursensor, um das System bei Überhitzung abschalten zu können.

Eine typische Anforderung könnte folgendermaßen formuliert sein: Wenn eine CAN-Nachricht eine Drehzahl von 100 U/min vorgibt, muss das System innerhalb von zwei Sekunden eine Drehzahl zwischen 98 und 102 U/min erreichen. Zum automatisierten Prüfen dieser Funktion ist ein Teststand erforderlich (Abbildung 4).

Das Testsystem simuliert für das zu prüfende Embedded-System (System Under Test, SUT) einen Motor, erzeugt also ein Drehgebersignal in Abhängigkeit von einem Plus-Minus-Signal. Die Eingänge des SUT sind somit von dessen Ausgängen abhängig (Closed Loop). Die Bewertung des Tests findet am Ausgang statt und lautet Pass oder Fail. Der Systemtest kann automatisiert stattfinden. Dabei gibt es jedoch eine Reihe von Problemen:

1. Die Fehlersuche ist schwierig. Als Verursacher kommen die Embedded-Firmware, die Hardware (Platine) oder eine fehlerhafte Simulation im Testsystem infrage.
2. Der Test überprüft das System für eine einzelne Bedingung. Es lässt sich nicht zeigen, dass etwa zusätzlich das Erzeugen der Pulsweitenmodulation auf dem Mikrocontroller für alle Tastgrade, also die Verhältnisse von Puls zu Periode, korrekt arbeitet.
3. Der interne Temperatursensor ist nicht Teil der Testschnittstelle. Um die Temperaturabschaltung zu prüfen, kann man den Teststand durch eine Heizung ergänzen. Dann lässt sich aber nicht mehr prüfen, wie das System beispielsweise auf einen defekten Sensor reagiert.
4. Jeder Teststand muss für die konkreten Belange des Prüflings neu aufgebaut werden.

Generell lassen sich die Probleme auf eine fundamentale Einschränkung bei Closed-Loop-Tests zurückführen: Das SUT hat viele interne Zustandsgrößen, die nach außen nicht sichtbar sind. Der Test kann lediglich versuchen, möglichst viele interne Zustände durch eine passende Auswahl von Eingangsgrößen herzustellen.

Open-Loop-Testing zwecks Vereinfachung

Bei Open-Loop-Tests entfällt die Notwendigkeit, interne Zustandsgrößen zu prüfen. Im Systemtest war die gesamte Leiterplatte Ziel des Tests. Der vorgeschlagene Open-Loop-Test hingegen betrachtet hier ausschließlich den Mikrocontroller.

Der Test hat die Aufgabe, die korrekte Funktionsweise des PWM-Treibers zu prüfen (siehe Abbildung 5, oben). Das Testsystem steuert ihn über eine Schnittstelle mit einem Tastgrad an. Der Mikrocontroller gibt an einem Pin ein PWM-Signal aus. Wenn das den gewünschten Tastgrad aufweist, lautet die Bewertung Pass, sonst Fail. Bei der Open-Loop-Struktur existiert keine Rückkopplung der Ausgänge auf die Eingänge des Mikrocontrollers.

In gleicher Weise lassen sich die Eingänge des Mikrocontrollers testen (siehe Abbildung 5, unten). Dabei erzeugt das Testsystem ein elektrisches Signal, das die Impulse des Drehgebers nachbildet. Die gemessene Drehzahl lässt sich im Anschluss über eine Schnittstelle aus dem Mikrocontroller auslesen.

Auf dem Mikrocontroller läuft eine spezielle Firmware, die unverändert alle zu testenden Teilkomponenten enthält. Eine Schnittstelle erlaubt das Steuern und Auslesen von außen. Der gezeigte Test kann somit als Hardware-Software-Integrationstest verstanden werden. Diese Struktur hat eine Reihe nennenswerter Vorteile:

1. Durch den Fokus auf eine Komponente hat jeder Testfall eine geringe Komplexität. Tests sind kompakt und damit leicht lesbar. Schlägt ein Test fehl, lässt sich die Ursache direkt zuordnen.
2. Jede Komponente kann systematisch für alle denkbaren Eingangswerte getestet werden.
3. Es ist möglich, interne Fehlerzustände zu prüfen, die in einem Systemtest nicht zugreifbar sind. Beispielsweise kann man die Treiber auf ein Verhalten bei Überlastung des CAN-Busses oder eine vorübergehende elektrische Störung der I²C-Kommunikation prüfen.
4. Die Tests finden auf Pin-Ebene des Mikrocontrollers statt, die für eine Vielzahl von Peripherien standardisiert ist. Damit lässt sich ein Testsystem für unterschiedliche Prüflinge wiederverwenden.

Closed Loop und Open Loop im Vergleich

Kriterium	Closed Loop	Open Loop
Interne Zustände	nicht sichtbar	sichtbar
System als Ganzes testbar	ja	nein
Tests auf dem realen MCU	ja	ja
Tests isoliert von spezifischer PCB	nein	ja
einzelne Funktionen isoliert testbar	nein	ja
Aufwand	hoch, da individuell für jedes System	gering, da standardisierte Pin-Funktionen