😭 🍌 👼 Systèmes de simulation distribués 🎵 👩🏿‍🔬 🆔

Pour pouvoir combiner des simulateurs individuels dans un système de simulation distribué, les normes et technologies suivantes sont actuellement utilisées:

IEEE1516 (remplace également HLA et DIS)
OPC;
CAPE-OPEN et autres normes «industrielles».

Le standard IEEE 1516 est le plus intéressant, car ce standard est directement lié aux simulateurs, visant à construire des systèmes de simulation distribués (protocoles, méthodes de contrôle et de rétroaction recommandées, architecture système, etc.).

La famille de technologies logicielles OPC (OLE for Process Control) qui fournit une interface unique pour la gestion des objets d'automatisation et des processus technologiques présente également un intérêt considérable, mais uniquement si l'intégration avec des objets d'automatisation et des processus technologiques est nécessaire. La norme CAPE-OPEN est utilisée pour l'interaction de simulateurs conçus spécifiquement pour l'industrie chimique.

L'Institut des ingénieurs électriciens et électroniciens (IEEE) a apporté une contribution significative à la normalisation de la modélisation et de la simulation. La modélisation distribuée (simulation) est une technologie d'échange de données entre simulateurs sur des réseaux informatiques locaux ou mondiaux. Cela permet aux simulateurs individuels de fonctionner ensemble comme un système de modélisation ou de simulation contrôlé. Le concept de modélisation distribuée est basé sur l'utilisation d'une architecture de haut niveau (HLA). En pratique, la norme IEEE 1516 définit l'architecture en utilisant une seule API (interface de programmation d'application). Les postulats de départ de la norme sont:

les modèles de simulation «monolithiques» simples ne peuvent pas répondre aux besoins des utilisateurs professionnels;
toutes les applications possibles de la simulation sont inconnues à l'avance;
la possibilité d'une combinaison arbitraire de simulateurs individuels dans des systèmes de simulation complexes devrait être prévue;
L'architecture de modélisation distribuée doit être aussi ouverte que possible aux futures technologies de modélisation et de simulation.

Actuellement, IEEE 1516 est la norme absolue pour l'interaction des simulateurs et des simulateurs dans les applications militaires, en raison des exigences strictes de compatibilité avec les simulateurs développés et utilisés par le ministère américain de la Défense et l'OTAN. Actuellement, IEEE 1516 est de plus en plus utilisé dans la sphère civile, dans le développement de simulateurs pour la formation du personnel de systèmes techniques complexes, dans l'aviation, l'astronautique, les transports, etc.

La famille OPC de technologies logicielles a été conçue pour réduire le coût de création et de maintenance des applications d'automatisation industrielle. Au début des années 90, les développeurs de logiciels industriels avaient besoin d'un outil universel pour échanger des données avec des appareils de différents fabricants ou avec différents protocoles de communication. OPC fournit aux développeurs de logiciels industriels une interface fixe universelle pour l'échange de données avec n'importe quel appareil. Dans le même temps, les développeurs de périphériques fournissent un programme qui implémente cette interface.

Pour créer des systèmes de simulation complexes, vous pouvez combiner l'utilisation d'IEEE 1516 et d'OPC, en obtenant la possibilité d'utiliser des équipements réels et des systèmes SCADA (figure), ce qui peut être très utile dans de nombreuses tâches.

La communication entre les normes IEEE 1516 (qui est de base pour les simulateurs) et OPC (utilisé dans les systèmes SCADA) peut être mise en œuvre soit directement dans le simulateur, soit par un intermédiaire. Le rôle d'un tel intermédiaire, par exemple, pour moi, est assuré par le package National Instruments LabView. LabView peut prendre en charge des modèles mathématiques de toute complexité, a un support OPC intégré, peut agir comme un serveur OPC, a un support efficace pour l'interaction avec diverses cartes d'E / S, ce qui vous permet d'utiliser directement l'équipement nécessaire, mais, malheureusement, ne dispose pas de moyens d'interaction avec IEEE 1516 , ce qui nécessite l'écriture des composants logiciels appropriés.

En raison de l'utilisation de la norme IEEE 1516 et OPC, il est possible de créer des systèmes de simulation distribués relativement complexes, y compris de nombreux simulateurs, équipements réels, les systèmes SCADA, etc. La

