Embedded Software Testing bezeichnet das Testen von Software, die eng mit dedizierter Hardware zusammenläuft und eine spezifische Aufgabe in einem übergeordneten System erfüllt. Tests erfolgen auf mehreren Stufen: Unit-Tests, Integrationstests und Systemtests, oft auf echter Zielhardware. Sicherheitskritische Systeme wie ABS unterliegen dabei normativen Standards, etwa MISRA für Codequalität.
Das Wichtigste in Kürze
- Embedded Software lässt sich nicht losgelöst von der Hardware testen: Systemtests erfordern reale Ziel-Hardware, weil Timing und Busprotokolle im Simulator nicht vollständig abgebildet werden können.
- Funktional sichere Embedded-Systeme unterliegen normativen Vorgaben wie dem V-Modell, das Spezifikation und Testnachweis auf jeder Ebene zwingend fordert.
- Statische Code-Analyse gegen MISRA-Regeln ist im sicherheitskritischen Embedded-Umfeld ein etablierter Standard, der eine ganze Klasse hardwarenaher Fehler in C und C++ präventiv ausschließt.
- Continuous Integration mit automatisierten Tests auf echter Zielhardware ist in professionellen Embedded-Projekten bereits Standard, weil parallele Teams sonst keine verlässliche Integrationsbasis haben.
- Wartbarkeit und Anpassbarkeit werden in Embedded-Projekten häufig zu spät mitgedacht, was bei mehreren Gerätevarianten schnell in technische Schuld und Zeitdruck mündet.
Was ein Embedded System ausmacht
Ein Embedded System ist Software, die in ein größeres System eingebettet ist und dort eine ganz spezielle Aufgabe erfüllt. Diese eine Aufgabe erledigt es in der Regel sehr gut.
Das Spektrum ist breit. Ein ABS-System im Auto ist ein eigenes Embedded System, eingebettet in das komplexe Gesamtsystem Auto. Auch die Kaffeemaschine, die guten Kaffee macht, ist ein Embedded System: mit nur einem Nutzer, der sie startet, aber mit einer klar umrissenen Funktion.
Die spezifische Aufgabe hat eine angenehme Nebenwirkung für die Entwicklung. Die Anforderungen ändern sich seltener als in der Webwelt, weil die Funktion von Anfang an feststeht. Erst wenn das Gerät beim Benutzer landet, fließt über Customer-Experience-Feedback neue Funktionalität nach, meist oben in der Applikationsebene.
Warum Embedded-Testen ohne Hardware nicht auskommt
Testen im Embedded-Umfeld läuft eng mit der Hardware zusammen, deshalb musst du am Ende auch mit Hardware testen und in einem Systemkontext. Genau hier liegt der größte Unterschied zu reiner Anwendungssoftware.
Das Gerät muss in seinem Systemkontext geprüft werden, und der bringt harte Randbedingungen mit. Beim ABS-System ist das Timing kritisch. Die Signale müssen exakt getaktet auf den Bus gebracht werden, und parallel willst du komplexe Szenarien des Gesamtsystems simulieren.
Diese Hardwareabhängigkeit ist die Konstante, die fast jede Entscheidung im Entwicklungs- und Testprozess prägt. Sie macht Embedded-Tests aufwendiger als Tests, die komplett auf simulierter Umgebung laufen können.
Qualität beginnt vor dem ersten Test, in der Architektur
Embedded-Qualität entscheidet sich nicht erst beim Testen, sondern bei der Architektur. Alexander Eisenhuth blickt zuerst durch die Architektenbrille, und dort werden die Weichen für Wartbarkeit, Performance und Anpassbarkeit gestellt.
Welche Ressourcen ein Gerät braucht, hängt davon ab, welche Qualitäten du priorisierst. Legst du den Fokus auf Wartbarkeit und brauchst keine Spitzenperformance, kannst du ein großzügig dimensioniertes Device wählen. Sind die Kosten der treibende Faktor, wird die Hardware klein, und dann sind plötzlich Kilobyte RAM die Grenze.
Der knappen Hardware begegnest du nicht mit verzweifeltem Code-Sparen, sondern mit Entscheidungen weiter oben: über die Programmiersprache, die Bibliotheken, das Konzept. Eine Schwäche, die sich rächt, ist fehlende Anpassbarkeit. Wer Gerätevarianten plant, aber kein Architekturkonzept dafür hat, rutscht schnell in technische Schuld. Dann drängt Time-to-Market, und die Architektur bleibt unter dem, was möglich wäre.
Wie der Code geprüft wird, bevor er läuft
Statische Code-Analyse fängt im Embedded-Bereich technische Fehler ab, die in hardwarenahen Sprachen wie C und C++ leicht passieren. Für funktional sichere Entwicklung gibt es eigene Standards.
Der Codier-Standard MISRA gibt Regeln vor, und statische Analyse prüft automatisiert, ob der Quellcode sie einhält. Damit ist ein großer Teil der typischen technischen Fehlerquellen abgedeckt, bevor überhaupt etwas auf der Hardware läuft.
Daneben gelten die Qualitätsmaße, die auch außerhalb von Embedded zählen: Komplexität des Quellcodes, zu große Module, Spaghetti-Code. Diese Analysen sind kein Embedded-Spezifikum, gehören aber fest dazu.
Welche Programmiersprachen heute im Einsatz sind
Die Basis ist klassisch C, dazu C++. Assembler ist in der Praxis kaum noch zu sehen.
Interessant für funktional sichere Systeme ist Rust, weil die Sprache Sicherheitsfeatures bereits eingebaut hat. Das passt gut zu den Anforderungen sicherheitskritischer Entwicklung.
Reif ist das Rust-Ökosystem für Embedded aber noch nicht. Das Tooling drumherum, etwa die Code-Analysen, muss erst mitwachsen, bevor Rust ein echter Standard wird. Die Richtung stimmt: Vieles deutet darauf hin, dass Rust die nächste Sprache in diesem Feld wird.
Die Teststufen im Embedded-Umfeld
Vom Aufbau her unterscheidet sich Embedded-Testen wenig vom klassischen Vorgehen. Es läuft über Unit-Tests, Integrationstests und Systemtests, nur dass die Hardware an mehreren Stellen mit reinkommt.
So sieht die Kette aus, wenn ein Produkt from scratch entsteht:
| Stufe | Worum es geht |
|---|---|
| Evaluation auf E-Val-Board | Kritische Dinge früh auf vorhandener CPU und Peripherie ausprobieren, Treiberschicht implementieren |
| Hardware- und Produkttests | EMV-Tests und Temperaturtests an der eigenen Elektronikentwicklung, Software muss noch nicht fertig sein |
| Unit-Tests | Einheiten vorab so testen, dass die Integration sauber zusammenpasst |
| Integrationstests | Komponenten-Integration ohne Hardware oder direkt auf der Hardware |
| Systemtests | Ende der Testkette, am realen Gesamtsystem |
Beim EMV-Test muss die Software noch nicht richtig funktionieren, es reicht, mit den Pins zu wackeln, um die Elektronikentwicklung nachzuweisen. Software und Hardware entstehen parallel, bis die Produktqualität für den Markt erreicht ist.
Die Aufteilung der Verantwortung ist klar. Systemtests übernehmen am Ende eigene Teams, während Unit-Tests und Regressionstests im Entwicklungsteam selbst geschrieben werden.
Sicherheitskritische Systeme bringen ihren eigenen Unterbau mit
Bei funktional sicheren Systemen arbeitest du in einem regulatorischen Umfeld, und die Normen geben viel vor. Ab einer bestimmten Sicherheitsstufe musst du nach diesen Vorgaben entwickeln.
Das V-Modell dient hier als Dokumentenmodell mit einer Spezifikationsseite und einer Testseite. Es wird sehr formal darauf geschaut, dass die richtigen Tests vorhanden sind, und du musst sie nachweisen.
Diese Formalisierung hat eine Konsequenz für den Lebenszyklus. Läuft ein zertifiziertes System einmal stabil, willst du nicht mehr leichtfertig ran, weil jede Änderung den regulatorischen Aufwand erneut auslöst. Ein Hebel dagegen liegt in der Architektur: Du zertifizierst nur den Teil, der wirklich relevant ist, und trennst ihn sauber vom nicht zertifizierten Rest.
Agil entwickeln trotz Hardware-Abhängigkeit
Agile Entwicklung ist im Embedded-Umfeld angekommen. Teams entwickeln in kurzen Iterationen, auch wenn die Hardware-Layouts naturgemäß länger brauchen.
Ob das funktioniert, hängt am Mindset und an der Unternehmenskultur, weniger an der Trennung von Hardware und Software. Wer im Kopf nicht mitgeht, bleibt überall ein Problem. Hardware lässt sich durchaus agil entwickeln, nur sind ihre Zyklen langsamer gespannt.
Kommunikation entscheidet, ob die Reibung klein bleibt. Beim EMV-Test sind die Hardware-Leute Stakeholder, und gemeinsam überlegt man Abkürzungen, statt erst eine vollständige Testspezifikation zu schreiben. Statt Dokument zuerst klärt man früh, welche Termine wann fällig sind und wie man zusammenkommt.
CI-Pipelines und Updates over the air sind Standard
Continuous Integration ist im Embedded-Bereich Standard, inklusive automatisierter Tests auf der Hardware. Bei Codeänderungen wird kontinuierlich integriert, und in der Pipeline hängen echte Target-Systeme, die Integrations- und Systemtests fahren.
Das ist kein Luxus, sondern Notwendigkeit. Embedded-Software besteht oft aus vielen Modulen und Komponenten, an denen mehrere Teams arbeiten, und alles muss ständig zusammenpassen. Damit rückt auch Continuous Delivery ins Bild.
Software over the air ist vor allem im Automotive-Bereich ein großes Thema, etwa wenn Systeme sich automatisiert aktualisieren. Das Risiko fängst du über Redundanz ab: Schlägt ein Update fehl, gibt es ein Fallback auf die letzte funktionierende Version. Dass ein Update gar nicht mehr greift, deutet eher auf einen Hardwaredefekt hin, etwa kaputten Speicher.
Wo Embedded-Teams am häufigsten hängen bleiben
Time-to-Market ist eine der größten Reibungsflächen. Komplexere Entwicklung und der Druck der Markteinführung müssen zusammenspielen, und das gelingt nicht immer.
Embedded-spezifisch ist eine andere Falle: Hardware, deren Funktionalität laut Datenblatt spezifiziert ist, die dann aber nicht ganz so funktioniert. Das kann einem im Projekt richtig auf die Füße fallen.
Und wie überall sind es Anforderungen und Kommunikation. Sind die Anforderungen richtig verstanden, setzen wir das Richtige um. Darauf muss der Architekt durchgehend ein Auge haben.
Security wird professionell adressiert, andere Qualitäten oft nicht
Security ist im Embedded-Umfeld professionell verankert, getrieben auch durch regulatorische Vorgaben. Es gibt Richtlinien, die verhindern sollen, dass ein System angegriffen werden kann.
Der Grund ist die Vernetzung. Die meisten Embedded Systems sind in ein Gesamtsystem integriert und damit ein offenes Tor für Einbruchsszenarien. Darauf wird geschaut, zumindest bei den größeren Unternehmen.
Bei anderen Qualitätsmerkmalen tun sich Unternehmen schwerer. Last-Szenarien wie Nutzerzahlen stammen eher aus der Webwelt und werden bei Embedded von vornherein anders adressiert. Wartbarkeit und Anpassbarkeit werden dagegen oft gar nicht mitgedacht, und gerade das fällt später teuer aus, wenn Gerätevarianten dazukommen und das Architekturkonzept fehlt.
Wo du tiefer in die Embedded-Welt eintauchen kannst
Wer sich für Embedded-Entwicklung inspirieren lassen will, findet beim Embedded Software Engineering Congress (ESE) in Sindelfingen einen festen Anlaufpunkt. Er findet jährlich im Dezember statt.
Das Programm deckt auch Testthemen ab. Über eine ganze Woche gibt es Seminartage und viele Vorträge, die meist von Praktikern gehalten werden.
Der Charakter der Konferenz ist familiär. Trotz vieler Teilnehmer kommen die Leute eng zusammen, und genau das macht sie für den Einstieg in das Thema attraktiv.
