Autor: Andr\u00e9 Schmitz, Green Hills Software<\/p>\n
Debugging mittels „printf()“, Setzen von Haltepunkten und Code-Ausf\u00fchrung via Einzelschritt sind die Debug-Methoden von gestern. Heutige Debug-Tools k\u00f6nnen bereits viel mehr, wie zum Beispiel automatische Fehlersuche zur Laufzeit, Heap-Analyse und Memory-Leak-Erkennung, Profiling und nicht zuletzt die Auswertung von Hardware-Tracedaten. Doch was wird in Zukunft kommen? Wie wird man komplexe Software auf Multi-Core-Systemen, die massiv auf verschiedene Peripherie-Komponenten zugreift, schnell und einfach debuggen k\u00f6nnen? Wie wird in einem Team gemeinsame Fehlersuche betrieben werden? Welche Methoden werden uns bei der Arbeit helfen, Zeit zu sparen? Dieses Papier zeigt den aktuellen Stand der Technik und gibt einen Ausblick auf neue Methoden und Technologien, die uns in Zukunft das Debuggen erleichtern werden.<\/strong><\/p>\n Debugging ist heute schon mehr als single-stepping, breakpoints und Memory View. Schon heute gibt es Tools zur statischen Code-Analyse oder MISRA-Checker, welche den Code sogar schon vor der ersten Ausf\u00fchrung analysieren und potentielle Fehler finden k\u00f6nnen. Dies ist die g\u00fcnstigste Art, Softwarefehler zu finden. Auch automatische Codegenerierung ist ein gro\u00dfer Schritt hin zu fehlerfreiem Code.<\/p>\n Wird das Programm auf dem Target ausgef\u00fchrt, so kann man verschiedene Methoden nutzen, Fehler im Programm leicht zu finden. Das Profiling (siehe Abbildung 1,\u00a0PDF<\/a>) erlaubt es zum Beispiel einfach, die Hotspots des Programms zu identifizieren und zu entscheiden, an welchen Stellen im Programm man weiter optimieren sollte. Die Laufzeit-Fehlersuche erlaubt es, mithilfe des Compilers \u00dcberpr\u00fcfungssequenzen in den Code einzubauen, mit deren Hilfe man ganz automatisch Fehler finden kann. Diese Fehler sind zum Beispiel die \u00dcberschreitung von Array-Grenzen, die \u00dcberschreitung des Wertebereichs von Variablen, die Division durch Null oder die Dereferenzierung eines Null-Pointers.<\/p>\n Wenn es um die Verwendung von dynamischem Speicher geht, so kann man sich mit aktuellen Tools automatisch alle Reservierungen auf dem Heap anzeigen lassen, Zugriffe auf nicht allokierten Speicher identifizieren und nicht zuletzt automatisch alle Memory Leaks finden lassen. Es gibt Tools zur Analyse des zeitlichen Verhaltens eines Systems, in dem alle relevanten Ereignisse geloggt und visualisiert werden.<\/p>\n Ein weiterer wichtiger Aspekt der Fehlersuche ist die Simulation. Man kann Code zum Beispiel auf simulierten Controller ausf\u00fchren oder das Verhalten der Sensorik und der Umwelt des Embedded Systems simulieren (Rest-Bus, Hardware in the Loop [1], etc.). Es gibt Werkzeuge mit deren Hilfe man automatisch Modul- und Integrationstests generieren kann um eine gute Testabdeckung und Test-Dokumen\u00adtation zu erhalten.<\/p>\n Ein ganzheitliches Testmanagement zeichnet sich durch mehrere Aspekte aus, um alle relevanten Tests in einem Projektzyklus abdecken zu k\u00f6nnen. Die erste S\u00e4ule ist die\u00a0Teststrategie<\/em>, in der festgelegt wird, wie im Projekt konkret vorgegangen wird. Die zweite S\u00e4ule bildet eine geeignete\u00a0Testmethodik<\/em>, die auf der\u00a0Teststrategie<\/em>\u00a0aufbaut. Die\u00a0Testmethodik<\/em>\u00a0beinhaltet vor allem eine Auswahl von verschiedenen Testverfahren und Testsystemen. Die dritte S\u00e4ule ist das Testmanagement in den Projekten. Die zentrale Rolle nimmt dabei der\u00a0Testmanager<\/em>\u00a0ein. Er ist verantwortlich f\u00fcr die Erstellung einer geeigneten\u00a0Teststrategie<\/em>\u00a0und\u00a0Testmethodik<\/em>\u00a0f\u00fcr das jeweilige Projekt.<\/p>\n Viele Controller haben eine Trace Unit integriert, sodass man mit passenden Trace Tools die Tracedaten sammeln und sehr geschickt aufbereiten kann. Nicht zuletzt kann man mit entsprechenden Tools dann auch quasi r\u00fcckw\u00e4rts in der Zeit debuggen, d.h. man wandert durch die Tracedaten, indem man den Program-Counter im Debugger vor- und zur\u00fcck wandern l\u00e4sst und dabei wie gewohnt Variablen und Register anzeigt (siehe Abbildung 2,\u00a0PDF<\/a>)<\/p>\n Wenn wir nun weiter in die Zukunft schauen, dann m\u00fcssen wir uns auf immer mehr Multi-Core-CPUs mit immer h\u00f6heren Takt-Frequenzen gefasst machen. Aktuelle High-End CPUs kommen mit 4 oder 8 Cores und einem Takt von mehr als 2GHz daher [2] [3]. Dieser Trend wird sicherlich weitergehen, und dabei ist es schon fast egal, was schneller w\u00e4chst, die Zahl der Cores oder die Frequenz.<\/p>\n Doch wie bekommt man die Tracedaten von einer 8 Core 2GHz CPU auf eine Trace-Hardware? Werden wir Tools haben, die uns die Analyse von nebenl\u00e4ufigen Anwendungen auf 8 oder mehr Cores \u00fcber einen langen Zeitraum erlauben?<\/p>\n Es ist absehbar, dass wir mehr und mehr heterogene Hardware und Software haben werden. Hier will man gleichzeitig verschiedene Betriebssysteme auf einem Hypervisor oder verschiedenen Cores der gleichen Architektur (Cortex-M4 und Cortex-A9) oder sogar Kombinationen von ganz unterschiedlichen Hardware-Architekturen debuggen k\u00f6nnen.<\/p>\n Ein weiteres interessantes Problem wird die Analyse der Interaktion von Software und Hardware sein. Es gibt zum Beispiel f\u00fcr nVidia GPUs ein Tool mit Namen Nsight [4], welches die Abl\u00e4ufe auf der GPU und im Programm-Code beim Rendern einer Szene darstellen kann und es erlaubt, diese effizient zu analysieren. Das Tool zeigt sehr gut die Interaktion zwischen CPU und GPU. Solche Tools gibt es derzeit aber nur f\u00fcr PCs, nicht aber f\u00fcr das den Embedded Bereich.<\/p>\n Ganz egal was wirklich kommen wird, wir werden auf jeden Fall in der Lage sein m\u00fcssen, mit immer gr\u00f6\u00dferen Datenmengen umzugehen und schnell und effizient zu durchsuchen, analysieren und visualisieren. Letztlich m\u00fcssen wir uns auch fragen, wie wir schneller Softwarefehler finden k\u00f6nnen. Das erfordert zuallererst ein Umdenken und Optimierungen im Entwicklungsprozess.<\/p>\n Lassen Sie mich den Ausblick in die Zukunft in Form von Fragen formulieren.<\/p>\n W\u00e4re es nicht sch\u00f6n, wenn man gro\u00dfe Datenmengen effizient visualisieren k\u00f6nnte, wo Sie zu jeder Zeit sehen k\u00f6nnen, was Ihr Programm wann genau macht oder gemacht hat? Daf\u00fcr brauchen Sie nat\u00fcrlich schnelle Werkzeuge auf Ihren Arbeitsplatzrechnern. Das Tool Nsight von nVidia ist optimiert f\u00fcr die Analyse von PC-Programmen, also Programmen, die auf demselben PC laufen wie das Tool. W\u00e4re es nicht sch\u00f6n, so \u00e4hnliche Tools f\u00fcr ein Embedded System auch nutzen zu k\u00f6nnen? Wir k\u00f6nnten dann sehr komplexe Softwaresysteme so laufen lassen, dass man alle Vorg\u00e4nge innerhalb und au\u00dferhalb des Systems in allen Details erkennen und korrelieren kann. Vielleicht ben\u00f6tigen wir dazu neue Simulationsumgebungen, wie wir sie heute noch nicht haben.<\/p>\n Sind wir schnell genug bei der Identifizierung der Ursache eines Softwarefehlers? Wenn wir es schaffen, unsere Prozesse und das Tooling so zu optimieren, dass die Zeit vom Auftreten und Erkennen eines Softwarefehlers bis zum Finden und Beheben der defekten Code-Stelle immer k\u00fcrzer wird, dann steigert das die Produktivit\u00e4t ungemein. Wir werden damit auch die immer komplexeren Softwaresysteme einfach debuggen k\u00f6nnen.<\/p>\n Wie sollen wir in Zukunft in immer gr\u00f6\u00dferen Softwareteams arbeiten, wenn immer komplexere Software immer obskurere Fehler hervorbringen? Wenn eine Tester einen schwer zu reproduzierenden Fehler gefunden hat, dann muss er dem Entwickler eine Umgebung zur Verf\u00fcgung stellen k\u00f6nnen, in der dieser das Problem in k\u00fcrzester Zeit wiederherstellen sowie den Fehler identifizieren und damit beheben kann.<\/p>\n Die Herausforderung bei der Software-Fehlersuche werden sein:<\/p>\n Wir brauchen neue Konzepte, Technologien und Werkzeuge, um die Produktivit\u00e4t der Softwareentwickler zu steigern.<\/p>\n [1]\u00a0https:\/\/de.wikipedia.org\/wiki\/Hardware_in_the_Loop<\/a><\/p>\n [2]\u00a0https:\/\/de.wikipedia.org\/wiki\/Intel_Atom<\/a><\/p>\n [3]\u00a0https:\/\/de.wikipedia.org\/wiki\/ARM_Cortex-A<\/a><\/p>\n [4]\u00a0https:\/\/www.nvidia.com\/object\/nsight.html<\/a><\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Test, Qualit\u00e4t & Debug.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Test, Qualit\u00e4t & Debug steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nStand der Technik<\/h2>\n
Das „Drei-S\u00e4ulen-Modell“<\/h2>\n
Herausforderungen der Zukunft<\/h2>\n
Ausblick in die Zukunft<\/h2>\n
Zusammenfassung<\/h2>\n
\n
Referenzen<\/h2>\n
\nTest, Qualit\u00e4t & Debug – unsere Trainings & Coachings<\/h2>\n
\nTest, Qualit\u00e4t & Debug – Fachwissen<\/h2>\n