question de la certification d'un simulateur ou simulateurs par rapport à l' aide à la norme IEEE 1516 mérite un examen séparé . fédère dans la terminologie IEEE 1516) et les bibliothèques de logiciels qui implémentent l'interaction. Mais le but de cette certification n'est pas d'identifier les défauts fonctionnels du programme (uniquement la certification de prise en charge de la norme IEEE 1516).

Organisations capables de certification:

ETATS-UNIS. Bureau de coordination de la modélisation et de la simulation du ministère de la Défense (DoD) (M&S CO). Site Web: 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

Examinons les problèmes liés à la construction de systèmes de simulation distribués basés sur la norme IEEE 1516. Les termes de base utilisés dans le support de l'information correspondent à la terminologie des systèmes de simulation interactifs distribués IEEE 1516 - ils sont fédération, fédération, objet, attribut et interaction. Le concept d'objet est défini comme un modèle d'un phénomène distinct dans le monde réel. Les objets n'ont pas de méthodes, ils n'ont que des états (seulement une structure de données sans fonctions pour les traiter). L'état des objets est caractérisé par un ensemble fixe d'attributs - des valeurs précises qui peuvent changer avec le temps. Chaque objet à tout moment est caractérisé par son état, qui est déterminé par un ensemble de valeurs actuelles de ses attributs. Les fédérés sont des descriptions mathématiques du comportement des objets - modèles de simulation,défini par logiciel (implémenté en langage directive) ou représenté par des valeurs de capteur matériel. En fait, les autorités fédérales peuvent être à la fois des imitateurs et de véritables équipements ou logiciels spéciaux. La seule exigence est de fournir une interface uniforme pour la communication. Les fédérés peuvent manipuler des objets en modifiant (mettant à jour) ou en obtenant (affichant) les valeurs de leurs attributs. En particulier, les utilisateurs des imitateurs sont également des fédérés. L'ensemble de tous les fédérés participant à la simulation forme une fédération.La seule exigence est de fournir une interface uniforme pour la communication. Les fédérés peuvent manipuler des objets en modifiant (mettant à jour) ou en obtenant (affichant) les valeurs de leurs attributs. En particulier, les utilisateurs des imitateurs sont également des fédérés. L'ensemble de tous les fédérés participant à la simulation forme une fédération.La seule exigence est de fournir une interface uniforme pour la communication. Les fédérés peuvent manipuler des objets en modifiant (mettant à jour) ou en obtenant (affichant) les valeurs de leurs attributs. En particulier, les utilisateurs des imitateurs sont également des fédérés. L'ensemble de tous les fédérés participant à la simulation forme une fédération.

