See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/228860062

Arquitetura de Software para Redes de Sensores Sem Fios: a Proeminência do

Middleware

Article

CITATIONS READS

2 243

8 authors, including:

Talles M. de A. Barbosa Iwens I. G. Sene

33 PUBLICATIONS   76 CITATIONS   
Universidade Federal de Goiás
24 PUBLICATIONS   119 CITATIONS   
SEE PROFILE
SEE PROFILE

Hervaldo Sampaio Carvalho Adson Rocha

University of Brasília University of Brasília
48 PUBLICATIONS   736 CITATIONS    211 PUBLICATIONS   1,092 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Multidimensional Compression of Electrophysiological Signals View project

Sistema de controle pneumatico para manutencao continua das vias aereas em neonatos View project

All content following this page was uploaded by Francisco Assis De Oliveira Nascimento on 26 May 2014.

The user has requested enhancement of the downloaded file.

 Arquitetura de Software para Redes de Sensores sem Fios: a
Proeminência do Middleware.
Talles Marcelo G. de A. Barbosa1, 3, Iwens G. Sene Jr1, 3, Hervaldo S. Carvalho2,
Adson F. da Rocha1, Francisco A. de O. Nascimento1
1
Departamento de Engenharia Elétrica – Universidade de Brasília (UnB)
2
Faculdade de Medicina – Universidade de Brasília (UnB)
Campus Universitário - Asa Norte - 70910-090 - Brasília - DF - Brasil
3
Departamento de Computação – Universidade Católica de Goiás (UCG)
Av. Universitária 1.440 - Setor Universitário - 74605-010 - Goiânia - GO - Brasil
{talles, iwens, carvalho, adson, assis}@unb.br, {talles, iwens}@ucg.br
Abstract. The main purpose of this paper is to describe the state of the art in
software architectures and middleware alternatives for supporting and
developing applications in Wireless Sensor Networks (WSN). A secondary
purpose is to introduce SOAB architecture (Software Architecture for Body-
worn Sensor Networks). SOAB will be useful for supporting human monitoring
applications implemented in the environment of the Body-worn Sensor
Networks project, a wearable and wireless micro-sensor network for
monitoring human physiological health.
Resumo. O objetivo maior deste artigo é apresentar o estado da arte acerca das
arquiteturas de software e middleware existentes e utilizadas para suporte e
desenvolvimento de aplicações em Redes de Sensores Sem Fios (RSSF).
Como propósito secundário apresentar uma arquitetura de software que será
chamada de SOAB (Software Architecture for Body-worn Sensor Networks).
SOAB será implementada a fim de oferecer suporte para o projeto Body-worn
Sensor Networks, uma rede vestível de sensores sem fios para monitoramento
da saúde fisiológica humana.
.

XXXII SEMISH 1616

 1. Apresentação
Do trabalho de [Flynn 1972] pode-se verificar a equivalência entre as Redes de
Computadores (RC) e as Redes de Sensores Sem Fios (RSSF) sob o ponto de vista do
hardware. Ambos representam sistemas Multiple Instructions Multiple Data (MIMD)
fracamente acoplados (sem memória compartilhada), sistemas multicomputadores ou
simplesmente sistemas distribuídos.
Então, podemos afirmar que as RSSF e as RC representam um mesmo
paradigma computacional, diferindo, porém, quanto ao contexto da utilização. Enquanto
uma RC tem como objetivo a troca de informações (comunicação) as RSSF se
apresentam como solução para um outro contexto das necessidades humanas: a
necessidade do monitoramento cooperativo de eventos. Uma RSSF é um conjunto
composto por unidades autônomas (nós-sensores) interconectados por um meio de
comunicação sem fios.
A evolução tecnológica propiciou a redução do volume ocupado pelo hardware
bem como dos custos associados aos produtos, permitindo cada vez mais a
universalização da Computação como agente de inovação e desenvolvimento, pois
possibilita com que os sistemas de computação se tornem veículos indispensáveis a
outros ramos da ciência. Nesse contexto, a arquitetura de software e o projeto adequado
do middleware terão grande valia porque possibilitarão a adequação do hardware às
diversas necessidades humanas existentes, bem como para aquelas necessidades que
ainda surgirão.
Assim sendo, o objetivo maior deste artigo é apresentar o estado da arte acerca
das arquiteturas de software e em especial sobre o middleware para as RSSF. Na seção
2 são apresentados os requisitos genéricos para arquiteturas de software utilizadas em
RSSF, com enfoque centrado no middleware. Na seção 3 são apresentados os principais
trabalhos desenvolvidos e que ainda estão em desenvolvimento acerca do tema. Na
seção 4, é apresentada uma reflexão sobre o estado atual da tecnologia e na seção 5,
levando em conta as conclusões, é apresentada uma arquitetura de software que vem
sendo desenvolvida e será implementada a fim de oferecer suporte para o projeto Body-
worn Sensor Networks, uma rede vestível de sensores sem fios para monitoramento da
saúde fisiológica humana.

2. Análise dos Requisitos

2.1 Requisitos Não-Funcionais
Uma RSSF é um tipo de sistema dependente da aplicação [Loureiro et al. 2004], ou
seja, os fatores que podem influenciar o projeto de uma RSSF advêm dos requisitos
obtidos diante da serventia para a qual a RSSF foi pensada, seu Design Space [Römer
2004b]. Os requisitos comuns à maioria das aplicações referem-se a: (a) uso eficiente da
energia elétrica (energy efficiency); (b) capacidade de funcionamento diante de
situações adversas (robustness); (c) capacidade de crescimento incremental [Ruiz et al.
2003]: (i) em suportar uma carga crescente de trabalho (scalability) e (ii) facilidade de
inserção de novos módulos (extensibility).

