Clever Geek Handbook

Verteilte Simulationssysteme



Um einzelne Simulatoren zu einem verteilten Simulationssystem kombinieren zu können, werden derzeit folgende Standards und Technologien verwendet:



  • IEEE1516 (ersetzt auch HLA und DIS)
  • OPC;
  • CAPE-OPEN und andere "Industriestandards".


Von größtem Interesse ist der IEEE 1516-Standard, da dieser Standard sich direkt auf Simulatoren bezieht und auf den Aufbau verteilter Simulationssysteme (Protokolle, empfohlene Steuerungs- und Rückkopplungsmethoden, Systemarchitektur usw.) abzielt.



Die Familie der OPC-Softwaretechnologien (OLE for Process Control), die eine einzige Schnittstelle für die Verwaltung von Automatisierungsobjekten und technologischen Prozessen bieten, ist ebenfalls von erheblichem Interesse, jedoch nur, wenn eine Integration mit Automatisierungsobjekten und technologischen Prozessen erforderlich ist. Der CAPE-OPEN-Standard wird für die Interaktion von Simulatoren verwendet, die speziell für die chemische Industrie entwickelt wurden.



Das Institut für Elektro- und Elektronikingenieure (IEEE) hat wesentliche Beiträge zur Standardisierung von Modellierung und Simulation geleistet. Die verteilte Modellierung (Simulation) ist eine Technologie für den Datenaustausch zwischen Simulatoren über lokale oder globale Computernetzwerke. Dadurch können einzelne Simulatoren als ein gesteuertes Modellierungs- oder Simulationssystem zusammenarbeiten. Das verteilte Modellierungskonzept basiert auf der Verwendung einer High-Level-Architektur (HLA). In der Praxis definiert der IEEE 1516-Standard die Architektur mithilfe einer einzigen API (Application Programming Interface). Die Ausgangspostulate des Standards sind:



  1. einfache "monolithische" Simulationsmodelle können die Anforderungen professioneller Benutzer nicht erfüllen;
  2. Alle möglichen Anwendungen der Simulation sind im Voraus unbekannt.
  3. Die Möglichkeit einer willkürlichen Kombination einzelner Simulatoren zu komplexen Simulationssystemen sollte bereitgestellt werden.
  4. Die verteilte Modellierungsarchitektur sollte für zukünftige Modellierungs- und Simulationstechnologien so offen wie möglich sein.


Derzeit ist IEEE 1516 der absolute Standard für die Interaktion von Simulatoren und Simulatoren in militärischen Anwendungen, da strenge Anforderungen an die Kompatibilität mit Simulatoren gestellt werden, die vom US-Verteidigungsministerium und der NATO entwickelt und verwendet werden. Derzeit wird IEEE 1516 zunehmend im zivilen Bereich eingesetzt, um Simulatoren für die Schulung von Personal komplexer technischer Systeme in der Luftfahrt, Astronautik, im Transportwesen usw. zu entwickeln.



Die OPC-Familie von Softwaretechnologien wurde entwickelt, um die Kosten für die Erstellung und Wartung industrieller Automatisierungsanwendungen zu senken. In den frühen 90er Jahren benötigten Entwickler industrieller Software ein universelles Tool für den Datenaustausch mit Geräten verschiedener Hersteller oder mit unterschiedlichen Kommunikationsprotokollen. OPC bietet Entwicklern industrieller Software eine universelle feste Schnittstelle für den Datenaustausch mit jedem Gerät. Gleichzeitig stellen Geräteentwickler ein Programm zur Verfügung, das diese Schnittstelle implementiert.



Um komplexe Simulationssysteme zu erstellen, können Sie die Verwendung von IEEE 1516 und OPC kombinieren und so die Möglichkeit erhalten, reale Geräte und SCADA-Systeme zu verwenden (Abbildung), was bei vielen Aufgaben sehr nützlich sein kann.