Le terme «interaction» est défini comme un message instantané (événement) qui n'est pas lié à une instance d'objet ou à une fédération spécifique, se produisant au niveau de la fédération (c'est-à-dire qu'il est impossible de déterminer l'expéditeur). Les interactions, contrairement aux états des objets, ne sont pas constamment maintenues dans le système, mais sont de nature instantanée. Un exemple serait la diffusion unidirectionnelle d'un message texte à tous les membres intéressés de la fédération. Le schéma de fédération hiérarchique (HLA / IEEE 1516) est illustré dans la figure

L'interaction des fédérés est réalisée à l'aide d'un mécanisme d'interaction général (RTI), implémenté sous forme d'abonnement. Un fédéré intéressé par l'obtention de certains attributs et interactions d'une autre fédération doit s'y abonner via le RTI. Le mécanisme de demande, de fourniture et de modification des valeurs d'attribut est illustré dans la figure. Le mécanisme d'organisation de la simulation distribuée et de la collaboration est illustré dans la figure.

Image. Schéma de fédération hiérarchique Les

objets dans le simulateur sont, en règle générale, des modèles 3D, des sources sonores, respectivement, les attributs de ces objets sont la position et l'orientation dans l'espace, la taille, le volume, etc. En ce qui concerne les simulateurs, les actions de l'utilisateur (fédération), par exemple l'inclusion d'une clé, peuvent être considérées comme des interactions.

. (RTI)

.

Lors de la création de systèmes de simulation distribués qui interagissent via RTI, il est nécessaire de prendre en compte les caractéristiques importantes suivantes. Tous les éléments des fédérations et fédérations doivent être documentés dans certains fichiers (les fichiers FOM (federation object model) sont utilisés pour décrire la fédération), les fédérations sont décrites dans les fichiers SOM (Simulation Object Model). Toutes les données sont stockées uniquement dans les fédérations, RTI ne stocke aucune donnée, mais les transfère uniquement. HLA permet à une seule fédération de changer la valeur d'un attribut à un moment donné (il existe un mécanisme spécial de gestion des droits pour le transfert des droits). Les fédérés peuvent gérer l'heure locale, HLA utilise divers mécanismes internes de gestion de l'heure (synchronisation).

De manière générale, la norme IEEE 1516 aborde un grand nombre de problèmes liés à la création de systèmes de simulation distribués, tels que le maintien de l'état de la fédération, le renouvellement de l'état, les différents mécanismes de synchronisation temporelle, les zones d'interaction des fédérés, etc. En raison du volume important de la norme elle-même et, de plus, du volume de code de programme pour démontrer tous les aspects décrits dans la norme, seule la mise en œuvre fondamentale des capacités «de base» sera démontrée ci-dessous (figure).

Image. Schéma fonctionnel de mise en œuvre des capacités de base IEEE 1516

Une présentation plus détaillée de la mise en œuvre est associée à la nécessité de présenter une liste assez large du programme, pour cette raison, le lecteur peut utiliser indépendamment les exemples de programmes fournis avec le logiciel pour prendre en charge RTI. Des exemples simples avec de nombreux commentaires sont inclus dans la bibliothèque The Portico Project et sont disponibles gratuitement sur porticoproject.org . Presque toutes les implémentations commerciales de la norme contiennent également de nombreux exemples.

À titre d'exemple, considérons la fédération suivante, qui se compose de deux fédérés: une voiture radiocommandée et un panneau de contrôle. Supposons que le contrôle soit effectué en réglant la vitesse de chacun des 4 moteurs de la voiture et en tournant les roues avant. La machine est équipée d'un capteur qui détermine la distance à l'obstacle et transmet un signal au panneau de commande. Pour cela, il est nécessaire de définir deux classes d'objets, cYpravlenie pour le panneau de contrôle et cDatchik pour le capteur de distance. Les attributs de la classe cYpravlenie sont wheel1, wheel2, wheel3, wheel4, wheel_angle. L'attribut de classe cDatchik est la distance. Voici un fichier de description de fédération, au format HLA 1.3 (les interactions sont données à titre d'exemple).

;;  —   (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) 
	) 
) 

)

Ensuite, le simulateur représentant le contrôle crée une fédération et un objet basés sur la classe cYpravlenie. Le simulateur représentant la voiture crée également une fédération et un objet basés sur la classe cDatchik. Les fédérés souscrivent également aux changements qui les intéressent, c'est-à-dire La machine fédérée s'abonne pour recevoir des données d'objet de la classe cYpravlenie (c'est-à-dire la classe cYpravlenie), et le contrôle fédéré s'abonne à la classe cDatchik. Ainsi, la machine reçoit les modifications du panneau de commande et le panneau de commande reçoit les données du capteur de la voiture.

La construction de systèmes de simulation plus sophistiqués nécessite une conception sérieuse. Tout d'abord, il est nécessaire de déterminer la composition principale de la fédération en première approximation, c'est-à-dire les fédérations, les objets fédérés et les attributs d'objet. Lors de l'élaboration du schéma de fédération, il est nécessaire de prendre en compte les composants matériels des systèmes de simulation distribués, c'est-à-dire que les capteurs et les dispositifs matériels de contrôle doivent également être représentés sous la forme de fédérations, d'objets et d'attributs. Sur l'image. montre la structure de la fédération du simulateur d'installation de pompe à ventouse.

Image. Structure de la fédération

Une fois la fédération composée, il est nécessaire de définir des liens, c'est-à-dire un reflet de quels fédérés publient (c'est-à-dire modifient) les attributs des objets et lesquels souscrivent aux modifications de ces attributs. En règle générale, au stade de la définition des liens, un grand nombre de «modifications» sont établies pour la structure de la fédération. Après le nombre requis d'itérations du «raffinement» de la structure et des relations, les concepteurs doivent établir le fait de «l'exactitude du modèle» de la fédération. Un exemple de définition de liens est illustré sur la figure (les objets sans liens sont masqués).

