• Nenhum resultado encontrado

4. Modelagem de Sistemas para RSASF Utilizando LWiSSy

4.2. LWiSSy

4.2.1. Visão estrutural

O subconjunto do metamodelo de LWiSSy apresentado na Figura 4-2 representa a visão que abrange as características estruturais das RSASF (visão estrutural). Ela destina-se aos especialistas de domínio e aborda a programação da rede como um todo e dos grupos de nós.

Por meio desta visão o especialista de domínio pode criar uma RSASF, através do componente WSANSystem, sem que seja necessário possuir conhecimentos profundos acerca desta área, uma vez que para isto basta que o especialista defina o nome (atributo name do componente WSANSystem) do sistema de RSASF que ele deseja criar. Feito isto, faz-se necessária à criação de regiões (componente Region). Uma região consiste de um agrupamento de nós que se localizam em uma mesma região geográfica, ou seja, nós que serão dispostos próximos uns dos outros no ambiente físico. Mais uma vez, o especialista terá apenas que definir o nome da região (atributo name do componente Region) e latitude e longitude (atributos latitude e longitude do componente Region), caso um ambiente externo seja considerado.

70

Figura 4-2 Modelo gráfico que representa a visão estrutural em LWiSSy.

Por sua vez, as regiões serão compostas por grupos de nós (componente

NodeGroup). Um grupo de nós trata-se de uma entidade a qual agrupa nós que

irão desempenhar tarefas semelhantes na rede. Dessa forma, o especialista deve definir quais e quantos grupos de nós irão integrar o seu sistema. Durante a modelagem de um grupo de nós, o especialista terá que definir o nome do grupo de nós (atributo name do componente NodeGroup), a quantidade mínima e máxima de nós pertencentes àquele grupo (atributos minNumNodes e

maxNumNodes do componente NodeGroup) e o tempo de vida desejado (atributo lifeTime do componente NodeGroup). O tempo de vida do grupo pode ser

definido como LONG ou SHORT, valor este que influenciará na tarefa do especialista de redes quanto ao gerenciamento do consumo de energia dos grupos de nós. Isto porque caso seja definido o valor LONG será necessário utilizar políticas de gerenciamento de energia mais restritivas, uma vez que o especialista de domínio deseja que àquele grupo permaneça ativo na rede por muito tempo. Caso contrário, quando o valor SHORT é escolhido, o especialista

71

de redes visualiza que as políticas podem ser menos restritivas já que não é esperada uma longa permanência daquele grupo na rede.

Convém destacar que o atributo de tempo de vida do grupo de nós foi incluído na modelagem de LWiSSy por se tratar de um requisito de QoS crítico para diversas aplicações da área de RSASF, como por exemplo: monitoramento de marés e oceanos, que permitem a melhoria da previsão climática de secas e inundações e a determinação dos índices de precipitação pluviométrica; detecção de focos de incêndio em florestas, afim de agilizar a localização e o combate ao fogo, etc. Isto ocorre porque muitos destes ambientes onde as redes são instaladas são de difícil acesso para o ser humano o que dificulta o acesso a esses elementos para manutenção. Além disso, o valor definido para o atributo lifeTime impacta diretamente na escolha dos protocolos de comunicação e roteamento que serão utilizados pelo sistema e definidos durante a modelagem da visão de refinamento efetuada pelo especialista de redes. A escolha destes protocolos é impactada, pois ambos lidam diretamente com o consumo de energia da rede, seja a fim de economizar ou não este recurso.

Nós pertencentes a grupos diferentes poderão estabelecer comunicação uns com os outros através de conexões sem fio (componente WirelessLink), nas quais devem ser definidos o grupo de nós que origina a comunicação (atributo

source do elemento WirelessLink) e o grupo de nós alvo da comunicação

(atributo target do elemento WirelessLink).