Die Kommunikation zwischen den IEEE 1516-Standards (die für Simulatoren grundlegend sind) und OPC (in SCADA-Systemen verwendet) kann entweder direkt im Simulator oder über einen Vermittler implementiert werden. Die Rolle eines solchen Vermittlers übernimmt für mich beispielsweise das National Instruments LabView-Paket. LabView unterstützt mathematische Modelle jeder Komplexität, verfügt über eine integrierte OPC-Unterstützung, kann als OPC-Server fungieren, bietet eine effektive Unterstützung für die Interaktion mit verschiedenen E / A-Karten, sodass Sie die erforderlichen Geräte direkt verwenden können, verfügt jedoch leider nicht über Interaktionsmöglichkeiten mit IEEE 1516 Dies erfordert das Schreiben der entsprechenden Softwarekomponenten.



Durch die Verwendung von IEEE 1516 und OPC ist es möglich, relativ komplexe verteilte Simulationssysteme zu erstellen, einschließlich vieler Simulatoren, realer Geräte, SCADA-Systeme usw. Die



Frage der Zertifizierung eines Simulators oder von Simulatoren hinsichtlich der Unterstützung des IEEE 1516-Standards verdient eine gesonderte Prüfung . Verbände in der IEEE 1516-Terminologie) und Softwarebibliotheken, die Interaktion implementieren. Der Zweck dieser Zertifizierung besteht jedoch nicht darin, Funktionsmängel des Programms zu identifizieren (nur die Zertifizierung der Unterstützung für den IEEE 1516-Standard).



Zertifizierungsfähige Organisationen:



  • USA. Das Modellierungs- und Simulationskoordinierungsbüro des Verteidigungsministeriums (DoD) (M & S CO). Website: www.msco.mil
  • . ONERA. (Office National d’Etudes et Recherches Aérospatiales) is the French national aerospace research center. : www.onera.fr
  • . Pitch Technologies AB. : www.pitch.se














Betrachten wir die Probleme beim Aufbau verteilter Simulationssysteme auf der Grundlage des IEEE 1516-Standards. Die in der Informationsunterstützung verwendeten Grundbegriffe entsprechen der Terminologie der verteilten interaktiven IEEE 1516-Simulationssysteme - dies sind Verbund, Verbund, Objekt, Attribut und Interaktion. Das Konzept eines Objekts wird als Modell eines separaten Phänomens in der realen Welt definiert. Objekte haben keine Methoden, sie haben nur Zustände (nur eine Datenstruktur ohne Funktionen zu ihrer Verarbeitung). Der Zustand von Objekten ist durch einen festen Satz von Attributen gekennzeichnet - genaue Werte, die sich im Laufe der Zeit ändern können. Jedes Objekt ist zu jeder Zeit durch seinen Zustand gekennzeichnet, der durch eine Reihe aktueller Werte seiner Attribute bestimmt wird. Federates sind mathematische Beschreibungen des Verhaltens von Objekten - Simulationsmodelle,softwaredefiniert (in Direktivensprache implementiert) oder durch Hardware-Sensorwerte dargestellt. In der Tat können Feds sowohl Nachahmer als auch reale Geräte oder spezielle Software sein. Die einzige Voraussetzung ist die Bereitstellung einer einheitlichen Schnittstelle für die Kommunikation. Föderierte können Objekte bearbeiten, indem sie die Werte ihrer Attribute ändern (aktualisieren) oder abrufen (anzeigen). Insbesondere sind Benutzer von Imitatoren auch Verbündete. Das Aggregat aller an der Simulation beteiligten Verbände bildet einen Verband.Die einzige Voraussetzung ist die Bereitstellung einer einheitlichen Schnittstelle für die Kommunikation. Föderierte können Objekte bearbeiten, indem sie die Werte ihrer Attribute ändern (aktualisieren) oder abrufen (anzeigen). Insbesondere sind Benutzer von Imitatoren auch Verbündete. Das Aggregat aller an der Simulation beteiligten Verbände bildet einen Verband.Die einzige Voraussetzung ist die Bereitstellung einer einheitlichen Schnittstelle für die Kommunikation. Föderierte können Objekte bearbeiten, indem sie die Werte ihrer Attribute ändern (aktualisieren) oder abrufen (anzeigen). Insbesondere sind Benutzer von Imitatoren auch Verbündete. Das Aggregat aller an der Simulation beteiligten Verbände bildet einen Verband.