Image. Un exemple de la première étape de définition des liens

Dans l'étape suivante, le nombre d'ordinateurs requis est déterminé et la répartition correspondante des fédérés. Par exemple, la fédération «A» fonctionnera sur l'ordinateur «1», les fédérations «B, C, D» fonctionneront sur l'ordinateur «2».

Image. Répartition des fédérés par ordinateurs

En règle générale, la répartition des fédérés est basée sur l'économie de leur modèle mathématique, si les modèles mathématiques des fédérés ne nécessitent pas de ressources informatiques importantes, alors un ordinateur peut être utilisé, si les modèles mathématiques des fédérés nécessitent des ressources informatiques importantes, il est nécessaire de déterminer le nombre d'ordinateurs et la répartition correspondante des fédérations.

L'étape suivante consiste à créer un fichier de description de fédération (voir l'exemple ci-dessus) qui reflète le «modèle correct» approuvé de la fédération. Vous créez ensuite une implémentation logicielle des fédérations en écrivant le code approprié pour interagir avec le RTI et le code pour implémenter le modèle mathématique de la fédération. Au stade final, il est nécessaire de tester le système de simulation distribué, d'identifier les erreurs, les «surcharges» de certains composants du système (sur la base des statistiques), la synchronisation correcte, etc. Les

statistiques pour chaque fédération séparément et pour la fédération dans son ensemble montrent le nombre et les types de requêtes exécutées et vous permet d'identifier d'éventuels problèmes pendant le fonctionnement du système.

Exemple de statistiques pour une fédération:

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

Synchronisation de l'heure

Comme l'a montré la pratique de la conception et de la mise en œuvre de systèmes de simulation distribués, la plus grande difficulté est causée par des problèmes liés au contrôle du flux temporel (synchronisation temporelle).

En règle générale, lorsque vous définissez la façon dont l'heure fédérée est synchronisée, deux paramètres sont définis, TimeRegulating et TimeConstrained. En pratique, ces modes affectent le processus de réception des messages d'autres fédérés et sont directement liés au mécanisme de classement des messages:

dans l'ordre de réception (les messages sont transmis dans l'ordre dans lequel ils ont été reçus sans contrôle horaire);
priorité (les messages entrants sont situés dans une file d'attente prioritaire, son horodatage est utilisé pour déterminer la priorité d'un message);
causal (garantit que les messages sont envoyés aux fédérés dans un ordre cohérent avec les événements précédents et suivants représentés par ces messages);
par horodatage (lors de l'utilisation de ce service, les messages seront envoyés aux fédérés dans l'ordre de leurs horodatages).

Il convient également de noter que différents fédérés peuvent utiliser différentes méthodes de synchronisation.

Bibliothèques logicielles pour l'implémentation RTI

Une liste des implémentations HLA \ IEE1516 disponibles est disponible sur en.wikipedia.org/wiki/Run-Time_Infrastructure . Aujourd'hui, un assez grand nombre d'implémentations sont disponibles, à la fois commerciales et non commerciales. La plupart des implémentations sont faites en JAVA et C ++ (ce sont les langages qui sont utilisés dans le standard), mais il existe également des implémentations pour MatLab, Python (projet CERTI), etc.

