Knowledge Base

Hardware in the Loop for Everybody

Die meisten Embedded Systeme werden zu spät oder nur unzureichend getestet. Fakt ist: Je später Fehler entdeckt werden, desto teurer ist die Behebung – die Kosten steigen exponentiell mit Fortschreiten des Projekts an. Im Extremfall einer Rückrufaktion für bereits gelieferte Produkte kann das zu Kosten in Millionenhöhe führen. Es muss also Ziel sein, deutlich früher zu testen – im Idealfall bereits durch Hardware in the Loop Tests während der Implementierung.

Kosten der Fehlerbehebung

Warum ist es schwierig Embedded Systeme zu testen?

Es gibt vielfältige Gründe, warum Embedded Systeme so schwer zu testen sind: Im Gegensatz zu „normaler“ Desktop Software haben Embedded Systeme Schnittstellen zu physikalischen Systemen und nicht nur zu anderen Softwaresystemen. Die Software, welche diese Systeme kontrolliert, ist hochgradig nebenläufig und Zustands-behaftet. Mit den üblichen Testverfahren wie z.B. sequenziellen Unit-Tests kann man solche Systeme meist nur schlecht testen.

Auf Simulation basierende Software in the Loop- (SIL) oder Hardware in the Loop-Tests (HIL) sind grundsätzlich gut geeignet für solche Tests. Die gängigen Hardwareplattformen und Softwaretools sind aber häufig zu teuer, um sie bereits während der Entwicklung an jedem Arbeitsplatz einzusetzen. Außerdem ist für die Entwicklung der Tests anderes Methoden- und Tool-Wissen nötig als für die Entwicklung der Applikation. In den meisten Fällen werden diese Methoden daher erst sehr viel später in der Testabteilung angewendet.

Der Entwickler kann so kaum strukturiert testen, sodass die entstehenden Embedded Systeme während der Entwicklung häufig nicht getestet, sondern eher „ausprobiert“ werden.

Wie kann man während der Entwicklung bereits Hardware in the Loop testen?

Um dennoch entwicklungsbegleitend testen zu können, sollten folgende Voraussetzungen erfüllt sein:

  • Der Entwickler sollte die Methoden und Tools bereits kennen, oder sich schnell einarbeiten können
  • Hardwareplattformen und Softwaretools müssen günstig sein, wenn sie an jedem Arbeitsplatz eingesetzt werden sollen
  • Methoden und Tools sollten die Entwicklung von Tests für Embedded Systeme auf unterschiedlichen Ebenen unterstützen (Komponenten-, Integrations- und Systemtests)
Strukturelle Sicht des Testsystems

Das Open Source-Modellierungswerkzeug Eclipse eTrice ermöglicht den Aufbau einer kostengünstigen und dennoch mächtigen Testplattform: Im Modell können Komponenten für Stimulation, Monitoring und Simulation entwickelt und generiert werden. Mit dem eTrice Add-on PROTOS-CaGe können Komponenten mit Test-Cases für das System beschrieben und vollständig generiert werden. Die kombinatorische Test-Case-Generierung ermöglicht eine sehr schnelle Entwicklung von Test-Cases mit hoher Abdeckung.

Alle Komponenten zusammen bilden eine portable, echtzeitfähige „Test Harness“ für die Applikation. Diesen kann man als SIL-Test (z.B. auf dem Entwicklungsrechner) oder als HIL-Test auf kostengünstiger Hardware (z.B. PROTOS miniHIL) ausführen. Die vollautomatische Durchführung der Tests wird durch einen Jenkins Continuous Integration Server (ebenfalls Open Source) übernommen.

Test First für Embedded Systeme!

Durch die gewählte Kombination aus Standard-Hardware und größtenteils frei verfügbaren Open-Source-Tools kann man eine modellgetriebene Software in the Loop- oder Hardware in the Loop-Testlösung aufbauen. Diese ermöglicht es bereits während der Applikationsentwicklung Embedded Systeme mit hoher Abdeckung automatisiert zu testen.

Haben Sie noch Fragen? Wollen Sie mit uns über Hardware in the Loop for Everybody diskutieren?

Mit dem Senden stimmen Sie unserer Datenschutzvereinbarung zu.