High Level Architecture (HLA)

Der CORBA-Ansatz ermöglicht Simulationssysteme zu starten und den Austausch von Da-ten zu verwalDa-ten. Eine zeitliche Synchronisation der Simulationssysteme kann nicht stattfin-den, ist aber notwendig. Die High Level Architecture (HLA) vom Amerikanischen Verteidi-gungsministerium stellt hierfür Mechanismen zur Verfügung. HLA ist eine Schnittstellenbeschreibungssprache und Architektur für die Koordination verteilter Simulationsanwendungen /21/, /22/, /23/. Das Ziel ist die Wiederverwendbarkeit und Interoperabilität von Simulationsmodellen, Simulationssystemen und Programmen.

Die militärische Herkunft zeigt sich in den verwendeten Begriffen. So sind Federates Teilnehmer an einem gemeinsamen Simulationslauf der sogenannten Federation. Die Federation stellt das gemeinsame vertragliche Dach dar, das bestimmt, was jeder Teilnehmer zur Simulation beiträgt und was er von anderen erwarten kann. Diese für die Federation relevanten Daten sind Objekte gemäß der objektorientierten Methodik.

HLA besteht aus drei Bestandteilen:

• Der Run Time Infrastructure (RTI), welches ein Kommunikationssystem ist, das Koordi-nationsdienste über Internet den Federates zur Verfügung stellt, durch die das Zusam-menspiel und das Verhalten der gesamten verteilten Simulation (Federation) und der Teilnehmer (Federates) gelenkt werden kann,

• einer Schnittstellenspezifikation, welche die Schnittstellen zwischen den Federates und der Runtime Infrastructure (RTI) definiert,

• dem Object Model Template (OMT), das Standards zur Dokumentation von Federations und Federates vorsieht /93/.

In HLA erfolgt eine Trennung zwischen Simulationsfunktionalität des Federates und der Interoperabilität. Das bedeutet, daß sich Federates nicht um die zeitliche Synchronisation und die Implementierung des Nachrichtenaustausches kümmern müssen. Die Infrastruktur, die die hierfür notwendigen Dienste zur Verfügung stellt, ist die Run-Time-Infrastructure (RTI). Bild 26 zeigt die Architektur und die den Federates zur Verfügung gestellten Dienste.

Federates sind eigenständige Simulationssysteme, die Nachrichten über ihre Objekte wie Lkw, Gabelstabler und Puffer auf der Run-Time-Infrastructure austauschen. Beispielsweise könnten der Gabelstabler und der Puffer zum Federate „Montage“ und der Lkw zum Federate „Transport“ gehören (siehe Bild 16).

Das Serverprogramm, das im Hintergrund abläuft, wird RTIExec genannt. Bei diesem Pro-gramm melden sich die Federates an und erfahren, auf welchem Rechner das

FedEx-Inhaltsverzeichnis

51

-tung des Datenaustausches zwischen den Federates derselben Federation obliegt. Hierfür stehen folgende Dienste zur Verfügung:

• Federation Management: Hier stehen grundlegende Funktionen zum Erzeugen und Ent-fernen des FedEx-Prozesses sowie zum Aus- und Eintritt von Federates bereit. Zudem werden Funktionen zum Anhalten, Speichern, und Wiederherstellen des Federation-Zustandes definiert.

• Declaration Management: Hierzu gehören Aufgaben, wie das Bekanntgeben der Klas-sen wie z. B. Lkw oder Gabelstapler, zu denen ein Federate etwas beitragen kann oder das Abonnieren der Klassen, über die ein Federate informiert werden möchte.

• Object Management: Aufgabe ist es, Objekte und deren Eigenschaften zwischen den Federates auszutauschen. Die zeitliche Ordnung der Interaktionen wird verwaltet.

• Ownership Management: Federates dürfen nur Attribute der eigenen Objekte verän-dern. Es sei denn, sie einigen sich über diese Rechte. Das gehört zu den Aufgaben des Ownership Managements.

Entladezone

Puffer Entnehmen(Material) Puffern(Material) Lkw

Entladen(Material) Beladen(Material)

FahreZu(Entladezone) Gabelstapler

Entladen(Material) Beladen(Material) FahreZu(Entladezone)

Kommunikationssystem: HLA E1:

Ort = Entladezone

E1 Ankunft Lkw Ereignisse

RTIexec FEDex

Ort Material

E1:

Ort = Entladezone Federation

Dienste: Federation Management, Object Management, Time Management, Declaration Management, Ownership Management und Data Distribution Management

Nachricht (Attribut „Ort“ verändert) Bild 26: Run Time Infrastructure (RTI)

