Sistemas de simulação distribuídos

Para poder combinar simuladores individuais em um sistema de simulação distribuído, atualmente são usados ​​os seguintes padrões e tecnologias:

• IEEE1516 (também substitui HLA e DIS)
• OPC;
• CAPE-OPEN e outros padrões da "indústria".

De maior interesse é o padrão IEEE 1516, uma vez que esse padrão se relaciona diretamente a simuladores, visa a construção de sistemas de simulação distribuídos (protocolos, controle recomendado e métodos de feedback, arquitetura de sistema etc.).



A família de tecnologias de software OPC (OLE for Process Control) que fornecem uma interface única para gerenciar objetos de automação e processos tecnológicos também é de interesse considerável, mas apenas se for necessária a integração com objetos de automação e processos tecnológicos. O padrão CAPE-OPEN é usado para a interação de simuladores projetados especificamente para a indústria química.



O Instituto de Engenheiros Elétricos e Eletrônicos (IEEE) fez contribuições significativas para a padronização da modelagem e simulação. A modelagem distribuída (simulação) é uma tecnologia para troca de dados entre simuladores em redes de computadores locais ou globais. Isso permite que simuladores individuais trabalhem juntos como um sistema controlado de modelagem ou simulação. O conceito de modelagem distribuída é baseado no uso de uma arquitetura de alto nível (HLA). Na prática, o padrão IEEE 1516 define a arquitetura usando uma única API (interface de programação de aplicativos). Os postulados iniciais da norma são:

1. modelos simples de simulação "monolítica" não podem atender às necessidades de usuários profissionais;
2. todas as possíveis aplicações de simulação são desconhecidas antecipadamente;
3. deve ser fornecida a possibilidade de combinação arbitrária de simuladores individuais em sistemas de simulação complexos;
4. A arquitetura de modelagem distribuída deve ser o mais aberta possível para futuras tecnologias de modelagem e simulação.

Atualmente, o IEEE 1516 é o padrão absoluto para a interação de simuladores e simuladores em aplicações militares, devido aos rigorosos requisitos de compatibilidade com simuladores desenvolvidos e usados ​​pelo Departamento de Defesa dos EUA e pela OTAN. Atualmente, o IEEE 1516 está sendo cada vez mais utilizado na esfera civil, no desenvolvimento de simuladores para treinamento de pessoal de sistemas técnicos complexos, em aviação, astronáutica, transporte, etc.



A família de tecnologias de software OPC foi projetada para reduzir o custo de criação e manutenção de aplicativos de automação industrial. No início dos anos 90, os desenvolvedores de software industrial precisavam de uma ferramenta universal para trocar dados com dispositivos de diferentes fabricantes ou com diferentes protocolos de comunicação. O OPC fornece aos desenvolvedores de software industrial uma interface fixa universal para troca de dados com qualquer dispositivo. Ao mesmo tempo, os desenvolvedores de dispositivos fornecem um programa que implementa essa interface.



Para criar sistemas de simulação complexos, você pode combinar o uso do IEEE 1516 e OPC, possibilitando o uso de equipamentos reais e sistemas SCADA (figura), que podem ser bastante úteis em muitas tarefas.



A comunicação entre os padrões IEEE 1516 (que é básico para simuladores) e o OPC (usado nos sistemas SCADA) pode ser implementada diretamente no simulador ou por meio de um intermediário. O papel desse intermediário, por exemplo, para mim, é desempenhado pelo pacote National Instruments LabView. O LabView pode suportar modelos matemáticos de qualquer complexidade, possui suporte OPC embutido, pode atuar como um servidor OPC, possui suporte eficaz à interação com várias placas de E / S, o que permite usar o equipamento necessário diretamente, mas, infelizmente, não possui meios de interação com o IEEE 1516 , que requer a gravação dos componentes de software apropriados.



Como resultado do uso do IEEE 1516 e OPC, é possível criar sistemas de simulação distribuídos relativamente complexos, incluindo muitos simuladores, equipamentos reais, sistemas SCADA, etc. A



questão da certificação do simulador ou simuladores com relação ao suporte à norma IEEE 1516 merece uma consideração separada . federados na terminologia IEEE 1516) e bibliotecas de software que implementam a interação. Mas o objetivo desta certificação não é identificar defeitos funcionais do programa (apenas certificação de suporte para o padrão IEEE 1516).



Organizações capazes de certificação:

• EUA. Gabinete de Coordenação de Modelagem e Simulação do Departamento de Defesa (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

Vamos considerar as questões de construção de sistemas de simulação distribuídos com base no padrão IEEE 1516. Os termos básicos usados ​​no suporte a informações correspondem à terminologia dos sistemas de simulação interativos distribuídos IEEE 1516 - federação, federação, objeto, atributo e interação. O conceito de um objeto é definido como um modelo de um fenômeno separado no mundo real. Os objetos não possuem métodos, apenas estados (apenas uma estrutura de dados sem funções para processá-los). O estado dos objetos é caracterizado por um conjunto fixo de atributos - valores precisos que podem mudar com o tempo. Cada objeto a qualquer momento é caracterizado por seu estado, que é determinado por um conjunto de valores atuais de seus atributos. Federados são descrições matemáticas do comportamento de objetos - modelos de simulação,definido por software (implementado na linguagem da diretiva) ou representado pelos valores dos sensores de hardware. De fato, os federais podem ser imitadores e equipamentos reais ou software especial. O único requisito é fornecer uma interface uniforme para comunicação. Os federados podem manipular objetos alterando (atualizando) ou obtendo (exibindo) os valores de seus atributos. Em particular, usuários de imitadores também são federados. O agregado de todos os federados participantes da simulação forma uma federação.O único requisito é fornecer uma interface uniforme para comunicação. Os federados podem manipular objetos alterando (atualizando) ou obtendo (exibindo) os valores de seus atributos. Em particular, usuários de imitadores também são federados. O agregado de todos os federados participantes da simulação forma uma federação.O único requisito é fornecer uma interface uniforme para comunicação. Os federados podem manipular objetos alterando (atualizando) ou obtendo (exibindo) os valores de seus atributos. Em particular, usuários de imitadores também são federados. O agregado de todos os federados participantes da simulação forma uma federação.



O termo "interação" é definido como uma mensagem instantânea (evento) que não está vinculada a uma instância ou federação de objeto específico, ocorrendo no nível da federação (ou seja, é impossível determinar o remetente). As interações, em contraste com os estados dos objetos, não são constantemente mantidas no sistema, mas são de natureza instantânea. Um exemplo seria uma transmissão unidirecional de uma mensagem de texto para todos os membros da federação interessados. O esquema de federação hierárquica (HLA / IEEE 1516) é mostrado na figura



A interação dos federados é realizada usando um mecanismo de interação geral (RTI), implementado como uma assinatura. Um federado interessado em obter certos atributos e interações de outra federação deve se inscrever através da RTI. O mecanismo para solicitar, fornecer e alterar valores de atributo é mostrado na figura. O mecanismo para organizar a simulação distribuída e a colaboração é mostrado na figura.





Cenário. Esquema de federação hierárquica Os



objetos no simulador são, via de regra, modelos 3D, fontes sonoras, respectivamente, os atributos de tais objetos são posição e orientação no espaço, tamanho, volume, etc. Com relação aos simuladores, as ações do usuário (federação), por exemplo, a inclusão de uma chave, podem ser consideradas como interações.





. (RTI)





. (RTI)





.



Ao criar sistemas de simulação distribuídos que interagem através da RTI, é necessário levar em consideração os seguintes recursos importantes. Todos os elementos de federações e federações devem ser documentados em arquivos específicos (os arquivos FOM (modelo de objeto de federação) são usados ​​para descrever a federação), as federações são descritas em arquivos SOM (modelo de objeto de simulação). Todos os dados são armazenados apenas em federações, o RTI não armazena nenhum dado, mas apenas o transfere. O HLA permite que apenas uma federação altere o valor de um atributo a qualquer momento (existe um mecanismo especial de gerenciamento de direitos para a transferência de direitos). Os federados podem gerenciar a hora local, o HLA usa vários mecanismos internos de gerenciamento de horas (sincronização).



Em geral, o padrão IEEE 1516 aborda um grande número de questões relacionadas à criação de sistemas de simulação distribuídos, como manutenção do estado da federação, renovação do estado, vários mecanismos de sincronização de tempo, áreas de interação de federados etc. Devido ao volume significativo do próprio padrão e, além disso, o volume do código do programa para demonstrar todos os aspectos descritos no padrão, apenas a implementação fundamental dos recursos "básicos" será demonstrada abaixo (figura).





Cenário. Diagrama de blocos de implementação de recursos básicos IEEE 1516



Uma apresentação mais detalhada da implementação está associada à necessidade de apresentar uma lista bastante grande do programa; por esse motivo, o leitor pode usar de forma independente os exemplos de programas fornecidos com o software para dar suporte à RTI. Exemplos simples com muitos comentários estão incluídos na biblioteca do The Portico Project e estão disponíveis gratuitamente em porticoproject.org . Quase todas as implementações comerciais da norma também contêm muitos exemplos.



Como exemplo, considere a seguinte federação, que consiste em dois federados: um carro controlado por rádio e um painel de controle. Suponha que o controle seja realizado definindo a velocidade de cada um dos 4 motores do carro e girando as rodas dianteiras. A máquina está equipada com um sensor que determina a distância do obstáculo e transmite um sinal ao painel de controle. Para isso, é necessário definir duas classes de objetos, cYpravlenie para o painel de controle e cDatchik para o sensor de distância. Os atributos da classe cYpravlenie são wheel1, wheel2, wheel3, wheel4, wheel_angle. O atributo da classe cDatchik é distance. A seguir, está um arquivo de descrição da federação, no formato HLA 1.3 (as interações são fornecidas como exemplo).

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

)
	

