Simulation 2

Die parallele (verteilte) Simulation ist eine Technik, bei der Computersimulationen auf Rechensystemen mit mehreren Prozessoren ausgeführt werden.

• Eng gekoppelte Mehrprozessorsysteme
• Netzwerk von Workstations (z.B. via Internet)

1. Physikalische Zeit
   => Zeit im physikalischen System
2. Simulations-Zeit
   => Repräsentation der physikalischen Zeit innerhalb der Computersimulation (Gleitpunktzahl in einem bestimmten Intervall)
3. Umgebungszeit (auch Realzeit)
   => Zeit während der Ausführung der Computersimulation (üblicherweise Ausgabe einer Hardware-Uhr)

Es gibt drei verschiedene Ausführungsarten:

1. As-fast-as-possible (unpaced): kein fixer Zusammenhang zwischen Fortschritt der Simulationszeit und Fortschritt der Echtuhrzeit
2. Real-time (paced): Jeder Fortschritt der Simulationszeit wird mit Fortschritt der Echtuhrzeit synchronisiert
3. Skalierte Echtzeit (paced): Fortschritt der Simulationszeit synchron zu S x äquivalentem Fortschritt in Echtuhrzeit (Zeitlupe bzw. Zeitraffer)

1. Lange Rechenzeiten
   => Schnellere Simulationsabläufe durch verteilte Simulation
2. Simulationsmodelle sind oft speicherintensiv
   => Verteilte Simulation ermöglicht größere Modelle
3. Geographische Verteilung
4. Nutzen von vorhandenen Ressourcen
   => Verteilte Simulation ermöglich effizientes Ressourcenmanagement
5. Interoperabilität zwischen vorhandenen Simulationen
   • Kopplung von Simulatoren verschiedener Hersteller
   • Kopplung heterogener Modellwelten (z.B. digitale Fabrik)

1. Virtuelle Umgebungen

=> Simulation in virtuellen Umgebungen, um dynamisch computer-generierte Entitäten zu schaffen

Beispiele: Training (militärisch, Notfallplanung), Unterhaltung (Video-Spiele), Soziale Interaktion

2. System-Analyse

=> Anwendung von Simulation auf Basis diskrete-ereignisgesteuerter Simulationsverfahren

Beispiele:

• Produktionssysteme, Logistik, Transportsysteme
• Telekommunikations-Netze
• Elektronische Systeme (z.B. Mikroelektronik, Computersysteme)
• Gefechtssimulation (konstruktiv)
• Ökologische Systeme

=> Fokus typischerweise auf Planung und Systemdesign

1. (hinreichend) gut parallelisierbares Modell
2. Parallele oder verteilte Architektur verfügbar
3. Mehraufwand (Software-Adaptierung, aufwendige Hardware) muss sich lohnen
   • Kapazitätsgrenzen (Zeit, Speicher) des bisherigen Systems reichen nicht mehr aus
   • Lange bzw. häufige Verwendung des Modells etc.
4. Gleiches bzw. gleichwertiges Ergebnis wie bei sequentieller Simulation soll erzielt werden können

Ansatz: Nutzung mehrerer Rechnerknoten oder Prozessoren, um Berechnungsaufgaben parallel abzuarbeiten. Dabei gibt es zwei grundlegende Möglichkeiten:

1. Parallelisierung auf Code-Basis
   • Compiler-Ebene
   • Funktions-Ebene
   • Applikations-Ebene
2. Parallelisierung auf Modell-Basis
   • Ereignis-Ebene
   • Teilmodell-Ebene

Bei der Verteilung auf Compiler-Ebene wird ein existierendes sequentielles Programm mittels eines parallelisierenden Compilers für Mehrprozessorsysteme adaptiert.

Vorteil: Geriner Adaptierungsaufwand

Nachteil: Aufgrund der dynamischen Parallelität in Simulationsprogrammen meist nicht effizient

Bei der Verteilung auf Funktionsebene werden Unterstützungsfunktionen, wie z.B. Zufallszahlengenerierung, Ereignislistenverwaltung, Statistikfunktionen etc. auf mehrere Prozessoren verteilt.

Vorteil: Mäßiger Adaptierungsaufwand

Nachteil: Schlechte Skalierbarkeit

Bei der Verteilung auf Applikationsebene laufen die Instanzen eines Simulationsprogramms mit unterschiedlichen Daten oder mit unterschiedlichen Zufallszahlenstartwerten auf mehreren Prozessen.

Vorteil: Geringer Adaptierungsaufwand

