Steffen Straßburger, Ulrich Klein

Institut für Simulation und Graphik

Fakultät für Informatik

Otto-von-Guericke-Universität Magdeburg

email:{strassbu@sunpool, uklein@isg}.cs.uni-magdeburg.de

Die verteilte Simulation erhält derzeit einen starken Impuls durch die High Level Architecture, welche die Erstellung interoperabler und wiederverwendbarer Module für verteilte Systeme unterstützt, die nicht notwendigerweise nur Simulationskomponenten enthalten müssen. Um die Simulations- und Animationswerkzeuge, die sich im zivilen Bereich bewährt haben, zur Erstellung HLA-kompatibler Modelle nutzen zu können, ist eine geeignete Erweiterung notwendig. Der Beitrag beschreibt die Anforderungen der High Level Architecture an Simulations- und Animationstools, geht auf die erfolgreiche Integration des Simulationssystems SLX ein und behandelt die Übertragbarkeit des Integrationsverfahrens auf andere Tools.

Obwohl die High Level Architecture for Modeling and Simulation (HLA) des amerikanischen Department of Defense (U.S. DoD) als recht junge Technologie noch einige Probleme in sich birgt, die auf ihre kurze Entwicklungszeit zurückzuführen sind, kann sie als zukünftiger Standard auf dem Gebiet der verteilten Simulation angesehen werden. Sie vereint verschiedene Vorgängerkonzepte aus dem militärischen Bereich (z.B. DIS, ALSP) und bietet eine Architektur, die offen für eine Vielfalt von Anwendungsgebieten gerade auch im zivilen Bereich ist. Das Hauptanliegen der High Level Architecture ist die Unterstützung der Wiederverwendbarkeit von Modellen und vor allem der Interoperabilität von Simulations- und Animationstools. Im Gegensatz zu anderen Technologien aus der verteilten Simulation, die vor allem eine bestmögliche Parallelisierung von Prozessen als Zielstellung haben (z.B. PVM, MPI), ist ihr Hauptanliegen somit nicht die Effizienzsteigerung.

Die HLA bietet eine Reihe neuer Ansätze, die Forderungen nach Wiederverwendbarkeit und Interoperabilität von Simulationsmodellen umzusetzen und die Schwierigkeiten mit monolithischen Modellen bei Änderungen der Funktionalität oder Konnektivität zu umgehen [2].

HLA definiert eine einheitliche Schnittstelle (HLA Interface), welche die Teilnehmer eines gemeinsamen Simulationslaufs (Federates) aufzuweisen haben, um in Kontakt mit der Runtime Infrastructure (RTI) zu treten, welche Basis-, Koordinations- und Kommunikationsdienste zur Laufzeit bereitstellt; Kommunikation findet lediglich zwischen Federate und RTI, nicht zwischen den Federates statt.. Eine Federation kann als ein Vertrag zur Durchführung eines Simulationslaufes (Federation Execution) zwischen den Federates angesehen werden, in dem die Einzelheiten und Objektmodelle der Federates (Simulation Object Model, SOM) und der Federation (Federation Object Model, FOM) festgelegt sind. Diese Informationen sind in einer definierten Form zu dokumentieren (Object Model Template, OMT). Weiterhin legt HLA zwingende Verhaltensregeln für Federates und Federations fest.

Ein Vorteil der Architektur ist die Offenheit für andere Arten von Federates; sowohl Softwarebausteine wie z.B. Datenbanken und Beobachter als auch reale Elemente wie Sensoren und andere Hardware können bei Einhaltung der HLA-Spielregeln bei Federation Executions mitwirken (Bild 1 aus [4]).

