Dynamische Adaption in heterogenen verteilten eingebetteten ...

2.2 Ansätze zur dynamischen Modifikation von Anwendungen
zu beachten: Wird der Programmcode im Programmspeicher abgelegt, so müssen die Anweisungen
vor der Verarbeitung zunächst in den Datenspeicher kopiert werden. Legt man das Programm hingegen
im Datenspeicher ab, so ist zu bedenken, dass dieser bei solchen Systemen oft deutlich knapper als
Programmspeicher ausfällt. Allerdings hat man dann den Vorteil, dass die Veränderungen nicht am Programmspeicher
vorgenommen werden müssen, dessen Beschreiben, im Gegensatz zum Datenspeicher,
oft aufwendiger ist.
Generelle Nachteile dieses Ansatzes wurden bereits genannt: der zusätzliche Speicherverbrauch
und die reduzierte Ausführungsgeschwindigkeit. Hinzu kommt noch, dass dieser Ansatz auf die
Veränderung der Anwendung beschränkt ist. Grundlegende Systemkomponenten oder der Interpreter
selbst können nicht verändert werden.
2.2.2 Verändern des Speicherabbildes als Ganzes
Will man nicht auf eine Skriptsprache oder interpretierten Zwischencode setzen, so kann man den
Binärcode auch direkt verändern oder austauschen. Im Bereich von kleinen Knoten gibt es dabei
zunächst die Möglichkeit, das Speicherabbild eines Knotens als eine Einheit zu betrachten und durch
ein neues zu ersetzen. Dieser Ansatz wird beispielsweise bei TinyOS [HSW + 00] angeboten. Dort gibt
es mit Xnp [Cro03, JKB03] und Deluge [HC04] zwei ähnliche Systeme, die ein komplettes Speicherabbild
übertragen und installieren. Vorteil dabei ist, dass auch grundlegende Teile des Betriebssystems
verändert werden können. Nachteil ist, dass auch für kleine Änderungen immer das gesamte Speicherabbild
übertragen und neu geschrieben werden muss. Um die Menge der zu übertragenden Daten zu
reduzieren, können auch nur die Änderungen übertragen werden, die zuvor aus einem Vergleich des
ursprünglichen und des neuen Abbildes extrahiert werden [RL03, JC04]. Meist muss dazu allerdings
das ursprüngliche Abbild vorliegen. Da das Speicherabbild auf dem Sensorknoten oft in Flashspeicher
geschrieben werden muss, gibt es auch Ansätze, die Änderungen so anzuordnen, dass möglichst wenige
Seiten von Änderungen betroffen sind [KP05a].
Keines der genannten Systeme ist in der Lage den Zustand des Knotens über eine Änderung hinweg
zu erhalten. Bei allen Systemen ist ein Neustart des Sensorknotens nach der Veränderung vorgesehen.
2.2.3 Austauschen von binären Programmmodulen
Um den Zustand teilweise zu erhalten, bietet es sich an, nicht den gesamten Speicher als Einheit
anzusehen, sondern kleinere Programmmodule auszutauschen beziehungsweise zu verändern. Bei der
Integration der Programmmodule in das bestehende System gibt es verschiedene Ansätze.
2.2.3.1 Positionsunabhängiger Code und indirekte Adressierung
Positionsunabhängiger Code (Position Independent Code, PIC) zeichnet sich dadurch aus, dass er keine
festen Adressen enthält und somit an beliebige Positionen im Speicher geladen und verwendet werden
kann. Sprünge innerhalb des Codes werden durch relative Sprünge realisiert. Die Anbindung an das
existierende System kann zum Beispiel über eine Tabelle mit Einsprungadressen realisiert werden.
Im Code wird dann anstelle der Adresse nur der Index in die Tabelle verwendet. Allerdings muss die
Tabelle an einer festen Position stehen. Auch der Zugriff auf globale Variablen muss über eine Tabelle
erfolgen, da ihre relative Position ebenfalls nicht konstant ist.
Positionsunabhängiger Code kommt häufig bei gemeinsam genutzten Bibliotheken zum Einsatz,
da sie in mehreren Prozessen an verschiedene Adressen gebunden werden. Ein anderes Beispiel ist
13