Nachteil: Nicht immer einsetzbar; hilft nicht bei zu großen Modellen

• globale Ereignisliste
• Parallel abzuarbeitende Ereignisse werden auf mehrere Prozessoren verteilt

Vorteile: Synchronisation einfacher, da zentral

Nachteile:

• Zentralistischer Ansatz
• uneffizient bei kleinen Ereignissen
• weniger geeignet für Architekturen mit verteiltem Speicher (Kommunikationsaufwand!)

• Räumliche (spatiale) Zerlegung des Modells in Regionen bzw. Kopplung vorhandener Teilmodelle
• Simulation der Regionen erfolgt mittels mehrerer "logischer Prozesse"
  • Interne Ereignisse
  • Externe Ereignisse
• Kommunikation zwischen den Teilmodellen erfolgt durch Nachrichten mit virtuellen Zeitstempeln (Simulationszeit)
• Unabhängige virtuelle (Simulations-)Zeiten in den Teilmodellen

Vorteile:

• Übersetzung (und damit potentielle Ausnützung) der Parallelität des simulierten Systems
• Eignung zur Kopplung vorhandener Teilmodelle

Nachteile:

• Synchronisationsmechanismus notwendig

Innerhalb eines verteilten ereignisdiskreten Simulationsmodells, das aus verschiedenen logischen Prozessen zusammengesetzt ist, kann es zu einer Kausalitätsverletzung kommen, wenn die lokalen Ereignisse eines Prozesses nicht in chronologischer, also zeitlich aufsteigender, Reihenfolge ausgeführt werden, da sich die virtuelle Zeiten in unterschiedlichen LPs voneinander unterscheiden können. Da die Modellregionen voneinander über Ereignisse kausal abhängig sind, kann es beim Empfang einer Nachricht aus der Vergangenheit zu einem Kausalitätsproblem kommen. Hier wird man dann nicht mehr dasselbe Ergebniss wie bei einer sequentiellen Simulation bekommen!

1. Konservative Simulation
   => Verhindern von Kausalitätsverletzungen durch Blockieren, bis nächstes Ereignis "sicher" ist
2. Optimistische Simulation
   => Kein Blockieren, sondern Rückgängigmachen von Ereignissen ermöglichen, falls Kausalitätsverletztung aufgetreten ist
3. Mischansätze
4. Zeitparallelismus statt räumlicher Modellzerlegung

Die konservative Simulation ist ein asynchrones Verfahren. D.h. wenn zwei Ereignisse parallel simuliert werden, heißt dies nicht, dass sie im simulierten Modell auch parallel "stattfinden". Das bedeutet, dass ein Ereignis mit dem Zeitstempel vt = t nur simuliert wird, wenn sicher ist, dass keine Nachricht mit Zeitstempel vtn <= t ankommen kann. (sonst Blockieren!)

Annahmen:

1. LPs tauschen Ereignisse mit Zeitstempeln aus (Nachrichten)
2. Statische Netzwerk-Topologie, keine dynamische Erzeugung von LPs
3. Nachrichten werden in Zeitstempelreihenfolge versendet
4. Netzwerk überträgt Nachrichten zuverlässig und in der richtigen Reihenfolge

Vorteile:

• Relativ einfache Realisierung (auch bei Parallelisierung sequentieller Simulatoren)

Nachteile:

• Langsamer Zeitfortschritt und schlechte Effizienz durch zahlreiche Kontrollnachrichten

Bei der optimistischen Simulation führen die LPs immer ihr nächstes lokales Ereignis aus, d.h. Kausalitätsverletzungen sind an sich möglich. Beim Empfang einer Nachricht mit Zeitstempel vtn <= t wird ein Korrekturmechanismus in Gang gesetzt, d.h. Rücksprünge in der virtuellen Zeit ("rollback" bzw. "timewarp") werden durchgeführt. D.h. ein Rückgängigmachen aller relevanten Aktionen (Zustand, simulierte Ereignisse, versandte Nachrichten) muss möglich sein.

Voraussetzungen:

1. LPs arbeiten Ereignisse lokal in Zeitstempelreihenfolge ab
2. Austausch externer Ereignisse über Nachrichten mit Zeitstempeln
3. Dynamische Netzwerktopologie erlaubt
4. Dynamische Hinzunahme von LPs erlaubt
5. Netzwerk: Zuverlässige Zustellung gefordert, aber Nachrichtenreihenfolge muss nicht erhalten bleiben

Vorteile:

