Suchen

Kein Rätselraten mehr

Trace-Visualisierung stützt das Debugging von RTOS-basierter Firmware

Seite: 2/4

Firma zum Thema

Herausforderungen bei der Anwendung eines RTOS

Was macht nun aber ein RTOS so besonders, dass man es als die dritte Generation beim Firmwaredesign bezeichnen kann? Ein RTOS übernimmt die Kontrolle über die Programmausführung und bringt mit den Tasks einen neuen Abstraktionsgrad ein. Der Kontrollfluss eines Programms lässt sich nun nicht mehr aus dem Quellcode ersehen, denn das RTOS entscheidet darüber, welche Task jeweils ausgeführt wird.

Bildergalerie

Während ein RTOS die Komplexität des Quellcodes einer Applikation verringern kann, reduziert es die der Applikation selbst innenwohnende Komplexität nicht. Eine Ansammlung scheinbar einfacher RTOS-Tasks kann, wenn sie gemeinsam als System ausgeführt wird, zu einem überraschend komplexen Laufzeitverhalten führen.

Der Entwickler muss festlegen, wie die Tasks miteinander interagieren und die Daten mit den Dienstfunktionen des RTOS teilen sollen. Dem Entwickler obliegt außerdem die Entscheidung über wichtige RTOS-Parameter wie die Task-Prioritäten (also die relative Dringlichkeit der Tasks), die durchaus nicht selbstverständlich sein müssen.

Selbst wenn Sie Ihren gesamten Code nach den bewährten Verfahrensweisen des RTOS-basierten Designs geschrieben haben, können andere Teile des Systems, ob es sich nun um Komponenten aus dem eigenen Unternehmen oder von Drittanbietern handelt, in derselben Umgebung laufen, aber sich nicht an dieselben Prinzipien halten.

Das grundlegende Problem besteht darin, dass es sich bei den RTOS-Tasks um keine isolierten Entitäten handelt. Zwischen den Tasks gibt es mindestens eine Art von Abhängigkeit, nämlich die von ihnen geteilte Prozessorzeit. Beim präemptiven Scheduling mit feststehender Priorität können praktisch jederzeit Tasks mit höherer Priorität erscheinen, die die Verarbeitung der Tasks geringerer Priorität verzögern.

Andere Arten geteilter Ressourcen (etwa globale Daten oder Hardwareperipherie) führen ebenfalls zu Abhängigkeiten zwischen den Tasks und können unvorhersehbare Verzögerungen bewirken, wenn die Synchronisation nicht korrekt geplant ist – unabhängig von den Task-Prioritäten.

Ein Beispiel für diese Art von Problemen findet man in der Pathfinder-Mission der NASA, in deren Verlauf ein Rover auf dem Mars gelandet wurde. Während dieser Mission kam es im Raumfahrzeug zu kompletten System-Resets, die zu Datenverlusten führten. Nach einigem Ärger ermittelte die NASA als Ursache ein klassisches RTOS-Problem, das als Prioritätsinversion bezeichnet wird.

Zu einer Prioritätsinversion kann es kommen, wenn ein Task hoher Priorität (Task H in der Abbildung 2 der Bildergalerie) auf eine geteilte Ressource (etwa eine Kommunikationsschnittstelle) zugreifen will, die gerade von einem Task mit geringerer Priorität (Task L) belegt wird. Task H würde normalerweise für kurze Zeit blockiert, bis Task L die geteilte Ressource freigibt.

Eine Prioritätsinversion tritt dann auf, wenn an dieser Stelle ein Task mittlerer Priorität (Task M) Task L unterbricht und die Aufgabe mit der eigentlich höheren Priorität dadurch weiter verzögert. Bei der Pathfinder-Mission der NASA führte dieses Verhalten zu System-Resets, zum Verlust von Daten und beinahe auch zu einem Fehlschlag der gesamten Mission.

Task-Abhängigkeiten wie das Scheduling und geteilte Ressourcen werden durch das Timing, also durch Verarbeitungszeiten und das Eingangs-Timing, beeinflusst. Dies macht es nahezu unmöglich, rein auf Grund des Quellcodes Aussagen über das Echtzeitverhalten eines RTOS-basierten Systems zu machen.

Unter dem Einfluss vieler Faktoren können die Tasks langsamer als vorgesehen laufen, zufällige, unerwartete Verzögerungen aufweisen oder auch niemals ausgeführt werden. Selbst dann, wenn das System scheinbar so arbeitet wie im Labor vorgesehen, kann es zahllose andere Verarbeitungs-Szenarien mit mehr oder weniger bedeutenden Timing-Unterschieden geben, von denen einige zu Problemen führen.

Im schlimmsten Fall besteht das System zwar die Tests, stürzt aber im Praxiseinsatz möglicherweise immer wieder ab.

(ID:44740567)