Ebenso wird ein transparentes Zeitmanagement unterstützt, welches den Federates außer der Koordinierbarkeit keine Vorschriften bzgl. des lokalen Zeitfortschritts (z.B. Zeitschritt-, Ereignis-, Echtzeitsimulation) macht. Durch die Wahl von Reihenfolge (receive_order bzw. time stamp order) und Zuverlässigkeit (reliable bzw. best_effort) der Ereignis- bzw. Nachrichtenübermittlung sowie der Charakterisierung des zeitlichen Verhaltens bzw. der zeitlichen Anforderungen jedes Federates (time_constrained, falls der lokale Zeitfortschritt durch den Zeitfortschritt anderer Federates beschränkt wird und time_regulating, falls der lokale Zeitfortschritt denjenigen der anderen Federates beeinflußt) ist es möglich, innerhalb einer Federation verschiedene Zeitregime und Synchronisationsprotokolle (konservative und optimistische) nebeneinander zu betreiben.

Eine andere wesentliche Neuerung betrifft den Umfang der notwendigen Kommunikation zwischen den Federates, der auf Basis früherer Protokolle aufgrund ungünstigen Netzlastverhaltens nur Systeme bis zu einer bestimmten Größenordnung zuließ. Die HLA erlaubt auf Basis eines publish/subscribe-Paradigmas (Declaration Management) den Federates die Spezifikation der interessierenden, von anderen Federates modellierten Objektklassen(attribute) (Abonnement per subscribe) sowie die selbst veröffentlichten Objektklassen(attribute) (Publikation per publish). Die eigentliche Neuerung enthält das Data Distribution Management, welches diese Spezifikation auf den Wertebereich der Objektattribute ausdehnt, die einen mehrdimensionalen Merkmalsraum aufspannen, in denen Regionen definiert werden können; lediglich für überlappende publish- und subscribe-Regionen findet dann ein tatsächlicher Datenaustausch statt. Somit müssen z.B. nicht alle Objekte eines Typs berücksichtigt werden, da eine Einschränkung auf die sichtbaren Objekte möglich ist. Die Leistungsfähigkeit und Überlegenheit dieses neuen Konzeptes wurde bereits bei einer militärischen Großübung (Synthetic Theatre of War STOW 1997) unter Beweis gestellt.

Die RTI-Software setzt intern auf TCP/IP auf und ermöglicht damit eine umfassende Flexibilität von der Verteilung der Federates bis hin zur Wahl des Kommunikationsmediums.

Die meisten der bis zum jetzigen Zeitpunkt durch die Entwickler von HLA, dem Defense Modeling and Simulation Office (DMSO), veröffentlichten Beispiel-HLA-Anwendungen wurden in der Programmiersprache C++ verfaßt. Obwohl vielfältige Bibliotheken zur Simulation direkt in C++ zur Verfügung stehen, ist es für einen an den Komfort von Simulationstools (bzw. Simulationssprachen) gewöhnten Simulationsentwickler als eher hinderlich zu betrachten, eine Simulation in C++ zu programmieren, nur um an einer verteilten Simulation in Stil von HLA-Federations teilnehmen zu können. Daher wurden von den Autoren die Möglichkeiten untersucht, klassische stand-alone Simulationstools in die High Level Architecture zu integrieren [4]. Die Arbeit beschränkt sich zur Zeit auf diskrete ereignisgesteuerte Tools, eine Erweiterung auf kontinuierliche Simulatoren und Sprachen (z.B. ACSL, Modelica) ist im Gespräch. Der Hauptteil des Vortrags soll exemplarisch am Beispiel von SLX, einem neuen Simulationstool [3] für Windows 95/NT-Betriebssysteme, demonstrieren, was zur Integration eines Simulators in die HLA notwendig ist, welche Anforderungen der Simulator erfüllen muß und wie die konkrete programmierungstechnische Umsetzung für SLX aussieht.

Für die Integration eines Tools als Federate in die High Level Architecture ist ein bestimmtes Programmierparadigma einzuhalten. Ein Federate kommuniziert mit der Runtime Infrastructure, welche die Dienste zur Kommunikation und Synchronisation bereitstellt, über einen sogenannten RTI-Botschafter. Konkret heißt dies, daß zur Kommunikation Methoden eines RTI-Botschafterobjektes aufgerufen werden müssen. Dieser RTI-Botschafter wird mit der RTI-Software als Teil einer Bibliothek bereitgestellt. Für die Windows-Betriebssysteme ist dies eine Dynamic Link Library, deren Funktionen zur Laufzeit aufgerufen werden.