Em seguida, o simulador que representa o controle cria uma federação e um objeto com base na classe cYpravlenie. O simulador que representa o carro também cria uma federação e um objeto com base na classe cDatchik. Os federados também assinam as alterações nas quais estão interessados, ou seja, A máquina federada assina o recebimento de dados do objeto da classe cYpravlenie (ou seja, a classe cYpravlenie) e o controle federado na classe cDatchik. Assim, a máquina recebe alterações do painel de controle e o painel de controle recebe dados do sensor no carro.



A construção de sistemas de simulação mais complexos requer um design bastante sério. Primeiro, é necessário determinar a composição principal da federação em uma primeira aproximação, isto é, federados, objetos federados e atributos de objetos. Ao elaborar o esquema de federação, é necessário levar em consideração os componentes de hardware dos sistemas de simulação distribuídos, ou seja, sensores e dispositivos de hardware de controle também devem ser representados na forma de federados, objetos e atributos. Na figura. mostra a estrutura da federação do simulador de instalação da bomba de haste de ventosa.





Cenário. Estrutura de federação



Após a composição da federação, é necessário definir links, ou seja, um reflexo de quais federados publicam (ou seja, alteram) os atributos de objetos e quais assinam as alterações desses atributos. Como regra, no estágio de definição de links, um grande número de "emendas" é estabelecido para a estrutura da federação. Após o número necessário de iterações do "refinamento" da estrutura e dos relacionamentos, os designers devem estabelecer o fato da "correção do modelo" da federação. Um exemplo de definição de links é mostrado na figura (objetos sem links estão ocultos).





Cenário. Um exemplo do primeiro estágio de definição de links



No estágio seguinte, o número necessário de computadores é determinado e a distribuição correspondente de federados. Por exemplo, a federação "A" funcionará no computador "1", as federações "B, C, D" funcionarão no computador "2".





Cenário. Distribuição de federados por computadores



Como regra geral, a distribuição de federados é baseada na economia de seu modelo matemático, se os modelos matemáticos de federados não exigirem recursos computacionais significativos, então um computador pode ser usado, se os modelos matemáticos de federados exigirem recursos computacionais significativos, é necessário determinar o número de computadores e a distribuição correspondente de federações.



A próxima etapa é criar um arquivo de descrição da federação (veja o exemplo acima) que reflete o "modelo correto" aprovado da federação. Em seguida, você cria uma implementação de software dos federados escrevendo o código apropriado para interagir com a RTI e o código para implementar o modelo matemático da federação. Na fase final, é necessário testar o sistema de simulação distribuído, identificar erros, "sobrecargas" de determinados componentes no sistema (com base em estatísticas), sincronizar corretamente, etc. As



estatísticas de cada federação separadamente e da federação como um todo mostram o número e os tipos de consultas executadas e permite identificar possíveis problemas durante a operação do sistema



Estatísticas de exemplo para uma federação:

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 

Sincronização de tempo

Como demonstrou a prática do design e implementação de sistemas de simulação distribuídos, os problemas mais difíceis estão relacionados ao controle do fluxo do tempo (sincronização do tempo).



Normalmente, quando você define como o tempo federado é sincronizado, dois parâmetros são definidos, TimeRegulating e TimeConstrained. Na prática, esses modos afetam o processo de recebimento de mensagens de outros federados e estão diretamente relacionados ao mecanismo de pedido de mensagens:

• em ordem de recebimento (as mensagens são transmitidas na ordem em que foram recebidas sem controle de tempo);
• prioridade (as mensagens recebidas estão localizadas em uma fila de prioridade, seu registro de data e hora é usado para determinar a prioridade de uma mensagem);
• causal (garante que as mensagens sejam enviadas aos federados em uma ordem consistente com os eventos anteriores e subsequentes representados por essas mensagens);
• por registros de data e hora (ao usar esse serviço, as mensagens serão enviadas aos federados na ordem de seus registros de data e hora).

Também é importante notar que diferentes federados podem usar diferentes métodos de sincronização.

Bibliotecas de software para implementação de RTI

Uma lista de implementações HLA \ IEE1516 disponíveis está disponível em en.wikipedia.org/wiki/Run-Time_Infrastructure . Hoje, um número razoavelmente grande de implementações está disponível, comercial e não comercial. A maioria das implementações é feita em JAVA e C ++ (essas são as linguagens usadas no padrão), mas também existem implementações para MatLab, Python (projeto CERTI) etc.



