• Nenhum resultado encontrado

Esta infraestrutura permite analisar o comportamento de uma RSSF quando a mesma est ´a executando uma dada aplicac¸ ˜ao reativa. Para tal, um modelo de simulac¸ ˜ao no Eboracum combina a carga de trabalho da aplicac¸ ˜ao alvo, a qual ´e composta por eventos gerados pelo ambiente, `a infraestrutura de computac¸ ˜ao e comunicac¸ ˜ao, permitindo assim avaliar a efici ˆencia de uma soluc¸ ˜ao, no que diz res- peito a m ´etricas que s ˜ao importantes para dom´ınios de aplicac¸ ˜ao espec´ıficos e res- pectivos usu ´arios finais. Atualmente, a avaliac¸ ˜ao suportada pelo Eboracum foca na efici ˆencia energ ´etica, permitindo avaliar a descarga de bateria dos nodos da rede ao executar uma dada aplicac¸ ˜ao. Considerando a bateria dos nodos e tamb ´em a manutenc¸ ˜ao das conex ˜oes da rede com a estac¸ ˜ao base, ´e poss´ıvel tamb ´em avaliar o tempo de vida da rede e o n ´umero de eventos sensoriados pela rede.

Para simular o processamento dos eventos capturados, os nodos s ˜ao providos de uma CPU. Um evento pode ser associado a um gr ´afico de tarefas e cada tarefa pode ter diferentes custos computacionais. Esses custos v ˜ao determinar quanto tempo a CPU ficar ´a ocupada e quanta energia ´e gasta com o processamento de cada tarefa e consequentemente o tratamento para aquele dado evento. Ap ´os o processamento, o nodo deve enviar uma mensagem para seu gateway, que por sua vez retransmite esta mensagem para o seu gateway, at ´e que a mensagem atinja o sink. Durante a simulac¸ ˜ao, a descarga das baterias dos nodos ´e calculada, considerando o estado de sua bateria e as atividades realizadas por estes.

34

Para simular a bateria do nodo descarregando durante a simulac¸ ˜ao, os nodos t ˆem a carga de suas baterias recalculadas de acordo com suas atividades. Esse processo de descarga baseia-se em custos definidos para cada modo de operac¸ ˜ao do nodo. Um nodo pode estar inativo, processando ou comunicando. Quando est ´a inativo, quer dizer que o nodo n ˜ao est ´a nem comunicando e nem processando, assumindo que os componentes respons ´aveis pelo sensoriamento (detecc¸ ˜ao de eventos) est ˜ao sempre trabalhando. O custo de recepc¸ ˜ao do r ´adio tamb ´em est ´a incluido no modo inativo do nodo. O custo de comunicac¸ ˜ao est ´a relacionado somente com a operac¸ ˜ao de envio de mensagens, ent ˜ao somente o nodo que transmite a mensagem descarrega sua bateria, mas a mensagem que faz v ´arios hops tem custo para cada nodo que a en- caminha. Quando no modo de processando, o n ´umero de ciclos de CPU executados ´e multiplicado pelo custo energ ´etico deste modo de operac¸ ˜ao para determinar a des- carga.

Para a parte visual das simulac¸ ˜oes, o Eboracum utiliza a interface gr ´afica ou GUI (do ingl ˆes, Graphical User Interface) do Ptolemy II, que ´e chamada Vergil e a qual per- mite que os projetistas possam construir modelos, instanciando componentes de suas bibliotecas, incluindo as primitivas suportadas pelo Eboracum. No entanto, construir modelos de RSSF com muitos componentes manualmente utilizando essa GUI pode ser uma tarefa muito custosa, no que diz respeito ao tempo de construc¸ ˜ao.

A construc¸ ˜ao do modelo de simulac¸ ˜ao tamb ´em pode ser realizada atrav ´es de codificac¸ ˜ao em Java, onde ´e poss´ıvel escolher as primitivas a serem instanciadas, bem como sua quantidade, posicionamento, dentre outras configurac¸ ˜oes. Seguindo esta ideia, o Eboracum tamb ´em oferece o BenchmarkGenerator, classe que pode ser utilizada para gerar modelos de simulac¸ ˜ao, evitando a instanciac¸ ˜ao de componentes e seu posicionamento manuais. Neste caso, o usu ´ario define o tipo de nodo que ser ´a utilizado, a quantidade de nodos e o tipo de distribuic¸ ˜ao dos mesmos na ´area de inte- resse (random ou mesh) e o posicionamento do sink. O usu ´ario deve definir tamb ´em os eventos que acontecem no ambiente e que geram a carga de trabalho para a rede, tipo e n ´umero de eventos, bem como sua distribuic¸ ˜ao espacial e temporal. O modelo gerado pelo BenchmarkGenerator pode ser ent ˜ao carregado pelo Vergil. Este modelo ´e representado em XML (do ingl ˆes, Extensible Markup Language), que ´e o formato empregado pelo Ptolemy II.

Ao t ´ermino da simulac¸ ˜ao, um arquivo no formato CSV (do ingl ˆes, Comma Sepa- rated Values) ´e gerado, contendo os resultados coletados. Na Tabela 1 ´e poss´ıvel visualizar um resumo dos dados providos neste arquivo.

Tabela 1: Dados que comp ˜oem o relat ´orio de simulac¸ ˜oes (FERREIRA; BRISOLARA; INDRUSIAK, 2015)

Nome Descric¸ ˜ao

#Eventos sensoriados N ´umero de eventos sensoriados, processados e quais foram enviados ao sink

Tempo total de simulac¸ ˜ao O tempo de simulac¸ ˜ao deve ser convertido em sema- nas ou meses

#Eventos restantes N ´umero de eventos restantes dentro das CPUs FIFOs de cada nodo sensor

Bateria restante Bateria de cada nodo sensor Tempo de morte Quando cada nodo morre

#Mensagens enviadas N ´umero de mensagens enviadas por cada nodo #Mensagens perdidas O n ´umero de mensagens perdidas ´e definido como

uma mensagem disparada por um evento e que ´e pro- cessada, mas a qual n ˜ao chega ao sink

4

MOBILIDADE EM RSSF: ESTRAT ´EGIA PROPOSTA

Este cap´ıtulo apresenta uma estrat ´egia din ˆamica para adaptabilidade em RSSF reativas, onde a mobilidade de nodos ´e empregada para maximizar a cobertura da rede. Em redes implantadas aleatoriamente, a estrat ´egia ´e empregada para mover os nodos visando espalh ´a-los sobre a ´area de interesse, evitando sobreposic¸ ˜oes e maximizando a cobertura desta ´area. Em redes implantadas em mesh ou grade (grid ), a estrat ´egia pode ser empregada para mover nodos `a medida em que alguns nodos ficam inativos devido `a falta de bateria. Neste caso, a mobilidade visa reposicionar os nodos visando reduzir as lacunas de cobertura causadas pela descarga da bateria de alguns nodos da rede.

A mobilidade proposta baseia-se no equil´ıbrio de forc¸as empregado em HOWARD; MATARI ´C; SUKHATME (2002a). Baseado nesta ideia de forc¸as da rob ´otica m ´ovel, em nossa estrat ´egia, nodos exercem forc¸as de repuls ˜ao que fazem com que nodos se movam, visando afast ´a-los uns dos outros de forma a minimizar a redund ˆancia entre os nodos e maximizar cobertura da rede. Os movimentos ocorrem at ´e que um equil´ıbrio est ´atico seja alcanc¸ado e a computac¸ ˜ao requerida para c ´alculo da nova posic¸ ˜ao ´e simples, o que permite sua implementac¸ ˜ao e emprego em ambientes de simulac¸ ˜ao de RSSF como o EBORACUM. A fundamentac¸ ˜ao te ´orica da estrat ´egia proposta ´e apresentada na Sec¸ ˜ao 4.1 e aspectos da implementac¸ ˜ao da estrat ´egia no framework EBORACUM s ˜ao discutidos na Sec¸ ˜ao 4.2.

Documentos relacionados