Der Begriff "Interaktion" ist definiert als eine Sofortnachricht (Ereignis), die nicht an eine bestimmte Objektinstanz oder einen Verbund gebunden ist und auf Verbundniveau auftritt (dh es ist unmöglich, den Absender zu bestimmen). Interaktionen werden im Gegensatz zu den Zuständen von Objekten nicht ständig im System aufrechterhalten, sondern sind augenblicklicher Natur. Ein Beispiel wäre eine einseitige Übertragung einer Textnachricht an alle interessierten Verbandsmitglieder. Das hierarchische Verbundschema (HLA / IEEE 1516) ist in der Abbildung dargestellt



Die Interaktion von Föderierten erfolgt mithilfe eines allgemeinen Interaktionsmechanismus (RTI), der als Abonnement implementiert ist. Ein Verband, der bestimmte Attribute und Interaktionen eines anderen Verbandes erhalten möchte, muss diese über die RTI abonnieren. Der Mechanismus zum Anfordern, Bereitstellen und Ändern von Attributwerten ist in der Abbildung dargestellt. Der Mechanismus zum Organisieren der verteilten Simulation und Zusammenarbeit ist in der Abbildung dargestellt.





Bild. Hierarchisches Verbundschema



Objekte im Simulator sind in der Regel 3D-Modelle bzw. Schallquellen. Die Attribute solcher Objekte sind Position und Ausrichtung in Raum, Größe, Volumen usw. In Bezug auf Simulatoren können die Aktionen des Benutzers (Verband), beispielsweise die Aufnahme eines Schlüssels, als Interaktionen betrachtet werden.





. (RTI)





. (RTI)





.



Bei der Erstellung verteilter Simulationssysteme, die über RTI interagieren, müssen die folgenden wichtigen Funktionen berücksichtigt werden. Alle Elemente von Verbänden und Verbänden müssen in bestimmten Dateien dokumentiert sein (FOM-Dateien (Föderationsobjektmodell) werden zur Beschreibung des Verbunds verwendet), Verbände werden in SOM-Dateien (Simulationsobjektmodell) beschrieben. Alle Daten werden nur in Verbänden gespeichert, RTI speichert keine Daten, sondern überträgt sie nur. Mit HLA kann jeweils nur ein Verbund den Wert eines Attributs ändern (es gibt einen speziellen Mechanismus zur Rechteverwaltung für die Übertragung von Rechten). Föderierte können die Ortszeit verwalten, HLA verwendet verschiedene interne Zeitverwaltungsmechanismen (Synchronisation).



Im Allgemeinen behandelt der IEEE 1516-Standard eine Vielzahl von Problemen im Zusammenhang mit der Erstellung verteilter Simulationssysteme, z. B. die Aufrechterhaltung des Status des Verbandes, die Erneuerung des Status, verschiedene Zeitsynchronisationsmechanismen, die Interaktionsbereiche von Verbänden usw. Aufgrund des erheblichen Umfangs des Standards selbst und des Umfangs des Programmcodes zur Demonstration aller im Standard beschriebenen Aspekte wird im Folgenden nur die grundlegende Implementierung der "grundlegenden" Funktionen demonstriert (Abbildung).





Bild. Blockdiagramm zur Implementierung der grundlegenden Funktionen nach IEEE 1516



Eine detailliertere Darstellung der Implementierung ist mit der Notwendigkeit verbunden, eine ziemlich große Liste des Programms vorzulegen. Aus diesem Grund kann der Leser die Beispiele von Programmen, die mit der Software geliefert werden, unabhängig voneinander zur Unterstützung von RTI verwenden. Einfache Beispiele mit vielen Kommentaren sind in der The Portico Project-Bibliothek enthalten und unter porticoproject.org frei verfügbar . Fast alle kommerziellen Implementierungen des Standards enthalten auch viele Beispiele.



