HLA síncrono e assíncrono

O CERTI, implementação do HLA utilizado, tem algoritmos que determinam como será realizada a comunicação entre os robôs da simulação. Esses algoritmos são tratados através de políticas de tempo, que determinam o modo como será feita a simulação, e podem assumir os modos síncronos e assíncronos pré-determinados, que serão testados e analisados nesta seção, com o objetivo de elencar os principais problemas em cada um desses modos de operação.

4.1 Experimento 1 31 Código Fonte 4.2: Criação, associação, desassociação e destruição da federação.

1

2 t h i s −>fedamb = new ExampleFedAmb ( federateName ) ;

3 4 / ∗ I n g r e s s o na F e d e r a c a o ∗ / 5 r t i a m b −>j o i n F e d e r a t i o n E x e c u t i o n ( federateName , " E x a m p l e F e d e r a t i o n " , fedamb ) ; 6 7 / / R e t i r a −se da na f e d e r a c a o 8 r t i a m b −>r e s i g n F e d e r a t i o n E x e c u t i o n ( RTI : : NO_ACTION ) ; 9 c o u t << " R e s i g n e d from F e d e r a t i o n " << e n d l ; 10 / ∗ Try and d e s t r o y f a d a r a t i o n ∗ / 11 Try { 12 r t i a m b −>d e s t r o y F e d e r a t i o n E x e c u t i o n ( " E x a m p l e F e d e r a t i o n " ) ; 13 c o u t << " D e s t r o y e d F e d e r a t i o n " << e n d l ; 14 } 15 c a t c h ( RTI : : F e d e r a t i o n E x e c u t i o n D o e s N o t E x i s t dne ) 16 {

17 c o u t << "No need t o d e s t r o y f e d e r a t i o n , i t doesn ’ t e x i s t " << e n d l ;

18 } 19 c a t c h ( RTI : : F e d e r a t e s C u r r e n t l y J o i n e d f c j ) 20 { 21 c o u t << " Didn ’ t d e s t r o y f e d e r a t i o n , f e d e r a t e s s t i l l j o i n e d " << e n d l ; 22 } 4.1.2.1 HLA síncrono

O HLA no modo síncrono, também conhecido como conservativo (FUJIMOTO, 1999), fun- ciona de forma a manter todos os robôs com o mesmo número de envio de mensagens, fazendo com que aquele que está atuando mais lentamente sempre imprima o ritmo do en- vio das mensagens e atrase a quantidade de mensagens enviadas pelos robôs mais rápidos, de modo que o número de mensagens se iguale. Isso ocorre porque os robôs que têm mais capacidade de envio não conseguem enviar de acordo com sua capacidade, porque têm que acompanhar o ritmo dos robôs cuja capacidade de envio é inferior à dos que conseguem enviar mais rapidamente.

Assim, para que a velocidade de transmissão seja ditada pelos robôs com menos veloci- dade para o envio, o AdvanceTime é bloqueante na transmissão de mensagens dos robôs que estejam atuando mais rapidamente. Esse bloqueio indica que, ainda que um robô esteja apto a transmitir, a autorização para esse envio só é concedida pelo RTIG quando todos os robôs solicitarem o advanceTime para a mesma iteração, ou seja, quando todos atingirem o mesmo tempo lógico global na execução

4.1 Experimento 1 32 Tabela 4.3: Resultado com comunicação sincrona

Cenário Tempo total (s) Período en- tre mensa- gens (ms) Mensagens enviadas em 100ms 1 15,81 1,58 63 2 126,4 12,64 7 3 137,8 13,78 7 4 63,8 6,38 15 5 188,9 18,89 5

4.1.2.2 Considerações e Análise HLA sincrono

Em cenários em que existem máquinas com atuação em que o tempo de processamento é sempre equivalente e o processamento se assemelha, esse método de funcionamento é o mais adequado. Esses cenários podem ser vistos na Tabela 4.1 nos Cenários 01 e 04.

No cenário 01, todos os robôs são compostos por computadores com alto poder de pro- cessamento, mas nenhum deles é um gargalo na aplicação. Não muito diferente, o cenário 04 é formado por robôs com médio poder de processamento, o que faz com que todo o sistema funcione com esse ritmo, mas, ainda assim, não existe nenhum gargalo significativo atuando no sistema.

Essa restrição, inerente a algoritmos síncronos, é proibitiva em cenários como o de fute- bol de robôs, uma vez que o tempo de processamento necessário para formar a mensagem pode variar bastante de acordo com vários fatores como oclusão, quantidade de objetos que serão processados, interferências externas, entre outros. Como exemplo dessa consequên- cia, pode-se verificar, nos Cenários 02, 03 e 05 da Tabela 4.3, que todos esses experimentos foram fortemente prejudicados pela atuação lenta de um dos seus robôs, aqui atuado pelo Raspberry PI. Isso é mais evidente quando comparados os cenários 01 e 02, que, só por substituir um dos seus membros pelo Raspberry PI, fez com que o tempo total ficasse cerca de oito vezes mais lento.

Como pode ser visto na Tabela 4.3, o pior cenário composto por cinco robôs, incluindo o Raspberry PI, obteve um intervalo entre mensagens de 18,89ms, o que está muito abaixo da restrição determinada para futebol de robôs, que é de 100ms. Isso demonstra que o HLA tem um grande potencial para aplicações críticas de tempo real, como o futebol de robôs.

4.1 Experimento 1 33 Tabela 4.4: Resultado com comunicação assíncrona

Tempo total (s) Netbook 1 Netbook 2 Raspberry Pi

61,2 Mensagens: 10.000 Mensagens: 8.780 Mensagens: 4

Intervalo: 6,12 ms Intervalo: 6,97 ms Intervalo: 15.300 ms

4.1.2.3 HLA assíncrono

Outra forma de funcionamento que o HLA pode assumir é a assíncrona ou otimista (FUJI- MOTO, 1999). Quando isso acontece, ele não impõe a política que obriga os robôs mais rápidos a terem que esperar a liberação por parte do servidor RTIG para eles enviarem suas mensagens, pois, ao realizar tal processo, existe o favorecimento do envio de mensagens do mais lento em detrimento dos mais rápidos. Assim, todos os robôs têm autorização para enviar todas as suas mensagens quando elas estiverem prontas. A principal vantagem desse método é que o sistema não deteriora devido ao mau funcionamento ou desempenho redu- zido momentaneamente de um dos robôs na rede. Dessa forma, todos os outros robôs serão capazes de atuar com desempenhos máximos durante toda a aplicação. Assim, para mensu- rar esse efeito em um sistema multirrobôs, foi repetido um dos cenários prévios, nesse caso, o cenário 03, pelo fato de apresentar um robô que atua com baixo desempenho durante a comunicação, o Raspberry PI.

4.1.2.4 Considerações e Análise HLA assincrono

Como mostra a Tabela 4.4, o tempo total médio da aplicação foi reduzido de 137 segundos, valor gasto na comunicação síncrona, para apenas 61. Isso mostra que o fator não limitante do algoritmo assíncrono aumenta o desempenho geral do sistema em mais de duas vezes.

Convém enfatizar que a rápida execução da aplicação reduz a atualização de posições dos robôs mais lentos. Como demonstrado na Tabela 4.4, o intervalo entre mensagens que era de cerca de 13 ms passou a ser de 15.300 ms no robô mais lento, fazendo com que ele receba muito mais mensagens do que pode enviar. Assim, o robô mais lento passou a ficar muito distante dos 100 ms determinados numa aplicação de futebol de robôs, o que faz desse modelo inviável em situações em que robôs possam se comportar mais lentamente do que os demais.