XXXII SEMISH 1617

 2.1.1 Modelo de Software Baseado no Middleware
Neste momento, far-se-á necessário explicitar a definição de middleware adotada para o
contexto das RSSF. Inspirado pela definição apresentada em [Blair et al. 2004],
middleware é um artefato em software que reside entre a aplicação e a infra-estrutura de
suporte provendo através de interfaces o reuso de serviços que podem ser compostos e
configurados para desenvolvimento facilitado de aplicações mais eficientes para
ambiente distribuído tal como uma RSSF.
Como elemento gerador de produtividade, várias funcionalidades podem ser
associadas ao middleware quando empregado nas RSSF. Diante do panorama de
necessidades [Blumenthal et al. 2003] [Blumenthal et al. 2004] enfatizam a necessidade
de que o middleware para RSSF seja: (a) passível de crescimento incremental; (b)
genérico; (c) baseado em componentes; (d) adaptativo e (e) reflexivo.
Quanto ao software, o crescimento incremental pode ser alcançado fazendo uso
de compiladores mais otimizados em relação às restrições de memória e processamento
advindas do hardware, por exemplo, com a redução de tipos de dados, variáveis e
componentes que não serão utilizados.
A generalização dos métodos depõe a favor do middleware na medida em que se
busca adaptar as interfaces ao invés dos programas e assim obtém-se maior clareza do
código, desempenho da plataforma, simplicidade do uso e flexibilidade de manutenção.
Como exemplo de um método pouco genérico pode-se imaginar uma chamada para
execução de um módulo que propõe o cálculo da raiz quadrada de um número e o único
argumento seria um valor inteiro para o qual se deseja calcular a raiz quadrada. Um
método mais genérico, ainda fazendo uso da modularização “black box”, preveria a
possibilidade de outros tipos de cálculos que não somente a raiz de expoente dois e
adicionaria outro argumento para que o programador pudesse dizer qual o expoente da
raiz que se deseja calcular.
Um middleware baseado em componentes interconectáveis pode ser
confeccionado a partir de módulos de software independentes, reutilizáveis e onde cada
componente implementa uma funcionalidade bem definida. Assim, viabiliza-se a
construção de plataformas que poderão ser definidas ou adaptadas (middleware
adaptativo) em função das necessidades de cada aplicação ou categoria de aplicações.
A adaptabilidade provida pelo uso de componentes permite a inclusão, a
substituição e até a remoção tanto dos mecanismos quanto das políticas utilizadas, mas
exige modularização cada vez mais granular quando se caminha na direção das
políticas, o que pode aumentar significativamente o custo de manutenção da arquitetura
e gerar ineficiência no desempenho. Em grande parte das vezes o que se busca é apenas
um “ajuste do comportamento” frente a uma nova aplicação, e assim um refinamento
pode ser implementado com a coexistência da Reflexão Computacional.
Reflexão Computacional refere-se à capacidade de um sistema “ser racional”
sobre seus próprios atos, portanto é vista como sinônimo de inspeção e ou adaptação
[Coulson 2000]. Um sistema reflexivo mantém sua auto-representação interconectada
de maneira causal [Maes 87], ou seja, mudanças executadas em sua auto-representação
devem ser propagadas pelo sistema subjacente. Reflexão Computacional não incorre
necessariamente em sobrecarga [Coulson et al. 2004]. No contexto de utilização das
RSSF o uso de uma arquitetura de software com capacidade reflexiva pode aumentar a

XXXII SEMISH 1618

 facilidade em tratar mudanças no ambiente da aplicação bem como oferecer
adaptabilidade a outros tipos de aplicações.
Outro requisito não mencionado pela literatura científica atual refere-se à
padronização de elementos componentes da arquitetura de software como fomento a
abertura dos sistemas utilizados em RSSF. Um sistema aberto é aquele preparado para
comunicar-se com qualquer outro sistema aberto usando regras padronizadas que
governam o formato, o conteúdo e o significado dos interlocutores reconhecidos. É fator
preponderante para que um sistema se torne portável e extensível.

2.2 Requisitos Funcionais

2.2.1 Acesso Remoto

O acesso remoto é o mecanismo que viabiliza a troca de informações entre as
aplicações. Abstrai a complexidade da rede para o programador através do uso de
primitivas tal como send() e receive(). O modelo baseado em sockets e disponibilizado
pelas plataformas Unix-like é um dos expoentes desse tipo de mecanismo.
A granularidade da transparência oferecida aos programadores é implementada
em função do tipo de encapsulamento (marshalling) desejado. Obviamente, quanto
maiores as restrições impetradas pelo hardware menores serão os níveis de abstração
disponibilizados.
Diferentes políticas podem ser implementadas a fim de determinar a semântica
que organiza o envio e o recebimento das informações assim como aquelas que definem
os tamanhos de buffers onde as informações serão pré-armazenadas.
Como métricas para avaliação dos mecanismos para acesso remoto em RSSF
verificam-se: (a) aumento da transparência sem perda da flexibilidade e (b) sobrecarga
no consumo de energia e consequentemente redução na sobrevida do sistema. Nesse
contexto a capacidade de adaptação dos mecanismos e políticas pode ser significativa
quando além do aumento de desempenho busca-se o desenvolvimento de uma
plataforma portável entre aplicações diversas.

2.2.2 Nomeação, Descoberta e Roteamento.

