Dynamische Adaption in heterogenen verteilten eingebetteten ...

4.5 Aufbau und Architektur
peek- und poke-Operationen vor. In der prototypischen Realisierung für AVR-Mikrocontroller
wurden getrennte Operationen zur Verfügung gestellt. Bei diesen Mikrocontrollern kommt hinzu,
dass der Programmspeicher durch Flashspeicher ausgeführt ist. Dieser kann nur seitenweise gelesen
und beschrieben werden, sodass die peek- und poke-Operationen eine entsprechend abgeänderte
Schnittstelle aufweisen.
Zur Realisierung der Operationen für AVR-Mikrocontroller muss bei der Positionierung des RCMs
berücksichtigt werden, dass der Code zum Verändern des Flashspeichers in einem bestimmten Adressbereich
des Programmspeichers liegen muss. Nur in dieser sogenannten Boot Loader Section [Atm07b]
sind die speziellen Befehle zum Beschreiben des Speichers wirksam.
4.5.6.3 Funktion und Erzeugung von Stellvertretern
Unterstützungsanforderungen werden durch spezielle Codestücke ausgelöst, die durch die Kontrollschicht
an Stellen in den Code eingebunden wurden, an denen eine Umkonfiguration nötig wird, weil
sich beispielsweise die Voraussetzungen für eine Konfiguration ändern. Diese Codestücke stellen die
Stellvertreter bei einem Fernaufruf oder beim Nachinstallieren von Prozeduren dar. Sie können jedoch
auch zusätzlich integriert werden, wenn eine Interaktion mit dem Verwalter notwendig ist.
Die Basisschicht stellt die Infrastruktur zur Verwaltung und Erzeugung dieser Stellvertreter bereit.
Die Erzeugung wird von Stellvertreterfabriken vom Typ StubFactory durchgeführt. Für verschiedene
Arten von Stellvertretern kann es je ein eigenes Fabrikobjekt geben. In der prototypischen
Implementierung wurden zwei Fabriken entwickelt. Eine Fabrik erzeugt Codestücke, die zur allgemeinen
Benachrichtigung und als Stellvertreter bei der bedarfsgesteuerten Installation verwendet werden
können. Diese Stellvertreter senden neben der Unterstützungsanforderung keine weiteren Daten zum
Verwalter. Die andere Fabrik erzeugt Stellvertreter, die für Fernaufrufe optimiert sind. Hier werden
neben der Unterstützungsaufforderung auch die Parameter der aufgerufenen Funktion an den Verwalter
gesendet.
Die generelle Funktionsweise der Fabriken unterscheidet sich nicht. Die Stellvertreter bestehen im
Wesentlichen aus zwei Teilen:
• einem allgemeinen Teil, der nur einmal im System vorhanden sein muss, und
• einem individuellen Teil, der für jeden Einsatz speziell angepasst wird.
Der spezifische Teil enthält eine eindeutige Identifikationsnummer und Parameter, um die Funktion
des allgemeinen Teils zu beeinflussen. Er ruft mit diesen Informationen den allgemeinen Teil auf,
der eine entsprechende Nachricht erstellt und, im Rahmen dessen, die notwendigen Informationen
sammelt. Anschließend greift der allgemeine Teil auf Funktionen des RCMs zurück, um die Nachricht
abzuschicken. Abbildung 4.19 zeigt den Ablauf.
Durch die Aufteilung des Stellvertreters in zwei Teile kann der Speicherbedarf pro Nutzung sehr
gering gehalten werden. Nur der individuelle Teil muss mehrfach vorhanden sein. Er ist allerdings sehr
klein, da er nur die unbedingt notwendigen Register sichert und mit den spezifischen Werten füllt. Dann
springt er sofort zu einem gemeinsam genutzten Codestück, welches die restlichen Registerinhalte
sichert und das RCM aufruft. Tabelle 4.4 zeigt den Speicherbedarf der beiden Stellvertreter für
verschiedene Architekturen.
Zur Erzeugung eines konkreten Stellvertreters lädt die Fabrik die beiden Teile für die jeweils
benötigte Architektur. Für den allgemeinen Teil des Stellvertreters muss die Fabrik nur sicherstellen,
dass er installiert wird, sobald ein Stellvertreter dieses Typs verwendet wird. Für den individuellen Teil
stellt das geladene Modul eine Vorlage dar, welche Platzhalter für die spezifischen Daten enthält. Die
83