Dynamische Adaption in heterogenen verteilten eingebetteten ...

2 Grundlagen und Techniken
semi-automatisch: Der Entwickler legt die Aufteilung des Programms in Overlays fest. Das Umschalten
der jeweils benötigten Overlays wird jedoch automatisch durchgeführt.
manuell: Der Entwickler muss nicht nur die Aufteilung der Software in Overlays manuell durchführen,
sondern er muss darüber hinaus durch Anweisungen im Code dafür sorgen, dass das richtige
Overlay eingelagert ist, wenn es benötigt wird.
Die automatische Überlagerung kann als Vorläufer der Seitenüberlagerung bei virtuellem Adressraum
(paging) betrachtet werden. Hierbei stößt eine Hardwareeinheit zur Adressumrechnung das Einlagern
von Datenblöcken (Seiten) an, wenn auf Adressen zugegriffen wird, deren Speicherstelle momentan
nicht im physikalischen Speicher repräsentiert ist.
Im Vergleich zur automatischen Seitenüberlagerung, zur Bereitstellung eines virtuellen Adressraums,
hat die Überlagerungstechnik den Vorteil, dass sie ohne zusätzliche Hardwareunterstützung verwendet
werden kann und somit für eingebettete Systeme geeignet ist. Für Echtzeitanwendungen hat die
(manuelle) Überlagerung außerdem den Vorteil, dass der Zeitbedarf für die Bereitstellung des benötigten
Codes deutlich besser vorhergesagt werden kann als bei einer transparenten Seitenüberlagerung im
Rahmen von virtuellem Speicher.
Der Nachteil ist allerdings, dass das Verfahren nicht transparent für den Softwareentwickler ist und
er sich über die Größe der Overlays bewusst werden muss. Auch das Finden einer optimalen Aufteilung
in Overlays ist eine nicht triviale Aufgabe.
Im Rahmen dieser Arbeit wird ein System erstellt, das ähnliche Eigenschaften aufweist wie eine
automatische Überlagerungstechnik. Die Codeblöcke werden allerdings nicht auf dem Gerät gelagert,
sondern bei Bedarf übertragen. Außerdem werden die Codeblöcke durch einen dynamischen Binder
angepasst, sodass sie an beliebigen Adressen eingesetzt werden können.
2.2 Ansätze zur dynamischen Modifikation von Anwendungen
Im Folgenden sollen einige Ansätze zur nachträglichen Veränderung von Code zur Laufzeit vorgestellt
werden. Die meisten Beispiele sind dabei aus dem Umfeld der Sensornetze entnommen, da die Zielplattform
kleine ressourcenbeschränkte Knoten sind. Weitere Systeme, die das dynamische Verändern
von Code zur Laufzeit erlauben, sind zum Beispiel bei Hicks [Hic01] zu finden.
2.2.1 Interpretergestützte Ausführung
Eine Möglichkeit, die Anwendung flexibel zu erstellen, ist die Verwendung einer Sprache, die erst
zur Laufzeit interpretiert wird. Das Vorgehen entspricht dem in Abschnitt 2.1.1.2 beschriebenen
Zwischencode: Eine Anwendung besteht aus einer Reihe von Befehlen, die durch einen Interpreter
gelesen, analysiert und umgesetzt werden. Eine Ausprägung dieses Ansatzes sind Skriptsprachen,
wie sie beispielsweise bei SensorWare [BHS03] eingesetzt werden. Hier werden mobile Agenten, die
für den Einsatz auf PDAs gedacht sind, in einer TCL-ähnlichen Skriptsprache programmiert. Eine
andere Ausprägung sind virtuelle Maschinen, die häufig durch Interpreter realisiert sind. Ein Beispiel
ist MagnetOS [LRW + 05], welches eine verteilte Java Maschine für PDAs bereitstellt. Für Sensornetze
sind die Systeme VM* [KP05b] und Maté [LC02] beispielhaft zu nennen.
Neben der kompakten Darstellung des Codes ist als weiterer Vorteil das relativ einfache Nachladen
eines Programms zur Laufzeit zu nennen. Abhängigkeiten zu anderen Programmmodulen oder zum
Laufzeitsystem werden durch den Interpreter aufgelöst. Der Code wird dabei dem Interpreter in Form
von Daten zur Verfügung gestellt. Speziell bei Harvard-Architekturen sind dabei einige Besonderheiten
12