Nomeação é o mecanismo que permite que cada nó sensor possa ser identificado de
forma unívoca. A solução convencional adotada pelas redes de computadores a partir do
protocolo IP requer capacidade para manipulação de bits proporcional ao número de nós
o que incapacita as atuais RSSF para implementação do protocolo IP como ele é
conhecido [Loureiro et al. 2004], [Chong & Kumar 2003]. Contudo, alternativas que
buscassem aproveitar a redundância existente entre os possíveis grupos de endereços
foram e ainda estão sendo desenvolvidas.
Loureiro [Loureiro et al. 2004] reconhece três tipos diferentes de endereçamento
para as RSSF: (a) endereçamento espacial; (b) endereçamento baseado em atributos; (c)
endereçamento de transações.
O mecanismo de descoberta implementa transparência necessária para a
localização dos sensores bem como dos serviços ofertados pelos mesmos. Esse
mascaramento pode ser estático – por meio de uma tabela associativa previamente
criada - ou dinâmico – usualmente implementado e mantido por meio de um repositório

XXXII SEMISH 1619

 responsável pelo gerenciamento de todos os recursos e serviços disponibilizados pela
rede a cada momento.
O roteamento é implementado por um mecanismo que efetua a escolha do
melhor caminho para o fluxo de dados entre dois ou mais nós. Em geral, as melhores
políticas para efetivar o roteamento dependerão da topologia escolhida para a montagem
da RSSF. Loureiro [Loureiro et al. 2004] classifica os tipos de roteamento como: (a)
roteamento plano, (b) roteamento hierárquico e (c) roteamento geográfico.
Em RSSF os serviços ofertados pelos mecanismos de nomeação, descoberta e
roteamento requerem rapidez, transparência e flexibilidade para troca ou ajuste das
políticas sem impacto relevante no consumo de energia.

2.2.3 Gerência, Manutenção e Monitoramento dos Recursos

Ahamed [Ahamed et al. 2004] verifica a possibilidade de dois tipos de políticas
empregadas em mecanismos para gerência de uma RSSF: (a) gerência proativa, onde a
ação executada pelo mecanismo antecipa a ocorrência de um evento relativo ao
funcionamento da RSSF; (b) gerência reativa, caso ação seja tomada após ocorrência do
evento.
Como funcionalidades almejadas para este tipo de mecanismo: (a)
monitoramento e ajuste do consumo de energia, (b) verificação de falhas, (c) segurança
e proteção, (d) inicialização e reconfiguração remota [Liu & Martonosi 2003], (e)
manutenção da consistência: (i) adição e remoção de nós e (ii) sincronização do tempo.
Entretanto, uma solução em middleware que contempla todas essas
funcionalidades formando um pacote único de software é impraticável até mesmo no
contexto das redes de computadores, pois terá impacto significativo no desempenho do
sistema. Dessa forma, há necessidade de uma estrutura flexível onde o desenvolvedor
possa definir quais as funcionalidades e políticas serão necessárias para a aplicação.
Aliado à flexibilidade existe ainda a necessidade de que a implementação destas
funcionalidades não crie sobrecarga para o consumo de energia e nem para a rapidez
com que o sistema deverá funcionar.

2.2.4 Cooperação: Fusão de Dados

L. Wald [Wald 1999] define o termo fusão de dados da seguinte forma: “Fusão de
dados é uma estrutura formal na qual estão expressos os meios e ferramentas para
junção dos dados originários de diferentes fontes. Seu objetivo é a obtenção de
informações de maior qualidade; a definição exata de ‘maior qualidade’ irá depender
da aplicação”.
Para muitas situações é interessante que a RSSF disponha de um mecanismo
capaz de sintetizar informações a partir da coleta de dados – fusão de dados - ou até
mesmo economizar recursos fazendo uso da redundância funcional que eventualmente
possa existir entre nós-sensores de uma mesma RSSF. Estudos mostraram que o
consumo de energia para executar 1000 instruções é equivalente ao consumo para
transmitir um bit de informação a cerca de cem metros de distância via radio [Culler &
Levis 2002].
Por outro lado, em [Carvalho et al. 2003c] verifica-se que para aplicações com
grandes restrições em largura de banda e ao atraso e quando executadas por uma RSSF

XXXII SEMISH 1620

 com pouca densidade de nós – tal como em aplicações para monitoramento humano – a
agregação de informações comumente empregadas através da técnica multihop é
dispensável. A agregação multihop é usualmente empregada pela utilização de
mecanismos que executam roteamento em RSSF, onde a informação usualmente
percorre por vários nós até chegar ao destino.
Neste momento algumas indagações podem surgir face ao dilema exposto. O
mecanismo de cooperação deverá ou não ser considerado quando o propósito é a
obtenção de uma RSSF multi-aplicações? Quando deverá ser utilizado? Como deverá
ser utilizado? O fato é que até o presente momento inexiste uma solução implementada
em middleware que responda a todas essas perguntas. Sabe-se que para muitas
aplicações o mecanismo de cooperação será sinônimo do aumento da produtividade, do
desempenho e da sobrevida e que para outras aplicações será indiferente ou até mesmo
prejudicial.
Mais uma vez a existência de uma plataforma de software flexível – que
possibilite a substituição de mecanismos e a troca de políticas – se faz necessária.
Porém, a flexibilidade não poderá incorrer em sobrecarga para o sistema, afetando a
rapidez com que o mesmo deverá atender às suas requisições.

3. Trabalhos Relacionados
A fim de agrupar as abordagens acerca de middleware para RSSF quatro tipos de
classificação foram estabelecidos: (a) máquina virtual; (b) base de dados; (c) orientado a
eventos e (d) serviços. Tipos diferentes de classificação, como data-oriented e mobile
agents, foram citados por [Römer 2004]. Contudo, espera-se que com esta categorização
um número maior de trabalhos possa ser catalogado a partir dos propósitos funcionais.

