Anais WoCCES SBRC 2014 - Universidade Federal de Santa

Transcrição

Anais
II Workshop de Comunicação em
Sistemas Embarcados Críticos
WoCCES 2014
XXXII Simpósio Brasileiro de Redes de Computadores e
Sistemas Distribuídos
5 a 9 de Maio de 2014
Florianópolis - SC
Anais
II Workshop de Comunicação em Sistemas
Embarcados Críticos – WoCCES 2014
Editora
Sociedade Brasileira de Computação (SBC)
Organizadores
Adriano Mauro Cansian (UNESP)
Alex Sandro Roschildt Pinto (UNESP)
Daniel Fernando Pigatto (USP)
José Márcio Machado (UNESP)
Kalinka Regina Lucas Jaquie Castelo Branco (USP)
Paulo Henrique Moreira Gurgel (USP)
Carlos André Guimarães Ferraz (UFPE)
Joni da Silva Fraga (UFSC)
Frank Siqueira (UFSC)
Realização
Universidade Federal de Santa Catarina (UFSC)
Promoção
Laboratório Nacional de Redes de Computadores (LARC)
Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014
Copyright ©2014 da Sociedade Brasileira de Computação
Todos os direitos reservados
Capa: Vanessa Umbelino (PostMix)
Produção Editorial: Roberto Willrich (UFSC)
Cópias Adicionais:
Av. Bento Gonçalves, 9500- Setor 4 - Prédio 43.412 - Sala 219
Bairro Agronomia - CEP 91.509-900 -Porto Alegre- RS
Fone: (51) 3308-6835
E-mail: [email protected]
Workshop de Comunicação em Sistemas Embarcados Críticos (2: 2014:
Florianópolis, SC)
Anais / II Workshop de Comunicação em Sistemas Embarcados Críticos;
organizado por Adriano Mauro Cansian... [et al.] - Porto Alegre: SBC, c2014
96 p.
WoCCES 2014
Realização: Universidade Federal de Santa Catarina
ISSN: 2177-496X
1. Redes de Computadores - Congressos. 2. Sistemas Distribuídos- Congressos.
I. Cansian, Adriano Mauro. II. Sociedade Brasileira de Computação. III. Título.
i
Promoção
Diretoria
Presidente
Paulo Roberto Freire Cunha (UFPE)
Vice-Presidente
Lisandro Zambenedetti Granville (UFRGS)
Diretora Administrativa
Renata de Matos Galante (UFRGS)
Diretor de Finanças
Diretor de Eventos e Comissões Especiais
Altigran Soares da Silva (UFAM)
Diretora de Educação
Mirella Moura Moro (UFMG)
Diretor de Publicações
José Viterbo Filho (UFF)
Diretora de Planejamento e Programas Especiais
Claudia Lage Rebello da Motta (UFRJ)
Diretor de Secretarias Regionais
Marcelo Duduchi Feitosa (CEETEPS)
Diretor de Divulgação e Marketing
Edson Norberto Caceres (UFMS)
Diretor de Relações Profissionais
Roberto da Silva Bigonha (UFMG)
Diretor de Competições Científicas
Ricardo de Oliveira Anido (UNICAMP)
Diretor de Cooperação com Sociedades Científicas
Raimundo José de Araujo Macêdo (UFBA)
Diretor de Articulação de Empresas
Avelino Francisco Zorzo (PUC-RS)
ii
Promoção
Conselho
Mandato 2013-2017
Alfredo Goldman (IME/USP)
José Palazzo Moreira de Oliveira (UFRGS)
Maria Cristina Ferreira de Oliveira (ICMC/USP)
Thais Vasconcelos Batista (UFRN)
Wagner Meira Junior (UFMG)
Mandato 2011-2015
Ariadne Carvalho (UNICAMP)
Carlos Eduardo Ferreira (IME - USP)
Jose Carlos Maldonado (ICMC - USP)
Luiz Fernando Gomes Soares (PUC-Rio)
Marcelo Walter (UFRGS)
Suplentes - 2013-2015
Alessandro Fabrício Garcia (PUC-Rio)
Aline Maria Santos Andrade (UFBA)
Daltro José Nunes (UFRGS)
Karin Koogan Breitman (PUC-Rio)
Rodolfo Jardim de Azevedo (UNICAMP-IC)
iii
Promoção
Laboratório Nacional de Redes de Computadores (LARC)
Diretoria 2012-2014
Diretor do Conselho Técnico-Científico
Elias P. Duarte Jr. (UFPR)
Diretor Executivo
Luciano Paschoal Gaspary (UFRGS)
Vice-Diretora do Conselho Técnico-Científico
Rossana Maria de C. Andrade (UFC)
Vice-Diretor Executivo
Paulo André da Silva Gonçalves (UFPE)
Membros Institucionais
SESU/MEC, INPE/MCT, UFRGS, UFMG, UFPE, UFCG (ex-UFPB Campus Campina
Grande), UFRJ, USP, PUC-Rio, UNICAMP, LNCC, IME, UFSC, UTFPR, UFC, UFF,
UFSCar, CEFET-CE, UFRN, UFES, UFBA, UNIFACS, UECE, UFPR, UFPA,
UFAM, UFABC, PUCPR, UFMS, UnB, PUC-RS, UNIRIO, UFS e UFU.
iv
Realização
Comitê de Organização
Coordenação Geral
Joni da Silva Fraga (UFSC)
Frank Augusto Siqueira (UFSC)
Coordenação do WoCCES
Adriano Mauro Cansian (UNESP)
Alex Sandro Roschildt Pinto (UNESP)
Daniel Fernando Pigatto (USP)
José Márcio Machado (UNESP)
Kalinka Regina L. J. Castelo Branco (USP)
Paulo Henrique Moreira Gurgel (USP)
Coordenação de Workshops
v
Realização
Organização Local
Carlos Barros Montez (UFSC)
Edison Tadeu Lopes Melo (UFSC)
Guilherme Eliseu Rhoden (PoP-SC)
Leandro Becker (UFSC)
Mário A. R. Dantas (UFSC)
Michelle Wangham (Univali)
Ricardo Felipe Custódio (UFSC)
Roberto Willrich (UFSC)
Rodrigo Pescador (PoP-SC)
Rômulo Silva de Oliveira (UFSC)
Secretaria do SBRC 2014
Juliana Clasen (UFSC)
Jade Zart (UFSC)
vi
Mensagem do Coordenador de Workshops do SBRC 2014
Confirmando a consolidação nos últimos anos, este ano o Simpósio Brasileiro de Redes
de Computadores e Sistemas Distribuídos (SBRC 2014) apresenta mais uma série de
workshops, visando a discussão de temas novos e/ou específicos, como Internet do
Futuro e Tolerância a Falhas. Os workshops envolvem comunidades focadas e oferecem
oportunidades para discussões mais profundas e ampliação de conhecimentos,
envolvendo pesquisadores e muitos estudantes em fase de desenvolvimento de seus
trabalhos em andamento. Neste ano tivemos novas submissões, além dos workshops já
considerados tradicionais parceiros do SBRC, o que representa o dinamismo da
comunidade de Redes de Computadores e Sistemas Distribuídos no Brasil. Infelizmente,
estas novas submissões não puderam ainda ser acomodadas, mas certamente serão
consideradas para próximas edições do SBRC.
Neste SBRC 2014, temos a realização de workshops já consolidados no circuito
nacional de divulgação científica nas várias subáreas de Redes de Computadores e
Sistemas Distribuídos, como o WGRS (Workshop de Gerência e Operação de Redes e
Serviços), o WTF (Workshop de Testes e Tolerância a Falhas), o WCGA (Workshop de
Computação em Clouds e Aplicações), o WP2P+ (Workshop de Redes P2P, Dinâmicas,
Sociais e Orientadas a Conteúdo), o WRA (Workshop de Redes de Acesso em Banda
Larga), o WoCCES (Workshop of Communication in Critical Embedded Systems), o
WoSiDA (Workshop on Autonomic Distributed Systems) e o WPEIF (Workshop de
Pesquisa Experimental da Internet do Futuro). Há que se mencionar a importante
parceria com o WRNP (Workshop da Rede Nacional de Ensino e Pesquisa), que em sua
15a edição, cumpre o importante papel de fazer a ponte entre as comunidades técnica e
científica da área. Não tenho dúvida que a qualidade técnica e científica dos workshops
se manterá em alta compatível com o SBRC.
Agradeço aos Coordenadores Gerais, Joni da Silva Fraga e Frank Siqueira (UFSC), pelo
convite para coordenar os workshops do SBRC 2014 e por todo o apoio recebido.
Desejo muito sucesso e excelente participação nos Workshops do SBRC 2014!
Carlos André Guimarães Ferraz( UFPE)
Coordenador de Workshops do SBRC 2014
vii
Mensagem dos Coordenadores do WoCCES
O II Workshop of Communication in Critical Embedded Systems (WoCCES) em
conjunto com o 32º Simpósio Brasileiro de Redes de Computadores e Sistemas
Distribuídos (SBRC 2013), em Florianópolis, SC, tem por objetivo atuar como um
fórum para apresentações técnicas de pesquisas em andamento e atividades relevantes
nas áreas de comunicação em sistemas embarcados críticos, congregando pesquisadores
e profissionais que atuam ativamente nessas áreas. O workshop também procura
estabelecer redes colaborativas multi-institucionais e grupos de competência técnicocientífica, bem como fortalecer atividades em andamento.
Sendo assim, o workshop se concentra em importantes inovações e avanços recentes na
especificação, projeto, construção e utilização da comunicação em sistemas embarcados
críticos, sendo que o objetivo do mesmo é o de reunir pesquisadores e profissionais da
indústria e da academia e proporcionar-lhes uma oportunidade para se informar sobre os
últimos desenvolvimentos, implantações, tendências tecnológicas e resultados de
pesquisa, bem como iniciativas relacionadas com sistemas embarcados e suas aplicações
em uma variedade de ambientes industriais.
Finalmente, a coordenação do workshop gostaria de agradecer a todos os autores e
participantes pela apresentação dos trabalhos e contribuições de pesquisa em
comunicação em sistemas embarcados e aplicações, agradecer a todos os revisores e
membros dos comitês de programa e de organização pelo apoio na elaboração do
programa do workshop e nas atividades, e adicionalmente agradecer os apoios da USP,
UNESP e SBC.
Adriano Mauro Cansian, co-coordenador e co-editor
UNESP – São José do Rio Preto
ACME! Computer Security Research Laboratory
Alex Roschildt Pinto, co-coordenador e co-editor
Laboratório de Automação e Computação Evolutiva – LACE
Daniel Fernando Pigatto, co-coordenador e co-editor
Universidade de São Paulo – ICMC
Laboratório de Sistemas Embarcados Críticos – LSEC
José Márcio Machado, co-coordenador e co-editor
Laboratório de Automação e Computação Evolutiva – LACE
Kalinka R. L. J. C. Branco, co-coordenadora e co-editora
Paulo H. M. Gurgel, co-coordenador e co-editor
viii
Comitê de Programa do WoCCES 2014
Adriano Mauro Cansian - IBILCE - UNESP São José do Rio Preto
Alex Sandro Roschildt Pinto - IBILCE - UNESP São José do Rio Preto
Carlos Barros Montez - Universidade Federal de Santa Catarina
Célia Leiko Ogawa Kawabata - IFSP - Campus São Carlos
Daniel Fernando Pigatto - ICMC-USP
Denis Fernando Wolf - ICMC-USP
Edson dos Santos Moreira - ICMC-USP
Ellen Francine Barbosa - ICMC-USP
Fábio Dacêncio Pereira - UNIVEM
Fernando Santos Osório - ICMC-USP
Gustavo Pessin - Vale
Horácio Antonio Fernandes de Oliveira - UFAM
Jacir Luiz Bordim - UNB
João Cunha - Instituto Politécnico de Coimbra
José Márcio Machado - IBILCE - UNESP São José do Rio Preto
Kalinka Regina Lucas Jaquie Castelo Branco - ICMC-USP
Luciana Martimiano - UEM
Luiz Henrique Castelo Branco - IFSP - Campus Araraquara
Marco Vieira - Universidade de Coimbra
Marcos Fagundes Caetano - UNB
Mario Antonio Ribeiro Dantas - UFSC
Mário Meireles Teixeira - UFMA
Paulo Portugal - Universidade do Porto
Raimundo Barreto - UFAM
ix
Sumário
Sessão Técnica 1 ........................................................................................................... 1
Uma Arquitetura para Fusão de Dados e Detecção de Outliers em Sensores de
Baixo Custo de Redes de Sensores sem Fio
Rafael Callegaro (UFSC), Carlos B. Montez, Alex R. Pinto e Ricardo Moraes... 3
Proposta de um Sistema Aberto de Controle em Hardware e Software para
VANT Direcionado à Entrega Confiável de Cargas
Luiz Carlos Querino Filho (FATEC) e Kalinka R. L. J. C. Branco...................... 17
Arquitetura experimental para automação e integração de ambientes
inteligentes com dispositivos móveis
Vandermi J. Silva (UFAM), Gustavo L. P. Silva, e Vicente F. de Lucena Jr. ..... 24
Sessão Técnica 2 ........................................................................................................... 39
Modelo de Arquitetura em Camadas para Interconexão de Sistemas em VANT
Emerson A. Marconato (USP) e Kalinka R. L. J. C. Branco................................ 41
Escalonamento de Sono e Efeito Recuperação em Baterias de Nodos em Redes
de Sensores sem Fio
Leonardo M. Rodrigues (UFSC), Carlos B. Montez, Paulo Portugal e
Francisco Vasques................................................................................................. 55
Position Paper................................................................................................................ 69
Uma Rede de Compartilhamento de Conteúdo Multimídia em Dispositivos
Móveis Baseados na Plataforma Android
Felipe Alexandre O. Machado (UFMA), Adriano V. Pinto e
Mário M. Teixeira................................................................................................. 71
Índice por Autor............................................................................................................ 85
x
32º Simpósio Brasileiro de Redes de Computadores e
Florianópolis - SC
(WoCCES 2014)
Sessão Técnica 1
Uma Arquitetura para Fusão de Dados e Detecção de Outliers
em Sensores de Baixo Custo de Redes de Sensores sem Fio
Rafael Callegaro1 , Carlos Montez1 , Alex R. Pinto3 , Ricardo Moraes12
1
Pós-Graduação em Eng. de Automação e Sistemas – PGEAS
2
Laboratório de Segurança em Computação - LabSEC
3
Campus Blumenau
UFSC – Universidade Federal de Santa Catarina
{rafael.callegaro, carlos.montez, arpinto, ricardo.moraes}@ufsc.br
Resumo. As aplicações nas áreas de Agricultura de Precisão, Engenharia Ambiental, frequentemente, utilizam sensores para o monitoramento de ambientes, como por exemplo, no controle de pragas, no processo de irrigação, na
determinação de mapas de solo e produtividade, no acompanhamento de áreas
florestais e de rios urbanos, etc. As Redes de Sensores sem Fio (RSSF) vêm
sendo propostas como infraestruturas para essas aplicações. Essas redes produzem um grande volume de dados e utilizam sensores de baixo custo e com
baixa confiabilidade, gerando dados anômalos (outliers) e afetando a qualidade
final do monitoramento. Essas condições implicam na necessidade de utilização
de métodos de fusão de informações que viabilizem o funcionamento da rede e
aumente a confiança nos dados monitorados. Este artigo propõe uma arquitetura para a fusão de informação voltada para sensores de baixa confiabilidade.
A arquitetura foi avaliada através de um estudo de caso envolvendo sensores de
pressão atmosférica de baixo custo, compatı́veis com a plataforma Arduino, cujos dados monitorados foram tratados por técnicas de fusão de informação. Os
resultados obtidos mostram que alguns dos métodos de fusão de baixo nı́vel e
técnicas para detecção de outliers, quando combinados e organizados segundo
a arquitetura proposta, conseguem substituir um único sensor centralizado e de
alto custo, mantendo a confiabilidade obtida nos dados monitorados.
1. Introdução
Uma Rede de Sensores Sem Fio (RSSF) consiste em uma rede composta por nodos de
baixo custo, com pequenas dimensões e com alguma capacidade de processamento e
transmissão. Desta forma os nodos têm capacidades que vão além da simples coleta
de informação, eles têm funcionalidades que permitem analisar e fundir seus próprios
dados ou dados de outros nós sensores, sendo ainda equipados com algum tipo de sensor com capacidade de monitoramento de grandezas fı́sicas. Além disso, normalmente
os nodos não se comunicam somente entre si, mas também com uma estação base, a
fim de que os dados possam ser divulgados, processados, analisados ou armazenados
[Dargie and Poellabauer 2010]. As aplicações variam desde os ambientes industriais, hospitalares, domótica, monitoramento urbano e de áreas rurais até os ambientes militares
[Akyildiz et al. 2002].
3
As RSSF começam a ser amplamente utilizadas nos processos de automatização
de monitoramento de diversas grandezas fı́sicas. Estas redes substituem as tradicionais
aplicações de monitoramento que assumem a abordagem centralizada, onde há um sensor
único monitorando cada grandeza observada. Este sensor, por ser único, necessita ser de
alta confiabilidade, robusto e, consequentemente, de alto custo. As obras de instalação
para garantir a confiabilidade das medições também costumam ter um alto custo associado. Essa abordagem centralizada também implica em manutenção dispendiosa, pois,
via de regra, o armazenamento dos dados é feito em dataloggers, que são dispositivos
dedicados para armazenar localmente dados coletados pelos sensores. O alto custo de
manutenção também é um problema, pois, muitas vezes há o requisito que estes sensores
sejam implantados em locais inóspitos e de difı́cil acesso, inviabilizando a substituição
constante de suas baterias e dificultando o acesso aos dataloggers.
Consequentemente, diversas aplicações que empregam uma infraestrutura de
RSSF, como por exemplo as de monitoramento ambiental, vêm deixando de ocupar, exclusivamente, a atenção da academia e gradualmente está sendo adotada por empresas,
substituindo as soluções tradicionais [Elmenreich 2007]. Essa ampliação de uso dá-se
pelas vantagens que as RSSF trazem, no que diz respeito à flexibilidade na implantação
da rede, maior cobertura espacial, custo dos sensores etc. No entanto, essa adoção só não
é maior porque ainda existem diversos desafios que precisam ser superados, a destacar:
(i) há uma geração de grande quantidade de dados, (ii) o consumo energético dos nodos
precisa ser reduzido e (iii) há dificuldades na detecção de dados anômalos (outliers) e
tolerância à falhas. Este trabalho foca nos problemas (i) e (iii), tratando-os sob o viés
dos métodos da fusão da informação, ou seja, técnicas que lidam com grande quantidade
de dados, que podem reduzir o consumo energético, além de serem capazes de aumentar
a confiabilidade nos dados monitorados pela rede, a partir de manipulação matemática
no conjunto de dados monitorados. Mais especificamente, este trabalho propõe que esses problemas sejam tratados de forma sistemática, através de uma arquitetura de fusão
de informações, que organiza o fluxo de dados e as diversas atividades necessárias para
integração dos diferentes tipos de fusão.
A principal questão que motiva este trabalho reside em saber se um conjunto de
sensores de baixo custo consegue substituir os tradicionais sensores centralizados e de alto
custo, mantendo, ou mesmo superando, a confiabilidade obtida nos dados monitorados.
No desenvolvimento deste trabalho foi realizada uma pesquisa bibliográfica com
o objetivo de encontrar e avaliar uma arquitetura de comunicação adequada para este
processo. Os aspectos relevantes sobre fusão da informação, no contexto deste trabalho,
são apresentados na seção 2. Porém, como não foi encontrada uma arquitetura a ser
aplicada diretamente no processo de monitoramento ambiental, propõe-se uma arquitetura
para a fusão de dados de sensores de baixo custo em RSSF (seção 3). Posteriormente, na
seção 4, descreve-se um estudo de caso, que utiliza sensores barométricos de baixo custo
e compatı́veis com a plataforma Arduino, que avalia a arquitetura. Por fim, algumas
considerações finais e trabalhos futuros são apresentados.
2. Fusão da Informação - Aspectos relevantes
O termo fusão da informação é amplamente utilizado na literatura.
Para
[Elmenreich 2007] a fusão da informação é um termo abrangente que cobre todos os as-
4
pectos do campo de fusão (exceto fusão nuclear ou fusão no mundo da música). É definida
por (Henrik Boström 2013) como o estudo de métodos eficientes para automaticamente ou
semi-automaticamente transformar informações de diferentes fontes e diferentes pontos
no tempo em uma representação que fornece apoio efetivo para tomada de decisão humana ou automatizada. A fusão de dados comumente faz referência a métodos de fusão
de dados brutos ou de sinal muito utilizado na fusão de sensores. Já o termo agregação
de dados, comum em RSSF, consiste em um subconjunto da fusão da informação e trata
basicamente de técnicas de transferência de dados [Kulik et al. 2002].
As vantagens de se realizar o sensoriamento utilizando vários sensores ao invés de
um único sensor está no aumento da disponibilidade, cobertura espacial, cobertura temporal e exatidão, podendo ainda diminuir a ambiguidade das observações e possibilitar
auto-ajustes. No entanto, caso as entradas de informações sejam de má qualidade ou existirem muitas falhas de forma que a quantidade de dados incorretos superem os corretos, o
desempenho global do sistema poderá ser afetado [Nakamura et al. 2007].
Quando se utiliza uma RSSF, como insfraestrutura no processo de monitoramento
de grandezas fı́sicas, é comum o uso de uma grande quantidade de nodos com sensores
de baixo custo. Basicamente os métodos de fusão podem utilizar a capacidade de processamento dos nodos para explorar a correlação espaço temporal das informações observadas diretamente pelos sensores para reduzir a quantidade de dados trafegados. Além
disso, podem ser utilizados para e detectar/corrigir dados discordantes (outliers) e falhas
[Zhou et al. 2011].
As falhas e erros são fontes de outliers ou dados discordantes, ou seja, os outliers são dados atı́picos em uma aplicação de monitoramento, e podem ter origens
de ataques maliciosos, eventos, falhas e erros. Os ataques maliciosos acontecem por
exemplo quando o atacante consegue obter vantagens ao manipular os dados dos sensores, como nas aplicações militares e são tratados com técnicas de tolerância a intrusão
[Fawzy et al. 2013].
2.1. Classificação da Fusão de Informações
[Dasarathy 1997] dividiu a fusão de informações segundo o nı́vel de abstração dos dados.
Na fusão de baixo nı́vel os dados brutos são fornecidos como entradas, combinadas diretamente em novos dados que são melhores que as entradas individuais e que podem ser
utilizados com os demais nı́veis de fusão. A nı́vel médio ou de caracterı́sticas, acontece a
abstração dos dados de forma que seja possı́vel representar um objeto de forma precisa e
concisa. Na fusão de alto nı́vel ou de decisão, acontece a tomada de decisão baseada nas
informações provenientes das camadas de nı́veis baixo e médio, onde podem ser incorporados conhecimentos a priori e informações especı́ficas sobre a tomada de decisão.
[Durrant-Whyte 1988] distingue a fusão baseada na configuração dos sensores.
Na configuração complementar, os sensores não dependem diretamente um do outro, mas
se complementam para obter uma imagem mais completa do fenômeno observado. Na
configuração redundante, são fornecidas medições independentes da mesma propriedade
em instantes diferentes ou por duas ou mais origens no mesmo instante a fim de proporcionar melhor precisão e/ou exatidão das observações. Na configuração cooperativa,
as informações são fornecidas por mais de um sensor para derivar informações que não
estariam disponı́veis se fosse utilizado apenas um. Normalmente, neste tipo de fusão há
5
perda de precisão e confiabilidade.
2.2. Modelos
Os modelos de fusão de informações na maioria das vezes descrevem um conjunto de
processos e como estes se relacionam, abstraindo-se de implementações ou instâncias
especı́ficas. Muitos modelos foram propostos para auxiliar no projeto de sistemas de
fusão de informações. Os mais comuns são: JDL Process Model [Steinberg 1999], DFD
Model [Dasarathy 1997] e Waterfall Model [Harris et al. 1998].
Estes modelos fornecem um esquema teórico e podem ser usados para facilitar
a compreensão dos requisitos e limitações introduzidas por métodos de fusão, mostram
como os dados se relacionam e especificam tarefas. Na maioria dos casos, a classificação
da fusão é baseada em nı́veis e os modelos são genéricos, com exceção ao JDL que é
aplicável diretamente na área militar. Embora tais modelos não considerem os aspectos
de rede (natureza distribuı́da) das RSSF, eles funcionam como um guia para especificar
quais métodos podem ser usados e como eles podem ser integrados em uma arquitetura.
3. Arquitetura para Fusão de Dados de Sensores de Baixo Custo
Neste artigo propõe-se uma arquitetura para aplicações de monitoramento com RSSF e
divide as atividades executadas em três camadas: Camada de Fusão Local, Camada de
Fusão de Baixo Nı́vel e Camada de Gerenciamento e Interface com Usuário (Fig. 1).
Figura 1. Arquitetura proposta para fusão de dados de sensores em RSSF.
A principal contribuição deste artigo está na definição e avaliação da Camada de
Fusão de Baixo nı́vel, que é responsável pelo recebimento dos dados provenientes da
RSSF, processamento e encaminhamento à Camada de Gerenciamento e Interface com
usuário, a qual é responsável por executar tarefas correspondentes à fusão de médio e de
alto nı́veis (conforme classificação apresentada em [Dasarathy 1997]). Essas tarefas - que
costumam envolver interações com usuários e acessos a bases de dados - são usualmente
empregadas nas tomadas de decisão e são dependentes de cada aplicação e, portanto, estão
6
fora do escopo deste artigo. Apresenta-se também neste artigo as técnicas comumente
empregadas na Camada de Fusão Local.
3.1. Camada de Fusão Local
O objetivo deste nı́vel de processamento é configurar os sensores para coletar dados sobre
o ambiente onde o mesmo está inserido, realizar algum tipo de fusão local e encaminhar os
dados para transmissão. Um dos primeiros passos é verificar junto ao fabricante do sensor
quais são as taxas de amostragens recomendadas. Também é necessário conferir se existe
algum tipo de ajuste a ser realizado no sensor, como por exemplo, a microcalibração. Dependendo da taxa de amostragem adotada, pode-se aplicar localmente aos dados algum
tipo de fusão, como por exemplo, a média aritmética. Alguns métodos de fusão das camadas superiores da arquitetura podem utilizar outras informações no seu processamento,
tais como a variância ou desvio padrão, gerados pela fusão local. Para o cálculo desses
valores, uma boa opção é realizar a fusão no intervalo entre beacons1 , como exemplificado na Figura 2, onde os nodos sensores realizam os cálculos de média aritmética e/ou
variância a cada 30 ou 60 segundos (intervalo entre os seus respectivos beacons).
Figura 2. Fusão local dos dados.
3.2. A Camada de Fusão de Baixo Nı́vel
A Camada de Fusão de Baixo Nı́vel foi subdividida em: calibração; timestamping;
detecção de erros grosseiros e sistemáticos; métodos de fusão e realimentação (Fig. 1).
3.2.1. Calibração
A calibração de sensores é um problema fundamental em RSSF [Tan et al. 2013]. Ela
consiste no conjunto de operações que estabelece e corrige a diferença existente entre
um valor medido e o verdadeiro valor. Em alguns casos, pode consistir de uma correção
aditiva ou multiplicativa da indicação com uma incerteza de medição associada. Como
ignora-se o verdadeiro valor, a calibração tende a minimizar a diferença entre o valor lido
e o verdadeiro valor da grandeza.
1
Os beacons são sinalizadores, que também podem ser definidos como pacotes de controle, gerados
periodicamente pelo coordenador para sincronizar a rede além de delimitar e descrever a estrutura do superframe das redes IEEE 802.15.4.
7
A calibração de cada dispositivo, individualmente e manualmente, conhecida
como micro-calibração pode ser intratável quando a rede possuir um grande número de
sensores [Tan et al. 2013]. Logo, a autocalibração ou calibração autodidata podem ser
empregadas neste processo. Um método convencional de auto calibração é a correção
de leituras de cada sensor para um referencial comum baseado em um sensor de referência que se tenha confiança, ou baseado na referência de um grupo de sensores
[Bychkovskiy et al. 2003].
3.2.2. Timestamping
Na arquitetura proposta, a fusão de baixo nı́vel pode ocorrer de forma on-line ou off-line.
No caso da fusão off-line, os coordenadores PAN não cumprem o papel de Centros de
Fusão, apenas encaminham os dados recebidos na direção do coordenador PAN Principal,
onde a fusão será executada. A fusão off-line pode ser utilizada para um estudo posterior
aprofundado do ambiente observado. Neste caso, é necessário associar marcações de
tempo referentes ao momento da observação em cada dado armazenado.
Os Centros de Fusão desempenham importante papel na Camada de Fusão de
Baixo Nı́vel quando ocorre a fusão on-line, sendo primordial em redes de sensores que
também possuam atuadores, para que seus resultados sejam utilizados imediatamente.
3.2.3. Detecção de erros grosseiros e sistemáticos
A detecção e eliminação de erros grosseiros é uma tarefa simples, porém, necessária
no processo de monitoraramento com RSSF, principalmente quando se admite o uso de
sensores de baixo custo. A detecção pode ser baseada, por exemplo, na simples inspeção
da faixa de operação dos sensores, ou seja, os dados obtidos e que se encontram fora
da faixa operacional de um sensor devem ser descartados. Erros sistemáticos são mais
difı́ceis de serem detectados. Correções básicas podem ser efetuadas já na implantação
(deployment) do sensor, quando estas influenciam no valor final. As demais correções
podem ser feitas baseando-se, por exemplo, em um sensor de referência, no qual já se
tenha confiança; ou baseando-se em um grupo de sensores, nos quais, coletivamente,
acredita-se que seus valores médios sejam confiáveis.
3.2.4. Métodos de Fusão
Neste nı́vel os dados dos sensores são comparados, a fim de detectar possı́veis sensores
discordantes. Diversos algoritmos podem ser utilizados. Nesta arquitetura, considera-se
um algoritmo apropriado aquele com a capacidade de comparar os dados obtidos pelos
sensores envolvidos na fusão e seguindo um critério realizar ou não a supressão dos seus
dados. A eliminação das observações de sensores, mesmo quando estes realizam leituras
corretas tende a descartar observações desnecessariamente, o que não é desejável. Ainda,
é conveniente que quando uma observação for descartada, de alguma forma o algoritmo
tenha capacidade de marcar ou mostrar de forma clara qual sensor e qual o motivo que
levou o dado a ser rejeitado. Igualmente, devido a dúvida sobre a qualidade dos sensores
8
de baixo custo, é desejável que o algoritmo tenha mecanismos capazes de computar a
qualidade do sensor durante o processo de fusão.
Um método muito utilizado para a fusão de dados é a média aritmética, que não é
adequada para a grande maioria das aplicações. Nas subseções abaixo descrevem-se as
principais caracterı́sticas dos métodos avaliados neste artigo. É importante destacar que
há diversas outras técnicas que poderiam ser avaliadas, como por exemplo as técnicas
baseadas em Filtro de Kalman [Nakamura et al. 2007]. No entanto, essas abordagens
são statefull, pois necessitam do histórico das mensagens anteriores de cada sensor e os
métodos estudados neste trabalho são stateless.
A. Média Tolerante a Falhas
Um dos métodos de fusão de sensores com simples aplicação, e bons resultados é a
média tolerante a falhas (MTF) proposto por [Marzullo 1990]. Basicamente o método
divide um conjunto ordenado de dados em três partes, eliminando as extremidades.
O primeiro passo desta técnica é ordenar o conjunto de dados enviados pelos nodos
sensores. Tomando t=N/3, onde N é o tamanho do conjunto, descartam-se os extremos da
amostra ordenada, ou seja as t maiores e as t menores medidas. O valor final é o cálculo
da média e desvio padrão dos valores restantes.
B. Confidence-weighted Averaging - CWA
[Elmenreich 2007] propôs um método de fusão relacionando a confiança nos sensores
pelo inverso da respectiva variância. A variância é uma medida útil em muitos casos
porque são aditivas, podendo-se comparar diferentes grupos de dados. O desvio-padrão,
por sua vez, tem a vantagem de ser expresso na mesma unidade que a variável medida,
tornando mais fácil de comparar resultados. Para [Elmenreich 2007], no melhor caso a
variância é próxima de zero, tendo assim a máxima confiança e no pior caso o sensor
gera valores aleatórios dentro da sua faixa de operação. A variância de pior caso pode
ser calculada como a variação de uma função aleatória uniformemente distribuı́da entre
os limites a e b, onde a e b são os valores mı́nimos e máximos de uma função aleatória,
uniformemente distribuı́da.
C. CWA + MTF
O CWA pode ser utilizado juntamente com outros métodos, como por exemplo a MTF
proposta por [Marzullo 1990], o que foi proposto por Elmenreich [Elmenreich 2007].
Assim o método se torna tolerante a falhas e considera a qualidade do sensor na fusão. O
método consiste em calcular a média ponderada incluindo todos os sensores através do
método CWA e, posteriormente, elimina-se 2/3 dos sensores conforme especificado no
MTF e calcula-se novamente a média ponderada.
D. CWA com alterações
O método proposto em [Elmenreich 2007] para fundir informações de sensores diferentes, prioriza os sensores com menor variância. Uma exceção apontada pelo próprio autor
do algoritmo é que, caso a variância seja zero, passa a ser necessário algum tratamento
especial para evitar a divisão por zero. Contudo, em experimentos preliminares efetuados
neste trabalho observou-se um outro problema, pois, como a arquitetura proposta é
voltada para RSSFs que utilizam sensores de baixo custo. Foi observado em alguns
9
cenários de execução, que leituras de dados coletados por um único sensor podiam
apresentar valores iguais por um longo perı́odo de tempo, caracterizando um sensor
defeituoso e “travado”. Esse travamento do sensor poderia ser definitivo ou temporário,
por um curto ou longo tempo. Esse sensor “travado”, pela sua baixa variância, fazia
com que seus dados incorretos contribuı́ssem com um maior peso no cálculo da média
ponderada do que os sensores corretos. Assim foi necessária uma alteração simples
do algoritmo original na implementação realizada. Basicamente, quando um sensor
apresentar variações entre leituras abaixo de um valor estipulado (e dependente do tipo
e da especificação do sensor), sua variância calculada será artificialmente aumentada
para o máximo valor possı́vel, contribuindo assim minimamente para o cálculo da média
ponderada.
E. Critério de Chauvenet
O critério de Chauvenet é um método estatı́stico que foi desenvolvido para a detecção
de outliers, podendo ser utilizado para detecção de falhas bizantinas. Ele baseia-se na
hipótese de que uma medição arbitrária pode ser rejeitada se a probabilidade de obter
o desvio da média para este valor é menor do que o inverso do dobro do número de
medições [Taylor 2012].
O tamanho da amostra é muito importante na utilização do método, pois com
uma amostra grande, há poucas chances de que um dos valores afetem a média de forma
significativa. Um valor divergente em uma amostra grande deve estar muito longe da
média para “mover” a distribuição. Isso faz com que a utilização de poucos dados tenha
exigências mais rı́gidas.
F. Método de Peirce
O método de Pierce é uma técnica estatı́stica para detecção de outliers, em uma amostra
com comportamento normal. O artigo original data de 1852, contudo é amplamente
utilizado nos dias atuais. [Ross 2003] descreve o método de detecção de dados suspeitos
proposto por Peirce como segue: “as observações devem ser rejeitadas quando os desvios
reais da média obtidos por mantê-los, é menor do que os desvios obtidos por sua rejeição,
multiplicada pela probabilidade de fazer tantos e não mais, observações anormais”.
Explicando de outra forma, o objetivo de sua técnica era gerar probabilidades
de erro que ocorrem no sistema onde todas as n observações são mantidas versus as k
amostras rejeitadas. Ele então rejeita k observações e verifica se a amostra é mais próxima
da normal que a anterior. O Critério de Peirce, prevê a detecção de mais de um dado
discordante na amostra. O método de cálculo utilizado por Peirce é matematicamente
complexo de usar. Desta forma Gould levou o método a ser apresentado em um formato
mais facilmente empregável com tabelas derivadas do trabalho de Peirce [Gould 1855].
3.2.5. Realimentação
As realimentações são informações obtidas de banco de dados, do usuário e outras fontes, incluindo os métodos de fusão de dados brutos. Por exemplo, informações sobre o
descarte dos dados de um sensor em especı́fico podem ser utilizadas para a calibração do
respectivo sensor.
10
4. Avaliação
Nesta seção avalia-se a arquitetura proposta através de um estudo de caso. Uma aplicação
de monitoramento ambiental, que usa a pressão atmosférica (PA) como grandeza principal, é utilizada para ilustrar o uso da arquitetura. A PA é uma grandeza relevante para
diversas áreas de aplicação, como a meteorologia, altimetria, engenharia sanitária e ambiental. Comumente para o sensoriamento da PA no monitoramento ambiental, emprega-se
um único sensor barométrico de alta qualidade, confiável, com especificações rı́gidas no
que tange à instalação e operação e, consequentemente, de alto custo.
O local escolhido para a realização das medições foi nas proximidades do Aeroporto Hercı́lio Luz na cidade de Florianópolis, Santa Catarina. Na Figura 3 pode-se
observar que foi utilizado um sensor de referência externo para questões comparativas
(identificado neste trabalho como Vaisala), este sensor externo é operado pela aeronáutica
e está localizado nas proximidades da cabeceira da Pista 14, a 5 metros de altitude com
referência ao nı́vel do mar. A distância entre o sensor do aeroporto e o local dos experimentos é de 1300 metros. Ainda com a finalidade de comparar os dados obtidos com
os sensores de baixo custo, utilizou-se um segundo sensor de referência preciso e de alto
custo (identificado neste trabalho como sensor de referência interno Young).
Figura 3. Local do experimento.
A comunicação entre os sensores do experimento foi realizada através de uma
RSSF IEEE 802.15.4 com topologia em estrela. Quatro sensores de baixo custo foram
usados nos experimentos, o que satisfaz o critério mı́nimo de sensores exigido pelas
técnicas de fusão apresentadas anteriormente.
O quinto nodo foi configurado para atuar como nodo coordenador PAN/Centro
de Fusão, sendo o computador responsável por armazenar os dados gerados. A rede foi
configurada para ser utilizada em modo com beacon ativado, e este nodo, cumprindo
seu papel de Coordenador PAN, é responsável por sincronizar a rede através do envio
de beacons. Para configurar a periodicidade da aplicação foi utilizado o valor do Beacon
Order (BO) = 11, o que define um Beacon Interval (BI) de aproximadamente 30 segundos.
11
Os demais nodos foram equipados com sensores de baixo custo Bosch. O software de rede utilizado nos nodos foi implementado sobre a camada MAC. Assim não
foram utilizados sistemas operacionais especı́ficos para RSSF, tais como o TinyOS ou
FreeRTOS.
A alimentação dos nodos de 1 a 4 equipados com sensores Bosch foi realizada por
2 baterias do tipo AA, sendo que os nodos também alimentavam os sensores Bosch. O
nodo 5, equipado com o sensor Young, utilizou fonte de alimentação AC/DC. O nodo 5 foi
interligado ao microcomputador utilizando comunicação serial com cabo USB e os dados
coletados pelos nodos foram armazenados em arquivo texto, acrecidos dos timestamps no
seguinte formato: < timestamp, nodo[1 − 10], variância [1 − 10] >.
O microcomputador do experimento teve seu horário sincronizado através do protocolo NTP, assim como ocorre com o microcomputador do aeroporto. Optou-se por
realizar a fusão a posteriori, pela existência de limitações de permanência no local do
experimento e na obtenção dos dados on-line do sensor de referência externo.
4.1. Resultados Experimentais
A primeira análise de dados realizada foi sobre os dados obtidos pelos sensores de referência interno (Young) e externo (Vaisala). O objetivo foi verificar se as leituras feitas
pelo sensor de referência interno são coerentes com as do sensor de referência externo.
Foram selecionados dados referentes a 24h de leituras e realizada uma média
horária da pressão atmosférica (Figura 4). Para realizar o comparativo foi necessário
corrigir os efeitos causados pela diferença de altitude de instalação dos dois sensores
(cerca de 1,5 metros), que equivale a 0.18 hPa, subtraı́dos dos valores obtidos pelo sensor
de referência externo. Além da altitude foi necessário se levar em consideração a exatidão dos sensores. Segundo os fabricantes, as leituras podem variar ± 0.3 hPa e, dessa
forma, a discrepância entre os dois sensores não deve ultrapassar ± 0.6 hPa. Observou-se
que a diferença máxima ficou em torno de ± 0.25 hPa. Logo, pode-se considerar que o
sensor de referência interno Young está validado com relação ao sensor de referência externo Vaisala, o qual é periodicamente calibrado, pois seus valores são utilizados para as
operações de decolagem e aterrizagem no aeroporto. Por conveniência, na continuidade
deste trabalho, os dados referentes aos sensores de baixo custo (Bosch) e os resultados
obtidos pela fusão de seus valores serão comparados somente com o sensor de referência
interno (Young), doravante chamado apenas de sensor de referência.
Diversas análises foram realizadas para avaliar as técnicas de fusão. Neste artigo
apresenta-se a análise de uma amostra de dados que contém um sensor discordante (Figura
5). Observa-se que este sensor sempre envia a mesma leitura de pressão atmosférica,
o que pode ser entendido como um sensor com alta precisão (variância zero). Porém,
esta diferença em relação aos outros sensores aconteceu provavelmente pelo baixo nı́vel
de bateria no nodo em que o sensor estava acoplado. Na Figura 5 observa-se que os
valores do sensor Bosch4 permanecem distante dos demais, chegando a diferir 1.31 hPa
da referência, enquanto os demais sensores diferem apenas 0.07 hPa.
A Figura 6 apresenta os resultados dos métodos de fusão aplicados a estes dados.
O método da aplicação da média aritmética obteve os piores resultados pois este inclui
todos os dados no cálculo da fusão. Como nesta amostra há um sensor com leituras
12
Figura 4. Comparação entre sensores de referência.
discordantes, a média é deslocada e esta técnica não permite dizer qual sensor apresenta
valores discordantes.
Ao aplicar o método de Chauvenet, verifica-se que o mesmo não detecta o sensor
4 como discordante, obtendo os mesmos valores que a média aritmética. Interessante
notar que se o sensor de referência fizesse parte do conjunto de sensores usados para o
cálculo da fusão, o método de Chauvenet conseguiria um melhor desempenho, eliminando
o sensor discordante e a realizando a média aritmética com os sensores restantes.
O método de Peirce conseguiu detectar corretamente o sensor 4 como discordante.
O máximo desvio entre o sensor de referência e o valor obtido na fusão foi de 0.03 hPa.
Diferente dos métodos de Chauvenet e Peirce, a Média Tolerante a Falhas (MTF) sempre
descarta os valores de dois terços dos sensores, mesmo estes tendo valores semelhantes.
O método proposto por Elmenreich (CWA) é o mais completo, no sentido em que
leva em consideração a qualidade do sensor. No entanto os dados de variância devem estar disponı́veis. Há três formas de executar o método: na primeira considera-se apenas a
variância informada pelos sensores (CWA); na segunda são incluı́das as modificações propostas neste artigo (CWA com alterações) e, por fim, utilizando o algoritmo modificado
em conjunto com a média tolerante a falhas (CWA + MTF).
Pode-se observar nos resultados apresentados na Tabela 1 que o método proposto
Figura 5. Amostra de dados com sensor discordante.
13
Figura 6. Aplicação dos métodos de Fusão de dados.
Rounds
1
2
3
4
5
6
7
8
9
10
Tabela 1. Método de Elmenreich.
Referência
CWA
CWA+MTF CWA com alt.
1012,29
1013,37
1012,31
1012,30
1012,27
1013,38
1012,28
1012,26
1012,24
1013,35
1012,25
1012,23
1012,23
1013,36
1012,20
1012,23
1012,22
1013,36
1012,18
1012,20
1012,19
1013,38
1012,17
1012,18
1012,18
1013,39
1012,19
1012,17
1012,16
1013,36
1012,18
1012,18
1012,17
1013,37
1012,15
1012,16
1012,15
1013,35
1012,12
1012,15
por Elmenreich (CWA sem alterações) tem um desempenho ruim, obtendo a diferença
máxima em torno de 1,2 hPa do sensor de referência. Este resultado evidencia que, caso
um sensor tenha leituras sequenciais iguais, a variância obtida é zero e o sistema terá sua
maior confiança no sensor discordante.
Utilizando o método de CWA com alterações, assume-se que um sensor com
variância constante, durante um determinado perı́odo, próxima de zero é defeituoso, fazendo com que sua variância seja elevada artificialmente a um valor máximo. Assim,
apesar do sensor defeituoso participar da média ponderada, obtém-se um resultado mais
aproximado do sensor de referência. A terceira forma aplicada é do método de CWA +
MTF, o que também faz com que os dados se aproximem da referência.
Na Tabela 2 pode-se observar o resultado da aplicação das técnicas MTF e o
CWA+MTF na amostra de dados. Pode-se verificar que o sensor 2 participou de todas
as médias, enquanto o sensor 4 foi corretamente desconsiderado em todas. Já o sensor
1, apesar de ter leituras próximas das corretas foi desconsiderado em 80% dos casos,
presentes nesta amostra. Comparando os resultados obtidos pela MTF com o sensor de
referência, encontra-se o valor máximo de 0.02 hPa.
5. Conclusões
As RSSF utilizando sensores de baixo custo para o monitoramento de grandezas fı́sicas,
vem substituindo a tradicional abordagem centralizada que utilizam um único sensor
confiável de alto custo. Parte desta mudança está relacionada com as vantagens que a
14
Tabela 2. MTF e CWA+MTF aplicados na amostra com sensor 4 discordante.
Sensor
Sensor
#1 #2 #3 #4
#1 #2 #3 #4
1o round
◦
•
•
◦
1o round
◦
•
•
◦
o
2 round
◦
•
•
◦
2o round
◦
•
•
◦
3o round
◦
•
•
◦
3o round
◦
•
•
◦
4o round
◦
•
•
◦
4o round
•
◦
•
◦
5o round
◦
•
•
◦
5o round
•
◦
•
◦
6o round
•
•
◦
◦
6o round
•
◦
•
◦
7o round
◦
•
•
◦
7o round
◦
•
•
◦
8o round
◦
•
•
◦
8o round
◦
•
•
◦
9o round
◦
•
•
◦
9o round
•
◦
•
◦
10o round •
•
◦
◦
10o round •
◦
•
◦
(a) MTF
(b) CWA com MTF
Legenda: • Participa da fusão ◦ Não participa da fusão
RSSF proporciona, como flexibilidade na implantação da rede, melhor cobertura espacial, custo dos sensores etc. No entanto surgem novos desafios na medida que tais redes
começam a ser utilizadas na prática. Por exemplo, elas geram uma grande quantidade de
dados, precisam ter funcionamento adequado à quantidade de energia fornecida, além de
falhas e erros ocasionados por nodos de RSSF equipados com sensores de baixo custo.
Assim a utilização de dados brutos, gerados pelos nodos sensores não tem sido adequada
para as aplicações.
Desta forma, este trabalho foca nesses problemas, tratando-os sob o viés dos
métodos de fusão da informação, ou seja, técnicas que diminuem a quantidade de dados
e aumentam sua confiabilidade. A arquitetura proposta foi aplicada no monitoramento
de ambientes. Os sensores de baixo custo foram calibrados baseados em um sensor de
referência, sem esta operação, os métodos de fusão não atingiriam o desempenho esperado devido ao desvio constante dos valores observados pelos sensores de baixo custo.
Os timestamps foram adicionados, proporcionando que a fusão fosse realizada off-line.
Os erros sistemáticos e grosseiros, como valores “zero” por exemplo, foram corretamente descartados antes de chegarem aos métodos de fusão. Dentre os métodos testados, Peirce e CWA + MTF se mostraram mais adequados para a fusão dos sensores. Já a
média aritmética, Chauvenet e CWA sem modificações, não tiveram bom desempenho na
presença de nodos falhos.
De forma geral a configuração da RSSF utilizada, juntamente com sensores de
baixo custo e a arquitetura proposta, teve desempenho superior do que quando utilizado
um sensor único de alto custo. Acredita-se que futuros sistemas de monitoramento de
ambientes utilizando RSSF e sensores de baixo custo, possam dispor deste trabalho como
ferramenta, tanto no que se refere ao levantamento bibliográfico, no desempenho dos
métodos testados, bem como utilizar ou basear sua aplicação na arquitetura proposta.
Referências
Akyildiz, I. F., Su, W., Sankarasubramaniam, Y., and Cayirci, E. (2002). Wireless sensor
networks: A survey. Comput. Netw., 38(4):393–422.
Bychkovskiy, V., Megerian, S., Estrin, D., and Potkonjak, M. (2003). A collaborative
approach to in-place sensor calibration. pages 301–316.
15
Dargie, W. and Poellabauer, C. (2010). Fundamentals of wireless sensor networks: theory
and practice. John Wiley & Sons Ltda.
Dasarathy, B. (1997). Sensor fusion potential exploitation-innovative architectures and
illustrative applications. Proceedings of the IEEE, 85(1):24–38.
Durrant-Whyte, H. F. (1988). Sensor models and multisensor integration. Int. J. Rob.
Res., 7(6):97–113.
Elmenreich, W. (2007). Fusion of continuous-valued sensor measurements using
confidence-weighted averaging. Journal of Vibration and Control (incorporating Modal Analysis), 13(9-10):1303–1312.
Fawzy, A., Mokhtar, H. M., and Hegazy, O. (2013). Outliers detection and classification
in wireless sensor networks. Egyptian Informatics Journal, 14(2):157 – 164.
Gould, B. A. (1855). On peirce’s criterion for the rejection of doubtful observations, with
tables for facilitating its application. Astronomical Journal, 4:81–87.
Harris, C., Bailey, A., and Dodd, T. (1998). Multi-sensor data fusion in defence and
aerospace. The Aeronautical Journal, 102(1015):229–244.
Kulik, J., Heinzelman, W., and Balakrishnan, H. (2002). Negotiation-based protocols for
disseminating information in wireless sensor networks. Wirel. Netw., 8(2/3):169–185.
Marzullo, K. (1990). Tolerating failures of continuous-valued sensors. ACM Trans. Comput. Syst., 8(4):284–304.
Nakamura, E. F., Loureiro, A. A. F., and Frery, A. C. (2007). Information fusion for
wireless sensor networks: Methods, models, and classifications. ACM Comput. Surv.,
39(3).
Ross, S. (2003). Peirce’s criterion for the elimination of suspect experimental data. Journal of Engineering Technology, 20(2).
Steinberg, Alan N Bowman, C. L. W. F. E. (1999). Revisions to the jdl data fusion model.
International Society for Optics and Photonics, pages 430–441.
Tan, R., Xing, G., Yuan, Z., Liu, X., and Yao, J. (2013). System-level calibration for data
fusion in wireless sensor networks. ACM Trans. Sen. Netw., 9(3):28:1–28:27.
Taylor, J. R. (2012). Introdução à Análise de Erros - o Estudo de Incertezas. BOOKMAN,
2a ed. edition.
Zhou, C.-H., Chen, B., Gao, Y., Zhang, C., and Guo, Z.-J. (2011). A technique of filtering
dirty data based on temporal- spatial correlation in wireless sensor network. Procedia
Environmental Sciences, 10, Part A:511 – 516.
16
Proposta de um Sistema Aberto de Controle em Hardware
e Software para VANT Direcionado à Entrega Confiável de
Cargas
Luiz Carlos Querino Filho1, Kalinka R. L. J. C. Branco2
1
FATEC - Faculdade de Tecnologia de Garça
Av. Presidente Vargas, 2331 – Garça – SP - Brasil
2
USP - ICMC - Instituto de Ciências Matemáticas e de Computação
Av. Trabalhador Sãocarlense, 400 - São Carlos - SP - Brasil
[email protected], [email protected]
Abstract. As a consequence of the evolutionary process of the miniaturization
of electronic components, sensors and wireless communication devices, UAVs
(Unmanned Aerial Vehicles) have become more accessible and present in
several types of applications. One of the recent possibilities of use for these
kind of devices is the delivery of parcels and cargo, and such use have began
to be tested by retail and transportation companies. This paper presents a
proposal of a UAV model using open hardware and softwares components,
allowing the transport and delivery of parcels in a quadcopter with route
planning, payload coupling, obstacle avoidance, package tracking during the
path and safe delivery with confirmation of identity of the receptor.
Resumo. Como consequência do processo evolucionário da miniaturização de
componentes eletrônicos, sensores e dispositivos de comunicação sem fio, os
VANTs (Veículos Aéreos Não Tripulados) se tornaram mais acessíveis e
presentes em diversos tipos de aplicações. Uma das mais recentes
possibilidades de uso para esses equipamentos é na entrega de pacotes e
encomendas, e tal utilização já começa a ser testada por empresas de varejo e
transportes. Este artigo apresenta uma proposta de um modelo de VANT com
uso de componentes de hardware e software abertos, proporcionando o
transporte e entrega de pacotes em um quadricóptero com planejamento de
rota, acoplamento de carga, desvio de obstáculos, rastreamento do pacote
durante o trajeto e entrega segura com confirmação da identidade do
receptor.
1. Introdução
Os VANTs (Veículos Aéreos Não Tripulados) são aeronaves que não necessitam de um
piloto a bordo para seu controle e que são construídas geralmente em escala menor que
as tradicionalmente tripuladas [Braga et al. 2011]. Podem ser elaborados como aviões,
dirigíveis e helicópteros, sendo que para este último há as variações com mais de dois
rotores, os chamados multirotores [Balas 2007].
Com a miniaturização dos componentes eletrônicos que equipam esses veículos,
e seu consequente barateamento, sua utilização nos mais diversos campos de atividade
aumentou significativamente. Vigilância, análise ambiental e missões militares são
17
alguns dos campos nos quais os VANTs são empregados atualmente [Branco et al.
2011].
Uma nova possiblidade de utilização para os VANTs passou a ganhar atenção
recentemente: o transporte e entrega de pacotes e encomendas. Como exemplo, a
Amazon, um dos principais nomes do varejo mundial, anunciou ao mundo o
desenvolvimento do serviço Amazon Prime Air, que utilizará multirotores para entrega
de encomendas aos seus clientes [Amazon 2014]. De modo semelhante, a DHL,
empresa de transportes, também já anunciou pesquisas nessa área, utilizando VANTs
para entrega de medicamentos [DailyMail 2014].
Figura 1. VANT do serviço Amazon Prime Air [Amazon 2014]
A perspectiva do uso de VANTs nesse ramo de atividade levanta uma série de
questões sobre o modelo de funcionamento de um sistema desse tipo - esse é o tema
abordado na seção 2 deste artigo. Posteriormente, na seção 3, é apresentado o modelo
conceitual do sistema, composto de um VANT e outros recursos de suporte necessários
à atividade de entrega, como uma estação de controle e planejamento da missão, um
servidor Web para intermediar a comunicação entre o veículo, remetente e destinatário
do pacote, e aplicativos móveis voltados ao acompanhamento e recepção da carga. A
seção 4 contém as considerações finais sobre a proposta e a possibilidade de
implementações futuras. Por fim, a seção 5 traz as referências bibliográficas consultadas
para elaboração deste artigo.
2. Objetivos, considerações gerais e funcionamento do sistema
A possibilidade do uso de um Veículo Aéreo Não Tripulado na entrega de encomendas
tradicionais (como aquelas realizadas em lojas de varejo) traria consequências óbvias na
rapidez e economia do processo de transporte. Fora do ramo tradicional de vendas,
VANTs também podem ser utilizados para transporte rápido de documentos e pequenos
objetos dentro de grandes cidades, não sendo afetados diretamente por problemas
típicos de serviços de entrega tradicionais (como aqueles realizados por motoboys e
transportadoras), como trânsito intenso e furto.
Quando se estende a área de atuação desses veículos, pode-se considerar
também seu uso na entrega de medicamentos, alimentos e outros bens em áreas de
difícil acesso ou sob condições insalubres. Contudo, algumas questões importantes para
o uso prático de um VANT na área de transporte devem ser consideradas, uma vez que
essa modalidade de uso para esses veículos começou a ganhar atenção apenas
recentemente. Uma das questões iniciais trata a respeito da regulamentação do uso de
18
um VANT dentro do espaço aéreo do país. Nos casos anteriormente citados, tanto a
Amazon quanto a DHL aguardam ainda a decisão de órgãos governamentais sobre as
condições necessárias para uso comercial desses veículos.
Uma vez não esquecida a necessidade de regulamentação, estudos que
viabilizarão o uso desses equipamentos para a realização dessa tarefa de entrega devem
ser realizados para permitir que, assim que as normas e regulamentações estejam
prontas os mesmos possam ser utilizados.
Assim, além da questão legal, o projeto de um VANT destinado à entrega deverá
possuir recursos que garantam a confiabilidade do serviço, bem como meios de
autenticação e confirmação do recebimento, tanto por parte do remetente quanto por
parte do destinatário.
Quanto ao veículo utilizado, este deverá possuir capacidade de reter a carga no
momento da decolagem, assim como liberá-la após o pouso. Dessa maneira, faz-se
necessário o uso de um dispositivo mecânico (controlado eletronicamente) adequado ao
acoplamento da carga, como o exemplo apresentado em [Thomas et al. 2013].
Consequentemente, o veículo também deverá ter as características que facilitem sua
decolagem e pouso em ambientes com espaço limitado; dessa forma, VANTs
multirotores (como quadricópteros) seriam ideais para essa tarefa, dada sua capacidade
para decolagem e aterrissagem vertical.
Após o acoplamento do pacote e decolagem, o VANT deverá seguir o caminho
até o destinatário obedecendo uma rota ideal pré-definida, visando realizar a entrega no
menor tempo possível. Durante o trajeto (incluindo decolagem e pouso), será necessário
detectar e evitar possíveis obstáculos, como prédios, postes, fios, árvores, entre outros.
O veículo deve contar com recursos de transmissão de dados e telemetria, para
que o remetente e o destinatário do pacote possam rastreá-lo durante o transporte. Esse
rastreamento pode ser realizado com o uso de um aplicativo móvel, por exemplo.
No momento da chegada ao destino, o VANT poderá simplesmente aterrissar em
um ponto pré-determinado e liberar o pacote, acionando o dispositivo mecânico de
retenção/liberação. Porém, para casos em que seja necessária uma confirmação da
identidade do receptor, é preciso que exista um meio de autenticação.
O diagrama exibido na Figura 2 ilustra o funcionamento em conjunto dos
recursos existentes na arquitetura proposta do sistema.
19
Figura 2. Diagrama de funcionamento do sistema de entregas por VANT
Inicialmente, o remetente do pacote (1) estabelece a missão de entrega para o
veículo, utilizando para tanto um tablet ou computador conectado à Internet. Nesse
momento, o pacote é acoplado ao VANT. Todas as informações relativas à rota de
entrega e destinatário são gerenciadas pelo Web Service existente em (2). O VANT,
equipado com um módulo de transmissão de dados em rede GSM (3), recebe os dados
da rota por meio do Web Service e inicia o trajeto ao destinatário (4).
Durante o percurso, tanto o destinatário (4) quanto o remetente (1) podem
acompanhar o trajeto do veículo. Os dados relativos à posição e estado do veículo (3)
são transmitidos ao Web Service (2), que os retransmite aos dispositivos usados por
remetente e destinatário.
Quando o VANT se aproxima da área de entrega (definida pelo controle de
missão, em (1)), um aviso é emitido ao Web Service, que o repassa ao destinatário.
Nesse momento, caso seja necessário, pode ser realizada uma validação do receptor.
Essa validação poderá ser realizada por meio do uso de chaves criptográficas e tokens
de identificação (tanto para o receptor quanto para o emissor), gerenciados e
transmitidos de forma segura pelo Web Service.
O ponto exato de aterrissagem do VANT em (4) poderá ser estabelecido
previamente ou por meio de cálculos relativos ao posicionamento do smartphone/tablet
do destinatário, considerando para tanto o uso de sensores de proximidade instalados no
veículo para que não ocorram colisões.
Os componentes necessários para implementação do sistema de entrega descrito
abrangem um conjunto de hardware e software abertos que, como um objetivo mais
específico desta proposta, poderão servir futuramente como plataforma de teste e
validação de outras pesquisas dentro da área de veículos aéreos não tripulados. Cabe
ainda ressaltar que todas as conjecturas levantadas levam em conta um capacidade de
energia renovável para que o veículo possa percorrer todo o trajeto de entrega e retornar
a base.
20
3. Estrutura do sistema
No centro do sistema, encontra-se um VANT utilizado para o transporte de
cargas, como o demonstrado em [Yakimenko et al. 2011]. Como citado anteriormente,
veículos multirotores como quadricópteros são particularmente adequados a essa
finalidade, em virtude da capacidade de VTOL (Vertical Take-Off and Landing).
Em outro ponto do sistema, é necessário um conjunto de serviços RESTful, que
juntos formarão uma API de monitoramento e controle da missão de entrega. A
especificação de uma API do tipo RESTful, semelhante à proposta em [Ruppen et al.
2011], padronizada facilitará o desenvolvimento de aplicações em diversas plataformas
para uso do sistema de entrega. O diagrama exibido na Figura 3 ilustra a relação entre
os elementos do sistema: a estrutura básica do VANT equipado com microcontrolador e
sensores; o servidor Web onde será realizada a telemetria dos dados do veículo e
autenticação do destinatário do pacote; e os aplicativos móveis para controle da missão
e rastreamento.
Figura 3.Diagrama simplificado do sistema de entrega
A arquitetura de implementação do VANT poderá utilizar microcontroladores de
padrão aberto (como o Arduino), assim como seus sensores e módulos de transmissão
de dados (Figura 3). Para acoplamento da carga, será necessário o uso de servos
conectados a algum tipo de mecanismo de retenção, como por exemplo uma garra
robótica. Estudos recentes demonstram a viabilidade do acoplamento de dispositivo
semelhante em um VANT.
É importante ressaltar que, em uma implementação prática, deverão ser
considerados os pesos de todos os componentes em relação à capacidade de carga útil
do VANT. Tais cálculos deverão ser realizados para o correto dimensionamento da
potência dos motores e tamanho das hélices do quadricóptero.
Os dados transmitidos entre o servidor, o VANT e os aplicativos (controle da
missão e rastreador) seguirão o padrão JSON, comumente usado em Web Services. Tais
dados deverão ser resumidos e com baixa complexidade, uma vez que a latência
existente em certos pontos da rede GSM de dados podem ser alta. A comunicação do
transmissor GSM existente no VANT com os Web Services poderá ser implementada
de forma segura, usando o protocolo HTTPS.
21
No caso de perda de sinal da rede de transmissão de dados, o VANT poderá ser
programado (antes do início da missão) para (a) retornar à base ou (b) seguir o caminho
até o destinatário (caso ainda possua sinal do GPS ativo e não necessite dos recursos de
autenticação). Também é possível agregar ao veículo outros recursos de transmissão de
dados sem-fio para que o VANT possa ser controlado manualmente em casos
imprevistos.
A metodologia de desenvolvimento do piloto automático do VANT [Neris 2001]
[Trindade et al. 2010] e módulos de controle e navegação seguirá o padrão MDD
(Model Driven Development), com implementação inicial e testes feitos pelo
MATLAB/Simulink, como realizado em [Bouabdallah e Siegwart 2007], [Neris 2001],
[Ribeiro e Oliveira 2010], [Trindade et al. 2010], utilizando o toolbox Aerospace
Blockset.
O aplicativo utilizado pelo destinatário, além de possuir os recursos para
rastreabilidade do VANT, poderá também atuar como validador de sua identidade. No
momento do confirmação do envio, o destinatário enviará ao aplicativo do usuário
(devidamente autenticado com login e senha) um token identificador, que deverá ser
confrontado com o mesmo valor obtido pelo VANT. Toda essa comunicação será
transmitida em um canal criptografado.
Os Web Services poderão ser definidos como serviços RESTful usando as
funcionalidades do Java EE 7. A aplicação de controle de missão, assim como o
aplicativo de rastreamento utilizado pelo destinatário, poderão ser implementados para
as principais plataformas móveis do mercado (iOS, Android ou Windows Phone), pois
dependerão unicamente do acesso aos serviços RESTful. Toda a API disponibilizada
pelos Web Services (e consumida pelo VANT e aplicativos móveis) deverá ser
padronizada para facilitar sua extensão e uso em diversas plataformas.
4. Considerações Finais
Este artigo apresentou uma proposta de um sistema de entrega de pacotes usando
Veículos Aéreos Não Tripulados, aliado à recursos de arquitetura orientada a serviços e
aplicativos móveis. A implementação deverá ser baseada no desenvolvimento baseado
em modelos (MDD - Model Driven Development), como indicado em [Branco et al.
2011], e na utilização de padrões abertos de hardware e software.
A implementação dessa arquitetura também poderá abrir caminho para a
implementação prática de diversos modelos científicos propostos, assim como
agregação de nova tecnologias à arquitetura. Como exemplo, pode ser citado o uso de
chips de identificação por rádio frequência (RFID) para proporcionar maior precisão na
localização do ponto de entrega (aterrissagem) do VANT, além de oferecer outras
formas de autenticação [Lehtonen et al. 2008].
5. Referências
Amazon Prime Air, Disponível em: <http://www.amazon.com/b?node=8037720011>
Acesso em: 28 Fev 2014
Balas, C. Modelling and Linear Control of a Quadrotor. Master Thesis. Cranfield
University. 2007
22
Bouabdallah, S., Siegwart, R. Full Control of a Quadrotor. In:. IEEE/RSJ international
conference on Intelligent robots and systems, 2007. IROS 2007. IEEE, 2007. p. 153158.
Braga, R. T. V., Branco, K. R. C., Trindade Jr, O., Gimenes, I. M. S. Evolving Tiriba
Design towards a Product line of Small Electric-Powered UAVs, In: 1a Conferência
Brasileira de Sistemas Embarcados Críticos, 2011, São Carlos. Anais do 1º CBSEC.
São Paulo, EDUSP, 2011. p. 67-72.
Branco, K. R. L. J. C. ; Pelizzoni, J. ; Neris, L O ; Trindade, O. Jr ; Osório, F S ; Wolf,
D. F. Tiriba: A New Approach of UAV based on Model Driven Development and
Multiprocessors. In: IEEE International Conference on Robotics and Automation ICRA Communications, 2011, Shangai. IEEE International Conference on Robotics
and Automation - ICRA Communications, 2011. p. 1-4.
DailyMail. "DHL tests delivery drone as airborne robots could be used to deliver
medicine", Disponível em: <http://www.dailymail.co.uk/sciencetech/article2520818/DHL-tests-delivery-drone-airborne-robots-used-deliver-medicine.html>
Acesso em 28 Fev 2014
Lehtonen, M., Staake, T., Michahelles, F. and Fleisch, E. "From Identification to
Authentication – A Review of RFID Product Authentication Techniques", In:
Networked RFID Systems and Lightweight Cryptography, Edited by Peter H. Cole
and Damith C. Ranasinghe, Springer Berlin Heidelberg, 2008 p. 169-187
Neris, L. O. Um Piloto Automático para as Aeronaves do Projeto ARARA. Dissertação
de Mestrado. Universidade de São Paulo. Dezembro, 2001.
Ribeiro, L. R., Oliveira, N. M. F. UAV Autopilot Controllers Test Platform Using
Matlab/Simulink and X-Plane. In: 40th ASEE/IEEE Frontiers in Education
Conference. Washington, DC. 2010.
Ruppen, A., Pasquier, J., & Hürlimann, T. A RESTful architecture for integrating
decomposable delayed services within the web of things. International Journal of
Internet Protocol Technology, 6(4), 247-259. 2011.
Thomas, J., Polin, J., Sreenath, K., & Kumar, V. Avian-inspired grasping for quadrotor
micro UAVs. In ASME International Design Engineering Technical Conference
(IDETC), Portland, Oregon. 2013.
Trindade Jr., O., Neris, L. O., Barbosa, L., Branco, K. R. L. J. C. . A Layered Approach
to Design Autopilots. In: IEEE-ICIT 2010 International Conference on Industrial
Technology, 2010, Viña del Mar. IEEE-ICIT 2010 International Conference on
Industrial Technology. Santiago do Chile: IEEE Press, 2010. v. v1. p. 1395-1400.
Yakimenko, O. A., Bourakov, E. A., Hewgley, C. W., Slegers, N. J., Jensen, R. P.,
Robinson, A. B., ... & Heidt, P. E. Autonomous Aerial Payload Delivery System
"Blizzard". In: Proceedings of the 21st Aerodynamic Delivery Systems Technology
Conference, AIAA, Dublin, Ireland (pp. 23-26). 2011.
23
Arquitetura experimental para automação e integração de
ambientes inteligentes com dispositivos móveis
Vandermi J. Silva1, Gustavo L. P. Silva1 ,Vicente F. De Lucena Jr.2
Instituto de Ciências Exatas e Tecnologia ICET – Universidade Federal do Amazonas
(UFAM)
Caixa Postal 69100-000 – Itacoatiara – AM – Brasil
1
Universidade Federal do Amazonas (UFAM)
{vandermi, vicente}@ufam.edu.br, [email protected]
Abstract. In this work an experimental architecture for automation and
integration smart environments with mobile devices is presented, considering
gathering and storage of data from sensors and actuators. After analyzing and
filtering data, the architecture will recommend services for users of smart
environment. The proposal focuses on building an architecture that integrates
information services based on context and presents a prototype for data
collection actions in actuators and sensors and a prototype embedded on a
mobile device (smart-phone) to interact with the sensors and actuators
installed in an academic environment. The architecture is in testing with
possible future modifications and adaptations to the integration of cognitive
agents and context management module to manage and filter the data in the
preprocessing module.
Resumo. Neste trabalho é apresentada uma arquitetura experimental para
automação e integração de ambientes inteligentes com dispositivos móveis
considerando a coleta e armazenamento de dados de sensores e atuadores.
Após a análise e filtragem de dados, a arquitetura permitirá recomendar
serviços para usuários de um ambiente inteligente. A proposta concentra-se
na construção de uma arquitetura que integre serviços baseados nas
informações de contexto e apresenta um protótipo para coleta de dados de
ações em atuadores e sensores e um protótipo embarcado em um dispositivo
móvel (smartphone) para interagir com os sensores e atuadores instalados em
um ambiente acadêmico. A arquitetura está em fase de teste com possíveis
modificações e adequações futuras com a integração de agentes no módulo
cognitivo e gerência de contexto para gerenciar e filtrar os dados no módulo
de pré-processamento.
1. Introdução
O uso do contexto em aplicações interativas é cada vez mais presente no cenário
tecnológico e necessita ser estudado mais profundamente especialmente nos casos em
que os cenários estão em constantes mudanças, por exemplo, os que envolvem Ambient
Intelligence (AmI) e computação ubíqua [Abowd et. al. 1997]. A computação ubíqua
permite reconhecer objetos e informações que estão em torno do usuário de forma
dinâmica e sem interferência humana e a união dos sistemas ubíquos com a
contextualização permitirá ao usuário maior mobilidade, além de facilitar o
reconhecimento e localização de objetos e pessoas, que poderão ser acessados de
24
qualquer lugar através de um enlace de comunicação [Krohn 2004].
Ambientes inteligentes estão cada vez mais sendo inseridos na vida das pessoas
por meio da automação residencial tanto através de tarefas corriqueiras como ligar ou
desligar um sistema de iluminação, quanto as mais difíceis que envolvem identificar o
contexto em que uma tarefa deve ser executada.
Uma das atividades a ser desenvolvida em AmI se dá pela necessidade de
localização de usuários em um determinado ambiente. Essa técnica de localização é
descrita com o termo em inglês indoor location [Yang 2007] e permite o uso de
tecnologias de redes sem fio para verificar o posicionamento de pessoas em um
ambiente utilizando Radio Frequency Identification (RFID) e outras tecnologias de rede
sem fio tais como os padrões IEEE 802.15.1, Bluetooth e IEEE 802.15.4, ZigBee.
Em [Yang 2007] e [Honkavirta 2009], são apresentados os conceitos e as
principais técnicas para localização indoor, que consiste basicamente em utilizar a
triangulação do sinal de rádio e aplicar algoritmos da vizinhança mais próxima, KNN,
seguido de modificações do algoritmo aplicando técnicas de predição baseadas nas
coletas das rotas mais comuns do usuário, além da utilização do mapeamento de pontos
de referência para ser aplicado na base de treinamento de um sistema de localização
indoor.
Baseado na necessidade de integrar os dados de sensores e atuadores em um
sistema context-wareness este trabalho propõe uma arquitetura para automação de
ambientes residenciais baseada em identificação de contexto em ambientes inteligentes
para automatizar de forma transparente a identificação do usuário, sua localização
indoor e suas preferências no contexto de uma residência automatizada. O trabalho foi
dividido em seis seções descritas a seguir: Na Seção 2 serão apresentados os conceitos e
definições sobre ambientes inteligentes AmI, context-aware e localização indoor, na
Seção 3 serão apresentados os trabalhos relacionados, na Seção 4 será apresentada a
arquitetura proposta na Seção 5 será apresentada a construção do protótipo finalizando
com as discussões e as conclusões do trabalho que serão apresentadas na Seção 6.
2.
Definições
Nesta seção serão apresentados os conceitos principais utilizados no trabalho para
facilitar o entendimento das tecnologias e ferramentas utilizadas na pesquisa. A seção
foi subdividida em ambientes inteligentes, context-aware e localização indoor.
2.1. Ambientes inteligentes
Uma definição de ambientes inteligentes descrito por [Aarts, 2004] é que AmI
proporciona ambientes sensíveis e que respondem à presença de pessoas, dando ênfase
na facilidade de utilização de serviços de apoio aos usuários e principalmente, no apoio
das interações humanas com interfaces inteligentes e intuitivas, embarcadas em todos
os tipos de objetos em ambientes capazes de reconhecer e reagir a presença de
indivíduos diferentes.
Em [Ramos, Augusto e Shapiro, 2008] AmI é apresentada como uma visão da
sociedade da informação onde as pessoas convivem em ambientes inteligentes e com
interfaces intuitivas embarcadas em dispositivos ao seu redor, capazes de reconhecer o
ambiente e seus usuários e responder a diferentes estímulos por meio de sensores e
acionadores. Esse novo paradigma proporciona a melhoria da qualidade de vida das
pessoas por meio de sistemas e de serviços que usam dispositivos inteligentes,
25
personalizados e interconectados.
A extração de dados baseados em contexto utiliza dentre outras, técnicas de
Inteligência Artificial, Redes Neurais Artificiais, Agentes Inteligentes e Lógicas Fuzzy
[Hoon e Ramos 2010], [Sampaio et. al. 2012] e [Fariba 2011]. Tais técnicas permitem
que os sistemas de AmI sejam capazes de interagir com o usuário a partir dos dados
obtidos do contexto e das regras inferidas por componentes inteligentes do sistema.
Assim, usando essas técnicas ou um subconjunto delas, provavelmente a integração e a
comunicação de diversos dispositivos instalados em um ambiente residencial
automatizado, será melhorada.
2.2. Context-aware
Em [Schilit e Theimer 1994], é apresentado uma definição de contexto como
localização e identificação de pessoas e objetos, no entanto, outras definições mais
abrangentes são apresentadas em [Ryan et. al. 1997] e em [Dey, 1998] como sendo a
localização de usuários no ambiente, estado emocional do usuário, temperatura do
usuário, temperatura do ambiente, comportamento, entre outras características.
Pode-se definir o contexto no sentido mais genérico como uma informação
qualquer que pode ser usada para caracterizar uma situação envolvendo pessoas, objetos
e lugares que são considerados relevantes para a interação entre o usuário e o sistema.
Já o conceito de sensibilidade ao contexto define que tipos de processo ou informação
que melhor se adequará a determinada situação e pode ser aplicada de forma flexível em
qualquer entidade móvel, visando à descoberta de padrões pessoais coletando,
interpretando e respondendo ao usuário sobre os aspectos de outros dispositivos e do
ambiente [Zimmer 2004].
Um sistema é context-aware se usar um contexto para disponibilizar
informações ou serviços relevantes para o usuário onde a relevância depende da tarefa
solicitada. Existem diferenças entre os conceitos de context-aware e contexto. O
contexto trata das atividades, identidade, localização e tempo em que ocorreram as
ações, enquanto que o context-aware trata da apresentação, execução automática e
entrega (tagging) das informações contextuais [Abowd et. al. 1997].
2.3. Localização Indoor
Existem diversos métodos na literatura para calcular a localização e o mais conhecido
deles é usando o Global Position System (GPS). No entanto, para a localização indoor
esse método não é eficaz devida a dificuldade de recepção do sinal em um ambiente
fechado, [G. Sun, J. Chen, W. Guo, e K.J.R. Liu 2005].
Para minimizar esse problema surgiram técnicas que utilizam a potencia do sinal
WI-FI para identificar acess points e fazer a trilateração do sinal na esperança de
diminuir a distancia entre o objeto ou pessoa a ser localizado no ambiente [P. Bahl e V.
N. Padmanabhan, 2000]. A localização indoor baseada na potencia do sinal de rádio
(RSS), pode ser implementada por meio de algoritmos e métodos probabilísticos para
determinar o posicionamento do usuário por meio da distancia entre os pontos de
referência e o sinal obtido, no qual se aplicando o método K-Nearest Neighbor (KNN),
pode-se melhorar o desempenho da técnica de localização [Altintas e Tacha 2011].
Neste trabalho o tópico referente à localização indoor foi explorado baseado na
potencia do sinal Wi-FI e técnicas probabilísticas para melhoria da aquisição do
posicionamento do usuário dentro de um ambiente.
26
3. Trabalhos Relacionados
Em [Corchado, J.; Bajo, J.; Abraham 2008] foi apresentada uma arquitetura de
healthcare para monitorar idosos em uma casa de saúde. O sistema possibilitou o
acompanhamento de pacientes com a doença de Alzheimer, por meio de etiquetas
Radio Frequency Identiﬁcation (RFID) instaladas na residência e no pulso de cada
idoso monitorado. Quando o idoso se aproximava de alguma porta ou janela, o sistema
capturava os dados do dispositivo RFID no seu pulso e enviava o sinal ao servidor de
localização instalado na administração da casa.
O sistema foi integrado em uma rede sem fios, que permitia que enfermeiros e
médicos tivessem acesso à localização do paciente, usando um Personal Digital
Assistent (PDA). Os equipamentos utilizados para acessar os dados foram empregados
como clientes do sistema que acessavam uma base de dados comum a todos os
componentes.
Em [Zamora-Izquierdo et. al. 2010] foi apresentado uma arquitetura para home
automation (HAM), composta por um sistema de monitoramento e controle por meio de
vários dispositivos embarcados conectados a sensores e atuadores e centralizados em
uma casa inteligente. O HAM possuía também, partes modularizadas que podiam ser
integradas para monitorar todas as áreas de uma residência ou parte dela. A arquitetura
suportava a infraestrutura de segurança e acesso remoto via internet através de dois
métodos de acesso externo, o protocolo HTTP, usado para o servidor gateway que
permitia monitorar o acesso a residência e o protocolo UDP para se comunicar com
módulos de segurança e gateway remotos. O sistema ainda possuía entradas para um
módulo de comunicação que podia ser bluetooth, ZigBee ou barramento Controller
Area Network,(CAN-BUS), além de permitir a troca de mensagens por meio de Short
Message System (SMS).
Em [Bonino e Corno 2010] foi apresentada uma contribuição para estender os
ambientes domóticos inteligentes (IDEs) para suportar inteligência baseada em regras,
iniciando com um modelo formal em que regras são definidas para avaliar as
propriedades dos ambiente por meio de ontologias. Duas linguagens de regras foram
utilizadas a Semantic Web Rule Language (SWRL) e a JenaRules, para formalização e
avaliação da camada de razão do sistema. As engines nomeadas de Jess e Jena foram
comparadas e os resultados foram apresentados quanto à checagem de propriedades nos
requisitos de efetividade da base de inteligência para prevê comportamentos, por
exemplo, adaptação e interação proativa com o usuário.
Os autores avaliaram as regras usando dois diferentes benchmarks, um ambiente
doméstico pequeno composto por seis cômodos e um ambiente de escritório mais
complexo composto por cinqüenta e duas salas. Como resultado, foi apresentado que o
raciocínio baseado em regras pode ser efetivamente aplicado em ambientes inteligentes
para avaliar on-line o contexto e provê comportamentos proativos para o ambiente.
Em [Li e Wang, 2011] foi apresentada uma proposta para uma arquitetura lógica
para desenvolvimento de sistemas AmI. Foram analisadas as funcionalidade de um
framework para um middleware de context-aware que fez uso de ontologias para
modelar as informações de contexto em ambiente de computação pervasiva, e inserir
uma camada de razão em alto e baixo nível para auxiliar nas aplicações context-aware
em sistemas de AmI. Foram definidos no artigo, contexto, context-awareness e
ontologia e proposto pelos autores uma arquitetura para um middleware sensível a
contexto. A arquitetura apresentada possuía três camadas: Camada de informação de
27
acesso, composta por uma base de dados comum obtida por sensores e atuadores, a
camada de middleware de context-aware, usada para programar as funcionalidades de
representação do contexto, gerência do contexto, armazenamento do contexto e o
compartilhamento das informações de contexto, a camada de aplicação, responsável por
disponibilizar as informações contextuais para consumidores finais.
No trabalho apresentado em [Altintas e Tacha 2012] os autores melhoraram os
resultados do algoritmo KNN para uso em sistemas de localização indoor, integrando
uma memória de curto prazo, Short Term Memory (STM), onde as leituras de potência
do sinal são armazenadas. Considerando a capacidade de movimento limitado de um
usuário móvel em um ambiente interno, locais anteriores do usuário podem ser levados
em consideração para obter sua posição atual. Na abordagem proposta, as leituras de
potência do sinal foram refinadas com os dados históricos anteriores e comparados com
o mapa de rádio do ambiente. Os resultados da avaliação indicam que o desempenho do
KNN com as modificações apresentadas supera algoritmo KNN convencional.
Neste trabalho pretende-se apresentar uma arquitetura experimental para
automação e integração de ambientes inteligentes com dispositivos móveis
considerando a coleta e armazenamento de dados de sensores e atuadores para após
análise e filtragem, recomendar serviços para usuários de um ambiente. A proposta
concentra-se na construção de uma arquitetura que integre serviços baseados nas
informações de contexto e apresenta um protótipo para coleta de dados de ações em
atuadores e sensores.
4. Arquitetura proposta
A partir da avaliação inicial feita por meio da revisão dos trabalhos relacionados, foi
desenvolvida uma arquitetura experimental para o desenvolvimento do trabalho que é
apresentada na forma de diagrama de blocos divididos em quatro módulos
interconectados. Estes módulos permitem receber dados de entrada adquiridos por
sensores e atuadores diversos instalados em uma residência ou escritório para em
seguida fazer o pré-processamento e após essa fase, definir as políticas e estratégias para
tomada de decisão. O resultado final serão os serviços disponíveis baseados nos dados
dos sensores, atuadores e preferências do usuário.
Figura 1. Overview da Arquitetura proposta
28
A contribuição principal da arquitetura proposta neste trabalho é desenvolver o
módulo cognitivo para recomendar serviços para o usuário de um sistema domótico de
maneira a minimizar seu esforço e promover a configuração automática do ambiente
baseado nas informações processadas. A Figura 1 apresenta o overview que será
discutido nas subseções a seguir.
4.1. Módulo de Entrada
O módulo de entrada é composto por diversos sensores e atuadores representados aqui
como câmeras, sensores de presença, sensores de luminosidade, sensores de portas e
sensores de temperatura, responsáveis por coletar os dados do ambiente e do usuário.
Um exemplo de dados relacionados a sensores que podem ser coletados no ambiente
são as entradas e saídas de um usuário que por meio de um sensor de abertura e
fechamento de portas e uma micro câmera podem ser capturadas e armazenadas na base
de dados.
Outro exemplo são os atuadores representados aqui por fechaduras eletrônicas,
relés, controles remotos e acionadores de cortinas automatizadas. Os dados de atuadores
como no caso clássico de acionamento de lâmpadas por meio de relés são armazenados
na base de dados e poderão servir como ponto de partida para um sistema preditor de
comportamento após a análise e filtragem.
4.2. Módulo de Pré-processamento do Conjunto de Dados
O conjunto de dados apresentado na arquitetura trata-se de uma base de dados brutos
coletados dos sensores e atuadores. São formados por atributos que podem representar
uma pessoa, um objeto físico ou um local específico dentro do ambiente. Inicialmente
os dados são subdivididos em dados de sensores Ds e dados de atuadores Da. Essa
divisão se dá para facilitar a classificação dos dados para serem armazenados no
histórico.
A partir da leitura e armazenamento de dados por meio do bloco de conjunto de
dados de maneira separada, os dados de sensores e atuadores são armazenados em
tuplas para posteriormente serem analisados e filtrados.
A representação formal dos dados pode ser feita por meio de uma matriz de
objetos dada por Xn x d onde n representa o número de objetos e d o número
de atributos de entrada de cada objeto. O valor de d define a dimensionalidade dos
objetos, espaço de entrada ou espaços de atributos. A Tabela 1 apresenta um exemplo
de tuplas de dados coletados de um sensor de movimento. Na tabela podem ser
observados os dados de um sensor de abertura de portas com a ação executada, a data,
hora e local do acionamento, onde cada linha da tabela corresponde a uma tupla da base
de dados.
Tabela 1. Exemplo de tuplas em uma matriz
Ação
Data
Hora
Local
0
21/06/2013
07:42:32
Porta principal
1
21/06/2013
08:09:16
Porta principal
0
21/06/2013
08:11:06
Porta principal
1
21/06/2013
08:34:16
Porta principal
O conjunto de dados pode ser codificado em um banco relacional, em uma
29
estrutura de dados de vetores e matrizes ou em documentos bem formados, por
exemplo, um arquivo XML. Durante a fase de pré-processamento é necessário definir
técnicas para análise e filtragem de dados e durante essa fase a caracterização dos
dados, o tipo e a escala devem ser observadas [Faceli, et. al 2011]. Para coleta de dados
deste trabalho foi desenvolvido um banco de dados modelo relacional que será
apresentado na Seção 5.
A caracterização dos dados consiste em mapear os atributos dos objetos do
conjunto de dados, o tipo, define se o atributo é qualitativo ou quantitativo e a escala
define as operações que podem ser realizadas sobre os valores do atributo. A escala
pode ser nominal, racional ou intervalar.
A análise consiste na preparação dos dados para descrever os objetos por meio
de um vetor de características ou um conjunto de atributos de entrada. Por exemplo, um
objeto sensor de movimento tem como características, um id, local de instalação e a
data/hora do disparo. A partir da análise e filtragem desses dados, pode-se definir que
sensor disparou e quais os horários que normalmente ele dispara nesse caso isso é uma
característica de escala intervalar.
A análise e filtragem de dados apresentada no bloco de pré-processamento serão
feitas visando à extração das características necessárias para identificação de grupos e
objetos semelhantes no conjunto de dados e regras de associação que relacionam esses
grupos.
4.3. Módulo Cognitivo
O módulo cognitivo representa a inteligência do sistema e está dividido em três
subsistemas que são as políticas, que contém as regras para o subsistema de decisão e as
estratégias, que contém os algoritmos para inferência das políticas. Um exemplo
simples de políticas baseadas em regras IF THEN ELSE, que pode ser implementada
em um protótipo para alimentar um sistema de decisão pode ser visto na Figura 2 A.
Figura 2. Exemplo de um encadeamento de regras
O resultado final de um encadeamento de regras desse tipo pode gerar uma
árvore de inferência conectando todas as regras utilizadas. A Figura 2 B apresenta a
árvore gerada a partir das três regras IF THEN ELSE.
Nesse exemplo pode se observar que o resultado final C, será possível a partir do
resultado das operações anteriores combinadas entre si e nesse caso C será a resposta
para as premissas. É obvio que um sistema inteligente não deve ser baseado apenas
nesse tipo de regras, entretanto o exemplo serve para enriquecer a visão da arquitetura
30
que está sendo apresentada e para implementar um protótipo simples como prova de
conceito.
As estratégias para auxiliar na decisão que podem ser utilizadas na arquitetura
proposta variam desde o uso de algoritmos para agentes inteligentes baseados em
utilidades [Russell e Norvig, 2004] até métodos probabilísticos e modelos descritivos
[Faceli, et. al, 2011], isso depende da escolha do método a ser implementado no
subsistema de estratégias.
O subsistema de decisão por meio das políticas e das estratégias estabelecidas
define quais os serviços que podem ser disponibilizados para o usuário a partir da
percepção atual e do histórico gerando uma lista de serviços disponíveis.
4.4. Módulo de Saída
As saídas esperadas do sistema são os serviços disponíveis ao usuário de acordo com
suas preferências que passam a ser as ações nos atuadores retroalimentando o sistema.
Um exemplo de serviço pode ser a climatização do ambiente de acordo com a
temperatura ideal para uma determinada pessoa ocupante de um ambiente inteligente.
Nesse caso o ambiente pode se ajustar para os padrões aprendidos durante as fases de
treinamento.
Nos casos em que mais de um usuário esteja disputando o mesmo serviço o
subsistema de decisão poderá fazer a média ponderada e recomendar a temperatura ideal
para todos. Outro exemplo de serviços seria o de localização de periféricos mais
próximos do usuário, por exemplo, uma impressora. Nesse caso se o usuário desejasse
imprimir um trabalho em uma impressora diferente da que normalmente imprime, o
serviço de impressão o avisaria por meio de um sistema de mensagens que haveria uma
impressora mais próxima a ele.
Diversos serviços podem ser desenvolvidos usando a arquitetura para isso basta
construir as políticas e estratégias baseadas nas análises dos dados de sensores e
atuadores.
5. Desenvolvimento do Protótipo
Durante o desenvolvimento do trabalho foi necessário instalar e configurar o hardware
e o software usados no protótipo e para isso foram utilizados os dispositivos citados na
Tabela 2 os quais foram instalados nas dependências do laboratório de sistemas móveis
e Automação do ICET-UFAM e do CETELI-UFAM.
Tabela 2. Hardware e Software utilizados no experimento
Material
Quantidade
Kit Placa Rogercom Zigbee e COM USB Rogercom e Xbee Pro Series
2
Roteador TPLink TL-WR1043ND com taxa de transferência 300Mbts
1
Servidor WEB 1.6 GHz 2MB L3 cache, 2Gb de RAM, HD 500Gb
1
Smartphone Android 4.4.2 KitCat
1
Tablet Tab3 4.1.2 Jelly Beam
1
Sensor Infravermelho passivo 2000CF/IVP 2000SF
2
31
5.1. Configuração dos Módulos de Transmissão sem fio Xbee
Os módulos XBee utilizados no experimento podem ser configurados por meio de
comandos de modem AT via porta serial. Os comandos AT principais utilizados para a
configuração dos nós XBee são apresentados na Tabela 3, esses comandos podem ser
digitados diretamente em um terminal Linux. Um exemplo de comando para configurar
um módulo XBee como servidor pode ser digitado da seguinte forma: "ATMY1,
ATDL2, ATNIserver, ATWR, ATCN". É muito importante não esquecer que com
exceção do comando +++ todos os outros comandos precisam da tecla <enter> para que
o módulo XBee responda.
Tabela 3. Comandos AT para configuração do módulo XBee
Comando AT
Resposta do módulo
Significado
+++
OK
Pronto para receber comandos
ATMY
5001
Número identificado do nó de origem
ATDL
5000
Número identificado do nó de destino
ATNI
Servidor
Nome do nó
ATWR
OK
Grava as alterações no módulo Xbee
ATAP
0
Módulo API desabilitado
ATCN
OK
Sai do módulo de comando
5.2. Desenvolvimento do experimento do lado Servidor
A aplicação servidor tem como objetivo receber informações dos sensores dispostos no
ambiente, podendo ser sensores de luminosidade, temperatura, umidade, abertura e
fechamento de porta, sensores de presença, entre outros. Neste protótipo foi utilizado
sensores de presença, informando e armazenando em banco de dados as ações de
presença no ambiente e sensores de abertura e fechamento de portas. A Figura 3
apresenta o banco de dados desenvolvido de acordo com o módulo de
pré-processamento apresentado na arquitetura proposta.
Figura 3. Base de Dados Desenvolvida no Experimento
32
A modelagem do banco de dados apresentado na Figura 3 contem oito entidades
mapeadas a partir dos dados que se pretendia coletar na fase de experimentos. Por
exemplo, horário de entrada, saída para almoço, saída para lanche, idas ao banheiro e
permanência na mesa de trabalho. As entidades principais responsáveis pelo
armazenamento são o usuário, ligado a um ou mais dispositivos, as entidades sensor e
actuator, responsáveis por coletar dados de ação e de sensoriamento do ambiente, e a
entidade action, responsável por armazenar as ações dos atuadores e sensores.
O sistema de coleta de dados foi implementado da seguinte maneira: O usuário é
previamente cadastrado na base com seus respectivos dipositivos que podem executar
ações nos atuadores e verificar a situação dos sensores que em seguida são armazenadas
na entidade ação. Todas as ações armazenadas na base poderão ser avaliadas pelo
módulo cognitivo para extrair características de contexto e recomendar serviços ao
usuário baseado no histórico da base e nas regras definidas no módulo cognitivo.
A base de dados permite o armazenamento dos dados de sensores e atuadores
que são relacionados com as ações executadas por eles. Cada usuários está relacionado
com os dispositivos móveis que utiliza e esses dispositivos também são interligados às
ações por meio do endereço de MAC. Desta forma é fácil mapear as atividades dos
sensores e atuadores, dispositivos móveis e, por sua vez, os usuários donos dos
dispositivos. No experimento foi utilizado o endereço MAC do dispositivo para
comparar com o endereço armazenado na base de dados somente para substituir o uso
das tecnologias de localização porque da forma como a solução foi construída é possível
associar na base de dados de sensores qual mesa de trabalho pertence a que usuário e se
o dispositivo dele encontra-se no escritório.
5.3. Desenvolvimento do experimento do lado Cliente
Para acesso ao sistema de controle, o usuário deve ter um dispositivo móvel
(smartphone, tablet ou notebook) conectado a rede sem fio. Ao iniciar a aplicação o
sistema busca obter o endereçamento físico local do dispositivo (endereço MAC local) e
o envia ao servidor, como uma requisição do tipo string, por meio do protocolo de
hipertexto HTTP usando o método POST. Por sua vez o servidor recebe a requisição e
por meio da consulta à base de dados, confirma a existência do cadastro do dispositivo
do usuário.
Figura 4. (A) Maquete utilizada no experimento (B) Aplicativo móvel desenvolvido em
Android
33
Confirmada a permissão de acesso do dispositivo, o servidor retorna uma
mensagem de confirmação para que seja mostrada ao usuário. Após o acesso ao sistema
o usuário tem a possibilidade de realizar controles do ambiente como ligar e desligar
lâmpadas condicionador de ar e outros dispositivos que possam ser monitorados. Essas
atividades feitas no ambiente por meio de um smartphone ou tablet, são armazenadas na
base de dados para posterior análise contextual.
Logo após a identificação e execução da ação, o servidor envia uma mensagem
de confirmação informando que a ação solicitada foi executada. Caso haja erro de
identificação do dispositivo o servidor informa e reporta à aplicação o erro ocorrido.
A Figura 4 apresenta o resultado da aplicação móvel acessando os sensores em
uma maquete desenvolvida no laboratório para simular o acionamento de lâmpadas nos
comôdos de uma residência e a Figura 5 apresenta o ambiente real da coleta de dados
feita usando sensores e atuadores em mesas e portas de um laboratório da universidade.
Figura 5. (A) Mesa de trabalho com sensor de presença (B) Porta com sensor de abertura
e fechamento (C) Coleta de Dados dos sensores e atuadores
Na Figura 5 A e B, pode se vê que os sensores estão posicionados para capturar
o movimento nas mesas de trabalho dos usuários enquanto que o sensor de abertura de
porta do tipo contato, foi instalado de modo a permitir a coleta dos dados das aberturas e
fechamentos da porta do laboratório. A Figura 5 C apresenta o log da inserção dos
dados na base.
6.
Resultados e Conclusões
O presente trabalho apresentou uma arquitetura experimental para automação e
integração de ambientes inteligentes com dispositivos móveis. A arquitetura foi dividida
34
em módulos na qual foram construídos dois protótipos experimentais, um cliente para
dispositivos móveis e um servidor para coletar dados de sensores e atuadores. A
arquitetura permitiu a integração desse dispositivos com sensores e atuadores para
monitorar um ambiente e disponibilizar serviços baseados no histórico de uso.
O conjunto de dados apresentado na arquitetura foi desenvolvido usando o banco
de dados relacional MySQL e suportou o armazenamento de uma quantidade
significativa de dados dos sensores, (40.000 tuplas) durante um mês de coleta diárias
sem travamentos. Esses dados serão tratados na camada cognitiva na próxima fase do
projeto, por meio das ações baseadas em estratégias e regras tendo como resultado final
a recomendação do uso de equipamentos de acordo com o perfil do usuário extraídos da
base de dados.
Um protótipo para dispositivos móveis simulando um ambiente residencial e de
escritório foi desenvolvido para testar a inserção automática dos dados de sensores e
atuadores bem como a identificação automática do dispositivo móvel do usuário por
meio do endereço físico de rede, permitindo simular a identificação da entrada e saída
do usuário no ambiente monitorado.
Além da coleta de dados em ambiente real foi disponibilizado também uma
maquete para teste de acionamentos de equipamentos eletrônicos para simular o uso de
lâmpadas e condicionadores de ar do ambiente.
Os resultados do trabalho foram a coleta de dados para a formação de uma base
de conhecimento, a integração entre o hardware dos sensores e atuadores com a
aplicação servidor e o acesso aos dados via rede sem fio com autenticação automática
feita pelo dispositivo móvel através da verificação do endereço físico do dispositivo na
rede.
A Estratégia utilizada para armazenar os endereços e reconhecer o usuário por
meio de seu dispositivo, foi modelar os dados baseaando-se nas ações dos dispositivos e
não na ação do usuário. Em outras palavras, os dispositivos é que executam as ações
assim que se conectam na rede sem fio, sem a necessidade de intervenção humana.
A arquitetura está em fase de teste com possíveis modificações e adequações
futuras com a integração de agentes no módulo cognitivo e gerência de contexto para
gerenciar e filtrar os dados no módulo de pré-processamento
Os próximos passos da pesquisa serão construir um preditor para analisar os
dados coletados na base e traçar o perfil do usuário para recomendar os serviços de uma
residência ou escritório automatizados.
Agradecimentos
Agradecemos a Fundação de Amparo à Pesquisa do Estado do Amazonas,
FAPEAM, a CAPES ao CNPq ao PPGI-UFAM ao CETELI-UFAM e ao ICET-UFAM
pelo apoio financeiro, materiais e laboratórios de pesquisa.
Referências
Abowd, G.D., Dey, A.K., Orr, R., Brotherton, J. Context-Awareness in Wearable and
Ubiquitous Computing. 1 International Symposium on Wearable Computers (1997)
179-180.
35
Altintas, B., & Serif, T. (2011). Improving RSS-Based Indoor Positioning Algorithm
via K-Means Clustering. Wireless Conference 2011-Sustainable.
Altintas, B., & Serif, T. (2012). Indoor Location Detection with a RSS-based Short
Term Memory Technique (KNN-STM), (March), 794–798.
Aarts, E.; , "Ambient intelligence: a multimedia perspective," Multimedia, IEEE ,
vol.11, no.1, pp. 12- 19, Jan.-March 2004.
Bonino, Dario; Fulvio, Corno. Rule-based intelligence for domotic environments,
Automation in Construction, Volume 19, Issue 2, March 2010.
Corchado, J.; Bajo, J.; Abraham, Gerami: Healthcare Delivery IN Geriatric Residences.
IEEE Intelligent Systems, 23(2):19-25, 2008.
Dey, A.K. Context-Aware Computing: The CyberDesk Project. AAAI 1998 Spring
Symposium on Intelligent Environments, Technical Report SS-98-02 (1998) 51-54
Faceli, Katti; Ana, Carolina, Lorena; João, Gama; André, C., P., L., F., de Carvalho.
Inteligência Artificial uma Abordagem de Aprendizado de Máquina. LTC 2011.
Fariba Sadri. 2011. Ambient intelligence: A survey. ACM Comput.
G. Sun, J. Chen, W. Guo, and K.J.R. Liu, “Signal processing techniques
in
network-aided positioning: a survey of state-of the-art positioning design.” IEEE
Signal Processing Magazine, vol. 22, no. 4, pp 12-23,
2005
Hoon Ko; Ramos, C.; , "A Survey of Context Classification for Intelligent Systems
Research for Ambient Intelligence,"Complex, Intelligent and Software Intensive
Systems (CISIS), 2010 International Conference on, vol., no., pp.746-751, 15-18
Feb. 2010.
Honkavirta, V., Perala, T., Ali, S. and Piche, R. 2009 A comparative survey of WLAN
location fingerprinting Methods. Proceedings of the 6th Workshop on Positioning,
Navigation and Communication.
Li, H., & Wang, J.. Application Architecture for Ambient Intelligence Systems Based
on Context Ontology Modeling. 2011 International Conference on Internet
Technology and Applications.
Krohn, A.; , "Ubiquitous computing and the Internet," Applications and the Internet,
2004. Proceedings. 2004 International Symposium on , vol., no., pp. 9, 2004.
P. Bahl and V. N. Padmanabhan, “RADAR: an in-building RF-based user location and
tracking system”. NFOCOM 2000. 19th Annual Joint
Computer and Communications Societies, vol.
36
Conference of the IEEE
2, pp. 775-784, 2000.
Ramos, C., Augusto, J. C., & Shapiro, D. (2008). Ambient Intelligence—the Next Step
for Artificial Intelligence. IEEE Intelligent Systems, 23(2), 15–18.
Ryan, N., Pascoe, J., Morse, D. Enhanced Reality Fieldwork: the Context-Aware
Archaeological Assistant. Gaffney,V., van Leusen, M., Exxon, S. (eds.) Computer
Applications in Archaeology (1997).
Russel, Stuart; Peter, Norvig. Inteligência Artificial “tradução da segunda edição”. RJ.
Campus 2004.
Sampaio, D.; Reis, L.P.; Rodrigues, R.; , "A survey on Ambient Intelligence
projects,"Information Systems and Technologies (CISTI), 2012 7th Iberian
Conference on, vol., no., pp.1-6, 20-23 June 2012.
Schilit, B.; Adams, N.; Want, R.; "Context-aware computing applications,"Mobile
Computing Systems and Applications, 1994. Proceedings., Workshop on, vol., no.,
pp.85-90, 8-9 Dec 1994.
Yang, C., Huang, Y. and Zhu, X., 2007. Hybrid TDOA/AOA method for indoor
positioning systems.
Zamora-Izquierdo, M.A.; Santa, J.; Gomez-Skarmeta,
́
A.F., "An Integral and
Networked Home Automation Solution for Indoor Ambient Intelligence," Pervasive
Computing, IEEE , vol.9, no.4, pp.66,77, October-December 2010
Zimmer, T.; , "Towards a better understanding of context attributes," Pervasive
Computing and Communications Workshops, 2004. Proceedings of the Second
IEEE Annual Conference on , vol., no., pp. 23- 27, 14-17 March 2004.
37
38
Florianópolis - SC
(WoCCES 2014)
Sessão Técnica 2
Modelo de Arquitetura em Camadas para
Interconexão de Sistemas em VANT
Emerson Alberto Marconato e Kalinka R. L. J. Castelo Branco
ICMC – USP – Instituto de Ciências Matemática e de Computação – Universidade de São
Paulo
Avenida Trabalhador São-carlense, 400 - Centro CEP: 13566-590 - São Carlos - SP - Brasil
{emerson, kalinka} @icmc.usp.br
Resumo
Modelos de arquitetura têm sido utilizado para permitir o desenvolvimento mais
adequado e estruturado de sistemas, desde os mais simples até os mais complexos. A
utilização de modelos em sistemas embarcados, principalmente quando se trata de sistemas
embarcados críticos, como é o caso de veículos aéreos não tripulados, visam a permitir
conformidades de padrões, redução no tempo de produção, redução e facilidade no
processo de manutenção e desenvolvimento. Sistemas embarcados críticos possuem
requisitos específicos, tais como alta confiabilidade e resposta em tempo real, segurança e
desempenho. A definição de um modelo arquitetural que permita que esses quesitos sejam
levados em consideração, e que propicie o atendimento aos padrões além de permitir o
desenvolvimento correto e acelerado é inovador e deve permitir que a comunidade
científica e a industria venham a ter benefícios com a sua concepção. Nesse sentido, este
trabalho visa o desenvolvimento de um modelo arquitetural para a interconexão de sistemas
de veículos aéreos não tripulados (VANTs).
1. INTRODUÇÃO
Os avanços tecnológicos e científicos vêm proporcionando diversas mudanças nos mais
variados setores da indústria, comércio e serviços. Sistemas embarcados são sistemas
computacionais que, de modo geral, fazem parte de um sistema maior. Esses sistemas
proveem, em sua maioria, monitoramento e controle em tempo real para todo o sistema. A
apresentação de requisitos especiais e o fornecimento de um conjunto pré-definido de
tarefas dedicadas a uma aplicação de tempo real são características dos sistemas
embarcados (LAZIC´; VELAŠEVIC´, 2004). Esses sistemas são considerados críticos
quando eventos de falha possibilitam perdas de vidas humanas ou de ativos de alto valor
(DUNN, 2003)(ARMOUSH; BECKSCHULZE; KOWALEWSKI, 2009) (KUMAR;
RAMAIAH; KHANAA, 2011)(YI; CAI; YUE, 2008).
Tanto em hardware quanto em software os sistemas embarcados têm se tornado cada vez
mais complexos. Sistemas multicore e multiprocessadores estão se tornando comuns, o que
tem aumentado ainda mais a complexidade do software (KOULOHERIS, 2003). Por outro
lado, eles estão se tornando mais e mais comuns de modo que podem ser vistos tanto em
ambientes domésticos como em ambientes profissionais, nos quais têm sido utilizados para
41
o controle ou gerenciamento de informação. Graças aos avanços da tecnologia esses
sistemas contam hoje com maior capacidade de processamento, memória e adaptação a
diferentes necessidades, podendo inclusive se comunicar com qualquer outro dispositivo,
embarcado ou não.
Um VANT constitui uma aplicação típica de um sistema embarcado crítico. O termo
VANT foi adotado pela FAA (Federal Aviation Administration) e pela comunidade
acadêmica internacional para designar sistemas que incluem não apenas os aviões, ma s
todos os elementos associados, tais como o payload, a estação de controle terrestre e os
links de comunicação (GAO, 2008). VANTs têm sido amplamente utilizados na agricultura
de precisão, segurança nacional (missões militares) e monitoramento ambiental. Diversos
trabalhos já foram publicados nessa área, demonstrando a viabilidade do uso desses
veículos como ferramentas importantes para realização da agricultura de precisão e no
monitoramento ambiental (TRINDADE JR, et al., 2010), (BRANCO, et al., 2011),
(TRINDADE, et al., 2012) por exemplo.
Existem diferentes tipos de VANTs que apresentam, inclusive, diferentes capacidades.
Algumas aeronaves podem voar de forma autônoma, seguindo uma trajetória de voo préprogramada (baseada em um grid ou uma sequência de waypoints) (TRINDADE JR, et al.,
2010), enquanto outras voam recebendo comandos a partir de estações terrestres operadas
por pilotos.
O tamanho da aeronave pode variar desde o micro até o grande, e a estação de controle
terrestre pode ser implementada em smartphones, tablets, notebooks ou redes de estações
de trabalho (estações de controle distribuídas).
Desse modo, a aeronave pode variar não apenas em tamanho, mas também na forma, no
tipo de propulsão e no desempenho. A interface homem-máquina pode variar desde um
joystick até uma interface de usuário tangível (por exemplo, uma mesa tangível com
realidade aumentada). O desempenho dos links de comunicação e o tipo de carga também
são muito importantes para cumprir a missão destinada ao sistema, dentre as quais pode-se
citar, dentre outras, a utilização em agricultura de precisão, vigilância de fronteiras e o
transporte de cargas (RODRIGUES, et al., 2011a),(BRANCO, 2012),(DOD, 2002), (DOD,
2005), (DOD, 2007) e (DOD, 2009).
Em um futuro um pouco mais distante espera-se que as únicas aeronaves tripuladas que
deverão permanecer atuantes são as que transportam passageiros, a exemplo do que ocorre
em outros sistemas de transporte, por exemplo, o metroviário no qual o condutor precisa
atuar somente em emergências.
Esse uso crescente dos VANTs deve fazer com que eles se tornem comuns, passando a
ser comercializados de forma mais ampla. Nesse cenário, arquiteturas que permitam a
organização e a definição mais específica dos componentes que compõem esses sistemas
embarcados (os VANTs), facilitarão o desenvolvimento de hardware e software que os
compõem, permitindo que esses veículos possam ser inseridos e incorporados mais
facilmente ao espaço aéreo e contribuindo para a sua disseminação.
Uma vez que os componentes de um VANT podem ser divididos em segmento aéreo e
segmento terrestre, e que cada um desses segmentos pode ser subdividido, a subdivisão
desses segmentos em camadas permite que o sistema seja dividido em subsistemas que
42
possam ter implementações diferentes e ajuda a separar em diversos níveis de criticidade as
partes que compõem um sistema complexo.
Visando o desenvolvimento de um modelo que atenda essas características, propomos o
LARISSA (Layered Architecture Model for Interconnection of Systems in UAV ) que o
título em Inglês para Modelo de Arquitetura em Camadas para Interconexão de Sistemas
em VANT.
Dessa forma, esse artigo está organizado como segue: a seção 2 apresenta os requisitos
do modelo de arquitetura para VANTs, a seção 3 descreve os principais trabalhos
relacionados, a seção 4 detalha o modelo proposto e a seção 5 discute sobre os benefícios
do LARISSA.
2. REQUISITOS DO MODELO DE ARQUITETURA
Um modelo constitui uma representação de abstrações, a partir das quais podem-se
avaliar, de forma racional, as propriedades de instâncias deste modelo. Qualquer modelo
deve permitir descrever o conjunto de todas as instâncias possíveis do conceito previamente
modelado.
Um modelo de referência, por outro lado, não está diretamente amarrado a nenhum
padrão, tecnologia ou outro detalhe de implementação concreta. Ele procura oferecer uma
semântica comum que pode ser usada de forma não ambígua através e entre
implementações diferentes. Nesse sentido, um modelo de referência tem a intenção de
oferecer um alto nível de artefatos comuns.
Na literatura, os termos modelo arquitetural, arquiteturas, arquiteturas de referência e
modelos de referência, são tratados como sinônimos, apesar de terem significados distintos,
mesmo que em alguns casos essa diferença seja sutil.
Arquitetura, por si só, é uma estrutura que identifica, define e organiza componentes. O
relacionamento e os princípios de projeto dos componentes, funções e interface
estabelecidas entre subsistemas também podem ser definidos por uma arquitetura (GRANT,
2005).
Por outro lado, um modelo de referência para uma arquitetura é uma arquitetura na qual
as entidades, relacionamentos e unidades de informação envolvidos nas interações entre e
dentro dos subsistemas e componentes são definidos e modelados. Em resumo, é um
modelo que incorpora o objetivo básico ou a ideia do sistema e pode ser considerado como
uma referência para várias finalidades (JUN, et al., 2009) e (REGLI, et al., 2009). O termo
modelo de arquitetura utilizado neste trabalho reflete exatamente essa última afirmação:
incorporar o objetivo básico e as ideias do sistema.
O uso crescente dos VANTs deve fazer com que eles se tornem cada vez mais comuns.
Neste cenário, as técnicas propostas neste trabalho facilitarão o desenvolvimento de
aplicações automatizadas de VANTs, permitindo a massificação de missões, e ainda, que
esses veículos possam ser inseridos e incorporados mais facilmente ao espaço aéreo,
contribuindo para a sua disseminação.
43
3. TRABALHOS RELACIONADOS
É imprescindível observar o estado da arte dos VANTs em relação aos modelos
arquiteturais, arquiteturas e suas variantes adotadas. Sendo assim, seguem os que se
destacaram durante a revisão bibliográfica devido tanto às semelhanças com o modelo
proposto quanto ao fato de abordarem tópicos relevantes para o trabalho.
A. Arquiteturas Tradicionais (Federadas)
O NIST (National Institute of Standards and Technologies) provê um modelo de
referência para VANTs (NIST, 2002). Este modelo de arquitetura é conhecido como
modelo convencional ou Federado, onde cada unidade de processamento tem seu projeto e
finalidade de uso específicos ou seja não compartilhados. Os trabalhos que seguem,
utilizam esta abordagem.
1. O Trabalho de Pastor, Lopez e Royo
O trabalho proposto em (PASTOR; LOPEZ; ROYO, 2007) baseia-se em uma arquitetura
de hardware e software desenhada para operar o controlador de missão e payload de
mini/micro VANTs. Segundo os autores a inovação da proposta está no uso de uma
arquitetura de hardware distribuída facilmente escalável pelo uso de LAN, arquitetura de
software baseada em subscrição de serviços, abstração da camada de comunicação e fluxo
de execução baseado no planejamento de missão. Segundo os autores, o alto nível de
modularidade oferecido por uma LAN provê flexibilidade para acoplar o tipo de
microprocessador mais adequado ao uso do módulo, atendendo seus requisitos funcionais.
2. MCAP
Em (OLSON; BURNS, 2005) é proposto um modelo de arquitetura. Trata-se da fase III
do projeto denominado MCAP (Manned / Unmanned Common Architecture Program),
utilizado pelo Exército norte-americano para uso em VANTs dos tipos FCS (Future
Combat Systems - Sistemas de Combate do Futuro) e C4ISR (Command, Control,
Communications, Computers, Intelligence, Surveillance and Reconnaissance - Comando,
Controle, Comunicações, Computadores, Inteligência, Vigilância e Reconhecimento).
A arquitetura MCAP, fase III, é baseada em componentes eletrônicos e software
prateleira - COTS e interfaces de padrões abertos. Os objetivos do desenvolvimento
modelo foi o de definir e desenvolver uma arquitetura capaz de suportar uma série
plataformas de VANTs do Exército norte-americano demonstrando o desempenho
sistema resultante em ambiente de laboratório.
3. RFCSA
de
do
de
do
Em (DENG; MA; ZHU, 2012) os autores propõem um projeto denominado
Reconfigurable Flight Control System Architecture (RFCSA) ou arquitetura reconfigurável
para sistemas de controle de voo. O desenvolvimento do projeto foi realizado seguindo os
seguinte pré-requisitos: Interface entre módulos simples e unificada - O módulo funcional
deve ser fácil de ser adicionado, removido ou substituído para aplicações específicas;
Projeto fácil para aplicações de alto nível - Baixo nível de necessidade de implementar
detalhes permite que o usuário desenvolva aplicações de alto nível facilmente; Reutilização
de Hardware e Software - O hardware e software desenvolvidos para uma aplicação podem
ser portados para outra sem necessidade de grandes modificações; Baixo custo - O produto
44
deve ser barato, expandindo o mercado de pequenos VANTs; Confiável - O hardware e
software devem ser de fáceis desenvolvimento e verificação.
A RFCSA consiste de uma série de módulos que atendem aos cinco requisitos citados
anteriormente. Todos os módulos são lógicos e físicos conectados via interface de módulos.
A interface de módulo é unificada.
4. LMA
O projeto apresentado por (NETO, et al., 2012) trata de uma arquitetura embarcada
modular, composta de três níveis: sistemas embarcados, link de comunicação e sistema de
navegação inercial.
O propósito do projeto é projetar e construir uma plataforma de VANT para
desenvolvimento e pesquisa de comportamento autônomo. A arquitetura proposta é
constituída por componentes eletrônicos embarcados modulares e protocolos de
comunicação baseados no modelo OSI. Esta arquitetura modular consiste de um circuito
principal com um microcontrolador/processador e uma série de módulos necessários para a
realização das tarefas, tais como: Unidade inercial e não inercial, unidade de auxílio à
navegação, acelerômetros, magnetômetro, barômetro, GPS, unidade de controle do motor e
outros.
B. Arquitetura IMA
Cabe destaque em detrimento aos outros modelos e arquiteturas, a IMA (Integrated
Modular Avionics), devido esta constituir uma arquitetura utilizada em novos projetos de
aeronaves convencionais e também em projetos de VANTs.
Prisaznuk (PRISAZNUK, 1992) propôs a IMA, um modelo integrado de aviônicos
proposta inicialmente para ser utilizada na aviação comercial e militar. Ela é definida em
torno do conceito de módulos de alto poder de processamento computacional com sistema
operacional que permite processamento independente do processamento do software
aplicativo. Os módulos de hardware compartilham recursos e são alocados em gabinetes, os
quais possuem interfaces bem definidas com a aeronave.
Uma vantagem da IMA em relação a federada é a economia de espaço, peso e consumo
de energia ou SWaP (Space, Weight, and Power), devido ao fato de uma única unidade
executar várias funções. Outra vantagem é a consolidação do hardware, pois tem-se vários
aplicativos sendo executados em menos processadores (WIND RIVER INC, 2008).
Recentemente, a arquitetura IMA vem sendo aplicada na concepção de VANT. Isso
pode ser observado a partir dos trabalhos encontrados na literatura aberta.
1. O Trabalho de Ilarslan,Bayrakceken and Arisoy
O projeto proposto por (ILARSLAN; BAYRAKCEKEN; ARISOY, 2011) baseia-se no
desenvolvimento de um sistema aviônico para um mini VTOL (Vertical Take-Off and
Landing - decolagem e pouso vertical) de propósitos acadêmicos para estudo da dinâmica
de voo, utilizando uma arquitetura derivada da IMA.
A construção de um mini VANT é possível, segundo os autores, devido ao surgimento
de novas tecnologias como os motores elétricos do tipo brushless (ausência de sistema de
escovas para alimentação elétrica do induzido) e as baterias de Li-Po (Lithium Polymer)
45
que são mais leves se comparadas às baterias de chumbo-ácido ou níquel-metal, mais
comuns de serem encontradas. Os objetivos do projeto são rever os conceitos da arquitetura
de sistemas aviônicos e desenvolver algoritmos de controle de voo. Os autores entendem
que além do conceitos básicos da IMA, são ainda pré-requisitos desta arquitetura a
aplicação de padrões abertos e uso de módulos comuns hardware e software, desde o
barramento de dados até linguagem de software, o uso de equipamento de prateleira Commercial-of-the-shelf (COTS) em todos os níveis, o uso de Sistemas Operacionais de
Tempo Real - Real Time Operating Systems (RTOS) comercialmente disponíveis que
suportem proteção (DO-178C), segurança (MILS - Multiple Independent Levels of
Security/Safety ) e padrões de particionamento (ARINC-653) e o desenvolvimento de
softwares que atendam os padrões exigidos.
2. ANKA
Outro projeto que faz uso da arquitetura IMA é o da estação de controle terrestre
utilizado no Sistemas de VANTs da força área da Turquia, conhecido como programa
ANKA (KAYAYURT, et al., 2011). Este trata-se da estação de controle terrestre utilizada
em conjunto com um VANT da categoria MALE (Medium Altitude Long Endurance Altitude média e longa duração) que voa a 30.000 pés de altitude - cerca de 9.144m e um
raio de alcance de 200 Km. A estação de controle terrestre utiliza dois tipos de softwares,
os de tempo real, responsáveis pelo controle de voo, telemetria e interface homemmáquina, que são desenvolvidos em linguagem ANSI C e são executados em dois
computadores PowerPC, trabalhando em sistema de redundância tipo Mestre/Escravo e os
de não tempo real, responsáveis pela gravação da telemetria e imagens, teste de pré-voo e
outra funcionalidades, que são desenvolvidos com metodologia orientada a objetos e
linguagem C# e .Net.
O desenvolvimento de ambos os tipo de software seguem alguns padrões:
- Uso da arquitetura geral e mensagem de interfaces para estações de controle terrestre,
especificados no documento OTAN STANAG 4586 (NATO/OTAN, 2007);
- Guia para desenvolvimento de softwares críticos para aviônicos, que define processos,
objetivos e atividades para cada nível de criticidade, padronizados pelo DO-178B emitido
pela RTCA (Radio Technical Commission for Aeronautics) (PANICKER, 2001);
- Desenvolvimento de software com particionamento de tempo e espaço, utilizando os
padrões IMA e ARINC-653.
Segundo os autores, o uso da IMA no projeto de software de tempo real empregado na
estação de controle terrestre auxiliou na modularização, proteção e divisão de tempo nos
componentes do software. A utilização deste modelo permitiu um desenvolvimento no qual
cada desenvolvedor era responsável por um módulo e um deles foi responsável pela
integração destes, o que facilitou o desenvolvimento e verificação do produto final.
3. Linux-based ARINC 653
O trabalho apresentado em (JIN, et al., 2012) os autores optaram pela IMA como
alternativa à arquitetura Federada devido ao crescente uso de recursos computacionais nos
aviônicos estarem gerando problemas de SWaP (Size, Weight, and Power - Tamanho, Peso
e Energia).
46
Os autores entendem que o uso dos conceitos da IMA são aplicáveis na construção de
um pequeno VANT de baixo custo, permitindo fácil desenvolvimento e extensão, e que
permite também a utilização de hardware de prateleira - COTS e software livre que
implemente a ARINC 653, que era objetivo proposto no projeto.
Esta seção apresentou os conceitos e definições de arquiteturas, modelos, modelos de
referência. Vários foram os trabalhos apresentados que auxiliam na definição das razões
para a construção de um novo modelo arquitetural para interconexão de sistemas para
veículos aéreos não tripulados.
Ademais, os artigos relacionados a VANTs encontrados na literatura apresentam
VANTs implementados usando abordagens tradicionais (VALAVANIS, 2007), (DOD,
2002), (DOD, 2005), (DOD, 2007) e (DOD, 2009). Por outro lado, Existem roadmaps que
ilustram os avanços esperados para os VANTs, publicados periodicamente por
organizações militares, como a Força Aérea dos Estados Unidos (USAF, 2009) e, nesses,
citam-se que para o futuro deve-se adotar uma arquitetura aberta, padronizada e escalável
que permitirá a adição rápida de funcionalidades modulares.
Mesmo existindo vários modelos e arquiteturas na literatura aberta, nenhum dos modelos
apresentados contempla todos os requisitos necessários para a confecção de um VANT que
não seja específico. Um resumo dos requisitos atendidos por cada um dos trabalhos é
apresentado na Tabela 1.
-
-
√
parcial
√
parcial parcial
parcial
-
parcial
√
-
-
-
-
-
√
Monitoramento e controle
parcial
-
parcial parcial
parcial
-
√
√
Navegação e serviços
parcial
√
parcial
√
√
parcial
parcial
√
Missão
√
√
parcial
√
√
-
√
√
Física do segmento terrestre
-
-
-
parcial
-
√
-
√
Estação de controle terrestre
-
parcial
-
parcial
√
√
parcial
√
RTOS distribuída
Abstração do sistema
-
47
√
LARISSA
√
Linux-based
ARINC 653
parcial parcial
ANKA
parcial
Física do segmento aéreo
LMA
Trabalho de Pastor,
Lopez e Royo
-
Camada / Projeto
RFCSA
MCAP
Trabalho de
Ilarslan, Bayrakceken
e Arisoy
Tabela 1
Comparativo entre os principais trabalhos encontrados na literatura aberta e o LARISSA.
A proposta aqui apresentada difere das demais revistas, pois trata a arquitetura em um
nível de abstração mais alto. Nenhuma delas estabelece ou especifica o nível de arquitetura
aqui vislumbrado, sendo as referências sobre modelos de arquitetura em camadas para
interconexão de sistemas em VANT quase inexistentes.
4. LARISSA: LAYERED ARCHITECTURE MODEL FOR INTERCONNECTION OF
SYSTEMS IN UAV
Neste modelo, os componentes de um VANT podem ser divididos em um segmento
aéreo e um segmento terrestre. O segmento aéreo é hierarquicamente composto pela (i)
camada física, (ii) camada RTOS (Real Time Operating System) distribuída, (iii) camada de
abstração do sistema, (iv) camada de monitoramento e controle, (v) camada de navegação e
serviços e (vi) camada de missão. O segmento terrestre é dividido em (i) uma camada física
e (ii) uma camada de estação de controle terrestre.
A separação em camadas permite que o sistema seja dividido em subsistemas que podem
ter implementações diferentes e auxilia a separação das partes que compõem um sistema
embarcado crítico complexo em diferentes níveis de criticidade. Dessa forma, as vantagens
proporcionadas pela arquitetura orientada a serviços podem ser aplicadas nas seções de
baixa criticidade, tornando o desenvolvimento dessas seções mais simples e flexível.
Dentre as vantagens proporcionadas, pode-se citar: configuração separada do ambiente,
melhoria da reusabilidade e manutenção, maior nível de abstração e de interoperabilidade,
interfaces mais interativas entre dispositivos, certificação dos componentes e sistemas de
informação, além da facilidade na utilização de serviços fornecidos por servidores externos
ao sistema.
Além das camadas e subcamadas, o modelo ora proposto irá definir os limites de cada
camada, delimitando até que ponto uma camada atua na arquitetura. Definir a função de
cada camada, ou seja, o que cada camada realiza, utilizando protocolos padronizados e
definir serviços tais como SOA e parâmetros para uso das especificações dos protocolos e
troca de informações entre as camadas.
Estas camadas podem ser representadas por meio de modelos, os quais tem o propósito
de servirem de guias para elaboração dos sistemas VANTs, especificando como será a
interligação entres os diversos componentes tais como sensores, circuitos de controle, GPS,
payload, sensores, comunicação com a estação de controle terrestre, dentre outros.
Na Tecnologia da Informação, uma arquitetura em camadas é utilizada para definir as
responsabilidades específicas de cada camada e a interligação entre elas. Baseadas em um
modelo de arquitetura, o fabricante de hardware ou o projetista de software podem
desenvolver seus produtos sabendo exatamente em que camada ele irá interagir no VANT,
quais são os parâmetros de entrada e saída ou qual o tipo de conexão deve ser utilizada.
A Figura 1 ilustra o modelo de arquitetura proposto de forma hierárquica.
48
Figura 1: O modelo proposto: LARISSA.
Como são camadas hierarquicamente composta, cada camada é composta por subníveis,
os quais descrevemos resumidamente:
A. Camada Física
A camada Física do segmento Aéreo é a camada de hardware da aeronave que pode ser
decomposta nas subcamadas de Estrutura, Aviônicos, Energia e Sistemas Auxiliares. Sendo
que cada subnível pode ser subdivido em subníveis mais específicos. A subcamada de
49
Estrutura representa as categorias de aeronaves utilizadas como VANT segundo suas
características aerodinâmicas. Os sistemas eletrônicos da aeronave, são descritos na
subcamada de Aviônicos, sendo esta composta por uma série de subcamadas. Os sistemas
de fornecimento de energia para o VANT, assim como os sistemas propulsão são tratados
pela subcamada de Energia. Por fim a camada Física conta com uma subcamada de
Sistemas Auxiliares. Esta subcamada divide-se em Mecanismos de Pouso e Mecanismos de
Decolagem.
B. Camada RTOS Distribuído
A camada de RTOS Distribuído, descreve um conjunto de APIs utilizados pelo sistema
operacional de tempo real embarcado na aeronave, sejam estes utilizado como entrada para
o RTOS ou uma saída deste. Na subcamada de Driver estão contidas as APIs de Drivers de
Hardware exceto os de Rede e por sua vez a Subcamada de Rede possui suas APIs.
C. Camada de Abstração do Sistema
É função da camada de abstração do sistema, definir um conjunto de hardware para uso
nas camadas superiores. A subcamada IPC (Inter-Process Communication) é responsável
pela abstração da comunicação entre os processos e a subcamada de E/S pela abstração de
funcionamento dos dispositivos de entrada e saída.
D. Camada de Monitoramento e Controle
A camada de Monitoramento e Controle, é responsável pelo monitoramento das ações da
aeronave bem como de seu controle. Ela está dividida nas subcamadas de Controle de Voo,
Subcamada de Tratamento de Emergência, subcamada de Tratamento de Redundância,
subcamada de Ciência de Aeronavegabilidade e subcamada de Gerenciamento de Energia.
A subcamada de Controle de Voo responde pelos Comando Básico que estão sendo
executado pela aeronave, a Decolagem Automática e também o Pouso Automático. Já a
subcamada de Tratamento de Emergência responde pelos eventos que não estão planejados,
como por exemplo um consumo de bateria além do estimado, inviabilizando o termino da
missão.
E. Camada de Navegação e Serviços
A camada Navegação e Serviços, é responsável pela navegação da aeronave, emitindo
sinais para que esta realize a trajetória necessária para cumprir a missão. É composta pelas
subcamadas de Coordenação de Tráfego Aéreo, de Controle de Trajetória de Voo, Ciência
Geopolítica e de Servidor. A subcamada de Coordenação de Tráfego Aéreo responde pelo
tráfego no espaço aéreo onde a aeronave está operando. A subcamada de Controle de
Trajetória de Voo orienta a navegação da aeronave seja para atingir os Waypoints ou a Grid
de coordenadas definidos pela missão. A subcamada de Ciência Geopolítica fica
responsável entre outras pelo limite virtual no qual a aeronave deve operar. A subcamada
de Servidor contém serviços não prioritários que auxiliam a navegação e o cumprimento da
missão.
F. Camada de Missão
A Missão, está subdividida em subcamada de SSI (Smart Sensor Interface), subcamada
de Controle Automático e Subcamada de Dados Sem Tratamento. A subcamada de SSI
(PIRES, et al., 2011) é responsável por acessar o MOSA (Mission Oriented Sensor Array)
50
(PIRES, et al., 2011) e realizar toda a verificação, permitindo averiguar se aeronave reuni
todos os atributos para realizar a missão imposta. A subcamada de Controle Automático
responde por aceitar os dados da missão (Uploading), enviar os dados coletados
(Downloading) e iniciar, parar, retomar ou cumprir parte da missão
(Start/Stop/Resume/Step). A subcamada de Dados Sem Tratamento é responsável
simplesmente por enviar dados que não precisam de um tratamento adequado. Corresponde
a essa camada, o trabalho de simplesmente garantir que os dados cheguem ao destino prédefinido.
Esta camada encerra a sequência de camadas do segmento Aéreo, a seguir são descritas
as camadas do segmento Terrestre.
G. Camada Física
A camada Física do segmento terrestre se assemelha em alguns aspectos a camada Física
do segmento aéreo. A divisão em subcamadas é assim apresentada: de Eletrônicos,
composta pelo subsistema de Hardware da Estação, basicamente computadores com
dispositivos que permitam opetar o VANT, como os Joysticks e subsistema de
Comunicações, idêntico a este subsistema no segmento Aéreo. A subcamada de Energia, é
responsável por fornecer energia para o segmento terrestre. A subcamada de Sistemas
Auxiliares, também guarda algumas semelhanças ao seu análogo no segmento terrestre,
porém conta ainda com o subsistema de Abrigo, que é um local onde monta-se a estrutura
da estação de controle terrestre e o subsistema de Suporte a Vida o qual responde pelo
suprimento de água e manutenção da temperatura do abrigo, possibilitando condições de
trabalho aos operadores do VANT.
H. Camada Estação de Controle Terrestre
A camada Estação de Controle Terrestre, possui as subcamadas de Controle e
Monitoramento, Troca de Mapas, Controle de Payload e Videoconferência.
A subcamada de Controle e Monitoramento recebe informações da aeronave em forma
de telemetria e também pode emitir comandos para guiar a aeronave. A subcamada de
Troca de Mapas responde pela capacidade de enviar novos mapas para aeronave quando da
alteração da missão inicial. O Controle de Payload envia sinais a aeronave com a finalidade
de controlar a movimentação e o funcionamento do sensores, câmeras e radares. A
Videoconferência responde pela capacidade de troca de som e imagem com outras estações
de controle ou outro local que conte o um sistema deste tipo.
5. CONCLUSÃO
VANTs são sistemas complexos que realizam missões complexas. VANTs grandes
constituem sistemas distribuídos com dezenas de processadores diferentes. Nestes sistemas,
existe a interconexão para troca de informação dentre as diferentes camadas que o compõe,
um modelo baseado em camadas delimita estritamente o que é função de cada camada e
quais parâmetros esta recebe da camada abaixo e quais parâmetros deve produzir para a
camada acima, facilitando assim o desenvolvimentos dos softwares, mesmo que por
terceiros. Este benefício poderá ser percebido quando do desenvolvimento e utilização do
SSI e MOSA, pois uma vez desenvolvidos, e os VANTs nos quais serão utilizados
51
seguirem o modelo LARISSA não deverão ter problemas de interconexão e funcionamento,
qualquer que seja o fabricante do VANT.
LARISSA pode ainda tornar-se referência para a criação de um VANT, pois o modelo
terá toda a especificação dos sistemas que compõem este, o que possibilita um fabricante X,
por exemplo, projetar e construir a estrutura do VANT, acoplar neste um sistema de
controle de missão desenvolvido pelo fabricante Y, um sensor desenvolvido pelo fabricante
Z e assim por diante. Outro benefício previsto é que a longo prazo, o uso de um modelo de
arquitetura, pode baixar o custo do projeto, pois possibilita o reúso da tecnologia já
desenvolvida, ampliando ainda mais o uso dos VANTs, seja para fins militares ou civis.
A utilização de uma arquitetura permite a definição de padrões e de formas,
principalmente levando a conformidade desses padrões (nesse caso específico de órgãos
como a FAA). A divisão em camadas permite reutilizar e atender requisitos, podendo-se
inclusive determinar requisitos de certificação ou homologação destas aeronaves e,
portanto, a inclusão destes espaço aéreo não segregado.
O presente trabalho encontra-se em andamento e pretende-se validá-lo utilizando duas
técnicas:


Utilização de questionários, os quais serão enviados a pesquisadores e
fabricantes de VANTs e
Realizar a implementação de uma ou mais camadas de forma completa, ou seja
especificação, implementação e utilização em conjunto com os protocolos e
serviços. Caso de uso: aplicar o padrão da camada implementada, em dois ou
mais pilotos automáticos de baixo custo, como por exemplo Ardupilot, Slugs,
OpenPilot e Paparazzi.
REFERÊNCIAS
ARMOUSH, A.; BECKSCHULZE, E.; KOWALEWSKI, S. Safety assessment of
design patterns for safety-critical embedded systems. In: SEAA ’09: PROCEEDINGS OF
THE 2009 35TH EUROMICRO CONFERENCE ON SOFTWARE ENGINEERING AND
ADVANCED APPLICATIONS, 2009, Washington. Proceedings. Washington: IEEE
Computer Society, 2009. p. 523-527.
BRANCO, K. et al. Tiriba a new approach of uav based on model driven development
and multiprocessors. In: IEEE INTERNATIONAL CONFERENCE ON ROBOTICS AND
AUTOMATION - ICRA COMMUNICATIONS, 2011, Shangai. Proceedings. Shangai:
IEEE, 2011. p. 6584–6587.
BRANCO, K. R. L. J. C. Contribuições na Área de sistemas distribuídos e redes de
computadores e suas aplicações em sistemas embarcados críticos. 2012. Tese de livre
docência, Instituto de Ciências Matemáticas e de Computação da Universidade de São
Paulo (ICMC-USP), São Carlos,SP, 2012.
DENG, Z.; MA, C.; ZHU, M. A Reconfigurable Flight Control System Architecture for
Small Unmanned Aerial Vehicles. In: 2012 IEEE INTERNATIONAL SYSTEMS
CONFERENCE (SYSCON), 2012, Vancouver. Proceddgings. Vancouver: IEEE, 2012. p.
1-4.
52
DOD. OSD UAV Roadmap 2002-2027. Washington,DC: U.S. Department of Defense.
Office of the Secretary of Defense, 2002. 205 p.
DOD. Unmanned Aircraft Systems Roadmap 2005-2030. Washington,DC: U.S.
Department of Defense. Office of the Secretary of Defense, 2005. 212 p.
DOD. Unmanned Systems Roadmap 2007-2032. Washington,DC: U.S. Department of
Defense. Office of the Secretary of Defense, 2007. 187 p.
DOD. Unmanned Systems Integrated Roadmap FY2009-2034. Washington,DC: U.S.
Department of Defense. Office of the Secretary of Defense, 2009. 210 p.
DUNN, W. R. Designing safety-critical computer systems. Computer, v. 36, n. 11, p.
40–46, 2003.
GAO. Unmanned aircraft systems - federal actions needed to ensure safety and
expand their potential uses within the national airspace system. [S.l.]: GAO, 2008.
(GAO-08-511).
GRANT, T. Unifying planning and control using an ooda-based architecture. In:
ANNUAL RESEARCH CONFERENCE OF THE SOUTH AFRICAN INSTITUTE OF
COMPUTER SCIENTISTS AND INFORMATION TECHNOLOGISTS ON IT
RESEARCH IN DEVELOPING COUNTRIES, REPUBLIC OF SOUTH AFRICA:
SOUTH AFRICAN INSTITUTE FOR COMPUTER SCIENTISTS AND INFORMATION
TECHNOLOGISTS, 2005, [S.l.]. Proceedings. p. 159–170.
ILARSLAN, M.; BAYRAKCEKEN, M. K.; ARISOY, A. Avionics System Design of a
Mini VTOL UAV. Aerospace and Electronic Systems Magazine, IEEE, v. 26, n. 10, p.
35-40, 2011.
JIN, H.-W. et al. WiP Abstract: Challenges and Strategies for Exploiting Integrated
Modular Avionics on Unmanned Aerial Vehicles. In: 2012 IEEE/ACM THIRD
INTERNATIONAL CONFERENCE ON CYBER-PHYSICAL SYSTEMS, 2012, Beijing.
Proceddgings. Beijing: IEEE Computer Society, 2012. p. 211.
JUN, L. et al. A role-based reference model for the service properties of service oriented
architecture. In: IFITA ’09: INTERNATIONAL FORUM ON INFORMATION
TECHNOLOGY AND APPLICATIONS, 2009, [S.l.]. Proceedings. p. 341-349.
KAYAYURT, B. et al. Ground control station avionics software development in ANKA
UAV. In: 30TH DIGITAL AVIONICS SYSTEMS CONFERENCE (DASC), 2011, Seattle.
Proceddgings. Seattle: IEEE/AIAA, 2011. p. 5B6-1 - 5B6-7.
KOULOHERIS, J. Future of System Level Design. In: PANEL DISCUSSION OF
FIRST
IEEE/ACM/IFIP
INTERNATIONAL
CONFERENCE
ON
HARDWARE/SOFTWARE CODESIGN AND SYSTEM SYNTHESIS, 2003, [S.l.].
KUMAR, S. P.; RAMAIAH, P. S.; KHANAA, V. Architectural patterns to design
software safety based safety-critical systems. In: ICCCS ’11: PROCEEDINGS OF THE
2011 INTERNATIONAL CONFERENCE ON COMMUNICATION, COMPUTING &
SECURITY, 2011, New York. Proceedings. New York: ACM, 2011. p. 620-623.
LAZIC´, L.; VELAŠEVIC´, D. Applying simulation and design of experiments to the
embedded. Software Testing, Verification & Reliability, v. 14, n. 4, p. 257–282, 2004.
53
NATO/OTAN. List of Current NATO Standards. [S.l.]: NATO/OTAN - NORTH
ATLANTIC
TREATY
ORGANIZATION,
2007.
Disponivel
em:
<http://nsa.nato.int/nsa/nsdd/listpromulg.html>. Acesso em: Outubro 2011.
NETO, J. M. M. et al. A Surveillance Task for a UAV in a Natural Disaster Scenario. In:
2012 IEEE INTERNATIONAL SYMPOSIUM ON INDUSTRIAL ELECTRONICS
(ISIE), 2012, Hangzhou. Proceedings. Hangzhou: IEEE, 2012. p. 1516 - 1522.
NIST. 4D/RCS: Reference Model Architecture for Unmanned Vehicle Systems
Version 2.0. [S.l.]: National Institute of Standards and Technologies, 2002.
OLSON, L.; BURNS, L. A Common Architecture Prototype for ARMY Tactical and
FCS UAVS. In: THE 24TH DIGITAL AVIONICS SYSTEMS CONFERENCE. DASC
2005., 2005, Washington. Proceddgings. Washington: IEEE, 2005. p. 8.B.5-1 - 8.B.5-11.
PANICKER, S. Applying DO178B for IV & V of Safety critical Software. [S.l.]:
Scribd, 2001. Disponivel em: <http://pt.scribd.com/doc/46780104/Applying-DO178B>.
Acesso em: Outubro 2012.
PASTOR, E.; LOPEZ, J.; ROYO, P. UAV Payload and Mission Control Hardware /
Software Architecture. IEEE A&E Systems Magazine, v. 22, p. 3-8, Junho 2007.
PIRES, R. M. et al. Mosa - mission oriented sensor array: A proposal. In: CLEI ’11:
PROCEEDINGS OF THE XXXVII CONFERENCIA LATINOAMERICANA DE
INFORMÁTICA, 2011, [S.l.]. Proceedings. p. 1309-1318.
PRISAZNUK, P. J. Integrated modular avionics. In: NATIONAL AEROSPACE AND
ELECTRONICS CONFERENCE. NAECON 1992, 1992, [S.l.]. Proceedings. p. 39-45.
REGLI, W. C. et al. Development and specification of a reference model for agent-based
systems. IEEE Transactions on Systems, Man, and Cybernetics - Part C: Applications
and Reviews, v. 39, n. 5, p. 572–596, 2009.
RODRIGUES, D. et al. Application of soa in safety-critical embedded systems.
Communications in Computer and Information Science, v. 206, p. 345–354, 2011a.
TRINDADE JR, O. et al. A Layered Approach to Design Autopilots. In: IEEE-ICIT
2010 INTERNATIONAL CONFERENCE ON INDUSTRIAL TECHNOLOGY, 2010,
Viña del Mar. Conferencia. Viña del Mar: IEEE Press, 2010. p. 1395-1400.
TRINDADE, O. et al. Robôs aéreos. In: ROBÓTICA MÓVEL, 2012, [S.l.]. p. 461–478.
VALAVANIS, K. P. Advances In Unmanned Aerial Vehicles: State of the Art and the
Road to Autonomy. International Series on Intelligent Systems, Control, And
Automation: Science And Engineering, v. 33, 2007.
WIND RIVER INC. ARINC 653 An Avionics Standard for Safe, Partitioned Systems.
In: IEEE-CS SEMINAR, 2008, [S.l.].
YI, Z.; CAI, W.; YUE, W. Adaptive safety critical middleware for distributed and
embedded safety critical system. In: NCM ’08: PROCEEDINGS OF THE 2008 FOURTH
INTERNATIONAL CONFERENCE ON NETWORKED COMPUTING AND
ADVANCED INFORMATION MANAGEMENT, 1., 2008, Washington, DC.
Proceedings. Washington, DC: IEEE Computer Society, 2008. p. 162-166.
54
Escalonamento de Sono e Efeito Recuperação em Baterias de
Nodos em Redes de Sensores sem Fio
Leonardo M. Rodrigues1 , Carlos B. Montez1 , Paulo Portugal2 , Francisco Vasques2
1
Programa de Pós-Graduação em Engenharia de Automação e Sistemas (PPGEAS)
Universidade Federal de Santa Catarina (UFSC) – Florianópolis, SC – Brasil
2
Faculdade de Engenharia da Universidade do Porto (FEUP)
Porto – Portugal
[email protected], [email protected], [email protected], [email protected]
Resumo. Neste artigo é apresentado um estudo sobre a questão energética em
nodos de uma Rede de Sensores sem Fio (RSSF). São abordados alguns modelos de bateria utilizados em simuladores para representar o comportamento de
uma bateria ao longo do tempo, conforme o consumo energético imposto pelos
nodos. A importância do escalonamento de tarefas nos nodos (escalonamento
do sono) também é discutida, assim como o chamado efeito recuperação das baterias. Resultados de simulações são usados para demonstrar a importância do
escalonamento na execução de atividades em cada nodo, refletindo no aumento
do tempo de vida da rede.
1. Introdução
O desenvolvimento, seguido pela evolução e redução nos preços, de nodos sensores
tem levado à uma popularização das Redes de Sensores sem Fio (RSSF). Esses nodos – com capacidade de processamento, comunicação e sensoriamento de grandezas
do ambiente (ex. temperatura, umidade, som, pressão atmosférica) – têm propiciado o
emprego de RSSF nos mais diversos domı́nios de aplicação [Buratti et al. 2009]. Originalmente, uma Rede de Sensores sem Fio era definida como aquela formada por
um grande número de nodos, espalhados de forma aleatória e com capacidades de
auto-gerenciamento [Akyildiz et al. 2002]. Atualmente, encontra-se esse tipo de rede
empregado em um escopo muito mais amplo, desde aplicações em ambientes industriais [Gungor and Hancke 2009] - onde muitas vezes há um número limitado de nodos os quais são cuidadosamente implantados - até em aplicações da agropecuária
[Aqeel-ur-Rehman et al. 2011] - onde é possı́vel a existência de milhares de nodos, alguns com mobilidade.
Independente do domı́nio de aplicação, em comum a todos os tipos de RSSF,
existe o conceito de “esforço colaborativo” entre os nodos, no sentido de monitorar as
grandezas do ambiente. A ideia básica é que a confiança no monitoramento seja baseada
em um grupo de sensores, de baixo custo, em vez de se basear em sensores individuais.
Ademais, geralmente há uma redundância no número de nodos implantados, de forma
que nem todos necessitam monitorar a mesma grandeza fı́sica simultaneamente. Outra
caracterı́stica importante nas RSSF é a necessidade de economia energética. O uso de
baterias nos nodos implica na preocupação de se manter a rede operacional o maior tempo
possı́vel. Isso é decorrente do fato da substituição de baterias, quando ocorrerem seus
55
esgotamentos, poder ser uma tarefa inviável ou ter um custo financeiro proibitivo, quando
a rede, por exemplo, for implantada em locais inóspitos ou tiver grande número de nodos.
A redundância em RSSF e a necessidade de se estender o tempo de vida da rede
implicam no estabelecimento de polı́ticas para se efetuar rodı́zio na utilização dos nodos
de forma eficaz. Quando a voltagem da bateria atinge um determinado nı́vel, conhecido
como cutoff, as reações eletroquı́micas internas deixam de acontecer, indicando que a
mesma está descarregada. Alguns nodos cujas baterias estejam próximas aos seus estados de cutoff podem ser encarregados de executar tarefas que consumam menos energia,
podendo até mesmo entrar em regimes ociosos (sleep mode) enquanto outros nodos, com
maior capacidade atual em suas baterias, assumem as tarefas de monitoramento e processamento local na rede.
As técnicas que realizam alternância na execução dos nodos muitas vezes são denominadas de escalonamento do sono (sleep scheduling) [Jurdak 2010]. Contudo, muitos
dos trabalhos sobre este assunto são baseados em simulações nas quais assume-se que
as baterias dos nodos têm comportamento simples, muitas vezes, lineares. Esse tipo de
suposição pode afetar os resultados obtidos pelas simulações, pois as baterias possuem
comportamentos bem mais complexos e difı́ceis de se modelar.
No contexto de modelagem de baterias, algumas pesquisas apontam
soluções para estimar o tempo de vida de baterias sob diversos tipos de cargas [Panigrahi et al. 2001, Rakhmatov et al. 2002, Jongerden and Haverkort 2008b,
Kerasiotis et al. 2010, Nguyen et al. 2011]. Em comum a esses trabalhos, a preocupação
em definir modelos que representem os efeitos da Taxa de Capacidade (Rate Capacity
Effect) e o de Recuperação (Recovery Effect), inerentes às baterias.
De uma forma simplificada, o Efeito Taxa de Capacidade representa o comportamento não-linear da bateria quando submetida à diferentes descargas de corrente; enquanto o Efeito Recuperação representa a habilidade da bateria em se recuperar quando
está ociosa ou submetida à cargas baixas. Estudos na literatura [Rakhmatov et al. 2002,
Li et al. 2013] apontam a existência de diferenças nos tempos de vida das baterias, decorrentes desses efeitos, conforme a ordem escolhida pelos nodos na execução de suas
tarefas. Neste artigo é investigado, no contexto das RSSF, o tempo de vida dos nodos,
conforme a escolha das atividades de transmissão e recepção de dados, além de atividades
de processamento. O objetivo é mostrar os efeitos da Taxa de Capacidade e Recuperação
nas baterias sob o ponto de vista do escalonamento de sono dos nodos da rede.
Este artigo está organizado da seguinte forma. A Seção 2 trata sobre os conceitos
básicos envolvidos neste trabalho. A Seção 3 mostra algumas definições com relação ao
modelo utilizado. A Seção 4 apresenta as simulações realizadas, bem como alguns resultados preliminares obtidos neste trabalho. Na Seção 5, apresentam-se as considerações
finais sobre os assuntos discutidos neste artigo.
2. Fundamentação Teórica
Esta seção tem como objetivo abordar alguns conceitos importantes que estão diretamente
ligados ao conteúdo deste artigo. Inicialmente, abordam-se as questões básicas sobre
baterias, tal como funcionamento e caracterı́sticas fı́sicas. Em seguida, são vistos os
conceitos sobre modelos de baterias conhecidos na literatura. Por fim, é feita uma revisão
sobre escalonamento de tarefas em nodos.
56
2.1. Conceitos sobre Baterias
As baterias são fundamentais nos dias de hoje, sem as quais, o conceito de mobilidade
não existiria. Basicamente, baterias são dispositivos que contêm uma ou mais células
eletroquı́micas capazes de transformar energia quı́mica em energia elétrica. As células são
formadas por dois terminais (eletrodos): o positivo (ou cátodo) e o negativo (ou ânodo).
Um eletrólito permite o fluxo de ı́ons entre os terminais da bateria.
+
-
V
Ânodo
Cátodo
e-
Eletrólito
Figura 1. Modo de funcionamento de uma bateria.
De forma geral, ao descarregar uma bateria, ocorre a oxidação do ânodo, gerando
elétrons (que fluem pelo circuito externo) e ı́ons carregados positivamente (que, por difusão, movem-se pelo eletrólito em direção ao cátodo). Reações de redução ocorrem no
cátodo, gerando ı́ons carregados negativamente. A Figura 1 ilustra o funcionamento de
uma bateria simples.
Além disso, cada bateria tem duas caracterı́sticas próprias: VOC é a voltagem em
circuito aberto, ou seja, a carga total armazenada na bateria sem a presença de nenhuma
corrente de descarga; e Vcut é o limite que indica quando a bateria está descarregada. Dois
parâmetros importantes são a capacidade teórica, que especifica qual a quantidade de
carga máxima que uma bateria suporta, e a capacidade atual, que estabelece a quantidade
de energia que uma bateria entrega sob uma determinada carga [Lahiri et al. 2002].
Existem diversos tipos de tecnologias de baterias recarregáveis: Ni-Cd (Nı́quelCádmio), Ni-MH (Nı́quel-Hidreto Metálico), Li-ion (Íons de Lı́tio), Li-polymer (Lı́tiopolı́mero). A tecnologia Ni-Cd foi amplamente utilizada em diversos dispositivos
eletrônicos (celulares e laptops, principalmente) devido ao seu baixo custo, entretanto,
perdeu espaço devido à baixa capacidade de carga e ao “efeito memória1 ”. A tecnologia
Ni-MH tem densidade de energia duas vezes maior que a tecnologia Ni-Cd, porém, tem
menor ciclo de vida, é mais cara e ineficiente com altas taxas de descarga. A bateria Liion é uma das mais utilizadas na atualidade, contando com maior densidade de energia
e ciclo de vida cerca de duas vezes maior que as baterias Ni-MH. Por outro lado, tem
maior sensibilidade a correntes de descarga e é mais cara que a tecnologia Ni-MH. Por
fim, as baterias Li-polymer são tão eficientes quanto a tecnologia Li-ion e ainda possuem
um invólucro flexı́vel, o que as tornam adequadas para uso em dispositivos móveis com
tamanho e peso reduzidos [Lahiri et al. 2002].
1
Diminuição da capacidade de carga com o passar do tempo.
57
2.1.1. Efeitos intrı́nsecos
Existem dois efeitos que estão presentes em qualquer bateria, independentemente da
tecnologia utilizada: Efeito da Taxa de Capacidade (Rate Capacity Effect) e Efeito
Recuperação (Recovery Effect). Tais efeitos são muito importantes para o tempo de vida
e a capacidade de uma bateria.
• Efeito Taxa de Capacidade: está relacionado à dependência entre a capacidade
atual da bateria e a magnitude da corrente de descarga. Neste caso, ao aplicar altas
correntes de descarga, a capacidade da bateria é significativamente reduzida.
• Efeito Recuperação: refere-se à habilidade que as baterias têm de recuperar parte
de sua capacidade nos intervalos que deixa de receber cargas (correntes) externas.
Dessa forma, indica-se que sejam inseridos perı́odos ociosos entre as cargas para
que a bateria tenha um maior tempo de vida [Li et al. 2013].
2.2. Modelos de Baterias
As questões energéticas são de extrema importância no contexto das RSSF, uma vez que
o tempo de vida da rede depende das baterias individuais dos nodos que dela participam.
É desejável que cada nodo maximize seu tempo de vida, podendo contribuir com a rede
pelo maior perı́odo possı́vel. Em um exemplo simples, onde um conjunto de nodos realiza o sensoriamento de uma determinada área, a falha de um nodo, por ter a sua bateria
exaurida, pode enfraquecer a precisão dos dados coletados naquela área especı́fica. Isso
prejudica a cobertura espacial da rede, tornando a captura de dados presente em apenas
alguns locais e inexistente em outros. Dessa forma, o estudo de técnicas que permitam o
aumento no tempo de vida de baterias é contı́nuo, reforçando a busca por novas tecnologias, algoritmos mais eficientes e modelos de bateria mais precisos.
2.2.1. Modelos de Bateria Analı́ticos
Os modelos de bateria analı́ticos são fundamentações matemáticas baseadas em equações
que buscam considerar as caracterı́sticas fı́sicas das baterias. Servem para estimar, conforme a carga aplicada, o tempo de vida das baterias. Esses modelos descrevem a bateria
de forma abstrata, porém, suas propriedades são modeladas utilizando apenas algumas
equações [Jongerden and Haverkort 2008a]. Por envolverem a avaliação de expressões
analı́ticas, tornam-se computacionalmente flexı́veis [Schneider et al. 2001]. Ou seja, é
possı́vel utilizar correntes como uma função de carga constante ou variável, ou alterar o
tipo de bateria. Além disso, podem modelar os efeitos eletroquı́micos inerentes às baterias, tais como o Efeito Recuperação e o Efeito da Taxa de Capacidade.
O modelo mais simples é a Lei de Peukert. Ele considera parte dos efeitos não
lineares, relacionando o tempo de vida da bateria com a taxa de descarga. Porém, o Efeito
Recuperação não faz parte do modelo. Assim, os resultados obtidos com a Lei de Peukert
são considerados bons apenas para cargas contı́nuas constantes, sendo inadequado quando
cargas variáveis ou interruptas são usadas [Jongerden and Haverkort 2008a].
Em [Rakhmatov and Vrudhula 2011], os autores introduzem um novo modelo que
descreve o processo de difusão do material ativo na bateria. Esse modelo permite estimar
58
o tempo de vida da bateria, com uma boa aproximação, para uma dada corrente de descarga utilizando os dez primeiros termos de uma soma infinita.
1-c
c
h2
h1
j
i
I
k
Carga Limite
Carga Disponível
Figura 2. Kinect Battery Model (KiBaM) [Manwell and McGowan 1993].
Outro modelo analı́tico é o KiBaM [Manwell and McGowan 1993]. Este modelo
abstrato é bastante intuitivo, sendo composto por dois tanques onde a carga da bateria
é distribuı́da, conforme ilustra a Fig. 2. O tanque Carga Disponı́vel fornece energia ao
dispositivo ligado diretamente à bateria. Já o tanque Carga Limite fornece carga ao tanque
Carga Disponı́vel. Entretanto, a taxa a qual ocorre a transferência de carga depende da
diferença entre as alturas das cargas nos dois tanques (h1 e h2 ), além do parâmetro k.
O parâmetro c indica uma fração da carga total (inserida no tanque Carga Disponı́vel)
encontrada na bateria [Jongerden and Haverkort 2008a].
Ao consumir uma corrente I, a bateria reduz sua carga disponı́vel, aumentando a
diferença entre as alturas nos dois tanques. Caso o consumo da corrente seja interrompido,
inicia-se o fluxo de carga entre o tanque Carga Limite e Carga Disponı́vel até que a altura
h1 seja novamente igual à altura h2 . Assim, durante um perı́odo ocioso, a bateria pode
aumentar sua capacidade e, consequentemente, manter-se ativa por mais tempo. O fluxo
entre os tubos é dado pelo sistema de equações diferenciais mostrado na Equação 1.
(
di
dt
dj
dt
= −I + k(h2 − h1 ),
= −k(h2 − h1 ),
(1)
tendo como condições iniciais: i(0) = c·C e j(0) = (1−c)·C, onde C representa a capacidade total da bateria. Além disso, h1 = i/c e h2 = j/(1−c). Tal sistema de equações pode
ser resolvido utilizando transformadas de Laplace [Jongerden and Haverkort 2008b]. A
Equação 2 mostra como calcular a quantidade de carga nos dois tanques.

0
0
i = i e−k0 t + (y0 k0 c−I)(1−e−k t ) − Ic(k0 t−1+e−k t )
0
k0
k0
0
j = j e−k0 t + y (1 − c)(1 − e−k0 t ) − I(1−c)(k0 t−1+e−k t ) ,
0
0
(2)
k0
onde k 0 é definido como:
k0 =
k
,
c(1 − c)
sendo i0 e j0 , respectivamente, as quantidades de Carga Disponı́vel e Limite nos tanques,
no tempo t = 0. Para y0 (carga total), tem-se: y0 = i0 + j0 . O KiBaM foi desenvolvido para modelar baterias Ácido-Chumbo. Segundo [Jongerden and Haverkort 2008a],
tal modelo não é adequado para baterias modernas utilizadas em dispositivos móveis,
como as baterias Li-ion. Por outro lado, se o interesse recai apenas no tempo de vida da
59
bateria, o KiBaM pode ser utilizado, uma vez que descreve adequadamente tanto o Efeito
da Taxa de Capacidade quanto o Efeito Recuperação.
2.2.2. Modelos de Bateria Estocásticos
Segundo [Jongerden and Haverkort 2008a], os primeiros modelos de bateria estocásticos
foram desenvolvidos por Chiasserini e Rao, entre 1999 e 2001. Tais modelos são baseados
em Cadeias de Markov com Tempo Discreto e produzem uma boa descrição qualitativa
do comportamento da bateria sob pulsos de descarga. Entretanto, o modelo proposto por
Chiasserini considera apenas o Efeito Recuperação, não conseguindo lidar com perfis de
carga arbitrários com descargas de corrente variável (Efeito da Taxa de Capacidade).
Em 2005, [Rao et al. 2005] propôs um modelo de bateria, também utilizando Cadeias de Markov, baseado no modelo analı́tico KiBaM [Manwell and McGowan 1993].
No entanto, a formulação foi alterada para baterias Ni-MH, comumente utilizadas em
nodos de uma RSSF. Os resultados experimentais deste modelo indicam que o tempo
de vida da bateria de Ni-MH depende da frequência da carga aplicada, o que não ocorre
no KiBaM original (para escalas de tempo menores que 30 minutos). A solução envolve
fazer com que a probabilidade de recuperar capacidade durante perı́odos ociosos dependa
do tamanho do perı́odo [Jongerden and Haverkort 2008a].
2.3. Técnicas de Escalonamento
Escolher a ordem na qual as tarefas2 devem ser realizadas em um nodo influencia a taxa
de descarga da sua bateria, pois a submete à diferentes correntes, ativando os seus efeitos
inerentes, tais como o Efeito Recuperação e o Efeito da Taxa de Capacidade. Algumas
tarefas consomem mais energia que outras, exigindo mais corrente ou levando mais tempo
para concluir. A escolha da ordem de execução das tarefas é chamada de escalonamento
de tarefas ou escalonamento do sono.
Apesar das pesquisas no escalonamento de tarefas já terem bem mais do que
uma década, um desafio que ainda necessita ser superado é o de como escolher a ordem de execução das tarefas de forma que o tempo de vida das baterias seja maximizado [Panigrahi et al. 2001, Rakhmatov et al. 2002, Nguyen et al. 2011, Li et al. 2013].
Em [Rakhmatov et al. 2002], apresenta-se um exemplo demonstrando o impacto
do sequenciamento de tarefas para a bateria do nodo. Uma conclusão desse trabalho é
que o tempo de vida da bateria é maximizado quando as tarefas são escolhidas de forma
que haja um decrescimento nas cargas de corrente das tarefas. Ou seja, enquanto a bateria
tem mais carga, as tarefas do nodo que consomem mais carga são escolhidas primeiro. À
medida que a capacidade da bateria do nodo é reduzida, as tarefas que consomem menos
carga são as escolhidas para executar.
Em [Li et al. 2013], apresenta-se a formulação do problema através de um simples
exemplo para transmissão de pacotes em aplicações de tempo real brandas (soft real-time).
Além disso, esse trabalho propõe um algoritmo de otimização local ciente de bateria que
insere perı́odos ociosos entre tarefas adjacentes, tirando proveito do Efeito Recuperação.
Com isso, o objetivo é minimizar o consumo de carga total do sistema.
2
O termo tarefa se refere a qualquer atividade do nodo que necessite de carga da bateria.
60
3. Modelo
Esta seção apresenta o modelo de bateria utilizado nas simulações. Com relação ao ambiente de simulação, utiliza-se o GNU Octave [Eaton 2014]. Por se tratar de uma linguagem interpretada de alto nı́vel, bem estabelecida e voltada para cálculo numérico, a
implementação de modelos matemáticos é facilitada.
Como visto na Seção 2.2, existem diversos modelos de bateria, cada um com
suas caracterı́sticas. O objetivo deste trabalho é observar o aumento no tempo de vida
de uma RSSF quando o Efeito Recuperação faz parte da rotina dos nodos nesta rede.
Além disso, deseja-se simular adequadamente o Efeito da Taxa de Capacidade quando
diferentes cargas são aplicadas nas baterias dos nodos da rede.
Diante desses motivos, um dos modelos de bateria que se encaixa no perfil descrito
é o KiBaM. Tal modelo aborda com certa simplicidade e grande abstração os conceitos
caracterı́sticos de uma bateria através da Equação 2. Utiliza-se uma função, denominada
kibam, que é chamada sempre que um nodo necessita executar uma tarefa (ou um conjunto
de tarefas). O Algoritmo 1 descreve de forma simplificada o funcionamento da função.
Algoritmo 1: Função KiBaM
1
2
3
4
5
6
7
8
9
Entrada: y0, i0, j0, I, timeInit, period
Saı́da: y0
inı́cio
initializeConstantsAndVariables();
enquanto t ≤ (timeInit + period) faça
compute-i(y0, i0, j0, I, t);
compute-j(y0, i0, j0, I, t);
saveOutput(i, j, t);
fim
updateVariables();
fim
De acordo com o Algoritmo 1, a função KiBaM tem parâmetros relacionados ao
nodo que lhe invoca. Com isso, é possı́vel definir a capacidade atual da bateria do nodo,
sua tarefa e seus perı́odos de funcionamento. Neste caso, y0 é a capacidade teórica da
bateria, i0 é a quantidade de carga no tubo Carga Disponı́vel, j0 é a quantidade de carga
no tubo Carga Limite, I é a corrente aplicada pela tarefa, timeInit é o tempo de inı́cio da
simulação e period é o tempo de execução da tarefa.
O núcleo dessa função está no cálculo do conteúdo dos tubos Carga disponı́vel
(i) e Carga Limite (j) (linhas 4 e 5, respectivamente). Para isso, utilizam-se as definições
encontradas na Equação 2. Por fim, o estado de cada tubo da bateria é salvo em um
arquivo à parte para análises e geração de gráficos (linha 6).
4. Resultados
Esta seção visa apresentar as simulações realizadas e os resultados preliminares desta pesquisa. O objetivo das simulações é fazer que o nodo execute até que a carga em sua bateria
seja esgotada (ou alcance um valor mı́nimo predeterminado, cutoff ). O nodo é alimentado por uma bateria com capacidade teórica de 1000 mAh (ou 3600 As) e conta com um
conjunto de tarefas para executar, bem como seus respectivos tempos de execução.
61
Tabela 1. Cargas utilizadas nas simulações.
Tarefa
Carga (mA)
Tempo de execução (min)
A
B
C
40
20
5
10
5
0 − 20
O conjunto de tarefas utilizadas em todas as simulações é composto por três tarefas
(Tabela 1). A primeira, denominada de A, tem consumo de 40 mA e executa por 10 min.
A segunda, B, consome 20 mA e tem tempo de execução igual a 5 min. Por fim, a
terceira, C, consome 5 mA e é executada por tempos variando entre 0 − 20 min, de
acordo com a simulação.
Sob o ponto de vista do nodo, tais tarefas equivalem, por exemplo, à uma aplicação
de monitoramento ambiental. Neste contexto, a Tarefa A representa o processamento
contı́nuo por um determinado tempo (10 min) realizado por um nodo, correspondendo a
uma leitura de sensor, um pequeno processamento local e transmissão do resultado para
outro nodo. A Tarefa B equivale ao perı́odo que o rádio receptor fica ligado à espera de
novas comunicações de outro nodo. Finalmente, a Tarefa C representa um perı́odo ocioso
(sleep mode) que o nodo tem para fazer valer o Efeito Recuperação em sua bateria.
A função KiBaM é usada para calcular a quantidade de carga consumida na bateria quando o nodo executa sua tarefa atual. Assim, a capacidade da bateria é reduzida
conforme a carga (corrente) aplicada ao realizar uma tarefa (Efeito da Taxa de Capacidade). Caso o nodo entre no sleep mode, o KiBaM é responsável por modelar o ganho
de capacidade na bateria do nodo (Efeito Recuperação). Utilizam-se os seguintes valores
para as constantes da Equação 2: k = 10−5 e c = 0, 625.
Carga Disponível (As)
Os resultados das simulações são mostrados em gráficos que descrevem a descarga
no tubo Carga Disponı́vel do nodo. Quatro cenários de uso são empregados para ilustrar
diferentes situações de execução das tarefas do(s) nodo(s).
Situação 1
Situação 2
Figura 3. Cenário 1: Nodo sem sleep mode (Situação 1).
Nodo com sleep mode de 8 horas (Situação 2).
62
4.1. Cenário 1
O Cenário 1 é usado para ilustrar a diferença nos tempos de execução com e sem Efeito
Recuperação. Com isso, consideram-se duas situações. A Situação 1 investiga o funcionamento do nodo sem utilizar o sleep mode até que sua bateria alcance o nı́vel de cutoff.
Neste caso, o nodo executa apenas a tarefa A. Na Situação 2, o nodo opera normalmente
(tal qual a Situação 1) até o momento que entra em sleep mode (em t = 850, aproximadamente). Neste momento, o nodo passa a executar a tarefa C, tirando proveito do Efeito
Recuperação por um determinado tempo (8 horas) e, então, retorna à atividade realizada
anteriormente, isto é, execução da tarefa A.
Na Figura 3, ao entrar em sleep mode (Situação 2), a bateria do nodo tem maior
tempo de vida. Na Situação 1, o nodo consegue operar por um tempo3 de 1200 min
(20 horas). Já a Situação 2, com sleep mode de 8 horas, o tempo alcançado é de
1550 min (25, 833 horas) de funcionamento. Poder-se-ia pensar que o nodo deveria
ter um tempo de vida de pelo menos 28 horas, afinal, na situação sem o sleep mode seu
tempo de vida foi de 20 horas. Porém, ao dormir por 8 horas, o nodo ainda está consumindo energia, mesmo que seja uma carga bastante baixa (5 mA). É possı́vel visualizar
esse fenômeno na Figura 3 (Situação 2), onde a bateria do nodo recupera parte de sua
capacidade e, em determinado momento, chega a um limite onde não consegue mais se
recuperar. A partir desse ponto, é reiniciado o processo de descarga.
Situação 1
Situação 2
Situação 3
Situação 4
Figura 4. Cenário 2: Nodo sem sleep mode (Situação 1).
Com diferentes tempos em sleep mode (Situação 2, 3 e 4).
4.2. Cenário 2
No Cenário 2, utilizam-se diferentes tempos para o sleep mode. Na primeira situação, o
nodo executa a tarefa principal A sem que exista “descanso” para a bateria. Na segunda
situação, insere-se a tarefa C com perı́odo em sleep mode igual à metade do tempo de
execução da tarefa A, isto é, 5 min. Na terceira situação, além da tarefa A, executa-se
a tarefa C pelo tempo de 10 min. Na quarta situação, o perı́odo da tarefa C sobe para
3
O termo “tempo” não se refere ao tempo real, mas sim à uma expectativa decorrente da simulação.
63
o dobro do tempo de execução da tarefa A, ou seja, 20 min. O nodo executa de forma
cı́clica, isto é, executa sua tarefa principal e, em seguida, entra em sleep mode pelo tempo
determinado de acordo com a situação simulada. O processo é reiniciado ao término do
sleep mode. A Figura 4 demonstra a execução das situações citadas.
De acordo com a Figura 4, a execução com sleep mode (Situações 2, 3 e 4) aumenta os tempos de vida do nodo. Na Situação 1, sem sleep mode, o tempo de vida da
bateria é de 1200 min (20 horas). Na Situação 2, que utiliza um ciclo de execução com
as tarefa A e C (sleep mode de 5 min), o tempo de duração da bateria sobe para 1455 min
(24, 250 horas). Na Situação 3, que executa as tarefas A e C (sleep mode de 10 min),
o tempo de vida da bateria alcança 1680 min (28 horas). Por fim, na Situação 4, que
executa as tarefas A e C (sleep mode de 20 min), o tempo de vida da bateria alcança
2070 min (34, 5 horas).
Tabela 2. Tempos obtidos no Cenário 2.
Situação
Sleep Mode
Tarefa(s)
Tempo (min)
1
2
3
4
Não
Sim (5 min)
Sim (10 min)
Sim (20 min)
A
AC
AC
AC
1200 (20, 00 h)
1455 (24, 25 h)
1680 (28, 00 h)
2070 (34, 50 h)
A Tabela 2 resume os resultados encontrados na simulação. Neste cenário,
percebe-se claramente que, ao inserir perı́odos ociosos na realização das tarefas do
nodo, ocorre um aumento significativo no tempo de vida da sua bateria graças ao Efeito
Recuperação. Comparando as Situações 1 e 3 deste cenário, o aumento no tempo de vida
da bateria do nodo é de 40%. No caso da Situação 3, o tempo em sleep mode é igual
ao tempo de execução da tarefa A. Ao comparar as Situações 1 e 4, onde o sleep mode
equivale ao dobro do tempo de execução da tarefa A, o aumento no tempo de vida da
bateria sobe para 72, 5%.
4.3. Cenário 3
No Cenário 3, acrescenta-se outra tarefa (B). O objetivo é verificar a influência da ordem
de execução das tarefas para o Efeito Recuperação e, consequentemente, para o tempo
de vida da bateria. O nodo executa o conjunto de tarefas mostrado na Tabela 1 em uma
determinada ordem e de forma cı́clica. São consideradas seis situações.
Tabela 3. Tempos obtidos no Cenário 3.
Situação
Sleep Mode
Ordenação
Tempo (min)
1
2
3
4
5
6
Não
Sim (10 min)
Sim (10 min)
Não
Sim (10 min)
Sim (10 min)
{AB}
{ACB}
{ABC}
{BA}
{BCA}
{BAC}
555 (09, 25 h)
725 (12, 08 h)
750 (12, 50 h)
570 (09, 50 h)
750 (12, 50 h)
750 (12, 50 h)
Na Situação 1, o perı́odo em sleep mode não é considerado, sendo admitida a
ordem de execução AB. Para a Situação 2, o perı́odo em sleep mode é acrescentado entre
64
as tarefas principais, com ordem de excução ACB. Na Situação 3, o perı́odo em sleep
mode é deslocado para o fim do ciclo, sendo sua ordem: ABC. Na Situação 4, retirase a tarefa C e a tarefa B é deslocada para o começo do ciclo. Neste caso, a ordem de
execução é BA. A Situação 5 passa a considerar o sleep mode, com ordem de execução
BCA. Por fim, na Situação 6 o perı́odo em sleep mode é deslocado para o fim do ciclo,
com ordem de execução BAC.
Os tempos de execução podem ser observados na Tabela 3. É possı́vel notar que a
ordem de execução das tarefas pode influenciar o tempo de vida da bateria do nodo. Mais
especificamente, nas Situações 2 e 3 existe uma pequena diferença nos tempos obtidos
pela simulação. Ao observar as Situações 1 e 4, também é possı́vel perceber uma pequena
diferença nos tempos obtidos, sendo que nestes casos não são considerados os perı́odos
em sleep mode.
Situação 1
4.4. Cenário 4
No Cenário 4, dois nodos são utilizados para verificar a diferença nos tempos de vida de
suas baterias com e sem o Efeito Recuperação. Os nodos têm baterias com a mesma capacidade teórica. São consideradas duas situações com diferentes formas de escalonamento.
Nodo 1
t (min)
Nodo 2
Situação 2
t (min)
Nodo 1
t (min)
Nodo 2
0
10
Legenda:
20
30
40
50
Executando
60
70
80
90
100
t (min)
Sleep Mode
Figura 5. Escalonamentos utilizados no Cenário 4.
Na Situação 1, cada nodo executa a tarefa A de forma simultânea, sem haver
perı́odos em sleep mode. Na Situação 2 adota-se um revezamento entre os nodos: enquanto um nodo executa a tarefa A, o outro nodo entra em sleep mode (execução da tarefa
C pelo mesmo tempo da tarefa A, isto é, 10 min), valendo-se do Efeito Recuperação da
bateria. Esse ciclo é repetido até que o nı́vel mı́nimo de bateria (cutoff ) em ambos os
nodos seja atingido. A Figura 5 mostra um esquema que resume o modo de execução em
cada uma das situações descritas anteriormente.
Na Figura 6 é ilustrada a execução das situações 1 e 2, além de uma situação
denominada de ’∗’. A Situação ’∗’ é equivalente à Situação 2, porém, representa o comportamento de um modelo de bateria que não leva em conta o Efeito Recuperação. Basicamente, ao invés do nodo recuperar a capacidade da bateria no perı́odo ocioso, ele
mantém a mesma capacidade da execução anterior para a próxima tarefa. Essa situação
é usada na figura para contrastar com a Situação 2 e mostrar o Efeito Recuperação e o
tempo adicional que esse efeito acrescenta no tempo de vida da bateria.
A bateria na Situação ’∗’ alcança um tempo de vida de 1382, 3 min (23, 03 horas).
Esse valor pode ser obtido de forma aproximada através de um simples cálculo. O tubo
65
Nodo 1
Nodo 2
Situação 1
Situação 2
Situação *
Figura 6. Cenário 4: Nodos sem sleep mode (Situação 1).
Nodos intercalados com sleep mode (Situação 2).
Nodos intercalados com sleep mode mas
sem Efeito Recuperação (Situação ’∗’).
Carga Disponı́vel tem capacidade de 625 mAh (ou 2250 As) e a carga executada é de
40 mA. A razão entre esses valores (625 mAh/40 mA) resulta em 15, 625 horas, que
equivale ao tempo total caso o nodo executasse continuamente. No entanto, como a
situação especı́fica adota uma execução intercalada, é preciso levar em consideração os
tempos em que o nodo não executa. Em 1 hora o nodo tem três perı́odos ociosos (neste
caso, não há recuperação da bateria). Por conseguinte, em 15, 625 horas, o nodo tem
46, 875 perı́odos ociosos. Como cada perı́odo ocioso tem duração de 10 min, multiplicase a quantidade de perı́odos ociosos; o resultado é 468, 75 min (7, 81 horas). Finalmente,
(15, 625 + 7, 81) = 23, 4 horas.
De acordo com a Figura 6, observa-se que a Situação 2 aumenta o tempo de vida
da rede. No caso da Situação 1, a execução simultânea dos nodos atinge um tempo de
1202 min (20, 03 horas). Nesta situação, o gráfico mostra as execuções sobrepostas dos
dois nodos, uma vez que as cargas das baterias no inı́cio da simulação são iguais e a
execução não conta com sleep modes. Já na Situação 2, quando a execução adota o revezamento na coleta de dados, a simulação atinge um tempo de 1662, 76 min (27, 71 horas).
Isso significa um aumento de 38, 33% no tempo de vida da rede. O gráfico dessa situação
mostra que, enquanto um nodo está executando, o outro está em sleep mode, recuperando
capacidade em sua bateria no perı́odo disponı́vel.
Como visto nos resultados simulados, adotar um sequenciamento (escalonamento
de tarefas) inapropriado (sem utilizar o sleep mode, por exemplo) pode drenar a bateria
de forma mais rápida. Assim, na medida do possı́vel, deve-se incorporar perı́odos ociosos entre as tarefas. Isso permite que a bateria recomponha parte de sua capacidade,
garantindo maior tempo de vida para o nodo.
5. Conclusão
O consumo energético dos nodos de uma RSSF é um dos problemas mais pesquisados, devido à necessidade de se manter esse tipo de rede “viva” o maior tempo possı́vel. Através
66
da busca por métodos eficientes de economia de energia nos nodos é possı́vel estender o
tempo de vida de suas baterias, aumentando o perı́odo ativo da rede como um todo. Prever
o perı́odo que ainda resta para um nodo se manter ativo, dependendo da carga de corrente
aplicada em qualquer momento, facilita o emprego de técnicas de escalonamento de sono,
as quais estendem o tempo de vida da rede, através do Efeito Recuperação.
O Cenário 4 mostra um caso simples, com apenas dois nodos. Porém, é possı́vel
generalizar esse cenário para representar uma RSSF contendo n nodos, sendo que apenas
uma fração desses nodos precisam estar ativos simultaneamente para monitorar o ambiente. Neste caso, poder-se-ia escolher os nodos que tenham maior capacidade em suas
baterias para realizar as leituras nos sensores e enviar tais dados para a estação base. Enquanto isso, os outros nodos poderiam recuperar parte da capacidade em suas respectivas
baterias. Com isso, acredita-se que o Efeito Recuperação faria grande diferença no tempo
de vida da rede.
Como trabalhos futuros, novas simulações podem ser realizadas, incluindo mais
nodos. Pretende-se integrar a presente modelagem em um ambiente voltado para
simulação de RSSF, como o OMNeT++ [OMNet++ Community 2014]. Esta ferramenta
conta com um modelo simples de bateria (linear), não representando de forma apropriada
os efeitos discutidos neste trabalho.
Agradecimentos: Os autores agradecem a CAPES e FCT pelo apoio a este trabalho.
Referências
Akyildiz, I. F., Su, W., Sankarasubramaniam, Y., and Cayirci, E. (2002). Wireless Sensor
Networks: A Survey. Computer Networks, 38(4):393–422.
Aqeel-ur-Rehman, Abbasi, A. Z., Islam, N., and Shaikh, Z. A. (2011). A Review of
Wireless Sensors and Networks’ Applications in Agriculture. CS&I.
Buratti, C., Conti, A., Dardari, D., and Verdone, R. (2009). An overview on wireless
sensor networks technology and evolution. Sensors (Basel, Switzerland), 9(9):6869–
96.
Eaton, J. W. (2014). GNU Octave. https://www.gnu.org/software/octave/.
Gungor, V. and Hancke, G. (2009). Industrial Wireless Sensor Networks: Challenges,
Design Principles, and Technical Approaches. IEEE Transactions on Industrial Electronics, 56(10):4258–4265.
Jongerden, M. R. and Haverkort, B. R. (2008a). Battery Modeling. Technical report,
University of Twente.
Jongerden, M. R. and Haverkort, B. R. (2008b). Which Battery to Use? 24th UK Performance Engineering Workshop, pages 76–88.
Jurdak, R. (2010). Radio sleep mode optimization in wireless sensor networks. Mobile
Computing, IEEE . . . , 9(7):955–968.
67
Kerasiotis, F., Prayati, A., Antonopoulos, C., Koulamas, C., and Papadopoulos, G. (2010).
Battery Lifetime Prediction Model for a WSN Platform. Fourth International Conference on Sensor Technologies and Applications (SENSORCOMM), pages 525–530.
Lahiri, K., Raghunathan, A., Dey, S., and Panigrahi, D. (2002). Battery-Driven System
Design: A New Frontier in Low Power Design. 15th International Conference on VLSI
Design (VLSID’02), pages 261–267.
Li, H., Yi, C., and Li, Y. (2013). Battery-Friendly Packet Transmission Algorithms for
Wireless Sensor Networks. IEEE Sensors Journal, 13(10):202–207.
Manwell, J. F. and McGowan, J. G. (1993). Lead Acid Battery Storage Model for Hybrid
Energy Systems. Solar Energy, 50(5):399–405.
Nguyen, H. A., Forster, A., Puccinelli, D., and Giordano, S. (2011). Sensor Node Lifetime: An Experimental Study. IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops), pages 202–207.
OMNet++ Community (2014). OMNeT++ Homepage. http://www.omnetpp.org.
Panigrahi, D., Chiasserini, C., Dey, S., Rao, R., Raghunathan, A., and Lahiri, K. (2001).
Battery Life Estimation of Mobile Embedded Systems. 14th International Conference
on VLSI Design, pages 57–63.
Rakhmatov, D. and Vrudhula, S. (2011). An Analytical High-Level Battery Model for
Use in Energy Management of Portable Electronic Systems. IEEE-ACM International
Conference on Computer Aided Design (ICCAD), pages 488–493.
Rakhmatov, D., Vrudhula, S., and Chakrabarti, C. (2002). Battery-Conscious Task Sequencing for Portable Devices Including Voltage/Clock Scaling. 39th Design Automation Conference, pages 189–194.
Rao, V., Singhal, G., Kumar, A., and Navet, N. (2005). Battery Model for Embedded Systems. 18th Internation Conference on VLSI Design held jointly with 4th Internationa
Conference on Embedded Systems Designs (VLSID), pages 105–110.
Schneider, K. K., Sausen, P. S., and Sausen, A. (2001). Análise Comparativa do Tempo de
Vida de Baterias em Dispositivos Móveis a Partir da Utilização de Modelos Analı́ticos.
Tendências em Matemática Aplicada e Computacional, 12(1):43–54.
68
Florianópolis - SC
(WoCCES 2014)
Position Paper
Uma Rede de Compartilhamento de Conteúdo Multimídia em
Dispositivos Móveis Baseados na Plataforma Android
Felipe Alexandre Oliveira Machado1 , Adriano Viana Pinto1 e
Mário Meireles Teixeira1
1
Laboratório de Sistemas Avançados da Web (LAWS)
Departamento de Informática – Universidade Federal do Maranhão (UFMA)
CEP: 65080-805 – São Luís – MA – Brasil
[email protected], [email protected],
[email protected]
Abstract. Traditionally, P2P networks have used common computers, but
more recently, with the widespread use of mobile devices, we note the growing
trend of convergence of technologies in these devices, which should be
accompanied by P2P networks. This article specifies and implements a P2P
network architecture based on mobile devices running on the Android
platform. It also developed an application for sharing multimedia content via
streaming on this P2P network. Performance tests have shown that the
connection speed and video coding rate were important factors on the
response time and throughput of the system, and the CPU utilization varied
from 20 to 50% depending on these factors.
Resumo. Tradicionalmente, redes P2P têm funcionado em computadores,
porém mais recentemente, com a disseminação do uso de dispositivos móveis,
nota-se a crescente tendência de convergência de tecnologias nesses
aparelhos, que deve ser acompanhada pelas redes P2P. Este trabalho
especifica e implementa uma arquitetura de rede P2P baseada em dispositivos
móveis operando sobre a plataforma Android. É também desenvolvida uma
aplicação de compartilhamento de conteúdo multimídia via streaming sobre
essa rede P2P. Testes de desempenho demonstraram que a velocidade de
conexão e a taxa de codificação de vídeo foram fatores preponderantes sobre
o tempo de resposta e a vazão do sistema, tendo a utilização da CPU variado
de 20 a 50% conforme esses fatores.
1. Introdução
As redes Peer-to-Peer (P2P) já fazem parte do cotidiano de muitas pessoas há mais de
uma década. Surgiram inicialmente com o objetivo de compartilhar conteúdo entre
usuários sem a necessidade de um servidor central, como no caso do paradigma clienteservidor. As redes P2P evoluíram rapidamente na direção do compartilhamento de
conteúdo relacionado a entretenimento, como músicas, vídeos, jogos, etc., sendo
frequentemente associadas à pirataria, visto que que muitos usuários compartilhavam, e
ainda compartilham, os arquivos armazenados em seus discos sem a devida atenção à
questão dos direitos autorais. Com este intuito de compartilhamento de arquivos,
surgiram arquiteturas famosas como Napster, Gnutella e Kazaa.
Outro uso das redes P2P consiste na utilização de ciclos ociosos das CPUs dos
equipamentos conectados à rede, que passam a ser utilizados como nós de uma máquina
71
paralela virtual, distribuída na rede, como no caso do projeto SETI@HOME. E, ainda,
as redes P2P podem ser utilizadas para o fornecimento de serviços multimídia, como
transmissão de áudio e vídeo, quer sob demanda ou em tempo real, a exemplo do Skype
e de Redes de Distribuição de Conteúdo (CDNs) como Akamai.
Durante muito tempo, a maioria dos nós das redes P2P foram somente
computadores pessoais de mesa ou notebooks. Atualmente, com a popularização do uso
de smartphones, tablets e dispositivos móveis em geral, com poder de processamento
sempre crescente, cada vez mais as redes P2P passam a ser utilizadas a partir de
plataformas móveis. Contudo, o que se observa é que esses dispositivos normalmente
atuam apenas como clientes da rede, simplesmente consumindo recursos, sem no
entanto compartilhar o próprio conteúdo armazenado ou fornecer serviços.
Em particular, a utilização de redes P2P para serviços de streaming de mídia
tem recebido atenção considerável de pesquisadores da área, pois permite aos
dispositivos funcionar como um meio de armazenamento distribuído, contribuindo,
buscando e obtendo conteúdo multimídia de forma autônoma (Zhang & Feng, 2009).
Sua grande vantagem, em relação à computação cliente/servidor, é possibilitar a
colaboração direta entre os usuários, sem depender de servidores administrados por
terceiros (Rocha et al., 2004).
No que diz respeito ao desenvolvimento de aplicativos para dispositivos móveis,
a plataforma Android vem obtendo bastante aceitação pela comunidade de
desenvolvedores por ser baseada em ferramentas de código aberto e com código fonte
disponível ao público em geral; possuir uma ampla documentação; ter um investimento
inicial em hardware relativamente baixo; apresentar uma curva de aprendizado suave
para a criação de aplicativos, por utilizar a linguagem de programação Java, bastante
difundida e popular; além de possuir uma base de usuários bastante extensa e com
grande potencial de crescimento, razões que tornam esta plataforma altamente atrativa
para desenvolvedores e usuários.
Este artigo propõe uma arquitetura de rede peer-to-peer, denominada P2PDroid,
voltada ao compartilhamento de conteúdo multimídia entre dispositivos móveis
interconectados por uma rede P2P. Descreve, ainda, um protótipo desta rede,
implementado em dispositivos baseados no sistema operacional Android. Apresenta
também um aplicativo denominado Playinbuddy, que torna automático e transparente o
fornecimento e a utilização de conteúdo multimídia por streaming entre os diversos
aparelhos conectados pela rede P2PDroid. Por fim, foi feita uma avaliação de
desempenho da solução apresentada, a qual demonstrou a viabilidade da arquitetura
aqui proposta.
Uma arquitetura de rede P2P com essas funcionalidades permite a formação de
redes ad hoc de forma descomplicada entre dispositivos móveis próximos entre si, sem
necessidade dos mesmos estarem conectados a uma rede Wi-Fi infraestruturada ou
mesmo de possuírem um endereço IP válido, conforme comprovaram os testes
realizados. Como exemplos de cenários de uso, uma rede P2P poderia ser formada entre
dispositivos móveis em uma quadra de esportes ou numa praça de alimentação de um
shopping center, a fim de distribuir áudio e vídeo sob demanda entre usuários detentores
de aparelhos com o aplicativo Playinbuddy instalado, aqui com fins de entretenimento.
Usos semelhantes poderiam ser realizados num chão de fábrica ou em campo, por
72
exemplo, para disseminação de dados captados por sensores entre celulares próximos
não conectados a um servidor central, dentre outras possibilidades.
No estágio atual do trabalho, o protótipo da rede P2PDroid foi implementado
utilizando o padrão Wi-Fi Direct, sendo utilizado o protocolo UPnP para entrega de
conteúdo multimídia, o que demonstra a flexibilidade da arquitetura P2P descrita,
podendo-se conceber sua portabilidade para sistemas embarcados que utilizem estes
protocolos já testados ou outros equivalentes.
O restante deste artigo está organizado como segue: a Seção 2 trata de alguns
trabalhos relacionados à presente proposta. A Seção 3 discute brevemente a arquitetura
do sistema operacional Android e de suas aplicações, enquanto a Seção 4 apresenta o
padrão Wi-Fi Direct utilizado na implementação do protótipo da rede P2PDroid, a qual
é detalhada na Seção 5. Na Seção 6, descreve-se a aplicação PlayingBuddy e são
apresentados resultados de testes de desempenho realizados com a mesma. Finalmente,
a Seção 7 discute as conclusões e trabalhos futuros.
2. Trabalhos Relacionados
Encontram-se na literatura algumas outras soluções que permitem o streaming de
conteúdo multimídia entre dispositivos móveis, em redes ad hoc domésticas.
O AirServer é uma solução proprietária desenvolvida pela App Dynamic
(Dynamic, 2011). Constitui-se como um receptor Airplay (protocolo proprietário
desenvolvido pela Apple e o aplicativo permite que o usuário transmita fluxos de mídia
a partir de seus dispositivos iOS para computadores Mac rodando Moutain Lion ou
Mavericks. Como exemplos de seu uso, permite que um professor transmita, a partir de
seu iPad, por exemplo, o conteúdo de uma apresentação para um MacBook conectado a
um projetor. É possível também transformar qualquer jogo para o sistema operacional
iOS em multiplayer, com até 16 conexões simultâneas. O AirServer é compatível com
uma ampla variedade aplicativos de terceiros, tais como YouTube, Vevo, e Air Media
Center constituindo-se como uma poderosa ferramenta de compartilhamento de
conteúdo multimídia para redes domésticas, desde que todos os dispositivos sejam
fabricados pela Apple ou compatíveis com seus protocolos, o que reduz drasticamente a
interoperabilidade desta solução, além de torná-la demasiado cara para um certo perfil
de usuário.
O Bubble UPnP Server (Bubblesoft, 2011) é um servidor de conteúdo
multimídia que utiliza o protocolo UPnP e também disponibiliza um aplicativo para
dispositivos com sistema Android que permite que um smartphone seja capaz de se
conectar ao servidor e reproduzir em tempo real o conteúdo multimídia disponibilizado
pelo mesmo. Pode ser executado em qualquer plataforma com Java 1.6 ou superior,
incluindo várias versões de Windows, MacOS X e Linux. Entretanto, a instalação e
configuração desta solução não é automática e pode ser um tanto complexa para
usuários leigos, além de que os dispositivos móveis podem desempenhar apenas o papel
de receptores de conteúdo multimídia, que é transmitido a partir do servidor central.
Destaca-se, ainda, o PS3 Media Server, um servidor de mídia UPnP compatível
com DLNA (PS3, 2008). Escrito em linguagem Java, suporta os principais sistemas
operacionais, com versões para Windows, Linux e MacOS X. Com esta solução, é
possível transmitir, transcodificar e receber conteúdo multimídia diretamente do console
73
Playstation 3 ou Xbox 360, com pouca ou nenhuma configuração. É oferecida uma
interface com o usuário amigável e intuitiva, assim como suporte a uma ampla gama de
formatos de conteúdo de mídia.
Como pode ser observado, as soluções levantadas pecam ora por exigir software
ou hardware proprietário, encarecendo-as ou por permitir transmissão de fluxos
multimídia em apenas um sentido (servidor/cliente), além de todos elas possuírem um
ponto central, concentrador, nem que seja para fins de configuração inicial. Por outro
lado, a rede P2PDroid de que trata este artigo tem configuração automática e imediata e,
como será visto à frente, não exige a figura de um servidor central e permite que cada
dispositivo desempenhe o papel de servidor ou cliente, conforme a necessidade.
Ademais, a rede P2PDroid funciona sobre o sistema operacional Android, a mais
popular plataforma para dispositivos móveis na atualidade, endossada por uma ampla
gama de fabricantes e com apelo para os mais diferentes tipos de usuários e fins.
3. Plataforma Android
Android é uma plataforma de software da Google e da Open Handset Alliance (OHA,
2013) que tem revolucionado o mercado global de telefones celulares.
A arquitetura do sistema operacional Android é dividida em camadas (Figura 1),
sendo a do Kernel Linux a que dá sustentação às outras, permitindo uma abstração entre
o hadware e o software. É responsável ainda por serviços indispensáveis em qualquer
sistema operacional, como o gerenciamento de memória e o escalonamento de
processos.
Figura 1. Arquitetura do Android (Android Developers, 2013).
74
A camada superior, a de Aplicação, é composta por softwares como navegadores
de internet, clientes de e-mail, mapas, jogos e aplicações de terceiros, todos escritos
utilizando a linguagem de programação Java em conjunto com os frameworks da
segunda camada, que oferecem funcionalidades como acesso a arquivos, telefonia,
informações de localização, notificações, alarmes etc.
Estes frameworks utilizam as bibliotecas escritas em C/C++ fornecidas pela
camada seguinte. Elas disponibilizam ao desenvolvedor um meio de acesso aos recursos
do sistema, como o banco de dados SQLite, a API de gráficos 3D OpenGL, bibliotecas
de mídia, um gerenciador de superfícies, dentre outros.
As aplicações no Android, apesar de ser escritas em Java, não são executadas em
uma Máquina Virtual Java (JVM) convencional, mas sim na máquina virtual Dalvik,
nativa do sistema. A Dalvik VM é uma máquina virtual baseada em registradores,
otimizada para aparelhos com pouca memória e projetada de forma que múltiplas
instâncias possam ser executadas simultaneamente, sendo o sistema operacional
responsável pelos serviços de escalonamento de processos, suporte a threads e
gerenciamento de memória. A Dalvik também implementa sua própria biblioteca de
classes, não sendo totalmente compatível com as especificações J2SE ou J2ME.
Diferentemente da JVM convencional, da Oracle, a Dalvik não executa os
bytecodes Java, que por sua vez são convertidos para arquivos .dex (Dalvik Executable)
e compactados em um único pacote com extensão .apk (Android Package), que é a
forma como as aplicações para Android são distribuídas.
As aplicações Android dividem-se em quatro blocos básicos: Activities,
Services, Content Providers e Broadcast Receivers. Uma Activity é um componente da
aplicação que fornece uma tela com a qual os usuários podem interagir (a GUI, por
assim dizer). Um aplicativo normalmente consiste de várias Activities.
Um Service é um componente da aplicação que pode executar operações de
longa duração em segundo plano e não fornece uma interface de usuário. Um aplicativo
pode vincular-se a um serviço para interagir com ele, utilizando comunicação entre
processos tradicional.
Os Contens Providers gerenciam o acesso a um conjunto de dados estruturados,
encapsulando-os e fornecendo mecanismos para definição de segurança de dados. Um
provedor de conteúdo conecta um conjunto de dados com um código sendo executado
em outro processo. Por exemplo, se o desenvolvedor necessitar acessar os contatos do
telefone, é possível fazê-lo por meio do Content Provider específico.
Por fim, o Broadcast Receiver é o componente que responde a alertas gerais do
sistema, os quais podem ser gerados pelas Activities, Services ou outros. Por exemplo, o
Intent (mensagem) SCREEN_OFF é gerado pelo sistema quando a tela é bloqueada e
um Broadcast Receiver pode responder a esse alerta quando o mesmo for capturado
pela aplicação.
4. O Padrão de Comunicação Wi-Fi Direct
O padrão Wi-Fi Direct (Android Developers, 2013) é uma tecnologia recente que permite
transformar qualquer aparelho Android em um ponto de acesso. É uma nova especificação
criada pela Wi-Fi Alliance que possibilita criar redes adhoc entre dispositivos Wi-Fi com a
mesma facilidade encontrada em conexões Bluetooth. Em vez de precisar conectar os
75
dispositivos a um ponto de acesso central, este novo protocolo transforma qualquer aparelho
que possua a tecnologia Wi-Fi em um ponto de acesso em potencial (Figura 2).
O padrão Wi-Fi Direct, pelas características a serem explanadas nesta seção, foi a
tecnologia escolhida para implementação da comunicação entre os dispositivos conectados
à rede P2PDroid (Seção 5), cuja especificação é genérica.
Figura 2. Proposta do Wi-Fi Direct.
4.1 Arquitetura
Em uma típica rede Wi-Fi, os clientes procuram e se associam a redes sem fio
disponíveis, que são criadas e anunciadas por Pontos de Acesso (AP). Cada um desses
dispositivos possui um conjunto diferente de funcionalidades e a grande novidade do
Wi-Fi Direct é que esses papéis são especificados como dinâmicos, portanto um
dispositivo Wi-fi Direct pode implementar tanto o papel de cliente quanto o de um AP
(ou servidor). Esses papéis são, portanto, funções lógicas que podem até mesmo ser
executadas em modo simultâneo pelo mesmo dispositivo.
Os dispositivos que implementam Wi-Fi Direct comunicam-se estabelecendo
Grupos P2P, os quais são funcionalmente equivalentes às redes tradicionais Wi-Fi com
infraestrutura pré-definida. Como mostrado na Figura 3, o dispositivo que se torna o
proprietário do grupo é chamado de P2P Group Owner (P2P GO) enquanto o
dispositivo que atua como cliente é conhecido como P2P Client. A atribuição desses
papeis, como já se disse, é feita de forma lógica e é dinâmica, o que torna a arquitetura
bastante flexível, como é desejável em uma solução para redes P2P.
Figura 3. Componentes P2P e topologia de uma rede Wi-Fi Direct.
76
4.2 A API Wi-Fi P2P
A programação de aplicações que utilizem Wi-Fi Direct é feita por meio da API Wi-Fi P2P
(Android Developers, 2013) que permite que dispositivos com Android 4.0 (API level 14)
ou superior, com hardware apropriado, conectem-se diretamente a qualquer outro
dispositivo, via Wi-Fi, sem necessidade de um ponto de acesso entre eles. Usando essa API,
o desenvolvedor pode descobrir e conectar-se a outros dispositivos que suportem o Wi-Fi
Direct e, então, comunicar-se com velocidade superior e a distâncias mais longas do que em
uma conexão Bluetooth. Isso torna o Wi-Fi Direct especialmente útil para aplicações que
compartilham dados entre usuários, tais como jogos multiplayer, aplicações de
compartilhamento de fotos e multimídia.
5. A Rede P2P Droid
Esta seção descreve a arquitetura de uma rede peer-to-peer para dispositivos móveis
baseados no sistema operacional Android, denominada P2PDroid. A rede P2PDroid
provê aos usuários uma infraestrutura básica de comunicação e compartilhamento de
recursos e foi implementada utilizando a API Wi-Fi P2P Manager criada pela Google.
Para que um dispositivo portátil Android possa se interligar à rede P2PDroid,
tudo que o usuário precisa fazer é instalar nele um pequeno aplicativo denominado
P2PDroid Client, desenvolvido para a versão 4.0 ou superior desse sistema operacional.
Ele implementa as principais funcionalidades da rede P2PDroid e permite a
comunicação e transferência de dados entres diferentes dispositivos que estejam
funcionando sobre essa rede.
5.1 Arquitetura
A rede P2PDroid define algumas operações básicas, essenciais para seu funcionamento
e inspiradas na arquitetura de rede P2P Gnutella. São elas:
•
Initialize(): Registra a aplicação cliente com o Wi-Fi Framework e deve ser
chamada assim que a aplicação é iniciada. Esse registro é necessário para que a
aplicação possa usar os recursos de Wi-Fi do dispositivo, como, por exemplo,
ser notificada quando o estado do Wi-Fi mudar (ON/OFF) ou ao receber um
pedido de conexão de outro dispositivo.
•
DiscoverPeers(): Inicia a descoberta dos pares da rede. Essa operação é usada
para iniciar a descoberta de pares (nós) ao alcance do dispositivo.
•
RequestPeers(): Ao detectar algum dispositivo ao alcance, usando a operação
DiscoverPeers(), solicita a cada um deles a lista de pares visíveis, a fim de que o
par ingressante possa começar a formar sua própria visão da rede P2P já
existente.
•
Connect(): Inicia uma conexão par-a-par com um dispositivo. Envia um convite de
conexão a outro dispositivo, esse podendo aceitar ou recusar o pedido.
•
Disconnect(): Encerra uma conexão com outro dispositivo.
Mais detalhes sobre a arquitetura e funcionamento da rede P2PDroid podem ser
encontrados em (Machado, 2013), que são aqui omitidos por razão de espaço.
77
5.2 P2PDroid Client
Usando a API Wi-Fi P2P citada acima, foi implementado um aplicativo que facilita a
descoberta, conexão e troca de mensagens entre os dispositivos móveis interconectados.
A arquitetura funciona de modo semelhante ao padrão Bluetooth, não sendo necessário
que os dispositivos possuam um endereço IP, contudo a descoberta dos pares é limitada
ao raio de abrangência do dispositivo envolvido.
Em termos de hardware, o Wi-Fi Direct trabalha com o Wi-Fi do dispositivo;
isso potencializa algumas características dessa arquitetura em relação a outras, como,
por exemplo, o raio de abrangência para descoberta de pares, a velocidade de
transferência de arquivos e a estabilidade da conexão, tornando-se assim mais robusta
do que seus concorrentes (Bluetooth 3.0, por exemplo).
O Cliente P2PDroid implementa as operações básicas definidas na Seção 5.1,
usando a API Wi-Fi P2P que interage diretamente com o padrão Wi-Fi Direct e, no
estágio atual de desenvolvimento, permite a descoberta automática de pares na rede e o
compartilhamento de arquivos entre eles. A comunicação entre os nós da rede P2PDroid
é realizada através de sockets, os quais podem operar no modo convencional ou seguro,
conforme relatado em (Machado, 2013).
A arquitetura P2PDroid foi implementada de forma extensível, de modo que é
possível a partir deste ponto desenvolver diversos tipos de aplicações sobre sua
infraestrutura, sendo uma delas descrita na Seção 6 a seguir.
6. Rede de Compartilhamento de Conteúdo Multimídia
A fim de ilustrar as potencialidades da rede P2PDroid como plataforma de
desenvolvimento de aplicações, foi especificada e implementada uma aplicação de
compartilhamento de conteúdo multimídia entre os nós da rede.
Esta rede, denominada de PlayingBuddy tem como objetivo permitir o
compartilhamento de arquivos de áudio e vídeo, armazenados nos dispositivos
conectados à rede P2PDroid, por meio de streaming, isto é, torna possível ouvir ou
assistir ao conteúdo sem a necessidade de baixá-lo do nó de origem. Potencializa-se,
assim, o uso da rede P2PDroid para fins de entretenimento doméstico, pois todo o
conteúdo multimídia pode ser acessado a qualquer momento por qualquer dispositivo,
sem a necessidade de qualquer tipo de configuração, ou seja, basta estar conectado a
rede para receber e transmitir fluxos de mídia.
No estágio atual, os pares da rede descobrem-se e conectam-se através da API
Wi-Fi P2P utilizada para implementação da rede P2PDroid. Para a realização da
comunicação multimídia, foi feita uma implementação em Java que utiliza o protocolo
UPnP (UPnP, 2013), definido pela DLNA (DLNA, 2013), acessado através da API
Cling. A rede P2PDroid funciona, portanto, como um overlay para interconexão e troca
de informações de controle entre os pares da rede, sendo os fluxos multimídia enviados
por streaming através do protocolo UPnP, amplamente utilizado em redes domésticas.
6.1 Arquitetura
Na concepção da aplicação PlayingBuddy, foram definidos os seguintes pacotes:
78
•
•
•
•
•
•
com.playinbuddy.util - Encapsula as classes para resolução de tarefas
corriqueiras como conversões de tipos de objetos, definição e gerenciamento de
variáveis de escopo da aplicação, funções de callback, etc.
com.playinbuddy.players - Encapsula as classes necessárias para a reprodução
dos conteúdos de mídia requeridos (áudio e vídeo) nos dispositivos receptores.
com.playinbuddy.mediaserver - Encapsula as classes necessárias à implementação das funções cliente/servidor de conteúdo de mídia UPnP.
com.playinbuddy.activities - Encapsula as classes que gerenciam a interface
com o usuário do aplicativo, além das chamadas aos serviços.
com.playinbuddy.objects - Encapsula as classes que representam os objetos
manipulados pela aplicação (Dispositivo e Conteúdo de Mídia).
com.playinbuddy.adapters - Encapsula as classes que funcionam como adaptadores entre os dados e as visões (GridView, ListView e TabView) utilizadas.
A Figura 4 ilustra o diagrama de classes do aplicativo PlayingBuddy desenvolvido:
Figura 4. Diagrama de Classes do aplicativo PlayingBuddy
No diagrama, observa-se que uma das principais classes é o MediaServer, do
qual dependem as três activities (interfaces com o usuário) da aplicação (StartActivity,
79
DevicelistActivity e ChannelActivity). Este, por sua vez, é composto por um servidor
HTTP (HttpServer) e por um serviço de diretórios (ContentDirectoryService). A classe
ContentNode é uma generalização dos itens de mídia que podem ser encontrados nos
dispositivos e compõe uma árvore de conteúdo (ContentTree) utilizada no serviço de
diretórios. As classes AudioFragment e VideoFragment compõem a tela que representa
o canal de mídia (ChannelActivity), que por sua vez agrega um adaptador de
visualização em abas (CustomTabsPagerAdapter) e uma classe para o preenchimento
dos dados nas visualizações em grade (CustomGridView) em cada aba. A finalidade de
cada classe pode ser melhor entendida a partir da descrição do funcionamento do
aplicativo PlayingBuddy na Seção 6.2.
6.2 Protótipo
Foi implementado um protótipo da rede PlayingBuddy, relatado nesta seção, o qual
pode passar por quatro estágios em seu ciclo de vida. O aplicativo, ao ser (1) iniciado no
dispositivo móvel, carrega as informações necessárias ao funcionamento dos serviços de
compartilhamento (endereços dos dispositivos, montagem do serviço de diretórios, etc.)
e aguarda as ações do usuário através de sua tela principal (Figura 5).
Figura 5. Tela inicial do aplicativo PlayingBuddy
Em seguida, (2) é feita a descoberta dos dispositivos ao alcance, por meio do
protocolo UPnP, os quais são listados na tela do dispositivo. A partir daí, (3) o usuário
pode selecionar um determinado dispositivo e escolher dentre os itens de áudio e vídeo
disponíveis, para reprodução via streaming. Nesta etapa, solicita-se a invocação do
serviço de diretórios para montagem de uma árvore de conteúdo multimídia no
dispositivo local. A Figura 6 ilustra a tela de descoberta de conteúdo multimídia no
aplicativo. Finalmente, utilizando o player especifico para o tipo selecionado pode-se
(4) ouvir um item de áudio ou assistir a um item de vídeo.
6.3 Avaliação de Desempenho
Esta seção relata alguns testes de desempenho realizados sobre a rede PlayingBuddy a
fim de determinar sua adequação para a transmissão de fluxos multimídia em um
ambiente móvel.
80
6.3.1
Planejamento dos Experimentos
Como cenário, considera-se um aparelho celular da fabricante Motorola modelo Razr i
XT890 rodando a versão 4.1.2 do sistema Android e um tablet da fabricante Samsung
Galaxy Tab 2 modelo GT-P3110 rodando a versão 4.0.3 do sistema Android, ambos
conectados a uma rede Wi-Fi através de um Nano Station M5 que possibilita a limitação
do oferecimento de banda.
Figura 5. Descoberta de conteúdo multimídia disponível para streaming
Como fatores que podem influenciar o resultado do experimento, tem-se a
Codificação do vídeo (Fator A), a Velocidade da conexão (Fator B) e o Tipo do
dispositivo (Fator C). Para cada fator são definidos dois níveis (valores distintos do
fator) resultando em um experimento 23 conforme ilustrado na Tabela 1.
3
Tabela 1. Planejamento fatorial do experimento (2 ).
Quanto a codificação de vídeo, H.264 360p e H.264 720p como níveis para este
fator representam vídeos com baixa e alta qualidade de imagem, respectivamente. A
velocidade de conexão tem níveis definidos por uma rede 802.11b (até 11 Mbps) para
redes com baixa taxa de banda e uma rede 802.11n (até 300 Mbps) para redes com alta
taxa de banda. Por fim, como níveis para o tipo de dispositivo foram escolhidos,
smartphone com capacidade de processamento e resolução de tela mais baixa e tablet
com processamento e resolução de tela mais elevada.
Cada experimento foi repetido cinco vezes e durou 30 segundos desde o início
da reprodução do conteúdo. Importante frisar também que o aplicativo Playinbuddy
sempre esteve executando em primeiro plano em cada dispositivo.
81
Como métricas de desempenho, foram utilizados o tempo de resposta (R),
utilização (U), vazão (X) e taxa de erro (E). O tempo de resposta representa o intervalo
entre o inicio das solicitações da entidade requisitante e o atendimento destas pela
entidade provedora de conteúdo. A taxa de throughput (vazão) define o número de
requisições que são atendidas por unidade de tempo. A utilização representa o uso dos
processadores disponíveis em cada dispositivo do experimento. Por fim, a taxa de erro
define o percentual de pacotes perdidos na rede.
As medições foram feitas utilizando-se o utilitário Android Debug Bridge
(ADB), que fornece um shell de depuração para o sistema operacional Android através
de um cabo USB conectado ao dispositivo ou através de uma porta TCP/IP, permitindo
executar em segundo plano comandos de monitoramento, como top e vmstat, enquanto
o aplicativo Playinbuddy estiver em execução na tela principal do dispositivo. A coleta
de dados se deu em intervalos regulares de 5 segundos. O sistema operacional Android
fornece a maioria das estatísticas de desempenho nos arquivos de sistema armazenados
no diretório /proc e os dados de desempenho são armazenados no diretório /proc/stat.
6.3.2
Resultados e Discussão
Esta seção mostra e discute os resultados mais relevantes, assim como a influência dos
diferentes fatores A, B e C, individualmente, nos resultados e também das combinações
destes sobre as métricas avaliadas conforme mostrado na Tabela 2.
Tabela 2. Influência dos fatores no desempenho do aplicativo.
Nota-se que a velocidade de conexão (B) é o fator mais influente sobre o tempo
de resposta, com percentual de 56,05% e também é responsável por parte importante da
vazão (variação de 31,39%), juntamente com a taxa de codificação do vídeo (A), com
influência de 27,64%, o que leva a uma influência conjunta desses dois fatores (AB) da
ordem de 26,74% na vazão do sistema. A codificação do vídeo tem influência
importante sobre a utilização da CPU (26,42%), a qual também apresenta certa
dependência do tipo do dispositivo (10,71%), principalmente quando considerada
conjuntamente com a codificação de vídeo (22,73%). O tipo do dispositivo (C) teve
pouca influência nas métricas avaliadas quando considerado individualmente. Destacase também a influência da combinação dos fatores A e B em todas as variáveis de
resposta (linha qAB). Os percentuais de dependência obtidos para o erro (E) não têm
muita relevância devido ao fato do erro aferido ter sido muito pequeno.
82
Foi realizado um estudo do efeito da codificação do vídeo no desempenho da
rede (Figura 6). Observa-se que a utilização máxima da CPU atingida pela carga de
trabalho com a codificação H.264 720p é de apenas 50%, estabilizando-se entre vinte a
trinta por cento, enquanto que na codificação H.264 360p chega a 33%, estabilizando-se
entre dez a vinte por cento. Isto mostra que a utilização da CPU na codificação H.264
720p é em média 50% maior do que na codificação H.264 360p. Também é possível
inferir que o uso da aplicação não causa sobrecarga em ambas as codificações
utilizadas, pois a Tabela 2 mostra que em média o serviço utiliza 30% da CPU dados os
fatores e níveis definidos no experimento.
Figura 6. Utilização da CPU.
Embora não seja possível relatar aqui todos os resultados, os experimentos
realizados demonstraram que a rede de compartilhamento de conteúdo multimídia
desenvolvida necessita de um poder de processamento moderado por parte dos
aparelhos utilizados e comporta-se de maneira satisfatória submetendo-se vídeos com
alta e baixa qualidade. Os níveis de largura de banda são fundamentais para o bom
desempenho da rede, importante destacar que o padrão mais comum atualmente,
802.11/n, a satisfaz completamente. Por fim, pode-se inferir que o uso de smartphones
ou tablets possui pouca influência no desempenho da rede.
7. Conclusão
Este trabalho descreveu uma arquitetura de rede peer-to-peer, denominada P2PDroid,
especificada e implementada sobre dispositivos móveis baseados no sistema operacional
Android. Esta rede foi definida de forma genérica, inspirada no protocolo Gnutella e
como prova de conceito implementou-se uma versão utilizando a API Wi-Fi P2P, da
Google, que funciona sobre o recente padrão Wi-Fi Direct de interconexão de
dispositivos, que possui como vantagens a não dependência de uma rede Wi-Fi
infraestruturada para a comunicação entre os dispositivos, os quais podem descobrir-se
de forma automática, desde que estejam próximos. O padrão Wi-Fi Direct atinge
velocidades superiores ao Bluetooth 3.0 e apresenta-se como uma solução viável a ser
utilizada em entretenimento doméstico, como jogos e multimídia e já vem disponível
em dispositivos Android 4.0 ou posteriores.
83
A rede P2PDroid, no seu estágio de desenvolvimento atual permite a descoberta
e interconexão de dispositivos portáteis baseados em Android, em uma rede P2P não
dependente de uma infraestrutura Wi-Fi. Além disso, permite a transferência de
arquivos de dados entre os dispositivos conectados.
Como exemplo de aplicação, foi desenvolvida sobre o P2PDroid uma solução de
compartilhamento de recursos multimídia por streaming. Esta aplicação, denominada
PlayingBuddy utiliza o protocolo UPnP para a troca efetiva do conteúdo multimídia e a
rede P2PDroid serve como meio de interconexão dos dispositivos. A descoberta dos
dispositivos se dá de forma rápida e instantânea e é possível tocar músicas e assistir a
vídeos em outros dispositivos de forma contínua, sem necessidade de baixar o conteúdo
para o dispositivo local. Testes de desempenho realizados demonstraram que a
aplicação PlayingBuddy opera em diferentes tipos de dispositivo, a variadas taxas de
codificação de mídia e tem um impacto de até 50% na utilização da CPU dos
dispositivos envolvidos.
Como trabalhos futuros, pretende-se produzir uma versão do aplicativo
PlayingBuddy baseada no protocolo Wi-Fi Direct e desenvolver outros tipos de
aplicações sobre a rede P2PDroid.
Referências
Android Developers. Acesso em 03 de Setembro de 2013,
em:http://developer. android.com/guide/topics/connectivity/wifip2p.html
disponível
Bubblesoft UPnP server. Acesso em 01 de janeiro de 2014, disponível em: .
http://www. bubblesoftapps.com/bubbleupnpserver/.
Digital Living Network Alliance (DLNA). Acesso em 03 de Setembro de 2013,
disponível em: http://www.dlna.org/.
Dynamic Airserver 5.0. Acesso em 03 de dezembro de 2013, disponível em:
http://www. airserver.com/.
Machado, F. A. O. Aplicações Seguras Sobre Uma Rede Peer-To-Peer Baseada na
Plataforma Android, Monografia de Graduação. UFMA, 2013.
Open Handset Alliance (OHA). Acesso em 03 de Setembro de 2013, disponível em:
http://www.openhandsetalliance.com/.
Ps3 media server. Acesso em 10 de outubro de 2013, disponível em: http://www.
ps3mediaserver. org/.
Universal Plug and Play (UPnP). Acesso em 03 de Setembro de 2013, disponível em:
http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf.
84
Índice por Autor
B
Branco, K.R.L.J.C. .......................17, 41
C
Callegaro, R. ........................................3
L
Lucena Jr., V.F. ..................................24
M
Machado, F.A.O. ................................71
Marconato, E.A. .................................41
Montez, C.B. ..................................3, 55
Moraes, R. ............................................3
P
Pinto, A.R. ...........................................3
Pinto, A.V. .........................................71
Portugal, P. .........................................55
Q
Querino Filho, L.C. ............................17
R
Rodrigues, L.M. .................................55
S
Silva, G.L.P. .......................................24
Silva, V.J. ...........................................24
T
Teixeira, M.M. ...................................71
V
Vasques, F. .........................................55
85

Anais WoCCES SBRC 2014 - Universidade Federal de Santa

Transcrição

Documentos relacionados

GUIA K641

H21-001 - Logger de dados da estação de tempo

vel-porta

Renault Master Fourgon 2.3 dCi L2H2 3.5T Confort

folheto automet.cdr

Volante 6 SK - MTE

MPG01 PT100

Audioguias - Centro Português de Fotografia

Circular 28 - Sindicato dos Bancários do Norte

AR-40 - Guster