STRATİGRAFİ

Para integrar o modelo proposto ao HLA é necessário realizar algumas mudanças em alguns atores do cenário e também na forma espacial como está dividido o cenário. Dessa forma, o modelo foi dividido em diversas partes, nas quais as mesmas pessoas envolvidas na simulação inicial continuarão andando ao redor do mesmo ambiente projetado. Tais pessoas estão dispersas de várias formas entre as máquinas escravas envolvidas na simulação. A Figura 31 mostra como pode ser feita tal divisão.

Figura 31. Divisão espacial do cenário do Ptolemy puro [printscreen da aplicação – elaborado pelo autor]

A Figura 32 apresenta como pode ficar tal divisão do modelo em diferentes máquinas. Como se pode notar, cada arquivo que está em uma máquina distinta irá apresentar parte das pessoas envolvidas na simulação, um conjunto de sensores, o alvo posicionado no mesmo lugar do modelo original, e os diretores responsáveis por fazer o gerenciamento de toda a simulação.

Figura 32. Divisão efetuada em máquinas escravas distintas [printscreen da aplicação – elaborado pelo autor]

O sensor central é um ator composto que sofreu as alterações necessárias para viabilizar a integração com o HLA. Como pode ser visto na Figura 33, este sensor contém tanto o SensorDataForecasting como também um novo ator, chamado

SlaveFederateActor (moldado com um quadrado na Figura 33), que é o ator responsável

por receber os dados em suas portas de entrada referente a captura das pessoas através dos sensores e enviá-los para o RTI. Os dados que irão para porta de entrada do

SlaveFederateActor, que, por sua vez, será enviado ao RTI, são os dados do SensorDataForecasting que são referentes a essa captura de forma mais detalhada

(sensor que capturou a pessoa, a pessoa capturada, o sensor central que está lidando com a informação, e o momento (time) da captura). O papel do SlaveFederateActor neste cenário é poder enviar tais dados ao RTI. Além desse ator, o diretor responsável por gerenciar as atividades que ocorrem nesse ator composto, também foi alterado. Criou-se um novo Diretor, chamado SlaveHLADEDirector (moldado com um retângulo na Figura 33), que é baseado no DE Director, adaptado para as necessidades do HLA.

Como pode ser notado na Figura 32 anterior, cada grupo de sensores que contém o SlaveFederateActor pode ser alocado em máquinas slaves distintas. Além de que, as pessoas envolvidas na simulação também podem estar espalhadas por várias máquinas

Figura 33. Sensor central em detalhes do escravo do cenário com HLA [printscreen da aplicação – elaborado pelo autor]

Além das máquinas escravas envolvidas na simulação, existe também para este caso específico, uma única máquina mestre isolada em uma máquina a parte da rede, que será a responsável por agrupar todos os dados resultantes das capturas dos sensores que, por sua vez, foram enviados ao RTI. É bom lembrar que o mestre só tem acesso aos dados capturados através do RTI (Regra 3 do HLA). Logo, a principal finalidade do mestre é ser uma espécie de gateway que receberá todos os dados envolvidos na simulação, de todas as máquinas escravas, através do RTI. Com os dados referentes a todos os escravos (federados) envolvidos na simulação, é possível realizar uma tomada de decisão, de acordo com a necessidade, que não faz parte do escopo desta dissertação.

A Figura 34 a seguir mostra o projeto da máquina mestre em detalhes, projeto esse que não faz presente no cenário que contém o Ptolemy de forma isolada, pois nesse caso não existia a necessidade de um mestre (ou um ponto central), porque todos os atores (pessoas, sensores que capturam as pessoas, sensores centrais) estavam inseridos no mesmo modelo (ou projeto) de simulação e assim a captura dos dados não precisava ser enviada para nenhum outro ator de fora do modelo em questão.

Assim como nas máquinas escravas, todas eram gerenciadas pelo

WirelessDirector, a máquina mestre também é gerenciada por esse mesmo diretor. O soundSource (esferas concêntricas) em questão é um ator composto que contém os

atores necessários para integrar o modelo por completo ao HLA. Nota-se então que esse ator contém o diretor MasterHLADEDirector, baseado no DE Director, responsável por gerenciar os dados que serão trocados entre os atores. O outro ator necessário para a integração com o HLA é o MasterFederateActor, que irá receber através do RTI todos os dados provenientes de todos os escravos, e assim irá enviar para a sua porta de saída (dados tratados do slave). Com tais dados na porta de saída, pode-se exibir na própria simulação tais dados, através de gráficos, animação, entre outras possibilidades. Os dados da porta de entrada desse ator são meramente ilustrativos, pois no exemplo em questão, o escravo não irá receber nenhum dado do mestre através do RTI. Os dados da porta de entrada do MasterFederateActor são enviados para o RTI também de tempo em tempo, que por sua vez, caso os escravos precisem, podem requisitar ao RTI tais dados, que serão copiados para sua porta de saída (SlaveFederateActor – dados do

máster tratados – Figura 33). Os demais parâmetros desse ator não se fazem necessário

uma explicação mais detalhada, já que não apresentam importância para este caso. Para entender melhor, basta analisar a Figura 17 (Seção 5.1) que explica em detalhes a troca desses dados. Em resumo, o escravo envia dados para o RTI através do

SlaveFederateActor, os dados que chegarão do slave para o RTI são os dados da porta

de entrada do SlaveFederateActor. O mestre por sua vez, recebe os dados enviados pelos escravos, através do MasterFederateActor, também através da requisição via RTI. Os dados recebidos são copiados para a porta de saída do MasterFederateActor. O sentido contrário também pode ser realizado.

Figura 34. Mestre em detalhes do cenário com HLA [printscreen da aplicação – elaborado pelo autor]

Uma observação interessante é que tanto o MasterHLADEDirector quanto o

SlaveHLADEDirector são subclasses do HLADirector, e é a classe principal que faz

praticamente toda a lógica necessária para lidar com o RTI. Essa interação através das classes envolvidas pode ser vista na Seção 5.1.1.

Outra importante característica desse cenário criado é que o mesmo continuou preservando a característica de heterogeneidade quando foi integrado ao HLA. Os dois modelos, o com e o sem HLA, trabalham com dois diretores distintos, sendo o

WirelessDirector o responsável pela gerencia global, e o DE Director responsável por

gerências locais.