3.1 Máquina Virtual

Scylla [Stanley- Marbell & Iftode 2000] é uma máquina virtual projetada para sistemas
embutidos móveis (embedded mobile systems). Além da gerência do hardware, Scylla
disponibiliza um mecanismo para acesso remoto (“inter-device communication”),
gerência de energia e recuperação de falhas.
MagnetOS [Sirer et al. 2001] é um sistema operacional distribuído que propõe
implementar o balanceamento de carga através da migração de código entre os sensores.
A carga de trabalho (Object Oriented Byte Code Program) – inspiração na tecnologia
Java - é distribuída de forma automática e transparente entre os elementos do conjunto a
fim de minimizar a troca de informações durante a execução de tarefas.
Bertha [Lifton et al. 2002] é o sistema operacional que dá suporte ao projeto
PushPin do M.I.T. É um projeto fortemente influenciado por modelos biológicos. Além
das atividades de kernel - como gerência de processador, memória e comunicação -
Bertha fornece suporte ao balanceamento de carga e atualização remota através de um
mecanismo conhecido com “Process Fragment Execution” que executa fragmentação do
código para que ele possa ser distribuído entre os nós para execução.
Como um dos projetos proeminentes nessa área, Maté [Culler et al. 2002] se
apresenta como uma máquina virtual capaz de interpretar byte-codes para a plataforma
Mica Motes/TinyOS de Berkeley viabilizando a reprogramação dos nós com economia
de energia e aumentando a proteção para o hardware. Maté capacita-se à execução de

XXXII SEMISH 1621

 instruções concorrentes mapeando essas instruções em tarefas gerenciadas pela unidade
subjacente, o sistemas operacional TinyOS.
Disponibilizando API (Application Programming Interface) de alto nível,
SensorWare [Boulis et al. 2003] se apresenta como um framework para suporte a
migração de programas (scripts) escritos em linguagem de programação TCL. Os
scripts têm como finalidade principal a coleta de informações monitoradas pela RSSF
assim como a reconfiguração da própria RSSF. SensorWare pretende também aumentar
o nível de proteção para as camadas subjacentes.

3.2 Base de Dados

O COUGAR [Bonnet et al. 2000] é uma abordagem que leva em consideração
limitações do enlace físico durante a agregação de informações a fim de minimizar o
consumo de energia e facilitar a coleta de dados. Disponibiliza uma interface SQL-like
para programação das consultas.
SINA [Jaikaeo et al. 2001] também oferece suporte a consultas e programas em
linguagem SQL-like. Incorpora um mecanismo de baixo nível a fim de facilitar a
formação de cluster hierarquizado para a agregação de dados. O tratamento de falhas
fica a cargo da aplicação.
O TAG (Tiny AggreGation Service for Ad-hoc Sensor Networks) [Madden et al.
2002] apresenta uma abordagem muito parecida ao COUGAR e também ao SINA.
Oferece um serviço genérico para agregação de informações e consulta aos nós em
linguagem SQL-like. Propõe eficiência buscando economizar tempo e energia. Como
plataforma de suporte foi utilizada a arquitetura TinyOS/MicaMotes de Berkeley.
Os sistemas que executam o processamento de consultas têm o desempenho
afetado pelos mecanismos que provêem a intercomunicação entre os nós. Contudo,
algumas melhorias poderão ser necessárias. De acordo com [Madden et al. 2004], a
evolução desse tipo de plataforma passa pela reorganização do software de maneira a
flexibilizar a construção e o reuso de mecanismos para processamento de consultas.
Limitado a cenários que não requerem comunicação multihop, o TinyLime
[Murphy et al. 2004] atua como um “envelope” de software sobre os subsistemas da
arquitetura MicaMotes de Berkeley. TinyLime surgiu através de uma simples adaptação
do Lime [Murphy et al. 2001] para uso em RSSF. Disponibiliza a RSSF através de uma
interface conhecida como Tuple Space e por meio da qual provê um modelo de memória
compartilhada, oriundo do Lime, entre aplicações e sensores. Os clientes em uso do
TinyLime desenvolvem suas aplicações através de templates escritos em linguagem
Java e o componente TOSMoteAcess é responsável pela tradução para a plataforma
MicaMotes.

3.3 Orientado a eventos

Como parte integrante de um projeto para monitoramento da vida selvagem na África
(ZebraNet), o Impala [Liu & Martonosi 2003] foi apresentado como uma lightweight
runtime, composta por um kernel e um middleware acoplados, que atua como
gerenciador de eventos e de dispositivos. Provê à plataforma capacidade de atualização
(update) e reconfiguração remota necessária ao tipo de aplicação para o qual foi
pensado buscando aumentar a performance, sinônimo de rapidez, confiabilidade e

XXXII SEMISH 1622

 consumo eficiente de energia. Disponibiliza um modelo de programação baseado em
eventos onde a aplicação é desenvolvida através de um conjunto de tratadores de
eventos.
O EnviroTrack [Abdelzaher et al. 2004] se apresenta como middleware
orientado a objetos para arquitetura MicaMotes de Berkeley. Provê interface de
programação baseada no monitoramento de eventos (tracking) do ambiente físico.
Almeja desta forma a redução dos custos de desenvolvimento das aplicações omitindo
ao programador detalhes da programação de baixo-nível

