Interoperabilität von Simulatoren

Interoparabilität von Simulatoren dient dem Training komplexer Szenarien im Verbund. Es ist der Austausch von

• Begegungsdaten (z.B. Flugzeugdynamik) und Status (z.B. Fahrwerk ein/aus)

• Audiodaten (z.B. Sprechfunk)

• Audio/Videodaten (z.B. Instructor, Operator, Überwachung)

über Vernetzungsstandards:

• DIS (UDP Broad-/Multicast)

• HLA (Middleware, RTI, OOP)

=> Das Zusammenwirken von Simulatoren

Es ist die Zusammenschaltung von örtlich verteilten Simulatoren und beteiligter IT zu einem Simulations- und Trainignsverbund über ein Wide-Area-Network (WAN) oder ein Local-Area-Network (LAN).

Objektorientierte Programmierung

Eine Klasse ist eine Zusammenfassung von:

• Daten = Attributen = Eigenschaften = Member Variables

• Funktionen = Operationen = Methoden = Member Functions

• Einteilung in public, protected und private Members

Ein Objekt (oder auch Instanz) ist eine Ausprägung einer Klasse.

Beispiel:

LINE 1: #include “myClass.h”Importieren der Klasse

LINE 2: myClass meineKlasse;Erstellen einer Instanz der Klasse myClass mit dem Namen meineKlasse.

Vererbung bedeutet, dass es eine Basisklasse gibt, die von einer abgeleiteten Klasse erweitert oder eingeschränkt wird.

Dies ermöglicht:

• Wiederverwendbarkeit von Klassen

• Übernahme der Atribute und Methoden der Basisklasse

Beispiel:

class childClass: public ParentClass {…};

Der Hauptvorteil von OOP ist die Wiederverwendbarkeit und Datenabstraktion von Klassen durch sog. Vererbung

Shared Memory ermöglicht es mehreren Programmen auf einen gemeinsamen Speicher zuzgreifen.

Siehe Bild Folie 3 - mit RAM Stack

• Erzeugen create()

• Verbinden connect()

• Write ()

• Read()

• Disconnect()

• Clear()

Es bedeutet, dass bestimmte Funktionen von verschiedenen Betrisbsystemen unterschiedlich gehandhabt werden und nicht zwingend zueinander kompatibel sind.

Vorteile:

• Einfache Programmierung

• Hochperformant

• gut für zyklische Daten

• Auf allen OS verfügbar

Nachteile:

• Betriebssystemspezifisch

• Bedingt geeignet für zeitdiskrete Ereignisse

• nicht Netzwerkfähig

• keine Standardisierte Datenschnittstelle

User-Datagram-Protocol

Ein sog. verbindungsloses Protokoll zur Übermittlung von Datagrammen

Ein verbindungsloses Protokoll ist

• unzuverlässig

  Datagramme können verloren gehen

• unsortiert

  Reihenfolge der Datagramme kann nicht garantiert werden

• ungeschützt

  Daten können verfälscht werden

Das verbindungslose Protokoll kann nicht sicherstellen, dass die gesendeten Daten auch empfangen werden.

• Unicast

  Nachricht an einen bestimmten Host

• Multicast

  Nachricht an eine Gruppe von Hosts

• Broadcast

  Nachricht an alle Hosts

Ein Sender benötigt im wesentlichen die folgenden Methoden:

• writeDatagram() - Methode zum senden

• Socket - Schnittstelle

• netinit() - Win32 Methode für Netzwerkfunktionen

• netcleanup() - Win32 Methode zum beenden von Netzwerkfunktionen

Die Methoden netinit() und netcleanup() werden von Windows NT-Systemen durch die Bibliothek wsock32.lib zur Verfügung gestellt.

Ein Empfänger benötigt im wesentlichen die folgenden Methoden:

• readDatagram() - Methode zum Empfangen

• Socket - Schnittstelle

• bind() - Methode zum “binden” an einen Port

• netinit() - Win32 Methode für Netzwerkfunktionen

• netcleanup() - Win32 Methode zum beenden von Netzwerkfunktionen

Die Methoden netinit() und netcleanup() werden von Windows NT-Systemen durch die Bibliothek wsock32.lib zur Verfügung gestellt.

Bei einer verteilten Simulation mittels UDP stellt ein System über UDP Daten in Form von Datagrammen bereit.

Diese können von einem oder mehreren Empfängern (Uni-, Multi- oder Broadcast) empfangen werden.

Eine Rückmldung an den Sender findet nicht statt.

1. netinit()

2. Create Socket

3. writeDatagramm()

4. netcleanup()

1. netinit()

2. bind()

3. if(recv = readDatagram() > 0)

4. netcleanup()

Vorteile:

• Netzwerkfähig

• Einfache Programmierung

• Performant - schnell, ideal für zeitkritische Anwendungen

• Verfügbarkeit: auf allen Betriebssystemen verfügbar

• Verbindungslos: Bootreihenfolge Server/Client egal

Nachteile:

• System-spezifisch: Windows != Linux

• Datagramme können verloren gehen

• Datagramme können fehlerhaft ankommen

Transmission Control Protocol

TCP ist eine bidirektionale Verbindung zwischen zwei Endpunkten.

1. WinSocket initialisieren

2. TCPSocket anfordern

3. connect mit Server

4. send/recv - Daten übermitteln

5. WinSocket beenden

1. WinSocket initialisieren

2. TCPSocket anfordern

3. bind - an Port “binden”

4. listen - Warteschlange konfigurieren

5. accept - Warten auf Client-Verbindungswunsch

6. send/recv - Daten übertragen

7. auf neue Verbindung warten

1. TCPSocket - initialisieren

2. connect() - Verbinden mit Server

3. send/recv - Daten übermitteln