Im Gegenzug kommuniziert die Runtime Infrastructure mit einem Federate über dessen Federate-Botschafter. Abbildung 2 veranschaulicht dieses Kommunikationsparadigma.

Der Federate-Botschafter ist vom Federate zu implementieren; eine Aufgabe, für die verschiedene Tools nicht geeignet sind [2]. Die Implementierung des Federate-Botschafters erfordert vom Federate insbesondere die Möglichkeit des Aufrufens von Rückruffunktionen (Callbacks) beim Simulator. Für Tools, bei denen eine solche direkte Kopplung nicht möglich ist, können verschiedene Gateway-Lösungen in Betracht gezogen werden. Bei einer solchen Lösung erfolgt die Kopplung nicht innerhalb des Kontrollflusses eines Programms, sondern über andere Mittel des Betriebssystems wie z.B. Dateien, Pipes oder Netzwerk- bzw. Socketverbindungen. Tool und Gateway stellen hier zwei getrennte Einheiten dar, die noch nicht einmal auf dem gleichen Rechner existieren müssen. Eigentliches Mitglied bzw. Federate in einer HLA-Federation wird das Gateway-Programm. Dieses hat dann praktisch eine Stellvertreter- oder Übersetzerrolle, da es mit der RTI und mit dem anzubindenden Tool in einer für den jeweiligen Partner verständlichen Form kommuniziert. Ein Beispiel für eine derartige Ankopplung von sogenannten Legacy-Applikationen ist das DIS/HLA-Gateway des Institute for Simulation and Training (IST) [1].

Ferner findet die Teilnahme an einer verteilten Simulation Niederschlag in der Notwendigkeit, einen lokalen Zeitfortschritt bei der RTI beantragen zu müssen. Dies versetzt die RTI in die Lage, den zulässigen, die Kausalität nicht mehr störbaren Datenaustausch zu ermitteln und durchzuführen, um anschließend die Erlaubnis zum Fortschreiten auf die beantragte Zeit bzw. der Zeit eines zu berücksichtigenden Ereignisses zu erlauben. Diese hauptsächlich bei der Formulierung des Simulationsmodells zu berücksichtende Tatsache setzt voraus, daß die Abarbeitung der lokalen Ereignislisten geeignet beeinflußt werden kann.

Der Simulator SLX verfügt über eine offene Softwarearchitektur. Sein Funktionsumfang läßt sich beinahe beliebig durch die Möglichkeit, Funktionen von Dynamic Link Libraries aufrufen zu können, erweitern. Diese Möglichkeit bildete die Grundvoraussetzung zur Ankopplung von SLX an die Runtime Infrastructure.

SLX hat eine C-ähnliche Syntax, wobei der Sprachumfang um vielfältige Konstrukte zur Unterstützung von prozeßorientierter Simulation erweitert wurde.

Da sich die in SLX verfügbaren Datentypen von den von der RTI-Software bereitgestellten Datentypen teilweise beachtlich unterscheiden (SLX implementiert ein teilweise modifiziertes Subset der in C/C++ verfügbaren Datentypen) und außerdem die Möglichkeit des Programmierens von Rückruffunktionen in SLX nur für den Toolhersteller Wolverine Software selbst möglich ist, kam für die Ankopplung von SLX an die RTI nur die Möglichkeit einer Wrapper-DLL in Frage (siehe Abbildung 3) [5].

