Verborgene Probleme aufdecken: Real

Jakob von Benin | 30. August 2023

Eine der am meisten unterschätzten Funktionen in der Entwicklung eingebetteter Software ist heute die Nachverfolgung einer Echtzeitbetriebssystemanwendung (RTOS). RTOS haben Eingang in fast alle IoT-Geräte und viele nicht vernetzte Geräte gefunden. Wenn Entwickler ihre Systeme testen, schauen sie sich häufig das externe Systemverhalten an, um zu beurteilen, ob es ordnungsgemäß funktioniert. Das Problem bei diesem Ansatz besteht darin, dass viele Systeme Verhaltensweisen aufweisen, die deterministisch auf Zeitskalen von weniger als 50 Millisekunden auftreten müssen. Ohne Nachverfolgung könnten Sie glauben, dass das System funktioniert, nur um dann, wenn es in die Hände Ihrer Kunden gelangt, festzustellen, dass es fehlerhaft ist und nicht unter allen Umständen ordnungsgemäß funktioniert. In diesem Beitrag werde ich Sie durch einige Trace-Funktionen führen und Beispiele dafür geben, wie ich Probleme erkannt habe, die möglicherweise erst entdeckt wurden, als die Geräte im Einsatz waren.

Bevor wir uns einige spezifische Beispiele ansehen, ist es hilfreich zu verstehen, wie eine RTOS-Anwendung verfolgt wird. Normalerweise besteht es aus zwei Teilen: einer Rekorderbibliothek, die Ereignisse in der RTOS-Anwendung auf dem Ziel verfolgt, und einer Visualisierungs-GUI, die die Ereignisdaten empfängt und anzeigt. Mit mehreren Tools können Entwickler diese Daten erfassen, beispielsweise Percepio Tracealyzer, SEGGER SystemView und Microsoft Azure RTOS TraceX. Es gibt viele andere, aber welches Tool Sie verwenden, hängt vom verwendeten RTOS und Ihren Visualisierungsanforderungen ab.

Im Allgemeinen installieren Sie die Trace-Recorder-Bibliothek des Tools, die häufig eine Trace-Aufgabe erstellt. Diese Aufgabe mit niedriger Priorität übernimmt die aufgezeichneten Ereignisdaten und überträgt sie an die Host-Anwendung (zumindest im Streaming-Modus). Ich erwähne dies, denn wenn Sie Ihren Code auf diese Weise instrumentieren, ist es wichtig zu beachten, dass zusätzliche CPU-Zyklen für die Aufzeichnung der Trace-Daten aufgewendet werden. Nach meinen Erfahrungen mit diesen Tools ist der Overhead so gering, dass man ihn nicht bemerkt (zumindest bei keiner Anwendung, an der ich gearbeitet habe). Es ist wichtig zu wissen, ob Sie den Trace-Recorder in Ihrer Release-Firmware belassen. Wenn Sie dies nicht tun, testen und validieren Sie Ihre Anwendung mit Ihrer Release-Firmware!

Ich habe kürzlich ein Team von Ingenieuren gecoacht, die mit Validierungstests für ihr Produkt begonnen hatten. Sie führten ihre Tests durch und glaubten, dass ihr System einwandfrei lief. Sie sagten mir, ihr System sei versandbereit; Sie sahen ein kleines Problem mit dem Telemetrie-Timing ihres Systems – keine große Sache. Meiner Erfahrung nach gibt es keine Kleinigkeiten. Kleinere Probleme sind normalerweise die Spitze des Eisbergs, die sich zu gigantischen Problemen entwickeln, wenn sie in die Hände des Kunden gelangen. Deshalb haben wir Percepio Tracealyzer eingerichtet, um die Anwendung zu verfolgen und zu sehen, wie ihr System einwandfrei funktioniert.

Wenn Sie sich Abbildung 1 unten ansehen, sehen Sie eine Darstellung der CPU-Auslastung des Systems. Jede Farbe im Diagramm stellt eine andere Aufgabe dar. Die x-Achse ist die Zeit und die y-Achse ist die CPU-Auslastung. Sieht das nach einem validierten System aus, das bereit ist, in die Hände der Kunden zu gehen?

Abbildung 1. Ein Beispieldiagramm zur CPU-Auslastung, bei dem die CPU-Auslastung die ganze Zeit über 100 % erreicht.