Ao escolher uma biblioteca, atenção especial deve ser dada à "certificação" para suportar a IEEE 1516. Como regra geral , todas as implementações comerciais têm um "certificado", as gratuitas não (muitas das implementações gratuitas estão se preparando para essa certificação).



Tabela de vendas comerciais:

• CAE RTI CAE Inc.
• en.wikipedia.org/wiki/CAE_Inc .
• Chronos RTI Magnetar Games
• www.magnetargames.com/Products/Chronos
• MÄK Alto desempenho RTI MÄK Technologies
• www.mak.com/products/rti.php
• Sistemas HLA Direct General Dynamics C4
• en.wikipedia.org/wiki/General_Dynamics_C4_Systems
• Sistemas de rede virtual RTI Openskies
• www.openskies.net
• Pitch PRTI Pitch Technologies
• www.pitch.se/products/pitch-prti/pitch-prti-overview.html
• RTI NG Pro Raytheon Corporação de Tecnologia Virtual
• www.raytheonvtc.com/products.jsp

Tabela de vendas não comerciais:

• CERTI ONERA
• savannah.nongnu.org/projects/certi
• en.wikipedia.org/wiki/ONERA
• O Projeto Portico littlebluefrog labs
• porticoproject.org
• GERTICO (RTI alemão baseado em Corba) Fraunhofer IITB
• www.iitb.fraunhofer.de/servlet/is/2920
• Universidade Nacional de Ciência e Tecnologia da RTI (NUST), Paquistão
• www.mcs.edu.pk/PDC-RG.html
• HLA aberto (ohla)
• sourceforge.net/projects/ohla

Pessoalmente, uso o projeto ONERA CERTI (https://savannah.nongnu.org/projects/certi) para dar suporte à infraestrutura de aplicativos distribuídos.

Medições da velocidade de interação dos federados via RTI

Esses testes são muito importantes no design de sistemas de simulação distribuídos, especialmente se diferentes federações estiverem localizadas em redes de computadores diferentes, e ainda mais importantes ao interagir com federados pela Internet.



Para obter os atrasos mínimos de tempo, você deve selecionar o servidor com os atrasos mais baixos de tempo de trânsito de pacotes (pode ser verificado usando o comando ping). Como exemplo, vamos considerar o trabalho de um dos sistemas distribuídos criados no NII EOR TyumGNGU. É usada uma rede de 100 megabits (atrasos de ping <0,231 ms), não há sincronização de tempo (para reduzir atrasos dentro da RTI), 2 computadores, o servidor (rtig) está sendo executado em uma das máquinas. Parâmetros de federação - 2 objetos contêm 5 atributos (um objeto por federação / computador), a interação entre federados é bidirecional. Como resultado do processamento das medições, foi obtida a dependência do número de interações por segundo no tamanho dos dados transmitidos.



Os resultados dessas medições permitem tirar muitas conclusões, por exemplo, se o simulador funcionar em um determinado "tempo real", ou seja, atualize, por exemplo, pelo menos 60 vezes por segundo e, para uma interação (para Fast Ethernet), não devem ser transmitidos mais de 300 kilobytes (se, por exemplo, 5 atributos e 60 kilobytes cada). Ao mesmo tempo, 300 kilobytes de dados transmitidos 60 vezes por segundo também indicam a possibilidade de usar o RTI para transferir dados de voz e vídeo entre simuladores, bem como para interagir com dispositivos de realidade virtual.



Quando federada pela Internet, a latência mínima é determinada em grande parte pelos atrasos na transmissão de pacotes. Por exemplo, se a latência de um pacote entre o servidor e o simulador for 300 ms, o número máximo de interações por segundo não excederá 3.



O uso de soluções mais rápidas, como IpoIB (IP sobre InfiniBand, RFC 4392), Ethernet 10G, Myrinet-10G, etc. permitirá aumentar a taxa de transferência e reduzir significativamente a latência (as soluções existentes permitem produzir 30 milhões de interações por segundo ou mais).

Interação com sistemas reais

Não apenas modelos matemáticos de objetos, isto é, sistemas artificiais, mas também sistemas e dispositivos reais podem atuar como federados. Exemplos incluem:

• microfone fornecendo dados de áudio;
• câmera de vídeo que fornece dados de vídeo;
• vários dispositivos de entrada / saída, como joysticks (imagem), impressoras, etc.
• vários sensores e mecanismos de controle conectados ao computador via placas ADC / DAC;
• equipamentos reais e sistemas SCADA (Figura 2.10.1., capítulo 1.4.1.) via interface industrial OPC;
• Interfaces para a "área de trabalho" de um sistema operacional real executando em um computador ou máquina virtual separada (figura);
• Dispositivos de RV (capítulo 4.5.9.);
• Interface de banco de dados, etc.

Tais possibilidades são de interesse considerável para simuladores e sistemas de simulação em geral.