Clever Geek Handbook

Sistemas de simulación distribuida



Para poder combinar simuladores individuales en un sistema de simulación distribuido, actualmente se utilizan los siguientes estándares y tecnologías:



  • IEEE1516 (también reemplaza HLA y DIS)
  • OPC;
  • CAPE-OPEN y otros estándares de "industria".


De gran interés es el estándar IEEE 1516, ya que este estándar se relaciona directamente con los simuladores, está destinado a construir sistemas de simulación distribuidos (protocolos, métodos recomendados de control y retroalimentación, arquitectura del sistema, etc.).



La familia de tecnologías de software OPC (OLE para control de procesos) que proporcionan una interfaz única para gestionar objetos de automatización y procesos tecnológicos también es de gran interés, pero solo si se requiere la integración con objetos de automatización y procesos tecnológicos. El estándar CAPE-OPEN se utiliza para la interacción de simuladores diseñados específicamente para la industria química.



El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) ha realizado importantes contribuciones a la estandarización de modelado y simulación. El modelado distribuido (simulación) es una tecnología para el intercambio de datos entre simuladores a través de redes informáticas locales o globales. Esto permite que los simuladores individuales trabajen juntos como un sistema de modelado o simulación controlado. El concepto de modelado distribuido se basa en el uso de una arquitectura de alto nivel (HLA). En la práctica, el estándar IEEE 1516 define la arquitectura mediante el uso de una única API (interfaz de programación de aplicaciones). Los postulados iniciales de la norma son:



  1. los modelos de simulación "monolíticos" simples no pueden satisfacer las necesidades de los usuarios profesionales;
  2. todas las posibles aplicaciones de simulación son desconocidas de antemano;
  3. se debe proporcionar la posibilidad de una combinación arbitraria de simuladores individuales en sistemas de simulación complejos;
  4. La arquitectura de modelado distribuido debe ser lo más abierta posible a futuras tecnologías de modelado y simulación.


Actualmente, IEEE 1516 es el estándar absoluto para la interacción de simuladores y simuladores en aplicaciones militares, debido a los estrictos requisitos de compatibilidad con simuladores desarrollados y utilizados por el Departamento de Defensa de los EE. UU. Y la OTAN. Actualmente, el IEEE 1516 se usa cada vez más en la esfera civil, en el desarrollo de simuladores para capacitar al personal de sistemas técnicos complejos, en aviación, astronáutica, transporte, etc.



La familia de tecnologías de software OPC ha sido diseñada para reducir el costo de crear y mantener aplicaciones de automatización industrial. A principios de los 90, los desarrolladores de software industrial necesitaban una herramienta universal para intercambiar datos con dispositivos de diferentes fabricantes o con diferentes protocolos de comunicación. OPC proporciona a los desarrolladores de software industrial una interfaz fija universal para el intercambio de datos con cualquier dispositivo. Al mismo tiempo, los desarrolladores de dispositivos proporcionan un programa que implementa esta interfaz.



Para crear sistemas de simulación complejos, puede combinar el uso de IEEE 1516 y OPC, obteniendo la oportunidad de usar equipos reales y sistemas SCADA (figura), que pueden ser bastante útiles en muchas tareas.



La comunicación entre los estándares IEEE 1516 (que es básico para simuladores) y OPC (utilizado en sistemas SCADA) puede implementarse directamente en el simulador o mediante un intermediario. El papel de tal intermediario, por ejemplo, para mí, lo realiza el paquete LabView de National Instruments. LabView puede soportar modelos matemáticos de cualquier complejidad, tiene soporte OPC incorporado, puede actuar como un servidor OPC, tiene soporte efectivo para la interacción con varias tarjetas de E / S, lo que le permite usar el equipo necesario directamente, pero, desafortunadamente, no tiene medios de interacción con IEEE 1516 , lo que requiere escribir los componentes de software adecuados.



Como resultado del uso de IEEE 1516 y OPC, es posible crear sistemas de simulación distribuidos relativamente complejos, que incluyen muchos simuladores, equipos reales, sistemas SCADA, etc. El



tema de la certificación del simulador o simuladores con respecto al soporte del estándar IEEE 1516 merece una consideración por separado . se federa en terminología IEEE 1516) y bibliotecas de software que implementan la interacción. Pero el propósito de esta certificación no es identificar defectos funcionales del programa (solo certificación de soporte para el estándar IEEE 1516).



Organizaciones capaces de certificación:



  • ESTADOS UNIDOS. La Oficina de Coordinación de Modelado y Simulación del Departamento de Defensa (DoD) (M&S CO). Sitio 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