3.4 Serviços
AutoSeC [Han & Venkatasubramanian 2001] é uma abordagem adaptativa que se
utiliza da combinação de informações coletadas durante o funcionamento do sistema,
juntamente com requisitos oriundos da aplicação para a configuração do serviço que
gerencia a Qualidade do Serviço (QoS) oferecida pela RSSF. Para tanto, vale-se de
métricas que procuram aumentar o throughtput, capacidade de vazão de informações, e
o scaling da RSSF.
O Data Service Middleware (DSWARE) [Li et al. 2003] foi apresentado como
uma arquitetura de software multicamadas a fim de integrar serviços de dados e oferecer
uma interface SQL-like para o desenvolvimento das aplicações. Seu funcionamento é
baseado num mecanismo adaptativo que, por meio da fusão de dados e da tomada de
decisões, prioriza informações com características de tempo real e que enfocam o uso
eficiente da energia.
SeNeTs [Blumenthal et al. 2003] [Blumenthal et al. 2004] é um emulador para
RSSF desenvolvido pela Universidade de Rostok. Propõe uma arquitetura de software
modularizada em componentes, que possibilite o crescimento incremental, seja
genérica, adaptativa e reflexiva. Não apresenta detalhes significativos acerca da
capacidade reflexiva a fim de torná-la viável de fato.
Sicherheit in Sensornetzen [Hurler et al. 2004] é ainda um trabalho em estado
embrionário que prevê a criação de um serviço de localização implementado por meio
de um middleware. Tem com propósito organizar a distribuição e a disponibilização de
serviços dentro de uma RSSF, algo parecido com os serviços de diretórios em redes de
computadores. A arquitetura é composta por dois principais componentes: Service
Manager, responsável por processar os pedidos de serviço e o Distributed Service
Directory, responsável pela catalogação dos serviços. Prevê ainda a criação de uma
linguagem específica para implementação dos serviços.
O Middleware Linking Applications and Networks (MiLAN) [Carvalho et al.
2003b] [Carvalho et al. 2004] é uma abordagem que implementa como principal serviço
a gerência proativa de QoS da Rede, monitorando e ajustando a largura de banda e o
consumo de energia de acordo com a importância (requisitos) definidos para cada
aplicação. Tem como principais objetivos: (a) maximizar o tempo de vida útil da rede e
(b) oferecer uma interface adequada para que as aplicações possam apresentar os seus
requisitos de forma quantificada e transparente.
Como projeto encabeçado pelo NCE/GTA-UFRJ, [Delicato et. al 2004]
apresentam um middleware para RSSF com certa similaridade ao MiLAN. Como
propósito principal estabelece um framework para a camada de aplicação a fim de

XXXII SEMISH 1623

 viabilizar a construção de aplicações diversas para as RSSF em formato padronizado. O
Formato XML e os protocolos oriundos desse formato são utilizados na composição do
mecanismo para representar consultas, tarefas e dados.

4. Ponderação: O Estado da Arte

Neste instante algumas considerações relativas ao estado da arte se fazem pertinentes.
Para tanto, considerar-se-ão dois estágios relativos às pesquisas e à tecnologia.
No primeiro momento (1994-2004), a maioria dos trabalhos encontrados
evidencia as possibilidades decorrentes do uso das RSSF em sua diversidade de
aplicações. Vários projetos foram desenvolvidos em várias partes do mundo, cada um
ao seu modo, realçando a aplicabilidade em construir plataformas para aplicações
específicas.
A maior preocupação durante esse período foi com o consumo de energia,
ressaltando que os nós-sensores seriam operados por baterias não-recarregáveis e que o
consumo excessivo, principalmente para aplicações de difícil manutenção, seria o maior
vilão contra a sobrevida da rede. A partir dessa premissa o software e principalmente o
hardware deveriam ser adaptados.
No tocante ao hardware, o conceito Low-Power que de forma imperativa exige
pouco consumo por ciclo de trabalho está sendo suplantado pelo conceito de Energy-
Efficient, que de forma granular vigora em função do consumo de energia por instrução
executada [Coelho et al 2003]. Quanto aos transmissores e receptores via rádio,
principais agentes do consumo de energia, padrões recém-lançados pela indústria, como
Bluetooth e que já vinham sendo utilizados em RSSF [Metha & Zarki 2004] perderam
espaço para outros mais novos ainda, como o IEEE 802.15.4 [Zigbee 2004]. E tudo isso
utilizando componentes de prateleira (off-the-shelf) de baixo custo. Entretanto, pouca
evolução se verificou no tocante às tecnologias que norteiam a construção das baterias.
No que tange o software, a maior parte da evolução aconteceu em função dos
protocolos para interconexão dos nós. Sempre levando em consideração a economia de
energia, estratégias baseadas no roteamento multihop aliadas às metodologias utilizadas
para fusão de dados passam a vigorar com freqüência a cada nova proposta de protocolo
apresentada. Em função das restrições do hardware que nesse momento desafiava a
operacionalização dos projetos, pouco se buscou em portabilidade e padronização,
especificamente para software.
A busca por plataformas mais flexíveis faz do momento atual (2005-x) palco
para discussões a respeito das arquiteturas tanto de hardware quanto do software.
A capacidade de reconfiguração do hardware aliada ao baixo consumo de
energia faz com que soluções baseadas em Field-Programmable Gate Array (FPGA)
sejam contestadas [Jovanov et al. 2004] [Coelho et al. 2003]. Assim sendo, arquiteturas
power-aware, como a primeira geração MicroAmps apresentadas pelo Massachusetts
Institute of Technology (M.I.T). [Chandrakasan et al. 2000] [Chandrakasan et al. 2002]
estão sendo reformuladas. É possível que avanços promovidos pela microeletrônica
eliminem a necessidade do uso da baterias já que ao ultrapassar a barreira dos 100µW
(MicroWatts) teoricamente os nós-sensores poderão ser alimentados pela energia
extraída do ambiente operacional [Chandrakasan et al. 2004].

