High Level Architecture
# High Level Architecture

High-Level Architecture (HLA) ist eine vom US-amerikanischen Verteidigungsministerium (genauer dem „Defense Modeling and Simulation Office, DMSO for the U.S. Department of Defense“) definierte Architektur zur integrierten und verteilten Simulation. Dieses Konzept ist im Jahr 2000 zum internationalen Standard geworden (IEEE 1516). Sie basiert auf der Idee, eine Gesamtsimulation in mehrere einzelne, kleine Simulationen aufzuteilen, die untereinander ihre Informationen austauschen. Die Kommunikation geschieht über ein Computernetzwerk. Verwaltet werden die einzelnen Simulationen dabei von einer zentralen Komponente, der sogenannten „Run-Time-Infrastructure“ (RTI). Diese überwacht den Simulationsablauf und verwaltet die Verteilung der Daten zwischen den Einzelsimulationen (Föderaten). Die Gesamtheit der Einzelsimulationen wird als „Föderation“ bezeichnet.

## Technischer Überblick

Die High-Level-Architecture basiert auf drei großen Definitionsbereichen
* Interface Specification: Diese definiert die Schnittstelle zwischen den Einzelsimulationen und der RTI. Dies sind konkret Programmbibliotheken, die die Funktionen und Datenstrukturen für die Kommunikation zwischen RTI und Föderaten beinhalten.
* Object Model Template (OMT): Das OMT definiert, welche Informationen zwischen den Simulationen ausgetauscht werden sollen und wie diese zu dokumentieren sind.
* HLA-Regeln: Definiert die Regeln, die eine Simulation einhalten muss, um standardkonform zu sein.
Die Daten, die zwischen HLA-Föderaten ausgetauscht werden, können entweder Objekte oder Interaktionen sein. Ein Objekt ist eine Datenstruktur, die in einer teilnehmenden Simulation vorhanden ist und die ihre Daten (Attribute) im Netzwerk verteilt. Eine Interaktion ist mit einem Ereignis gleichzusetzen und besitzt bestimmte Parameter. Zum Beispiel besitzt ein Objekt „Flugabwehrpanzer“ in Simulation A die Attribute Position, Geschwindigkeit, Beschleunigung etc. Eine Interaktion kann nun z. B. das Abfeuern eines Lenkflugkörpers auf ein Kampfflugzeug in Simulation B sein und als Parameter den Typ des Gefechtskopfes, das beschossene Ziel oder das abfeuernde Objekt besitzen. Nun wäre Simulation B in der Lage, auf das Abfeuern des Lenkflugkörpers zu reagieren.
Die Daten können als Unicast UDP/TCP oder Multicast übertragen werden. Somit bietet die HLA mehr Flexibilität im Bereich der vernetzten Simulation als das Simulationsprotokoll DIS, das seine Daten ausschließlich per Broadcast austauscht.

## Interface Specification

Die Schnittstelle zwischen Simulation und RTI ist in der Regel objektorientiert und in einer Programmiersprache wie C++ oder Java implementiert. Die zur Verfügung stehenden Objekte und Funktionen können in folgende Gruppen (service groups) unterteilt werden:
* Federation Management
* Declaration Management
* Object Management
* Time Management
* Data Distribution Management
* Ownership Management
* Support Services

## Object Model Template (OMT)

Das OMT bildet einen gemeinsamen Rahmen für die Kommunikation zwischen HLA-Föderaten. Es handelt sich um eine standardisierte Schablone für ein Datenmodell und legt fest, welche Daten mit anderen Föderaten ausgetauscht werden können. Das Datenmodell selber kann frei definiert werden. Man unterscheidet zwei Arten von Datenmodellen:
* Federation Object Model (FOM): Dieses definiert die Objekte mit Attributen und die Interaktionen mit Parametern, die innerhalb einer Föderation ausgetauscht werden können und ist deshalb föderationsweit bekannt.
* Simulation Object Model (SOM): Vergleichbar mit FOM, definiert jedoch die Daten, die ein einzelner Föderat austauschen kann.
Damit ein Datenaustausch innerhalb einer Föderation möglich ist, müssen die Föderaten mit ihrem SOM zumindest eine gemeinsame Schnittmenge des FOM unterstützen.

## HLA-Regeln

Die HLA-Regeln beschreiben Anforderungen an Föderaten und Föderationen beim Simulationsablauf. Hier werden u. a. die Kommunikationsgrundlagen definiert.
Regeln für Federations:
* Jede Federation muss ein Federation Object Model (FOM) besitzen, das kompatibel zum Object Model Template (OMT) der HLA ist.
* Alle simulationsbezogenen Objektinstanzen einer Federation sollen seinen Federates zugeordnet sein, nicht der RTI.
* Während einer Federation Execution muss der gesamte Datenaustausch zwischen seinen Federates über die RTI erfolgen.
* Die gesamte Kommunikation zwischen einem Federate und der RTI hat unter Verwendung von Diensten der Interface Specification der HLA zu erfolgen.
* Während einer Federation Execution darf es für ein Attribut einer Instanz zu jedem Zeitpunkt nur höchstens ein Federate geben, in dessen Besitz das Attribut ist.
Regeln für Federates:
* Jedes Federate muss ein Simulation Object Model (SOM) besitzen, das kompatibel zum Object Model Template (OMT) der HLA ist.
* Federates sollen Attribute der im SOM definierten Objekte empfangen bzw. aktualisieren, sowie die im SOM definierten Interaktionen senden bzw. empfangen können.
* Federates sollen Attribute der im SOM definierten Objekte während der Federation Execution dynamisch anderen Federates übereignen bzw. den Besitz von anderen Federates übernehmen können.
* Federates sollen Bedingungen, unter denen Attribute der im SOM definierten Objekte aktualisiert werden, verändern können.
* Jedes Federate soll seine lokale Zeit so verwalten können, dass der in der SOM festgelegte Datenaustausch mit anderen Federates korrekt ausgeführt werden kann. (Time Management)
Die RTI überprüft die Einhaltung der HLA-Regeln, der Implementierungsgrad variiert je nach verwendeter RTI. Insbesondere „Time Management“ wird nicht von allen RTIs unterstützt.

## Standards

Die HLA ist seit 2000 im IEEE-Standard 1516 definiert, welcher sich in folgende Anteile gliedert:
* IEEE 1516-2000: High Level Architecture - Framework and Rules
* IEEE 1516.1-2000: High Level Architecture - Federate Interface Specification
* IEEE 1516.1-2000: Errata (16. Okt. 2003)
* IEEE 1516.2-2000: High Level Architecture - Object Model Template (OMT) Specification
* IEEE 1516.3-2003: Recommended Practice for HLA Federation Development and Execution Process (FEDEP)