Consideremos los problemas de la construcción de sistemas de simulación distribuidos basados ​​en el estándar IEEE 1516. Los términos básicos utilizados en el soporte de información corresponden a la terminología de los sistemas de simulación interactivos distribuidos IEEE 1516: federación, federación, objeto, atributo e interacción. El concepto de un objeto se define como un modelo de un fenómeno separado en el mundo real. Los objetos no tienen métodos, solo tienen estados (solo una estructura de datos sin funciones para procesarlos). El estado de los objetos se caracteriza por un conjunto fijo de atributos: valores precisos que pueden cambiar con el tiempo. Cada objeto en cualquier momento se caracteriza por su estado, que está determinado por un conjunto de valores actuales de sus atributos. Las federaciones son descripciones matemáticas del comportamiento de los objetos: modelos de simulación,definido por software (implementado en lenguaje directivo) o representado por valores de sensores de hardware. De hecho, los federales pueden ser imitadores y equipos reales o software especial. El único requisito es proporcionar una interfaz uniforme para la comunicación. Las federaciones pueden manipular objetos cambiando (actualizando) u obteniendo (mostrando) los valores de sus atributos. En particular, los usuarios de imitadores también son federados. El conjunto de todos los federados que participan en la simulación forma una federación.El único requisito es proporcionar una interfaz uniforme para la comunicación. Las federaciones pueden manipular objetos cambiando (actualizando) u obteniendo (mostrando) los valores de sus atributos. En particular, los usuarios de imitadores también son federados. El conjunto de todos los federados que participan en la simulación forma una federación.El único requisito es proporcionar una interfaz uniforme para la comunicación. Las federaciones pueden manipular objetos cambiando (actualizando) u obteniendo (mostrando) los valores de sus atributos. En particular, los usuarios de imitadores también son federados. El conjunto de todos los federados que participan en la simulación forma una federación.



El término "interacción" se define como un mensaje instantáneo (evento), no vinculado a una instancia específica de un objeto o federación, que ocurre en el nivel de federación (es decir, es imposible determinar el remitente). Las interacciones, en contraste con los estados de los objetos, no se mantienen constantemente en el sistema, sino que son de naturaleza instantánea. Un ejemplo sería una transmisión unidireccional de un mensaje de texto a todos los miembros de la federación interesados. El esquema de federación jerárquica (HLA / IEEE 1516) se muestra en la figura



La interacción de los federados se lleva a cabo utilizando un mecanismo de interacción general (RTI), implementado como una suscripción. Un federado interesado en obtener ciertos atributos e interacciones de otra federación debe suscribirse a ellos a través del RTI. El mecanismo para solicitar, proporcionar y cambiar los valores de los atributos se muestra en la figura. El mecanismo para organizar la simulación distribuida y la colaboración se muestra en la figura.





Imagen. Esquema de federación jerárquica Los



objetos en el simulador son, por regla general, modelos 3D, fuentes de sonido, respectivamente, los atributos de dichos objetos son posición y orientación en espacio, tamaño, volumen, etc. Con respecto a los simuladores, las acciones del usuario (federación), por ejemplo, la inclusión de una clave, pueden considerarse interacciones.





. (RTI)





. (RTI)





.



Al crear sistemas de simulación distribuidos que interactúan a través de RTI, es necesario tener en cuenta las siguientes características importantes. Todos los elementos de federaciones y federaciones deben documentarse en archivos específicos (los archivos FOM (modelo de objeto de federación) se usan para describir la federación), las federaciones se describen en archivos SOM (Modelo de objeto de simulación). Todos los datos se almacenan solo en federaciones, RTI no almacena ningún dato, solo lo transfiere. HLA permite que solo una federación cambie el valor de un atributo en un momento dado (existe un mecanismo especial de administración de derechos para transferir derechos). Las federaciones pueden administrar la hora local, HLA utiliza varios mecanismos internos de administración de tiempo (sincronización).



En general, el estándar IEEE 1516 aborda una gran cantidad de problemas relacionados con la creación de sistemas de simulación distribuidos, como el mantenimiento del estado de la federación, la renovación del estado, varios mecanismos de sincronización horaria, las áreas de interacción de los federados, etc. Debido al volumen significativo del estándar en sí mismo y, además, al volumen del código del programa para demostrar todos los aspectos descritos en el estándar, solo se demostrará a continuación la implementación fundamental de las capacidades "básicas" (figura).





Imagen. Diagrama de bloques de implementación de capacidades básicas IEEE 1516



Una presentación más detallada de la implementación está asociada con la necesidad de presentar una lista suficientemente grande del programa, por esta razón, el lector puede usar de forma independiente los ejemplos de programas que vienen con el software para soportar RTI. Se incluyen ejemplos simples con muchos comentarios en la biblioteca de The Portico Project y están disponibles gratuitamente en porticoproject.org . Casi todas las implementaciones comerciales del estándar también contienen muchos ejemplos.