XXXII SEMISH 1624

 Quanto ao software é provável que as discussões caminhem na direção da
padronização e da flexibilização como forma de garantir e aumentar a portabilidade das
plataformas junto à diversidade de aplicações, assim como ocorreu com as redes de
computadores. Nesse sentido, discussões acerca da arquitetura de software,
principalmente sobre o middleware, serão de grande valia.
Por ter sido a primeira plataforma disponível comercialmente, a plataforma
MicaMotes de Berkeley [Crossbow 2004] anda a passos mais largos mas não
necessariamente na direção correta. De fato ainda não existem padrões que norteiam o
desenvolvimento de aplicações, como interfaces POSIX, ou que enquadram as
funcionalidades pertinentes ao middleware, como por exemplo, o padrão CORBA.
A possibilidade de inserção dos modelos desenvolvidos pela engenharia de
software como a Computação Reflexiva e a modularização em Componentes e Aspectos
tem chamado a atenção de pesquisadores como [Blair et al. 2004b]. Por outro lado,
novos paradigmas de programação como Abstract Regions [Welsh et al. 2004] têm
aparecido como solução para interface homem-máquina no contexto das RSSF. De
qualquer maneira, a busca por uma arquitetura de software mais flexível e preparada
para reuso será tema para debates nos próximos anos.

5. Conclusão: uma Proposta

Como extensão ao trabalho de [Carvalho et al. 2003] [Carvalho et al. 2003b] [Carvalho
et al. 2003c] [Carvalho et. al 2004], SOAB (Software Architecture for Body-worn
Sensor Networks) tem como propósito o projeto e a construção de uma arquitetura de
software para suporte a uma RSSF utilizada no monitoramento humano (projeto Body-
worn Sensor Networks).
Dentre as informações monitoradas estarão: (a) o eletrocardiograma
(ECG/EKG); (b) o eletroencefalograma (EEG) (c) o eletromiograma não-invasivo
(EMG); (d) a oximetria de pulso (SpO2), (e) a resistência galvânica da pele (GSR); (f)
temperatura e (g) monitoramento da posição. A grande expectativa, dentre outras, é a
possibilidade de que a inserção das RSSF na indumentária humana (Wearable
Computing) possa proporcionar um novo paradigma para o monitoramento da saúde.
Tanto para o projeto do hardware como para a arquitetura de software a palavra
chave que norteia as decisões é “flexibilidade”. Contudo, neste texto estaremos atentos
principalmente às discussões que direcionam o projeto do software.
Flexibilidade diante da arquitetura de software refere-se à capacidade de ajuste
da plataforma a fim de acomodar uma aplicação genérica e facilitar a integração com
outras plataformas. Assim sendo, entende-se que uma arquitetura orientada a serviços
permitirá que a própria aplicação possa definir, a partir de seus requisitos funcionais,
quais serviços (funcionalidades) serão necessários. Como benefício, por exemplo, uma
aplicação para telemetria de atletas que contenha requisitos diferentes do
monitoramento de pacientes em ambiente doméstico (Smart Home) poderá utilizar a
mesma plataforma de suporte pela reconfiguração por meio do software.
SOAB prevê modularização em camadas funcionais, onde cada camada será
responsável por prover um grupo de serviços. São camadas funcionais: (a) kernel –
gerenciamento do hardware (b) middleware – interconexão e serviços em rede e (c)
aplicação – interfaceamento com o usuário e integração com outros sistemas.

XXXII SEMISH 1625

 Cada camada poderá ser composta por um ou mais componentes. Para grande
parte dos componentes do software serão disponibilizados dois tipos de interfaces: (a)
interface funcional e (b) meta-interface. A interface funcional é responsável por oferecer
a transparência necessária aos desenvolvedores enquanto as meta-interfaces oferecem
acesso às estruturas internas dos componentes, especialmente para ajuste
comportamental do software. Para o componente responsável pelo escalonamento de
tarefas, por exemplo, a disponibilidade de uma interface dual permitirá o ajuste da
política de escalonamento levando em consideração o consumo de energia (Energy
Efficient Real-Time Scheduling [Sinha & Chandrakasan, 2001]).
No espaço do kernel, assim como no do middleware, verifica-se a presença de
duas estruturas de código residentes em memória, o micro-kernel e o micro-daemon (
vide Figura 1). O micro-daemon, responsável pela manutenibilidade dos serviços do
middleware, mapeia cada novo serviço em uma tarefa executada pelo micro-kernel.
Entretanto, cabe ao micro-daemon a possibilidade de estabelecer os valores de
prioridade para cada tarefa assim como o ajuste dos parâmetros que governam o
escalonamento das mesmas através das interfaces funcionais e das meta-interfaces do
kernel, que poderão, ainda, serem utilizadas para inspeção comportamental das
atividades do kernel.
Ainda no espaço do kernel verifica-se a separação entre o nível-base e os
tratadores de eventos. Essa flexibilidade possibilitará que para cada nova aplicação
grupos específicos de tratadores de eventos possam ser compostos, configurados e
utilizados, promovendo reuso de código com eficiência em memória.
A camada de aplicação pode atuar diretamente tanto sobre o middleware, quanto
sobre o kernel. Para isso, precisa disponibilizar ao usuário uma forma adequada para
interação com a RSSF. Ainda por meio de meta-interfaces, SOAB – na camada de
aplicação – permite que o usuário possa definir e até mesmo reconfigurar qual é a
melhor ou a mais adequada interface funcional para o seu trabalho. Além da interface
com o usuário, a camada de aplicação pode ser vista como uma camada de software
para integração da RSSF com outras redes de comunicação e que soluções já existentes,
como o MiLAN [Carvalho et. al 2004], podem facilmente serem acopladas.
O acesso às meta-interfaces do kernel, o deployment de componentes no
middleware - funcionalidade prevista para a segunda versão de SOAB - e a
reconfiguração da interface para usuário também serão disponibilizadas por meio de
funcionalidades especificas da camada de aplicação, implementada num terminal fora
do hardware que representa o nó-sensor.
Até o momento, de acordo com a literatura pesquisada nenhum documento
encontrado apresenta proposta semelhante acerca da viabilidade de uma plataforma
multi-aplicações para RSSF. Calcada na capacidade de adaptação através de meta-
interfaces e na independência das camadas de software esta proposta trás inovações
consideráveis para futuras discussões acerca das arquiteturas de software para RSSF
fazendo deste documento referência relevante sobre o tema.
Dessa forma, é importante avigorar que a arquitetura de software e o projeto
adequado do middleware terão grande valia porque possibilitarão a adequação do
hardware às diversas necessidades humanas existentes, diante da diversidade de
aplicações, bem como para aquelas necessidades que ainda surgirão e assim, cada vez