Die entwickelte Wrapper-DLL mußte in einer Mischung aus reinem C und C++ implementiert werden. Der in C geschriebene Teil beinhaltet die eigentliche "Wrapper"-Funktionalität, d.h. die von SLX aufzurufenden C++-Funktionen (oder genauer Methoden des RTI-Botschafterobjektes) werden durch normale C-Funktionen "umhüllt", so daß sie von SLX aufgerufen werden können. Dies ist nötig, da SLX nicht in der Lage ist, C++-Objekte zu instanziieren und dann deren Methoden aufzurufen. Der in C++ geschriebene Teil der Bibliothek enthält die Funktionalität des vom Federate bereitzustellenden Federate-Botschafters.

Dieser Lösungsansatz ist durchaus als direkte Kopplung des Simulators an die RTI anzusehen, da die Kopplung im Gegensatz zu gewöhnlichen Gateway-Lösungen innerhalb des Kontrollflusses eines Programms erfolgt.

Die Kommunikation von SLX mit der RTI erfolgt über zwei Stufen, da SLX zuerst, wie oben erwähnt, eine C-Funktion aufruft, welche dann ihrerseits die entsprechende C++-Methode des RTI-Ambassadors ruft. Die Umsetzung der C++-Methoden in C-Funktionen erfolgte nahezu in einer 1:1 Abbildung gemäß der HLA Interface Specification [4], es werden jedoch teilweise Vereinfachungen, die nur im Sinne des SLX-Nutzers sein können, vorgenommen. So werden beispielsweise Funktionen, die von SLX immer im Zusammenhang gerufen werden müssen, zu einer Funktion zusammengefaßt. Alternativ wird jedoch auch die Möglichkeit gewährt, jede Methode des RTI-Botschafters einzeln aufzurufen.

Die Bibliothek übernimmt außerdem eine Umwandlung der SLX-Datentypen in RTI-Typen und Handles. So gibt der SLX-Nutzer beispielsweise zur Publikation eines Objektes den reinen ASCII-Namen des Objektes an. Dieser wird dann von der entsprechenden Wrapper-Funktion in ein RTI-Handle umgerechnet. Da das für den Nutzer völlig transparent geschieht, wird ihm dadurch erheblich die anderweitig wesentlich kompliziertere Programmierarbeit mit der Runtime Infrastructure erleichtert. Für die Wrapper-Bibliothek besteht die Notwendigkeit, aus der jeweiligen SLX-Datendarstellung die von der RTI-Bibliothek erwartete Datendarstellung zu ermitteln. Die ist in den Fällen mit Risiken verbunden, in denen die SLX-Typen in ihrer Bytegrößen von denen im Federation Object Model (FOM) vereinbarten abweichen. SLX kennt z.B. für Gleitkommazahlen lediglich 8 Byte Double-Werte. Dies kann bei einer vom FOM geforderten Standardlänge des Float-Types von 4 Byte zu Informationsverlusten führen.

Der umgekehrte Kommunikationsweg erfolgt ebenfalls zweistufig: Von der Runtime Infrastructure (konkret: der RTI-Bibliothek) erfolgen Funktionsaufrufe beim Federate-Botschafter, der von der SLX-RTI-Bibliothek implementiert wird. Dies geschieht durch Vererbung der Methoden eines abstrakten Federate-Botschafterobjektes, welches in der RTI-Bibliothek bereitgestellt wird. Der Federate-Botschafter ist für das Empfangen von jeder Art von Nachrichten verantwortlich. Der Prozeß des "Empfangens" erfolgt durch die bereits erwähnten und in der HLA Interface Specification festgelegten Rückruffunktionen. Als typische Nachrichten seien hier Attribut-Updates und Interaktionsnachrichten sowie Nachrichten über das Gewähren des lokalen Zeitfortschritts genannt.

Dieser Federate-Botschafter gibt die ihm durch die Funktionsaufrufe übermittelten Informationen über gemeinsame Speicherbereiche an den Simulator SLX weiter. Diese Lösung wurde als die effektivste betrachtet, da SLX in der jetzigen Version nicht die Möglichkeit des Aufrufens von selbstgeschriebenen Rückruffunktionen bietet. Es besteht nur die Möglichkeit, vom SLX-Hersteller definierte Rückruffunktionen aufzurufen (z.B. um SLX mitzuteilen, daß Kontrollvariable von außen geändert wurden); die Möglichkeit solche Funktionen selbst zu schreiben wurde für eine spätere SLX-Version in Aussicht gestellt.

