Dynamische Adaption in heterogenen verteilten eingebetteten ...

2 Grundlagen und Techniken
SOS [HKS + 05], ein Betriebssystem für Sensorknoten, welches das Nachinstallieren und Austauschen
von Programmmodulen zur Laufzeit mithilfe von positionsunabhängigem Code realisiert.
Durch dieses Verfahren kann das Modul im gebundenen Binärcode zum Knoten übertragen und ohne
weitere Vorbereitung an beliebiger Adresse eingesetzt werden. Da die Aufrufe zu dem Modul indirekt
über eine Tabelle ausgeführt werden, ist auch das Austauschen des Programmmoduls einfach, da lediglich
die Adresse in der Tabelle anzupassen ist. Auf der anderen Seite ist die Indirektionsstufe auch ein
Nachteil, da das Auflösen zusätzlich Laufzeit benötigt. Ein weiterer Nachteil ist, dass eine Werkzeugkette
benötigt wird, die positionsunabhängigen Code erstellen kann. Entsprechende Werkzeuge sind
allerdings nicht für alle Plattformen verfügbar. Für die MSP430 Mikrocontroller von Texas Instruments
sind beispielsweise keine Compiler verfügbar, um positionsunabhängigen Code zu erzeugen. Für AVR
Mikrocontroller unterstützt der GCC diese Art der Codeerstellung. Ein Programmmodul kann hier
allerdings maximal 4 KByte groß sein, da das die maximale Entfernung für einen relativen Sprung ist.
2.2.3.2 Vorab-gebundene Programmmodule
Um die Einschränkung von positionsunabhängigem Code zu vermeiden und dennoch die Einbindung
neuer Module möglichst einfach zu gestalten, können Module verwendet werden, die bereits vor der
Übertragung gebunden wurden. Somit ist kein Binden auf dem Knoten erforderlich. Dafür müssen
allerdings Informationen über alle vorhandenen Symbole auf dem externen Rechner vorhanden sein.
Außerdem kann ein so vorbereitetes Modul nur für ein System verwendet werden, welches exakt dem
Aufbau der gegebenen Symbolinformationen entspricht.
Beispiele aus dem Bereich der Sensornetzwerke sind frühe Versionen von Contiki [DGV04]. Teilweise
kann auch der Baukasten für virtuelle Maschinen VM* [KP05b] in diese Kategorie eingeordnet
werden, der die Erweiterung des Interpreters mittels extern gebundenen Modulen ermöglicht.
2.2.3.3 Dynamisch gebundene Programmmodule
Um die Module flexibler einsetzen zu können, kann man das Binden auch erst auf dem Knoten durchführen.
Ein Beispiel hierfür ist FlexCup [MGL + 06], ein im Rahmen des TinyCubus–Projekts [MLM + 05]
entwickeltes Updatesystem für Sensorknoten. Auch bei neueren Versionen von Contiki [DFEV06]
wird auf dynamisches Binden der Module gesetzt.
Der Vorteil des Verfahrens ist, dass die Programmmodule nicht für eine spezielle Speicherbelegung
erstellt werden und somit auf mehreren Knoten eingesetzt werden können, auch wenn sich diese leicht
unterscheiden. Nachteil ist allerdings, dass nicht nur der Binder auf jedem Knoten vorhanden sein muss,
sondern auch die Symbolinformationen. Ebenso müssen neue Symbol- und Relokationsinformationen
mit dem Modul zu jedem Knoten übertragen werden.
2.2.4 Vergleich der Verfahren
In Tabelle 2.1 werden die verschiedenen Ansätze anhand einiger Kriterien miteinander verglichen.
Je weniger Infrastruktur am Knoten benötigt wird, desto mehr Speicherplatz steht für die eigentliche
Software zur Verfügung. Interpreterbasierte Verfahren und dynamisches Binden benötigen beide
umfangreichen Code oder Daten auf dem Knoten. Für das Anwenden von Änderungen ist weniger
Code notwendig. Das Einspielen von exakt vorbereiteten Programmmodulen oder Speicherabbildern
benötigt hingegen am wenigsten Infrastruktur am Knoten.
Betrachtet man die Menge der zu übertragenden Daten, so ist die Übertragung des gesamten
Speicherabbildes das Maximum. Ein guter Wert wird erreicht, wenn nur die veränderten binären
14