Leider war die CPU des betreffenden Systems zu 100 % ausgelastet. Bei näherer Betrachtung stellte sich heraus, dass kritische Fristen fehlten und die Funktion nicht deterministisch war. Menschliche Beobachtung war nutzlos, um diese Probleme durch die Nachverfolgung der Anwendung zu entdecken. Wäre das Produkt so versendet worden, hätten die Kunden Probleme gehabt. Durch die Erfassung einiger einfacher Spuren konnten wir ein Problem erkennen und Abhilfe schaffen. Als wir etwas tiefer gingen, identifizierten wir ein paar kleine Ursachen, deren Behebung weniger als einen halben Tag dauerte, und die resultierende CPU-Auslastung stieg von Abbildung 1 auf etwa Abbildung 2.

Abbildung 2. Ein Beispiel für ein CPU-Auslastungsdiagramm, das besser für ein Produktionssystem geeignet ist.

Die verbesserte CPU-Auslastung ist viel geringer und lässt Spielraum für das Hinzufügen zukünftiger Funktionen und stellt sicher, dass der Kunde über ein System verfügt, das reagieren und seine Fristen einhalten kann.

Die RTOS-Ablaufverfolgung erkennt nicht nur Probleme mit der CPU-Leistung. Es verhält sich wie ein Oszilloskop für Software! Durch die Visualisierung von Threads können Sie verschiedene Muster in Ihrem System erkennen und Inkonsistenzen identifizieren. Das Ergebnis ist, dass Sie Probleme wie Prioritätsumkehrungen, Deadlocks und Task-Hunger feststellen können. Schauen wir uns ein Beispiel an.

Nachdem das CPU-Auslastungsproblem behoben war, war die Versuchung groß, zu feiern. Das System sah gut aus, oder? Nur weil Ihre CPU-Auslastung gut aussieht, bedeutet das nicht, dass sich alle Threads korrekt verhalten. Nachdem ich die Berichte und Traces zur Aufgabenleistung untersucht hatte, fiel mir etwas Interessantes auf. Eine der Aufgaben (gelb), die regelmäßig ausgeführt werden sollten, wurde nicht ausgeführt. Es würde dreimal nahezu korrekt ausgeführt werden, eine lange Pause einlegen und dann fortfahren, wie in Abbildung 3 dargestellt.

Abbildung 3. Aufgabenansichten können Inkonsistenzen in der Aufgabenperiodizität aufdecken, wie in der gelben Aufgabe zu sehen ist.

Mit dem Trace-Tool stellte sich heraus, dass die Periodizität der Aufgabe um 50 % schwankte! Würde ein Mensch dies ohne Rückverfolgung bemerken? Nein. Würde es die Leistung dieses Systems beeinträchtigen und Probleme vor Ort verursachen? Ja! Nachdem wir das Problem erkannt hatten, dauerte es erneut weniger als eine Stunde, es aufzuspüren und zu lösen! Ohne das Trace-Tool wäre das Produkt jedoch auf den Markt gekommen, hätte Probleme gehabt und hätte zu verärgerten Kunden und möglicherweise langen Debug-Zyklen bei der Suche nach der Grundursache geführt.

Wenn Sie eine Anwendung schreiben, die ein RTOS verwendet, sollten Sie Ihre Anwendung verfolgen. Sie sollten es nicht unmittelbar vor dem Übergang in die Hände Ihrer Kunden verfolgen, sondern während des gesamten Entwicklungszyklus. Wenn Sie eine Softwareänderung, die ein Problem verursacht, sofort erkennen können, können Sie sie schnell beheben und sparen Zeit und Geld für die spätere Suche nach dem Problem im Entwicklungszyklus. Sie können wirklich nicht verstehen, was Ihr System tut, bis Sie es verfolgen, und nur dann können Sie feststellen, ob es sich so verhält, wie Sie es sich vorstellen. Ich verwende Trace-Tools nun schon seit einem halben Jahrzehnt oder länger, und ich kann Ihnen gar nicht sagen, wie oft sie mir dabei geholfen haben, Probleme zu erkennen, die ich sonst nicht erkannt hätte. Ebenso wie Unit-Tests halte ich das Tracing für ein unverzichtbares Werkzeug, und ich denke, Sie werden es auch tun.

Weitere Informationen zu Textformaten