• Potentielle Parallelität wird besser genutzt
• FIFO-Übertragung von Nachrichten nicht notwendig

Nachteile:

• Höherer Verwaltungsaufwand
• Hoher Speicherplatzbedarf durch Zustandsspeicherung
• Komplexe Realisierung
•  u.U. großer Overhead

Ein Deadlock kann bei einem Zyklus von LPs auftreten, wobei ein LP auf den anderen LP wartet, so dass kein LP mit der Zeit fortschreiten kann. Die Simulation befindet sich im Deadlock.

Deadlocks können durch "null"-messages vermieden werden. Dabei sendet jeder LP eine null-message mit Angabe einer unteren Schranke für Zeitstempel zukünftiger Nachrichten an den benachbarten LP.

1. Null Message Algorithmus (auf jedem LP ausgeführt):

WHILE (Simulation nicht beendet)

1. warte bis jede FIFO-Queue mindestens eine Nachricht enthält
2. Entferne Ereignis mit kleinstem Zeitstempel von der FIFO-Queue und arbeite dieses Ereignis ab
3. Sende Null-messages mit unterer Schranke für Zeitstempel zukünftiger Nachrichten an benachbarte LPs (aktuelle Zeit + lookahed)

END LOOP

2. Beispiel (siehe Bild):

• LHR zu Beginn bei Zeit 5
• LHR sendet Null-message mit zeitstempel 8 an MUC
• MUC sendet Null-Message an VIE mit Zeitstempel 11
• VIE kann nun Nachricht mit Zeitstempel 7 abarbeiten

Der Lookahead-Wert L gibt Auskunft darüber, dass ein Prozess zum Zeitpunkt T nur Ereignis-Nachrichten verschicken wird, die mindestens einen Zeitstempel von T+L haben wird. Dabei hängt der Lookahead-Wert vom Modell ab und kann aus folgenden Größen abgeleitet werden:

1. von physikalischen Nebenbedingungen des realen Systems (z.B. maximale Fahrtgeschwindigkeit eines Panzers)
2. von charakteristischen Eigenschaften der Modell-Komponenten (z.B. Reaktionszeiten)
3. von der Toleranzgrenze gegenüber zeitlichen Ungenauigkeiten (diese Grenze kann als Lookahead benutzt werden)
4. Vorausberechnung von Simulationsaktivitäten (z.B. "future lists" für Zufallszahlen)

Als Beispiel kann die Simulation des Flugverkehrs betrachtet werden. Werden zwei Flughäfen durch zwei LPs dargestellt und ist bekannt, dass die Flugzeit zwischen den beiden Flughäfen 3 Stunden beträgt, so haben diese LPs für die Kommunikation untereinander einen Lookahead-Wert von 3. LP1 weiß genau, wenn zum Zeitpunkt T ein Ereignis bearbeitet wird, das durch eine Ereignis-Nachricht eine Landung bei LP2 einplant, so muss dieses Ereignis einen Zeitstempel von mindestens T+3 haben. Somit schickt LP1 eine Null-Nachricht an LP2 mit Zeitstempel T+3. LP2 kann seinerseits alle Ereignisse bis zum Zeitpunkt T+3 abarbeiten und Null-Messages verschicken; die Simulationszeit schreitet voran.

Die Performance des Null-Message-Algorithmus im abhängig vom Lookahead-Wert. Je kleiner der Wert, desto mehr Null-Messages müssen verschickt werden, um in der Zet voranzuschreiten. Ein Lookahead-Wert von 0machten den Algorithmus unbrauchbar, da hier ein endloser Zyklus von Null-Nachrichten mit dem selben Zeitstempel entsteht.

Transiente Nachrichten dienen dem asynchronen Nachrichtentransfer, d.h. der Sender einer Nachricht kann mit den Berechnungen fortfahren, bevor bekannt ist, dass die Nachricht empfangen wurde.

Problem:

• Nachrichten, die "unterwegs" sind

Auftreten z.B. bei Berechnung von:

• Sicheren Ereignissen (konservativ)
• Barrieren-Synchronisation
• Global Virtual Time (optimistisch)

Vorgehen:

• Voraussetzung: FIFO-Kommunikation (keine Reihenfolgeäderungen)
• Verwende Nachrichtenzähler (gesendet/empfangen) in jedem LP
• Keine transienten Nachrichten, wenn die Summe der beiden Zähler über alle LPs gleich ist

Bei Empfang einer Nachricht aus der virtuellen Vergangenheit (sog. "straggler message")