Die zur Kommunikation genutzten gemeinsamen Speicherbereiche lassen sich in einen statischen und in mehrere dynamische, die modellabhängig definiert werden können, aufteilen.

Gemeinsame statische Speicherbereiche

Der statische Bereich ist ein für alle HLA-konformen SLX-Modelle gleicher Bereich, über den der Federate-Botschafter Statusänderungen an SLX weiterleitet. Dieser statische Bereich wird als ein SLX-Objekt mit fester Struktur definiert. Zu Beginn einer Simulation teilt das SLX-Programm der Bibliothek den Ort des Objektes im Speicher mit. Somit ist von beiden Programmteilen (SLX und Bibliothek) ein Zugriff auf das Objekt möglich. Da es mittels des SLX-Features "Write DLL Header File" möglich ist, die konkrete Datenstruktur eines SLX-Objektes offenzulegen, kennt die Bibliothek die Struktur des Objektes zur Compile-Zeit und kann Änderungen sehr einfach vornehmen.

Um direkt externe Änderungen von Objektattributen und Interaktionen an das SLX-Modell weitergeben zu können, wurden außerdem dynamische Speicherbereiche, auf die ebenfalls von der Bibliothek und SLX zugegriffen werden kann, eingeführt.

Gemeinsame dynamische Speicherbereiche

Diese dynamischen Bereiche sind jedoch vom Modell abhängig, da sie konkret die für die Objektsichtweise von HLA notwendigen Objekte und Interaktionen betreffen. Das Problem hierbei ist, daß die Struktur dieser SLX-Objekte nicht zur Compile-Zeit der Bibliothek bekannt ist und somit die SLX-internen Algorithmen zur Speicherung von Objekten wahlfreier Struktur berücksichtigt werden müssen. SLX-Objekte sind intern zwar selbstbeschreibend, da Informationen über die Objekte zur Laufzeit in Symboltabellen gehalten werden; diese Informationen sind jedoch nicht für den Endnutzer gedacht und werden nicht offengelegt. Daher mußte außerdem eine Lösung zur Übermittlung der Datenstruktur eines Objektes (welche Attribute mit welchen Typen es besitzt) an die Bibliothek gefunden werden. Zur Lösung dieses Problems wurde die Konvention eingeführt, daß mit Übergabe der Information des Speicherortes eines dynamischen Objektes gleichzeitig Informationen über die Datenstruktur des Objektes in Form eines Typ-Strings übergeben werden müssen. Mittels dieses Typ-Strings und den vom SLX-Hersteller bereitgestellten Informationen über die interne Datenrepräsentation wurde es dann möglich, über Zeigeroperationen auf jedes Objektattribut direkt zuzugreifen. Zur Zeit ist es mit diesem Mechanismus möglich, Attribute mit Basisdatentypen wie Integer, Double, String oder Boolean und die für SLX-spezifischen Kontrollvarianten dieser Typen (Control Integer, Control Double etc.) zu behandeln.

Handhabung komplexer Datentypen

An einer Lösung für komplexere SLX-Typen, wie Aufzählungstypen (enum), Mengen (set) oder Objekte, die als Attribute wiederum Objekte haben, wird derzeit gearbeitet. Letzteres ist z.B. nötig, um komplexere Objekte anderer Federates (z.B. reine C++-Simulationen), die C-structs als Typen für Attribute verwenden, intern in SLX abbilden zu können.

