Dynamische Adaption in heterogenen verteilten eingebetteten ...

4 Basisschicht eines Verwalters
Abbildung 4.18: Klassendiagramm des Kommunikationssystems
In dem vereinfachten Klassendiagramm erkennt man die Dreiteilung in DeviceStub, CommSys und DeviceLink.
DeviceStub stellt die Schnittstelle für die anderen Komponenten zur Verfügung. Neben der allgemeinen Version
gibt es noch eine erweiterte Schnittstelle (DeviceStubPaged), welche seitenbasierte Zugriffe auf den Speicher
anbietet, um Zugriffe auf Mikrocontroller mit Flashspeicher zu optimieren. Zur Übertragung wird ein CommSys-Objekt
verwendet, welches hauptsächlich das Übertragungsprotokoll abwickelt und zur Kommunikation auf ein DeviceLink-
Objekt zurückgreift. Die Byteordnung von Adressen, die während der Kommunikation ausgetauscht werden, passt ein
CommHelper-Objekt an.
Speichers (Dual-Ported-RAM) unterstützen, indem die Speicherzugriffe direkt umgesetzt werden oder
man entsprechende Kommandos erzeugt und über eine festgelegte Speicherstelle austauscht.
Das Gegenstück zum DeviceStub des Verwalters ist das Fernwartungsmodul (Remote Configuration
Module, RCM) auf dem verwalteten Gerät. Das RCM muss immer auf dem Knoten installiert
sein und ist normalerweise Teil des initialen Moduls. Es stellt den Kommunikationsendpunkt dar und
empfängt und verarbeitet die Anfragen des Verwalters. Dazu implementiert es ebenfalls das oben
beschriebene Kommunikationsprotokoll. Zum Zugriff auf das Kommunikationsmedium und zur Ausführung
der Befehle ist das RCM in das Laufzeitsystem integriert. Der Aufbau des RCMs ist daher
vom verwendeten Laufzeitsystem abhängig und wird in Abschnitt 4.5.7 diskutiert.
4.5.6.2 Befehle an einen verwalteten Knoten
Die Befehle, die ein RCM bearbeiten muss, sind sehr einfach gehalten. Zu den grundlegenden Operationen
gehört das Auslesen (peek) und Beschreiben (poke) von Speicherstellen sowie das Fortsetzen
der Ausführung auf dem Knoten nach einer Unterstützungsanforderung (resume). Daneben können
noch geräte- oder laufzeitsystemspezifische Befehle angeboten werden, die oft zur Optimierung der
Vorgänge dienen.
Mithilfe der peek- und poke-Operationen kann der Verwalter den Zustand des Knotens auslesen
und Daten installieren. Um den Zustand des Knotens vollständig erfassen zu können, benötigt der
Verwalter zum Teil auch den Inhalt einiger Register. Auf einigen Architekturen, wie beispielsweise
den AVR-Mikrocontrollern, sind alle Register in den Speicher eingeblendet und können somit über
die peek-Operation abgefragt werden. Bei anderen Architekturen ist eine zusätzliche Operation dafür
notwendig 11 .
Bei Harvard-Architekturen muss die Möglichkeit bestehen, auf die verschiedenen Adressräume
zuzugreifen. Hierzu kann man den Adressraum in der Adresse codieren 12 oder man sieht getrennte
11 Bei x86- und H8/300-Architekturen ist beispielsweise eine zusätzliche Operation GetBasePointer realisiert, die den
Inhalt des Registers EBP beziehungsweise r6 zurückliefert.
12 Zur Codierung des Adressraumtyps kann man Bits verwenden, welche außerhalb des gültigen Adressbereichs liegen. Ein
gesetztes Bit bedeutet beispielsweise, dass es sich um eine Adresse im Programmspeicher handelt.
82