Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Heute tauchen wir mal in die Welt der Embedded Software Entwicklung ein. Wie testet man dort, wie stellt man Qualität sicher, welche Eigenheiten gibt es und was ist gerade im sicherheitskritischen Bereich zu beachten. Zu Gast dazu bei mir Alexander Eisenhuth, ein Experte für Embedded Systeme. Und jetzt viel Spaß bei der Folge.
Hallo Alex, schön, dass du da bist. Vielen Dank, Ritschi, für die Einladung. Ich freue mich, heute hier zu sein. Ja, ich bin auch ganz aufgeregt, weil wir ein ganz neues Thema hatten, mit dir jetzt, was wir im Podcast noch nie hatten. Und zwar geht es im großen Feld des ganzen Embedded System, Embedded Entwicklung, was ja schon ein bisschen eine andere Welt ist,
als jetzt, sage ich mal, eine olle Webseite oder so. Schon was ganz anderes. Und wir sind das Thema mal ein bisschen gestriffen bei der Folge mit Rainer Grimm, der über C++ erzählt hat und da auch so ein bisschen in die Richtung gegangen von so Steuerungen und sowas. Und da ist es schön, dass wir mit dir dann nochmal einen Experten haben, wo wir dann nochmal tiefer einsteigen können, was so die Qualitätssicherung, das Testen im Embedded Umfeld betrifft.
Ja, sehr schön. Ja, vielleicht starten wir da einfach gleich ganz, ganz, ganz wild mit rein. Wie blickst denn du auf Qualität, auf Testing aus dieser Embedded Brille? Da muss ich erst sagen, ich muss ja erstmal durch die Architektenbrille schauen. Ich bin ja Software-Architekt bei Embedded Systems, aber da spielen dann immer Qualitäten natürlich eine große Rolle. Das ist meine Aufgabe, Qualität, Software zu bringen und natürlich die finale
Qualität, dass es auch gescheit funktioniert. Und ja, das Testen ist immer eine besondere Herausforderung bei Embedded Systems, weil du läufst ja immer sehr eng mit der Hardware zusammen. Und deswegen musst du eigentlich auch mit Hardware testen und dann in einem Systemkontext. Weil ich mache nochmal einen Schritt zurück. Was ist ein Embedded System? Ein Embedded System ist ein System, oftmals in einem anderen System, aber das eine ganz
spezielle Aufgabe hat und die erfüllt es eigentlich relativ gut. Vielleicht nochmal so ein paar Worte dazu. Also so ein ABS-System im Auto ist ein eigenes Embedded System. Das Auto ist ein komplexes System, aber auch die Kaffeemaschine, die dir coolen Kaffee macht, ist ein Embedded System. Zwar nur mit dem User, sagen wir mal, der das startet, aber macht den Kaffee ja richtig gut. Und deswegen muss man beim Testen auch irgendwie das Gerät in seinen
Systemkontext reinbringen. Und das kannst du dir ja vorstellen, das ist manchmal eine ganz kleine Herausforderung. Zum Beispiel, wenn du an das ABS-System denkst, da ist ja das Timing und das auf dem Autobus bringen ein ganz kritisches Ding. Da musst du ganz exakt dieses Timing einhalten. Andererseits musst du auch noch das Szenario am besten simulieren von diesem ganzen komplexen System. Und da gibt es ja dann ganz unterschiedliche Einsätze, wie man da vorgeht.
Vielleicht gehen wir noch mal einen Schritt zurück, wenn du sagst, aus der Architektenrolle, da sind wir ja noch ein bisschen vorm Testen, bevor überhaupt was da ist. Also in der klassischen Softwareentwicklung gibt es ja dann auch so irgendwelche Reviews, da gibt es statische Analysen, die da gemacht werden. Gibt es da eine Spezialität bei Embedded Systems, wie da rangegangen wird oder wie Qualität schon auch mit reingedacht wird bei der Architektur?
Also die Qualität von Programmcode, da gibt es natürlich schon eigene Standards, sagen wir mal, wo man vielleicht auch Richtung funktional sichere Entwicklung geht. Da gibt es so Codier-Standards MISRA und da gibt es dann statische Code-Analysen, die dann schauen, dass der Quellcode die MISRA-Regeln einhält. Dann ist schon mal ein großer Set von so technischen möglichen Fehlern, die man ja in dieser Hardware-nahen Sprache eigentlich immer machen kann,
in C und C++ abgedeckt. Das ist vielleicht ein Aspekt, der bei Embedded und statischer Code-Analysen wichtig ist. Und das andere ist, denke ich, von anderen auch nicht. Da geht es dann um Qualitäten wie Komplexität des Quellcodes oder wie auch immer Spaghetti-Code, zu große Module, solche Sachen ist da auch. Ist denn da auch das Thema der ganzen – also für mich, in meiner Vorstellung hat ein Embedded-System immer sehr beschränkte Ressourcen auch,
die ich irgendwo betrachten muss. Also ich muss schauen, dass das Ganze auch irgendwie performant und klein ist, damit das alles da irgendwie auf dem Zeug auch laufen kann. Ist das so oder ist das ein Irrglaube von mir? Oh ja, das hängt von ganz schön vielen Dingen ab. Im Endeffekt hängt es davon ab, welche Qualitäten du brauchst. Das heißt, legst du auf Wartbarkeit ein großes Augenmerk und brauchst gar nicht so die Performance, dann hast du natürlich auch
ein großzügig dimensioniertes Device. Wenn das jetzt aber, sagen wir mal, weil die Kosten so extrem wichtig sind, muss es was ganz Kleines sein. Und da spielen vielleicht dann schon wieder diese Dinge rein, die du dir vielleicht so vorstellst, dass du nur Kilobytes von RAM hast und dann musst du den Code ganz klein schreiben. Aber dem begegnest du natürlich, indem du die Programmiersprache danach auswählst oder die Bibliotheken oder, oder, oder. So kann ich mir das vorstellen.
Weil du gerade sagst Programmiersprachen, was wird da heutzutage so verwendet in dem Umfeld? Naja, klassisch kommt es von C. Ich glaube, Assemble habe ich schon lange nicht mehr gesehen. C++, klar. Aber es öffnet sich ja auch gerade so eine neue Programmiersprache Rust, die vor allem Sicherheitsfeatures schon in der Sprache drin hat, was ganz interessant ist für das Umsetzen von funktional sicheren Systemen. Aber da ist so dieses Ökosystem noch nicht so ganz so weit mitgewachsen,
dass es schon ein großer Standard ist. Da gehört ja auch das ganze Tooling dazu, dass das da drauf passt. Du sagst jetzt Codeanalysen oder so. Aber das ist im Umbruch und ich denke, das wird ein Weg sein. Das kommt als nächste Sprache. Ja, das ist, ich glaube, auch beim Richtung, wenn man Richtung Testen schaut, ja ein total wesentlicher, viele von diesen Steuerungsgeräten oder einige sind natürlich auch in einem sehr kritischen Umfeld. Also du hast vorher das ABS
angesprochen. Ich meine, das sollte schon funktionieren, wenn es gebraucht wird. Wenn nicht, haben wir ein Problem. Welche Testarten oder welche Teststufen werden denn da verwendet? Wie wird denn da vorgegangen, um sowas auch wirklich abzusichern, dass es das macht, was es soll? Ja, bei den funktionalen Sicherheitssystemen hast du ja ein regularisches Umfeld. Also du musst, wenn du so eine gewisse Zielstufe hast, einfach noch bestimmten Normen entwickeln. Und
die geben dir da schon ziemlich viel vor. Also du musst quasi, du hast das V-Modell als Dokumentenmodell, das heißt, du hast ja die Spezifikationsseite und die Testseite. Und da wird schon sehr formal drauf geschaut, dass du die richtigen Tests hast und die musst du dann auch quasi nachweisen. Und sagen wir mal, ja, das ist dann erstmal so ein normativer, regularischer Unterbau, den du hast. Und wenn ich jetzt so entwickle und teste,
wie kann ich mir das vorstellen mit so einem Entwicklungsprozess? Das ist sehr hardware-nah. In meiner Welt kann ich da schon viel vorneweg simulieren, in irgendwelchen Simulatoren damit arbeiten oder auf irgendwelchen, oder brauche ich dann immer schon die Hardware? Und was ist, wenn sich die ändert? Wie ist denn so ein typischer Entwicklungsablauf da?
Also ganz typisch, wenn du, sagen wir mal, Produkte from the scratch machst, dann hast du ein Eval-Board, wo schon mal die CPU und ein bisschen Peripherie drumherum ist. Und da kannst du schon mal so für dich kritische Dinge einfach ausprobieren, ob das überhaupt funktioniert auf der Hardware. Und dann kannst du schon die Getreiber-Schicht,
das heißt die Schicht, die mit der Hardware spricht, implementieren. Und ich würde sagen, wenn dann das mal alles grün ist, was du brauchst, dann kannst du, dann musst du ja meistens dann auch eine Elektronikentwicklung haben. Das hast du ganz oft bei diesen Embedded-Systemen, dass du ja wirklich ein eigenes Mainboard, so in Anführungszeichen, um es zu verständlich zu machen, entwickelst, eine Hardware-Entwicklung hast und darauf läuft dann deine Software. Und da hast
du dann von der Produktentwicklung oft solche Dinge wie EMV-Tests. Da muss die Software noch nicht richtig funktionieren, aber du musst schon ein bisschen mit dem Pins wackeln. Da muss schon mal nachgewiesen werden, dass deine Elektronikentwicklung natürlich richtig ist. Und dann gibt es noch verschiedene andere Stufen, die Temperaturtests kommen dann zum Beispiel oder so. Und dann musst du parallel quasi dann auch die Software entwickeln, um dann eine Qualität des
Produkts zu haben, mit dem es dann an den Markt gehen kann. Und in dem Fall, glaube ich, unterscheidet sich Embedded-Entwicklung gar nicht so groß von den anderen. Du gehst mit Unit-Testing vor, weil du dir die Einheiten schon mal so grob vortestest, das heißt, wenn du sie zusammensteckst in die Integration, ist das schon mal richtig funktionieren. Und dann gehst du mit Integrations-Tests weiter, das heißt, du machst entweder Komponenten-Integration ohne Hardware oder dann eben
auf der Hardware Tests. Und zum Schluss dann die Systemtests. Also auch so ein Vorgehen. Und seit ich unterwegs bin als Software-Architekt, zumindest ist auch die agile Entwicklung in meiner Welt schon eingezogen. Das heißt, du hast dann Teams, die in kurzen Iterationen die Software entwickeln. Du hast zwar nicht Anforderungen, die sich ständig ändern, weil das ist so eine Eigenheit von so einem Embedded-System, dass es so eine ganz spezifische Aufgabe hat. Ändert sich eigentlich erstmal auch
nichts, erst wenn es dann zum User geht, zum Benutzer. Dann kann es natürlich schon sein, dass man erst das Feedback vom Benutzer einholt, die Customer Experience und da dann nochmal Dinge entwickelt. Das wäre dann alles oben in der Applikationsebene. Du hast jetzt gerade ein spannendes Thema angesprochen, nämlich Agilität in dem ganzen Umfeld. Also ich war selber mal in einem Projekt, das war schon Jahre her, da wurde auch Hardware entwickelt und die Software dazu.
Und da war das ganze Thema Kommunikation mit der Hardware-Seite immer sehr schwierig, weil das agile Zeug, das funktioniert bei uns eh alles nicht. Wir müssen hier mit Lieferanten und mit Dingen und das dauert alles bei uns. Also das war echt schwierig. Das ist jetzt nur meine Erfahrung. Aber wie ist denn das heute? Funktioniert das gut als Team? Wie wird da kommuniziert und sich da so die Bälle zugespielt, dass man so diesen agilen Gedanken auch mit
reinkriegt? Oder beschränkt sich das rein auf die Software-Seite, die die Hardware kann machen, was sie will? Ich sage mal so, das kommt natürlich viel auf das Mindset an. Das kannst du dir ja vorstellen. Wenn Leute einfach im Kopf nicht mitgehen wollen, dann hat man mit denen immer ein Problem. Aber ich denke, das ist erstmal auch unabhängig von der Hardware und Software. Das ist eigentlich auch eine Unternehmenskultur, wie man miteinander redet. Hardware kann durchaus
auch agil entwickelt werden. Aber natürlich gehen solche Layouts und solche Sachen, die dauern natürlich viel längerer Spannung. Du musst ja schon quasi eine Hardware haben, auf die du deine Software integrieren kannst. Ich habe es ja vorher so kurz angesprochen, was da die Stufen sind. Aber die sind natürlich auch darauf angewiesen. Zum Beispiel sind die ja eigentlich die Stakeholder im EMV-Test. Also kommuniziert man schon, wie man das jetzt
realisiert. Du musst nicht immer eine Software schreiben, um an einem CPU-Pin zu wackeln oder was auch immer. Da kann man sich dann auch überlegen, wie man Abkürzungen geht. Das ist ja dann eben die Agilität, dass man nicht ein Dokument schreibt mit Testspezifikationen, sondern dass man dann zusammen überlegt, wann sind die Termine, wann muss was fertig sein und vielleicht so zusammenkommt. Okay, also es funktioniert schon, dass man sich da auch gut
austauscht. Das ist ja, denke ich, auch ein sehr wichtiger Faktor, gerade wenn man in dem Kontext auch arbeitet. Jetzt sind wir in den letzten Jahren in der Softwareentwicklung. Das ist ja ganz einen großen Boost an Automatisierung auf allen Ebenen so erlebt. Also zum einen quasi die ganzen Tests automatisiert zu machen, damit wir mehr testen können, damit wir mehr Variationen
haben und diese Dinge. Und zum anderen auch, um die Prozesse, dieses ganze Deployment, diese Pipelines bis hin zu Continuous Integration und solche Sachen zu automatisieren, um das auch quasi schneller und besser zu machen. Wie ist das im Embedded-Umfeld? Ist das da auch ein Thema oder ist das so ein bisschen eher so handwerklich, manuell? Was sind denn da so die in den letzten Jahren? Ist das mitgegangen oder ist das da kein Thema? Doch, doch. Das ist also so eine CI-Pipeline.
Das ist Standard eigentlich von den Unternehmen, mit denen ich zusammengearbeitet habe. Und das heißt, da wird kontinuierlich, wenn du Codeänderungen hast, integriert und auch auf der Hardware automatisiert getestet. Also in der Regel sind da wirklich auch Target-Systeme dabei, die dann ganz spezifische Sachen testen, also so Integrations-Tests oder Systemtests. Und ich
glaube, das ist schon einfach Standard. Das ist ja ein Muss, wenn man mit verschiedenen Teams, also so eine Embedded-Software musst du dir vielleicht nicht nur vorstellen wie so fünf oder sechs Komponenten, kleinere oder Module. Je nachdem gibt es da die ganze Bandbreite dabei. Und du hast auch viele Teams, die zusammenarbeiten müssen. Und das muss ja eigentlich immer ständig alles passen, so dass man eigentlich ist das Continuous Delivery schon auch so ein bisschen
ein Thema. Software over the air ist glaube ich ein Automotive-Thema, dass du dann einfach bei Tesla auch wirklich ständeautomatisiert rausgeben kannst und die Systeme sich aktualisieren. Also ja, auch ein Riesenthema. Aber mit herausfordernden Rangbedingungen eben diese Hardwareabhängigkeiten. Ja. Also ich denke, gerade in solchen Fällen ist natürlich auch das Risiko dabei, das muss ja dann wieder funktionieren. Es ist ja blöd, wenn so ein Update irgendwie fehlschlägt
oder so was. Also das ist mir vielleicht bei meinem Wecker zu Hause oder irgendwas ist mir das egal, dann stecke ich den nochmal per USB an, dann kriege ich da ein Update und kann die Uhrzeit besser anzeigen oder was auch immer, wenn das mal over the air nicht funktioniert. Aber beim Auto ist es natürlich schon irgendwie, das muss dann laufen auch. Also es ist eine große Anforderung auch an den ganzen Prozess der Auslieferung von Updates und von der Sicherstellung der
Integrität des Ganzen. Na, da kann ich mich beruhigen. Da wird oft mit Redundanzen gearbeitet. Das heißt, wenn ein Update nicht funktioniert, dann gibt es ein Vorweg auf das Letzte, weil das hat ja schon mal gut funktioniert und sind ja keine kritischen Fehler jetzt, sagen wir mal, drin. Das muss ja gewährleistet werden. Und deswegen ist das, dass es nicht funktioniert, muss es eigentlich ein Hardware-Defekt sein, dass das Teil des Speichers
kaputt ist oder sowas. Ich selber fahre ein Auto, da ist wenig Software drin, das ist schon so alt. Das zeigt auch gar nichts mehr an. Aber das nächste wird da wahrscheinlich ein bisschen anders aussehen. Was meistens so ist, sind gerade so die größten Herausforderungen in der Entwicklung von Embedded Software, wenn du so drauf schaust, was du so mitbekommst. Wo strugglen denn die meisten … Meinst du jetzt, wo es Probleme gibt in der Entwicklung oder was meinst du?
Genau so. Also wo Teams sich oft aufreiben oder hängen bleiben oder Probleme haben. Ich glaube schon, dass es das Thema zum einen Time-to-Market auch ist, dass man seine Entwicklung, die ja schon komplexer ist und auch eine Markteinführung da ist, dass das zusammenspielt aus dieser Perspektive. Was vielleicht Embedded-spezifisch auch sein kann, ist, dass Funktionalitäten von der Hardware auf dem Datenblatt spezifiziert sind, aber dann doch
nicht ganz so richtig funktionieren. Das kann einem dann echt auf die Füße fallen. Da habe ich mal ein paar Geschichten mitgekriegt. Und ich denke auch, wie überall sind es die Anforderungen und die Kommunikation, sind die Anforderungen richtig verstanden, setzen wir das richtig um. Da muss man schon auch als Architekt immer ein Auge drauf haben.
Wenn du jetzt so auf deine Projekte schaust, auf deine Erfahrungen in der ganzen Software-Welt, in der klassischen oder in der anderen, da gibt es ja häufig auch so Test-Teams, die dann sich darum kümmern, nur die ganzen Tests zu machen, Performance-Spezialisten sind und so. Wie ist das im Embedded-Umfeld? Ist das etwas, was viel auch durch die Entwickler selbst passiert, oder gibt es da auch wirklich Test-Spezialisten, die sich nur um Test- und Qualitätssichernde
Maßnahmen auch kümmern? Ja, durchaus. Die Systemtests, die werden eigentlich von eigenen Teams dann zum Schluss gemacht. Also das ist ja das Ende der Testkette. Aber die Unit-Tests, die Regressionstests, die werden eigentlich im Team selber geschrieben. So erhebe ich das her. Okay, verstehe. Also eigentlich gibt es ja quasi auch die Spezialisten-Teams dafür. Und vielleicht noch auf die, wenn wir mal ein bisschen
hinschauen auf die ganzen nicht-funktionalen Themen. Also das eine ist ja, dass das Ding funktioniert, also das macht, was es machen soll. Aber jetzt gibt es ja da auch, sagen wir mal, gerade jetzt auch im aktuellen Zeitgeschehen natürlich das ganze Thema Security. Auch, ja, ich weiß nicht, im Embedded-Umfeld mit Usability wahrscheinlich eher weniger, aber oder vielleicht auch, sonst vielleicht noch Dings. Und Performance und Last,
so Themen, wie nimmst du das wahr in dem Umfeld? Wie wird denn das adressiert? Also Security, das wird schon sehr professionell adressiert. Da gibt es dann einfach so Richtlinien, die ja irgendwie, glaube ich, auch vom regulatorischen Feld vorgegeben werden, damit ein System nicht gekabert werden oder angegriffen werden kann. Weil auch jedes, nicht jedes, aber die meisten sind ja irgendwo im Gesamtsystem integriert und es ist ja natürlich
ein offenes Tor. Und da gibt es ja Einbruchsszenarien und da wird schon drauf geschaut, auf jeden Fall. Ich kann natürlich nur dafür sprechen, mit denen ich zusammenarbeite, sind ja eigentlich eher die größeren Unternehmen. Bei den anderen Qualitäten, das erlebe ich so,
dass es sich die Unternehmen schwer tun, das richtig zu formulieren. Ich glaube, zu Last-Szenarien ist es vielleicht noch was aus der Webwelt, wenn man Anzahl der User oder irgendwie sowas vorgibt, ist beim Embedded System irgendwie anders und wird von Anfang an anders adressiert. Aber die Wartbarkeit, die wird eigentlich gar nicht so oder die Anpassbarkeit,
die wird manchmal gar nicht so mit mitbedacht. Und das macht es natürlich dann schwer, wenn du zum Beispiel Gerätevarianten hast und du hast dir davor nicht von der Architektur ein Konzept dafür überlegt, wie ich Gerätevarianten habe. Und dann komme ich halt schnell in eine technische Schuld und dann kommt wieder der Time-to-Market und dann musst du wieder nicht die Architektur
so haben, wie du sie gerne hättest. Und dann wird es immer ein bisschen schwierig und da muss einfach dann auch wieder Zeit eingerechnet werden, um diese Qualität dann wieder reinzukriegen. Ja, ja. Ja, und ich glaube, eine Herausforderung ist ja auch in dem Umfeld, dass ja gerade bei so Steuerungssoftware oder sowas, wenn das mal läuft und wenn das mal zertifiziert ist und wenn das mal da ist, dann ist es ja auch, dann will man da ja auch jetzt nicht mehr so schnell ran an das
Ding. Also das muss ja dann auch wirklich eine Zeit lang auch wirklich stabil laufen, weil man jede Änderung wieder diesen ganzen regulatorischen Kram auch mit sich zieht, den man dann irgendwie betrachten muss. Ja, also das ist ja auch bei den Industriebussen oft so, dass man sich zertifizieren lässt für einen Bus und da kannst du natürlich zertifizierte Komponenten haben, je nach Standard.
Und ein anderer Teil der Software ist vielleicht nicht zertifiziert. Da schaust du natürlich dann auch drauf, dass du das mit den Architekturen machst, dass du dann nur den Teil, der wirklich relevant ist, zertifizieren lässt. Verstehe, ja. Ja, wenn man jetzt sagt, okay, als Softwareentwickler oder als Testerpfarrer, das ist eine Welt, da würde ich auch gerne mal ein
bisschen eintauchen. Hast du da so einen Tipp für ein Forum oder eine Konferenz oder so, wo man unbedingt mal vorbeischauen muss, wo man sagen kann, ach klasse, dort kann ich mich mal so ein bisschen inspirieren lassen in die Richtung? Wie meinst du jetzt, fürs Testen jetzt spezifisch? Oh, generell für die Embedded Entwicklung. Gibt es da irgendwas in Deutschland vielleicht?
Ja, ja, tatsächlich. Wir haben in Deutschland den Light Congress, ich würde sogar europäischen Light Congress sagen, mit der ESE, mit dem Embedded Software Engineering Congress in Sintring, der ist immer im Dezember. Und da sind auch Testthemen tatsächlich dabei. Das ist eine ziemlich coole Sache. Das ist so eine ganze Woche und da gibt es so Seminartage und dann gibt es einfach ganz schön viele Vorträge, die eigentlich immer von Leuten aus der Praxis gehalten werden.
Und die ganze Konferenz, die ist auch so ganz familiär, das ist so irgendwie, kommen da wahnsinnig viele Leute zusammen, aber das ist so eine coole Sache. Also es macht irgendwie tierisch Spaß, wenn man das so sagt. Ja, super. Das ist auch ein toller Tipp, den werden wir auch gleich in die Show Notes dann mit reinpacken und mit dem Link dazu packen. Vielleicht ist ja für den einen oder anderen auch spannend. Ja, super. Alex, vielen lieben
Dank für diese Einsichten mal in diese bisschen andere Welt für den einen oder anderen. Ich bin gespannt, was so an Feedback kommt. Ich weiß gar nicht, wie viele Embedded Entwickler oder Tester wir in der Community haben. Meldet euch doch mal. Was ist eure Meinung zu dem Thema? Möchte ich auch mal hören. Ich wünsche dir noch eine schöne Zeit. Ich danke dir, dass du hier im Podcast warst und hoffe, wir sehen uns dann auch mal bald in echt. Das wäre total cool, Ritschi. Vielen Dank für
die Einladung nochmal und dir einen guten Tag. Dankeschön. Ciao. Ciao, ciao. [Musik]