Lors du choix d'une bibliothèque, une attention particulière doit être portée à la «certification» pour supporter IEEE 1516. En règle générale , toutes les implémentations commerciales ont un "certificat", les libres n'en ont pas (beaucoup d'implémentations libres se préparent à une telle certification).

Tableau des ventes commerciales:

CAE RTI CAE Inc.
en.wikipedia.org/wiki/CAE_Inc .
Jeux Chronos RTI Magnetar
www.magnetargames.com/Products/Chronos
Technologies RTI MÄK hautes performances MÄK
www.mak.com/products/rti.php
Systèmes HLA Direct General Dynamics C4
en.wikipedia.org/wiki/General_Dynamics_C4_Systems
Systèmes de cybernet Openskies RTI
www.openskies.net
Pitch pRTI Pitch Technologies
www.pitch.se/products/pitch-prti/pitch-prti-overview.html
RTI NG Pro Raytheon Virtual Technology Corporation
www.raytheonvtc.com/products.jsp

Tableau des ventes non commerciales:

CERTI ONERA
savannah.nongnu.org/projects/certi
en.wikipedia.org/wiki/ONERA
Le projet Portico Littlebluefrog Labs
porticoproject.org
GERTICO (RTI allemand basé sur Corba) Fraunhofer IITB
www.iitb.fraunhofer.de/servlet/is/2920
Rendezvous RTI National University of Science and Technology (NUST), Pakistan
www.mcs.edu.pk/PDC-RG.html
Ouvrir HLA (ohla)
sourceforge.net/projects/ohla

J'utilise personnellement le projet ONERA CERTI (https://savannah.nongnu.org/projects/certi) pour soutenir l'infrastructure des applications distribuées.

Mesures de la vitesse d'interaction des fédérés via RTI

Ces tests sont très importants dans la conception de systèmes de simulation distribués, en particulier si différentes fédérations sont situées sur des réseaux informatiques différents, et encore plus importants lors de l'interaction de fédérés sur Internet.

Pour obtenir les délais minimaux, vous devez choisir le serveur avec les délais de transit de paquets les plus faibles (vous pouvez vérifier à l'aide de la commande ping). A titre d'exemple, considérons le travail de l'un des systèmes distribués créés au NII EOR de TyumGNGU. Un réseau de 100 mégabits est utilisé (délais de ping <0,231 ms), il n'y a pas de synchronisation horaire (pour réduire les délais à l'intérieur de RTI), 2 ordinateurs, le serveur (rtig) fonctionne sur l'une des machines. Paramètres de fédération - 2 objets contiennent 5 attributs (un objet par fédération / ordinateur), l'interaction entre les fédérés est bidirectionnelle. À la suite du traitement des mesures, la dépendance du nombre d'interactions par seconde à la taille des données transmises a été obtenue.

Les résultats de telles mesures nous permettent de tirer de nombreuses conclusions, par exemple si le simulateur doit fonctionner en un «temps réel» donné, c'est-à-dire mise à jour, par exemple, au moins 60 fois par seconde, puis pour une interaction (pour Fast Ethernet) pas plus de 300 kilo-octets doivent être transmis (si, par exemple, 5 attributs, puis 60 kilo-octets chacun). Dans le même temps, 300 kilo-octets de données transmises 60 fois par seconde indiquent également la possibilité d'utiliser RTI pour transférer des données vocales et vidéo entre simulateurs, ainsi que pour interagir avec des appareils VR.

Lorsqu'elle est fédérée sur Internet, la latence minimale est largement déterminée par les délais de transmission des paquets. Par exemple, si les délais de transmission d'un paquet entre le serveur et le simulateur sont de 300 ms, alors le nombre maximum d'interactions par seconde ne dépassera pas 3.

L'utilisation de solutions plus rapides comme IpoIB (IP over InfiniBand, RFC 4392), 10G Ethernet, Myrinet-10G, etc. . permettra d'augmenter le débit et de réduire significativement la latence (les solutions existantes permettent de produire 30 millions d'interactions par seconde ou plus).

Interaction avec des systèmes réels

Non seulement les modèles mathématiques d'objets, c'est-à-dire les systèmes artificiels, mais aussi les systèmes et dispositifs réels peuvent agir en tant que fédérés. Les exemples comprennent:

microphone fournissant des données audio;
caméra vidéo fournissant des données vidéo;
divers périphériques d'entrée / sortie tels que joysticks (image), imprimantes, etc.
divers capteurs et mécanismes de contrôle connectés à l'ordinateur via des cartes ADC / DAC;
équipements réels et systèmes SCADA (Figure 2.10.1., Chapitre 1.4.1.) via l'interface OPC industrielle;
Interfaces avec le «bureau» d'un système d'exploitation réel fonctionnant sur un ordinateur ou une machine virtuelle séparé (figure);
Appareils VR (chapitre 4.5.9.);
Interface de base de données, etc.

Ces possibilités présentent un intérêt considérable pour les simulateurs et les systèmes de simulation en général.

Systèmes de simulation distribués

Synchronisation de l'heure

Bibliothèques logicielles pour l'implémentation RTI

Mesures de la vitesse d'interaction des fédérés via RTI

Interaction avec des systèmes réels

More articles: