Embedded-Systeme steuern heute eine enorme Bandbreite an Anwendungen, von Fahrzeugsteuergeräten über Industrieanlagen bis hin zu Medizingeräten und IoT-Produkten. Entsprechend gut müssen sie vor ihrem Einsatz geprüft werden. Welche Techniken helfen gemäß dem Stand der Technik zu testen, wenn man im sicherheitskritischen Umfeld arbeitet? Bei Zeitdruck oder Kostendruck suchen manche Ingenieure Hilfe von KI-Agenten beim Test. Wie kann man und darf man vorgehen, wenn man auf sich auf diese Weise Unterstützung holt? Wie stellt man Qualität sicher?
Besondere Herausforderungen beim Embedded-Software-Testing
Im Vergleich zu klassischer IT-Software birgt Embedded-Software einige zusätzliche Herausforderungen:
Begrenzte Ressourcen
Embedded-Systeme arbeiten oft mit sehr begrenztem Speicher, niedriger CPU-Leistung und strikten Anforderungen an den Energieverbrauch. Tests müssen prüfen, ob die Software unter diesen Rahmenbedingungen unter allen Umständen läuft und auch diese „Umstände“ ermitteln.
Hardwareabhängigkeit
Die Software interagiert mit Sensoren, Aktoren und spezifischer Hardware. Fehler entstehen gegebenenfalls erst im Zusammenspiel mit der Zielplattform. Es ist daher unter anderem wichtig, mit Sensoren zu testen, die an der Fertigungstoleranzgrenze liegen.
Echtzeitanforderungen
Viele Systeme müssen innerhalb definierter Zeitgrenzen reagieren – etwa im Automotive-Umfeld oder in der Industrieautomatisierung. Ein Test der Reaktionszeiten unter verschiedenen Lastsituationen kann nicht garantieren, dass der Worst Case abgedeckt wurde. Die Testläufe sollten daher mit einer Analyse ergänzt werden.
Nebenläufigkeit und Interrupts
Interrupts und die Verwendung eines RTOS erhöhen die Komplexität des Tests von Echtzeitanforderungen erheblich und erschweren die Fehlersuche.
Teure Testumgebungen
Zielhardware oder spezielle Testsysteme stehen manchmal nur begrenzt zur Verfügung oder sind kostspielig, wie etwa das in Bild 1 gezeigte System. Eine Test-Impact-Analyse kann helfen, Tests zu identifizieren, die fast ohne Risiko ausgelassen werden können.
Testen beginnt nicht erst am Ende eines Projekts
Man kann Software am Ende eines Entwicklungsprozesses nicht „gesundtesten“, wenn es schon am Anfang Probleme gibt. Verschiedene Verifikationsmethoden im gesamten Software-Lebenszyklus helfen, Fehler früh zu finden oder gänzlich zu vermeiden.
Dazu gehören insbesondere:
Review und Verbesserung der Anforderungen – lässt sich heutzutage schnell und kostengünstig mit KI-Unterstützung durchführen
Review des Software-Designs und Hardware-Designs bezüglich Testbarkeit
Statische Code-Analyse zur frühzeitigen Erkennung von Fehlern
Unit-Tests zur Überprüfung einzelner Funktionen oder Module
Integrationstests zur Validierung des Zusammenspiels von Komponenten
Systemtests, die das Verhalten des Gesamtsystems überprüfen
Analytische Verfahren zur Einhaltung von Echtzeitanforderungen oder Nicht-Existenz von Data Races
Jede dieser Teststufen deckt unterschiedliche Fehlerklassen auf. Für Systeme mit hohen Integritätsanforderungen ist keine Teststufe verzichtbar.
Black-Box-Tests und strukturelle Testmethoden
Ein wichtiger Bestandteil moderner Teststrategien sind Black-Box-Testmethoden. Dabei wird das Verhalten eines Systems ausschließlich über seine Schnittstellen geprüft – unabhängig von der internen Implementierung. Diese Methode ist besonders geeignet, um Anforderungen systematisch zu validieren.
Darüber hinaus spielt die Erfassung der strukturellen Testabdeckung insbesondere bei Unit-Tests eine wichtige Rolle. Die erzielte Abdeckung bewertet die Adäquatheit von Tests. Leider bedeutet 100 Prozent Erreichungsgrad aber noch lange nicht, dass man gute Arbeit gemacht hat. Entsprechend fordert unter anderem die ISO 29119 auch die Dokumentation von sogenannten Test Coverage Items. Die Erfassung der strukturellen Testabdeckung bei Systemtests kann Testlücken identifizieren, bereitet aber bei speicherbegrenzten Embedded-Systemen meist Schwierigkeiten.
Spielarten von Systemtests in Embedded-Systemen
Embedded-Systeme müssen oft unter extremen Bedingungen zuverlässig funktionieren. Deshalb sind spezialisierte Testmethoden erforderlich. Typische Testarten sind unter anderem:
Stress Tests: Verhalten unter Überlast oder bei Ressourcen-Engpässen
Load Tests: Stabilität und Performanz unter verschiedenen Lastsituationen
Volume Tests: Verarbeitung großer Datenmengen
Resource Tests: Nutzung von Speicher, CPU oder Bandbreite
Echtzeitanalyse: Worst-Case Execution Time (WCET)
Wenn ein System harte Echtzeitbedingungen zu erfüllen hat, kommt die Analyse der Worst-Case Execution Time (WCET) ins Spiel. Die WCET-Analyse bestimmt die maximale Ausführungszeit eines nicht unterbrechbaren Programmblocks. Sie ist insbesondere in sicherheitskritischen Bereichen von großer Bedeutung und kann unter bestimmten Umständen einen mathematischen Beweis der Erfüllung der Echtzeitanforderungen liefern.
Schedulability-Analyse für Echtzeitbetriebssysteme
Wenn mehrere Tasks parallel auf einem Echtzeitbetriebssystem laufen, muss sichergestellt werden, dass alle Aufgaben rechtzeitig ausgeführt werden können. Die Schedulability-Analyse, illustriert in Bild 2, untersucht genau diese Frage. Sie prüft, ob das geplante Scheduling mit den vorhandenen Ressourcen und Prioritäten unter allen Umständen realisierbar ist – man spricht von „Planbarkeit“.
Der Beweis so einer Planbarkeit ist nicht trivial und wird für ein Modell des Systems durchgeführt. Ohne bestimmte Randbedingungen, wie Schwellen für maximale Interrupt-Raten oder maximale Längen von Interrupt-Serviceroutinen, kann der Beweis nicht gelingen.
Race Conditions und Deadlocks zuverlässig erkennen
Besonders schwierig in Tests zu finden sind Fehler durch Nebenläufigkeit, etwa Race Conditions oder Deadlocks. Diese Fehler treten häufig nur unter sehr spezifischen Timing-Bedingungen auf und lassen sich schwer reproduzieren.
Moderne Analysewerkzeuge und spezielle Testverfahren ermöglichen jedoch ein systematisches Erkennen solcher Probleme, siehe Bild 3. Unter gewissen Randbedingungen gelingt auch hier ein Beweis, dass Software frei von Deadlocks oder Race Conditions ist.
Testaufwand von Consumer bis sicherheitskritisch skalieren
Nicht jedes Embedded-System benötigt denselben Verifikationsaufwand. Ein Consumer-IoT-Gerät wird anders getestet als ein sicherheitskritisches Steuergerät.
Normen für sicherheitsrelevante Software definieren deshalb unterschiedliche Integritätsstufen und entsprechende Anforderungen an den Umfang der Tests. Diese Normen können auch für Software mit hohen Integritätsanforderungen, aber ohne sicherheitskritische Funktion als Richtschnur genommen werden. Dann ist es eine Frage der Haftung, den Testaufwand so zu skalieren, dass er zur Kritikalität des Systems passt.
Praxiswissen aus realen Projekten
Viele Methoden des Embedded-Software-Testing lassen sich erst dann wirklich gut verstehen, wenn sie anhand konkreter Beispiele erklärt werden. In praxisorientierten Trainings lernen Entwicklerinnen, Tester und technische Projektleiter unter anderem,
wie Unit- und Systemtests systematisch entworfen werden,
welche Werkzeuge für welche Art von Software für die statische Code-Analyse geeignet sind,
wie Integrationstests strukturiert aufgebaut werden,
wie sich Erfordernisse aus Normen wie der ISO 26262 umsetzen lassen.
Praktische Übungen helfen dabei, Testmethoden direkt auf reale Fragestellungen aus dem eigenen Projektumfeld anzuwenden.
Fazit: Qualität entsteht nicht zufällig
Mit zunehmender Softwarekomplexität wird auch Embedded-Software-Testing komplexer und zu einer Schlüsselkompetenz moderner Entwicklungsteams.
Erfolgreiche Projekte zeichnen sich durch eine systematische Teststrategie aus, die:
den gesamten Entwicklungsprozess begleitet,
spezialisierte Methoden für Echtzeit- und Ressourcentests nutzt,
Testautomatisierung konsequent einsetzt
und den Testaufwand an die Kritikalität des Produkts anpasst.
Wer diese Prinzipien früh in seine Entwicklungsprozesse integriert, reduziert das Projektrisiko und erhöht die Zuverlässigkeit seiner Systeme. Das nötige Fachwissen vorausgesetzt, kann die Teststrategie auch KI-Unterstützung umfassen und die Testkosten reduzieren.