Betrachten Sie als Beispiel den folgenden Verband, der aus zwei Verbänden besteht: einem ferngesteuerten Auto und einem Bedienfeld. Angenommen, die Steuerung erfolgt durch Einstellen der Drehzahl für jeden der 4 Motoren des Fahrzeugs und Drehen der Vorderräder. Die Maschine ist mit einem Sensor ausgestattet, der den Abstand zum Hindernis ermittelt und ein Signal an das Bedienfeld sendet. Dazu müssen zwei Objektklassen definiert werden, cYpravlenie für das Bedienfeld und cDatchik für den Abstandssensor. Die Attribute der cYpravlenie-Klasse sind Rad1, Rad2, Rad3, Rad4, Radwinkel. Das cDatchik-Klassenattribut ist distance. Das Folgende ist eine Verbundbeschreibungsdatei im HLA 1.3-Format (Interaktionen werden als Beispiel angegeben). 



;;  —   (FED )   HLA 1.3

(Fed 
  (Federation Test) 
  (FedVersion v1.3) 
  (Federate "fed" "Public") 
  (Spaces 
	(Space "Geo" 
		(Dimension X) 
		(Dimension Y) 
	) 
  ) 

(Objects 
	(Class cYpravlenie 
		(Attribute wheel1 reliable timestamp) 
		(Attribute wheel2 reliable timestamp) 
		(Attribute wheel3 reliable timestamp) 
		(Attribute wheel4 reliable timestamp) 
		(Attribute wheel_angle reliable timestamp) 
	) 
	(Class cDatchik 
		(Attribute distance reliable timestamp) 
	) 
) 
	 
(Interactions 
	(Class reaction BEST_EFFORT RECEIVE 
	(Sec_Level "Public") 
		(Parameter dx) 
		(Parameter dy) 
		(Parameter dz) 
	) 
) 

)


Als nächstes erstellt der Simulator, der das Steuerelement darstellt, einen Verbund und ein Objekt basierend auf der cYpravlenie-Klasse. Der Simulator, der das Auto darstellt, erstellt auch einen Verbund und ein Objekt basierend auf der cDatchik-Klasse. Die Föderierten abonnieren auch die Änderungen, an denen sie interessiert sind, d. H. Der Verbundcomputer abonniert den Empfang von Objektdaten von der cYpravlenie-Klasse (d. H. Der cYpravlenie-Klasse) und die Verbundsteuerung für die cDatchik-Klasse. Somit empfängt die Maschine Änderungen vom Bedienfeld und das Bedienfeld empfängt Daten vom Sensor im Fahrzeug.



Der Aufbau komplexerer Simulationssysteme erfordert ein ernsthaftes Design. Zunächst ist es notwendig, die Hauptzusammensetzung des Verbunds in erster Näherung zu bestimmen, d. H. Verbände, Verbundobjekte und Objektattribute. Bei der Erstellung des Verbundschemas müssen die Hardwarekomponenten der verteilten Simulationssysteme berücksichtigt werden, d. H. Sensoren und Steuerhardwaregeräte sollten auch in Form von Verbundsystemen, Objekten und Attributen dargestellt werden. Auf dem Bild. zeigt den Aufbau des Verbunds des Saugstabpumpen-Installationssimulators.





Bild. Föderationsstruktur



Nachdem der Verbund zusammengestellt wurde, müssen Verknüpfungen definiert werden, dh eine Reflexion darüber, welche Verbände die Attribute von Objekten veröffentlichen (dh ändern) und welche Änderungen dieser Attribute abonnieren. In der Regel werden in der Phase der Definition von Links zahlreiche "Änderungen" für die Struktur des Bundes festgelegt. Nach der erforderlichen Anzahl von Iterationen der "Verfeinerung" der Struktur und der Beziehungen müssen die Designer die Tatsache der "Modellkorrektheit" des Verbandes feststellen. Ein Beispiel für die Definition von Links ist in der Abbildung dargestellt (Objekte ohne Links sind ausgeblendet).





