Echtzeitbetriebssysteme mittels Trace analysieren

Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

Parasoft® Deutschland GmbH

PLS Programmierbare Logik & Systeme GmbH

Daten-Trace, die Alternative zum Code-Trade

Eine Alternative zum Code-Trace ist der Daten-Trace. Echtzeitbetriebssysteme greifen für das Task-Scheduling zumeist auf eigene Verwaltungsstrukturen im Speicher des Mikrocontrollers zurück. Diese spiegeln den aktuellen Zustand des Systems wieder, beispielsweise welcher Task gerade aktiv ist oder ob sich das System in der Interrupt-Verarbeitung befindet. Änderungen des Systemzustandes wie ein Taskwechsel resultieren daher immer in einem Schreibzugriff auf diese Verwaltungsstrukturen.

Manche Trace-Implementierungen bieten mit Daten-Trace die Möglichkeit, diese Schreibzugriffe aufzuzeichnen und erlauben damit eine exakte Nachverfolgung und Analyse von Zustandswechseln im System. Daten-Trace ist jedoch wegen des hohen Speicherplatzbedarfs recht teuer, und ohne weitere Maßnahmen landen zudem auch alle anderen Speicherzugriffe der Applikation im Trace, was ähnlich dem Code-Trace ebenfalls unerwünscht ist. Damit nur die interessanten Zugriffe auf die Verwaltungsstrukturen aufgezeichnet werden, müssen extra dafür geeignete Filter verwendet werden.

Unabhängig davon, welche Trace-Art zur Ermittlung der Laufzeitinformationen benutzt wird, ist die Verfügbarkeit von eindeutigen und einheitlichen Zeitstempeln unabdingbar. Ohne diese ist es quasi unmöglich, exakte Messungen durchzuführen und verwertbare Ergebnisse zu gewinnen.

Beispiel: OSEK-ORTI

Wie eine Trace-Daten-basierte Analyse in der Praxis abläuft, lässt sich gut am Beispiel eines OSEK-basierten Betriebssystems demonstrieren. Die Abkürzung OSEK steht für Offene Systeme und deren Schnittstellen für die Elektronik in Kraftfahrzeugen, einen Standard für die Implementierung von Echtzeitbetriebssystemen vorrangig im Automotive-Umfeld. Eine Weiterentwicklung bzw. Weiternutzung der OSEK-Spezifikation findet sich im bekannten AUTOSAR wieder. Speziell für die Kommunikation mit Analysewerkzeugen und Debuggern wurde im Rahmen der OSEK das ORTI-Format (OSEK Runtime Interface) definiert. Dieses Format beschreibt in einer Textdatei, dem sogenannten ORTI-File, alle notwendigen internen Daten des Betriebssystems so, dass Werkzeuge sie in geeigneter Weise nutzen und für Anwender visualisieren können.

Der Debugger, hier im speziellen die Universal Debug Engine (UDE) von PLS, extrahiert aus diesem ORTI-File nun die Datenstruktur, in welchem beispielsweise der jeweils aktuelle Task hinterlegt ist (Bild 1). Diese Information dient der Konfiguration der Trace-Filter, so dass letztendlich nur relevante Informationen für die Task-Analyse im Daten-Trace aufgezeichnet werden (Bild 2) .

In einem nachfolgenden Analyseschritt wird der Trace so aufbereitet, dass sich die Sequenzen ausgeführter Betriebssystem-Tasks zeitlich exakt visualisieren lassen. Mit dafür spezialisierten Tools wie dem Eclipse Trace Compass können dann schlussendlich ausgefeilte Visualisierungen und ebenso weitere Auswertungen erfolgen (Aufmacherbild).

Die UDE stellt dafür eine Exportfunktion in das Best Trace Format (BTF) der Firma Timing Architects zur Verfügung, welches speziell als Austauschformat für Ereignis-Traces entwickelt wurde und bei einer ganzen Reihe von Werkzeugen aus den Bereichen Simulation, Profiling und Trace-Analyse Verwendung findet.

Code- und Daten-Trace als Allheilmittel?

Wie an dem Beispiel deutlich wird, stellt eine Tool-Kopplung mit dem Debugger und die Nutzung von Hardware-Trace inzwischen durchaus eine echte Alternative zur Gewinnung von Laufzeitinformationen mittels Instrumentierung oder durch spezielle Monitore dar. Zwar ist Hardware-Trace per se hinsichtlich der gesammelten Daten oft zu feingranular und damit speicherhungrig – typischerweise wird ja der gesamte Kontrollfluss auch innerhalb von Funktionen aufgezeichnet –aber die Nutzung von ORTI für Daten-Trace relativiert diesen Nachteil schnell. Unterm Strich bietet Trace also eine gänzlich rückwirkungsfreie und damit sehr exakte Methode für die Gewinnung von Laufzeitinformation, auch für Untersuchungen auf Task- bzw. Betriebssystemebene.

* Jens Braunes ist Product Marketing Manager bei der PLS Programmierbare Logik & Systeme

(ID:44498572)