High Level Architecture
Vorlage:Qualitätssicherungstext
Die Diskussion über diesen Antrag findet auf der Qualitätssicherungsseite statt.
Hier der konkrete Grund, warum dieser Artikel auf den QS-Seiten eingetragen wurde:
Kann das bitte jemand verständlich ausdrücken oder auf das Wesentliche kürzen? -- FriedhelmW 15:31, 20. Nov 2005 (CET)
Die Entwicklung im Bereich der Modellbildung und Simulation (M&S) in den letzten 40 Jahren zeigte deutlich, dass ein einzelnes Modell oder monolithisches Simulationssystem nicht allen Verwendungszwecken und Benutzern gerecht werden kann. Außerdem ist es unmöglich, alle Verwendungs- und Kombinationsmöglichkeiten von Simulationen vorherzusehen. Die logische Konsequenz war die Entwicklung eines modularen und komponentenbasierten Ansatzes für verteilte Simulationen.
Doch wie ist es möglich, dies global so umzusetzen, dass räumlich verteilte Simulationen ohne Funktionalitätsverlust koordiniert werden können? Diese Frage gewann im Laufe der 80er Jahre immer mehr an Bedeutung. Ziel musste es also sein eine "globale synthetische Simulationsumgebung" zu schaffen.
Das amerikanische Verteidigungsministerium (genauer das Defense Modeling and Simulation Office, DMSO for the U.S. Department of Defense, DoD; [1] ) hat eine Architektur zur integrierten und verteilten Simulation definiert - die s.g. "High-Level Architecture, HLA". Dieses Konzept ist im Jahr 2000 zum internationalen Standard geworden (IEEE 1516).
Eine der Grundideen der HLA ist, die Simulationsfunktionalität von der Infrastruktur zu trennen, welche allgemeine, die Interoperabilität gewährleistende Dienste bereitstellt. Die interne Struktur von Simulationen wird von der HLA nicht spezifiziert.
Eine HLA-Simulation besteht aus vier Elementen:
- Federate
Ein Federate ist die Bezeichnung für ein einzelnes Mitglied einer HLA-Simulation.
- Federation
Eine Federation ist ein Verbund von Federates (HLA-Simulation).
- Runtime Infrastructure (RTI)
Die im Simulationsverbund zusammenarbeitenden Federates nutzen als Kommunikationsplattform die RTI. Sie ermöglicht nicht nur, dass alle Federates einer Federation miteinander über definierte Schnittstellen kommunizieren können, sondern sie stellt auch für den Simulationsablauf notwendige Dienste zur Verfügung.
- Federation Object Model (FOM)
Für den Datenaustausch zwischen den einzelnen Federates ist ein FOM, d.h. eine Beschreibung der gemeinsamen Datenbasis, definiert.
Die HLA als Standard
Die HLA besteht aus drei Grundbestandteilen:
- HLA Rules
Sie bestimmen das Verhalten und die Fähigkeiten von Federates und Federations.
- HLA Object Model Template (OMT)
Dieses Template (Vorlage) wird benutzt, um die Objektmodelle von Federates (Simulation Object Model - SOM) und Federations (Federation Object Model - FOM) zu beschreiben.
- HLA Interface Specification (IFSpec)
Sie legt fest, wie die Federates mit der HLA Software (die Runtime-Infrastruktur - RTI) kommunizieren, welche die unterstützenden Dienste zur Verfügung stellt. Diese IFSpec Schnittstelle ist für verschiedene Programmiersprachen (C++, JAVA, ADA95 ...) erhältlich.
Die HLA verwendet eine objektorientierte Sicht auf Simulationen und Simulationseinheiten. Alle modellierten Einheiten werden als Objekte betrachtet, deren Zustand und Eigenschaften durch Attribute beschrieben werden. Nicht-persistente Ereignisse, die zu bestimmten Zeitpunkten auftreten, werden Interactions genannt. Interactions besitzen Parameter und können für die Modellierung von Interaktion zwischen Objekten genutzt werden.
Diese Objektsicht beschreibt nur die Sicht von außen und macht keine Aussagen über die interne Verarbeitung der Daten in einem Simulator.
HLA-Rules
Funktional wird die HLA durch einen Satz von Regeln definiert, der die Funktion von Simulationen und den angebotenen Diensten der RTI beschreibt. Dabei geben die Regeln das Zusammenspiel der HLA-Komponeneten vor und beschreiben die Verantwortlichkeiten von Federates und RTI. Somit sind sie für den Nutzer sowohl für das Verständnis der HLA-internen Kommunikation (zwischen den einzelnen Federates) wichtig, als auch gleichsam eine Anleitung wie die HLA genutzt werden soll. Bei der Definition der HLA wurden zehn Regeln festgelegt. Die ersten fünf beschreiben die Federation, während sich die letzten fünf mit den Federates befassen.
Regeln für Federations
- R 1: Federations müssen ein Federation Object Model (FOM) besitzen, welches mit mit dem HLA object Model Template (OMT) kompatibel ist.
- R 2: Alle simulationsbezogenen Objektinstanzen einer Federation sollen ihren Federates, nicht der RTI, zugeordnet sein.
- R 3: Die gesamte Kommunikation zwischen einem Federate und der RTI muss unter Verwendung von Diensten der Interface Specification
der HLA geschehen.
- R 4: Während einer HLA-Simulation muss der gesamte Datenaustausch zwischen den Federates über die RTI erfolgen.
- R 5: Während einer HLA-Simulation darf das Attribut einer Objektinstanz zu jedem Zeitpunkt nur höchstens einem Federate gehören, in
dessen Besitz das Attribut ist.
Regeln für Federates
- R 6: Jeder Federate muss ein SimulationObject Model (SOM) besitzen, welches mit dem HLA Object Model Templete kompatibel ist.
- R 7: Federates sollen Attribute der im SOM definierten Objekte aktualisieren bzw. zurückgeben sowie die im SOM definierten
Interaktionen senden bzw. empfangen können.
- R 8: Jeder Federate soll Attribute der im SOM definierten Objekte während der HLA-Simulation dynamisch anderen Federates übertragen
bzw. den Besitz von anderen Federates übernehmen können.
- R 9: Federates sollen die Bedingungen verändern können, unter denen Attribute der im SOM definierten Objekte aktualisiert werden.
- R10: Jeder Federate soll seine lokale Zeit so verwalten können, dass er den Datenaustausch mit anderen Federates korrekt
koordinieren kann.
Object Model Template (OMT)
Der Modellentwickler spezifiziert mit dem OMT den gemeinsamen Rahmen (Objekt- und Interaktionsbeschreibung,Datenformat für Attribute und Parameter)für die in einem Simulationsmodell verwendeten Objekten und Interaktionen.
Nach HLA-Regel Nr. 6 muss jeder Federate ein Simulation Object Model (SOM) besitzen. So muss der Modellentwickler für jeden Federate ein SOM erstellen. In einem SOM werden alle Objekte und deren Attribute sowie alle Interaktionen und deren Parameter beschrieben, die von anderen Federates abonniert bzw. veröffentlicht werden. Für den Simulationsverbund muss ein Federation Object Model (FOM) definiert werden. Darin wird gemäß OMT festgelegt, welche gemeinsame Informationen benötigt werden, um die Ziele der Simulation im Verbund zu erreichen. Es werden nicht alle Informationen, die im SOM eines jeden beteiligten Federates stehen, verwendet, sondern nur eine Schnittmenge über alle SOM's.
Interface Specification
Nach HLA-Regel Nr. 3 muss der Datenaustausch über die RTI laufen. Somit ist eine Schnittstelle nötig, welche einerseits definiert wie die Federates mit der RTI kommunizieren und andererseits welche unterstützende Dienste die RTI für den Simulationsverbund zur Verfügung stellt.
Die RTI beinhaltet sechs verschiedene Dienstgruppen, auf die jeder Federate zugreifen kann:
- a) Federation Management
Die Federation Management Dienste sind zuständig für die Koordination der Aktivitäten während der Ausführung einer Simulation. Darunter fallen Initiierung von Federates, deren Beitritt zu einer Federation, sowie ihr Austritt.
- b) Declaration Management
Deklaration seitens der Federates, welche Daten sie für die übrigen Federates bereitstellen (publish) und an welchen Daten sie selbst interessiert sind (subscribe). Zudem regelt das Declaration Management, zu welchen Zeitpunkten die unterschiedlichen Daten bei den Federates bearbeitet werden.
- c) Object Management
Das Object Management regelt den Ablauf des Registrierens eines neuen Objekts bei der RTI. Diese teilt dies den übrigen Federates mit. Außerdem regelt das Object Management, wie Updates der publizierten Objekte gehandhabt werden sollen.
- d) Ownership Management
- e) Data Distribution Management
- f) Time Management
Das Time Management dient zum Verwalten der Zeitpunkte, zu denen Interaktionen oder Upadtes geschickt/empfangen werden. Dazu existieren zwei verschiedene Modi zur Zeitverwaltung (Time Regulation u. Time Constrained).