Bild. Ein Beispiel für die erste Stufe der Definition von Links



In der nächsten Stufe wird die erforderliche Anzahl von Computern und die entsprechende Verteilung von Verbänden bestimmt. Beispielsweise funktioniert der Verbund "A" auf dem Computer "1", die Verbände "B, C, D" auf dem Computer "2".





Bild. Verteilung von Föderierten durch Computer



In der Regel basiert die Verteilung von Föderierten auf der Wirtschaftlichkeit ihres mathematischen Modells. Wenn die mathematischen Modelle von Föderierten keine signifikanten Rechenressourcen erfordern, kann ein Computer verwendet werden. Wenn die mathematischen Modelle von Föderierten signifikante Rechenressourcen erfordern, ist es erforderlich, die Anzahl der Computer und die entsprechende Verteilung der Föderationen zu bestimmen.



Der nächste Schritt besteht darin, eine Verbundbeschreibungsdatei (siehe Beispiel oben) zu erstellen, die das genehmigte "richtige Modell" des Verbunds widerspiegelt. Anschließend erstellen Sie eine Softwareimplementierung von Verbänden, indem Sie den entsprechenden Code für die Interaktion mit der RTI und den Code für die Implementierung des mathematischen Modells des Verbunds schreiben. In der letzten Phase ist es erforderlich, das verteilte Simulationssystem zu testen, Fehler, "Überlastungen" bestimmter Komponenten im System (basierend auf Statistiken) zu identifizieren, die Synchronisation zu korrigieren usw. Die



Statistiken für jeden Verbund einzeln und für den Verbund insgesamt zeigen die Anzahl und Art der ausgeführten Abfragen an und ermöglicht es Ihnen, mögliche Probleme während des Betriebs des Systems zu identifizieren.



Beispielstatistik für einen Verband: 