Die Behandlung solcher Konstrukte ist jedoch insofern komplizierter, als daß hier die Komponenten des C-Structs von der Wrapper-DLL analysiert werden müssen, um sie in die entsprechende SLX-Repräsentation umzuwandeln. Für einfache Basistypen wie Integer oder Double ist dies relativ trivial, da diese attributsweise von der RTI-Bibliothek geliefert werden und durch einfaches Type-Casting in die SLX-konformen Darstellung umgewandelt werden können. Dadurch treten bei den Basistypen keine Probleme mit unterschiedlichen Byte-Größen zwischen in SLX nicht existierenden C-Typen auf (siehe Vergleich der Größen Double / Float unter Punkt 4.2). Da C-Structs jedoch von der RTI-Bibliothek als Ganzes geliefert werden (also als eine Aneinanderreihung von Bytes), ist es für deren Behandlung notwendig, die eigentlichen Elemente des Structs und deren Bytegrößen zu kennen.

Der Grad der möglichen Wiederverwendbarkeit der vorgestellten Lösung ist relativ hoch, da sich die Grundidee, einen Simulator über eine Zwischen- bzw. Wrapper-Bibliothek HLA-fähig zu machen, durchaus auch auf andere Simulationstools übertragen läßt [5]. Prinzipiell ist die Lösung für jeden Simulator, der Standard-C DLL’s aufrufen kann, geeignet. Anzupassen sind jedoch die Regelungen zum Datenaustausch, da hierfür die SLX-interne Repräsentation der Daten von der DLL berücksichtigt werden mußte. Stehen für ein Simulationstool keine Informationen über die interne Datenrepräsentation zur Verfügung, sind andere Lösungen, z.B. über ein allerdings ineffizienteres Polling, denkbar. Bei einer solchen Lösung müßte der Simulator z.B. nach jedem Zeitfortschritt aktiv bei der Bibliothek anfragen, ob Attributsänderungen eingetroffen sind.

Es ist ebenfalls denkbar, die vorliegende DLL, die speziell für Windows 95 / Windows NT entwickelt wurde, auf andere Betriebssysteme zu portieren und somit eine Ausgangsbasis für die HLA-Anbindung von Simulatoren, die nicht unter Windows lauffähig sind, zu schaffen.

Die für die HLA-Anbindung des Simulators SLX entwickelte Bibliothek stellt eine modellunabhängige und somit für den Simulator SLX allgemeingültige Lösung der Problematik "HLA-Kompatibilität" dar. Mit dieser HLA-Anbindung ist es möglich, SLX-Modelle mit Modellen anderer Simulatoren, die ebenfalls HLA-kompatibel sind, zu koppeln. Dies ist z.B. sinnvoll, wenn komplexe Modelle in verschiedenen Simulatoren existieren, die für eine gemeinsame Simulation genutzt werden sollen. Insgesamt ist festzustellen, daß der Initialaufwand, um ein Tool HLA-fähig zu machen, durchaus nicht zu unterschätzen ist (die SLX-RTI-Bibliothek besteht z.B. aus ca. 5000 Programmzeilen). Mit dem Erbringen dieses Initialaufwandes für ein Tool wird jedoch ein großes Potential für mögliche Kopplungen mit anderen Tools, Simulatoren oder Visualisierungsprogrammen geschaffen.

Die Ausdehnung des Projektes auf andere Simulatoren, z.B. auch der kontinuierlichen Simulation (z.B. Simulink / Matlab) ist geplant. Eine Verbesserung der Lösung für SLX wird mit der in Aussicht gestellten Möglichkeit des Programmierens von Rückruffunktionen in SLX möglich werden. Ob jedoch gänzlich auf die Lösung einer Zwischen-DLL verzichtet werden kann, erscheint fraglich und ist auch nicht unbedingt notwendig, da sich viele für die Programmierung mit der RTI notwendigen Umrechnungen direkt in C einfacher gestalten.

Die Anwendung der vorgestellten Bibliothek für SLX ist für verschiedene Projekte mit heterogener Federatestruktur vorgesehen, u.a. für die verteilte Modellierung von Beispielproblemen aus der Logistik, der Fertigungsorganisation sowie der Echtzeit-Fahrsimulation.