Ein Angebot von

Trace-Visualisierung beim Debugging von RTOS-Firmware

| Autor / Redakteur: Dr. Johan Kraft * / Sebastian Gerstl

Bild 1: Pathfinder mit dem Rover Sojourner während der Vorbereitungsphase. Bei der Marsmission der NASA kam es zu einem Problem mit dem RTOS.
Bild 1: Pathfinder mit dem Rover Sojourner während der Vorbereitungsphase. Bei der Marsmission der NASA kam es zu einem Problem mit dem RTOS. (Bild: NASA)

Echtzeit-Betriebssysteme sind in Embedded Systemen längst fest etabliert. Um RTOS-basierte Systeme vernünftig zu debuggen, bedarf es aber besserer Einblicke in ihre Echtzeitverarbeitung.

Vor einigen Jahrzehnten gab es in der Embedded-Industrie eine Verlagerung des Schwerpunkts von der Assembler- zur C-Programmierung. Schnellere Prozessoren und bessere Compiler ermöglichten diese Anhebung des Abstraktionsgrads, die die Produktivität und Qualität der Entwicklung verbesserte.

Zurzeit befinden wir uns inmitten einer neuen bedeutenden Umstellung in der Firmwareentwicklung-Technologie: die zunehmende Verwendung von Echtzeit-Betriebssystemen (Real-Time Operating Systems – RTOS) verkörpert die dritte Generation der Entwicklung von Embedded-Software. Ein RTOS ist ein schnelles und deterministisches Betriebssystem für den Einsatz in Embedded- und IoT-Anwendungen. Seine Hauptaufgabe ist das Multithreading, um die Aufteilung der Softwarefunktionalität in mehrere ‚parallel‘ laufende Teilprogramme, so genannte ‚Tasks‘ zu ermöglichen.

Der Trend zum Echtzeit-Betriebssystem

RTOS sind kein Hype mehr, wie sie es noch vor 10 bis 15 Jahren waren, sondern befinden sich in allen möglichen Arten von Embedded-Anwendungen im Einsatz. Im Embedded Market Survey, der wohl am besten etablierten und am meisten vertrauten Studie der Branche, ist dieser Trend klar erkennbar. Auf die Frage nach der ‚größten technologischen Herausforderung‘ wird am häufigsten das RTOS genannt. Der Anteil dieser Antwort wuchs von 12 % im Jahr 2013 auf 17 % 2014 und 26 % im Jahr 2015. Der historisch sehr fragmentierte Markt scheint sich jetzt in einer Konsolidierungsphase zu befinden, in der sich die Entwickler zunehmend den führenden Akteuren zuwenden.

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.

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 (z. B. 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 eine Task hoher Priorität (Task H in der folgenden Abbildung) auf eine geteilte Ressource (z. B. eine Kommunikationsschnittstelle) zugreifen will, die gerade von einer 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 eine Task mittlerer Priorität (Task M) Task L unterbricht und die hochpriore Task 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 bei Ihren Kunden immer wieder ab.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44950748 / Embedded Betriebssysteme)