»Monolithische« Echtzeitbetriebssysteme erweitern
»Apps« fürs RTOS
Fortsetzung des Artikels von Teil 1
»Apps« fürs RTOS
Die Module nutzen die Dienste des Kernels über eine Schnittstelle zum Modul-Manager (Bild 5). Dieser im Kernel-Image enthaltene Agent lädt und initialisiert die Module und koordiniert alle Anforderungen von RTOS-Diensten durch die Module. Die Threads innerhalb der Module führen ihre Dienstaufrufe so aus, als wäre der Dienst direkt an die Applikation gelinkt.
In dem Modul werden diese Aufrufe jedoch von einer Schnittstellenkomponente behandelt, die mit dem Modul-Manager kommuniziert. Durch den Wegfall des Trap-Mechanismus lassen sich Dienstaufrufe mit wenig Verarbeitungsaufwand verarbeiten. Vom Modul-Manager gibt es nur eine einzige Instanz. Dennoch können unbegrenzt viele Module gleichzeitig geladen sein, und auch für die Zahl der Threads pro Modul gibt es keine Obergrenze.
Man erreicht hiermit, dass der Kernel in einer abgegrenzten Verarbeitungsinstanz residiert, die fortlaufend aktiv ist, um Aufrufe seitens der Module bedienen zu können. Um die Effizienz zu maximieren, können die Applikations-Threads alternativ auch an den Kernel gelinkt werden und zusammen mit dem Kernel als Bestandteil dessen ausführbarer Image-Datei im Speicher des Zielsystems residieren.
Diese Option vermeidet das Laden der Module, die diese Threads enthalten, und ergibt die effizienteste Schnittstelle. Allerdings wird das Kernel-Image hierdurch größer, sodass weniger Speicherplatz für die Module bleibt. Auch wird die Chance vergeben, die Applikations-Threads dynamisch auszutauschen. Mithilfe downloadfähiger Applikationsmodule kann das RTOS zusätzliche Applikations-Threads neben jenen, die an den Kernel gelinkt sind, dynamisch laden und verarbeiten.
Die Applikationen erhalten hierbei zusätzliche Funktionen, ohne einen größeren Footprint oder einen erhöhten Speicherbedarf in Kauf nehmen zu müssen. Überdies bleibt der Vorteil einer effizienten Schnittstelle für Dienstaufrufe erhalten. Nicht zuletzt lassen sich bereits im Einsatz befindliche Systeme bedarfsorientiert rekonfigurieren und updaten.
Die Technik der downloadfähigen Applikationsmodule eignet sich besonders für Situationen, in denen der Applikationscode nicht in den verfügbaren Speicher passt, in denen nach der Installation eines Produkts neue Module hinzugefügt werden müssen oder wenn partielle Firmware-Updates notwendig sind. Ein weiterer Vorteil des Herunterladens separater Applikationsmodule ist die Tatsache, dass die einzelnen Module von verschiedenen Teams oder einzelnen Programmierern entwickelt werden können. Das jeweilige Team kann sich dann auf einen bestimmten Aspekt der Gesamtfunktion eines Produkts konzentrieren, ohne sich mit Details befassen zu müssen.
Fehlfunktionen lassen sich vermeiden
Nachteilig an einem solchen Konzept ist, dass das Risiko von Fehlfunktionen steigt, wenn das Modul in das System eingefügt wird und mit dem Kernel sowie mit anderen Modulen interagieren muss. Die Entwickler hegen verstärkte Bedenken, ob sich die externen Module mit den anderen vertragen.
Noch schlimmer als ein Programm-Bug, der Fehlfunktionen verursacht oder einen Absturz des Moduls verursacht, ist ein Bug, der ein anderes Modul oder gar den RTOS-Kernel selbst kontaminiert. Ungeachtet aller Tests bleibt das Risiko einer zufälligen Korruption des Stacks oder des Speichers infolge eines falsch berechneten Zeigers, einer falsch berechneten Arraygrenze oder eines Stack-Überlaufs erhalten.
Jobangebote+ passend zum Thema
Derartige Fehler können katastrophale Folgen haben und außerdem schwierig zu finden sein - besonders dann, wenn nur ein Teil des Entwicklungsteams mit dem betreffenden Modul vertraut ist. Noch schwieriger wird es, wenn die Ursache für einen solchen Fehler in den betreffenden Code zurückverfolgt wird und sich dieser in einem ganz anderen Modul befindet.
Da das Einkreisen der Ursache solcher katastrophalen Fehler so enorm schwierig ist, ist es umso wichtiger, diese Fehler von vornherein zu vermeiden. Um Systeme vor dieser Art zufälliger Beeinträchtigung zu schützen, ist es sinnvoll, die Threads eines Moduls vom Zugriff auf Speicherstellen außerhalb des eigenen Bereichs abzuhalten. Stattdessen sollten RTOS-Dienste für das Message-Passing angeboten werden.
Diese Schutzmaßnahmen bewahren Module und den Kernel vor unbeabsichtigter Korruption durch fehlerhafte Schreib- oder Sprung-Operationen und auf Wunsch auch durch falsche Lesevorgänge. Mit der MMU (Memory Management Unit) oder MPU (Memory Protection Unit) des Systems lassen sich Speichergrenzregister einrichten, die dafür sorgen, dass der Code eines Moduls nur auf den eigenen Speicherbereich zugreifen kann (Bild 6).
Über den Autor:
John A. Carbone ist Vice President of Marketing bei Express Logic.
- »Apps« fürs RTOS
- »Apps« fürs RTOS