RTIA: Statistics (processed messages)
Joined federation as car_federate
Synchronization point announced: ReadyToRun
Achieved sync point: ReadyToRun, waiting for federation...
Federation Synchronized: ReadyToRun
Time Policy Enabled
Published and Subscribed
Add instance object: obj_datchik
Removing temporary file _RTIA_3033_ExampleFederation.fed on resign federation.
Resigned from Federation
Didn't destroy federation, federates still joined
List of federate initiated services 
--------------------------------------------------
1 Message::CLOSE_CONNEXION (MSG#1)
1 Message::DESTROY_FEDERATION_EXECUTION (MSG#3)
1 Message::JOIN_FEDERATION_EXECUTION (MSG#4)
1 Message::RESIGN_FEDERATION_EXECUTION (MSG#5)
1 Message::SYNCHRONIZATION_POINT_ACHIEVED (MSG#10)
1 Message::PUBLISH_OBJECT_CLASS (MSG#28)
1 Message::SUBSCRIBE_OBJECT_CLASS_ATTRIBUTES (MSG#32)
1 Message::SUBSCRIBE_INTERACTION_CLASS (MSG#34)
1 Message::REGISTER_OBJECT_INSTANCE (MSG#40)
1708 Message::UPDATE_ATTRIBUTE_VALUES (MSG#41)
855 Message::TIME_ADVANCE_REQUEST (MSG#91)
3 Message::GET_OBJECT_CLASS_HANDLE (MSG#112)
6 Message::GET_ATTRIBUTE_HANDLE (MSG#114)
1 Message::GET_INTERACTION_CLASS_HANDLE (MSG#116)
120516 Message::TICK_REQUEST (MSG#141)
2564 Message::TICK_REQUEST_NEXT (MSG#142)
List of RTI initiated services 
--------------------------------------------------
1 NetworkMessage::ANNOUNCE_SYNCHRONIZATION_POINT (MSG#13)
1 NetworkMessage::FEDERATION_SYNCHRONIZED (MSG#15)
1 NetworkMessage::DISCOVER_OBJECT (MSG#43)
1711 NetworkMessage::REFLECT_ATTRIBUTE_VALUES (MSG#45)
49 NetworkMessage::GET_FED_FILE (MSG#84)
Number of Federate messages : 125662
Number of RTIG messages : 1763
RTIA: Federate destroyed
TCP Socket 3 : total = 122015 Bytes sent 
TCP Socket 3 : total = 340249 Bytes received
UDP Socket 4 : total = 0 Bytes sent 
UDP Socket 4 : total = 0 Bytes received
	     :
CERTI RTIG up and running ... 
New federation: ExampleFederation 
Looking for FOM file... 
   Trying... open_test.fed --> cannot access. 
   Now trying.../usr/local/share/federations/open_test.fed... opened. 

 TCP Socket  7 : total =    340400 Bytes sent 
 TCP Socket  7 : total =    122015 Bytes received 
 UDP Socket  4 : total =         0 Bytes sent 
 UDP Socket  4 : total =         0 Bytes received 
 TCP Socket  6 : total =    258616 Bytes sent 
 TCP Socket  6 : total =    283044 Bytes received 
 UDP Socket  4 : total =         0 Bytes sent 
 UDP Socket  4 : total =         0 Bytes received


Zeitsynchronization



Wie die Praxis des Entwurfs und der Implementierung verteilter Simulationssysteme gezeigt hat, hängen die schwierigsten Probleme mit der Steuerung des Zeitflusses (Zeitsynchronisation) zusammen.



Wenn Sie festlegen, wie die Verbundzeit synchronisiert wird, werden normalerweise zwei Parameter festgelegt: TimeRegulating und TimeConstrained. In der Praxis wirken sich diese Modi auf den Empfang von Nachrichten von anderen Verbänden aus und stehen in direktem Zusammenhang mit dem Mechanismus zur Reihenfolge von Nachrichten:

  • in der Reihenfolge des Empfangs (Nachrichten werden in der Reihenfolge gesendet, in der sie ohne Zeitkontrolle empfangen wurden);
  • Priorität (eingehende Nachrichten befinden sich in einer Prioritätswarteschlange, ihr Zeitstempel wird verwendet, um die Priorität einer Nachricht zu bestimmen);
  • kausal (stellt sicher, dass Nachrichten in einer Reihenfolge an die Verbände gesendet werden, die mit den vorhergehenden und nachfolgenden Ereignissen übereinstimmt, die durch diese Nachrichten dargestellt werden);
  • nach Zeitstempeln (bei Verwendung dieses Dienstes werden Nachrichten in der Reihenfolge ihrer Zeitstempel an Verbände gesendet).


Es ist auch erwähnenswert, dass verschiedene Verbände unterschiedliche Synchronisationsmethoden verwenden können.



Softwarebibliotheken für die RTI-Implementierung



Eine Liste der verfügbaren HLA \ IEE1516-Implementierungen finden Sie unter en.wikipedia.org/wiki/Run-Time_Infrastructure . Heutzutage ist eine ziemlich große Anzahl von Implementierungen verfügbar, sowohl kommerzielle als auch nichtkommerzielle. Die meisten Implementierungen werden in JAVA und C ++ durchgeführt (dies sind die Sprachen, die im Standard verwendet werden), es gibt jedoch auch Implementierungen für MatLab, Python (CERTI-Projekt) usw.



Bei der Auswahl einer Bibliothek sollte der "Zertifizierung" zur Unterstützung von IEEE 1516 besondere Aufmerksamkeit gewidmet werden. In der Regel Alle kommerziellen Implementierungen haben ein "Zertifikat", kostenlose nicht (viele der kostenlosen Implementierungen bereiten sich auf eine solche Zertifizierung vor).



Kommerzielle Verkaufstabelle:





Nichtkommerzielle Verkaufstabelle:





Ich persönlich verwende das ONERA-Projekt CERTI (https://savannah.nongnu.org/projects/certi), um die Infrastruktur verteilter Anwendungen zu unterstützen.



Messungen der Interaktionsgeschwindigkeit von Föderierten über RTI



Solche Tests sind beim Entwurf verteilter Simulationssysteme sehr wichtig, insbesondere wenn sich verschiedene Verbände in verschiedenen Computernetzwerken befinden, und noch wichtiger bei der Interaktion von Verbänden über das Internet.



Um die minimalen Zeitverzögerungen zu erreichen, müssen Sie den Server mit den geringsten Verzögerungen bei der Paketübertragung auswählen (Sie können dies mit dem Befehl ping überprüfen). Betrachten wir als Beispiel die Arbeit eines der verteilten Systeme, die am NII EOR von TyumGNGU erstellt wurden. Es wird ein 100-Megabit-Netzwerk verwendet (Ping-Verzögerungen <0,231 ms), es gibt keine Zeitsynchronisation (um Verzögerungen innerhalb von RTI zu reduzieren), 2 Computer, der Server (RTIG) wird auf einem der Computer ausgeführt. Verbundparameter - 2 Objekte enthalten 5 Attribute (ein Objekt pro Verbund / Computer), die Interaktion zwischen Verbänden erfolgt in beide Richtungen. Als Ergebnis der Verarbeitung der Messungen wurde die Abhängigkeit der Anzahl von Wechselwirkungen pro Sekunde von der Größe der übertragenen Daten erhalten.



Die Ergebnisse solcher Messungen erlauben es uns, viele Schlussfolgerungen zu ziehen, zum Beispiel, ob der Simulator in einer gegebenen "Echtzeit" arbeiten sollte, d. H. Aktualisieren Sie beispielsweise mindestens 60 Mal pro Sekunde, dann sollten für eine Interaktion (für Fast Ethernet) nicht mehr als 300 Kilobyte übertragen werden (wenn zum Beispiel 5 Attribute, dann jeweils 60 Kilobyte). Gleichzeitig weisen 300 Kilobyte Daten, die 60 Mal pro Sekunde übertragen werden, auf die Möglichkeit hin, RTI zur Übertragung von Sprach- und Videodaten zwischen Simulatoren sowie zur Interaktion mit VR-Geräten zu verwenden.



Bei einem Verbund über das Internet wird die minimale Latenz weitgehend durch die Paketübertragungsverzögerungen bestimmt. Wenn beispielsweise die Latenz eines Pakets zwischen dem Server und dem Simulator 300 ms beträgt, überschreitet die maximale Anzahl von Interaktionen pro Sekunde 3 nicht.



Die Verwendung schnellerer Lösungen wie IpoIB (IP über InfiniBand, RFC 4392), 10G Ethernet, Myrinet-10G usw. ermöglicht es, den Durchsatz zu erhöhen und die Latenz erheblich zu reduzieren (vorhandene Lösungen ermöglichen die Erzeugung von 30 Millionen Interaktionen pro Sekunde oder mehr).



Interaktion mit realen Systemen



Nicht nur mathematische Modelle von Objekten, dh künstliche Systeme, sondern auch reale Systeme und Geräte können als Verbund fungieren. Beispiele beinhalten:



  • Mikrofon mit Audiodaten;
  • Videokamera, die Videodaten bereitstellt;
  • verschiedene Ein- / Ausgabegeräte wie Joysticks (Bild), Drucker usw.
  • verschiedene Sensoren und Steuermechanismen, die über ADC / DAC-Karten mit dem Computer verbunden sind;
  • reale Geräte und SCADA-Systeme (Abbildung 2.10.1., Kapitel 1.4.1.) über die industrielle OPC-Schnittstelle;
  • Schnittstellen zum "Desktop" eines realen Betriebssystems, das auf einem separaten Computer oder einer virtuellen Maschine ausgeführt wird (Abbildung);
  • VR-Geräte (Kapitel 4.5.9.);
  • Datenbankschnittstelle usw.


Solche Möglichkeiten sind für Simulatoren und Simulationssysteme im Allgemeinen von erheblichem Interesse.


More articles:


All Articles