Como ejemplo, considere la siguiente federación, que consta de dos federaciones: un automóvil controlado por radio y un panel de control. Suponga que el control se lleva a cabo ajustando la velocidad de cada uno de los 4 motores del automóvil y girando las ruedas delanteras. La máquina está equipada con un sensor que determina la distancia al obstáculo y transmite una señal al panel de control. Para esto es necesario definir dos clases de objetos, cYpravlenie para el panel de control y cDatchik para el sensor de distancia. Los atributos de la clase cYpravlenie son wheel1, wheel2, wheel3, wheel4, wheel_angle. El atributo de clase cDatchik es la distancia. El siguiente es un archivo de descripción de la federación, en formato HLA 1.3 (las interacciones se dan como ejemplo). 



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

)


A continuación, el simulador que representa el control crea una federación y un objeto basado en la clase cYpravlenie. El simulador que representa el automóvil también crea una federación y un objeto basado en la clase cDatchik. Los federados también se suscriben a los cambios que les interesan, es decir, La máquina federada se suscribe a la recepción de datos de objetos de la clase cYpravlenie (es decir, la clase cYpravlenie) y el control federado a la clase cDatchik. Por lo tanto, la máquina recibe cambios desde el panel de control, y el panel de control recibe datos del sensor en el automóvil.



La construcción de sistemas de simulación más sofisticados requiere un diseño serio. Primero, es necesario determinar la composición principal de la federación en una primera aproximación, es decir, federados, objetos federados y atributos de objeto. Al elaborar el esquema de federación, es necesario tener en cuenta los componentes de hardware de los sistemas de simulación distribuidos, es decir, los sensores y los dispositivos de hardware de control también deben estar representados en forma de federados, objetos y atributos. En la foto. muestra la estructura de la federación del simulador de instalación de la bomba de varilla de bombeo.





Imagen. Estructura de la federación



Una vez compuesta la federación, es necesario definir enlaces, es decir, un reflejo de qué federaciones publican (es decir, cambian) los atributos de los objetos y cuáles se suscriben a los cambios de estos atributos. Como regla general, en la etapa de definición de enlaces, se establece una gran cantidad de "enmiendas" para la estructura de la federación. Después del número requerido de iteraciones del "refinamiento" de la estructura y las relaciones, los diseñadores deben establecer el hecho de la "corrección del modelo" de la federación. En la figura se muestra un ejemplo de definición de enlaces (los objetos sin enlaces están ocultos).





Imagen. Un ejemplo de la primera etapa de definición de enlaces



En la siguiente etapa, se determina el número requerido de computadoras y la distribución correspondiente de federaciones. Por ejemplo, la federación "A" funcionará en la computadora "1", las federaciones "B, C, D" funcionarán en la computadora "2".





Imagen. Distribución de federados por computadoras



Como regla general, la distribución de federados se basa en la economía de su modelo matemático, si los modelos matemáticos de federados no requieren recursos informáticos significativos, entonces se puede usar una computadora, si los modelos matemáticos de federados requieren recursos informáticos significativos, es necesario determinar el número de computadoras y la distribución correspondiente de federaciones.



El siguiente paso es crear un archivo de descripción de la federación (vea el ejemplo anterior) que refleje el "modelo correcto" aprobado de la federación. Luego crea una implementación de software de federados escribiendo el código apropiado para interactuar con el RTI y el código para implementar el modelo matemático de la federación. En la etapa final, es necesario probar el sistema de simulación distribuida, identificar errores, "sobrecargas" de ciertos componentes en el sistema (basados ​​en estadísticas), sincronización correcta, etc. Las



estadísticas para cada federación por separado y para la federación en su conjunto muestran el número y los tipos de consultas ejecutadas y le permite identificar posibles problemas durante el funcionamiento del sistema.



Estadísticas de ejemplo para una federación: 



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


Sincronización de tiempo



Como ha demostrado la práctica del diseño e implementación de sistemas de simulación distribuida, los problemas más difíciles están relacionados con el control del flujo del tiempo (sincronización de tiempo).



Normalmente, cuando establece cómo se sincroniza el tiempo federado, se establecen dos parámetros, TimeRegulating y TimeConstrained. En la práctica, estos modos afectan el proceso de recibir mensajes de otros federados y están directamente relacionados con el mecanismo de pedido de mensajes:

  • en orden de recepción (los mensajes se transmiten en el orden en que fueron recibidos sin control de tiempo);
  • prioridad (los mensajes entrantes se encuentran en una cola de prioridad, su marca de tiempo se utiliza para determinar la prioridad de un mensaje);
  • causal (asegura que los mensajes se envíen a los federados en un orden coherente con los eventos anteriores y posteriores representados por esos mensajes);
  • por marcas de tiempo (cuando se utiliza este servicio, los mensajes se enviarán a las federaciones en el orden de sus marcas de tiempo).


