Open Loop Testing Die Testlücke bei Embedded Firmware

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

embeff GmbH

Der Test von Embedded Firmware ist zu kompliziert. Enorme Ressourcen werden für einen Systemtest aufgewendet, der zu wenige Fehler entdeckt. Dieses Problem kann mit Open-Loop-Tests gelöst werden.

Für Embedded Firmware ist der korrekte Umgang mit Mikrocontroller Peripherie (GPIO, CAN und mehr) essentiell. Dazu werden Treiber programmiert. Open-Loop-Tests können diese Treiber im Detail prüfen.

Open Loop ist ein Begriff aus der Regelungstechnik. In der Regelungstechnik geht es darum, über eine Beeinflussung eines Prozesses einen gewünschten Zustand am Ausgang herzustellen.

Closed-Loop-Regler messen kontinuierlich den Ausgang. Aus der Abweichung zwischen Soll- und Ist-Zustand wird ein Stelleingriff berechnet. Open Loop Regler steuern „blind“ einen Prozess, sie sind also nicht vom aktuellen Systemzustand abhängig. Das vereinfacht die Handhabung.

Embedded Systeme werden üblicherweise in einer Art getestet, die mit Closed-Loop-Reglern vergleichbar ist. Mit Open-Loop-Prinzipien kann die Komplexität im Testen dramatisch reduziert werden. Tests werden kompakt und verständlich.

Der Artikel wird zunächst den Stand der Technik im Testen vom Embedded Systemen beschreiben. Dann wird der Zusammenhang mit Closed Loop Systemen verdeutlicht. Anschließend wird mit Open-Loop-Prinzipien eine alternative Herangehensweise entwickelt.

Stand der Technik beim Testing

Als Beispiel dient ein Embedded System zur Drehzahlregelung eines Motors. Dieses System:

• basiert auf einem Mikrocontroller

• erhält über CAN-Nachrichten mit einer Soll-Drehzahl

• steuert per PWM eine Leistungselektronik zur Versorgung des externen Motors

• erhält über einen Drehgeber Impulse, aus der die Ist-Drehzahl errechnet werden kann, enthält einen internen Temperatursensor, um das System bei Überhitzung abzuschalten

Eine typische Anforderung könnte so formuliert sein:

• Wenn per CAN-Nachricht eine Drehzahl von 100/min übersendet wird, dann muss das System innerhalb von 2 Sekunden eine Drehzahl zwischen 98 und 102 U/min erreicht haben.

Soll diese Anforderung automatisch geprüft werden, muss ein Teststand aufgebaut werden. Die folgende Grafik zeigt einen solchen Teststand in seiner Struktur.

Das Testsystem muss für das Embedded System (System Under Test, SUT) ein Drehgeber-Signal simulieren.

Dazu muss basierend auf den +/- Signalen ein Motor elektrotechnisch nachgebildet werden. Die Eingänge des SUT sind damit abhängig von den Ausgängen des SUT. Diese geschlossene Schleife ist das Merkmal jedes Closed Loop Systems. Der Test wird basierend auf dem Ausgang als „Pass“ oder „Fail“ bewertet.

Der gewünschte Systemtest kann so automatisiert durchgeführt werden. Es ergeben sich jedoch eine Reihe von Problemen:

• 1. Tritt ein Fehler auf, kann die Ursache nicht zugeordnet werden. Mögliche Ursachen sind die Embedded Firmware, die Hardware (Platine) oder auch eine fehlerhafte Simulation im Testsystem.

• 2. Der Test überprüft das System für eine einzelne Bedingung. Es lässt sich beispielsweise nicht zeigen, dass die PWM-Erzeugung auf dem Mikrocontroller für alle möglichen Tastgrade korrekt arbeitet.

• 3. Der interne Temperatursensor ist nicht Teil der Testschnittstelle. Um die Temperaturabschaltung zu prüfen, kann der Teststand durch eine Heizung ergänzt werden. Allerdings kann auch dann nicht geprüft werden, 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 all diese 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 dieser internen Zustände durch eine "passende" Auswahl von Eingangsgrößen herzustellen.

Open Loop Testing

Bei Open-Loop-Test entfällt die Notwendigkeit, interne Zustandsgrößen prüfen. Im Systemtest war die gesamte Leiterplatte Ziel des Tests. Im vorgeschlagenen Open Loop Test wird ausschließlich der Mikrocontroller betrachtet.

Im Test soll die korrekte Funktionalität des PWM-Treibers geprüft werden (Abbildung 4). Das Testsystem steuert über eine Schnittstelle den PWM-Treiber mit einem Tastgrad an. Der Mikrocontroller gibt an einem Pin ein PWM-Signal aus. Der Test prüft jetzt, ob das Signal den gewünschten Tastgrad aufweist und führt eine Bewertung in „Pass“ oder „Fail“ durch.

Die Open-Loop-Struktur ist direkt ersichtlich: Es gibt keine Rückkopplung der Ausgänge auf die Eingänge des Mikrocontrollers.

In gleicher Weise lassen sich auch Eingänge des Mikrocontrollers testen (Abbildung 5). Dabei wird vom Testsystem ein elektrisches Signal erzeugt. Das Signal bildet die Impulse des Drehgebers nach. Im Anschluss kann über eine Schnittstelle aus dem Mikrocontroller die gemessene Drehzahl ausgelesen werden.

Auf dem Mikrocontroller läuft eine spezielle Firmware, die unverändert alle zu testenden Teilkomponenten enthält. Diese Teilkomponenten werden über eine Schnittstelle nach außen steuer- und auslesbar gemacht. Der gezeigte Test kann damit als sogenannter Hardware-Software-Integrationstest verstanden werden.

Diese Struktur hat eine Reihe von Vorteilen:

• 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, kann direkt die Ursache zugeordnet werden.

• 2. Jede Komponente kann systematisch für alle denkbaren Eingangswerte getestet werden.

• 3. Es können interne Fehlerzustände getestet werden, die in einem Systemtest nicht zugreifbar sind. Beispielsweise können die Treiber auf ein Verhalten bei Überlastung des CAN-Busses, oder eine vorübergehende elektrische Störung der I2C-Kommunikation geprüft werden.

• 4. Tests werden auf Pin-Ebene des Mikrocontrollers durchgeführt. Diese Ebene ist für eine Vielzahl verfügbarer Peripherien standardisiert. Das Testsystem kann für verschiedene Prüflinge wiederverwendet werden.

Fazit

Systemtests müssen neben der Testanregung immer eine Simulation der Umgebung zur Verfügung stellen. Diese Notwendigkeit erzwingt eine Closed-Loop-Struktur.

Bei Open-Loop-Tests besteht diese Notwendigkeit nicht, da sie als Integrationstest ausgelegt werden können. Die Testanregung gibt hier ein Pin-Verhalten vor oder ruft Funktionen im Code auf.

Das gezeigte Open-Loop-Prinzip ermöglicht das Formulieren von HW-SW-Integrationstests. Diese Tests können Teilkomponenten des Systems unter allen vorstellbaren Bedingungen prüfen. Eine solche Prüfung ist mit Systemtests nicht wirtschaftlich möglich. Open Loop Testing kann einen Beitrag leisten, die oft vorgeschlagene Testpyramide bei Embedded Systemen sinnvoll umzusetzen.

(ID:48525889)