XXXII SEMISH 1626

 mais, será possível que a Computação se transforme num agente de inovação e
desenvolvimento universal.

Figura 1. Layout Funcional de SOAB.

Referências
Abdelzaher T., Blum B., Evans D., George J., George S., Gu L., He T., Huang C.,
Nagaraddi P., Son S., Sorokin P., Stankovic J. and Wood A.(2004) “EnviroTrack:
Towards an Environmental Computing Paradigm for Distributed Sensor Networks”,
In IEEE ICDCS , March.
Ahamed S., Vyas A. and Zulkernine M. (2004) “Towards Developing Sensor Networks
Monitoring as a Middleware Service”, In Proc. of the International Workshop on Ad
Hoc and Sensor Networks - International Conference on Parallel Processing (ICPP
'04), August.
Amorim C. et al. (2004) “Tutorial sobre Redes de Sensores”, In Simpósio Brasileiro de
Redes de Computadores (SBRC), maio.
Blair G., Campbell A. and Schmidt D., (2004) "Middleware Technologies for Future
Communication Networks", IEEE Network, Vol. 18, No. 1, January.
Blair G., Coulson G., Grace P. (2004b) "Research Directions in Reflective Middleware:
the Lancaster Experience", In Proceedings of the 3rd Workshop on Reflective and
Adaptive Middleware (RM2004) co-located with Middleware 2004, October.
Blumenthal J., Handy M., Golatowski F., Haase M. and Timmermann D. (2003)
“Wireless Sensor Networks - New Challenges in Software Engineering”, In
Proceedings of 9th IEEE International Conference on Emerging Technologies and
Factory Automation (ETFA), September.

XXXII SEMISH 1627

 Blumenthal J., Handy M. and Timmermann D. (2004) “Software Development using
SeNeTs for Wireless Sensor Networks”, In 2nd International Forum Life Science
Automation, Rostock, September.
Bonnet P., Gehrke E. J. and Seshadri P. (2000) “Querying the Physical World”, IEEE
Personal Communications, Special Issue on Smart Spaces and Environments,
October.
Boulis A., Han C., and Srivastava M. (2003) “Design and implementation of a
framework for efficient and programmable sensor networks”, In The First
International Conference on Mobile Systems, Applications, and Services (MobiSys
2003), May.
Carvalho H., Heinzelman W., Murphy A. and Coelho C. (2003) “A General Data
Fusion Architecture”, In Proceedings of the 6th International Conference on
Information Fusion (Fusion 2003), June.
Carvalho H., Heinzelman W., Murphy A. and Coelho C. (2003b) “Network-Based
Distributed Systems Middleware”, In Proceedings of the 1st International Workshop
on Middleware for Pervasive and Ad-Hoc Computing, June.
Carvalho, H. et al. (2003c) “A biomedical wearable device for remote monitoring of
physiological signals”, Proceedings. ETFA '03. IEEE Conference, September.
Carvalho H., Perillo M., Heinzelman W, Murphy A. (2004) "Middleware to Support
Sensor Network Applications", IEEE Network Magazine Special Issue, January.
Chandrakasan P. A. et al. (2000) “Power-Aware Systems”, In Proceedings of 34th
Asilomar Conference, November.
Chandrakasan P. A. et al. (2002) “Power Aware Wireless Microsensor Systems”,
Keynote Paper ESSCIRC, September.
Chandrakasan P. A. et al. (2004) “Design considerations for next generation wireless
power-aware microsensor nodes”, Proceedings of VLSID 2004, pp. 361-367,
January.
Chong C., Kumar P. (2003) “Sensor networks: Evolution, opportunities, and
challenges”, Proceedings IEEE, August.
Coelho. Jr C. et al. (2003) “Survey on Wireless Sensor Network Devices”, In
ETFA2003, September.
Coulson G. (2000) “What is a reflective Midddleware?”, IEEE Distributed Systems on-
line.
Coulson, G., Blair, G.S., Grace, P. (2004) “On the Performance of Reflective Systems
Software”, Proceedings of the International Workshop on Middleware Performance
(IWMP 2004), April.
Crossbow (2004) “Smarter Sensor in Silicon”, http://www.xbow.com, 2004.
Culler D. and Levis P. (2002) “Maté: A Tiny Virtual Machine for Sensor Networks”, In
Proceedings of the 10th International Conference on Architectural Support for
Programming Languages and Operating Systems (ASPLOS X).

XXXII SEMISH 1628

 Delicato F., Pires F. P., Lages A., Rezende F. J. and Pirmez L. (2004) “Middleware
orientado a Serviços para Redes de Sensores Sem Fio”, In Simpósio Brasileiro de
Redes de Computadores (SBRC), Maio.
Flynn, M. J. (1972) “Some Computer organization and their effectiveness”, IEEE Trans.
On Computers, vol. C-21, pp948-960, september.
Han Q. and Venkatasubramanian N. (2001) “AutoSeC: An Integrated Middleware
Framework for Dynamic Service Brokering”, IEEE Distributed Systems Online.
Hurler B., Hof H. and Zitterbart M. (2004) “A General Architecture for Wireless Sensor
Networks: First Steps”, In 4th International Workshop on Smart Appliances and
Wearable Computing, Tokyo Japan, march 2004.
Jaikaeo C., Shen C. and Srisathapornphat C. (2001) “Sensor Information Networking
Architecture and Applications”, IEEE Personal Communication Magazine.
Jovanov E. et. al. (2004) “Reconfigurable Intelligent Sensors for Health Monitoring: A
Case Study of Pulse Oximeter Sensor”, In Proceedings of the 26th Annual
International Conference of the IEEE Engineering in Medicine and Biology Society,
San Francisco, September.
Li S., Son S. and Stankovic J. (2003) “Event Detection Services Using Data Service
Middleware in Distributed Sensor Networks”, Proc. 2nd Int’l. Wksp. Info.
Processing in Sensor Networks, April.
Lifton J., Seetharam D., Broxton M., Paradiso J. (2002) “Pushpin Computing System
Overview: A Platform for Distributed, Embedded, Ubiquitous Sensor Networks”,
PushPin Project, MIT-Media Labs.
Liu T. and Martonosi M. (2003) "Impala: A Middleware System for Managing
Autonomic, Parallel Sensor Systems", ACM SIGPLAN Symposium on Principles
and Practice of Parallel Programming, June.
Loureiro A. A. et al. (2004) “Arquiteturas para redes de Sensores Sem Fio”, Simpósio
Brasileiro de Redes de Computadores (SBRC), maio.
Madden S., Franklin M., Hellerstein J. and Hong W. (2002) “TAG: A tiny aggregation
service for ad-hoc sensor networks”, Proceedings of Operating Systems Design and
Implementation. USENIX, December.
Madden S, Woo A. and Govindan R. (2004) “Networking support for query processing
in sensor networks”, Communications of the ACM, vol. 47 no. 6, june.
Maes P. (1987) “Concepts and Experiments in Computational Reflection”, In
Procedings of OOPSLA’87.
Mehta V., El Zarki M. (2004) “A bluetooth based sensor network for civil infrastructure
health monitoring”, Wireless Networks Magazine ACM Issue 4, july.
Murphy, A. L., Picco, G. P., and Roman, G.-C., (2001) “LIME: A Middleware for
Physical and Logical Mobility,” In Proceedings of the 21st International Conference
on Distributed Computing Systems, April.
Murphy A, Curino C., Giani M. and Giorgetta M., (2004) “TinyLIME: Bridging Mobile
and Sensor Networks through Middleware” Submitted for publication,
http://www.elet.polimi.it/upload/picco/listpub.html, December.

XXXII SEMISH 1629

 Römer K. (2004) “Programming Paradigms and Middleware for Sensor Networks”,
GI/ITG Fachgespräch Sensornetze, Karlsruhe, February.
Römer K., Mattern F. (2004) “The Design Space of Wireless Sensor Networks”, IEEE
Wireless Communications, December .
Ruiz L. B., Loureiro A. A., Franciscani F. P., Rainer R. P., e Nogueira, J. M. S. (2003)
“Middleware para redes de sensores sem fio”, Livro texto do IV WTF do XXI
Simpósio Brasileiro de Redes de Computadores (SBRC). ISBN 85-88442-49-3.
Sinha A. and Chandrakasan A. (2001) "Energy Efficient Real-Time Scheduling" In
Proeedings of the International Conference on Computer Aided Design (ICCAD),
San Jose, November.
Sirer G. E., Barr R., T.W. Danny Kim, Fung I.(2001) “Automatic Code Placement
Alternatives for Ad Hoc and Sensor Networks”, Computer Science Technical Report
2001-1853. Cornell University, October.
Stanley-Marbell P. and Iftode L. (2000) “Scylla: A Smart Virtual Machine for Mobile
Embedded Systems”, In Proceedings of The 3rd IEEE Workshop on Mobile
Computing Systems and Applications.
Wald L. (1999) “Some terms of reference in data fusion”, IEEE Transactions on
Geoscience and Remote Sensing.
Welsh M. et al. (2004) “Programming Sensor Networks Using Abstract Regions”,
Proceedings of the First USENIX/ACM Symposium on Networked Systems Design
and Implementation (NSDI '04), March.
Yu X. et al. (2002) “Adaptive Middleware for Distributed Sensor Environments”,
University of California.
Yu Y., Krishnamachari B. and Prasanna V. (2004) "Issues in Designing Middleware for
Wireless Sensor Networks", IEEE Network Magazine, January.
Zigbee Aliance, (2004) http://www.zigbee.org/, Dezembro.

XXXII SEMISH 1630

View publication stats