Debugging von Embedded-Multicore-Systemen

Know-how  –  0 Kommentare

Das Debugging von Software gehört zu den schwierigeren Aufgaben. Die mittlerweile große Verbreitung von Multicore-Prozessoren im Bereich eingebetteter Systeme verschärft die Situation noch. Denn die meisten Debugging-Werkzeuge sind unzureichend auf die neuen Herausforderungen vorbereitet. Tracing könnte hier Abhilfe schaffen.

Eingebettete Systeme werden zunehmend komplexer. Die Durchdringung verschiedener industrieller Anwendungen mit Multicore-Prozessoren verstärkt diese Entwicklung. Die hohe Rechenleistung der neuen Prozessoren ermöglicht es den Herstellern einerseits, neue Funktionen auf ihren Geräten zur Verfügung zu stellen. Andererseits lassen sich auf solchen Prozessoren viele Funktionen unter einem Dach vereinigen, die zuvor auf mehr Geräte zu verteilen waren. Die Hersteller sparen Platz, Gewicht und somit Kosten.

Das Debugging von Software ist im Allgemeinen nicht einfach. Ist die Software dann in sicherheitskritischen Anwendungen integriert, wird es für die Ingenieure noch schwieriger. Sie müssen häufig nichtfunktionale Anforderungen beachten. Durch den Einsatz von Multicore-Prozessoren kommt eine weitere Dimension hinzu: parallel laufende, sich gegenseitig beeinflussende Prozesse.

Mit welchen Problemen die Softwareentwickler tatsächlich zu kämpfen haben, hat eine Umfrage des Fraunhofer-Instituts für Eingebettete Systeme und Kommunikationstechnik ESK festgestellt. Der Fokus der Befragung lag auf der Entwicklung von Software für eingebettete Systeme mit Multicore-Prozessoren. Diese bieten neben hoher Rechenleistung vergleichsweise geringen Energieverbrauch.

Allerdings haben die ESK-Forscher festgestellt, dass Multicore Softwareentwickler oft vor neue Herausforderungen stellt. Um diese zu verifizieren, haben sie Programmierer unterschiedlicher Branchen befragt. Sie gaben Auskunft über die Nutzung von Multicore-Prozessoren, Werkzeuge und größten Probleme bei der Entwicklung eingebetteter Software. Die Reproduzierbarkeit von Fehlern und das Debugging zeitkritischer Software wurden am häufigsten als Problem genannt. Die meisten Entwickler sehen Debugging also tatsächlich als eine der schwierigsten Aufgaben an.

Im Folgenden betrachtet der Artikel sicherheitskritische Systeme mit strikten Zeitschranken. Die Zeitschranken sind zusätzliche Anforderungen an die Software: Das Ergebnis muss spätestens zu dieser Schranke vorliegen oder es ist wertlos. Diese Eigenschaft beeinflusst das Debugging erheblich. Haben Werkzeuge Einfluss auf die Dauer der Ausführung, können Zeitschranken verletzt werden. Softwarekomponenten, die von der untersuchten Komponente abhängen, können dadurch in ihrem Zeitverhalten beeinträchtigt werden und ebenfalls ihre Zeitschranken überschreiten. Ein verwandter Effekt erschwert zudem die Reproduzierbarkeit von Fehlern. Vom konkreten Zeitverhalten hängen sowohl die Funktion der Software als auch das Auftreten des Fehlers ab.

Neue Probleme durch Multicore

Multicore-Prozessoren erweitern die Probleme noch um Parallelität. Unabhängige Softwarekomponenten lassen sich nun gleichzeitig ausführen, müssen sich aber bestimmte Ressourcen teilen. Die meisten Entwickler denken sofort an Hauptspeicher und Cache. Andere geteilte Ressourcen sind etwa Busse, Bus-Controller und allgemein die Peripherie. Diese werden bei Problemen selten beachtet.

Die Herausforderung mit geteilten Ressourcen ist, dass sie zwischen Softwarekomponenten Wechselwirkungen vermitteln, die der Entwickler weder beabsichtigt noch vorhergesehen hat: Die Ausführung einer Softwarekomponente kann vom konkreten Verhalten einer anderen Komponente abhängig sein. Auf den normalen Betrieb muss das keine Auswirkungen haben. Eine Abschätzung der Ausführungszeit (engl.: Worst Case Execution Time) lässt sich heute auch von paralleler Software berechnen. Debugging-Werkzeuge bleiben dabei aber unberücksichtigt; die Werkzeuge können auch ansonsten unabhängig Softwarekomponenten beeinflussen.

Trace der Ausführung eines Dual-Core-Systems; die Komponente "Soft-RT Task" erfährt eine Verletzung ihrer Zeitschranke (durch blaues Dreieck markiert). Die Ursache ist im unteren Teil der Abbildung sichtbar: Ein Interrupt und dessen Behandlung (dunkelgraue Flächen) haben die Anwendung unterbrochen (Abb. 1).

Dargestellt ist die Ausführung eines Echtzeitsystems mit zwei Softwarekomponenten auf einem Dual-Core-System. Bei der Planung ist nicht berücksichtigt, dass sich eine externe Debugging- Verbindung zu einer der beiden Softwarekomponenten, in der Abbildung General Task genannt, herstellen lässt. Diese Verbindung führt im gezeigten Szenario zu seltenen und schwer reproduzierbaren Verletzungen der Zeitschranke der nicht mit dem Debugger verbundenen Komponente (in Abb. Soft-RT Task).