Após a definição dos grupos de nós, o especialista de domínio precisa definir ainda quais recursos (componente Resource) serão implantados nos nós que compõem cada um dos grupos. Assim sendo, o especialista de domínio pode definir um recurso como sendo um sensor (componente Sensor) caso ele deseje acoplar uma ou mais placas de sensores (sensores de temperatura, de localização, de luminosidade, entre outros) nos nós sensores presentes naquele grupo. Caso seja necessária à utilização de atuadores (componente Actuator) o

72

especialista poderá definir o tipo de atuador que será utilizado (relay ou

shaker). O especialista pode ainda definir recursos do tipo porta (componente Port), os quais são utilizados por nós sink para conectá-los as estações base

seja por meio de portas USB ou seriais.

Por fim, faz-se necessária a definição das aplicações (componente

Application) que serão executadas por cada um dos grupos de nós presentes no

sistema. Esta característica de permitir a execução de múltiplas aplicações em uma mesma infraestrutura de sensoriamento faz com que LWiSSy suporte a modelagem da nova geração de sistemas para RSASF (Shared Sensor Networks). Durante a modelagem deste elemento, o especialista de domínio deve definir o nome da aplicação (atributo name do componente Application), uma descrição (atributo description do componente Application), caso ache necessário, a quantidade de nós que desempenharão as atividades relacionadas com aquela aplicação (atributo nodesQuantity do componente Application), a acurácia dos dados desejada pela aplicação (atributo dataAccuracyRange do componente

Application) e a latência máxima esperada (atributo maxLatency do componente Aplication). Dentre os atributos supracitados dois merecem uma atenção

especial, sendo eles dataAccuracyRange e maxLatency.

O primeiro deles lida com um importante requisito de QoS, a saber, a precisão (acurácia) dos dados que é exigida pelas aplicações e que norteia a decisão sobre qual protocolo de comunicação será utilizado, visto que diferentes protocolos proveem diferentes garantias de QoS. Esse atributo pode assumir valores entre 0 e 1, onde 0 significa que a precisão dos dados não é importante para a aplicação (como em algumas aplicações de monitoramento ambiental, por exemplo) e 1 significa que a precisão é um requisito crítico para a aplicação (como em aplicações para monitoramento em health care e em indústrias petroquímicas).

O segundo atributo, maxLatency, o qual deve ser definido em milissegundos, lida com o intervalo de tempo entre o momento em que determinada ação é

73

sensoriada até o momento em que essa informação é armazenada no seu destino final, seja um nó sink ou um outro nó da rede. Este atributo deve ser definido com base no documento de requisitos do sistema e seu valor afeta diretamente o consumo de energia da rede e o protocolo de comunicação que será utilizado, pois quanto menor for a latência máxima definida, mais intensa será a comunicação entre os nós da rede, causando um aumento no consumo de energia e a necessidade de utilização de um protocolo de comunicação confiável a fim de garantir que a maior quantidade possível de pacotes transmitidos sejam recebidos.

Após uma rápida análise da visão descrita acima é possível notar que há dois tradeoffs na visão estrutural. O primeiro deles acontece entre os atributos

lifeTime (componente NodeGroup) e dataAccuracyRange (componente

Applicaton), visto que não é possível garantir uma acurácia de dados elevada

caso políticas de gerenciamento de energia que visam um gasto mínimo sejam utilizadas. O outro tradeoff ocorre entre os atributos lifeTime (componente

NodeGroup) e maxLatency (componente Application). Como apresentado no

parágrafo anterior, a latência máxima definida impactará no consumo de energia da aplicação. No entanto, convém ressaltar que este consumo não decrescerá monotonicamente ao passo que o valor da latência máxima for aumentado [YU, 2004]. Para garantir que estes conflitos não sejam inseridos durante a modelagem de sistemas para RSASF, o metamodelo de LWiSSy não permite a configuração dos atributos lifeTime e dataAccuracyRange em seus valores máximos simultaneamente, nem a definição de latências máximas inferiores a 1,5 segundos caso o atributo lifeTime seja configurado como LONG (para se chegar a este valor foram utilizadas as equações definidas em [SCHURGERS, 2001]).

Documentos relacionados