UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA
DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO
DISSERTAÇÃO DE MESTRADO
LWiSSy: Uma Linguagem Específica de
Domínio Para Modelagem de Sistemas de
Redes de Sensores e Atuadores Sem Fio
Priscilla Victor Dantas
Natal-RN
Priscilla Victor Dantas
LWiSSy: Uma Linguagem Específica de Domínio
para Modelagem de Sistemas de Redes de Sensores e
Atuadores Sem Fio
Dissertação de Mestrado submetida ao
Programa de Pós-Graduação em Sistemas e
Computação do Departamento de Informática e
Matemática Aplicada da Universidade Federal
do Rio Grande do Norte como parte dos
requisitos necessários para a obtenção do grau
de Mestre em Sistemas e Computação.
Orientador(a)
Prof.ª Dr.ª Flávia Coimbra Delicato
Co-orientador(a)
Prof.ª Dr.ª Thaís Vasconcelos Batista
Universidade Federal do Rio Grande do Norte – UFRN
Departamento de Informática e Matemática Aplicada – DIMAp
Natal-RN
UFRN / Biblioteca Central Zila Mamede Catalogação da Publicação na Fonte Dantas, Priscilla Victor.
LWiSSy: uma linguagem específica de domínio para modelagem de sistemas de redes de sensores e atuadores sem fio. / Priscilla Victor Dantas. – Natal, RN, 2012.
134 f. : il.
Orientadora: Profa. Dra. Flávia Coimbra Delicato. Co-orientadora: Profa. Dra. Thaís Vasconcelos Batista.
Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Programa de Pós-Graduação em Sistemas e Computação.
1. Redes de sensores sem fio – Dissertação. 2. Atuadores sem fio - Dissertação. 3. LWiSSy - Dissertação. 4. Lingua-gem específica de domínio – Dissertação. 5. Modularização – Dissertação. I. Delicato, Flávia Coimbra. II. Batista, Thaís Vasconcelos. III. Universidade Federal do Rio Grande do Norte. IV. Título.
AGRADECIMENTOS
Este ciclo que aqui se encerra é apenas mais um dos vários que pretendo
concluir durante minha vida acadêmica. Trata-se na realidade de mais uma
porta aberta após anos de dedicação a esta pesquisa.
Desde já gostaria de agradecer a Deus, pois ao longo deste ciclo fui
abençoada pela presença de várias pessoas importantes e, sem as quais, eu
não teria conseguido superar os percalços do caminho.
As minhas orientadoras Flávia e Thaís, sem as quais eu não teria sequer
começado este ciclo. Agradeço em especial a Flávia, a qual me acompanha
desde a graduação e que, mesmo sem perceber, me fez descobrir todo o
potencial que eu tenho e sempre procurou me ajudar nos momentos mais
difíceis, mesmo que a distância.
Aos meus pais, minha avó e minha irmã que nunca duvidaram da minha
capacidade e sempre me ajudaram com palavras de apoio e incentivo.
A Taniro, meu parceiro de pesquisa que desde o início me ajudou bastante e
com o qual eu espero trabalhar mais vezes.
As minhas amigas Paula, Amanda, Isolda, Tati, Renata Souza e Thaís Burity
que por muitas vezes me fizeram enxergar além dos problemas e, me arrisco a
dizer, até me carregaram diante algumas dificuldades, deixo aqui o meu imenso
“O ignorante afirma, o sábio duvida, o sensato reflete.”
RESUMO
DANTAS, Priscilla Victor. LWiSSy: Uma Linguagem Específica de Domínio para Modelagem de Sistemas de Redes de Sensores e Atuadores Sem Fio. Natal, 2012. Dissertação (Mestrado em Sistemas e Computação) – Programa de Pós-Graduação em Sistemas e Computação/Departamento de Informática e Matemática Aplicada, Universidade Federal do Rio Grande do Norte, Natal, 2012.
As Redes de Sensores e Atuadores Sem Fio (RSASF) vêm emergindo
rapidamente e têm atraído o interesse da comunidade de pesquisa e da
indústria, graças a vários fatores, dentre eles a aplicabilidade desse
tipo de rede nos mais diversos domínios de aplicações (aviação, engenharia
civil, medicina, dentre outros). Além disso, avanços na comunicação sem fio e
miniaturização dos componentes de hardware também contribuíram para a
rápida proliferação dessas redes. Apesar disso, ainda existem alguns desafios a
serem transpostos a fim de se atingir o pleno potencial de utilização das
RSASF. Dentre estes, o desenvolvimento de sistemas de RSASF aparece como
um dos mais relevantes atualmente, haja vista a quantidade de variáveis
envolvidas no processo de desenvolvimento. Atualmente, uma vasta gama de
plataformas de RSASF e diversas linguagens de programação de baixo nível
podem ser empregadas no desenvolvimento desses sistemas. Dessa forma, é
necessário que o desenvolvedor possua tanto conhecimento de baixo nível
relativo à plataforma da RSASF, quanto conhecimento específico do domínio de
cada uma das aplicações presentes no sistema. A fim de efetuar o
desacoplamento da utilização destes conhecimentos durante o processo de
desenvolvimento, de forma a facilitar tal processo, este trabalho propõe LWiSSy
(Domain Language for Wireless Sensor and Actuator Networks Systems), uma
linguagem para modelagem de sistemas para RSASF baseada no uso de DSLs
(Domain Specific Language). As DSLs, pelo fato de aumentarem o nível de
várias etapas, permitirão que ambos os especialistas envolvidos (domínio e
redes) possam contribuir diretamente durante o desenvolvimento do sistema e
de maneira mais desacoplada do que ocorre atualmente. Além dos benefícios
supracitados, LWiSSy possibilitará ainda a decomposição do sistema em
diferentes níveis de abstração, haja vista a necessidade de representar
diferentes características (estrutural e comportamental) e granulosidades
(programação em nível de rede, em nível de grupos de nós e em nível de nó) em
um único sistema.
Palavras-chave: Redes de Sensores e Atuadores Sem Fio, LWiSSy,
ABSTRACT
DANTAS, Priscilla Victor. LWiSSy: Uma Linguagem Específica de Domínio para Modelagem de Sistemas de Redes de Sensores e Atuadores Sem Fio. Natal, 2012. Dissertação (Mestrado em Sistemas e Computação) – Programa de Pós-Graduação em Sistemas e Computação/Departamento de Informática e Matemática Aplicada, Universidade Federal do Rio Grande do Norte, Natal, 2012.
The field of Wireless Sensor and Actuator Networks (WSAN) is fast increasing
and has attracted the interest of both the research community and the industry
because of several factors, such as the applicability of such networks in
different application domains (aviation, civil engineering, medicine, and others).
Moreover, advances in wireless communication and the reduction of hardware
components size also contributed for a fast spread of these networks. However,
there are still several challenges and open issues that need to be tackled in
order to achieve the full potential of WSAN usage. The development of WSAN
systems is one of the most relevant of these challenges considering the number
of variables involved in this process. Currently, a broad range of WSAN
platforms and low level programming languages are available to build WSAN
systems. Thus, developers need to deal with details of different sensor platforms
and low-level programming abstractions of sensor operational systems on one
hand, and they also need to have specific (high level) knowledge about the
distinct application domains, on the other hand. Therefore, in order to decouple
the handling of these two different levels of knowledge, making easier the
development process of WSAN systems, we propose LWiSSy (Domain Language
for Wireless Sensor and Actuator Networks Systems), a domain specific
language (DSL) for WSAN.
The use of DSLs raises the abstraction level during the programming of
systems and modularizes the system building in several steps. Thus, LWiSSy
allows the domain experts to directly contribute in the
and network experts to program sensor nodes to meet application requirements
without having specific knowledge on the application domain. Additionally,
LWiSSy enables the system decomposition in different levels of abstraction
according to structural and behavioral features and granularities (network,
node group and single node level programming).
L
ISTA DE FIGURAS
FIGURA 2-1ATUAÇÃO DE UM NÓ SINK NUMA RSASFS. ... 28
FIGURA 2-2COMPONENTES DO HARDWARE DE UM NÓ SENSOR. ... 30
FIGURA 2-3PILHA DE PROTOCOLOS DAS RSSFS... 34
FIGURA 2-4HARDWARE CONSTITUINTE DO DISPOSITIVO SUN SPOT. ... 40
FIGURA 2-5MICAZ MOTE. ... 43
FIGURA 2-6DIVERSAS VERSÕES DE ARDUÍNO... 45
FIGURA 2-7XBEE SHIELD. ... 46
FIGURA 2-8ARTEFATOS ENVOLVIDOS NA ABORDAGEM MDA ... 52
FIGURA 2-9OS TRÊS PASSOS PRINCIPAIS NO PROCESSO MDA. ... 54
FIGURA 2-10TRANSFORMAÇÃO PIM PARA PSM... 54
FIGURA 4-1METAMODELO DA DSL INTERMEDIÁRIA COM DESTAQUE PARA AS DIFERENÇAS ENTRE ELA E A PROPOSTA EM [LOSILLA, 2007]. ... 64
FIGURA 4-3MODELO GRÁFICO QUE REPRESENTA A VISÃO ESTRUTURAL EM LWISSY. ... 70
FIGURA 4-4MODELO GRÁFICO QUE REPRESENTA A VISÃO COMPORTAMENTAL EM LWISSY. ... 74
FIGURA 4-5MODELO GRÁFICO QUE REPRESENTA A VISÃO DE REFINAMENTO EM LWISSY. ... 79
FIGURA 4-6CONSTRUÇÃO DA INFRAESTRUTURA MDA UTILIZADA. ... 80
FIGURA 4-7ADAPTAÇÃO DO PROCESSO DE DESENVOLVIMENTO PROPOSTO EM [RODRIGUES,2011]. ... 82
FIGURA 4-8VISÃO ESTRUTURAL DO SISTEMA FIRE DETECTION SYSTEM ESPECIFICADA PELO ESPECIALISTA DE DOMÍNIO. ... 84
FIGURA 4-9VISÃO COMPORTAMENTAL DA APLICAÇÃO TEMPERATURE MONITORING ESPECIFICADA PELO ESPECIALISTA DE DOMÍNIO. .. 85
FIGURA 4-10VISÃO COMPORTAMENTAL DA APLICAÇÃO TRIGGER ALARM ESPECIFICADA PELO ESPECIALISTA DE DOMÍNIO. ... 86
FIGURA 4-11VISÃO DE REFINAMENTO DO SISTEMA FIRE DETECTION SYSTEM ESPECIFICADA PELO ESPECIALISTA DE REDES. ... 87
FIGURA 5-1MODELAGEM DA APLICAÇÃO DE SHM COM A DSL INTERMEDIÁRIA. ... 91
FIGURA 5-2MODELAGEM DA APLICAÇÃO BURNING FOREST COM A DSL INTERMEDIÁRIA. ... 95
FIGURA 5-3MODELAGEM ESTRUTURAL DO SISTEMA ACCIDENTAL FALL DETECTION SYSTEM UTILIZANDO A DSLLWISSY. ... 99
FIGURA 5-4MODELAGEM COMPORTAMENTAL DA APLICAÇÃO POSITION SENSING UTILIZANDO A DSLLWISSY. ... 100
FIGURA 5-5MODELAGEM COMPORTAMENTAL DA APLICAÇÃO MOVEMENT SENSING UTILIZANDO A DSLLWISSY. ... 101
FIGURA 5-6MODELAGEM COMPORTAMENTAL DA APLICAÇÃO VIDEO CHECK UTILIZANDO A DSLLWISSY. ... 101
FIGURA 5-7MODELAGEM COMPORTAMENTAL DA APLICAÇÃO FALL CHECK UTILIZANDO A DSLLWISSY. ... 102
FIGURA 5-8MODELAGEM DE REFINAMENTO DO SISTEMA ACCIDENT FALL DETECTION SYSTEM UTILIZANDO A DSLLWISSY. ... 103
FIGURA 5-9MODELAGEM DO SISTEMA ACCIDENTAL FALL DETECTION UTILIZANDO A DSL PROPOSTA POR [LOSILLA,2007]. ... 104
FIGURA 5-11MODELAGEM EM NÍVEL DE GRUPOS DE NÓS DO SISTEMA ACCIDENTAL FALL DETECTION SYSTEM UTILIZANDO A DSL PROPOSTA POR [SHIMIZU,2011]. ... 107
Lista de tabelas
TABELA 2-1CARACTERIZAÇÃO DAS RSASFS SEGUNDO A CONFIGURAÇÃO. ... 32
TABELA 2-2COMPARAÇÃO DE CÓDIGO BLOQUEANTE E DIVIDIDO EM FASES. ... 45
TABELA 3-1SUMARIZAÇÃO DAS CARACTERÍSTICAS DAS DSLS DISCUTIDAS NESTE CAPÍTULO E LWISSY. ... 62
TABELA 5-1RESULTADO GERAL DA ANÁLISE COMPARATIVA ENTRE AS DSLS. ... 109
Lista de abreviaturas e siglas
ADC - Analog to Digital Converter
APT – Automatically Programmed Tool
AST - Abstract Syntax Tree
BNF - Backus-Naur Form
CIM - Computation Independent Model
CLDC - Connected Limited Device Configuration
CPU – Central Process Unit
DC – Direct Current
DSL – Domain Specific Language
EMF – Eclipse Modeling Framework
ESRT - Event-to-Sink Reliable Transfer
GEF - Graphical Editing Framework
GMF – Graphical Modeling Framework
IDE – Integrated Development Environment
IEEE – Institute of Electrical and Electronics Engineers
J2ME – Java Micro Edition
LEACH – Low-Energy Adaptive Clustering Hierarchy
LQRP - Link Quality Routing Protocol
LWiSSy – Domain Language for Wireless Sensor Networks Systems
M2M – Model to Model
M2T – Model to Text
MDA – Model Driven Architecture
MDD – Model Driven Development
MIDP – Mobile Information Device Profile
nesC – network embedded systems C
OCL – Object Constraint Language
OMG - Object Management Group
PC – Personal Computer
PDM - Platform Definition Model
PIM – Platform Independent Model
PROC – Proactive Routing with Coordination
PSFQ – Pump Slowly, Fetch Quickly
PSM – Platform Specific Model
QoS – Quality of Service
RMST – Reliable Multi-Segment Transport
RSSF – Redes de Sensores e Atuadores Sem Fio
RSSF - Redes de Sensores Sem Fio
SHM – Structural Health Monitoring
SMP - Sensor Management Protocol
SO – Sistema Operacional
SQDDP - Sensor Query and Data Dissemination Protocol
Sun SPOT - Sun Small Programmable Object Technology
TADAP - Task Assignment and. Data Advertisement Protocol
tinyOS - Tiny Operational System
USA – United States of America
USB – Universal Serial Bus
VM – Virtual Machine
XMI – XML Metadata Interchange
Sumário
Lista de tabelas ... 13
Lista de abreviaturas e siglas ... 14
Sumário ... 17
1. Introdução... 19
1.1. Motivação ... 21
1.2. Objetivos ... 25
1.3. Organização do documento ... 26
2. Conceitos Básicos ... 27
2.1. Redes de Sensores e Atuadores Sem Fio... 27
2.1.1. Arquitetura ... 29
2.1.2. Modelos de comunicação e entrega de dados em RSASFs ... 37
2.1.3. Qualidade de serviço (QoS) em RSASFs ... 38
2.2. Plataformas para RSASF ... 39
2.2.1. Sun SPOT ... 39
2.2.2. TinyOS ... 42
2.2.3. Arduíno ... 45
2.3. Linguagem Específica de Domínio ... 47
2.3.1. Vantagens e Desvantagens de DSLs ... 49
2.4. Ferramentas de Modelagem ... 50
2.5. Desenvolvimento Dirigido a Modelos ... 51
2.5.1. Modelos ... 52
2.5.2. Transformações ... 53
3. Trabalhos Relacionados ... 56
4.1. DSL para RSASF: Primeira versão ... 63
4.2. LWiSSy ... 68
4.2.1. Visão estrutural ... 69
4.2.2. Visão comportamental ... 73
4.2.3. Visão de refinamento ... 78
4.3. Descrição da Infraestrutura MDA ... 80
4.4. Desenvolvimento de sistemas utilizando LWiSSy ... 81
4.4.1. Exemplo ilustrativo ... 83
5. Avaliação ... 88
5.1. Análise da DSL Intermediária Proposta ... 88
5.1.1. Prova de conceito ... 88
5.1.2. Cenários de mudança ... 92
5.2. LWiSSy ... 96
5.2.1. Análise Comparativa ... 96
5.2.2. Experimento Controlado ... 110
6. Conclusões e Trabalhos Futuros ... 118
Referências ... 120
19
1.
Introdução
Redes de Sensores e Atuadores Sem Fio (RSASF) constituem atualmente uma
área de pesquisa bastante promissora devido, em parte, aos grandes avanços
recentes na microeletrônica e nas tecnologias de redes sem fio, e em parte à sua
potencial aplicação em diferentes domínios, como por exemplo, militar,
monitoramento ambiental e de habitat, controle e monitoramento industrial,
monitoramento de estruturas civis, segurança, monitoramento da saúde de
pacientes, dentre inúmeras outras [WANG, 2008].
Uma RSASF é composta por dispositivos, geralmente alimentados por
baterias, que incorporam diversas funcionalidades (processamento,
sensoriamento, comunicação sem fio, atuação, etc.) e são espacialmente
distribuídos em uma região que se deseja monitorar [SADILEK, 2007]. Sistemas
de RSASFs são compostos por uma ou mais aplicações que observam o mundo
físico e obtêm informações úteis a partir dele. Logo após os dados serem obtidos
pelos elementos de sensoriamento, eles são processados e analisados para que
decisões sejam tomadas com base neles e, caso necessário, operações concretas
sejam executadas no ambiente monitorado [LOSILLA, 2007] através do uso dos
elementos atuadores. Por exemplo, em uma aplicação de irrigação de plantio
presente em um sistema de RSASF, um sensor pode coletar variáveis
ambientais diversas (como umidade e temperatura) e, a partir dos dados
coletados, enviar a informação para os nós sensores vizinhos (aqueles que estão
espacialmente próximos), de forma a determinar se certa área do plantio
necessita ou não de irrigação. Caso a irrigação seja necessária, um nó atuador
pode acionar as mangueiras para que estas efetuem a irrigação da área em
questão.
A primeira geração de sistemas de RSASFs adotava uma abordagem de
projeto “específico da aplicação” [HEINZELMAN, 2002], tendo como objetivo
20
nós. Nesse contexto, a maioria dos sistemas, os quais eram compostos por
apenas uma aplicação, era desenvolvido como software monolítico construído
para uma dada plataforma de sensores alvo e um dado sistema operacional
(SO). Os desenvolvedores de sistemas precisavam conhecer vários detalhes da
operação da rede e dos protocolos utilizados e construir seus programas ou
usando as abstrações de baixo nível providas pelo SO dos sensores, ou
diretamente sobre o hardware. Os sistemas eram, portanto, desenvolvidos em
linguagem de programação de baixo nível, determinadas a partir da escolha da
plataforma de sensores alvo, para que então fossem especificados os aspectos
relativos ao domínio do problema. A falta de uma metodologia formal ou
sistemática para prover suporte a todo o ciclo de vida de desenvolvimento
desses sistemas resultava em projetos dependentes de plataforma e código
difícil de manter, alterar e reusar.
Como exemplo do cenário descrito acima, pode-se imaginar a situação na
qual uma empresa deseja desenvolver um software para o monitoramento de
estruturas de plataformas de petróleo. Caso a empresa decida contratar uma
equipe de programadores especializados em programação de RSASFs, estes
encontrarão diversas barreiras no desenvolvimento do sistema, as quais estão
diretamente relacionadas com o conhecimento do domínio do problema (ou
seja, a área da engenharia civil centrada no monitoramento de estruturas), tais
como conhecimentos sobre a estrutura e o tipo da plataforma, fatores que
afetam a saúde (estrutural) da plataforma, forma de distribuição dos sensores e
atuadores para obter as melhores medições, além de toda a parte relativa aos
modelos matemáticos necessários para executar na rede. Por outro lado, se a
empresa contratar apenas especialistas do domínio de monitoramento de
estruturas, estes encontrarão dificuldades na implementação dos programas, já
que engenheiros civis em geral constroem suas aplicações usando a linguagem
C ou MATLAB, e não possuem conhecimento de programação de mais baixo
21
Nesse contexto, é possível perceber que o desenvolvimento de sistemas para
RSASFs impõe vários desafios para o programador, requerendo habilidades e
conhecimentos distintos. Por um lado, existe a necessidade de conhecimento
específico de plataformas de RSASFs e de lidar com um baixo nível de
abstração na construção dos sistemas, e por outro, conhecimento específico
sobre o domínio da aplicação a ser executada na rede, que pode envolver as
mais diversas áreas do conhecimento humano. Claramente, há diferentes níveis
de abstração envolvidos no desenvolvimento de sistemas para RSASF, sendo
que especialistas em domínios desejam preferencialmente lidar com abstrações
de mais alto nível, enquanto que especialistas em redes podem ser expostos a
lidar com abstrações de mais baixo nível. Adicionalmente, há várias decisões de
projeto na área de RSASFs que envolvem conhecimento tanto de alto nível
(sistema e aplicações) quanto de baixo nível (protocolos e configurações da
rede), já que a existência de otimizações específicas do sistema e de cada uma
das aplicações comprovadamente contribuem para a eficiência em energia
global da rede [YU, 2004]. Nota-se ainda que, com as abordagens tradicionais
de programação para RSASF, nenhum tipo de reuso (conhecimento,
programação, domínio) é facilitado, dificultando assim qualquer mudança de
plataforma visto que todo o sistema terá que ser refeito do zero. Por fim, é
importante ressaltar que o custo com a manutenção do sistema é elevado, uma
vez que as linguagens de programação utilizadas possuem baixo nível de
abstração.
1.1.
Motivação
Há atualmente uma grande diversidade de plataformas que oferecem suporte ao
desenvolvimento e execução de sistemas para RSASFs, cada uma com seus
próprios requisitos, ambientes e ferramentas associados. Por exemplo, os
sensores da família MICA [Crossbow, 2012] utilizam o sistema operacional
tinyOS [TinyOS, 2012], o qual disponibiliza para os desenvolvedores a
22
memória de um sistema de RSASF) [nesC, 2012]. Os sensores Sun SPOT [Sun
SPOT, 2012] utilizam a linguagem Java, versão MicroEdition, para
desenvolvimento de sistemas, os quais executam diretamente sobre o hardware
sem necessidade de sistema operacional, haja vista a utilização da máquina
virtual da plataforma J2ME, Squawk Virtual Machine. Já os sensores da
plataforma open-source Arduíno [Projeto Arduíno, 2012] utilizam uma
linguagem própria baseada em C/C++.
O desenvolvimento de aplicações para RSASFs não é uma tarefa fácil, uma
vez que tais redes apresentam requisitos específicos, como limitações críticas
dos recursos dos nós, abstrações de baixo nível disponíveis para construir
programas e a necessidade de gerenciar, de modo eficiente, a comunicação e a
coordenação dos nós (que muitas vezes chegam à ordem de centenas ou até
milhares de nós em uma rede). Além de demandar requisitos específicos, as
RSASFs também se caracterizam por uma enorme heterogeneidade com
respeito ao software, as tecnologias de rádios empregadas, as capacidades dos
nós, aos protocolos de redes, as estratégias de segurança que podem ser
utilizadas, aos mecanismos de localização e de mobilidade, dentre outros. Em
adição, há uma grande heterogeneidade nos requisitos das aplicações já que,
como visto, RSASFs podem ser úteis para uma ampla gama de domínios.
Diferentemente dos sistemas de RSASFs de primeira geração, os quais foram
citados anteriormente, o projeto de redes atuais e futuras tem seguido novas
tendências e sofrido importantes mudanças. Dentre elas, há uma tendência em
projetar sistemas de RSASFs de larga escala para diferentes aplicações, as
quais podem rodar concomitantemente ou não nos nós instalados. Ou seja, a
abordagem de projetar redes específicas para uma única aplicação alvo tem
sido substituída pela construção de redes de “propósito geral”, onde a
infraestrutura de sensoriamento é compartilhada por múltiplas aplicações
[BHATTACHARYA, 2010]. Esta nova geração de sistemas para RSASF, que tem
sido denominada de Redes de Sensores Compartilhadas (Shared Sensor
23
multifuncionais, oferece vantagens em termos de custo e flexibilidade, uma vez
que os nós sensores são compartilhados entre as diversas aplicações que
compõem o sistema. Além disso, nessa nova abordagem, os nós dessas redes
devem ser programados para cada uma das aplicações, preferencialmente
através de interfaces de alto nível que abstraiam as características das
plataformas subjacentes e permitam aos desenvolvedores representarem os
requisitos de seus domínios de aplicações utilizando linguagens com as quais
estejam mais familiarizados. Nesses cenários emergentes, é indesejável (e
improvável) que, em tempo de projeto, os desenvolvedores já saibam as
características das plataformas de RSSF nas quais suas aplicações irão
executar.
Ao mesmo tempo em que é importante possibilitar a participação dos
especialistas de domínio durante o processo de desenvolvimento do sistema e
desacoplar o sistema da infraestrutura de rede subjacente na qual ele irá
executar, sendo, portanto necessário prover interfaces de alto nível de
abstração, também é essencial haver a possibilidade de otimização
(refinamento) do sistema de RSASF como um todo e de cada uma das
aplicações geradas, haja vista as limitações de recursos existentes neste tipo de
rede. Tal refinamento muitas vezes requer a manipulação de funcionalidades de
baixo nível, como por exemplo, o modelo de entrega de dados ou a topologia de
rede utilizada, o que gera um tradeoff entre o alto grau de abstração desejado
por especialistas de domínio e o potencial de otimização requerido pelos
especialistas de redes. Adicionalmente, a programação de uma RSASF dá-se em
diferentes granulosidades, podendo envolver desde a especificação de um
processo de alto nível (macro-programação), descrevendo toda a infraestrutura
do sistema, até a especificação do processamento individual a ser realizado
internamente por cada nó da rede (micro-programação), passando pela
programação de grupos de nós, ou seja, a descrição de cada uma das
aplicações presentes no sistema (em termos do fluxo de dados ou de controle
24
identificar diferentes níveis de abstração em termos dos requisitos dos usuários
envolvidos e da granulosidade da programação, com impacto direto na
capacidade de otimização provida pelos diferentes níveis de abstração.
Neste trabalho argumenta-se que a adoção de uma DSL (Domain Specific
Language) durante este processo é uma solução que permite a programação de
sistemas para RSASF em diferentes níveis de abstração, de acordo com o
especialista envolvido, harmonizando a lacuna existente entre os
conhecimentos de nível específico de cada uma das aplicações e de nível de
plataformas de RSASFs, tirando o melhor proveito de ambos, e que mantém um
alto nível de otimização destas aplicações.
Nesse trabalho propomos a linguagem LWiSSy (Domain Language for
Wireless Sensor Networks Systems). Além de promover os benefícios supramencionados, os elementos de LWiSSy permitem a especificação de
sistemas de modo a, por um lado, esconder detalhes de implementação quando
desejado e, por outro lado, expor tais detalhes quando necessário (com o intuito
de melhorar o desempenho da rede).
Com o intuito de gerar, de maneira rápida, eficiente e automática, o
código-fonte dos sistemas modelados com LWiSSy, este trabalho utilizará a abordagem
MDD (Model Driven Development) proposta em [RODRIGUES, 2011]. No MDD o
sistema é construído a partir de modelos, os quais são mapeados de um nível
de abstração para outro através de definições de transformações. Os modelos
são gerados com base em metamodelos, os quais são modelos que definem a
estrutura e regras de formação da linguagem na qual os modelos serão
expressos.
No decorrer do trabalho será demonstrado como o uso de linguagens
específicas de domínio pode aumentar o nível de abstração durante a
modelagem de sistemas, aumentar o reuso de conhecimento de nível do
especialista de domínio, facilitar o desenvolvimento de sistemas multifuncionais
25
compõem. Em caso de mudança de plataforma-alvo, os modelos gerados podem
ser reusados para a remodelagem do sistema desde que metamodelos e
programas de transformação que definem a nova plataforma-alvo sejam
construídos.
1.2.
Objetivos
O objetivo geral deste trabalho é propor a linguagem LWiSSy, uma linguagem
específica para o domínio de RSASF que será gerada com base na UML (Unified
Modeling Language). LWiSSy possibilitará: (i) a participação direta do
especialista de domínio durante o ciclo de desenvolvimento de sistemas para
RSASF; (ii) a decomposição do sistema em diferentes níveis de abstração, haja
vista a necessidade de representar diferentes características (estrutural e
comportamental) e granulosidades (programação em nível de rede, em nível de
grupos de nós e em nível de nó) em um único sistema. O metamodelo que
define a linguagem será especificado com expressividade suficiente para
atender uma ampla gama de domínios, levando sempre em consideração a
legibilidade, para que não seja exigido, do especialista de domínio, um profundo
conhecimento a respeito de RSASF.
Com a utilização da infraestrutura MDA (Model Driven Architecture) proposta
em [RODRIGUES, 2011] não será necessário especificar os metamodelos das
plataformas que serão utilizadas (Sun SPOT e tinyOS), nem definir os
respectivos programas de transformação de modelo para texto (M2T), uma vez
que estes artefatos já foram desenvolvidos. Os objetivos secundários deste
trabalho:
Definição dos programas de transformação entre modelos (M2M - Model
to Model), para que seja possível efetuar as transformações necessárias
26
Análise de LWiSSy por meio de um experimento controlado com o objetivo
de avaliar se a adoção da linguagem afeta no entendimento de sistemas
de RSASF;
Análise comparativa entre LWiSSy e outras duas DSLs presentes na
literatura ([LOSILLA, 2007] e [SHIMIZU, 2011]) a fim de avaliar a
expressividade da linguagem proposta neste trabalho e seus benefícios
com relação a outras propostas existentes.
1.3.
Organização do documento
O restante deste trabalho está estruturado em cinco capítulos. O Capítulo 2
apresenta os conceitos básicos necessários para o entendimento deste trabalho.
O Capítulo 3 discorre sobre alguns trabalhos relacionados presentes na
literatura. O Capítulo 4 expõe, em detalhes, LWiSSy, a linguagem proposta, e a
infraestrutura MDA utilizada. O processo de avaliação do trabalho é discutido
no Capítulo 5. Por fim, o Capítulo 6 apresenta as conclusões e os trabalhos
27
2.
Conceitos Básicos
Este Capítulo apresenta alguns conceitos básicos que serão úteis para a
compreensão do trabalho. A Seção 2.1 abrange a área de Redes de Sensores e
Atuadores Sem Fio, contendo descrições básicas como arquitetura,
funcionamento e exemplos de aplicações. A Seção 2.2 faz uma breve descrição
acerca das plataformas para redes de sensores e atuadores sem fio que serão
utilizadas. O conceito de Linguagem Específica de Domínio (Domain Specific
Language - DSL) será discutido na Seção 2.3. A Seção 2.4 apresenta as
ferramentas de modelagem que foram utilizadas durante o desenvolvimento de
LWiSSy. Por fim, a Seção 2.5 discorre sobre a abordagem MDA utilizada no
presente trabalho durante o processo de desenvolvimento de sistemas para
RSASF.
2.1.
Redes de Sensores e Atuadores Sem Fio
Uma RSASF é uma Rede Sem Fio do tipo ad hoc, composta por dezenas a
milhares de dispositivos eletrônicos de baixo custo, que tem como principal
objetivo realizar tarefas de sensoriamento de forma distribuída em benefício de
aplicações clientes e executar ações no ambiente monitorado. Elas diferem das
redes de computadores tradicionais por vários motivos, dentre os quais
podemos citar: não utilização de meios físicos de comunicação, baixos recursos
de memória e processador, quantidade limitada de energia, entre outros.
Embora um nó sensor possua pouca capacidade computacional e de
energia, um esforço colaborativo entre vários nós sensores proporciona a
realização de tarefas com uma eficiência muito maior. Para que isso seja
possível é necessário distribuir os sensores no ambiente de forma que as
propriedades essenciais sejam preservadas. Tal distribuição pode ser feita de
28
Os nós sensores coletam as informações do ambiente (temperatura, pressão,
etc.), comunicam-se uns com os outros, fazendo um processamento local antes,
se necessário, e enviam os dados coletados para os nós sorvedouros (sink node),
que, por sua vez, coletam as informações enviadas pelos nós sensores e as
entrega ao usuário ou a aplicação final. O sorvedouro, diferentemente dos
demais nós da rede, geralmente possui maior poder computacional, não tem
restrição de energia e localiza-se geograficamente distante da área onde os
sensores estão instalados. Esses nós funcionam como uma interface entre a
aplicação e a rede. A Figura 2-1 exibe um exemplo da atuação de um nó
sorvedouro numa RSASF. O nó E coleta um determinado fenômeno e
comunica-se com seus vizinhos, a fim de levar a informação até o Ponto de
Acesso.
Figura 2-1 Atuação de um nó sink numa RSASFs.
Nós sensores podem ser distribuídos em diversos locais, inclusive de difícil
acesso. Assim sendo, é fundamental que a rede consiga operar durante longos
períodos de tempo sem a intervenção humana. Além disso, os nós são
alimentados, no geral, por baterias não recarregáveis, portanto o tempo de vida
operacional da RSASF é severamente limitado pela capacidade da bateria dos
seus nós. Dessa maneira, todas as etapas de projeto e funcionamento de
RSASFs devem levar em conta o consumo de energia e procurar otimizá-lo.
RSASFs em geral possuem uma alta densidade de nós, o que faz com que
29
Como a maior fonte de consumo de energia nos sensores é a transmissão de
dados, grande parte das pesquisas visam propor soluções para obter e rotear os
dados de forma eficiente em energia, a fim de estender o tempo de vida global
da rede. No entanto, independente da solução escolhida, deve haver um
equilíbrio entre o consumo de energia e a qualidade global do dado entregue à
aplicação.
Por sua vez, os nós atuadores, os quais operam em resposta a situações
interpretadas pelos nós sensores, possuem a função de modificar valores do
meio a fim de corrigir falhas e controlar o objeto monitorado. As redes
compostas de atuadores apresentam um grande interesse em diferentes áreas
como a área médica, onde sistemas embutidos podem liberar medicamentos de
acordo com as necessidades do paciente [LOUREIRO, 2003].
Além dos fatores já mencionados, RSASF possuem uma estrutura topológica
altamente dinâmica. Dependendo da aplicação, nós podem se movimentar,
podem ser retirados da rede ao terem seus recursos esgotados, novos nós
podem ser adicionados ou podem ser temporariamente desligados por medida
de economia de energia, alterando assim a topologia ativa da rede. As condições
ambientais onde a rede está instalada também podem sofrer alterações. Logo,
as RSASFs devem possuir um elevado grau de auto-organização e adaptação.
A maioria dos protocolos de roteamento de dados baseia-se na comunicação
multi-hop de curto alcance e adotam algum mecanismo de agregação de dados
dentro da rede, diminuindo assim o número de mensagens transmitidas
através dos sensores.
2.1.1.
Arquitetura
Redes de sensores e atuadores sem fio são compostas por três componentes
organizacionais, são eles: infraestrutura, pilha de protocolos e aplicação. Esta
30
A infraestrutura de uma RSASF consiste nos nós da rede (características
físicas e capacidades) e no seu estado de instalação no ambiente.
O hardware de um nó sensor é composto tipicamente por quatro
subsistemas: sensoriamento, processamento, comunicação e energia (Figura
2-2).
Figura 2-2 Componentes do hardware de um nó sensor.
O subsistema de sensoriamento é composto pelos dispositivos de
sensoriamento e pelo conversor de sinal analógico para digital (ADC). Os
dispositivos de sensoriamento têm capacidade de sensoriar diversos tipos de
condições ambientais, como: temperatura, umidade, movimento veicular, níveis
de ruído, níveis de stress mecânico de objetos, e características como
velocidade, direção e tamanho de um objeto. Um nó sensor pode conter uma ou
mais unidades de sensoriamento. Sua função é coletar, eventualmente agregar,
e transmitir seus próprios dados e os dos seus vizinhos para os nós
sorvedouros.
Já o subsistema de processamento tem o objetivo de controlar os sensores,
31
dados e gerenciar os procedimentos necessários para que haja colaboração
entre os nós.
O subsistema de comunicação é composto, geralmente, por um dispositivo
de rádio frequência. No entanto, também é possível utilizar um dispositivo ótico
ativo ou passivo. O subsistema de comunicação que utiliza rádio frequência é
composto por um transceiver, uma antena e um conjunto de componentes
discretos para configurar as características da camada física. O qual pode
operar em três modos: recepção, transmissão e desligado (power-off).
Por fim, o subsistema de energia é composto por uma bateria e um
conversor DC-DC. Existem vários tipos de bateria que podem ser utilizadas em
um nó sensor e cada uma possui suas particularidades. Quanto ao conversor
DC-DC, ele recebe uma voltagem DC de entrada e produz uma voltagem DC de
saída que, no geral, é diferente da primeira. Ele é responsável por fornecer uma
tensão constante para o sensor e o seu fator de eficiência determina o tempo de
vida da bateria.
Dependendo da aplicação outros subsistemas podem existir, como por
exemplo, o de localização (para determinar com precisão a posição de um nó) e
o de movimento (para mover o nó para um local que permita a realização de
uma tarefa).
Além dos subsistemas citados acima, o projeto de um nó sensor pode incluir
um sistema operacional rudimentar que gerencia a operação do nó sensor da
forma mais eficiente possível. Um exemplo de sistema operacional desenvolvido
especialmente para sensores, e utilizado em grande parte do hardware hoje
existente, é o TinyOS. Outra plataforma com destaque é o Sun SPOT devido ao
uso da linguagem Java ME.
O estado de instalação da rede no ambiente diz respeito à localização dos
nós sensores no espaço físico, à densidade da rede e a possíveis deslocamentos
32
podem ser classificadas segundo a sua configuração conforme mostrado na
Tabela 2-1.
Configuração
Composição
Homogênea Rede composta de nós que apresentam a mesma
capacidade de hardware. Eventualmente os nós podem executar software diferente.
Heterogênea Rede composta por nós com diferentes
capacidades de hardware.
Organização
Hierárquica RSASF em que os nós estão organizados em
grupos (clusters). Cada grupo terá um líder (cluster-head) que poderá ser eleito pelos nós comuns. Os grupos podem organizar hierarquias entre si.
Plana Rede em que os nós não estão organizados em
grupos.
Mobilidade
Estacionária Todos os nós sensores permanecem no local onde foram depositados durante todo o tempo de vida da rede.
Móvel Rede em que os nós sensores podem ser
deslocados do local onde inicialmente foram depositados.
Densidade
Balanceada Rede que apresenta uma concentração e
distribuição de nós por unidade de área considerada ideal segundo a função objetivo da rede.
Densa Rede que apresenta uma alta concentração de
nós por unidade de área.
Esparsa Rede que apresenta uma baixa concentração de
nós por unidade de área.
Distribuição
Irregular Rede que apresenta uma distribuição não
uniforme dos nós na área monitorada.
Regular Rede que apresenta uma distribuição uniforme de
nós sobre a área monitorada.
Tabela 2-1 Caracterização das RSASFs segundo a configuração.
Com relação aos modelos de entrega de dados, as RSASFs podem ser
classificadas como periódicas, contínuas, reativas ou dirigidas a eventos. Nas
redes periódicas, os nós sensores coletam os dados em intervalos de tempos
pré-determinados. Um exemplo são aplicações de monitoramento de
temperatura. A temperatura não muda bruscamente a todo o momento.
33
sensores. Quando a coleta de dados se dá de maneira contínua, os nós
sensores devem coletar os dados continuamente. Um exemplo são as aplicações
que monitoram pacientes cardíacos. Tais aplicações devem capturar os dados
constantemente a fim de garantir a integridade física do paciente. Nas redes
reativas, os nós sensores coletam os dados apenas quando o observador
solicita-os. As aplicações militares que monitoram as forças presentes em um
campo de batalha podem ser citadas como este tipo de rede. Neste tipo de aplicação o observador pode solicitar “manualmente” que ocorra uma atualização dos dados coletados. Já nas aplicações dirigidas a eventos, os nós
sensores coletam os dados, apenas, caso algum evento de interesse do
observador ocorra. Aplicações que monitoram queimadas podem exemplificar
este tipo de sensoriamento. Nelas, o observador pode solicitar que ele seja
informado caso a temperatura na região seja superior a um determinado valor.
Por fim, é importante ressaltar que diversas formas de sensoriamento podem
ser combinadas em uma única aplicação. Como exemplo é possível citar a
mesma aplicação militar descrita anteriormente. Afinal, é notável que tal
aplicação alcançará resultados melhores caso ela seja reativa e dirigida a
eventos, evitando assim surpresas desagradáveis para as tropas no campo de
batalha.
Quanto a pilha de protocolos utilizada em uma RSASF (Figura 2-3), esta
consiste em cinco camadas horizontais (aplicação, transporte, rede, enlace de
dados e física) e três planos verticais (gerenciamento de energia, gerenciamento
de tarefas e gerenciamento de mobilidade).
A camada de aplicação refere-se aos protocolos de nível de aplicação que são
de uso comum para as diferentes aplicações. Diferentes tipos de software de
aplicação, dependendo da tarefa de sensoriamento, podem ser construídos e
utilizados para interação com a RSASF. No entanto, alguns autores, como
[AKYILDIZ, 2002], afirmam que os protocolos para a camada de aplicação ainda
são poucos explorados. Dessa maneira, alguns autores sugerem três protocolos
34
(SMP), o qual tem por finalidade tornar o hardware e o software das camadas
mais baixas transparentes para as aplicações que gerenciam a rede de
sensores; protocolo de anúncio de dados e designação de tarefas (TADAP), que
visa fornecer à aplicação cliente da rede interfaces para conduzir a
disseminação de seus interesses ou para receber anúncios de dados enviados
pelos sensores; e protocolo de consulta e disseminação de dados (SQDDP), que
fornece, para as aplicações, interfaces para a emissão de suas consultas e para
a coleta das respostas que chegam da rede.
Figura 2-3 Pilha de protocolos das RSSFs.
A camada de transporte é responsável pela manutenção do fluxo de dados
entre a origem e o destino, caso a aplicação necessite. Em geral, o fluxo da
informação disseminada em uma RSASF pode ser classificado como: flooding
(nós sensores fazem broadcast de suas informações para seus vizinhos que
fazem broadcast desses dados para outros até que o ponto de acesso seja
alcançado), unicast (nós sensores podem se comunicar diretamente com o
ponto de acesso usando protocolos de roteamento multi-hop), ou multicast (nós
35
membros do grupo). Uma grande vantagem da utilização do flooding ou do
broadcast trata-se da ausência de um protocolo complexo da camada de rede
para efetuar roteamento e gerenciamento de localização dos nós.
O objetivo da camada de rede é tratar do roteamento dos dados. Exemplos
de protocolos de roteamento: LQRP (Link Quality Routing Protocol), Tiny
Beaconing, LEACH, PROC, entre outros. Já a camada de enlace tem como
objetivo assegurar conexões confiáveis em uma rede de comunicação.
A camada física abrange as técnicas de transmissão, recepção, e modulação
utilizadas na rede. Como a comunicação entre os nós é responsável pela maior
parte do consumo de energia em uma RSASF, a eficiência em termos de energia
assume uma importância significativa durante o projeto da camada física.
Os três planos de gerenciamento permitem a coordenação dos nós sensores
quanto à realização das tarefas de sensoriamento e quanto ao consumo global
de energia da rede. Eles são necessários para que os nós sensores possam
trabalhar juntos de forma eficiente em termos de energia, roteamento de dados
em redes com sensores móveis e compartilhamento de recursos entre si.
O plano de gerenciamento de energia permite gerenciar a forma como a
energia é gasta pelos nós sensores. Por exemplo, um nó sensor pode desligar
seu receptor após receber uma mensagem de um de seus vizinhos, evitando a
recepção de mensagens duplicadas. Um sensor com baixo nível de energia pode
decidir não participar mais do roteamento de mensagens e reservar o restante
de sua energia para o sensoriamento. Com esse intuito, o sensor deve avisar
seus vizinhos de sua decisão, enviando-lhes essa informação em broadcast.
Todas estas decisões são responsabilidades do plano de gerenciamento de
energia.
O plano de gerenciamento de tarefas permite balancear e escalonar as
tarefas de sensoriamento de uma região específica. Não é necessário que todos
os sensores localizados na região alvo definida pela aplicação estejam ativos ou
36
alguns nós participam mais na realização da tarefa do que outros, dependendo
do seu nível de energia ou do grau com que possam contribuir para a tarefa.
Sem este plano de gerenciamento, cada nó sensor irá apenas trabalhar
individualmente. Do ponto de vista de toda a rede, ela será mais eficiente
somente se cada nó puder colaborar um com o outro. Desta forma a vida útil de
uma rede de sensores e atuadores sem fio pode ser prolongada.
Já o plano de gerenciamento de mobilidade permite detectar e registrar o
movimento dos nós, de modo a manter sempre uma rota para o usuário e a
guardar, para cada nó, a informação sobre quem são seus vizinhos.
Com relação às aplicações é possível afirmar que diversas aplicações
utilizando RSASF vêm sendo desenvolvidas. Estas aplicações podem ser
homogêneas ou heterogêneas quanto aos tipos, dimensões e funcionalidades
dos nós utilizados. Dessa maneira, o uso de RSASFs habilita uma ampla gama
de aplicações potenciais, pertencentes aos mais variados ramos do
conhecimento humano. A seguir algumas áreas, onde RSASF podem ser
empregadas, são exemplificadas:
Militar: Monitoramento de forças, equipamentos e munições amigas,
vigilância do campo de batalha, reconhecimento de forças e terrenos
inimigos, detecção e reconhecimento de ataques biológicos, químicos e
nucleares, sistemas inteligentes de mira, dentre outros. Como RSASF são
compostas por centenas a milhares de nós de baixo custo e descartáveis,
a destruição destes por ações inimigas não prejudicará tanto a operação
militar quanto a destruição de um sensor tradicional, de maior custo.
Ambiental: Monitoração de variáveis ambientais em locais internos como
prédios e residências, e locais externos como florestas, desertos, oceanos,
vulcões, etc. Aplicações nesta área podem incluir o rastreamento do
movimento de pássaros, o monitoramento em grande escala da Terra e a
exploração planetária; o monitoramento biológico e ambiental das águas,
37
Medicina: Monitoramento de pacientes, realização de diagnósticos,
administração de drogas em hospitais, o monitoramento de dados
fisiológicos humanos, e o monitoramento de médicos e pacientes dentro
de um hospital.
Doméstica: Eletrodomésticos podem possuir nós sensores e atuadores
inteligentes embutidos. Esses nós podem interagir entre si e com redes
externas via Internet ou satélite, permitindo que usuários gerenciem
dispositivos domésticos local ou remotamente de forma fácil e integrada.
Além das áreas já citadas, RSASFs também são utilizadas em outros setores.
No entanto, tais setores utilizam RSASF de forma mais genérica para
segurança, monitoramento, controle, atuação e monitoramento de ambientes
externos e internos. Dentre estes setores podemos citar: produção industrial,
no monitoramento em indústrias petroquímicas, fábricas, refinarias e
siderúrgicas de parâmetros como fluxo, pressão, temperatura e nível,
identificando problemas como vazamento e aquecimento; áreas industriais, no
monitoramento de dados em regiões de difícil acesso e manutenção; extração de
petróleo e gás, nas plataformas em alto mar, onde o monitoramento da extração
de petróleo e gás é bastante crítico; e na indústria de aviação, neste setor
sensores sem fio são utilizados no lugar dos cabos responsáveis pela
interconexão do sistema de controle da tecnologia fly-by-wire.
2.1.2.
Modelos de comunicação e entrega de dados
em RSASFs
Comunicação de infraestrutura e comunicação da aplicação são os tipos de
comunicação geralmente suportados por RSASF.
A comunicação de infraestrutura é responsável pela troca de mensagens
entre os nós a fim de configurar, manter ou otimizar a operação da rede. As
trocas de mensagens para descobrir o caminho dos nós sensores e atuadores
38
para a eleição de novos líderes são consideradas comunicações de
infraestrutura.
A comunicação de aplicação responsabiliza-se pela transferência dos
interesses da aplicação para a rede, a partir da qual a entrega de dados tem
início, e pela transferência dos dados coletados sobre o fenômeno em estudo,
desde sua origem até a aplicação destino.
O interesse da aplicação deve ser especificado em relação ao fenômeno
estudado, evitando que o usuário precise ter conhecimento quanto à
infraestrutura e aos protocolos de comunicação subjacentes.
Após a definição do interesse da aplicação, os dados começam a ser
coletados e enviados pela rede. O tipo de tráfego da aplicação será determinado
pelo modelo de entrega de dados (os modelos existentes são definidos na Seção
2.1.1).
A maioria das aplicações de RSASF admite a perda de dados, assim um
mecanismo elaborado para garantia de envio de dados não é justificado. Vários
protocolos de roteamento utilizam técnicas com o intuito de diminuir a perda
de dados, como o Difusão Direcionada, que repassa os dados através de vários
caminhos. No entanto, durante as comunicações de infraestrutura a rede
precisa de uma entrega confiável de dados, pois isto garantirá o gerenciamento
correto de toda a rede. A partir desta necessidade, alguns protocolos foram
criados, dentre estes podemos citar: PSFQ (Pump Slowly, Fetch Quickly), ESRT
(Event-to-Sink Reliable Transfer) e RMST (Reliable Multi-Segment Transport).
2.1.3.
Qualidade de serviço (QoS) em RSASFs
Há uma ampla variedade de definições possíveis para o conceito de QoS em
redes de sensores e atuadores [FROLIK, 2004], [IYER, 2003], [PERILLO, 2003],
[PERILLO, 2003]. Em [FROLIK, 2004] QoS em uma RSASF é definida em termos
da resolução espacial da rede. Já [YU, 2004] considera a latência como um
39
que, para alguns tipos de aplicações, o tempo de vida da rede é um requisito
crítico. Com base nas afirmações acima é possível observar que o tipo de
aplicação alvo influencia consideravelmente nos requisitos de QoS desejados.
Nesse sentido, em [FROLIK, 2004] aplicações de RSASFs são classificadas em
duas classes: dirigidas a desempenho e dirigidas a custo.
As aplicações dirigidas a desempenho caracterizam-se pelas restrições de
energia e largura de banda, além de demandar dados em tempo real, ou seja, a
latência é um requisito de QoS crítico.
Já as aplicações dirigidas a custo possuem requisitos de latência menos
severos e uma maior restrição com relação à energia e os requisitos mais
importantes são o tempo de vida e a acurácia dos dados.
2.2.
Plataformas para RSASF
Esta Seção descreve as duas plataformas de redes de sensores e atuadores
sem fio que serão utilizadas ao longo deste trabalho: Sun SPOT e TinyOS. Além
disso, apesar de não ser utilizada neste trabalho, a plataforma Arduíno é
descrita para ilustrar ainda mais a diversidade de plataformas para RSASF
existentes atualmente.
2.2.1.
Sun SPOT
Sun SPOT (Sun Small Programmable Object Technology) é a alcunha dada para
um elemento de RSASF (um nó sensor, especificamente), desenvolvido pela Sun
Microsystems. Sua plataforma de hardware inclui uma gama de sensores
embutidos, bem como uma interface amigável para dispositivos externos.
Trata-se de uma plataforma experimental que foi projetada de maneira a
permitir que programadores que nunca tenham trabalhado com dispositivos
embutidos possam pensar em programas com funcionalidades voltadas para
RSASF. Ela se destaca das demais plataformas para redes de sensores por
40
utilização de ferramentas de desenvolvimento padrão (IDEs) como o NetBeans.
Por utilizar a máquina virtual (VM) Squawk, que permite que as aplicações sejam executadas “on the bare metal” (direto no hardware, o que diminui o overhead e melhora o desempenho), os nós sensores não necessitam de um
sistema operacional.
Sua plataforma de hardware inclui uma gama de sensores embutidos, bem
como uma interface amigável para dispositivos externos. Os dispositivos de
sensoriamento Sun SPOT são constituídos por uma placa de processador, uma
placa de sensor e uma bateria, sendo embalados em uma caixa de plástico
(Figura 2-4). A menor estação base possui apenas a placa de processador em
uma caixa de plástico.
Figura 2-4 Hardware constituinte do dispositivo Sun SPOT.
A placa do sensor é composta por:
Um acelerômetro de 3 eixos (com duas possíveis escalas: 2G ou 6G);
Um sensor de temperatura;
Um sensor de luz;
8 leds compostos por três cores cada um;
6 entradas analógicas legíveis por um ADC;
41
5 pinos de I/O de propósito geral;
4 pinos de saída de corrente alta.
Cada Sun SPOT possui um processador ARM970T 32-bit 180Mhz com 512K
RAM e 4M Flash. A placa de processador utiliza um rádio de 2.4GHz com uma
antena integrada na placa. O rádio é um TI CC2420 (anteriormente ChipCon) e
é compatível com IEEE 802.15.4. Cada placa de processador tem uma interface
USB (utilizada para se conectar ao PC). Existem dois leds, um vermelho e um
verde. E por fim há um micro controlador Atmel Atmega88 de 8 bits utilizado
como controlador de potência.
Todo dispositivo Sun SPOT possui uma bateria recarregável de íon lítio de
3.7V e 750 mAh que é recarregada sempre que o dispositivo é conectado a um
PC ou a um hub USB. A estação base Sun SPOT não possui bateria o que faz
com que sua energia fique diretamente ligada a uma conexão USB com o PC
host. Se a bateria for ativada tanto pela CPU quanto pelo rádio ela poderá
suportar até 7 horas de operações. Podendo ser prorrogado caso o processador
entre no modo sleep e caso o rádio seja desligado quando não estiver em uso.
No modo sleep a bateria irá durar mais de 900 dias. Caso todos os 8 leds
sensores da placa estejam ativos a bateria irá durar por cerca de 3 horas.
A estação base, a qual se diferencia dos demais dispositivos por não possuir
bateria nem placa de sensores, nas plataformas Sun SPOT se conecta a sua
respectiva máquina de desenvolvimento (um PC) e permite a escrita de
programas que podem ser executados no próprio PC que utiliza o rádio da
estação base para se comunicar com dispositivos Sun SPOTs remotos. As
ferramentas de desenvolvimento também fazem uso da estação base para
implantar e depurar aplicações em Sun SPOTs remotos. Observa-se que
qualquer dispositivo Sun SPOT pode ser utilizado como estação base. No
entanto, este dispositivo não poderá utilizar os sensores disponíveis em sua
42
Os sensores Sun SPOT utilizam a implementação Java ME que suporta a
CLDC 1.1 (Connected Limited Device Configuration) [CLDC, 2012], especificação
para utilização da plataforma Java ME em dispositivos com recursos muito
limitados, e MIDP 1.0 (Mobile Information Device Profile) [MIDP, 2012],
especificação para utilização da plataforma Java em dispositivos móveis. Além
disso, os sensores também oferecem as funcionalidades básicas de um sistema
operacional.
As plataformas que suportam a utilização do Sun SPOT são atualmente:
Windows Seven, Macintosh X 10.4 rodando tanto baseado no Power PC quanto
na Intel, Linux (Fedora Core 5, SuSE 10.1 e Ubuntu 9.10) e Solaris x86.
O Sun SPOT ainda fornece um simulador que é capaz de rodar uma
aplicação Sun SPOT em um computador desktop. Isso permite testar um
programa antes de sua implantação em um SPOT real, ou caso não exista um
SPOT real disponível. Se uma estação base partilhada estiver disponível, um
SPOT virtual (dispositivo Sun SPOT simulado) também pode interagir através
do rádio com SPOTs reais.
2.2.2.
TinyOS
TinyOS é um sistema operacional open source projetado para redes de sensores
e atuadores sem fio que foi desenvolvido originalmente como um projeto de
pesquisa na Universidade da Califórnia em Berkley, USA. Atualmente existe
uma comunidade internacional de usuários e desenvolvedores. O TinyOS
possui uma arquitetura baseada em componentes que torna possível a rápida
implementação enquanto diminui o código fonte gerado, devido à existência de
vários componentes já programados, o que é um importante requisito
considerando as severas restrições de memória de um nó. A biblioteca de
componentes do TinyOS inclui protocolos de rede, serviços distribuídos, drivers
de diferentes sensores e ferramentas de aquisição de dados - todas podem ser
usadas de modo completo ou refinadas para uma aplicação personalizada.
43
orientadas a eventos. Como prova do seu sucesso, o TinyOS já foi portado para
várias plataformas de hardware de nós sensores (ex. família mica, família telos,
etc.) [TinyOS, 2012]. Um dos representantes da família MICA é o mote (outra
denominação de nó) conhecido como MICAz (Figura 2-5). Ele é equipado com
um processador Atmel128L com uma capacidade máxima de processamento de
oito milhões de instruções por segundo quando operando a 8MHz. Ele também
possui um transceptor RF que opera com o IEEE 802.15.4/Zigbee [IEEE 802.15
TG4, 2012] trabalhando a uma frequência de 2,4- 2,4835 GHz. O MICAz
funciona com TinyOS (v1.1.7 ou posterior) e é compatível com diversas placas
de sensoriamento disponíveis [MARTINCIC, 2005].
Figura 2-5 MICAz Mote.
NesC (network embedded systems C) é uma extensão da linguagem de
programação C utilizada na implementação de aplicações para TinyOS tendo
sido projetada para incorporar os princípios de estruturação e os modelos de
execução do TinyOS. As aplicações desenvolvidas são muito dependentes do
hardware e os nós rodam apenas um único fluxo por vez, ou seja, não há
suporte a programação multi-thread. O TinyOS possui algumas características
importantes que influenciaram o design do nesC: uma arquitetura baseada em
componentes, um modelo de concorrência simples baseado em eventos e
operações divididas em fases (split-phase) para lidar com a característica de
44 Arquitetura baseada em componentes: TinyOS provê um conjunto de
componentes reutilizáveis. Uma aplicação conecta componentes usando a
especificação de ligações (wirings) que é totalmente independente da
implementação dos componentes. Assim, cada aplicação customiza o conjunto
de componentes que usa.
Tarefas e concorrência baseada em eventos: Existem duas fontes de
concorrência no TinyOS: tarefas (tasks) e eventos (events). Tarefas são
mecanismos de computação. Elas são executadas até sua conclusão e não
possuem preempção entre si. Eventos também são executados até a conclusão,
mas podem causar preempção na execução de tarefas ou outros eventos.
Eventos podem ser tanto a conclusão de uma operação dividida em fases (
split-phase operation) ou um evento do ambiente onde o nó está instalado. A
execução do TinyOS é totalmente dirigida a eventos representando interrupções
de hardware.
Operações divididas em fases (split-phase operations): Como tarefas são executadas não preemptivamente o TinyOS não possui operações bloqueantes.
Todas as operações que podem ter uma execução demorada são divididas em
fases: a requisição da operação e sua conclusão são funções distintas. Um
exemplo típico de uma operação dividida em fases é o envio de um pacote: um
componente pode chamar o comando send para iniciar a transmissão de rádio
da mensagem; e o componente de comunicação sinaliza sendDone quando a
transmissão estiver completa. A Tabela 2-2 mostra a comparação entre código
bloqueante e um código de fases divididas [TinyOS, 2012].
Código Bloqueante Código Dividido em Fases
1 if (send() == SUCCESS) { 2 sendCount++;
3 }
1 // start phase
2 send();
3 //completion phase
4 void sendDone(error_t err) { 5 if (err == SUCCESS) { 6 sendCount++;
![Figura 4-1 Metamodelo da DSL intermediária com destaque para as diferenças entre ela e a proposta em [LOSILLA, 2007]](https://thumb-eu.123doks.com/thumbv2/123dok_br/15686602.117447/64.918.180.782.361.946/figura-metamodelo-intermediária-destaque-diferenças-entre-proposta-losilla.webp)
