Debugging von RTOS-Software-Systemen
Schluss mit dem Rätselraten
Fortsetzung des Artikels von Teil 2
Prioritätsinversion auf dem Mars
Ein höchst prominentes und kostspieliges Beispiel für die Art von Schwierigkeiten trat während der Pathfinder-Mission der NASA auf, bei der 1997 ein Rover auf dem Mars gelandet wurde. Während der Mission kam es im Raumfahrzeug zu kompletten System-Resets, die Datenverluste zur Folge hatten. Nach erheblichen Problemen fand die NASA heraus, dass die Ursache in einem klassischen RTOS-Problem lag, das als Prioritätsinversion bekannt ist.
Zu einer Prioritätsinversion kann es kommen, wenn eine Task hoher Priorität (die rot dargestellte Task H in Bild 6) auf eine geteilte Ressource wie etwa eine Kommunikationsschnittstelle zugreifen will, die gerade von einer Task mit geringerer Priorität (Task L, grün) genutzt wird. Task H würde normalerweise für eine kurze Zeitspanne blockiert, bis Task L die geteilte Ressource freigibt. Zu einer Prioritätsinversion kommt es, wenn an der Stelle eine Task mittlerer Priorität (Task M, gelb) Task L unterbricht und die hoch priore Task dadurch verzögert, wie in Bild 6 dargestellt. Bei der Pathfinder-Mission der NASA führte das zu wiederholten Timeout-Fehlern mit daraus resultierenden Resets, Datenverlusten und beinahe zu einem Fehlschlag der Mission.
Jobangebote+ passend zum Thema
Mit Tracing können Entwickler Probleme dieser Art detektieren und vermeiden. Es umfasst das Aufzeichnen des Softwareverhaltens zur Laufzeit, um die gesammelten Trace-Daten im Nachgang zu analysieren. Weiterhin erfolgt das Tracing oftmals im Entwicklungslabor, ist jedoch ebenso in der Produktion nutzbar. Im Labor ist es ununterbrochen aktiv, um das Verhalten aufzuzeichnen und Fehler nach dem Deployment aufzudecken. Das Produktions-Tracing kann eine effektive Technik zum Detektieren selten auftretender Fehler sein, die sich in einem Debugger jedoch schwer reproduzieren lassen. Unter anderem kann es um Fälle gehen, in denen ein System langsamer reagiert als erwartet, falsche oder suboptimale Ergebnisse ausgibt, stehen bleibt oder abstürzt.
Schluss mit dem Rätselraten
Das Debugging RTOS-basierter Systeme lässt sich drastisch vereinfachen, verbunden mit einem Reduzieren der Debugging-Zeit von Tagen oder Wochen auf lediglich Stunden sowie besseren Einblickmöglichkeiten in deren Echtzeit-Verarbeitung. Nötig ist hierfür ein Software-Tracing auf der RTOS-Ebene. Hier ist ein gutes Visualisieren entscheidend dafür, um verwertbare Informationen aus den Daten extrahiert zu können. Zwar gibt es durchaus mehrere Tools, die ein einfaches RTOS-Tracing bieten, jedoch wird es erst mit einer ausgefeilten Visualisierung deutlich einfacher, den Trace zu verstehen, wichtige Probleme zu identifizieren und die Möglichkeiten zu verifizieren.
Der Autor
Dr. Johan Kraft ist CEO und Gründer von Percepio, einem schwedischen Unternehmen, das die Tracealyzer-Visualisierungstools entwickelt. Dr. Kraft hat einen Doktortitel in Informatik inne. Seine akademische Arbeit konzentrierte sich auf praktische Methoden zur Zeitanalyse von eingebetteter Software, die in enger Zusammenarbeit mit der regionalen Industrie durchgeführt wurde. Vor seiner Promotion arbeitete er als Entwickler von Embedded-Software mit dem Schwerpunkt auf Steuerungs-Software für Industrieroboter.
johan.kraft@percepio.com
- Schluss mit dem Rätselraten
- Aufdecken von Fehlern
- Prioritätsinversion auf dem Mars
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Software Engineering
Kostenlose Tracealyzer-Version verfügbar
Sicherheit bei der Software-Entwicklung
Welcher Standard ist der Beste?
Entwicklungstools
Segger unterstützt SiFive Debug-/Trace-Interface
Covid-19
Debuggen im Homeoffice
Sicherheit für mobile Anwendungen
Verschlüsselung im Smartphone-Format
Tools für die Software-Entwicklung
Linux-Systeme schneller entwickeln mit Tracealyzer 4.4
Multiprocessing mit OpenAmP
Viele Kerne – zwei Möglichkeiten