• Rücksetzen der LVT auf eine VT kleiner als der Zeitstempel der straggler message
• Wiederherstellen der Zustandsvariablen und der aktuellen Ereignisliste dieser VT
• Versenden einer Antinachricht zu jeder versandten Nachricht mit einem Zeitstempel T > LVT

1. Copy state saving:

=> Zustand vor bzw. nach jedem Ereignis wird gespeichert

Vorteile:

• Technik unabhängig von der Simulationsanwendung

Nachteile:

• Ereignisausführung wird durch Anlegen von Checkpoints verlangsamt (ineffizient, wenn sich nur wenig Zustandsvariablen ändern)
• Verbraucht sehr viel speicher

2. Infrequent state saving / Checkpointing:

=> Zustand wird in (regelmäßigen) Abständen gespeichert

Vorteile:

• Weniger Overhead für State-saving
• Weniger Speicherbedarf
• Weitgehende Unabhängigkeit von der Simulationsanwendung

Nachteile:

• Erhöhung der für Rollbacks benötigten Zeit
• Erhöhte Komplexität für Timewarp Implementierungen

3. Incremental state saving:

=> Nur Änderungen von Zustandsvariablen werden gespeichert

Vorteile:

• Effizienter als copy state saving, wenn die meisten Zustandsvariablen nicht bei jedem Ereignis verändert werden
• Kann auch zusätzlich zu copy state saving verwendet werden

Nachteile:

• Muss zusätzlich zu den modifizierten Variablen noch deren Adressen speichern
• Höherer Implementierungsaufwand

4. Backward-Computing:

=> Einzelnes Rückgängig-Rechnen von Ereignissen

Vorteile:

• Reduziere Overhead bei Ereignisberechnung
• Reduizerter Speicherbedarf

Nachteile:

• Wesentlich komplexerere Implementation

Eine virtuelle Umgebung wird als "verteilt" bezeichnet, wenn sie auf zwei oder mehr vernetzten Computern ausgeführt wird, die die Berechnung der Simulation der virtuellen Welt gemeinsam durchführen.

Ziel hierbe ist die Ermöglichung von Interaktionen mehrerer, voneinander entfernter Benutzer in einer gemeinsamen virtuellen Welt.

• Einbettung von Benutzer
  => Interaktion
• Hinreichend realistische Repräsentation eines tatsächlichen oder fiktiven realen Systems
  => "Virtual World"
• Wahrnemung der Benutzer als Qualitätsmaßstab
• Selektive Auflösung
• "Fair Fight": Gleichwertige Behandlung aller Benutzer

Analytische Simulation:

1. So schnell wie möglich, d.h. ohne Schrittmacher (unpaced)
2. Meist enge geographische Kopplung (Typisch: Mehrprozessorrechner)
3. Wiederholbarkeit meist strenge Forderung
4. Synchronisation: Strikte Forderung nach Kausalität bzw. strenger zeitlicher Anordnung von Ereignissen

Verteilte virtuelle Umgebungen:

1. Meis in Echtzeit bzw. skalierte Echtzeit (paced)
2. Oft geographische/räumliche Verteilung der beteiligten Rechner (LAN/WAN)
3. Exakte Wiederholbarkeit oft nicht kritisch
4. Synchronisations-Anforderungen weniger streng: Wahrnehmung des Benutzers als Kriterium (mit Toleranzgrenzen)

1. Architektur mit zentralem Server

• Nutzer loggen sich auf zentralem Server ein
• Nur Simulationsberechnungen zu Einheiten, die vom Client "besessen" werden, werden dort ausgeführt
• Hauptaufgabe auf Client-Seite: Visualisierung
• Globaler Zustand der Simulation (z.B. Position aller Einheiten) wird im Server verwaltet
• Computation-Only Einheiten (z.B. "Computer generated forces") im Server berechnet

Vorteile:

• Einfache Implementierung

Nachteile:

• Schlechte Skalierbarkeit
• Mangelnde Zuverlässigkeit

2. Architektur mit verteilten Servern:

• Nutzer loggen sich auf Zugangsserver ein
• Hauptaufgabe auf Client-Seite: Visualisierung
• Zustand der Simulation (z.B Position aller Einheiten) wird auf Servern verteilt verwaltet
• Schnelle Verbindung zwischen Servern für Konsistent-Haltung des verteilten Zustands
• Höhere Rechenleistung für komplexe Modelle und Computer generated Forces

Vorteile:

• Bessere Skalierbarkeit
• Schnelle Kommunikationskanäle zwischen Servern

Nachteile:

• Möglichkeit zur Redundanz

3. Serverlose Architektur

• Simulationsberechnungen werden lokal durchgeführt
• Zustand der Simulation (z.B. Positionen aller Einheiten) wird auf allen beteiligten Rechnern verteilt verwaltet
• Nachrichten-basierte Kommunikation
• z.B. Kopplung vorhandener Simulationssysteme

Vorteile:

• Bessere Verteilung
• Kommunikation zwischen Client/Server direkt möglich

Nachteile:

• problematische Wartung!

DIS steht für Distributed Interactive Simulation und ist ein Datenaustauschstandard zur Steuerung von Simulationssystemen. Mittels DIS vernetzte Simulationssysteme können in Echtzeit simulierte Informationen austauschen und versetzen so die Nutzer der damit vernetzten Systeme in die Lage, in ihrem jeweiligen Simulator eine identische Umweltdarstellung wahrzunehmen.

Vorteile:

• Einfacher Aufbau einer Simulation
• Keine Management-Funktionalitäten
• Sehr schnell
• PDUs einfach mit Netzwerkmonitor interpretierbar
• Niedrige LAN-Netzlast durch Broadcast

Nachteile:

• Bei der Implementierung einer DIS-Simulation muss viel Netzwerk-Code selbst geschrieben werden
• evtl. Routing-Schwierigkeiten zwischen Subnetzen (da Broadcast), die aber durch einen Forwarder behoben werden können

1. Autonome Simulationsknoten
   • Vereinfacht Erstellung und Integration von Simulatoren in verteilte virtuelle Umgebungen
   • DIS Knoten ist verantwortlich für Zustände von einer oder mehreren Einheiten (z.B. Panzer), sowie für die Darstellung des Zustands relevanter externer Einheiten (z.B. anderer Panzer)
   • Informationen werden über genormte Nachrichten (PDUs - Protocol Data Units) ausgetauscht
   • DIS Knoten bestimmt NICHT die Empfänger der Nachrichten
   • Zeitsteuerung erfolgt lokal über Hardware-Uhren, d.h. keine Koordination zwischen Simulatoren
2. Übertragung von tatsächlichen Zuständen ("ground truth" information)
   • Jede Abweichung von dieser Tatsacheninformation muss beim Empfänger geschehen (um z.B. eingeschränkte Sicht oder ungenaue Sensoren zu simulieren)
3. Übertragung ausschließlich von Zustandsänderungen
   • Zur Senkung der Nachrichtenströme werden nur Zustandsaktualisierungen übertragen
4. Nutzung von Dead Reckoning Algorithmen
   • Um die Anzahl von Zustandsaktualisierungen weiter zu reduzieren, werden Zustände externer Einheiten lokal extrapoliert

Unter Dead Reckoning (= Koppelvaigation) versteht man das Abschätzen von Zustandsvariablen (insbesondere Position) durch Extrapolation mit Hilfe von Geschwindigkeit, Beschleunigung etc. Dadurch verringert sich die Anzahl der zu verschickenden Nachrichten innerhalb einer virtuellen Umgebung enorm, da das lokale Dead Reckonoing Modell (DRM) die Position externer Objekte zwischen den Updates mittels Schätzung voraussagt. Auch die eigene Position wird per DRM ermittelt und mit der exakten Position verglichen. Falls die Abweichung zu groß ist, werden Positionsupdates gesendet. Diskontinuitäten beim Empfänger der Updates kann Sprünge inder Visualisierung verursachen. Die Latzenzzeit der Nachrichten wird nicht berücksichtigt (Zeitstempel der Nachricht wird in Berechnung mit einbezogen).

High Level Archiitecture ist eine Architektur für verteile Simulation zur Untersützung der Interoperabilität und Wiederverwendbarkeit von verschiedenen Arten von Programmen. Die Kopplung von unterschiedlichen Simulatoren (Federates) bilden dabei die sog. Federation (modularer, zusammensetzbarer Ansatz zur Bildung von
Simulationsföderationen). Die HLA ermöglicht somit eine variable Größe von Szenarien und Anzahl von Bedienern.
 

1. Interoperabilität
   => Simulationen müssen fähig sein, Daten auszutauschen und diese sinnvoll zu interpretieren
2. Wiederverwendbarkeit
   => Simulationen müssen wohldefinierte und wohldokumentierte Schnittstellen aufweisen
3. Föderationen von Simulationen
   => Unterschiedliche Simulationen (sog. Federates) formen eine Föderation