Kommunikationssysteme

Bild 27 gibt einen Überblick über die Abfolge der Funktionen für die Zusammenarbeit ver-schiedener Simulationssysteme. Beispielhaft soll das Simulationssystem „Transport“ be-trachtet werden, welches das Simulationssystem „Montage“ über die Ankunft eines Lkws informiert. Hierfür erfolgt zunächst das Eintreten in eine Federation durch die Methoden

„create“ und „join“ des Botschafter-Objektes der Federation. Simulationssystem und Fede-ration kommunizieren über sogenannte Botschafter-Objekte. Im zeigt die Pfeilrichtung an, welches Botschafter-Objekt gemeint ist. Ein Pfeil in Richtung Federation bedeutet einen Aufruf der Methode des Botschafter-Objekts des Federation, ein Pfeil in anderer Richtung ein Aufruf der Methode des Botschafter-Objekts des Simulationssystems.

Ein wichtiger Teil der Schnittstellen sind die Beschreibung der Eigenschaften der Objekte.

Ein Objekt, das zur Schnittstelle gehört, kann als ein Sender angesehen werden, der Nachrichten über seine Eigenschaften an alle sendet, die daran interessiert sind. Ein

Transport Federation

Erzeugen „Materialversorgung“ (create) Eintreten (join)

Erzeugen und Anmelden der Lkw-Objekte (register)

Veröffentlichen der Lkw-Klasse (publish)

Verfolgen der Änderungen (send, update and reflect) Austausch der Attributrechte

(attribute ownership) Zerstören der Objekte (delete, remove) Beginn des shutdowns

Abmelden (resign)

Entfernen des Federates (remove)

Abonnieren von Klassen, z. B.: Lkw oder Material anderer Simulationssysteme

(subscribe, discover)

Inhaltsverzeichnis

53

-Simulationssystem gibt solche Objekte der Federation durch die Methoden „publish“ und register“ bekannt. Im Beispiel erfolgt die Bekanntgabe des Lkw-Objekts (siehe auch Bild 26) durch das Simulationssystem „Transport“. Ein Simulationssystem, das über Veränderungen eines Objekts wie z. B. des Lkw-Objekts informiert werden möchte, meldet dieses Interesse durch die Methode „subscribe“ bei der Federation an und wird durch „discover“ über die Objekte andere Simulationssysteme bzw. durch „send“, „update“ und „reflect“ über die Attributwerte der Objekte informiert. Weitere Methoden stehen zum Verlassen einer Federation zur Verfügung. Neben einer solchen 1-zu-n Kommunikation stehen den Simulationssystemen auch eine direkte Kommunikation über Nachrichten zur Verfügung.

Ein grundlegender Unterschied zu CORBA ist dementsprechend, daß Interaktionen zwischen den Objekten als Nachrichten und nicht als Methodenaufrufe verstanden werden.

Nachrichten zeigen Veränderungen in den Werten der Eigenschaften der Objekte bespielsweise des Lkw-Objektes an.

Eine Hauptaufgabe ist die zeitliche Koordination der Zusammenarbeit unterschiedlicher Federates im Time Management. Dieses Zeitmanagement ist Voraussetzung für die Interoperabilität zwischen Simulationssystemen, da es durchaus darauf ankommt, zeitsynchron zu laufen. HLA läßt es jedem Federate offen, wie er am Zeitmanagement der Federation teilnimmt. Hierzu gibt es zwei grundlegende Schalter. Möchte das Federate aktive sich an der Zeitermittlung beteiligen, ist der Schalter (time regulating) zu setzen.

Dadurch wird der Federate in die Lage versetzt, Ereignisse mit Zeitmarken zu erzeugen.

Zur Unterordnung in die Regie zum Zeitfortschritt ist der Schalter (time constraint) verantwortlich. Ist dieser Schalter gesetzt, muß der Federate den Zeitfortschritt bei der Federation beantragen. Bild 28 zeigt die Abfolge von Schritten zur Synchronisation mit Hilfe der ereignisorientierten Vorgehensweise. Zunächst ermitteln beide Simulationssysteme, Montage und Transport, das nächste lokale Ereignis. So beantragt die Montage einen Zeitfortschritt zum Ereignis E10 und der Transport zum Ereignis E7. Daraufhin wird von HLA das nächste zu verarbeitende Ereignis anhand der Zeitmarke festgelegt und den Simulationssystemen der Zeitfortschritt zum nächsten Ereignis E7 mitgeteilt. Nach der Verarbeitung des Ereignisses beginnt die geschilderte Prozedur von neuem.

Kommunikationssysteme

3.2.3 Agentenbasierte Systeme