Embed Size (px)
Citation preview
Saymon Castro de Souza
Uma abordagem baseada em regras e computação em nuvem para
desenvolvimento de aplicações em redes de sensores sem fio
VITÓRIA
2013
Saymon Castro de Souza
Uma abordagem baseada em regras e computação em nuvem para
desenvolvimento de aplicações em redes de sensores sem fio
Dissertação submetida ao Programa de Pós-
graduação em Informática da Universidade
Federal do Espírito Santo, como requisito
parcial para obtenção do título de Mestre em
Informática.
Orientador: Prof. Dr. José Gonçalves Pereira
Filho
VITÓRIA
2013
Saymon Castro de Souza
Uma abordagem baseada em regras e computação em nuvem para
desenvolvimento de aplicações em redes de sensores sem fio
Dissertação submetida ao Programa de Pós-Graduação em Informática da Universidade
Federal do Espírito Santo como requisito parcial para a obtenção do grau de Mestre em
Informática.
Aprovada em 30 de Agosto de 2013.
COMISSÃO JULGADORA:
__________________________________ Prof. Dr. José Gonçalves Pereira Filho
Departamento de Informática - UFES Orientador
__________________________________ Prof. Dr. Magnos Martinello Departamento de Informática - UFES
__________________________________ Profa. Dra. Patricia Dockhorn Costa Departamento de Informática - UFES
__________________________________ Profa. Dra. Silvana Rossetto
Departamento de Ciência da Computação - UFRJ
Dedico este trabalho a todos os professores
que tive, pois de alguma maneira,
contribuíram para minha formação.
Agradecimentos
À minha família, que me forneceu a base para que eu conseguisse alcançar meus
objetivos. Também gostaria de agradecer aos meus amigos, seja pelo apoio, pelas
discussões e pelos momentos de descontração, durante o mestrado.
A todos do Centro de Educação a Distância (Cead), do Instituto Federal do
Espírito Santo (Ifes), que me deram apoio total, sempre incentivando durante essa
caminhada.
Ao Eugênio pela colaboração e dedicação a este projeto; e ao Diego Luchi e
Isaac Pereira pela disponibilidade para discutir aspectos importantes deste trabalho.
Aos professores do Departamento de Informática da UFES, pelos ensinamentos;
Ao meu orientador, José Gonçalves, pela grande experiência e enorme dedicação
que me serviram de exemplo profissional e pessoal.
Especialmente, à Jésica, que teve e tem papel muito importante em minha vida,
desde a graduação, estando junto a mim, compreendendo meus momentos de estresse.
RESUMO
Este trabalho propõe uma infraestrutura para gerenciamento de aplicações de
redes de sensores sem fio em ambiente de nuvem computacional. O trabalho inclui o
projeto e a implementação de uma arquitetura conceitual que suporta o desenvolvimento
das aplicações e um sistema de gerenciamento que implementa um espaço para a
criação das regras, gestão das assinaturas das informações de sensoriamento e a
integração com serviços. O objetivo da infraestrutura proposta é simplificar a
construção de aplicações de RSSF e promover uma separação de responsabilidades
entre os usuários programador e o especialista de domínio envolvidos no processo de
desenvolvimento, ao mesmo tempo que permite ampliar o número de aplicações e os
potenciais domínios de uso dos dados coletados pelas redes.
Palavras-chave: redes de sensores sem fio, computação em nuvem, sistemas
baseado em regras
ABSTRACT
This work proposes an infrastructure for managing wireless sensor networks
applications in cloud computing environment. The work includes the design and
implementation of a conceptual architecture that supports the development of
applications and a management system that implements a space for the creation of rules,
management of applications’ subscriptions and integration with services. The aim of
infrastructure is to simplify the construction of WSN applications and promote a
separation of concerns regarding the programmer and the user domain expert involved
in the development process, while increasing the number of potential applications and
areas of use for the data collected by the sensor networks.
Keywords: wireless sensor networks, cloud computing, rule-based systems.
Lista de Figuras
Figura 1 - Nó sensor inteligente. ...................................................................................... 8
Figura 2 - Fonte de energia secundária. ............................................................................ 9
Figura 3 - Estabelecimento de uma RSSF não estruturada. Fonte: (LOUREIRO et al.,
2003) ............................................................................................................................... 10
Figura 4 - Áreas de aplicação de RSSF. Fonte: (FUJITSU, 2013) ................................. 11
Figura 5 - Arquitetura de sistemas baseados em regras. Fonte: (HILL, 2003)............... 14
Figura 6 - Computação em nuvem. Fonte: (ZHANG; CHENG; BOUTABA, 2010) .... 16
Figura 7 - Modelo básico publish/subcriber. Fonte: (EUGSTER et al., 2003) .............. 21
Figura 8 - Desacoplamento no espaço. Fonte: (EUGSTER et al., 2003) ....................... 22
Figura 9 - Desacoplamento no tempo. Fonte: (EUGSTER et al., 2003) ........................ 23
Figura 10 - Desacoplamento de sincronização. Fonte: (EUGSTER et al., 2003) .......... 24
Figura 11 - Modelo básico de fila. .................................................................................. 26
Figura 12- Sistema multicanal com fila única. ............................................................... 29
Figura 13 - Sistema multicanal com fila individual. ...................................................... 29
Figura 14 - Integrating Wireless Sensor Networks with Cloud Computing. Fonte:
(AHMED; GREGORY, 2011) ....................................................................................... 36
Figura 15 - Arquitetura conceitual. Fonte: (LE et al., 2010). ......................................... 37
Figura 16 – Provisão de serviços. Fonte: (YURIYAMA; KUSHIDA; ITAKURA, 2011).
........................................................................................................................................ 39
Figura 17 - Arquitetura Conceitual ................................................................................. 51
Figura 18 - Arquitetura da implementação ..................................................................... 53
Figura 19 - Serviço de gerenciamento da arquitetura proposta. ..................................... 57
Figura 20 - Interface com o usuário................................................................................ 60
Figura 21 - Cadastro de usuários. ................................................................................... 61
Figura 22 - Edição e exclusão de usuários. .................................................................... 61
Figura 23 - Edição e exclusão de aplicações. ................................................................. 62
Figura 24 – Cenário Hospitalar. ..................................................................................... 65
Figura 25 - Regras do cenário......................................................................................... 68
Figura 26 - Interface com o especialista do domínio...................................................... 69
Figura 27 - Componente de configuração nesC. ............................................................ 71
Figura 28 - Componente de Implementação nesC.......................................................... 72
Figura 29 - Implementação da arquitetura. ..................................................................... 75
Figura 30 - Modelo básico de fila. .................................................................................. 77
Figura 31 - Modelo de filas da arquitetura proposta. ..................................................... 79
Figura 32 - Gráfico - Atraso Médio x Taxa de serviço. ................................................. 82
Figura 33 – Gráfico - Atraso médio pelo ρx. ................................................................... 83
Lista de Tabelas
Tabela 1 - Notação de Fila – A/B/m/k/M (MOREIRA, 2007) ....................................... 30
Tabela 2 - Comparação dos trabalhos de infraestrutura Sensor-Cloud. ......................... 40
Tabela 3 - Comparação dos trabalhos que propõe abordagens baseadas em regras para
aplicações das RSSF. ...................................................................................................... 43
Tabela 4 - Informações de estabilidade da vacina contra Varicela. ............................... 66
Lista de Siglas/Acrônimos
RSSF – Redes de Sensores Sem Fio.
IAM - Identity and Access Management.
AWS – Amazon Web Services.
SNS – Simple Notification Service.
SQS – Simple Queue Service.
RDS - Relational Database Service.
S3 – Simple Storage Service.
Sumário
1. Introdução ............................................................................................................... 1
1.1 Motivação ........................................................................................................... 1
1.2 Objetivos ............................................................................................................. 4
1.3 Organização do Trabalho .................................................................................... 5
2. Referencial Teórico ................................................................................................. 7
2.1 Redes de Sensores Sem Fio ................................................................................ 7
2.2 Sistemas Baseados em Regras .......................................................................... 12
2.3 Computação em Nuvem .................................................................................... 15
2.3.1 Tipos de computação em nuvem ............................................................ 17
2.3.2 Características da computação em nuvem .............................................. 18
2.3.4 Computação em Nuvem e Redes de Sensores Sem Fio ......................... 19
2.4 Publish/subscribe .............................................................................................. 20
2.4.1 Publish/subscribe baseado em Tópicos .................................................. 24
2.4.2 Publish/subscribe baseado em Conteúdo ............................................... 24
2.4.3 Publish/subscribe baseado em Tipo .................................................. 25
2.5 Conceitos Básicos de Filas ................................................................................ 25
2.5.1 Notação de Kendall ................................................................................ 30
2.6 Considerações do Capítulo................................................................................ 31
3. Trabalhos Relacionados ....................................................................................... 33
3.1 Infraestrutura Sensor-cloud ............................................................................... 33
3.1.1 Integrating Wireless Sensor Networks with Cloud Computing ............. 35
3.1.2 Secured WSN-integrated cloud computing for u-life care ..................... 37
3.1.3 A New model of accelerating service innovation with Sensor-Cloud
Infrastructure ................................................................................................... 38
3.1.4 Discussão ................................................................................................ 39
3.2 Abordagem de alto nível para definição de regras em aplicações de RSSF ..... 40
3.2.1 The Design and Implementation of a Declarative Sensor Network
System ............................................................................................................. 41
3.2.2 FACTS-A rule-based middleware architecture for wireless sensor
networks .......................................................................................................... 42
3.2.3 A model-Based Approach for Building Ubiquitos Application Based on
Wireless Sensor Network ................................................................................ 42
3.2.4 Discussão ................................................................................................ 43
3.3 Considerações do Capítulo................................................................................ 44
4. Arquitetura Proposta ............................................................................................ 47
4.1 Introdução ......................................................................................................... 47
4.2 Princípios e Requisitos ...................................................................................... 48
4.3 Arquitetura Conceitual ...................................................................................... 50
4.4 Arquitetura da implementação .......................................................................... 53
4.4.1 Serviço de gerenciamento da arquitetura ............................................... 56
4.5 Considerações do capítulo ................................................................................ 62
5. Prova de Conceito ................................................................................................. 64
5.1 Cenário .............................................................................................................. 64
5.2 Visão do especialista de domínio ...................................................................... 66
5.2 Visão do desenvolvedor .................................................................................... 70
5.4 Considerações do capítulo ................................................................................ 73
6. Avaliação ................................................................................................................ 74
6.1 Introdução ......................................................................................................... 74
6.2 Análise teórica .................................................................................................. 75
6.3 Considerações do capítulo ................................................................................ 83
7. Conclusões ............................................................................................................. 84
8. Referências ............................................................................................................. 88
1
Capítulo 1
1. Introdução
Este capítulo apresenta a motivação, os objetivos e a organização deste
trabalho. São introduzidas as áreas de pesquisa nas quais o trabalho se apóia
e descrito o problema central a ser investigado. As tecnologias usadas na
solução são brevemente apresentadas, as quais são detalhadas nos capítulos
que seguem.
1.1 Motivação
Redes de Sensores sem Fio (Wireless Sensor Networks) (AKYILDIZ et al.,
2002; YICK; MUKHERJEE; GHOSAL, 2008) têm se tornado ferramentas essenciais
no monitoramento de grandezas do mundo físico. Estruturas formadas por diminutos
nós com capacidade de processamento, armazenamento, comunicação e sensoriamento,
as Redes de Sensores sem Fio (RSSF) permitem aos seus usuários interagirem e
observarem, com grande nível de detalhe e precisão, os mais variados ambientes,
domínios e objetos de interesse. As suas características de baixo custo, pequena
dimensão, flexibilidade e facilidade de implantação dão a essas redes um potencial
enorme de aplicação em diversas áreas, permitindo que elas se apresentem como
componentes importantes de soluções de monitoramento e controle em vários cenários
de aplicação. Por exemplo, em um cenário de Cidades Inteligentes (SU; LI; FU, 2011),
as RSSF podem ser usadas na implantação de serviços de observação e controle de
aspectos do cotidiano das cidades, como vigilância de espaços públicos, prédios e outras
estruturas civis, monitoramento de rios, córregos e matas urbanas, monitoramento de
2
áreas de desastre e risco, apoio à mobilidade urbana, rastreamento e localização de
cargas e objetos, entre outras.
No entanto, para se atingir plenamente o seu potencial de uso, o
desenvolvimento de aplicações para redes de sensores sem fio precisa ser facilitado e
tornar-se acessível para usuários de diferentes domínios e áreas de conhecimento
(RODRIGUES et al., 2012). É fato que, atualmente, construir aplicações reais para
redes de sensores sem fio ainda é uma atividade desafiadora, mesmo para
programadores experientes, por exigir do desenvolvedor de aplicações conhecimentos
de aspectos de programação de baixo nível, de especificidades das plataformas de
sensoriamento e das abstrações fornecidas pelo sistema operacional, simultaneamente às
questões relacionadas às regras do domínio em análise e aos requisitos de alto nível da
aplicação, tudo isso em um ambiente caracterizado por fortes restrições de recursos de
hardware. Em resumo, um modelo de programação fácil de utilizar e eficiente continua
sendo um grande desafio na comunidade de redes de sensores sem fio (CHU et al.,
2007).
Em geral, as aplicações de RSSF são concebidas para atender um determinado
domínio, sendo que os nós são programados para suprir aplicações específicas dentro do
domínio, com regras e eventos bem definidos. Normalmente, os desenvolvedores
providenciam o mapeamento dos requisitos de alto nível das aplicações do domínio em
programas e configurações de baixo nível da plataforma base dos nós sensores. Este fato
favorece a construção de aplicações com alto grau de acoplamento entre a lógica de
negócio e a plataforma de hardware da rede de sensores. Essa situação, indesejada,
resulta em baixa flexibilidade do produto final, sua dependência de plataforma e
dificuldade de manutenção.
O cenário acima traz à tona três questões importantes: (i) o desenvolvedor de
aplicações para RSSF tem de lidar com muitos aspectos no processo de
desenvolvimento, em diferentes níveis de abstração; (ii) a participação e a interatividade
do analista do domínio é relativamente baixa no processo, particularmente em função da
alta curva de aprendizagem das linguagens e sistemas operacionais usados em RSSF; e
(iii) existe uma limitação do uso da RSSF ao cenário ao qual foi projetado, isto é, os
dados coletados pela RSSF ficam restritos às poucas aplicações alvo do domínio, ao
3
passo que eles poderiam ser consumidos, em tese, por quaisquer aplicações, de
diferentes domínios, interessadas nos dados coletados.
Em relação a (i) e (ii) uma das estratégias para abordar o problema é promover o
que na comunidade de engenharia de software é conhecido por “separação das
preocupações” (“separation of concerns”) (MITCHELL, 1990), considerando, no
presente caso, duas visões: uma primeira se refere ao entendimento dos detalhes de
programação e configurações de baixo nível, protocolos de comunicação e
sensoriamento do ambiente; a segunda diz respeito especificamente às regras e lógica da
aplicação e eventos do domínio. Essa separação de “concerns” contribui para
diferenciar claramente os papéis do usuário programador e do usuário analista do
domínio, o que poderia potencializar a participação e a melhoria da interatividade do
usuário do domínio na concepção final da aplicação. Nesta abordagem, programadores
experientes atuariam no tratamento dos aspectos de sensoriamento considerando as
especificidades da arquitetura de hardware do nó sensor e os protocolos de comunicação
inerentes às redes. A definição das regras e eventos do domínio de aplicação, por outro
lado, passaria a ser uma preocupação do usuário do domínio, que tem um conhecimento
muito mais especializado das regras de negócio. Evidentemente, é importante que as
regras possam ser facilmente descritas e compreendidas pelos analistas de domínio. Em
função disso, a linguagem usada para a descrição de regras deve possuir flexibilidade
para alteração e construção de novas regras e eventos, pois essas características do
domínio geralmente são dinâmicas.
Em relação à questão levantada em (iii), assumindo que os dados coletados por
uma mesma rede possam ser compartilhados por uma ampla gama de aplicações que
atendam a demandas de domínios potencialmente distintos, ampliar o universo das
aplicações alvo pode ser conseguido com o desacoplamento entre cliente/servidor a
partir da definição de alguma estratégia de comunicação assíncrona oferecida, por
exemplo, por mecanismos de publish-subscribe. Além disso, em um cenário de
demanda crescente por serviços baseados em redes de sensores, a implantação da visão
de computação em nuvem (cloud computing) pode preparar a arquitetura da solução
para problemas futuros de escalabilidade.
Percebe-se que ainda poucos são os trabalhos que exploram os aspectos acima
discutidos de maneira integrada, quais sejam: (i) a separação de “concerns” e o uso
linguagens declarativas para facilitar a descrição das regras da aplicação; (ii) o suporte à
4
comunicação assíncrona, baseada no modelo publish-subscribe; e (iii) o uso de
conceitos de computação em nuvem para tratar aspectos de escalabilidade em cenários
caracterizado pela existência um número potencialmente grande de redes de sensores e
aplicações de diferentes domínios.
Este trabalho apresenta uma infraestrutura de apoio ao desenvolvimento de
aplicações de redes de sensores sem fio levando em consideração os aspectos acima
mencionados. O trabalho está centrado na proposta de uma arquitetura conceitual que
visa simplificar a construção de aplicações que consomem dados de redes de sensores
sem fio e promover uma separação de responsabilidades entre os usuários
programadores e analistas de domínio, envolvidos no processo de desenvolvimento, ao
mesmo tempo que permite ampliar o número de aplicações e os potenciais domínios de
uso dos dados coletados das redes.
A implementação da arquitetura utiliza a plataforma Drools (BALI, 2009) como
sistema de definição de regras. A Amazon foi adotada como infraestrutura de
computação em nuvem e a Amazon Web Services (AWS) (CLOUD, 2011) foi utilizada
para interação programática com a infraestrutura criada.
1.2 Objetivos
O trabalho tem como objetivo geral definir uma infraestrutura de integração
“sensor-cloud” flexível no que se refere à possibilidade de alterações nas regras e
eventos do domínio e escalável em relação a capacidade de armazenamento de
processamento de dados de sensoriamento de inúmeras RSSF distintas, para apoio ao
desenvolvimento de aplicações de redes de sensores sem fio. A proposta tem como
base o conceito de “separation of concerns“, neste caso centrada na separação das
responsabilidades pela definição de aspectos de alto nível das aplicações dos requisitos
de baixo nível presentes nos motes (nós sensores).
Este objetivo geral pode ser refinado nos seguintes objetivos específicos:
Desenvolver uma arquitetura conceitual de integração entre redes de sensores e
uma plataforma de computação de nuvem computacional, como forma de prover
escalabilidade e compartilhamento de dados;
Implementar um protótipo da arquitetura proposta e demonstrar o seu potencial
de uso por meio de um cenário de aplicação;
5
Definir um ambiente baseado no paradigma de programação declarativa para
descrição das regras de negócio e dos eventos de interesse das RSSF, bem como
pelo gerenciamento das aplicações e usuários do sistema.
Avaliar aspectos de desempenho da arquitetura proposta.
1.3 Organização do Trabalho
Além desta Introdução, o trabalho está organizado em mais seis capítulos, a
saber:
Capítulo 2: apresenta um breve referencial teórico abordando conceitos básicos
dos sistemas baseados em regras e da tecnologia de computação em nuvem. O
capítulo trata, também, do modelo de interação publish-subscribe e conceitos
básicos de teoria das filas.
Capítulo 3: discute os trabalhos relacionados.
Capítulo 4: descreve o projeto da arquitetura conceitual e detalhes da
implementação da arquitetura proposta.
Capítulo 5: apresenta um cenário de uso do protótipo desenvolvido.
Capítulo 6: realiza uma breve avaliação de desempenho da arquitetura proposta
sob a ótica da teoria de filas.
Capítulo 7: conclui a dissertação, apresentando as considerações finais e as
perspectivas de continuidade do trabalho.
6
7
Capítulo 2
2. Referencial Teórico
Este trabalho explora diversas áreas de pesquisa atuais, como redes de
sensores sem fio, computação em nuvem e sistemas baseados em regras.
Para um melhor entendimento das contribuições do trabalho, este capítulo
realiza uma revisão dos conceitos básicos dessas áreas de pesquisa. O
capítulo está organizado da seguinte forma: a Seção 2.1 introduz as redes de
sensores sem fio, apresentando as suas principais características, benefícios
e restrições; a Seção 2.2 discute conceitos relacionados aos sistemas
baseados em regras e o seu paradigma declarativo de programação; a Seção
2.3 descreve a área de computação em nuvem e a sua integração com as
redes de sensores sem fio; a Seção 2.4 introduz o paradigma de interação
publish/subscribe, usado no presente trabalho; e, finalmente, a Seção 2.5
traz as considerações finais do capítulo.
2.1 Redes de Sensores Sem Fio
A evolução das tecnologias de microeletrônica e micromecânica (MEMS -
Microelectromecanical Systems) tem permitido a construção de dispositivos inteligentes
de pequenas dimensões, com capacidade de sensoriamento, processamento,
armazenamento e comunicação sem fio, com custos de manufatura cada vez mais
reduzidos (HO; TAI, 1998). Esses dispositivos eletrônicos diminutos podem ser
organizados em uma estrutura topológica qualquer, formando uma infraestrutura de
8
comunicação distribuída comumente referenciada de Rede de Sensores sem Fio (RSSF)
ou Wireless Sensor Networks (AKYILDIZ et al., 2002; LOUREIRO et al., 2003). Um
exemplo de nó sensor por ser visto na Figura 1. Geralmente, o termo nó sensor
inteligente é aplicado ao chip que contém um ou mais sensores com capacidade de
processamento de sinais e comunicação de dados.
Figura 1 - Nó sensor inteligente.
A função mais comum de um nó sensor é amostrar propriedades físicas de um
ambiente, comunicar as leituras e, eventualmente, exercer alguma atuação baseada em
uma ou mais entradas. Nesse sentido, as redes de sensores sem fio têm se tornado
ferramentas essenciais no monitoramento de grandezas do mundo físico, permitindo aos
seus usuários interagirem e observarem, com grande nível de detalhe e precisão, os mais
variados ambientes, domínios e objetos de interesse. Observa-se que um nó pode
possuir uma diversidade de sensores, tais como mecânicos, térmicos, fotoelétricos,
químicos, magnéticos, etc.
Os nós sensores podem ser implantados em locais de difícil acesso. Assim, a
comunicação sem fio é, convenientemente, adotada como forma de transmissão dos
dados coletados até uma estação base. A estação base geralmente é representada por
microcomputador que processa e armazena as informações oriundas das RSSF;
entretanto, a fim de possibilitar o intercâmbio de dados entre uma RSSF e uma rede
TCP/IP convencional, é necessário que haja um elemento que seja capaz de se
9
comunicar com os protocolos de ambas as redes. Tal elemento é conhecido como
gateway.
Uma das características mais fundamentais de uma rede de sensores é que os nós
possuem uma fonte de energia com capacidade limitada e a substituição dessas fontes
torna-se inviável na maioria dos casos. Uma bateria é a principal fonte de energia em
um nó sensor; entretanto, alguns nós podem possuir uma fonte de alimentação
secundária, podendo obter energia a partir do ambiente, por exemplo, painéis solares,
térmicos, etc. (Figura 2).
Figura 2 - Fonte de energia secundária.
A capacidade de processamento e transmissão de cada nó está limitada pela
quantidade de energia disponível, observando-se que os nós consomem diferentes
quantidades de energia dependendo se estão usando o rádio, lendo os sensores,
executando cálculos locais ou em estado adormecido. Por exemplo, a transmissão e
recepção de dados consomem três ou mais vezes energia do que qualquer outra
operação. Isso tem impacto direto na arquitetura e na operação dos protocolos usados
em redes de sensores sem fio.
Uma RSSF geralmente tem pouca ou nenhuma infraestrutura e é constituída por
um certo número de nós sensores (algumas dezenas a milhares) que trabalham em
conjunto para monitorar uma região para obter dados sobre o meio ambiente. Segundo
(YICK; MUKHERJEE; GHOSAL, 2008) existem dois tipos de RSSF: estruturadas e
não estruturadas. Uma RSSF não estruturada (Figura 3) é aquela que contém um
conjunto denso de nós sensores que podem ser implantados de forma aleatória em uma
determinada área. Uma vez implantado, a rede é autônoma para realizar as funções de
monitoramento. Em uma RSSF não estruturada, realizar operações de manutenção da
rede, tais como o gerenciamento da conectividade e detecção de falhas, é uma tarefa
10
complexa, devido a existência de um número expressivo de nós sensores. Em uma
RSSF estruturada, todos ou parte dos nós sensores são implantados em uma maneira
previamente planejada. A vantagem de uma rede estruturada é que devido à quantidade
reduzida de nós, aspectos de detecção de falhas são facilitados. Uma RSSF não
estruturada tem maior chance de fornecer uma cobertura incompleta do ambiente
monitorado, apesar de dispor de um número de nós muito superior a uma RSSF
estruturada.
Figura 3 - Estabelecimento de uma RSSF não estruturada. Fonte: (LOUREIRO et al., 2003)
As redes de sensores sem fio têm potencial de aplicação em diversos cenários.
Exemplos incluem o rastreamento de alvos militares e de vigilância (DURISIC et al.,
2012); (HUSSAIN; KHAN; SUP, 2009); (LEE et al., 2009), o monitoramento de
ambientes naturais (POLASTRE et al., 2004), o monitoramento da saúde de idosos
(FERGUS et al., 2009; LAWRENCE et al., 2009), a exploração de ambientes
industriais (EL KOUCHE et al., 2011), entre outros. Por exemplo, em um cenário de
Cidades Inteligentes (SU; LI; FU, 2011), as redes de sensores podem ser usadas na
implantação de serviços de observação e controle de aspectos do cotidiano das cidades,
como vigilância de espaços públicos, prédios e outras estruturas civis, monitoramento
da qualidade de matas e do nível de rios e córregos urbanos, monitoramento de áreas de
11
desastre e risco, apoio à mobilidade urbana, rastreamento e localização de cargas e
objetos, entre outras. A Figura 4 ilustra possibilidades de aplicação de redes de
sensores em contextos distintos de uma cidade.
.
Figura 4 - Áreas de aplicação de RSSF. Fonte: (FUJITSU, 2013)
Ao contrário das redes tradicionais, uma RSSF tem o seu próprio projeto e
apresenta fortes restrições de recursos. As restrições de recursos incluem, como visto,
uma quantidade limitada de energia, comunicação de curto alcance, baixa largura de
banda, e capacidades de processamento e armazenamento limitados em cada nó. As
restrições de projeto, por outro lado, são dependentes da aplicação e são baseadas no
ambiente monitorado (YICK; MUKHERJEE; GHOSAL, 2008). Por exemplo, o
ambiente desempenha um papel fundamental na determinação do tamanho da rede, sua
topologia e protocolos de roteamento. Em ambientes fechados, um quantitativo inferior
de nós é necessário para formar uma rede em um espaço limitado; entretanto, ambientes
externos podem necessitar de mais nós sensores para cobrir uma área maior. A
implantação de uma RSSF não estruturada é preferível à implantação estruturada
quando o ambiente é inacessível por seres humanos ou quando a rede é composta por
centenas de milhares de nós. Obstruções no ambiente também pode limitar a
comunicação entre os nós, o que, por sua vez, afeta a conectividade de rede (ou
topologia).
12
Pesquisas recentes (AHMED; GREGORY, 2011; ATIF ALAMRI, 2013;
EGGERT et al., 2013; LE et al., 2010; YURIYAMA; KUSHIDA; ITAKURA, 2011)
destacam o interesse no uso de redes de sensores sem fio em ambiente de nuvem
computacional, como forma de armazenar e compartilhar informações de sensoriamento
entre aplicações distintas, de domínios variados, de maneira escalável. Outro interesse
atual da área de RSSF se refere à construção de mecanismos, ambientes e estratégias
para facilitar a construção de aplicações baseadas em redes de sensores sem fio. Em
(MOTTOLA; PICCO, 2011) são descritas e analisadas diversas abordagens propostas
na literatura para esta finalidade. Uma abordagem que se destaca é o uso do paradigma
declarativo de programação, em que o desenvolvedor define o que deve ser feito pela
aplicação a ser executada nos nós de uma RSSF, em contraste com a abordagem
imperativa, onde o programador indica explicitamente como deve ser feito, por meio de
uma sequencia de passos definidos.
No contexto de abordagens declarativas para desenvolvimento de aplicações
para RSSF, as linguagens baseadas em regras surgem como abordagem que favorecem a
construção de aplicações de forma simplificada, abstraindo detalhes inerentes à
plataforma de hardware. A promessa das abordagens baseadas em regras é possibilitar
que um conjunto de regras seja definido utilizando uma linguagem declarativa de alto
nível e, por meio de mecanismos de transformação, ocorra a geração de um programa
específico para a plataforma do nó sensor. Para construir um programa equivalente em
uma abordagem imperativa, por exemplo, em nesC (GAY et al., 2003), é necessário um
maior esforço para especificar as regras e o comportamento dos nós sensores,
considerando plataformas de hardwares distintas.
2.2 Sistemas Baseados em Regras
Diferentemente dos sistemas que se apoiam na programação imperativa, em que
a resolução de um problema é feita com soluções algorítmicas, os sistemas baseados em
regras são sistemas computacionais que empregam o paradigma declarativo de
programação para a resolução de problemas (HAYES-ROTH, 1985). Neste paradigma,
o conhecimento relativo ao domínio do problema é representado através de regras
(instruções), descritas na forma condição → ação, as quais são usadas para derivar
13
conclusões a partir de premissas (HILL, 2003). A solução do problema consiste em
descrever o que deve ser feito, omitindo-se grande parte do como fazer, cabendo ao
sistema decidir qual a melhor escolha para uma solicitação específica. Controle e
monitoramento, diagnóstico, previsão, classificação, reconhecimento de padrões e
sensibilidade ao contexto, são exemplos de aplicações que podem se beneficiar de uma
abordagem declarativa.
Em um sistema baseado em regras, todo o conhecimento que se tem do mundo
pode ser explicitado através das regras. Nas regras, estruturas do tipo if-then, a primeira
parte da estrutura (LHS - left hand side) contém as premissas (condições, predicados) a
serem satisfeitos, e a segunda parte (RHS – right hand side) contém as ações a serem
realizadas, ou seja, as conclusões da regra. Por exemplo, na ocorrência de uma
condição específica descrita no LHS, o RHS pode conter chamadas para serviços do
sistema, tais como o envio de um e-mail ou um SMS. O domínio de uma regra é
definido como o conjunto de todas as informações no qual a regra pode atuar. Os fatos
representam as informações sobre o mundo.
Num sistema baseado em regras existe uma separação explícita das regras de
negócio, descritas numa linguagem declarativa, do restante da aplicação. É
responsabilidade de um outro programa, a máquina de inferência ou de regras (rule
engine), determinar quando e quais regras de negócio serão executadas. Em geral, a
arquitetura de um sistema baseado em regras é composta dos seguintes sub-sistemas:
uma máquina de inferência (inference engine ou rule engine), uma base de regras (rule
base) e uma memória de trabalho (working memory). A máquina de inferência, por sua
vez, é sub-dividida em três componentes: pattern matcher, agenda e execution engine.
14
Figura 5 - Arquitetura de sistemas baseados em regras. Fonte: (HILL, 2003)
A máquina de inferência, também chamada de interpretador de regras, controla
todo processo de aplicação das regras aos fatos contidos na working memory com
intuito de obter os resultados do sistema. Geralmente, funciona em ciclos discretos. A
cada ciclo de processamento, as regras são comparadas pelo pattern matcher com os
fatos existentes na memória de trabalho, gerando um conjunto de regras a serem
ativadas. Este conjunto é chamado de conjunto conflito (conflict set), que é ordenado
para formar uma agenda usando um processo de resolução de conflitos (conflict
resolution). A base de regras (rule base) contém as regras do sistema, normalmente
utilizando alguma estrutura de dados eficiente, por exemplo, rete network (FORGY,
1982).
Existem atualmente diversas implementações de máquina de regras. Duas
importantes implementações são as providas pelos ambientes JESS (HILL, 2003) e
Drools (BALI, 2009).
Alguns trabalhos advogam o uso de sistemas baseados em regras para a
descrição de regras e eventos em redes de sensores sem fio (CHU et al., 2007)
(TERFLOTH; WITTENBURG; SCHILLER, 2006). Uma das justificativas é que o
paradigma declarativo possibilita um maior nível de abstração que o imperativo,
tornando mais natural, simples e flexível para o desenvolvedor a construção de regras.
Além disso, toda alteração realizada na base de regras é aplicada imediatamente a
novos fatos. Entretanto, a máquina de regras pode demandar recursos elevados de
processamento e memória, o que pode comprometer o seu emprego em ambientes com
hardware limitado. Uma abordagem para este problema é hospedar o sistema de regras
15
em um ambiente de nuvem computacional. Esta abordagem é particularmente útil em
cenários com um número expressivo de regras e uma grande quantidade de dados
compartilhados por uma ampla gama de aplicações de RSSF, de diferentes domínios.
Essas teriam acesso aos dados oriundos das redes de sensores como serviços escaláveis
e com alta disponibilidade, sem restrições quanto ao tamanho da base de regras e ao
número de dados coletados nas diversas redes envolvidas.
2.3 Computação em Nuvem
A computação em nuvem (cloud computing) é um paradigma computacional que
oferece recursos computacionais de hardware e software (processamento,
armazenamento, plataformas e aplicações) como unidades de serviços (ARMBRUST et
al., 2010).
Os três tipos mais comuns de serviços de computação em nuvem são:
infraestrutura como serviço (IaaS – Infrastructure as a Service), plataforma como
serviço (PaaS – Platform as a Service) e software como serviço (SaaS – Software as a
Service) (ZHANG; CHENG; BOUTABA, 2010). Segundo esses autores, a arquitetura
de computação em nuvem pode ser dividida em 4 camadas: (i) hardware, (ii)
infraestrutura, (iii) plataforma e (iv) aplicação, o que é ilustrado na Figura 6.
16
Figura 6 - Computação em nuvem. Fonte: (ZHANG; CHENG; BOUTABA, 2010)
A camada de hardware é responsável por gerenciar os recursos físicos da
nuvem, incluindo os servidores físicos, roteadores, switches, sistema de força e
refrigeração. Na prática, a camada de hardware é tipicamente implementada nos data
centers. Um data center geralmente possui centenas de servidores que são organizados
em racks e interconectados através de switches, roteadores entre outros. Questões
típicas da camada de hardware inclui configuração de hardware, tolerância a falhas,
gerenciamento do tráfego, sistema de força, e gerenciamento dos recursos de
refrigeração.
A camada de infraestrutura, também conhecida como camada de virtualização,
é responsável por criar um conjunto de recursos de armazenamento e processamento,
dividindo os recursos físicos por meio de tecnologias de virtualização. A camada de
infraestrutura é um componente essencial para a computação em nuvem, uma vez que
muitas ferramentas fundamentas, tais como o dimensionamento dinâmico de recursos,
são disponibilizados apenas por meio de tecnologias de virtualização.
A camada de plataforma é construída sobre a camada de infraestrutura,
consistindo dos sistemas operacionais e frameworks de desenvolvimento. O objetivo
desta camada é minimizar o custo de implantação de aplicativos. Tipicamente,
17
provedores de computação em nuvem que atuam na camada plataforma fornecem API´s
de desenvolvimento que possibilitam o uso de recursos de armazenamento e banco de
dados, entre outros.
A camada de aplicação, o mais alto nível da hierarquia, consiste nas atuais
aplicações em nuvem. Diferentemente de aplicações tradicionais, as aplicações em
nuvem podem aproveitar os recursos automáticos de escalabilidade para alcançar um
melhor desempenho, disponibilidade e menor custo operacional.
2.3.1 Tipos de computação em nuvem
Existem muitas questões a serem consideradas quando há intenção de adotar uma
plataforma em nuvem, por exemplo, redução de custo de operação, aumento da
confiabilidade e segurança, entre outros. Em (ZHANG; CHENG; BOUTABA, 2010)
são discutidas as questões supracitadas em relação aos tipos de nuvens, abaixo segue a
descrição de cada tipo:
Nuvem pública: uma nuvem no qual os provedores de serviço oferecem seus
recursos como serviços para um público geral. As nuvens públicas oferecem
diversos benefícios, tais como: não há necessidade de um capital inicial para
investimento em uma infraestrutura, os riscos são de responsabilidade do
provedor do ambiente de nuvem computacional. Contudo, as nuvens públicas
não têm um controle refinado sobre os dados, no que se refere a aspectos de
segurança; o que dificulta sua eficácia em alguns contextos.
Nuvem privada: também conhecida como nuvem interna, são projetadas para
uso exclusivo de uma determinada organização, sendo que a nuvem privada
pode ser implantada e gerenciada pela própria organização. A nuvem privada
fornece um alto grau de controle sobre o desempenho, confiabilidade e
segurança.
Nuvem hibrida: trata-se da combinação entre os modelos de nuvens públicas e
privadas, cujo objetivo é minimizar as limitações de cada abordagem. Em uma
nuvem hibrida, parte do serviço de infraestrutura é provido por uma nuvem
privada, enquanto a outra parte é disponibilizada por uma nuvem pública.
18
Devido essa abordagem, a nuvem híbrida se torna mais flexível que as nuvens
públicas e privadas, pois é possível ter um controle mais rigoroso da segurança
sobre as informações contidas nas aplicações, se comparado com nuvem pública
e possuir a facilidade de redimensionar a capacidade dos serviços. O projeto de
uma nuvem híbrida requer um cuidado no que se refere a melhor divisão entre os
componentes que são providos pelas nuvens pública e privada.
Nuvem virtual privada: trata-se basicamente de uma plataforma privada que é
executada sobre uma nuvem pública, sendo que a principal diferença é que essa
abordagem possibilita uma forma de acesso segura à infraestrutura com intuito
de permitir configurações mais detalhadas visando segurança, como por
exemplo, regras de firewall.
2.3.2 Características da computação em nuvem
A computação em nuvem provê diversas características que diferem de um
serviço de computação tradicional, dentre as quais, destacamos a seguir, conforme
(ZHANG; CHENG; BOUTABA, 2010):
Multi-tenancy: em um ambiente de nuvem, os serviços de diversos fornecedores
estão localizados em um único data center. Os problemas de desempenho e
gerenciamento desses serviços são compartilhados entre os fornecedores de
serviço e o provedor da plataforma em nuvem. A arquitetura em camadas
(Figura 6) apresenta uma divisão natural das responsabilidades: o fornecedor de
serviços de uma determinada camada somente é responsável pelos objetivos
específicos associados a esta camada. Entretanto, essa abordagem apresenta
dificuldades em relação ao gerenciamento da interação entre os vários
fornecedores de serviço.
Compartilhamento de recursos: o provedor de infraestrutura oferece um
conjunto de recursos computacionais que pode ser disponibilizados de forma
dinâmica a diversos clientes. Essa característica possibilita uma maior
flexibilidade no gerenciamento do uso dos recursos disponíveis no data center.
Geralmente, adota-se uma infraestrutura de servidores altamente consolidada,
19
que contribui para minimizar os custos, tais como: consumo de energia e
refrigeração.
Distribuição geográfica e acesso ubíquo à infraestrutura: Nuvens são
geralmente acessíveis por meio da Internet e a utiliza como forma de entrega de
serviços. Por isso, qualquer dispositivo com acesso à Internet deve conseguir
acessar serviços em nuvem. Além disso, para alcançar um alto desempenho,
diversos ambientes em nuvem possuem data centers localizados em várias
regiões em todo mundo.
Orientado à serviços: a computação em nuvem adota um modelo de operação
orientado a serviço. Os serviços em um ambiente de nuvem computacional
(IaaS, PaaS e SaaS) são providos conforme um acordo de nível de serviço
negociado com os clientes.
Provisionamento dinâmico de recursos: uma das principais características da
computação em nuvem é que os recursos computacionais podem ser alocados e
disponibilizados de forma instantânea (on the fly).
Auto-organização: como os recursos podem ser alocados ou desalocados
conforme a demanda, os provedores tem a capacidade de gerenciar o consumo
de recursos conforme a necessidade do cliente. O gerenciamento automatizado
de recursos gera grande agilidade, o que possibilita os provedores de serviços
responder rapidamente às mudanças na demanda.
Preço baseado na utilização: provedores de computação em nuvem utilizam o
modelo de precificação - pague pelo que utilizar. O esquema de preço exato
pode variar de serviço para serviço. Por exemplo, um provedor IaaS pode cobrar
pela quantidade de horas que uma máquina virtual ficou em execução, já um
provedor SaaS pode cobrar pela quantidade de usuários que utilizam o software.
2.3.4 Computação em Nuvem e Redes de Sensores Sem Fio
Como visto, a computação em nuvem tem como características principais o
compartilhamento de dados e o fornecimento de serviços escaláveis. Em um cenário de
aumento da demanda por serviços baseados em redes de sensores e de ampliação do
universo e domínio das aplicações, esta característica pode ser extremamente
20
interessante para os desenvolvedores de aplicações de RSSF. Ao usar a nuvem como
parte da arquitetura de solução, os desenvolvedores podem se concentrar na essência do
problema a ser resolvido, diminuindo as preocupações com problemas de escalabilidade
no processamento e armazenamento de dados de sensoriamento, compartilhamento dos
dados dos sensores entre aplicações distintas, ao aumento da quantidade de redes e de
dados coletados, ao aumento expressivo do número de regras de negócio, etc.
É evidente que problemas de escalabilidade das RSSF não são resolvidos com a
integração entre as redes de sensores sem fio e uma infraestrutura de nuvem
computacional, principalmente relacionados a composição da infraestrutura interna de
uma RSSF, tais como, aspectos de roteamento e comunicação.
Neste ambiente de integração entre redes de sensores e computação em nuvem,
que vem sendo denominado de “Sensor Cloud”, usuários podem, usando recursos
computacionais armazenados na nuvem, acessar, processar, armazenar, compartilhar e
visualizar dados de sensores de várias aplicações, reduzindo o desperdício de uso hoje
observado nos dados de sensoriamento (ATIF ALAMRI, 2013). Em resumo, quando
RSSF são integradas aos ambientes de nuvem computacional, as deficiências das redes
em termos de capacidade de armazenamento de dados coletados dos sensores e
processamento conjunto desses dados é minimizado. Além disso, no caso de soluções
baseadas em regras, o aumento de consumo de memória, causado pelo crescimento da
base de regras, tem pouco impacto em uma infraestrutura em nuvem, devido sua
capacidade de escalabilidade.
2.4 Publish/subscribe
O paradigma publish/subscribe oferece aos assinantes (Subcribers) a capacidade
de manifestar seu interesse em um evento ou um padrão de eventos (Subcribe), a fim de
ser notificado posteriormente de qualquer evento gerado por um publicador (Publisher),
que corresponde ao seu registro de interesse. Em outras palavras, os publicadores
publicam (Publish) informações em um barramento de software (gestor de eventos) e os
consumidores assinam as informações que desejam receber do barramento. Esta
informação é tipicamente denominada evento, e o ato de entregá-lo é conhecido como
notificação (notify). Uma vez tendo manifestado interesse, um assinante é notificado
21
sempre que for gerado um evento por quaisquer publicadores que casem (Matching)
com seu interesse.
O modelo básico do sistema de interação publish/subscribe, conforme definido
em (EUGSTER et al., 2003) e representado pela Figura 7, conta com três macro
elementos: os publicadores, os assinantes e o serviço de eventos (event service). O
serviço de eventos representa um elemento mediador entre os publicadores (produtores
de eventos) e os assinantes (consumidores de eventos). Ele possui um conjunto de
funcionalidades internas: (i) notificação de eventos; (ii) armazenamento e gestão de
assinaturas; e (iii) entrega eficiente de eventos.
Figura 7 - Modelo básico publish/subcriber. Fonte: (EUGSTER et al., 2003)
Os assinantes registram seu interesse em eventos acionando a operação
Subcribe() presente no serviço de eventos, sem conhecer as verdadeiras fontes desses
eventos. Esta informação de assinatura permanece armazenada no serviço de eventos. Já
a operação Unsubscribe(), realiza o processo de cancelamento de uma assinatura
existente, sendo assim, o assinante deixa de receber eventos que casariam com a
assinatura cancelada.
Em um processo de geração de um evento, um publicador geralmente aciona a
operação publish(). O serviço de eventos propaga o evento para todos os assinantes que
22
possuem interesse neste evento em particular. Assim, todos os assinantes serão
notificados de todos os eventos em conformidade com os seus interesses.
O desacoplamento (decoupling) que o serviço de eventos provê entre o publicador e o
assinante pode ser decomposto em três dimensões, descritas a seguir:
Desacoplamento no espaço: neste paradigma, o publicador não necessita saber
da existência dos assinantes interessados nos eventos publicados, o mesmo se
aplica a situação contrária.
Figura 8 - Desacoplamento no espaço. Fonte: (EUGSTER et al., 2003)
Desacoplamento no tempo: esta característica indica que o publicador tem a
capacidade de publicar eventos indepedente da disponibilidade do assinante. A
situação inversa também se aplica, em que o assinante pode receber notificações
que foram publicadas por um publisher que não está mais conectado. No
paradigma Publish/Subscribe a ordem de publicação e subscrição de eventos não
importa. Entretanto, existem mecanismos para que o Publicador indique um
tempo limite para que o evento prescreva.
23
Figura 9 - Desacoplamento no tempo. Fonte: (EUGSTER et al., 2003)
Desacoplamento de sincronização: ilustrado pela Figura 10, indica que tanto a
publicação quanto o recebimento de notificação acontecem de forma assíncrona,
ou seja, tanto o publicador quanto o assinante não precisam interromper o seu
fluxo principal de execução para atender as solicitações. O desacoplamento de
sincronização é importante para permitir que dispositivos enviem mensagens ao
serviço de eventos e continuem suas atividades, não precisando bloquear seus
processos. A notificação ocorre após um casamento entre os eventos publicados
e as assinaturas existentes, ou seja, o serviço de eventos avalia a compatibilidade
entre eventos publicados e subscritos. Para avaliar compatibilidade entre eventos
é necessário que o evento de interesse seja um subconjunto do evento publicado.
Desta forma, o serviço de eventos notifica o assinante da ocorrência do
casamento e encaminha os eventos compatíveis. Assim, o assinante recebe
apenas um subconjunto dos eventos publicados. O processo de casamento, ou
seja, seleção das mensagens compatíveis é, geralmente, chamado de filtro.
24
Figura 10 - Desacoplamento de sincronização. Fonte: (EUGSTER et al., 2003)
Particularmente em relação à filtragem de mensagem, três tipos principais
podem ser identificados: Topic Based, Content Based, Type Based. Uma breve
descrição desses tipos é feita a seguir.
2.4.1 Publish/subscribe baseado em Tópicos
No publish/subscribe baseado em tópicos (Topic Based), os eventos são
classificados por assuntos (tópicos) de interesse. No processo de publicação do evento,
o publicador define o assunto no qual o evento publicado pertence. Na subscrição, o
assinante indica por quais assuntos ele está interessado. Desta forma, o serviço de
eventos faz o casamento entre os eventos publicados e as assinaturas, em seguida,
procede com a notificação aos assinantes correspondentes.
2.4.2 Publish/subscribe baseado em Conteúdo
No publish/subscribe baseado em conteúdo (Content Based), os eventos são
classificados de acordo com seu conteúdo. O serviço de eventos verifica o conteúdo da
mensagem enviada pelo publicador e avalia se esta é compatível com o conteúdo que o
assinante está interessado. No processo de filtragem baseada em conteúdo o serviço de
eventos pode ficar sobrecarregado com o processamento, uma vez que, para fazer o
casamento, é necessário processar a estrutura interna de cada evento
25
publicado/notificado. A sobrecarga de processamento tem um impacto direto no tempo
de respostas aos dispositivos finais.
2.4.3 Publish/subscribe baseado em Tipo
No publish/subscribe baseado em tipos (Type Based), os eventos são
classificados de acordo com o tipo de conteúdo. No processo de publicação, o publisher
define o tipo do seu conteúdo, por exemplo, uma cadeia de caracteres (string) ou um
inteiro. De forma análoga, o assinante subscreve um interesse por meio do tipo em que
está interessado. O servidor de serviços analisa o conteúdo do evento para verificar se
existe algum tipo conhecido e, caso haja, procede com a notificação ao assinante
interessado naquele tipo de mensagem.
2.5 Conceitos Básicos de Filas
No contexto das sensor clouds, os dados são coletadas do ambiente pelas RSSFs
e transmitidos até uma infraestrutura de computação em nuvem, a fim de serem
armazenados e processados pelas aplicações que se subscreveram a esses dados. A
natureza da operação deste tipo de sistema pode resultar na formação de filas: filas
ocorrem quando a procura pelo serviço é maior do que a capacidade de atender às
demandas das aplicações. Portanto, é importante compreender conceitos básicos de
Teoria das Filas com o objetivo de avaliar o comportamento teórico da interação entre
as diversas redes de sensores e a plataforma de nuvem computacional.
Os sistemas de filas podem ser definidos por um processo de chegada de clientes
a um sistema de atendimento para receber um ou mais serviços, executados por um
determinado quantitativo de servidores. O termo cliente e servidor são utilizados de
forma genérica, ou seja, em cada cenário de aplicação determinados papéis assumem as
funções de clientes e servidores.
A teoria das filas foi desenvolvida para prover modelos matemáticos que
retratem previamente o comportamento de sistemas que fornecem serviços que possuem
demandas que aumentam aleatoriamente. As filas possuem dois elementos básicos: o
cliente, elemento que chega e requer atendimento, e o servidor, processo ou pessoa que
realiza o atendimento ao cliente. A Figura 11 mostra uma representação de um processo
26
de filas típico, onde a taxa média de chegada de clientes está representada por meio da
variável λ, e o servidor representado por uma taxa média de atendimento µ.
Figura 11 - Modelo básico de fila.
O comportamento estatístico dos clientes que acessam o sistema de filas pode
ser descrito por uma distribuição de probabilidades empírica, que pode ser representada
por um modelo analítico conhecido de probabilidade. O modelo de Poisson
(KLEINROCK, 1975) é comumente usado para descrever a forma como os clientes
chegam ao sistema de filas e, para definir essa distribuição, é necessário ter apenas a
taxa média de chegadas.
Em geral, um modelo de filas pode ser definido pelas seguintes características
(COSTA, 2013):
Processo de chegada de clientes e seu comportamento
Geralmente, assume-se que os tempos entre chegadas são independentes e tem
uma distribuição em comum. Em mais detalhes, nos processos de filas comuns,
os processos de chegadas são estocásticos, ou seja, desenvolvem-se no tempo e
no espaço conforme leis de probabilidade. Assim, é necessário conhecer a
distribuição de probabilidade descrevendo os tempos entre as sucessivas
chegadas dos clientes. Também é necessário saber se os clientes podem chegar
simultaneamente (rajada).
O comportamento do cliente no sistema de filas pode seguir três padrões:
(i) paciente – indica que o cliente decide esperar o atendimento, independente do
tamanho da fila; (ii) decepcionado – cliente que após a chegada, ao analisar o
tamanho da fila, decide não entrar; e por último, (iii) impaciente – define os
clientes em duas situações: os que entram na fila, mas após um determinado
tempo, decidem sair; e em cenários onde há múltiplas filas e o pode cliente
mudar de fila.
27
Um fator final que pode ser considerado apesar do padrão de chegada é a
maneira no qual o padrão muda com o tempo. Um padrão de chegada que não
muda com o tempo (ou seja, que a distribuição de probabilidade descrevendo o
processo de chegada é independente do tempo) é chamado padrão de chegada
estacionário. Um padrão que não é independente do tempo é chamado não-
estacionário.
Padrões de Serviço
As características apresentadas no item anterior, processo de chegada de
clientes, se aplica para discussão dos padrões de serviço. A mais importante é
que uma distribuição de probabilidade é necessária para descrever a sequência
de tempos de atendimento aos clientes.
Os serviços também podem ser simples ou em lote. O processo de
serviço pode depender do número de clientes em espera. Caso o serviço tenha
essa dependência, ele é considerado dependente de estado.
Serviços, de forma análoga as chegadas, podem ser estacionários ou não
estacionários em relação ao tempo. Por exemplo, o aprendizado pode ser
considerado um fator de produtividade, de forma que, o serviço pode se tornar
mais eficiente quando experiência é obtida, ou seja, não importa o número de
clientes na fila (dependência do estado) e sim o período de tempo em atividade
(dependência do tempo).
Disciplina das Filas
A disciplina de filas refere-se a maneira como os clientes são escolhidos
para entrar em serviço após uma fila ser formada. Segundo (COSTA, 2013),
existem quatro tipos principais de disciplina: (i) FCFS (First-Come-First-
Served), ou seja, o primeiro a chegar é o primeiro a ser servido; (ii) LCFS (Last-
Come-First-Served), o último a chegar é o primeiro a ser servido; (iii) disciplinas
baseadas em esquemas de prioridade; e (iv) seleção de clientes de forma
aleatória.
Existem duas situações gerais em disciplinas de prioridade. No primeiro
caso, que é chamado de preemptivo, o cliente com a mais alta prioridade é
permitido entrar em serviço independentemente de outro cliente com menor
prioridade estar sendo servido, de forma que, o cliente com menor prioridade é
28
interrompido e tem seu trabalho reiniciado mais tarde. Quando reiniciado, ele
pode iniciar do ponto onde parou ou reiniciar todo o processo. Na segunda
situação de prioridade, chamado caso não preemptivo, os clientes com mais alta
prioridade vão para o início da fila, mas só entram em serviço quando o cliente
sendo atendido deixa o sistema, mesmo que ele tenha uma prioridade baixa.
Capacidade do Sistema
Em alguns processos de filas existe uma limitação física da quantidade de
espaço na fila, de modo que, se as filas alcançarem um certo comprimento,
nenhum novo cliente poderá entrar no sistema até que o espaço disponível seja
obtido com o atendimento de um cliente e a consequente diminuição do tamanho
da fila. Estas situações são denominadas como sistemas de filas finitos, ou seja,
existe um limite finito do tamanho máximo do sistema.
Número de canais de serviço
Quando o número de canais de serviço são definidos, tipicamente estão
sendo determinados o número de servidores de serviços paralelos que podem
servir os clientes simultaneamente.
A Figura 12 ilustra um sistema multicanal com fila única, ou seja,
existem diversos servidores que executam os mesmos serviços, onde todos os
clientes obtém acesso ao serviço por meio de uma única fila. Esta abordagem é
interessante, pois mesmo com a indisponibilidade de um servidor, o sistema
continua operante.
29
Figura 12- Sistema multicanal com fila única.
A Figura 13 mostra um sistema multicanal com fila individual. Nesta
abordagem, cada servidor possui sua própria fila, se comparado com a abordagem
anterior, esta possui desvantagem em termos de desempenho, já que a indisponibilidade
de um servidor, afeta diretamente todos os clientes presentes na sua respectiva fila.
Figura 13 - Sistema multicanal com fila individual.
30
2.5.1 Notação de Kendall
A notação de processos de filas proposta por (KENDALL, 1953) é descrita por
uma sequência de símbolos, separados por “/”. A representação geral de uma fila pode
ser vista como A/B/m/k/M, onde A indica a distribuição de interchegada dos clientes, B o
padrão de serviço de acordo com uma distribuição de probabilidade para o tempo de
serviço, m o número de canais de serviços paralelos (servidores), k a capacidade do
sistema e M a disciplina de filas. Alguns símbolos padrões para estas características são
mostradas na Tabela 1.
Características Símbolo Significado
Distribuição de Tempo entre chegadas
(A) e Distribuição de Tempo de Serviço
(B)
M Markoviano
D Determinístico
E Tipo k-Erlang(k = 1,2,...)
H Mistura de k exponenciais
PH Tipo fase
G Geral
Número Paralelo de Servidores (m) 1, 2, ..., ∞
Restrição na capacidade do sistema (k) 1, 2, ..., ∞
Disciplina da fila (M) FCFS First Come First Served
LCFS Last Come First Served
RSS Seleção aleatória por serviço
PR Prioridade
GD Disciplina Geral
Tabela 1 - Notação de Fila – A/B/m/k/M (MOREIRA, 2007)
31
Em muitas situações só os três primeiros símbolos são utilizados, ou seja, os
itens subsequentes são omitidos em contexto onde assume-se que o sistema tem
capacidade ilimitada e possui uma disciplina FCFS.
2.6 Considerações do Capítulo
Este capítulo apresentou conceitos básicos relacionados a áreas distintas (redes
de sensores sem fio, computação em nuvem, sistemas baseados em regras, modelo de
interação publish-subscribe) que apresentam grande potencial de integração no cenário
atual da computação ubíqua. Nesta dissertação, defende-se a ideia de que a
convergência dessas áreas é bastante oportuna aos propósitos da universalização das
aplicações de RSSF, podendo essas tecnologias serem convenientemente combinadas de
modo a se criar infraestruturas que potencializem a construção de aplicações que
consomem dados provenientes de redes de sensores sem fio.
Iniciativas que propõem essa integração, porém, ainda são incipientes. O
próximo capítulo realiza uma breve descrição de alguns trabalhos que tratam desta
tentativa de integração. A proposta de integração desenvolvida nesta dissertação é
apresentada na sequência, no Capítulo 4.
32
33
Capítulo 3
3. Trabalhos Relacionados
Este capítulo apresenta exemplos de trabalhos correlatos, que tratam de
questões de pesquisa relacionadas aos temas centrais desta dissertação. São
descritas abordagens que propõem algum tipo de infraestrutura em nuvem
para facilitar o desenvolvimento de aplicações de redes de sensores sem fio
e apresentadas algumas propostas de sistemas baseados em regras para
apoio à criação de serviços e aplicações de redes de sensores sem fio. O
capítulo está estruturado como segue. A Seção 3.1 apresenta exemplos de
infraestruturas de integração entre computação em nuvem e as redes de
sensores, a Seção 3.2 descreve algumas infraestruturas voltadas para
ambientes de redes de sensores que se apoiam em sistemas de regras e a
Seção 3.3 traz as considerações finais do capítulo.
3.1 Infraestrutura Sensor-cloud
Nos últimos anos, temos presenciado um aumento no número de pesquisas e um
grande interesse na implantação de infraestruturas de apoio à integração de redes de
sensores e tecnologias de computação em nuvem – o que vem sendo denominado de
infraestruturas sensor-cloud. O interesse é justificado pela promessa dessas
infraestruturas de oferecerem aos desenvolvedores um ambiente aberto, flexível e
escalável para a criação de aplicações de controle e monitoramento.
34
Em (ALAMRI et al, 2013) é apresentada uma visão geral da área de sensor-
cloud. O trabalho destaca os benefícios e os desafios da integração entre essas duas sub-
áreas de pesquisa, tendo como foco a apresentação de arquiteturas e modelos de ciclos
de vida de serviços voltados para a criação de infraestrutura de serviços e aplicações
baseadas em sensor-clouds.
Em (EGGERT et al., 2013), são apresentados três grandes desafios no processo
de integração entre infraestruturas de computação em nuvem e redes de sensores sem
fio, a saber:
(i) Suporte de ferramentas para facilitar o desenvolvimento de
aplicações. É enfatizado a necessidade de aumentar o nível de
abstração do processo de desenvolvimento, em que são citados como
exemplo o desenvolvimento orientado a modelo (Model Driven
Developer), linguagens específicas de domínio (Domain Specific
Language) e arquitetura orientada a serviço (Service-oriented
Architecture);
(ii) Mecanismos de segurança e privacidade. As RSSF coletam
informações sensíveis, onde o interesse é realizar o compartilhamento
desses dados com serviços confiáveis, garantindo que somente
usuários com autorização tenham acesso às informações. Também é
enfatizado que a segurança não está restrita ao ambiente de nuvem,
inclui a própria RSSF e suas limitações quanto ao excesso de
overhead causado por mecanismos de segurança.
(iii) Dimensões sociais de infraestruturas Sensor-Cloud e o impacto na
vida privada. Neste contexto, o autor compreende que as informações
de sensoriamento podem ser disponibilizadas de quaisquer
dispositivos que possuam sensores e acesso à Internet. A questão
levantada é que existem poucos trabalhos que discutem as questões
sociais e os impactos desta abordagem.
Na literatura da área, existem vários trabalhos que descrevem arquiteturas para
integração entre RSSF e infraestruturas de computação em nuvem. Exemplos
representativos são os trabalhos descritos em (AHMED; GREGORY, 2011), (LE et al.,
35
2010) e (YURIYAMA; KUSHIDA; ITAKURA, 2011), os quais são brevemente
discutidos a seguir. Para efeitos de avaliação, formam o escopo da discussão os
seguintes requisitos:
Compartilhamento de informações coletadas pelas RSSF entre aplicações.
Como visto, a motivação para o uso de uma infraestrutura tecnológica sob o
paradigma de nuvem computacional integrada a uma rede de sensores é
possibilitar o uso da enorme massa de dados coletada por aplicações distintas,
mesmo de diferentes domínios;
Aspectos de segurança da informação. Quando informações oriundas de redes
de sensores estão disponíveis em um ambiente de nuvem computacional,
questões de segurança da informação são trazidas à tona e devem ser tratadas.
Oferta de Serviços. É interessante que a infraestrutura tenha capacidade de
prover serviços aos seus usuários (ex: Email, SMS, etc.), a fim de aumentar o
nível de abstração das ações a serem realizadas a partir dos dados coletados;
Suporte ao desenvolvimento de aplicações. Conforme destacado em (EGGERT
et al., 2013), este é um desafio atual da pesquisa em RSSF. É importante
oferecer ao usuário final uma forma facilitada de desenvolvimento de aplicações
(“universalização”).
3.1.1 Integrating Wireless Sensor Networks with Cloud Computing
Em (AHMED; GREGORY, 2011) é proposto um framework de integração entre
redes de sensores sem fio e computação em nuvem, onde organizações, pesquisadores e
administradores acessam os dados em um repositório de dados coletados da rede
utilizando métodos de autenticação e políticas de acesso em uma plataforma de
computação em nuvem. O protótipo descrito implementa o mecanismo de autenticação
entre o cliente/provedor e política de controle de acesso aos recursos da nuvem.
36
Figura 14 - Integrating Wireless Sensor Networks with Cloud Computing. Fonte: (AHMED; GREGORY, 2011)
Conforme pode ser visto na Figura 14, os usuários – administrador, pesquisador
e empresas realizam acesso a plataforma em nuvem por meio de uma unidade de
autenticação. Os dados coletados da RSSF são enviados pelo gateway até a unidade de
processamento de dados, que procede com a formatação dos dados e em seguida o
armazenamento no repositório de dados. Os usuários recebem os dados da RSSF por
meio de assinatura, adotando uma estrutura publish/subscribe. O foco deste trabalho
está relacionado ao mecanismo de autenticação/autorização de usuário para acesso às
informações contidas no repositório de dados.
Em relação aos aspectos de segurança, o trabalho introduz um mecanismo de
autenticação/autorização dos usuários no ambiente de nuvem para acesso às
37
informações contidas no repositório de dados; porém, a arquitetura não contempla a
segurança na transmissão dos dados da origem (a RSSF) até o destino (o ambiente de
nuvem computacional). Além disso, o trabalho não abrange questões relacionadas ao
desenvolvimento e provisão de serviços e nem provê suporte ao desenvolvimento de
aplicações para o usuário no ambiente de nuvem computacional.
3.1.2 Secured WSN-integrated cloud computing for u-life care
Em (LE et al., 2010) é descrita uma abordagem para integração sensor-cloud,
incluindo aspectos de segurança em redes de sensores sem fio. O propósito da
infraestrutura criada é o de monitorar a saúde dos pacientes e compartilhar os dados
coletados com médicos, enfermeiros e farmácias, entre outros interessados. A segurança
na rede de sensores é obtida por meio de um componente especializado, chamado
gestor de confiança, presente nos motes.
Figura 15 - Arquitetura conceitual. Fonte: (LE et al., 2010).
Como mostrado na Figura 15, para acessar dados na nuvem, os usuários
(médicos e enfermeiros) devem autenticar e possuir permissões de acesso. Os dados do
corpo e das atividades de um paciente são capturados por meio de sensores e câmeras, e
38
transmitidos para a nuvem. Tais informações são enviadas para o Activity Recongnition
Engine, que tem a capacidade de inferir o estado do paciente. As informações do
paciente podem ser acessadas globalmente e compartilhadas entre grupos de hospitais.
Observa-se que por se tratar de informações especialmente sensíveis, a
segurança dos dados é levada em consideração desde a obtenção até o consumo dos
mesmos. O compartilhamento também é possível, entretanto, não foi mencionada a
disponibilização de ferramentas para apoio de novas aplicações a partir dos dados
coletados. A segurança é uma questão amplamente abordada neste trabalho, onde é
possível distinguir dois focos de preocupações: a rede de sensores e a plataforma de
nuvem computacional. Em geral, o trabalho demonstra uma grande preocupação –
refletida nos elementos de sua arquitetura – de que as informações coletadas estejam
disponíveis apenas para usuários devidamente autorizados. A arquitetura fornece um
serviço de inferência a partir dos dados coletados; porém, não é mencionada uma
estrutura para desenvolvimento de novos serviços. E, finalmente, não existe um suporte
explícito ao desenvolvimento de aplicações pelo usuário final.
3.1.3 A New model of accelerating service innovation with Sensor-Cloud
Infrastructure
Em (YURIYAMA; KUSHIDA; ITAKURA, 2011) é descrita uma infraestrutura
de sensor-cloud que promove a virtualização de sensores físicos com vistas ao seu
compartilhamento entre usuários finais, não especialistas. Por meio do conceito de
sensores virtuais (virtual sensors) os usuários tem livre acesso para controlar os seus
sensores sem preocupações, por exemplo, com detalhes internos e/ou localização física.
Grupos de sensores virtuais podem ser criados e o aprovisionamento dinâmico de
sensores é garantido pela infraestrutura.
39
Figura 16 – Provisão de serviços. Fonte: (YURIYAMA; KUSHIDA; ITAKURA, 2011).
A Figura 16 apresenta a fase de provisão de serviços, onde o usuário escolhe um
ou mais serviços a serem utilizados a partir do catálogo de serviços e o ambiente cria
uma instância do serviço solicitado, de maneira automatizada, e retorna uma
confirmação ao usuário. O foco deste trabalho está em dois atores: o usuário que
desenvolve serviços e os disponibiliza por meio de um catálogo de serviços, e o usuário
que usa os serviços previamente disponíveis no catálogo. Essa abordagem visa criar um
modelo de pagamento pelo serviço de provisão da infraestrutura e aumentar o nível de
abstração no que se refere à infraestrutura tecnológica. Desta maneira, o
compartilhamento de dados é realizado por meio de instâncias virtuais dos sensores.
O trabalho de (YURIYAMA; KUSHIDA; ITAKURA, 2011) permite o
compartilhamento de informações coletadas das RSSF por meio de instâncias virtuais
do sensores, bem como o desenvolvimento de serviços que são disponibilizados em um
catálogo para uso. No que se refere à segurança, o ambiente somente menciona
mecanismos de autenticação no ambiente de nuvem computacional, ou seja, a
arquitetura não contempla aspectos de segurança no processo de coleta e na transmissão
de dados das redes de sensores até o ambiente em nuvem. Além disso, não há suporte
explícito de desenvolvimento de aplicações na plataforma em nuvem.
3.1.4 Discussão
A Tabela 1 apresenta uma comparação dos trabalhos analisados. Na tabela, o
símbolo “+” significa que o trabalho atende completamente ao requisito avaliado, o “–“
indica que o trabalho atende apenas parcialmente, enquanto que o símbolo “•”
representa o não atendimento ao requisito. Os requisitos estão assim identificados:
compartilhamento de informações coletadas pelas RSSF entre aplicações (R1); aspectos
40
de segurança da informação (R2); serviços (R3); e suporte ao desenvolvimento de
aplicações (R4).
Escopo
Trabalhos I II III IV
(AHMED; GREGORY, 2011) + - • •
(LE et al., 2010) + + - •
(YURIYAMA; KUSHIDA; ITAKURA, 2011) + - + -
Tabela 2 - Comparação dos trabalhos de infraestrutura Sensor-Cloud.
Conforme mostrado na Tabela 2, a maioria dos trabalhos analisados não atende
ao requisito R4. ratificando as conclusões de (EGGERT et al., 2013) de que existe uma
carência de suporte qualificado para o desenvolvimento de aplicações em ambiente de
nuvem computacional usando dados provenientes das redes de sensores sem fio, sendo
esse um dos grandes desafios a ser enfrentado pela comunidade de pesquisa em sensor-
cloud nos próximos anos.
3.2 Abordagem de alto nível para definição de regras em aplicações de
RSSF
Os últimos anos também viram crescer o número de trabalhos que exploram
abordagens de alto nível para a definição de aplicações para RSSF, onde se destacam o
uso de linguagens declarativas e abordagens baseadas em regras em redes de sensores
sem fio. O interesse se justifica em função da constatação de que o alto acoplamento
existente entre a lógica da aplicação e a plataforma de sensores das abordagens
tradicionais que empregam o paradigma imperativo, invariavelmente resulta em códigos
dependentes de plataforma, com baixo grau de reuso, difícil de manter e com um nível
de abstração que dificulta e afasta a participação do especialista de domínio. Novas
linguagens declarativas específicas de domínio, sistemas de middleware baseados em
regras e metodologias de desenvolvimento apoiados em modelos (MDD - Model
Driven Development) surgiram para tratar esses problemas.
41
Na literatura estudada, vários são os trabalhos que investigam esses aspectos, sendo
alguns deles: (CHU et al., 2007), (TERFLOTH; WITTENBURG; SCHILLER, 2006) e
(RODRIGUES et al., 2012), os quais são apresentados a seguir. Para efeitos de
comparação, formam o escopo da discussão os seguintes requisitos:
Atualização das regras e eventos da aplicação. As regras e eventos podem ser
dinâmicas, dependendo do domínio de aplicação, portanto, é relevante analisar
as possibilidades de atualização e suas limitações.
Limitação quanto ao quantitativo de regras e eventos da aplicação. Em alguns
domínios de aplicação as redes de sensores sem fio, o quantitativo de regras e
eventos pode ser extenso e é relevante que a abordagem proposta suporte tal
demanda.
Separação das preocupações. O uso de uma abordagem baseada em regras tem
como uma das suas principais motivações a possibilidade de elevação do nível
de abstração no processo de construção de aplicações para RSSF o que, como já
frisado, favorece a aproximação do especialista do domínio na definição das
regras e eventos do domínio da aplicação.
3.2.1 The Design and Implementation of a Declarative Sensor Network System
Especificamente em relação ao uso de linguagens declarativas em RSSF, (CHU
et al., 2007) propõe uma linguagem denominada Snlog e um compilador que realiza a
transformação das regras definidas nessa linguagem em uma linguagem específica para
nós sensores. Como estudo de caso, o artigo apresenta a transformação para a
linguagem nesC (GAY et al., 2003), nativa do sistema operacional TinyOS (LEVIS et
al., 2005). É produzido um código binário da aplicação, o qual é distribuído nos nós
sensores que compõe a rede. Como resultado, é gerada uma aplicação nativa para o
hardware com um conjunto inicial de regras. Caso seja necessário realizar modificações
nas regras, é preciso gerar um novo binário e realizar o processo de gravação no mote.
42
3.2.2 FACTS-A rule-based middleware architecture for wireless sensor
networks
Como exemplo de iniciativa de construção de sistemas de middleware para
RSSF, (TERFLOTH; WITTENBURG; SCHILLER, 2006) apresentam a arquitetura de
um middleware baseado em regras para redes de sensores sem fio, composto de um
conjunto de ferramentas para ajudar no processo de desenvolvimento. Foi criada uma
linguagem de definição de conjunto de regras, chamada RDL, que é compilada pelo
ambiente de execução FACTS – executado no computador – cujo produto é um
bytecode que é interpretado pelo nó sensor, permitindo, assim, a interoperabilidade da
aplicação. O bytecode pode ser otimizado de acordo com a plataforma na qual a
aplicação será implantada, e isso implica em otimização de memória e energia. Esta
arquitetura de middleware permite a alteração das regras por meio do processo de
compilação e substituição do bytecode no nó sensor.
3.2.3 A model-Based Approach for Building Ubiquitos Application Based on
Wireless Sensor Network
(RODRIGUES et al., 2012) apresenta um alinhamento de objetivos gerais com
a proposta aqui apresentada no sentido de que ambos os trabalhos usam a separação de
“concerns” como abordagem base para aumentar o nível de abstração e permitir uma
distribuição de responsabilidades mais equilibrada e uma maior participação do
especialista do domínio no processo de desenvolvimento da aplicação. O trabalho
desenvolve uma infraestrutura MDA – Model Driven Architecure para redes de sensores
sem fio, onde especialistas de domínio são responsáveis por gerarem um modelo
independente de plataforma (PIM – Platform Independent Model) que sofre
transformações semi-automáticas no sistema até chegar a um modelo dependente de
plataforma (PSM – Platform Specific Model) que representa a lógica da aplicação
mapeada na plataforma alvo.
43
3.2.4 Discussão
Observa-se que os trabalhos supracitados apresentam abordagens nas quais as
regras estão presentes dentro dos nós sensores. Entretanto, em cenários em que existam
muitas regras e a necessidade de alteração das mesmas com frequência, as abordagens
mencionadas podem não ser adequadas. Esse fato reforça a importância de abordagens
que favoreçam a definição das regras da aplicação fora do nó sensor, em direção à
nuvem computacional. Essa mudança promove: (i) flexibilidade, no sentido que
permitir alteração das regras sem a necessidade de alteração da aplicação contida no nó
sensor; (ii) interoperabilidade, permitindo que sejam consumidos dados de
sensoriamento de arquiteturas de motes distintos; (iii) escalabilidade, característica que
é provida pelo ambiente de nuvem computacional.
A Tabela 3 faz uma comparação dos trabalhos analisados, adotando a mesma
representação anterior: o símbolo “+” indica que o trabalho atende completamente ao
requisito, o símbolo “–“ indica que o trabalho atende apenas parcialmente, e símbolo “•”
indica que o trabalho não atende ao requisito. Os requisitos estão assim identificados:
Atualização das regras e eventos da aplicação (R1); Limitação quanto ao quantitativo de
regras e eventos da aplicação (R2); e (R3) Separação das preocupações.
Escopo
Trabalhos I II III
(CHU et al., 2007) + • •
(TERFLOTH; WITTENBURG; SCHILLER, 2006) + • •
(RODRIGUES et al., 2012) + • +
Tabela 3 - Comparação dos trabalhos que propõe abordagens baseadas em regras para aplicações das RSSF.
Conforme pode ser visto na Tabela 3, todos os trabalhos analisados possuem
uma limitação em relação ao quantitativo de regras e eventos da aplicação, o que é
ocasionado pelas limitações de hardware dos nós sensores. Com a sua abordagem
MDA, apenas (RODRIGUES et al., 2012) trata explicitamente o requisito de separação
das preocupações. Os demais trabalhos (CHU et al., 2007) e (TERFLOTH;
44
WITTENBURG; SCHILLER, 2006), elevam o nível de abstração no processo de
definição das regras e eventos utilizando linguagens declarativas baseadas em regras;
porém, ainda há uma sobreposição de preocupações, pois além das regras e eventos, o
desenvolvedor define aspectos inerentes ao gerenciamento de recursos de hardware do
nó sensor.
Todos os trabalhos, de alguma maneira, viabilizam a atualização de novas regras
nos nós sensores. Em (CHU et al., 2007), as novas regras são implementadas por meio
da distribuição do binário pela RSSF. Já em (TERFLOTH; WITTENBURG;
SCHILLER, 2006), as regras são distribuídas através do bytecode gerado a partir das
regras, sendo esse bytecode copiado para o middleware presente no nó sensor que
realiza o processo de interpretação do mesmo. Finalmente, em (RODRIGUES et al.,
2012), as novas modificações nas regras são atualizadas por meio da instalação do
binário no nó sensor, gerado por transformações sucessivas a partir de um modelo.
De maneira geral, observa-se nas abordagens supracitadas que o processo de
atualização das regras e eventos da aplicação pode não ser uma tarefa trivial, visto que
é necessário atualizar todos os nós da rede. Observa-se, ainda, que a limitação do
quantitativo de regras e eventos está vinculada à capacidade do nó sensor, o que, em
alguns domínios, pode ser um fator crítico.
3.3 Considerações do Capítulo
Neste capítulo foram apresentados trabalhos da literatura que propõem algum
tipo de infraestrutura em nuvem visando facilitar o desenvolvimento de aplicações que
consomem dados de Redes de Sensores sem Fio. Foram também descritos alguns
sistemas de middleware baseados em regras para apoio à criação de serviços e
aplicações nesse ambiente de rede.
No que se refere à provisão de infraestruturas de integração entre as redes de
sensores e a nuvem computacional, percebe-se, pela análise da literatura da área, uma
carência de ferramentas de apoio à construção de aplicações em ambiente sensor-cloud.
Do mesmo modo, ainda são poucos os trabalhos que exploram abordagens de alto nível
para definição de regras em aplicações de RSSF.
45
A análise desta amostra de trabalhos permitiu reforçar a importância de
infraestruturas como a proposta nesta dissertação. Esta análise permitiu ainda avaliar
opções de tecnologias de computação em nuvem e sistemas baseados em regras,
algumas das quais foram empregadas na implementação da arquitetura conceitual e do
sistema de gerenciamento de aplicações de RSSF proposta neste trabalho, os quais são
apresentados em detalhes nos próximos capítulos.
46
47
Capítulo 4
4. Arquitetura Proposta
Este capítulo apresenta o projeto e a implementação da infraestrutura de
apoio à construção de aplicações de RSSF proposta neste trabalho. O
capítulo se inicia com um breve resumo dos problemas que motivaram a
proposição de infraestrutura (Seção 4.1) seguida de uma descrição dos
requisitos que nortearam a definição da arquitetura conceitual (Seção 4.2).
A Seção 4.3 apresenta os componentes da arquitetura conceitual proposta.
A Seção 4.4 descreve a implementação da arquitetura, ressaltando as
escolhas tecnológicas adotadas para a realização do protótipo da arquitetura.
A Seção 4.5 conclui o capítulo.
4.1 Introdução
Como descrito na introdução deste trabalho, o desenvolvimento de aplicações
para redes de sensores sem fio pode ser uma tarefa complexa, exigindo do
desenvolvedor conhecimentos de programação de baixo nível relacionados às
especificidades das plataformas de sensoriamento e sistemas operacionais, além de
conhecimentos do domínio do problema e dos requisitos das aplicações.
Uma das consequências deste cenário é que o programador recebe uma
sobrecarga de demandas de desenvolvimento, em função da baixa participação do
usuário especialista de domínio na definição direta das regras de negócio e na
48
especificação dos requisitos de alto nível da aplicação. Este fato pode ser explicado, em
parte, devido à ausência de mecanismos que facilitem ou promovam a participação do
especialista de domínio no processo de definição das regras da aplicação. Isso, de certa
forma, dificulta o processo de universalização de sistemas computacionais baseados em
redes de sensores sem fio.
Outra questão já mencionada, também relevante – especialmente quando se
considera cenários otimistas que preveem o uso maciço de aplicações de RSSF e outros
objetos inteligentes (smart objects) (VASSEUR; DUNKELS, 2010) nos próximos anos
– é que hoje, via de regra, o desenvolvimento é voltado para suportar cenários em que
os dados dos sensores são usados por uma aplicação específica, visando a um propósito
particular, sem o apoio de infraestruturas que favoreçam o compartilhamento dos dados
coletados entre aplicações (ATIF ALAMRI, 2013). Esta abordagem está na contramão
de cenários futuros de uso das redes de sensores, por exemplo, em Cidades Inteligentes,
que demandam infraestruturas que favoreçam o aprovisionamento de serviços e o
desenvolvimento de aplicações com alto grau de compartilhamento de dados, escaláveis
e em diferentes domínios.
Com base nessas premissas, as próximas seções descrevem a infraestrutura
criada neste trabalho para apoiar o desenvolvimento de aplicações de RSSF. O projeto
da arquitetura conceitual proposta tem por base um conjunto de requisitos funcionais e
não funcionais, os quais são descritos a seguir.
4.2 Princípios e Requisitos
A arquitetura conceitual proposta está inserida numa abordagem de
desenvolvimento centrada nos seguintes princípios:
Uso de uma abordagem de alto nível para representação das regras e
eventos em um ambiente de nuvem computacional. A abordagem de alto
nível deve possibilitar ao especialista do domínio autorizado a definição de
regras e suas respectivas ações. As ações devem ser providas pela arquitetura, de
forma transparente ao usuário.
49
Compartilhamento de informações coletadas por redes de sensores sem fio
entre aplicações. A arquitetura conceitual de integração entre as redes de
sensores sem fio e a plataforma de nuvem computacional deve prover
mecanismos que permitam o compartilhamento de informações de
sensoriamento de diversas redes de sensores sem fio, devidamente autorizadas
na arquitetura.
Além desses princípios, a arquitetura proposta deve atender aos seguintes
requisitos:
R1. Segurança da plataforma de nuvem computacional: O ambiente de
nuvem computacional deve suportar conexões seguras com a rede de
sensores, sendo desejável que exista algum mecanismo de autenticação.
R2. Gestão de regras e eventos do domínio: A construção de regras e
eventos deve ser realizada por meio de um paradigma de programação
flexível, que viabilize a sua descrição em alto nível de abstração. Deve ser
possível a definição de um repositório de regras e eventos do domínio. O
processamento das regras e eventos do domínio deve ser escalável e possuir
um mecanismo capaz de invocar serviços, por meio de interfaces
padronizadas. O ambiente deve, ainda, suportar uma forma de subscrição de
dados obtidos da RSSF, considerando aspectos relacionados a controle de
privacidade.
R3. Gestão de serviços: Deve ser possível ao especialista de domínio acionar
serviços como parte da definição das regras de negócio. Serviços são
funcionalidades disponíveis para o usuário do domínio com intuito de serem
utilizadas nas ações das regras, por exemplo, o envio de um SMS ou de um
email. Os serviços devem possui baixo acoplamento em relação ao ambiente
de definição de regras e eventos do domínio, ou seja, devem ser fornecidos
como uma caixa preta para esse ambiente. Para tanto, é necessário prover
uma interface de comunicação com os elementos externos, uma lista de
métodos e parâmetros. É desejável que haja um repositório onde os serviços
são cadastrados e disponibilizados ao especialista de domínio.
R4. Comunicação RSSF-Nuvem: Deve existir uma interface capaz de
estabelecer e manter conexões seguras com o ambiente de nuvem
50
computacional. Esta interface deve, ainda, suportar os protocolos da rede à
qual está vinculada e ser capaz de formatar os dados recebidos das redes em
um formato que permita o intercâmbio de informações com a plataforma de
nuvem computacional. É desejável que seja realizado o tratamento dos
aspectos referentes à precisão dos dados recebidos das redes de sensores
(gerenciamento de QoC – Quality of Context).
R5. Serviço de gerenciamento da arquitetura: a infraestrutura deve prover
um ambiente que possibilite a definição de diferentes papéis aos seus
usuários: o administrador e o especialista do domínio. Deve ser possível
descrever facilmente as regras, definir ações e os dados necessários para o
gerenciamento de usuário e serviços na infraestrutura proposta. É importante
que a interface de gerência seja concebida considerando aspectos de
usabilidade e independência de plataforma.
R6. Privacidade. A preservação da privacidade é uma das premissas dos
sistemas de compartilhamento de informações. Assim, ao mesmo tempo em
que devem existir facilidades para que os usuários e aplicações
compartilhem dados, é tarefa do sistema prover garantias para que nenhuma
pessoa não autorizada tenha acesso a dados e informações para os quais não
tenha permissão.
4.3 Arquitetura Conceitual
A Figura 17 mostra a arquitetura conceitual da infraestrutura proposta. São
identificados os seus componentes, os quais estão distribuídos em duas camadas, e os
atores do processo, representados nos papéis do especialista de domínio e do
desenvolvedor de aplicações para RSSF.
51
Figura 17 - Arquitetura Conceitual
A arquitetura conceitual é dividida em duas camadas: (i) uma Camada de Fonte
de Dados (Data Source Layer); e uma (ii) Camada de Nuvem (Cloud Layer). Esta
divisão visa à separação de responsabilidades entre o desenvolvedor que detém
conhecimentos do ambiente de rede de sensores e o analista de domínio, que detém
conhecimentos do domínio e das regras de negócio da aplicação. Esta abordagem
permite a cada um deles usar os seus conhecimentos específicos sem a necessidade de
lidar com exigências que não pertencem ao seu campo de especialização (RODRIGUES
et al., 2012).
A Camada de Fonte de Dados abstrai as funcionalidades providas pela rede de
sensores, encapsulando aspectos de programação e configuração de baixo nível, tais
como detalhes das plataformas de nós sensores, especificidades de protocolos, sistemas
operacionais e comunicação sem fio, além da interface com a Internet. Ela também
abstrai a origem e a localização dos dados capturados pela rede de sensores sem fio.
Cada instância da Camada de Fonte de Dados inclui a rede de sensores
propriamente dita, com seus nós e a estação base, e a conexão com o ambiente de
nuvem computacional, provida pelo gateway. Este elemento da arquitetura entende o
protocolo de comunicação da RSSF, sendo capaz de receber os dados capturados pelos
sensores e de repassá-los para uma plataforma em nuvem na Internet por meio de um
canal seguro.
52
A Camada de Nuvem possui um conjunto de funções que facilita a interação do
especialista do domínio no processo de desenvolvimento da aplicação de RSSF. A
camada abstrai os detalhes da obtenção dos dados de sensoriamento da rede, no sentido
de facilitar o desenvolvimento de aplicações; e incorpora componentes e
funcionalidades essenciais para a definição das regras de negócio e da gerência de
aplicações e controle de usuários do sistema. Essa camada é constituída dos seguintes
elementos: Gestor de Autenticação (Autentication Manager), Gestor de Usuários (User
Manager), Gestor de Regras e Eventos do domínio (Rules and Events Manager),
Controle de Privacidade (Privacy Control) e um Gestor de Serviços (Service Manager).
A plataforma de nuvem computacional somente recebe dados de sensoriamento
das redes autorizadas. Para tanto, deve haver um elemento de comunicação RSSF-
nuvem, que possua permissão de publicação de dados coletados da RSSF no ambiente
de nuvem computacional. O Gestor de Autenticação é o responsável pela validação das
credenciais de acesso e pelo estabelecimento de um canal de comunicação seguro entre
esse elemento de comunicação e a RSSF.
O controle de acesso e definição de permissões na arquitetura é provida pelo
Gestor de Usuários. Este controle consiste na criação de usuários, definição de grupos e
suas permissões. Estas permissões estão associadas aos elementos presentes na
arquitetura, tais como o Gestor de Regras e Eventos, incluindo o controle de subscrição,
e o Gestor de Serviços, definindo qual grupo de usuário tem direito de cadastrar, editar
ou excluir serviços.
O Gestor de Regras e Eventos permite subscrever dados coletados das RSSF,
criar arquivos de regras no repositório, definir regras e eventos com alto nível de
abstração e flexibilidade, além de acionar serviços disponíveis no repositório de
serviços.
O Gestor de Serviços provê suporte ao cadastro, edição e exclusão de serviços,
que podem ser internos ou externos à plataforma. Como consequência, é disponibilizado
um repositório de serviços, que consiste de uma lista de serviços para o especialista de
domínio utilizar nas ações das regras.
Um Serviço de Gerenciamento da arquitetura (Service Management
Architecture) é fornecido para dar acesso aos elementos definidos na Camada de Nuvem
da arquitetura. Este serviço fornece uma interface que privilegia a flexibilidade e a
53
portabilidade, sendo possível ser implantada em plataformas operacionais diversas,
como Windows, Linux e Macintosh.
Dos requisitos indicados na seção 4.1, apenas o requisito de privacidade (R6)
não está sendo contemplado nesta versão da arquitetura, devendo este ser objeto de
trabalho futuro.
4.4 Arquitetura da implementação
A arquitetura da implementação é mostrada na Figura 18, onde se pode destacar
a estrutura tecnológica utilizada para viabilizar e atender os requisitos da arquitetura
conceitual definida na seção anterior.
Figura 18 - Arquitetura da implementação
Segundo a abordagem de desenvolvimento usada neste trabalho, o especialista
de RSSF inicialmente constrói as aplicações que serão gravadas nos nós da rede de
sensores e no gateway, usando alguma linguagem de programação adequada à
plataforma de sensores e respectivo sistema operacional. O especialista do domínio, por
sua vez, abstrai os detalhes de implementação da rede e, por meio da interface do
usuário provida pelo Serviço de Gerenciamento da arquitetura, define as regras e os
54
eventos de interesse da aplicação, bem como as redes das quais ele deseja obter dados.
Para a definição das regras e eventos ele faz uso da linguagem declarativa
disponibilizada pela infraestrutura.
Para que as redes desejadas possam começar a disponibilizar os dados para a
nuvem é necessário que ocorra a execução da aplicação contida no gateway. Tal
aplicação é responsável pelas seguintes funcionalidades: estabelecer e manter uma
conexão segura com a infraestrutura de nuvem computacional; e receber dados oriundos
da RSSF por meio da estação base, adequando-os em um formato apropriado para
transmissão até a nuvem computacional. Na primeira execução dessa aplicação, é
estabelecida uma conexão criptografada com a nuvem. Nesse processo, são enviadas as
credenciais de acesso e o Gestor de Autenticação realiza a validação das mesmas,
estabelecendo, então, um canal seguro para a transmissão dos dados coletados das
redes.
Na implementação realizada, cada rede transmite as informações coletadas até a
estação base (base station) utilizando uma estrutura de dados independente de
plataforma de sensoriamento, que recebe as informações via interface sem fio e as
encaminha para o gateway via alguma interface apropriada (ex: serial). O gateway, por
sua vez, extrai as informações e as encapsula em formato JSON (CROCKFORD, 2006),
transmitindo-as para o respectivo tópico (topic) definido no ambiente de nuvem
computacional. O formato JSON foi adotado como formato de intercâmbio de dados por
exigir menos recursos computacionais para seu processamento, se comparado com o
formato XML (NURSEITOV et al., 2009), estando alinhado com as limitações de
hardwares inerentes às RSSF.
A interface RSSF-nuvem, foi implementada por meio dos elementos base station
e gateway. A aplicação presente no Gateway gerou dois componentes no processo de
implementação: o Unit Format Data e o Manager Connection. O Unit Format Data
recebe as informações da interface serial, extrai os dados de sensoriamento contidos na
estrutura de dados independente de plataforma, e adequa tais dados ao formato JSON. O
Manager Connection estabelece um canal de comunicação via https com a plataforma
de nuvem computacional, e envia os dados para a estrutura publish/subscribe. A
implementação do Gateway e do Gestor de Autenticação atende ao requisito R4 da
55
arquitetura conceitual de se estabelecer uma interface segura de comunicação RSSF-
nuvem computacional.
A Amazon foi adotada como plataforma de computação em nuvem e a Amazon
Web Services - AWS (CLOUD, 2011) foi utilizada para interação programática com a
sua infraestrutura. Desta forma, foi possível utilizar os serviços de conexão
criptografada com a nuvem, utilizando credenciais de autenticação. O compartilhamento
de dados foi viabilizado pelo Simple Notification Service em conjunto com o Simple
Queue Service (CLOUD, 2011), gerando uma arquitetura publish/subscribe. Neste caso,
o Simple Notification Service atua como publicador no ambiente de nuvem
computacional e o Simple Queue Service atua como assinante. Essas escolhas
tecnológicas atendem ao requisito R1 da arquitetura conceitual.
O Gestor de Subscrição, sub-componente do Gestor de Regras e Eventos do
domínio, viabiliza o recebimento de dados das RSSF. Ele foi implementado por meio de
uma estrutura publish/subscribe (EUGSTER et al., 2003). Os gateways das RSSF
assumem o papel de publicadores e, para isso, associado a cada rede, é instanciado um
tópico (topic) na nuvem.
O tópico é uma representação virtual dos dados de sensoriamento de uma
determinada RSSF, tecnologicamente representado pelo serviço Simple Notification
Service, sendo ele o elemento da implementação contido na nuvem que permite às
aplicações realizarem assinaturas de conteúdo das redes de sensores. As assinaturas
podem ser realizadas por meio de diversos protocolos, tais como e-mail, http, https ou
queues. O tópico recebe os dados serializados e dispara notificações (push) para os
assinantes do tópico. Essa notificação contém metadados e a mensagem que representa
os dados capturados pela RSSF.
Em alguns cenários, é possível que sejam capturados e transmitidos muitos
dados de sensoriamento; logo, é importante que haja um mecanismo para receber esses
dados e encaminhá-los para as aplicações que fizeram as devidas subscrições. Neste
trabalho, foi adotado o modelo de filas. As filas podem ser entendidas como assinantes
de tópicos dos quais se tem interesse em receber dados. Cada aplicação baseada em
regras possui uma fila. Lista de mensagens (notificações) surgem à medida que
acontecem as notificações dos tópicos que possuem os dados que chegam das fontes de
dados. Uma thread consome as mensagens à medida que elas chegam às filas. Esta
thread recebe as notificações em formato JSON e o transforma em um objeto JAVA.
56
O ambiente Drools (BALI, 2009) foi adotado como plataforma de regras na
implementação realizada. A escolha de Drools atende ao requisito (ii) da arquitetura
conceitual. Drools oferece uma linguagem específica de domínio, denominada Drools
Rule Language (DRL), de alto nível de abstração, que proporciona flexibilidade e
agilidade para alterações das regras de negócio e dos eventos de interesse da aplicação.
Drools possui uma máquina de regras e uma memória de trabalho. A máquina de regras
recebe objetos JAVA da thread, os quais são inseridos como fatos na memória de
trabalho. A aplicação escrita pelo analista de domínio é representada por um arquivo de
regras, as quais são processadas por uma máquina virtual em um ambiente de nuvem
computacional. Para invocar serviços no right-hand side da regra, foi desenvolvido um
cliente de serviços.
Os serviços foram implementados utilizando a arquitetura Web Services RESTful
(RICHARDSON; RUBY, 2008), o que permitiu obter baixo acoplamento e possibilitou
o desenvolvimento de novos serviços a serem utilizados pelos usuários do domínio no
right hand side das regras.
4.4.1 Serviço de gerenciamento da arquitetura
Para realizar o gerenciamento da arquitetura, foi desenvolvida uma aplicação
web, detalhada em (FRAGA, 2013), que permite gerenciar o repositório de regras e
eventos do domínio, realizar o controle dos usuários, criar e manter serviços, e definir a
relação de subscrição entre as aplicações baseadas em regras e as fontes de dados.
Assim, as diversas aplicações do domínio podem consumir dados de sensoriamento
oriundos das fontes de dados nos quais tenham interesse. A Figura 19 apresenta o
serviço de gerenciamento da arquitetura proposta no presente trabalho.
57
Figura 19 - Serviço de gerenciamento da arquitetura proposta.
A seguir são descritos os elementos do serviço supracitado, indicando as
tecnologias adotadas na implementação:
EC2 (Amazon Elastic Compute Cloud). O serviço EC2, da Amazon, foi
adotado como mecanismo de hospedagem do serviço de gerenciamento
da arquitetura. Trata-se de um serviço da web que fornece uma
capacidade de computação redimensionável na nuvem (CLOUD, 2011).
Para isso, foi instanciada uma máquina virtual, onde foram instalados os
aplicativos openjdk-7 e Tomcat7, necessários para executar aplicações
com JSP e Servlets. O Tomcat7 foi configurado para responder ao
protocolo HTTPS, com intuito de fornecer encriptação de dados e por
consequência, maior segurança. Essa instância é responsável por
processar toda a interação com o usuário, incluindo atividades como: (i)
gerência do banco de dados; (ii) controlar o acesso e permissão de
usuários; (iii) viabilizar o gerenciamento dos sistemas baseados em
regras; e (iv) gerenciar serviços. O EC2 também foi utilizado para
hospedar o servidor de serviços. Essa instância contém a implementação
58
dos serviços, ou seja, é responsável pelo atendimento às requisições de
execução de serviços empregadas nas ações das regras. Outros serviços
podem ser implementados em outras máquinas virtuais na infraestrutura
da Amazon ou provido por qualquer outra infraestrutura. A arquitetura
suporta o cadastro de serviços, onde novos serviços podem ser
implementados por um desenvolvedor e incorporados a arquitetura,
desde que tal serviço esteja acessível na Internet. Serviços públicos
também pode ser adicionados à arquitetura, por exemplo, um serviço de
persistência dos dados de sensoriamento em uma planilha na
infraestrutura do Google Drive.
Jersey RESTful Web Services. Como dito, a implementação do servidor
de serviços tem por objetivo prover funcionalidades a serem usadas pelos
especialistas do domínio nas ações das regras. Ele foi dividido em duas
partes: um cliente de serviços e um servidor de serviços. O cliente de
serviços é uma classe JAVA responsável por realizar solicitações HTTP
ao servidor de serviços. A URI é gerada pelo cliente combinando o
endereço do servidor, o nome do serviço que se deseja chamar e os
parâmetros exigidos por ele. O servidor recebe as solicitações do cliente
e realiza o processamento conforme a solicitação recebida. Para o
funcionamento desta estrutura, os serviços devem ser previamente
cadastrados por meio da interface web, que armazena suas informações
no banco de dados. Tais informações incluem: nome do serviço,
endereço do servidor, parâmetros e informações de perfil (quando
houver). A implementação realizada adotou o estilo arquitetural RESTful
Web Services, utilizando a tecnologia Jersey. Como exemplo, foi
implementado um serviço de envio de e-mail (SendEmail). Uma
vantagem importante da adoção do estilo arquitetural RESTFul é que os
provedores de serviços e seus clientes podem interoperar mesmo que
escritos em diferentes linguagens de programação. A maioria das
linguagens de programação possuem suporte ao estilo arquitetural
RESTful. Com isso, pode-se desenvolver sistemas e disponibilizar
determinadas funcionalidades a fim de serem reaproveitados por outras
59
aplicações, sem exigir a utilização da mesma plataforma em que o
serviço foi desenvolvido.
AWS IAM (Identity and Access Management). Provê o controle de
acesso dos diversos usuários do sistema aos recursos da Amazon. Foram
definidos dois tipos de perfis de usuário: administrador e desenvolvedor.
O perfil administrador tem permissão de gerenciar usuários, aplicações e
serviços. O perfil desenvolvedor possui permissão de edição de uma
aplicação na qual ele possui acesso previamente configurado. O
especialista do domínio (perfil desenvolvedor) tem a permissão de acesso
de leitura dos serviços SNS, SQS, IAM e RDS. Já para o serviço S3
(vide abaixo) lhe foi concedida permissão de leitura e escrita, pois este
serviço é responsável pelo armazenamento dos arquivos de regras das
aplicações. Já o perfil administrador tem acesso de leitura e escrita à
todos os serviços citados. Todo usuário, independentemente do perfil,
possui chaves de autenticação, que permitem o acesso ao serviço de
gerenciamento da arquitetura e aos serviços da Amazon. A interface web
provida pelo serviço de gerenciamento da arquitetura apresenta somente
os recursos que cada perfil de usuário tem acesso.
RDS (Relational Database Service). Trata-se de um serviço oferecido
pela Amazon de banco de dados relacional. No contexto desta
implementação, o banco de dados é utilizado para guardar informações
sobre aplicações baseadas em regras, usuário, gateways das RSSF e dos
serviços. A utilização deste serviço tem como benefícios a
escalabilidade, consistência e segurança. O RDS permite aumentar sua
capacidade a qualquer momento, fornecendo mecanismos automáticos de
backup e registro de log. Para ter acesso ao serviço, é necessário realizar
configurações de permissão de usuários e de quais endereços IPs terão
acesso ao banco.
S3 (Simple Storage Service). Em relação à arquitetura, o S3 tem a
função de repositório de arquivos onde estão armazenadas as regras das
aplicações. Nele foi criado um Bucket, nome dado a uma unidade de
armazenamento na Amazon, chamado GwAppBucket, que permite a
gravação de um número ilimitado de arquivos de 1 byte a 5 terabytes
60
cada. As vantagens de sua utilização é prover um repositório de arquivos
altamente durável e escalável, pois permite acesso simultâneo à leitura e
gravação por diferentes usuários ou threads de aplicações. Além disso,
contém um mecanismo de redundância que garante mais segurança e
disponibilidade.
A Figura 20 apresenta um exemplo da interface de edição de aplicações,
desenvolvida a partir das tecnologias citadas. Nesta tela, o especialista do domínio
consegue visualizar o nome da aplicação, os usuários que tem permissão de edição deste
conjunto de regras, os serviços disponíveis e a edição das regras do domínio. Ao salvar
a regra, os dados de sensoriamento são incluídos como fatos na máquina de regras
Drools e, então, quando houver um casamento de fatos com o left hand side da regra, a
ação definida pelo especialista do domínio é executada.
Figura 20 - Interface com o usuário.
No exemplo de regra mostrado na Figura 20, caso o fato (dado coletado da
RSSF) inserido na máquina de regras tenha a luminosidade acima de 500, então o
ClientService invoca um serviço de envio de e-mail, passando os parâmetros listados.
O serviço de gerenciamento da arquitetura interage e provê acesso aos seguintes
elementos da arquitetura conceitual:
Gestor de Usuários – por meio da interface, é possível a criação, edição
e exclusão de usuários. Além disso, é possível definir os perfis de
61
acesso. A Figura 21 e a Figura 22 representam as funcionalidades
implementadas do elemento da arquitetura Gestor de usuários, sendo que
a primeira ilustra o cadastro de usuários e a última apresenta a tela de
edição de usuários.
Figura 21 - Cadastro de usuários.
Figura 22 - Edição e exclusão de usuários.
Gestor de Regras e Eventos – foi construído no paradigma web com
intuito de facilitar a interação do usuário do domínio, tornando-o
independente de plataforma. O acesso ocorre por meio de autenticação e
o protocolo utilizado foi o https. A interface web, provida pelo serviço de
gerenciamento da arquitetura permite a criação, edição e exclusão de
arquivos de regras do repositório, além da definição dos usuários que
possuem acesso de desenvolvedor e de quais redes de sensores sem fio se
deseja consumir dado (Figura 23).
62
Figura 23 - Edição e exclusão de aplicações.
Gestor de Serviços – pela interface web provida pelo serviço de
gerenciamento da arquitetura, é possível a criação, edição e exclusão dos
serviços disponíveis. No protótipo implementado, tais serviços podem
ser construídos em um servidor que adote uma arquitetura RESTful Web
Services.
Em resumo, a interface web possibilitou a criação das regras, gestão das
assinaturas das informações de sensoriamento e a integração com serviços - que adota a
arquitetura RESTful de maneira simples e transparente. Desta forma, foi atendido o
requisito R5 da arquitetura conceitual proposta neste trabalho.
4.5 Considerações do capítulo
Este capítulo apresentou uma proposta de infraestrutura para integração entre
RSSF e nuvem computacional com suporte de alto nível para definição de regras, cuja
arquitetura conceito promove o conceito de separação de “concerns” e permite uma
participação mais ativa do analista de domínio no desenvolvimento das aplicações.
A implementação da arquitetura disponibiliza os dados coletados de diferentes
redes de sensores distintas a fim de possibilitar o compartilhamento dos mesmos na
nuvem por diferentes aplicações. A plataforma Drools de sistema de regras e a
plataforma de nuvem da Amazon foram adotadas como base para a implementação do
protótipo da infraestrutura proposta.
O Capítulo 5 apresenta um exemplo de aplicação da estrutura proposta, em um
cenário na área de estabilidade de fármacos. Questões relacionadas à avaliação de
desempenho teórico da arquitetura são discutidas no Capítulo 6.
63
64
Capítulo 5
5. Prova de Conceito
Este capítulo ilustra um exemplo de uso do sistema proposto. Inicialmente,
na Seção 5.1, o cenário a ser usado é apresentado, do domínio hospitalar e
da área de conservação de medicamentos. A Seção 5.2 descreve a visão de
alto nível do especialista do domínio no contexto da aplicação escolhida,
demonstrado pela utilização de regras Drools. A Seção 5.3 trata da visão do
usuário desenvolvedor (programador), ressaltando as especificidades e as
preocupações de baixo nível de abstração envolvidas na aplicação.
5.1 Cenário
O cenário de uso se refere ao domínio da conservação de medicamentos, onde
existem estudos denominados estabilidades que, na área farmacêutica, determinam os
critérios e o tempo de validade dos produtos farmacêuticos. Segundo (SILVA et al.,
2009):
“A estabilidade é definida como o tempo durante o qual a especialidade
farmacêutica ou mesmo a matéria prima considerada isoladamente,
mantém dentro dos limites especificados e durante todo o período de
estocagem e uso, as mesmas condições e características que possuía
quando da época de sua fabricação”.
A estabilidade dos produtos farmacêuticos depende de fatores ambientais, tais
como temperatura, umidade e luz, e de outros fatores relacionados ao próprio produto,
65
como propriedades físicas e químicas, de substâncias ativas e excipientes farmacêuticos,
forma farmacêutica e sua composição, processo de fabricação, tipo e propriedades dos
materiais de embalagens (RESOLUÇÃO, 2005).
Os hospitais são um cenário típico em que questões relacionadas à estabilidade
de produtos farmacêuticos são relevantes. Nestes locais, existem setores
especificamente responsáveis pelo armazenamento e conservação dos medicamentos.
Figura 24 – Cenário Hospitalar.
Geralmente, os profissionais que atuam na área farmacêutica dentro dos
hospitais, dentre as suas atividades, tem a incumbência de averiguar durante intervalos
de tempo pré-determinados as variáveis do ambiente onde e como estão acondicionados
os medicamentos. Existe uma atenção especial com os medicamentos mais sensíveis à
variação de temperatura, especialmente por conta do alto custo de alguns deles;
entretanto, em geral a medição e o controle das variáveis do ambiente são realizados de
forma manual. Esse procedimento, além de lento e custoso, é suscetível a erros.
Percebe-se, portanto, que o domínio hospitalar é um cenário promissor no que se refere
ao uso de tecnologias que suportem a coleta de informações do ambiente, facilitem a
66
realização do processamento das regras de negócio e, eventualmente, executem ações
específicas conforme o especialista do domínio ache necessário.
Usando esse cenário como base, as próximas seções discutem as diferenças de
visões entre o analista de domínio e o programador da RSSF na construção de uma
aplicação de RSSF hipotética usando a infraestrutura proposta nesta dissertação.
5.2 Visão do especialista de domínio
Em (SAÚDE, 2001) é apresentado um conjunto extenso de regras de
estabilidade, onde foi possível constatar a diversidade e dinamicidade do domínio. O
levantamento realizado apresenta um fato interessante (Tabela 4): a vacina contra
varicela, dependendo do fabricante, possui características de conservação distintas. Este
exemplo demonstra a necessidade da participação do especialista do domínio na
construção e manutenção das regras do sistema, pois podem ser desenvolvidos novos
medicamentos e estes serem inseridos em um ambiente monitorado. Geralmente, deseja-
se que o sistema emita um alerta caso as variáveis do ambiente não satisfaçam às
características de estabilidade.
Vacina contra Varicela
Laboratório Temperatura
Smith Kline + 2 a +8ºC
Merck Sharp & Dohme - 15ºC
Biken 5 ºC ou inferior
Tabela 4 - Informações de estabilidade da vacina contra Varicela.
É importante que o especialista do domínio consiga definir regras de forma
dinâmica, utilizando uma abordagem de alto nível, conforme as características de
conservação dos medicamentos. Adicionalmente, deve ser possível para ele definir
ações a serem executadas caso as informações do ambiente casem com alguma regra
pré-determinada de não conformidade do domínio.
67
A Figura 25 apresenta um exemplo de conjunto de regras que pode ser definido
pelo especialista do domínio utilizando a linguagem de alto nível do ambiente Drool.
Considera-se que no hospital existem dois locais são armazenados os medicamentos,
sendo que cada local possui uma RSSF e um gateway.
O exemplo da Figura 25 mostra seis regras que representam as restrições de
temperatura da vacina contra varicela, de três fabricantes distintos, conforme descrito na
Tabela 4. Neste exemplo, para cada fabricante de vacina, foi produzido um par de regras
com intuito de enviar um e-mail de alerta caso a temperatura monitorada esteja fora dos
padrões estabelecidos, a fim de manter a estabilidade dos fármacos. O objetivo da
utilização de duas regras para cada fabricante é evitar que sejam enviados múltiplos e-
mails em situações onde a temperatura coletada não atenda os critérios definidos. Para
cada par de regras, a primeira tem a função de disparar um e-mail de alerta quando a
informação coletada não atender as especificidades de estabilidade da vacina; a segunda
regra é utilizada é acionada sempre que a temperatura estiver em seus parâmetros
normais. Um flag é utilizado para evitar o flooding de e-mails quando houver alguma
não conformidade na temperatura.
A regra “Varicela – Smith Kline laboratory” define que caso a temperatura de
quaisquer sensores não esteja entre 2ºC e 8ºC, então o serviço SendEmail presente no
repositório de serviços é acionado, passando os seguintes parâmetros: perfil de e-mail
(conta de e-mail da origem, previamente configurada), e-mail de destino, assunto e
conteúdo. Este serviço é acionado por meio de uma requisição http, onde o
ClientService procede com a formação da url e seus parâmetros.
A regra seguinte indica que uma mensagem de e-mail é enviada (por meio do
serviço SendEmail), com os mesmos parâmetros citados anteriormente, caso a
temperatura seja coletada por meio do “gateway1” seja maior que -15ºC. E, finalmente,
a última regra define que se a informação enviada pelo “gateway2” até o ambiente de
nuvem computacional for superior a 5ºC, então o serviço SendEmail é acionado.
Vale mencionar que a Figura 25 ilustra um exemplo de utilização de regras em
um determinado domínio. O código abaixo utiliza variáveis (flags) que podem não ser
escaláveis conforme o aumento de fatos na memória de trabalho. Além disso, não está
sendo considerado aspectos temporais neste exemplo, apesar do Drools Fusion prover
este tipo de suporte.
68
Figura 25 - Regras do cenário.
O especialista do domínio tem, portanto, uma função relevante no processo de
definição de regras de negócio e ações da aplicação. A Figura 26 mostra a interface que
o especialista tem acesso no sistema desenvolvido. Mediante autenticação, é possível
definir um conjunto de regras e ações para um determinado conjunto de dados de
sensoriamento. O especialista do domínio define um nome, os usuários que terão
acesso, as redes de sensores sem fio que se deseja obter dados (representado pelo termo
- gateway) e, por fim, as regras e ações a serem realizadas. As regras são definidas em
69
Drools Rule Language e as ações podem ser compostas de serviços. Os dados são
inseridos como fatos na respectiva da memória de trabalho do Drools.
Figura 26 - Interface com o especialista do domínio.
Observa-se que o especialista do domínio não precisa compreender os detalhes
inerentes à RSSF, pois ele apenas indica qual a RSSF que deseja obter dados, sendo
transparente todo processo de captura e transmissão dos dados até a plataforma de
nuvem computacional. A utilização dos serviços também é transparente, pois basta
invocá-los e informar os parâmetros necessários. Sendo assim, o especialista do
domínio consegue se aproximar das definições das regras e eventos do domínio,
utilizando uma abordagem de alto nível, flexível e extensível. Este último justifica-se
pelo suporte que a arquitetura possui à inclusão de novos serviços ao repositório de
serviços.
Observa-se, ainda, que o cenário hospitalar apresentado pode ser estendido em
diversos contextos, tais como: adição de regras para novos medicamentos incluídos nos
locais monitorados pelas redes de sensores existentes; inclusão de novas redes em
outros setores ou mesmo em outros hospitais; monitoramento de toda cadeia logística,
desde o fabricante até o hospital, inclusive no transporte dos mesmos, entre outros.
Esse último contexto evidencia requisitos específicos de projeto de RSSF que
influenciam diretamente na construção das aplicações para as RSSF, tais como,
mobilidade dos nós sensores, gateways com acesso móvel à Internet, algoritmos de
roteamento específicos, adequação do hardware do nó sensor, etc. Além disso, o
70
contexto citado remete à possibilidade de se ter diversos especialistas de domínios
distintos com a demanda de construir regras a partir dos dados coletados pelas diversas
RSSFs, situação essa contemplada pela arquitetura, onde usuários podem ser
cadastrados e associados às aplicações baseadas em regras. Além disso, novos serviços
podem ser incorporados à arquitetura por meio do cadastro no repositório de serviços.
Como exemplos de serviços é possível citar: envio de SMS; integração com outros
serviços de nuvem, tais como Google Apps; persistência das informações em banco de
dados; entre outros. Todas essas possibilidades de extensão do cenário apresentado e
suas especificidades fortalecem a ideia defendida neste trabalho em relação à separação
das preocupações e a adequação dos elementos que compõe a sua arquitetura.
5.2 Visão do desenvolvedor
O desenvolvedor de aplicações para RSSF (usuário “programador da RSSF”) é
responsável por analisar os ambientes do hospital onde a rede de sensores será instalada,
realizando o levantamento de todos os requisitos necessários para a efetiva construção
da rede física sob o ponto de vista do hardware a ser empregado (tipo de mote, gateway,
placas de sensoriamento, etc.) e da programação desses elementos.
A Figura 27 e a Figura 28 apresentam um exemplo típico de aplicação
construída para RSSF que usa o framework de programação TinyOS e a linguagem de
programação nesC. A Figura 27 representa um componente dito de configuração, cuja
função é estabelecer as ligações entre os diversos componentes da aplicação por meio
das suas interfaces. A Figura 28 exibe um exemplo de componente de implementação,
cujo objetivo é definir as funções e eventos a serem tratados pela rede.
71
Figura 27 - Componente de configuração nesC.
72
Figura 28 - Componente de Implementação nesC.
73
Essas duas figuras compõe um exemplo de aplicação simples, cujo objetivo é
monitorar a luminosidade periodicamente e encaminhar as informações coletadas via
interface sem fio para todos os nós em sua zona de alcance. Essa aplicação ainda é
capaz de receber informações remotas para alteração do intervalo de tempo em que é
monitorado e transmitido os dados de luminosidade.
Como é possível perceber, mesmo nessa aplicação simples existe uma série de
conceitos necessários para a compreensão da aplicação, incluindo as características do
framework de programação, a linguagem, a plataforma de hardware, entre outros, o que
tende a uma longa curva de aprendizagem e conhecimento especializado, longe do
universo do analista de domínio.
No caso específico do cenário de uso, as redes de sensores usadas nos hospitais
podem eventualmente ser heterogêneas, apresentarem diferentes tipos de nós, placas de
sensoriamento diversas, sistemas operacionais diferentes e requisitos de comunicação
variáveis, tornando a tarefa de desenvolvimento e integração dessas redes muito mais
complexas do que o exemplo da Figura 28. Isso reforça a necessidade de se construir
ambientes com facilidades para comportar as diferentes visões dos profissionais
envolvidos no desenvolvimento das aplicações de RSSF.
5.4 Considerações do capítulo
Este capítulo apresentou um cenário de uso para a abordagem proposta neste
trabalho, focando na separação das preocupações (separation of concerns) entre os
usuários responsáveis pelo desenvolvimento de aplicações para RSSF.
O próximo capítulo apresenta uma avaliação teórica da infraestrutura no que se
refere à caracterização do modelo de filas do sistema, as quais atuam como assinantes
de informações oriundas das RSSF. São mostradas as equações que regem o
comportamento do sistema.
74
Capítulo 6
6. Avaliação
Visando investigar o comportamento teórico da infraestrutura proposta, este
capítulo avalia a implementação da arquitetura do ponto de vista do seu
modelo de filas. O objetivo é fazer um estudo inicial acerca de questões de
escalabilidade e desempenho da implementação realizada. Para
detalhamento da análise teórica, são usados os conceitos básicos de Teoria
das Filas introduzidos no Capítulo 2
6.1 Introdução
Conforme descrito no Capítulo 4, as informações oriundas das redes de sensores
são enviadas para o ambiente de nuvem computacional com o intuito de serem
consumidas por aplicações baseadas em regras. Como visto, foi adotada a arquitetura
publish/subscribe para viabilizar a comunicação entre as redes e as aplicações que
possuem as regras e os eventos do domínio. Cada aplicação baseada em regras recebe as
informações das RSSF que tem interesse por meio de uma fila, sendo que cada
aplicação possui a sua própria fila.
Considerando este contexto, é importante que seja feita uma caracterização
teórica em relação ao tráfego gerado pelas RSSF e a capacidade de consumo dessas
informações pelas aplicações. Para tanto, a próxima seção revisita conceitos básicos de
teoria das filas com intuito de especificar o tipo com vistas a investigar as limitações
teóricas da arquitetura proposta.
75
6.2 Análise teórica
A Figura 29 ilustra a implementação da arquitetura proposta no trabalho, onde
são destacadas algumas variáveis de interesse, consideradas relevantes para a avaliação
da arquitetura no que se refere às suas limitações teóricas de escalabilidade. Na figura, é
representado um sistema com n redes de sensores sem fio enviando os dados coletados
do ambiente para os seus respectivos tópicos, presentes no ambiente de nuvem
computacional, que publicam tais dados para os seus assinantes. É possível que existam
n máquinas virtuais com seus sistemas baseados em regras em execução e procedendo
com a coleta dos dados de suas respectivas filas.
Figura 29 - Implementação da arquitetura.
76
Geralmente, cada ambiente onde se deseja implantar uma rede de sensores sem
fio possui características muito particulares. Isso impacta em toda a análise e definição
do projeto da rede, ou seja, o ambiente influencia fortemente na definição do hardware
dos nós sensores, dos protocolos de comunicação, e de quais variáveis devem ser
monitoradas, entre outros. As características distintas entre os projetos de redes de
sensores sem fio e os ambientes monitorados podem implicar em uma variação do
volume de informações coletadas e transmitidas para a nuvem computacional. Assim,
para representar a taxa média de mensagens transmitidas de uma RSSF, adota-se a
variável λ (lambda).
Os sistemas baseados em regras, representados na Figura 29 pelas máquinas
virtuais onde são executados, possuem uma base de regras que define um determinado
domínio, com regras e ações bem definidas, sendo as informações de sensoriamento
coletadas da sua respectiva fila. A variável µ representa o tempo de serviço, ou seja, a
soma dos tempos médios de coleta informações da fila, processamento (transformação
da mensagem em JSON em objeto JAVA), e da inclusão dos objetos como fatos na
memória de trabalho do Drools. Vale ressaltar que o tempo de serviço no contexto deste
trabalho não considera o tempo de processamento das regras e suas respectivas ações,
pois não existe dependência da inserção de um novo objeto e o processamento das
regras, em outras palavras, para inserir um objeto na memória de trabalho do Drools não
é necessário esperar o processamento dos fatos anteriores.
A definição das variáveis λ, como taxa média de mensagens oriundas das RSSFs
por unidade de tempo, e µ, como taxa média de coleta de informações da fila, são muito
importantes para que seja realizada uma análise de limitações teóricas da arquitetura. O
cenário representado neste trabalho, onde existe um tópico que publica informações em
uma fila a uma taxa média λ, e um sistema baseado em regras, que possui a
funcionalidade de coletar mensagens de uma fila com um tempo médio µ, remete a um
modelo clássico estudado em teoria das filas, como pode ser visto na Figura 30.
Como visto, uma fila possui dois elementos básicos: o cliente, elemento que
chega e requer atendimento, e o canal de atendimento, processo ou pessoa que realiza o
atendimento do cliente. No contexto deste trabalho, o cliente é representado pela
mensagem enviada pela RSSF e o canal de atendimento pela máquina virtual que
executa o sistema baseado em regras que consome dados da fila. Observa-se, neste caso,
que o atendimento se refere apenas à entrega da mensagem como fato na memória de
77
trabalho, ou seja, o atendimento não inclui casamento do fato com as regras existentes e
a eventual execução das ações previstas. Essa premissa tem como fundamento a não
necessidade de esperar o processamento das regras para inserção de um novo fato na
memória de trabalho.
Figura 30 - Modelo básico de fila.
Segundo (ADAN; RESING, 2002), é possível definir seis componentes
principais de uma fila. Esses são listados abaixo, instanciado aos componentes da
infraestrutura proposta:
modelo de chegada dos clientes ao serviço: geralmente é especificado
pelo tempo entre chegadas dos clientes, podendo ser determinístico ou
ser uma variável aleatória seguindo uma distribuição de probabilidade.
Os clientes, no contexto deste trabalho, são as mensagens oriundas das
redes de sensores sem fio, que seguem as características de uma variável
aleatória discreta. Assume-se, como premissa, que o modelo de chegada
das mensagens provenientes das redes de sensores seguem uma
distribuição de Poisson (GARDINER; OTHERS, 1985), a uma taxa
média de chegada λ. Segundo (MOHAMMED; AGAMY, 2011), o
modelo de distribuição Poisson é um dos mais antigos e é amplamente
utilizado para representar modelos de tráfegos de redes, sendo aqui
também adotado;
modelo de serviço: normalmente especificado pelo tempo de serviço e de
forma análoga ao modelo de chegada dos clientes, o modelo de serviço
pode ser determinístico ou ser uma variável aleatória com uma
distribuição de probabilidade. Neste trabalho, assume-se como premissa
que o modelo de serviço é determinístico pois o atendimento ao cliente
78
consiste na inserção das mensagens como fatos na memória de trabalho
da máquina de regras e a inserção de um novo fato não depende do
processamento do fato anterior;
Número de servidores: se refere ao número de servidores que atendem a
uma fila. No contexto deste trabalho, existe 1 (um) servidor por fila;
Capacidade do sistema: se refere ao número de clientes que o sistema é
capaz de atender. Neste trabalho, a fila é um serviço escalável, provido
pelo ambiente de nuvem computacional da Amazon e, portanto, é
possível considerar o valor como infinito;
Tamanho da população: número potencial de clientes que podem chegar.
Neste trabalho, o número de mensagens das redes de sensores que podem
ser enviadas para as filas é considerado infinito;
Disciplina da fila: é o modo como os clientes (mensagens) são atendidas.
Neste trabalho é adotada a disciplina FCFS (First Come, First Served).
Usando a notação de Kendal (KENDALL; ALAN, 1961), foi definido o modelo de fila
empregado na arquitetura implementada como sendo do tipo M/D/1. A Figura 31 exibe
uma representação em uma notação clássica de filas à luz da implementação realizada,
representada na Figura 29.
79
Figura 31 - Modelo de filas da arquitetura proposta.
A rede WSN1 envia dados coletados para o seu respectivo tópico na nuvem a
uma taxa média λ1. A fila Q1, que é assinante do tópico que representa a WSN1, recebe
informações do mesmo a uma taxa média λ1. A máquina virtual, que executa o sistema
baseado em regras consome as mensagens da fila a uma taxa µ1.
A fila Q2 assina informações das redes WSN1 e WSN2; portanto, a taxa média
de chegada de mensagens, considerando que se trata de uma variável aleatória, tendo
como premissa que a mesma se comporta como uma distribuição Poisson, é a soma das
taxas médias λ1 e λ2. O consumo das mensagens da fila, assumindo o comportamento
discreto, como justificado anteriormente, é feito a uma taxa µ2.
Observa-se que na arquitetura proposta, pode ocorrer a chegada de informações
de diferentes redes (clientes) para uma mesma aplicação baseada em regras (servidor).
Como visto, assume-se como premissa que cada rede tem um comportamento de um
processo de Poisson independente; sendo assim, a propriedade de merging desta
distribuição indica a soma de duas variáveis de Poisson independentes, que é ainda uma
variável de Poisson com parâmetro igual à soma dos respectivos parâmetros.
80
(1)
É importante analisar as situações teóricas de comportamento da arquitetura no
que se refere à saturação, ou seja, quando a quantidade de mensagens oriundas das
RSSFs for superior a capacidade da aplicação consumir tais informações da fila,
caracterizando uma situação onde a fila pode crescer indefinidamente. Isso pode ser
obtido por meio da razão entre a taxa de chegada e a capacidade de serviço, conforme
pode ser visto na equação abaixo:
(2)
Na equação (2) – carga de trabalho, o índice x representa, no contexto deste
trabalho, o servidor que executa a sua respectiva aplicação baseada em regras. Cada
aplicação possui sua própria fila. O índice n representa os tópicos. O termo ρx representa
as características de utilização da arquitetura, sendo que enquanto ρx for menor que 1 (ρx
< 1) o sistema possui a capacidade superior de consumir mensagens da fila em relação
a taxa de chegada de mensagens. Se o ρx for igual a 1 (ρx = 1) a capacidade de consumo
de mensagens da fila e a taxa e chegada são equivalentes. Caso o ρx seja maior que 1 (ρx
> 1) a taxa de chegada de mensagens é superior a capacidade de consumo. Neste último
caso, se a fila possuir capacidade limitada, o sistema tende a descartar novas
mensagens; entretanto, na implementação realizada, a fila possui capacidade infinita;
portanto, o comportamento do sistema neste contexto seria do aumento do atraso médio
total (delay) para consumo das mensagens contidas na fila.
A arquitetura proposta envolve o processamento de dados obtidos das redes de
sensores; logo, em alguns cenários de aplicação, o delay pode ser um fator relevante.
Para guiar a análise do atraso médio total, é possível utilizar as propriedades de uma fila
M/D/1 em regime estacionário, dado pela seguinte equação:
(3)
81
O atraso médio total ( ) se refere à soma do tempo de espera e o tempo de
serviço. Portanto, dois fatores influenciam no atraso médio, a taxa de serviço ( ) e a
taxa de utilização (ρx).
A versão atual da arquitetura define uma associação 1:1 entre uma fila e a sua
respectiva aplicação baseada em regras. Considerando os fatores que influenciam no
aumento do atraso médio total, deve-se medir a taxa média de mensagens de cada RSSF
na qual a aplicação possui interesse e avaliar a capacidade de serviço do servidor. Caso
seja necessário diminuir o delay, uma alternativa é ampliar a capacidade de
processamento do servidor a fim de aumentar o valor de e, por consequência,
diminuir o valor de ρx.
Baseado nas equações de comportamento levantadas para a arquitetura, a Figura
32 apresenta um gráfico da relação entre o atraso médio total e a taxa de serviço, onde
se pode perceber que quando a taxa de serviço tende a zero, o atraso total médio tende
ao infinito e que quando ela é aumentada, o atraso total médio diminui. Ou seja, caso a
capacidade dos servidores seja aumentada, diminuindo a taxa de serviço, existe uma
tendência de diminuir o atraso total médio de consumo das informações presentes na
fila de uma determinada aplicação baseada em regras.
82
Figura 32 - Gráfico - Atraso Médio x Taxa de serviço.
A Figura 33 ilustra o comportamento da equação (3) para os valores de ρx entre
0 e 1. Observa-se que quando ρx tende a zero, o atraso médio total tende ao infinito.
Dois fatores influenciam no aumento do ρx, o primeiro é o somatório das taxas médias
de chegadas de mensagens das RSSF no qual uma aplicação baseada em regras tem
interesse; o segundo fator é a capacidade do servidor de consumir mensagens da fila.
83
Figura 33 – Gráfico - Atraso médio pelo ρx.
6.3 Considerações do capítulo
Este capítulo apresentou uma breve avaliação teórica da implementação da
arquitetura em relação ao sistema de filas decorrente da sua arquitetura. Do estudo
realizado, conclui-se que as filas existentes no sistema tendem a um modelo M/D/1,
assumindo-se como premissa que o modelo de chegada de dados de uma RSSF tem
como característica estatística uma distribuição Poisson. As equações de taxa de serviço
e de atraso médio total do sistema apresentadas servem para orientar a identificação dos
fatores que podem influenciar no delay do consumo das mensagens da fila.
O próximo capítulo apresenta as considerações finais deste trabalho, destacando
as suas considerações finais e perspectivas de trabalhos futuros.
84
Capítulo 7
7. Conclusões
Este trabalho apresentou uma arquitetura de suporte ao desenvolvimento de
aplicações de redes de sensores sem fio, baseada no uso de regras e nuvem
computacional, que promove a divisão de responsabilidades entre o programador da
rede e o especialista de domínio na construção das aplicações. Na arquitetura proposta,
a definição das regras de negócio e o tratamento dos eventos são retirados dos nós
sensores – o que consiste em um benefício adicional, considerando as restrições de
memória dos motes – e definidos e processados em uma plataforma de nuvem.
A implementação da arquitetura utilizou a plataforma Drools como sistema de
regras e a Amazon EC2 como plataforma de nuvem computacional. Por meio da adoção
da abordagem de regras, alterações puderam ser realizadas diretamente nas regras sem a
necessidade de nova compilação de código. Um web service RESTful foi implementado
para disponibilizar serviços a serem utilizados nas regras, propiciando o baixo
acoplamento desejado dos serviços em relação à definição das regras e permitindo o
desenvolvimento de novos serviços, independentemente de alterações na arquitetura. O
paradigma publish/subscribe foi usado como mecanismo básico para implementar o
compartilhamento dos dados provenientes das redes de sensores sem fio entre as
aplicações.
Foi desenvolvido um serviço web para gerenciar as aplicações, suas assinaturas
e o controle de acesso de usuários. Um estudo inicial sobre o comportamento teórico do
sistema de filas do ambiente proposto foi realizado com vistas à avaliar o seu
desempenho. Na implementação realizada, cada aplicação está associada a uma fila,
assinando o conteúdo de tópicos de interesse.
85
A adoção da abordagem baseada em regras provido em um ambiente de nuvem
computacional favoreceu a participação do especialista do domínio na definição das
regras do domínio, provendo um suporte para o desenvolvimento de aplicações reativas
sem que o especialista do domínio tenha conhecimento dos detalhes técnicos do projeto
das RSSF das quais qual ele consome informações coletadas do ambiente.
Como visto ao longo do estudo, as redes de sensores sem fio são muito limitadas
em relação aos recursos de hardware, o que implica em fortes restrições no processo de
desenvolvimento de aplicações, em especial em domínios onde as regras de negócio
podem ser muito extensas. Uma dificuldade adicional para o desenvolvedor de
aplicações diz respeito à diversidade de hardware de sensoriamento, o que requer
conhecimentos cada vez mais especializados, de baixo nível de abstração.
Sendo assim, qualquer movimento no sentido de facilitar o uso dados de RSSF
por usuários menos especializados e em domínios de aplicação diferentes, contribui para
a sua maior adoção. Observa-se que a integração entre RSSF e nuvem computacional é
uma tendência atual, particularmente devido à alta capacidade de uma infraestrutura em
nuvem para lidar com o volume de dados de tais redes.
Tais preocupações nortearam o projeto da infraestrutura aqui apresentada.
Entretanto, algumas questões importantes não foram tratadas nesta versão da
arquitetura, constituindo, portanto, temas naturais de trabalhos futuros. Dentre elas
destacamos:
Implementação do módulo de controle de privacidade;
A abordagem proposta defende a integração de dados coletados do
ambiente em uma plataforma de computação em nuvem. Entretanto,
apesar de considerarmos um tema relevante, a privacidade ficou fora do
escopo deste trabalho. Não há nenhum mecanismo que limite o acesso
aos dados capturados, pois a partir do momento que a rede de sensor sem
fio está conectada ao ambiente de nuvem, todos os dados capturados são
transmitidos, podendo ser consumido por quaisquer aplicações baseadas
em regras, presentes na arquitetura, que tenham interesse naquela
informação.
Inclusão de um componente de gerência de QoC (Quality of Context);
86
A arquitetura atual assume que os dados capturados pelas redes de
sensores sem fio e entregues na nuvem estão fieis a realidade do
ambiente monitorado. Entretanto, sabe-se que existem diversos fatores
que podem influenciar na precisão das informações coletadas, logo, um
trabalho futuro importante é incluir na arquitetura proposta um
componente de gerenciamento de qualidade de contexto, com a
finalidade de diagnosticar a precisão dos dados recebidos na nuvem,
assim, diminuindo a possibilidade de falso-positivos.
Realização de testes de capacidade (reais e simulados);
Neste trabalho foi descrito uma avaliação teórica da arquitetura de
implementação considerando algumas premissas. Logo, é importante a
realização de testes de capacidade em ambientes reais e simulados como
forma de avaliar
Disponibilização de novos serviços para uso nas regras;
Como forma de enriquecer as possibilidades de ações das aplicações
baseadas em regras, é importante o desenvolvimento de novos serviços,
explorando integração com outros serviços providos por plataformas de
nuvem computacional, redes sociais, integração com mecanismos
atuadores, entre outros.
Implementação da arquitetura proposta em um ambiente de nuvem
computacional de código aberto;
A plataforma de computação em nuvem da Amazon permite que
pesquisadores criem uma conta gratuita, para utilização limitada dos
serviços oferecidos pelo ambiente. A implementação da arquitetura
proposta em um ambiente de nuvem computacional de código aberto irá
proporcionar o desenvolvimento de testes de capacidade e desempenho,
além de permitir um maior controle dos serviços do ambiente.
Mecanismos de verificação e validação das regras;
Como forma de aprimorar a implementação da arquitetura proposta neste
trabalho, é importante desenvolver meios de verificar e validar as regras
escritas em Drools. Esses mecanismos geralmente estão presentes em
87
IDEs Java, entretanto, na implementação da arquitetura deste trabalho, as
regras são descritas por meio de uma interface web que não realiza as
verificações e validações necessárias antes da sua efetiva utilização.
Padronização da forma de armazenamento dos dados de sensoriamento.
Uma questão importante, porém abordado de forma superficial neste
trabalho se refere à forma de representação dos dados coletados, levando
em consideração a semântica da informação e a heterogeneidade do
hardware dos nós sensores. Em relação à semântica, existe uma linha de
pesquisa conhecida como Semantic Sensor Network, que baseado em
conceitos da web semântica, promove uma adaptação para o cenário de
redes de sensores sem fio. No que se refere à heterogeneidade do
hardware dos nós sensores, existem trabalhos que abordam essa questão,
utilizando uma notação XML para representação das informações.
88
8. Referências
ADAN, I.; RESING, J. Queueing theory. Eindhoven University of Technology
Eindhoven, , 2002.
AHMED, K.; GREGORY, M. Integrating Wireless Sensor Networks with Cloud
Computing. Mobile Ad-hoc and Sensor Networks (MSN), 2011 Seventh International
Conference on. Anais...2011
AKYILDIZ, I. F. et al. Wireless sensor networks: a survey. Computer networks, v. 38,
p. 393-422, 2002.
ARMBRUST, M. et al. A view of cloud computing. Communications of the ACM, v.
53, p. 50-58, 2010.
ATIF ALAMRI, M. A. H. WASAI SHADAB ANSARI MOHAMMAD MEHEDI
HASSAN M. SHAMIM HOSSAIN ABDULHAMEED ALELAIWI. A Survey on
Sensor-Cloud: Architecture, Applications, and Approaches. International Journal of
Distributed Sensor Networks, v. 2013, 2013.
BALI, M. Drools JBoss Rules 5.0 Developer’s Guide. [s.l.] Packt Publishing Ltd,
2009.
CHU, D. et al. The design and implementation of a declarative sensor network
system. Proceedings of the 5th international conference on Embedded networked sensor
systems. Anais...ACM, 2007
CLOUD, A. E. C. Amazon web services. Retrieved November, v. 9, p. 2011, 2011.
COSTA, L. C. Teoria das Filas, 2013. Disponível em:
<http://www.deinf.ufma.br/ mario/grad/filas/TeoriaFilas_Cajado.pdf>
CROCKFORD, D. JSON: The fat-free alternative to XML. Proc. of XML.
Anais...2006
DURISIC, M. P. et al. A survey of military applications of wireless sensor networks.
Embedded Computing (MECO), 2012 Mediterranean Conference on. Anais...2012
EGGERT, M. et al. SensorCloud: Towards the Interdisciplinary Development of a
Trustworthy Platform for Globally Interconnected Sensors and Actuators.
Wissenschaftliche Ergebnisse der Trusted Cloud Initiative, 2013., 2013.
EL KOUCHE, A. et al. WSN application in the harsh industrial environment of the
oil sands. Wireless Communications and Mobile Computing Conference (IWCMC),
2011 7th International. Anais...2011
EUGSTER, P. T. et al. The many faces of publish/subscribe. ACM Computing
Surveys (CSUR), v. 35, p. 114-131, 2003.
89
FERGUS, P. et al. A framework for physical health improvement using Wireless
Sensor Networks and gaming. Pervasive Computing Technologies for Healthcare,
2009. PervasiveHealth 2009. 3rd International Conference on. Anais...2009
FORGY, C. L. Rete: A fast algorithm for the many pattern/many object pattern match
problem. Artificial intelligence, v. 19, p. 17-37, 1982.
FRAGA, E. Serviço para gerenciamento de aplicações em um ambiente de
computação em nuvem e rede de sensores sem fio. [s.l.] Brasil, Universidade Federal
do Espírito Santo, 2013.
FUJITSU. WisReed: a technology to enable sensor network of future, 2013.
Disponível em: <http://www.fujitsu.com/global/services/solutions/sensor-
network/future/>
GARDINER, C. W.; OTHERS. Handbook of stochastic methods. [s.l.] Springer
Berlin, 1985. v. 3
GAY, D. et al. The nesC language: A holistic approach to networked embedded
systems. Acm Sigplan Notices. Anais...ACM, 2003
HAYES-ROTH, F. Rule-based systems. Commun. ACM, v. 28, p. 921-932, set. 1985.
HILL, E. F. Jess in Action: Java Rule-Based Systems. Greenwich, CT, USA:
Manning Publications Co., 2003.
HO, C.-M.; TAI, Y.-C. Micro-electro-mechanical-systems (MEMS) and fluid flows.
Annual Review of Fluid Mechanics, v. 30, p. 579-612, 1998.
HUSSAIN, M. A.; KHAN, P.; SUP, K. KYUNG. WSN research activities for
military application. Advanced Communication Technology, 2009. ICACT 2009. 11th
International Conference on. Anais...2009
KENDALL, D. G. Stochastic processes occurring in the theory of queues and their
analysis by the method of the imbedded Markov chain. The Annals of Mathematical
Statistics, p. 338-354, 1953.
KENDALL, M. G.; ALAN, S. The advanced theory of statistics. Vols. II and III. 1961.
KLEINROCK, L. Queueing systems. volume 1: Theory. 1975.
LAWRENCE, E. et al. Data Collection, Correlation and Dissemination of Medical
Sensor Information in a WSN. Networking and Services, 2009. ICNS ’09. Fifth
International Conference on. Anais...2009
LE, X. H. et al. Secured WSN-integrated cloud computing for u-life care. Consumer
Communications and Networking Conference (CCNC), 2010 7th IEEE. Anais...IEEE,
2010
LEE, S. H. et al. Wireless sensor network design for tactical military applications :
Remote large-scale environments. Military Communications Conference, 2009.
MILCOM 2009. IEEE. Anais...2009
90
LEVIS, P. et al. Tinyos: An operating system for sensor networks. In: Ambient
intelligence. [s.l.] Springer, 2005. p. 115-148.
LOUREIRO, A. A. et al. Redes de sensores sem fio. Simpósio Brasileiro de Redes de
Computadores (SBRC). Anais...2003
MITCHELL, R. J. Managing Complexity in Software Engineering. [s.l.] Peter
Peregrinus Ltd, 1990. v. 17
MOHAMMED, A. M.; AGAMY, A. F. A Survey on the Common Network Traffic
Sources Models. INTERNATIONAL JOURNAL OF COMPUTER NETWORKS
(IJCN), p. 103, 2011.
MOREIRA, D. A. Pesquisa Operacional: curso introdutório. [s.l.] Thomson
Learning, 2007.
MOTTOLA, L.; PICCO, G. P. Programming wireless sensor networks: Fundamental
concepts and state of the art. ACM Computing Surveys (CSUR), v. 43, p. 19, 2011.
NURSEITOV, N. et al. Comparison of JSON and XML Data Interchange Formats: A
Case Study. CAINE, v. 2009, p. 157-162, 2009.
PEREIRA, I. ; DOCKHORN COSTA, P. ; ALMEIDA, J. P. A. . A Rule Based
Platform for Situation Management. In: 2013 IEEE International Multi-Disciplinary
Conference on Cognitive Methods in Situation Awareness and Decision Support
(CogSIMA), 2013, SAN DIEGO. Cognitive Methods in Situation Awareness and
Decision Support (CogSIMA), 2013 IEEE Third International Multi-Disciplinary
Conference on, 2013.
POLASTRE, J. et al. Wireless sensor networks. In: RAGHAVENDRA, C. S.;
SIVALINGAM, K. M.; ZNATI, T. (Eds.). Norwell, MA, USA: Kluwer Academic
Publishers, 2004. p. 399-423.
RESOLUÇÃO, A. N. DE V. S. Guia para a realização de estudos de estabilidade.
[s.l.] Poder Executivo, Brasília, DF, Diário Oficial da União., 2005.
RICHARDSON, L.; RUBY, S. RESTful web services. [s.l.] O’Reilly, 2008.
RODRIGUES, T. et al. A Model-Based Approach for Building Ubiquitous Applications
Based on Wireless Sensor Network. In: Mobile and Ubiquitous Systems: Computing,
Networking, and Services. [s.l.] Springer, 2012. p. 350-352.
SAÚDE, M. DA. Manual dos Centros de Referência de Imunobiológicos Especiais.
[s.l.] Fundação Nacional de Saúde, 2001.
SILVA, K. et al. Modelos de avaliação da estabilidade de fármacos e medicamentos
para a indústria farmacêutica. Revista de Ciências Farmacêuticas Básica e Aplicada,
América do Norte, v. 30, p. 12, 2009.
SU, K.; LI, J.; FU, H. Smart city and the applications. Electronics, Communications
and Control (ICECC), 2011 International Conference on. Anais...IEEE, 2011
91
TERFLOTH, K.; WITTENBURG, G.; SCHILLER, J. FACTS–A rule-based
middleware architecture for wireless sensor networks. Communication System
Software and Middleware, 2006. Comsware 2006. First International Conference on.
Anais...IEEE, 2006
VASSEUR, J.-P.; DUNKELS, A. Interconnecting smart objects with ip: The next
internet. [s.l.] Morgan Kaufmann, 2010.
YICK, J.; MUKHERJEE, B.; GHOSAL, D. Wireless sensor network survey. Computer
networks, v. 52, p. 2292-2330, 2008.
YURIYAMA, M.; KUSHIDA, T.; ITAKURA, M. A New Model of Accelerating
Service Innovation with Sensor-Cloud Infrastructure. Proceedings of the 2011
Annual SRII Global Conference. Anais...: SRII ’11.Washington, DC, USA: IEEE
Computer Society, 2011Disponível em: <http://dx.doi.org/10.1109/SRII.2011.42>
ZHANG, Q.; CHENG, L.; BOUTABA, R. Cloud computing: state-of-the-art and
research challenges. Journal of Internet Services and Applications, v. 1, p. 7-18,
2010.