4. Differenzierung zwischen Simulationsfunktionalität und Basisdiensten
   • Alle Basisdienste (Datenaustausch / Kommunikation) werden von einer Runtime Infrastructure (RTI) bereitgestellt, welche über eine wohldefinierte Schnittstelle mit den Simulationen gekoppelt ist
   • Objektsichtweise auf Simulationen: alle modellierten Elemente werden als "Objekte" bezeichnet
     • Attribute zur Modellierung der Charakteristika und Zustände
     • Interaktionen zur Modellierung der Kommunikation / Wechselwirkung zwischen Objekten
     • Keine Restriktionen bzgl. der Implementation innerhalb der Simulationen

Die HLA basiert auf drei Grundkomponenten:

1. Interface Specification:
   • definiert die Schnittstelle zwischen den Einzelsimulationen und der RTI
   • Programmbibiliotheken, die die Funktionen und Datenstrukturen für die Kommunikation zwischen der RTI und der Federates beinhaltet
2. Object Model Template (OMT):
   • definiert, welche Informationen zwischen den Simulationen ausgetauscht werden sollen und wie diese zu dokumentieren sind
3. HLA-Regeln:
   • Definiert die Regeln, die eine Simulation einhalten muss, um standardkonform zu sein

Die Runtime Infrastructur (RTI) überwacht den Simulationsablauf und verwaltet die Verteilung der Daten zwischen den Federates. Die RTI setzt sich aus folgenden Dienstgruppen zusammen:

1. Federation Management
   • Erstellen und Löschen von Federation Executions
   • An- und Abmelden von Federation Executions
   • Checkpoints, Synchronisationspunkte, Restart
2. Decleration Management
   • Publikation und Subskription von Objektattributen und Interaktionen
3. Object Management
   • Erstellen und Löschen von Objekt-Instanzen
   • Austausch von Attribut-Updates u. Interaktionen
4. Ownership Management
   • Besitzübergabe von Objektattributen
5. Time Management
   • Koordination des logischen Zeitfortschritts
6. Data Distribution Management
   • Unterstützung effizienten Datenroutings

Um den Traffic zu verringern, werden die Daten nicht mittels Broadcast versendet (wie bei DIS), sondern werden sinnvoll am diejenigen verteilt, die diese Daten gerade benötigen. Daten können also subskribert werden. Dabei unterscheidet man zwischen statischer und dynamischer Datenverteilung.

Statische Datenverteilung:

• Berücksichtigt nur statische Eigenschaften, die sich während der Ausführung nicht ändern
• Beispiel: Declaration Management in der HLA
  • Klassenbasierte Datenverteilung
  • Subskribierte Positions-Attribute aller Objekte der Klasse "Panzer"

Dynamische Datenverteilung:

• Berücksichtigt dynamische Größen, die sich während der Ausführung ändern können
• Beispiel: Data Distribution Management in der HLA
  • Routing spaces
  • Subskribiere Positions-Attribute von "Panzer" Objekten in meinem Sektor der Landkarte

Dynamische Datenverteilung:

Jeder Federate hat eine (abstrakte) logische Zeit, diese ist für die HLA dimensionslos, d.h.
sie unterliegt der Vereinbarung innerhalb der Federation. Federates müssen ihren lokalen Zeitfortschritt beantragen mit Next Event Request oder Time Advance Request. Das Federate zeigt damit an, dass es vor der beantragten Zeit keine neuen Nachrichten erzeugen wird (falls es nicht neue Nachrichten empfängt). Die RTI vergibt ein "Time Advance Grant", sodass keine Nachrichten mit einem kleineren Zeitstempel erlaubt sind, falls ein Zeitstempel einmal genehmigt wurde.

• Angabe von Lookahead ist erforderlich
• Federates beantragen Zeitfortschritt mit "NextEventRequest" und bekommen einen "TimeAdvanceGrant" als Antwort
• Bei Update von Attributen schickt ein Federate "UpdateAttributValues", empfangende Federates erhalten daraufhin ein "ReflectAttributeValues"

Time-Regulating: Federate kann Ereignisse versenden

Time-Constrained: Federate ist zeitsynchron mit der HLA. Dadurch ist das Federate in der Lage Zeitfortschritt zu beantragen (nur wenn auch Time-Regulating) sowie Ereignisse nach ihrem Zeitstempel sortiert zu verarbeiten (Time Stamp Order - TSO). Federates die nicht time-constrained sind verarbeiten Ereignisse immer nur in Ankunfsreihenfolge (Receive Order - RO).