Dynamische Adaption in heterogenen verteilten eingebetteten ...

2.2 Ansätze zur dynamischen Modifikation von Anwendungen
interpretiert
alles tauschen
nur Änderungen
pos. unabh. (PIC)
vorab-gebunden
dyn. gebunden
geringe Infrastruktur am Knoten - - + - 0 + - -
geringe Übertragungsmenge ++ - - + + + -
geringer Aufwand am Knoten + + - 0 + -
Flexibilität der Modulverwendung + 0 - + - +
geringe Mehrkosten zur Laufzeit - - + + 0 + +
feine Granularität + - - 0 + + +
Tabelle 2.1: Vergleich der Verfahren zum Codeupdate
Daten übertragen werden. Nur bei der Übertragung von speziellem interpretierten Code können unter
Umständen noch bessere Werte erreicht werden. Beim dynamischen Binden ist zu beachten, dass neben
dem Code zusätzlich Symbol- und Relokationsinformationen am Knoten benötigt werden.
Der Aufwand, um die Änderung auf dem Knoten einzuspielen, ist besonders gering, wenn der Code
schon von einem externen Rechner vorbereitet wurde. In diesem Fall müssen weder Tabellen angepasst,
noch Code gebunden werden.
Bei der Flexibilität wird betrachtet, wie gut man die Methode für die Veränderung mehrerer Knoten
einsetzen kann. Enthält der übertragene Code keinen Bezug zur aktuellen Speicherbelegung, so kann er
für verschiedene Knoten verwendet werden, ansonsten kann das Programm nur für genau einen Knoten
angewandt werden.
Beim Aufwand zur Laufzeit sticht besonders die Interpretation hervor, da der Code analysiert und
umgesetzt werden muss. Alle anderen Verfahren haben kaum oder keinen zusätzlichen Mehraufwand
zur Laufzeit.
In der Granularität der Veränderung ist der Hauptunterschied, ob man den gesamten Speicher
betrachtet oder einzelne Programmteile verändern kann.
2.2.5 Zustandsanpassung
Die bisher vorgestellten Techniken beschäftigen sich hauptsächlich mit dem Verändern von Code. Der
Laufzeitzustand wurde dabei kaum beachtet. Bei den meisten beispielhaft angesprochenen Systemen
bleibt der Zustand bei einer Veränderung auch nicht erhalten. Das System wird nach der Veränderung
neu gestartet, um ungültige Zeiger zu eliminieren. Lediglich Contiki [DGV04] bietet die Möglichkeit
an, dass die alte Version eines Programmmoduls seinen Zustand sichert, sodass er von der neuen
Version verwendet werden kann. Die Anpassung des Zustands bleibt der Anwendung überlassen.
Will man ungültige Referenzen vermeiden, müssen entweder genügend Informationen zur Verfügung
stehen, um alle Referenzen zu kennen oder man führt eine Indirektionsstufe ein. Wie bereits vom positionsunabhängigen
Code bekannt, werden dann Aufrufe beispielsweise über eine Tabelle durchgeführt,
die einen Bezeichner auf eine Adresse abbildet [BHA + 05]. Die Anpassung anderer Werte des Zustands
kann im Allgemeinen nicht automatisch erfolgen, da die Bedeutung der einzelnen Elemente unbekannt
ist. Unterstützung kann das System nur bei der Erstellung von Sicherungspunkten bieten.
15