Echtzeit Echtzeitbetriebssysteme mittels Trace analysieren

Code- und Daten-Trace haben keinerlei Einfluss auf das Echtzeitverhalten eines Systems. Voll zum Tragen kommt dieser Vorteil etwa bei der Analyse des Laufzeitverhaltens von Echtzeitbetriebssystemen.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

PLS Programmierbare Logik & Systeme GmbH

Einer der kritischsten Punkte beim Test und der Analyse von Embedded Software ist erfahrungsgemäß die Systembeobachtung an sich. Schließlich gibt es eine ganze Reihe von Faktoren, die das Laufzeitverhalten negativ beeinflussen können.

Bildergalerie

Bereits beim Build-Prozess stellt sich die Frage: Wird die Applikation für Debugging und Test oder für die Produktion mit zusätzlicher Optimierung hinsichtlich Code-Größe oder Geschwindigkeit kompiliert? Später soll für Leistungsoptimierungen dann oft auch noch ein zusätzliches Profiling durchgeführt werden. Für die Messung der Laufzeiten von Funktionen und Tasks muss die Applikation dafür nicht selten instrumentiert werden. Der hinzugefügte Testcode hat einen zwar geringen, aber trotzdem messbaren Einfluss auf das Laufzeitverhalten. Unter Umständen ändert sich durch den zusätzlich notwendigen Code sogar das Speicherlayout. In diesem Fall kann der Einfluss natürlich nicht mehr ignoriert werden.

Zu den weiteren, Varianten der Systembeobachtung auf höherer Ebene zählt das vor allem im Zusammenhang mit Echtzeitbetriebssystemen häufig zum Einsatz kommende sogenannte Monitoring. Der Monitor „späht“ dafür nach Änderungen von Betriebssystemzuständen, die üblicherweise auf speziellen Speicherinhalten abgebildet werden. Über Interrupts, wie sie unter anderem bei Taskwechseln auftreten, aktiviert sich der Monitor und protokolliert das Ereignis für die spätere Analyse.

Wer auf eine Instrumentierung des Programmcodes oder Monitore für die Laufzeitanalyse von Echtzeitbetriebssystemen komplett verzichtet will, sollte sich vorsichtshalber gleich nach einem Mikrocontroller mit geeigneter Trace-Hardware inklusive leistungsfähiger Trace-Schnittstelle umsehen. Entsprechend ausgestattete MCU-Familien werden inzwischen von fast allen Halbleiterherstellern angeboten. Mittlerweile ist die Trace-Fähigkeit oftmals sogar schon ein K.O.-Kriterium bei der Plattformentscheidung.

Trace erlaubt es, Änderungen der Systemzustände ohne Einfluss auf das Echtzeitverhalten zu beobachten. Dafür stehen je nach Controller-Hersteller und Trace-Architektur mehrere Trace-Arten zur Wahl, die für die Analyse des Laufzeitverhaltens von Betriebssystemen interessant erscheinen. Bevor wir darauf näher eingehen, gilt es aber erst einmal zu klären, welche Informationen eigentlich konkret benötigt werden.

Bei Applikationen, die von einem Echtzeitbetriebssystem kontrolliert werden, spielen für die Beurteilung der Ausführungsperformance die Laufzeiten der einzelnen Tasks eine ganz entscheidende Rolle. Aus diesen Zeiten lässt sich unter anderem direkt ableiten, ob das System in einem vernünftigen Maße ausgelastet ist oder aber an der Grenze der Leistungsfähigkeit arbeitet. Wie oft ein Task durch andere Tasks in seiner Arbeit unterbrochen wird bzw. wie lange die einzelnen Tasks jeweils am Stück arbeiten können, ist ebenfalls ein wichtiges Kriterium. Hier bietet sich oftmals erhebliches Optimierungspotenzial, denn Taskwechsel verursachen einen nicht zu vernachlässigenden Overhead. Gleiches gilt für die Interrupt-Last. Über sie lässt sich ermitteln, wie oft und wie lange die Ausführung der Tasks durch Interrupts unterbrochen wird.

Um möglichst einfach und schnell an die benötigten Laufzeitinformationen für alle erforderlichen Messungen zu kommen, bietet sich augenscheinlich zu allererst einmal Code-Trace an. Aus ihm lassen sich für die Task-Analyse die Taskwechsel ermitteln, die inklusive des Schedulers letztlich durch mehrere Funktionsein- und -austritte, also Unterbrechungen der sequenziellen Ausführung, gekennzeichnet sind. So weit so gut. Nur: ein normaler Code-Trace ist für die Aufgabenstellung eigentlich viel zu umfangreich. Es werden ja auch Trace-Daten für die Ausführung von Code innerhalb von Funktionen aufgezeichnet; Bedingungen wie if-then-else-Konstrukte oder Schleifen. Dies geht natürlich zu Lasten der Trace-Größe, was wiederum den chipinternen und/oder externen Trace-Speicher völlig unnötig belastet.

(ID:44498572)