También vale la pena señalar que diferentes federados pueden usar diferentes métodos de sincronización.



Bibliotecas de software para la implementación de RTI



Una lista de implementaciones disponibles de HLA \ IEE1516 está disponible en en.wikipedia.org/wiki/Run-Time_Infrastructure . Hoy en día, hay un número bastante grande de implementaciones disponibles, tanto comerciales como no comerciales. La mayoría de las implementaciones se realizan en JAVA y C ++ (estos son los lenguajes que se usan en el estándar), pero también hay implementaciones para MatLab, Python (proyecto CERTI), etc.



Al elegir una biblioteca, se debe prestar especial atención a la "certificación" para admitir IEEE 1516. Como regla general , todas las implementaciones comerciales tienen un "certificado", las gratuitas no (muchas de las implementaciones gratuitas se están preparando para dicha certificación).



Tabla de ventas comerciales:





Tabla de ventas no comerciales:





Yo personalmente uso el proyecto ONERA CERTI (https://savannah.nongnu.org/projects/certi) para soportar la infraestructura de aplicaciones distribuidas.



Mediciones de la velocidad de interacción de los federados a través de RTI



Tales pruebas son muy importantes en el diseño de sistemas de simulación distribuidos, especialmente si las diferentes federaciones se encuentran en diferentes redes de computadoras, y aún más importante cuando interactúan federaciones a través de Internet.



Para lograr los retrasos mínimos de tiempo, debe seleccionar el servidor con los retrasos de tiempo de tránsito de paquetes más bajos (se puede verificar con el comando ping). Como ejemplo, consideremos el trabajo de uno de los sistemas distribuidos creados en el NII EOR de TyumGNGU. Se utiliza una red de 100 megabits (retardos de ping <0.231 ms), no hay sincronización de tiempo (para reducir los retrasos dentro de RTI), 2 computadoras, el servidor (rtig) se está ejecutando en una de las máquinas. Parámetros de federación: 2 objetos contienen 5 atributos (un objeto por federación / computadora), la interacción entre federados es bidireccional. Como resultado del procesamiento de las mediciones, se obtuvo la dependencia del número de interacciones por segundo con el tamaño de los datos transmitidos.



Los resultados de tales mediciones nos permiten sacar muchas conclusiones, por ejemplo, si el simulador debe funcionar en un "tiempo real" dado, es decir actualizar, por ejemplo, al menos 60 veces por segundo, luego, para una interacción (para Fast Ethernet) no se deben transmitir más de 300 kilobytes (si, por ejemplo, 5 atributos, luego 60 kilobytes cada uno). Al mismo tiempo, 300 kilobytes de datos transmitidos 60 veces por segundo también indican la posibilidad de usar RTI para transferir datos de voz y video entre simuladores, así como para interactuar con dispositivos de realidad virtual.



Cuando se federa a través de Internet, la latencia mínima está determinada en gran medida por los retrasos en la transmisión de paquetes. Por ejemplo, si la latencia de un paquete entre el servidor y el simulador es de 300 ms, el número máximo de interacciones por segundo no excederá 3.



El uso de soluciones más rápidas como IpoIB (IP sobre InfiniBand, RFC 4392), 10G Ethernet, Myrinet-10G, etc. permitirá aumentar el rendimiento y reducir significativamente la latencia (las soluciones existentes permiten producir 30 millones de interacciones por segundo o más).



Interacción con sistemas reales.



No solo los modelos matemáticos de objetos, es decir, los sistemas artificiales, sino también los sistemas y dispositivos reales pueden actuar como federados. Ejemplos incluyen:



  • micrófono que proporciona datos de audio;
  • cámara de video que proporciona datos de video;
  • varios dispositivos de entrada / salida, como joysticks (imagen), impresoras, etc.
  • varios sensores y mecanismos de control conectados a la computadora a través de tarjetas ADC / DAC;
  • equipos reales y sistemas SCADA (Figura 2.10.1., Capítulo 1.4.1.) a través de la interfaz OPC industrial;
  • Interfaces con el "escritorio" de un sistema operativo real que se ejecuta en una computadora o máquina virtual separada (figura);
  • Dispositivos de realidad virtual (capítulo 4.5.9.);
  • Interfaz de base de datos, etc.


Dichas posibilidades son de considerable interés para los simuladores y los sistemas de simulación en general.


More articles:


All Articles