1. TCPSocket - initialisieren

2. bind() - an Port “binden”

3. listen() - Warteschlange konfigurieren

4. accept() - neue Verbindung akzeptieren

5. send()/recv() - Daten übermitteln

6. auf neue Verbindung warten

Vorteile:

• Bidirketionale Verbindung - sicherstellen das Empfänger bereit ist

• Netzwerkfähig

• Sortiert - Reihenfolge der Daten ist gewährleistet

• Fehlererkennung - Fehler können erkannt werden (Checksum)

• häufigste Verwendung (z.B. Webserver)

Nachteile:

• Etwas langsamer als UDP

• festgelegte Startreihenfolge Server(1)/Client(2)

• Aufwändiger zu Programmieren

TCP ist eher geeignet für zeitdiskrete Daten.

Eine PDU ist eine Protocol Data Unit, also eine standardisierte Nachricht zur Informationsübertragung zwischen Simulatoren.

Beispiele für PDUs:

• Entity State PDU

  Information über Zustand einer Entität (Typ, Position, Geschwindigkeit, …)

• Fire PDU

• Detonation PDU

• Collision PDU

• Shutdown PDU

Der Distributed Interactive Simulation - Standard basiert auf dem UDP-Protokoll.

Zum Einsatz kommen vor allem:

• UDP Mulitcast

• UDP Broadcast (255.255.255.255)

• Identification of the entity that issued the PDU

• Identification of the force to which the entity belongs

• Specific entity type

• Location information:

  • Location with respect to the world

  • Velocity

  • Orientation

• Information required for representing entitys appearance

  • Apperance (normal, on fire, smoking, dust cloud)

  • Markings

  • presence of parts, variable parameters

• Capabilites of the entity

  • Resupply

  • Repair

• 32 Bit: Simulation Adress

  • 16 Bit (unsigned): Site Number

  • 16 Bit (unsigned): Application Number

• 16 Bit: Entity Number

• 8 Bit: Enitity Kind

• 8 Bit: Domain

• 16 Bit: Country

• 8 Bit: Category

• 8 Bit: Subcategory

• 8 Bit: Specific

• 8 Bit: Extra

Beispiel:

(1,2,78,40,14,0,0) => (Platform, Air, Germany, Trainer, Beech, None, None )

Entity State: 1152 Bit

Abtastrate: 20ms -> 1/0,02s = 50 Hz

Übertragungsrate: 50Hz * 1152 Bit => 57.600 Bit/s

20 Entitäten: 20 * 57.600 Bit/s = 1.152.000 Bit/s -> 1,15 MBit/s

Somit ist eine Datenrate von 1.152.000 Bit/s nötig.

Zur Reduktion der notwendigen Datenrate wird das sog. Dead Reckoning benutzt.

Es approximiert den zukünftigen Verlauf mittels Dead Reckoning Model (DRM) auf Sender- / Empfängerseite.

Die Daten werden seltener abgeglichen und die übergänge mittels PT1- Filter gegättet.

Vorteile:

• Einfache Programmierung

• keine zentrale Komponente nötig

• Robust, verbindungsloses Protokoll

• Einfache Inbetriebnahme

• kostengünstig

Nachteile:

• hohe Netzwerklast

• Objektmodell sehr starr, Änderungen nur schwer möglich -> Änderung an allen Simulatoren nötig

• Föderate

  Föderate sind Einzelsimulationen, also einzelne Kopmonenten innerhalb einer Gesamtsimulation, der sog. Föderation. (z.B. eine BO-105 oder ein 2D/3D - Viewer)

• Föderation

  Die Föderation ist die Gesamtheit aller Einzelsimulationen. Also der Zusammenschluss aller Einzelkomponenten.

Die Run-Time Infrastructure:

• überwacht den Simulationsablauf.

• verteilt die Daten an die Einzelsimulationen.

• kommuniziert über TCP / UDP.

Das Föderat nutzt den sog. publish um Daten an diem RTI zu senden. Die RTI nutzt den sog. subscribe um die Daten an die Föderate zu senden.

Federation Object Model (FOM)

FOM sind standardisierte Beschreibungen welche Informationen zwischen Föderaten ausgetauscht wird.

Dabei kommt der Objektorientierte Ansatz von HLA zum tragen.

• BaseEntity.PhysicalEntity.Platform.Aircraft

• …

• WeaponFire

• MunitionDetonation

• Wirkt auf der Empfängerseite

• Entscheidet ob und wie gut der Audiostream hörbar ist

• Serialisierter Audiostream

• Als Folge Von HLA Daten als RadioSignal.EncodedAudioRadioSignal

Vorteile:

• gute Netzwerkausnutzung

• FOM durch Vererbung gut erweiterbar

• In RTI sind alle Daten verfügbar, z.B. zur Überwachung, Diagnose, Logging

Nachteile:

• Kommerzielle RTI teuer

• Komplexe Installation

• Programmierung der Föderate aufwändig

ExEntity myAircraft;

myAircraft.setId(5);

double speed = myAircraft.getSpeed();

cout << “Geschwindigkeit: “ << speed << endl;

myAircraft.draw();

myAircraft.move();

Die Klasse ExEntity erweitert die Basisklasse Entity

Das Serialisieren überführt eine strukturierte Datenabbildung in eine sequenzielle Darstellung. Dadurch können Daten für die Übermittlung mittels UDP oder TCP vorbereitet werden.

Verschlüsselung - SSL

• https: hypertext transfer protocol secure

• Webserver

• E-Mail Server

• HLA-Systeme

• PitchRTI

• Hypertext Transfer Protocol

• Hypertext Transfer Protocol Secure

• Application Programming Interface

• Domain Name Service

• Dynamic Host Control Protocol

8.8.8.8 - Google