Wenn Software direkt mit Sensoren und Aktoren zusammenspielt, wird Testen zur Gratwanderung. Echtzeit, knappe Ressourcen und die Launen der Elektronik setzen enge Grenzen. Simulation hilft, stößt in sicherheitskritischen Kontexten jedoch schnell an Grenzen. Die zentrale Hürde ist Beobachtbarkeit: Klassische Instrumentierung bläht Code auf und verfälscht Zeiten. Ein anderer Weg ist Embedded Trace: Die CPU sendet Ereignisse hardwareseitig nach außen, ein FPGA erfasst und wertet sie live aus. So werden Code-Coverage und Timing im Integrationstest auf echter Hardware messbar.
In dieser Episode spreche ich mit Alexander Weiss und Martin Heininger über Embedded Testing. Wir plaudern über Echtzeit-Probleme, knappe Ressourcen und die Abhängigkeit von Elektronik. Simulation hilft, stößt aber im Safety-Bereich schnell an Grenzen. Ein Problem ist die Beobachtbarkeit: Klassische Instrumentierung bläht Code auf und verändert Laufzeiten. Ihr Gegenentwurf: Embedded Trace. Die CPU funkt Ereignisse hardwareseitig nach außen, ein FPGA wertet live aus. So kann man Code-Coverage im Integrationstest auf echter Hardware messen.
"Ich bin ein totaler Fan von Embedded Trace. Das beseitigt alle Probleme, die man mit der Instrumentierung hat, weil an der CPU eine Hardware ist, die nach außen funkt, was die CPU macht, ohne dass die Applikation das mitbekommt." - Alexander Weiss, Martin Heininger
Alexander Weiss ist seit jeher in der Embedded Welt zu Hause: während seines Elektrotechnikstudiums an der TU München, seiner Promotion an der TU Dresden, als Gründer der Accemic Technologies GmbH, als SW/HW/FPGA Entwickler und als Autor.
Martin Heininger studierte Elektrotechnik an der Fachhochschule in Augsburg, nach einer Ausbildung zum Radio- und Fernsehtechniker. Danach hat er mehr als 15 Jahre im Schwerpunkt in Luftfahrtprojekten Praxis Know-How gesammelt, im Bereich des Testing, der Entwicklungsprozessdokumentation und den Zulassungsverfahren. Seit mehr als 10 Jahren gibt er diese Methoden und das Prozesswissen für die Entwicklung von sicherheitskritischen Embedded Systemen an seine Kunden in Hands-On Beratungsprojekten weiter.
Wer im Bereich Softwaretest arbeitet, denkt oft an Web-Anwendungen, Datenbanken oder Apps. Doch Embedded Systeme sind eine Kategorie für sich. Hier laufen Programme nicht auf virtuellen Servern, sondern auf echter Hardware mit begrenzten Ressourcen. Das bringt ganz eigene Herausforderungen mit sich.
Alexander Weiß und Martin Heiniger haben im Podcast erklärt, warum das Testen von Embedded-Systemen anders abläuft als in klassischen IT-Projekten. Sie sagen: Im Embedded-Bereich braucht man eine Mischung aus Elektrotechnik und Informatik, denn die Software interagiert direkt mit Schaltkreisen und Sensoren.
Anders als in IT-Systemen mit dicken Datenbanken zählt hier jeder Speicherplatz. Ein typischer Mikrocontroller hat wenig Platz, und auch die Rechenzeit ist beschränkt. Echtzeit-Anforderungen bestimmen den Takt. Bei Embedded-Anwendungen bedeutet das: Jede Verzögerung kann das ganze System beeinflussen. Tests dürfen den Ablauf nicht verändern. Wer testet, muss also das System im Inneren gut verstehen – von den CPU-Registries über den Speicher bis hin zu Bussystemen wie Ethernet oder CAN.
Viele Entwickler setzen auf Simulationen. Doch wie Martin Heiniger erklärt, bleibt das immer ein Kompromiss. "Kannst du mir beweisen, dass die Simulation die Wahrheit ist?" fragt er kritisch. Bei sicherheitskritischen Systemen geht es oft nicht nur um das Programm, sondern darum, wie Hard- und Software zusammenarbeiten. Die ultimative Wahrheit liegt meistens in der realen Hardware.
Embedded Entwickler kommen häufig aus der Elektrotechnik. Viele Informatiker haben wenig Lust auf Lötpunkte oder Schaltpläne. Trotzdem braucht es beide Blickwinkel. Alexander Weiß betont, dass ein tiefes Verständnis für die Architektur jedes Geräts zählt. Ohne dieses technische Wissen bleiben viele Fehler unentdeckt.
Im klassischen IT-Umfeld sind Volumentests mit riesigen Datenmengen typisch. Im Embedded-Bereich dagegen handelt es sich oft um Stresstests für kurze Kommunikationswege. Ein weiterer Unterschied: Die Messung der Code Coverage (Testabdeckung). Im Embedded und vor allem im Safety-Bereich gilt oft: Jede Codezeile muss getestet sein, weil ein Fehler katastrophale Folgen haben kann. Das ist im IT-Bereich mit seinen Millionen Zeilen Code und Datenbanken kaum möglich oder sinnvoll.
Alexander bringt ein weiteres Thema auf: die Beobachtbarkeit. Im IT-Bereich lassen sich Systeme leicht instrumentieren, um Code zu überwachen. Bei Embedded-Geräten ist das schwieriger. Jede zusätzliche Messanweisung kann die Performance ruinieren oder das Programm in einen anderen Zustand bringen.
Die Experten erklären, dass herkömmliche Instrumentierung bald an ihre Grenzen stößt. Hier kommt Embedded Trace ins Spiel. Das ist eine Hardware am Mikrocontroller, die ausliest, was der Prozessor macht, ohne das eigentliche System zu beeinflussen. Das ist wie ein Auge, das zuschaut, ohne zu stören.
So lässt sich zum Beispiel beim Integrationstest live beobachten, welche Befehle wie oft ausgeführt werden – und das bei voller Geschwindigkeit und ohne Speicherprobleme. Das gab es früher nur für kurze Ausschnitte, heute können ganze Tagesabläufe analysiert werden, wenn die Hardware stimmt.
Besonders in der Luftfahrt und anderen sensiblen Bereichen wird das Thema Testabdeckung gesetzlich reguliert. Die Experten würden sich wünschen, dass Integrationstests an Bedeutung gewinnen, weil sie am echten System stattfinden. Unit Tests sollen spezifisch dort eingesetzt werden, wo Integrationstests nicht alle Fälle abdecken. So kann der Nachweis der Softwarequalität verbessert werden, auch für Zulassungen etwa bei Flugzeugen oder Autos.
Neue Hardware-Möglichkeiten könnten den Bereich revolutionieren – weniger arbeitsintensive Unit-Tests, mehr aussagekräftige Integrationsprüfungen. Aber die Normen müssen sich mitentwickeln, damit Technik und Regulierung zusammenpassen.
Wer Embedded Systeme testet, braucht technisches Wissen, Geduld und das richtige Werkzeug. Neue Hardware-Lösungen bieten spannende Möglichkeiten, um echte Abläufe zu messen – ohne Kompromisse bei Sicherheit oder Performance. Die Zukunft liegt in cleverer Integration von Test und Technik, damit nicht nur die Software, sondern auch das System als Ganzes sicher funktioniert.