Dynamische Adaption in heterogenen verteilten eingebetteten ...

4 Basisschicht eines Verwalters
2. Ausführung der Operationen (peek, poke, resume, . . . ).
4.5.7.1 Kommunikation
Im einfachsten Fall kann das RCM ein eigenes Kommunikationsmedium nutzen, das nur für die
Verbindung zum Verwalter verwendet wird. Dann kann die Steuerung der Kommunikationshardware
vollständig durch das RCM erfolgen und die Integration in das Laufzeitsystem des Geräts ist minimal.
Bei der prototypischen Realisierung wurden jedoch Geräte verwendet, die nur eine Kommunikationsschnittstelle
bereitstellen und die auch für die Anwendung zur Verfügung stehen soll. Die Erkennung
und Auswertung der Paketstruktur wurde daher stromorientiert implementiert und in den Treiber der
Kommunikationsschnittstelle integriert. Dadurch können Nachrichten an das RCM aus dem restlichen
Nachrichtenstrom herausgefiltert werden. Die ankommenden Daten werden dazu nach einer speziellen
Signatur überprüft, die anzeigt, dass es sich um ein Paket für das RCM handelt.
4.5.7.2 Ausführung der Operationen
Der nächste Schritt ist die Ausführung der Befehle. Dies muss wiederum mit dem Laufzeitsystem
koordiniert werden. Die Realisierung ist davon abhängig, ob das Laufzeitsystem mehrere nebenläufige
Aktivitätsträger anbietet und von welcher Seite die Interaktion gestartet wurde.
Initiiert der Verwalter die Interaktion, so stellt sie ein asynchrones Ereignis für den verwalteten
Knoten dar. Der Knoten muss auf solche Ereignisse vorbereitet sein, um die Befehle des Verwalters
verarbeiten zu können. Bei der Realisierung hat man verschiedene Möglichkeiten. Die Ausführung
der Operationen kann beispielsweise direkt nach dem Empfangen der Nachricht gestartet werden. Sie
wird dann noch im Kontext der Unterbrechungsbehandlung ausgeführt und der aktive Thread bleibt
unterbrochen. Alternativ kann man auch einen neuen Thread beziehungsweise Task erstellen und diesen
zur Verarbeitung einreihen, sodass er zu einem späteren Zeitpunkt vom regulären Scheduler aktiviert
wird.
Wie bereits in Abschnitt 4.4.2.3 aufgezeigt, hat der zweite Ansatz in Systemen wie TinyOS Vorteile.
TinyOS bietet nur einen Aktivitätsträger, daher wird bei diesem Vorgehen die Operation nicht nebenläufig
zu einer aktiven Aufgabe abgearbeitet. Bietet die Laufzeitunterstützung jedoch die nebenläufige
Abarbeitung von mehreren Aufgaben an, so ist dieser Vorteil nicht unbedingt gegeben. Wird außerdem
eine verdrängende Einplanungsstrategie verwendet, so muss man für eine geeignete Koordinierung
sorgen, sodass keine ungültigen Zwischenzustände der Veränderungen sichtbar werden.
Geht die Interaktion vom verwalteten Gerät aus, so erfolgt sie synchron im Rahmen einer Unterstützungsanforderung.
Der aktuelle Thread ist daher unterbrochen und muss nach erfolgreicher
Unterstützung durch den Verwalter transparent fortgesetzt werden. In Systemen wie TinyOS kann
in diesem Fall die zweite der oben beschriebenen Möglichkeiten nicht angewandt werden. Da nur
ein Aktivitätsträger angeboten wird, könnte die Abarbeitung der Verwaltungsoperationen durch einen
neuen Task erst aktiviert werden, wenn der aktuelle Task beendet wurde. Um diese Verklemmung zu
vermeiden, muss die Abarbeitung entweder direkt im Rahmen der Unterbrechungsbehandlung oder
durch den aktuellen Task selbst durchgeführt werden. Bei Laufzeitsystemen, die mehrere nebenläufige
Ausführungen unterstützen, ist diese Einschränkung nicht gegeben und man hat drei Varianten zur
Auswahl. Abbildung 4.21 stellt diese nebeneinander dar.
4.5.7.3 Speicherbedarf
Im Rahmen der prototypischen Implementierungen zu dieser Arbeit wurde ein RCM für verschiedene
Systeme entwickelt. Tabelle 4.5 zeigt den Speicherbedarf der Beispielimplementierung. Das RCM wird
86