II Workshop de Comunicação em Sistemas Embarcados Críticos … · de Computadores e Sistemas Distribuídos (SBRC 2014) apresenta mais uma série de workshops, visando a discussã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

Sociedade Brasileira de Computação (SBC)

Laboratório Nacional de Redes de Computadores (LARC)

Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014

i

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.


ii

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)


iii

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)


iv

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.


v

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



vi

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)


vii

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


viii

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écnico-

cientí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




ix

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


x

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

32º Simpósio Brasileiro de Redes de Computadores e


Florianópolis - SC

II Workshop de Comunicação em

Sistemas Embarcados Críticos

(WoCCES 2014)

Sessão Técnica 1

Uma Arquitetura para Fusao de Dados e Deteccao de Outliersem Sensores de Baixo Custo de Redes de Sensores sem Fio

Rafael Callegaro1, Carlos Montez1, Alex R. Pinto3, Ricardo Moraes12

1Pos-Graduacao em Eng. de Automacao e Sistemas – PGEAS

2Laboratorio de Seguranca em Computacao - LabSEC

3Campus Blumenau

UFSC – Universidade Federal de Santa Catarina

{rafael.callegaro, carlos.montez, arpinto, ricardo.moraes}@ufsc.br

Resumo. As aplicacoes nas areas de Agricultura de Precisao, Engenharia Am-biental, frequentemente, utilizam sensores para o monitoramento de ambien-tes, como por exemplo, no controle de pragas, no processo de irrigacao, nadeterminacao de mapas de solo e produtividade, no acompanhamento de areasflorestais e de rios urbanos, etc. As Redes de Sensores sem Fio (RSSF) vemsendo propostas como infraestruturas para essas aplicacoes. Essas redes pro-duzem um grande volume de dados e utilizam sensores de baixo custo e combaixa confiabilidade, gerando dados anomalos (outliers) e afetando a qualidadefinal do monitoramento. Essas condicoes implicam na necessidade de utilizacaode metodos de fusao de informacoes que viabilizem o funcionamento da rede eaumente a confianca nos dados monitorados. Este artigo propoe uma arquite-tura para a fusao de informacao voltada para sensores de baixa confiabilidade.A arquitetura foi avaliada atraves de um estudo de caso envolvendo sensores depressao atmosferica de baixo custo, compatıveis com a plataforma Arduino, cu-jos dados monitorados foram tratados por tecnicas de fusao de informacao. Osresultados obtidos mostram que alguns dos metodos de fusao de baixo nıvel etecnicas para deteccao de outliers, quando combinados e organizados segundoa arquitetura proposta, conseguem substituir um unico sensor centralizado e dealto custo, mantendo a confiabilidade obtida nos dados monitorados.

1. IntroducaoUma Rede de Sensores Sem Fio (RSSF) consiste em uma rede composta por nodos debaixo custo, com pequenas dimensoes e com alguma capacidade de processamento etransmissao. Desta forma os nodos tem capacidades que vao alem da simples coletade informacao, eles tem funcionalidades que permitem analisar e fundir seus propriosdados ou dados de outros nos sensores, sendo ainda equipados com algum tipo de sen-sor com capacidade de monitoramento de grandezas fısicas. Alem disso, normalmenteos nodos nao se comunicam somente entre si, mas tambem com uma estacao base, afim de que os dados possam ser divulgados, processados, analisados ou armazenados[Dargie and Poellabauer 2010]. As aplicacoes variam desde os ambientes industriais, hos-pitalares, domotica, monitoramento urbano e de areas rurais ate os ambientes militares[Akyildiz et al. 2002].


3

As RSSF comecam a ser amplamente utilizadas nos processos de automatizacaode monitoramento de diversas grandezas fısicas. Estas redes substituem as tradicionaisaplicacoes de monitoramento que assumem a abordagem centralizada, onde ha um sensorunico monitorando cada grandeza observada. Este sensor, por ser unico, necessita ser dealta confiabilidade, robusto e, consequentemente, de alto custo. As obras de instalacaopara garantir a confiabilidade das medicoes tambem costumam ter um alto custo asso-ciado. Essa abordagem centralizada tambem implica em manutencao dispendiosa, pois,via de regra, o armazenamento dos dados e feito em dataloggers, que sao dispositivosdedicados para armazenar localmente dados coletados pelos sensores. O alto custo demanutencao tambem e um problema, pois, muitas vezes ha o requisito que estes sensoressejam implantados em locais inospitos e de difıcil acesso, inviabilizando a substituicaoconstante de suas baterias e dificultando o acesso aos dataloggers.

Consequentemente, diversas aplicacoes que empregam uma infraestrutura deRSSF, como por exemplo as de monitoramento ambiental, vem deixando de ocupar, ex-clusivamente, a atencao da academia e gradualmente esta sendo adotada por empresas,substituindo as solucoes tradicionais [Elmenreich 2007]. Essa ampliacao de uso da-sepelas vantagens que as RSSF trazem, no que diz respeito a flexibilidade na implantacaoda rede, maior cobertura espacial, custo dos sensores etc. No entanto, essa adocao so naoe maior porque ainda existem diversos desafios que precisam ser superados, a destacar:(i) ha uma geracao de grande quantidade de dados, (ii) o consumo energetico dos nodosprecisa ser reduzido e (iii) ha dificuldades na deteccao de dados anomalos (outliers) etolerancia a falhas. Este trabalho foca nos problemas (i) e (iii), tratando-os sob o viesdos metodos da fusao da informacao, ou seja, tecnicas que lidam com grande quantidadede dados, que podem reduzir o consumo energetico, alem de serem capazes de aumentara confiabilidade nos dados monitorados pela rede, a partir de manipulacao matematicano conjunto de dados monitorados. Mais especificamente, este trabalho propoe que es-ses problemas sejam tratados de forma sistematica, atraves de uma arquitetura de fusaode informacoes, que organiza o fluxo de dados e as diversas atividades necessarias paraintegracao dos diferentes tipos de fusao.

A principal questao que motiva este trabalho reside em saber se um conjunto desensores de baixo custo consegue substituir os tradicionais sensores centralizados e de altocusto, mantendo, ou mesmo superando, a confiabilidade obtida nos dados monitorados.

No desenvolvimento deste trabalho foi realizada uma pesquisa bibliografica como objetivo de encontrar e avaliar uma arquitetura de comunicacao adequada para esteprocesso. Os aspectos relevantes sobre fusao da informacao, no contexto deste trabalho,sao apresentados na secao 2. Porem, como nao foi encontrada uma arquitetura a seraplicada diretamente no processo de monitoramento ambiental, propoe-se uma arquiteturapara a fusao de dados de sensores de baixo custo em RSSF (secao 3). Posteriormente, nasecao 4, descreve-se um estudo de caso, que utiliza sensores barometricos de baixo custoe compatıveis com a plataforma Arduino, que avalia a arquitetura. Por fim, algumasconsideracoes finais e trabalhos futuros sao apresentados.

2. Fusao da Informacao - Aspectos relevantes

O termo fusao da informacao e amplamente utilizado na literatura. Para[Elmenreich 2007] a fusao da informacao e um termo abrangente que cobre todos os as-


4

pectos do campo de fusao (exceto fusao nuclear ou fusao no mundo da musica). E definidapor (Henrik Bostrom 2013) como o estudo de metodos eficientes para automaticamente ousemi-automaticamente transformar informacoes de diferentes fontes e diferentes pontosno tempo em uma representacao que fornece apoio efetivo para tomada de decisao hu-mana ou automatizada. A fusao de dados comumente faz referencia a metodos de fusaode dados brutos ou de sinal muito utilizado na fusao de sensores. Ja o termo agregacaode dados, comum em RSSF, consiste em um subconjunto da fusao da informacao e tratabasicamente de tecnicas de transferencia de dados [Kulik et al. 2002].

As vantagens de se realizar o sensoriamento utilizando varios sensores ao inves deum unico sensor esta no aumento da disponibilidade, cobertura espacial, cobertura tem-poral e exatidao, podendo ainda diminuir a ambiguidade das observacoes e possibilitarauto-ajustes. No entanto, caso as entradas de informacoes sejam de ma qualidade ou exis-tirem muitas falhas de forma que a quantidade de dados incorretos superem os corretos, odesempenho global do sistema podera ser afetado [Nakamura et al. 2007].

Quando se utiliza uma RSSF, como insfraestrutura no processo de monitoramentode grandezas fısicas, e comum o uso de uma grande quantidade de nodos com sensoresde baixo custo. Basicamente os metodos de fusao podem utilizar a capacidade de pro-cessamento dos nodos para explorar a correlacao espaco temporal das informacoes obser-vadas diretamente pelos sensores para reduzir a quantidade de dados trafegados. Alemdisso, podem ser utilizados para e detectar/corrigir dados discordantes (outliers) e falhas[Zhou et al. 2011].

As falhas e erros sao fontes de outliers ou dados discordantes, ou seja, os ou-tliers sao dados atıpicos em uma aplicacao de monitoramento, e podem ter origensde ataques maliciosos, eventos, falhas e erros. Os ataques maliciosos acontecem porexemplo quando o atacante consegue obter vantagens ao manipular os dados dos senso-res, como nas aplicacoes militares e sao tratados com tecnicas de tolerancia a intrusao[Fawzy et al. 2013].

2.1. Classificacao da Fusao de Informacoes

[Dasarathy 1997] dividiu a fusao de informacoes segundo o nıvel de abstracao dos dados.Na fusao de baixo nıvel os dados brutos sao fornecidos como entradas, combinadas dire-tamente em novos dados que sao melhores que as entradas individuais e que podem serutilizados com os demais nıveis de fusao. A nıvel medio ou de caracterısticas, acontece aabstracao dos dados de forma que seja possıvel representar um objeto de forma precisa econcisa. Na fusao de alto nıvel ou de decisao, acontece a tomada de decisao baseada nasinformacoes provenientes das camadas de nıveis baixo e medio, onde podem ser incorpo-rados conhecimentos a priori e informacoes especıficas sobre a tomada de decisao.

[Durrant-Whyte 1988] distingue a fusao baseada na configuracao dos sensores.Na configuracao complementar, os sensores nao dependem diretamente um do outro, masse complementam para obter uma imagem mais completa do fenomeno observado. Naconfiguracao redundante, sao fornecidas medicoes independentes da mesma propriedadeem instantes diferentes ou por duas ou mais origens no mesmo instante a fim de pro-porcionar melhor precisao e/ou exatidao das observacoes. Na configuracao cooperativa,as informacoes sao fornecidas por mais de um sensor para derivar informacoes que naoestariam disponıveis se fosse utilizado apenas um. Normalmente, neste tipo de fusao ha


5

perda de precisao e confiabilidade.

2.2. Modelos

Os modelos de fusao de informacoes na maioria das vezes descrevem um conjunto deprocessos e como estes se relacionam, abstraindo-se de implementacoes ou instanciasespecıficas. Muitos modelos foram propostos para auxiliar no projeto de sistemas defusao de informacoes. Os mais comuns sao: JDL Process Model [Steinberg 1999], DFDModel [Dasarathy 1997] e Waterfall Model [Harris et al. 1998].

Estes modelos fornecem um esquema teorico e podem ser usados para facilitara compreensao dos requisitos e limitacoes introduzidas por metodos de fusao, mostramcomo os dados se relacionam e especificam tarefas. Na maioria dos casos, a classificacaoda fusao e baseada em nıveis e os modelos sao genericos, com excecao ao JDL que eaplicavel diretamente na area militar. Embora tais modelos nao considerem os aspectosde rede (natureza distribuıda) das RSSF, eles funcionam como um guia para especificarquais metodos podem ser usados e como eles podem ser integrados em uma arquitetura.

3. Arquitetura para Fusao de Dados de Sensores de Baixo CustoNeste artigo propoe-se uma arquitetura para aplicacoes de monitoramento com RSSF edivide as atividades executadas em tres camadas: Camada de Fusao Local, Camada deFusao de Baixo Nıvel e Camada de Gerenciamento e Interface com Usuario (Fig. 1).

Figura 1. Arquitetura proposta para fusao de dados de sensores em RSSF.

A principal contribuicao deste artigo esta na definicao e avaliacao da Camada deFusao de Baixo nıvel, que e responsavel pelo recebimento dos dados provenientes daRSSF, processamento e encaminhamento a Camada de Gerenciamento e Interface comusuario, a qual e responsavel por executar tarefas correspondentes a fusao de medio e dealto nıveis (conforme classificacao apresentada em [Dasarathy 1997]). Essas tarefas - quecostumam envolver interacoes com usuarios e acessos a bases de dados - sao usualmenteempregadas nas tomadas de decisao e sao dependentes de cada aplicacao e, portanto, estao


6

fora do escopo deste artigo. Apresenta-se tambem neste artigo as tecnicas comumenteempregadas na Camada de Fusao Local.

3.1. Camada de Fusao Local

O objetivo deste nıvel de processamento e configurar os sensores para coletar dados sobreo ambiente onde o mesmo esta inserido, realizar algum tipo de fusao local e encaminhar osdados para transmissao. Um dos primeiros passos e verificar junto ao fabricante do sensorquais sao as taxas de amostragens recomendadas. Tambem e necessario conferir se existealgum tipo de ajuste a ser realizado no sensor, como por exemplo, a microcalibracao. De-pendendo da taxa de amostragem adotada, pode-se aplicar localmente aos dados algumtipo de fusao, como por exemplo, a media aritmetica. Alguns metodos de fusao das ca-madas superiores da arquitetura podem utilizar outras informacoes no seu processamento,tais como a variancia ou desvio padrao, gerados pela fusao local. Para o calculo dessesvalores, uma boa opcao e realizar a fusao no intervalo entre beacons1, como exemplifi-cado na Figura 2, onde os nodos sensores realizam os calculos de media aritmetica e/ouvariancia a cada 30 ou 60 segundos (intervalo entre os seus respectivos beacons).

Figura 2. Fusao local dos dados.

3.2. A Camada de Fusao de Baixo Nıvel

A Camada de Fusao de Baixo Nıvel foi subdividida em: calibracao; timestamping;deteccao de erros grosseiros e sistematicos; metodos de fusao e realimentacao (Fig. 1).

3.2.1. Calibracao

A calibracao de sensores e um problema fundamental em RSSF [Tan et al. 2013]. Elaconsiste no conjunto de operacoes que estabelece e corrige a diferenca existente entreum valor medido e o verdadeiro valor. Em alguns casos, pode consistir de uma correcaoaditiva ou multiplicativa da indicacao com uma incerteza de medicao associada. Comoignora-se o verdadeiro valor, a calibracao tende a minimizar a diferenca entre o valor lidoe o verdadeiro valor da grandeza.

1Os beacons sao sinalizadores, que tambem podem ser definidos como pacotes de controle, geradosperiodicamente pelo coordenador para sincronizar a rede alem de delimitar e descrever a estrutura do su-perframe das redes IEEE 802.15.4.


7

A calibracao de cada dispositivo, individualmente e manualmente, conhecidacomo micro-calibracao pode ser intratavel quando a rede possuir um grande numero desensores [Tan et al. 2013]. Logo, a autocalibracao ou calibracao autodidata podem serempregadas neste processo. Um metodo convencional de auto calibracao e a correcaode leituras de cada sensor para um referencial comum baseado em um sensor de re-ferencia que se tenha confianca, ou baseado na referencia de um grupo de sensores[Bychkovskiy et al. 2003].

3.2.2. Timestamping

Na arquitetura proposta, a fusao de baixo nıvel pode ocorrer de forma on-line ou off-line.No caso da fusao off-line, os coordenadores PAN nao cumprem o papel de Centros deFusao, apenas encaminham os dados recebidos na direcao do coordenador PAN Principal,onde a fusao sera executada. A fusao off-line pode ser utilizada para um estudo posterioraprofundado do ambiente observado. Neste caso, e necessario associar marcacoes detempo referentes ao momento da observacao em cada dado armazenado.

Os Centros de Fusao desempenham importante papel na Camada de Fusao deBaixo Nıvel quando ocorre a fusao on-line, sendo primordial em redes de sensores quetambem possuam atuadores, para que seus resultados sejam utilizados imediatamente.

3.2.3. Deteccao de erros grosseiros e sistematicos

A deteccao e eliminacao de erros grosseiros e uma tarefa simples, porem, necessariano processo de monitoraramento com RSSF, principalmente quando se admite o uso desensores de baixo custo. A deteccao pode ser baseada, por exemplo, na simples inspecaoda faixa de operacao dos sensores, ou seja, os dados obtidos e que se encontram forada faixa operacional de um sensor devem ser descartados. Erros sistematicos sao maisdifıceis de serem detectados. Correcoes basicas podem ser efetuadas ja na implantacao(deployment) do sensor, quando estas influenciam no valor final. As demais correcoespodem ser feitas baseando-se, por exemplo, em um sensor de referencia, no qual ja setenha confianca; ou baseando-se em um grupo de sensores, nos quais, coletivamente,acredita-se que seus valores medios sejam confiaveis.

3.2.4. Metodos de Fusao

Neste nıvel os dados dos sensores sao comparados, a fim de detectar possıveis sensoresdiscordantes. Diversos algoritmos podem ser utilizados. Nesta arquitetura, considera-seum algoritmo apropriado aquele com a capacidade de comparar os dados obtidos pelossensores envolvidos na fusao e seguindo um criterio realizar ou nao a supressao dos seusdados. A eliminacao das observacoes de sensores, mesmo quando estes realizam leiturascorretas tende a descartar observacoes desnecessariamente, o que nao e desejavel. Ainda,e conveniente que quando uma observacao for descartada, de alguma forma o algoritmotenha capacidade de marcar ou mostrar de forma clara qual sensor e qual o motivo quelevou o dado a ser rejeitado. Igualmente, devido a duvida sobre a qualidade dos sensores


8

de baixo custo, e desejavel que o algoritmo tenha mecanismos capazes de computar aqualidade do sensor durante o processo de fusao.

Um metodo muito utilizado para a fusao de dados e a media aritmetica, que nao eadequada para a grande maioria das aplicacoes. Nas subsecoes abaixo descrevem-se asprincipais caracterısticas dos metodos avaliados neste artigo. E importante destacar queha diversas outras tecnicas que poderiam ser avaliadas, como por exemplo as tecnicasbaseadas em Filtro de Kalman [Nakamura et al. 2007]. No entanto, essas abordagenssao statefull, pois necessitam do historico das mensagens anteriores de cada sensor e osmetodos estudados neste trabalho sao stateless.

A. Media Tolerante a FalhasUm dos metodos de fusao de sensores com simples aplicacao, e bons resultados e amedia tolerante a falhas (MTF) proposto por [Marzullo 1990]. Basicamente o metododivide um conjunto ordenado de dados em tres partes, eliminando as extremidades.O primeiro passo desta tecnica e ordenar o conjunto de dados enviados pelos nodossensores. Tomando t=N/3, onde N e o tamanho do conjunto, descartam-se os extremos daamostra ordenada, ou seja as t maiores e as t menores medidas. O valor final e o calculoda media e desvio padrao dos valores restantes.

B. Confidence-weighted Averaging - CWA[Elmenreich 2007] propos um metodo de fusao relacionando a confianca nos sensorespelo inverso da respectiva variancia. A variancia e uma medida util em muitos casosporque sao aditivas, podendo-se comparar diferentes grupos de dados. O desvio-padrao,por sua vez, tem a vantagem de ser expresso na mesma unidade que a variavel medida,tornando mais facil de comparar resultados. Para [Elmenreich 2007], no melhor caso avariancia e proxima de zero, tendo assim a maxima confianca e no pior caso o sensorgera valores aleatorios dentro da sua faixa de operacao. A variancia de pior caso podeser calculada como a variacao de uma funcao aleatoria uniformemente distribuıda entreos limites a e b, onde a e b sao os valores mınimos e maximos de uma funcao aleatoria,uniformemente distribuıda.

C. CWA + MTFO CWA pode ser utilizado juntamente com outros metodos, como por exemplo a MTFproposta por [Marzullo 1990], o que foi proposto por Elmenreich [Elmenreich 2007].Assim o metodo se torna tolerante a falhas e considera a qualidade do sensor na fusao. Ometodo consiste em calcular a media ponderada incluindo todos os sensores atraves dometodo CWA e, posteriormente, elimina-se 2/3 dos sensores conforme especificado noMTF e calcula-se novamente a media ponderada.

D. CWA com alteracoesO metodo proposto em [Elmenreich 2007] para fundir informacoes de sensores diferen-tes, prioriza os sensores com menor variancia. Uma excecao apontada pelo proprio autordo algoritmo e que, caso a variancia seja zero, passa a ser necessario algum tratamentoespecial para evitar a divisao por zero. Contudo, em experimentos preliminares efetuadosneste trabalho observou-se um outro problema, pois, como a arquitetura proposta evoltada para RSSFs que utilizam sensores de baixo custo. Foi observado em alguns


9

cenarios de execucao, que leituras de dados coletados por um unico sensor podiamapresentar valores iguais por um longo perıodo de tempo, caracterizando um sensordefeituoso e “travado”. Esse travamento do sensor poderia ser definitivo ou temporario,por um curto ou longo tempo. Esse sensor “travado”, pela sua baixa variancia, faziacom que seus dados incorretos contribuıssem com um maior peso no calculo da mediaponderada do que os sensores corretos. Assim foi necessaria uma alteracao simplesdo algoritmo original na implementacao realizada. Basicamente, quando um sensorapresentar variacoes entre leituras abaixo de um valor estipulado (e dependente do tipoe da especificacao do sensor), sua variancia calculada sera artificialmente aumentadapara o maximo valor possıvel, contribuindo assim minimamente para o calculo da mediaponderada.

E. Criterio de ChauvenetO criterio de Chauvenet e um metodo estatıstico que foi desenvolvido para a deteccaode outliers, podendo ser utilizado para deteccao de falhas bizantinas. Ele baseia-se nahipotese de que uma medicao arbitraria pode ser rejeitada se a probabilidade de obtero desvio da media para este valor e menor do que o inverso do dobro do numero demedicoes [Taylor 2012].

O tamanho da amostra e muito importante na utilizacao do metodo, pois comuma amostra grande, ha poucas chances de que um dos valores afetem a media de formasignificativa. Um valor divergente em uma amostra grande deve estar muito longe damedia para “mover” a distribuicao. Isso faz com que a utilizacao de poucos dados tenhaexigencias mais rıgidas.

F. Metodo de PeirceO metodo de Pierce e uma tecnica estatıstica para deteccao de outliers, em uma amostracom comportamento normal. O artigo original data de 1852, contudo e amplamenteutilizado nos dias atuais. [Ross 2003] descreve o metodo de deteccao de dados suspeitosproposto por Peirce como segue: “as observacoes devem ser rejeitadas quando os desviosreais da media obtidos por mante-los, e menor do que os desvios obtidos por sua rejeicao,multiplicada pela probabilidade de fazer tantos e nao mais, observacoes anormais”.

Explicando de outra forma, o objetivo de sua tecnica era gerar probabilidadesde erro que ocorrem no sistema onde todas as n observacoes sao mantidas versus as kamostras rejeitadas. Ele entao rejeita k observacoes e verifica se a amostra e mais proximada normal que a anterior. O Criterio de Peirce, preve a deteccao de mais de um dadodiscordante na amostra. O metodo de calculo utilizado por Peirce e matematicamentecomplexo de usar. Desta forma Gould levou o metodo a ser apresentado em um formatomais facilmente empregavel com tabelas derivadas do trabalho de Peirce [Gould 1855].

3.2.5. Realimentacao

As realimentacoes sao informacoes obtidas de banco de dados, do usuario e outras fon-tes, incluindo os metodos de fusao de dados brutos. Por exemplo, informacoes sobre odescarte dos dados de um sensor em especıfico podem ser utilizadas para a calibracao dorespectivo sensor.


10

4. Avaliacao

Nesta secao avalia-se a arquitetura proposta atraves de um estudo de caso. Uma aplicacaode monitoramento ambiental, que usa a pressao atmosferica (PA) como grandeza princi-pal, e utilizada para ilustrar o uso da arquitetura. A PA e uma grandeza relevante paradiversas areas de aplicacao, como a meteorologia, altimetria, engenharia sanitaria e ambi-ental. Comumente para o sensoriamento da PA no monitoramento ambiental, emprega-seum unico sensor barometrico de alta qualidade, confiavel, com especificacoes rıgidas noque tange a instalacao e operacao e, consequentemente, de alto custo.

O local escolhido para a realizacao das medicoes foi nas proximidades do Ae-roporto Hercılio Luz na cidade de Florianopolis, Santa Catarina. Na Figura 3 pode-seobservar que foi utilizado um sensor de referencia externo para questoes comparativas(identificado neste trabalho como Vaisala), este sensor externo e operado pela aeronauticae esta localizado nas proximidades da cabeceira da Pista 14, a 5 metros de altitude comreferencia ao nıvel do mar. A distancia entre o sensor do aeroporto e o local dos expe-rimentos e de 1300 metros. Ainda com a finalidade de comparar os dados obtidos comos sensores de baixo custo, utilizou-se um segundo sensor de referencia preciso e de altocusto (identificado neste trabalho como sensor de referencia interno Young).

Figura 3. Local do experimento.

A comunicacao entre os sensores do experimento foi realizada atraves de umaRSSF IEEE 802.15.4 com topologia em estrela. Quatro sensores de baixo custo foramusados nos experimentos, o que satisfaz o criterio mınimo de sensores exigido pelastecnicas de fusao apresentadas anteriormente.

O quinto nodo foi configurado para atuar como nodo coordenador PAN/Centrode Fusao, sendo o computador responsavel por armazenar os dados gerados. A rede foiconfigurada para ser utilizada em modo com beacon ativado, e este nodo, cumprindoseu papel de Coordenador PAN, e responsavel por sincronizar a rede atraves do enviode beacons. Para configurar a periodicidade da aplicacao foi utilizado o valor do BeaconOrder (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 soft-ware de rede utilizado nos nodos foi implementado sobre a camada MAC. Assim naoforam utilizados sistemas operacionais especıficos para RSSF, tais como o TinyOS ouFreeRTOS.

A alimentacao dos nodos de 1 a 4 equipados com sensores Bosch foi realizada por2 baterias do tipo AA, sendo que os nodos tambem alimentavam os sensores Bosch. Onodo 5, equipado com o sensor Young, utilizou fonte de alimentacao AC/DC. O nodo 5 foiinterligado ao microcomputador utilizando comunicacao serial com cabo USB e os dadoscoletados pelos nodos foram armazenados em arquivo texto, acrecidos dos timestamps noseguinte formato: < timestamp, nodo[1− 10], variancia [1− 10] >.

O microcomputador do experimento teve seu horario sincronizado atraves do pro-tocolo NTP, assim como ocorre com o microcomputador do aeroporto. Optou-se porrealizar a fusao a posteriori, pela existencia de limitacoes de permanencia no local doexperimento e na obtencao dos dados on-line do sensor de referencia externo.

4.1. Resultados Experimentais

A primeira analise de dados realizada foi sobre os dados obtidos pelos sensores de re-ferencia interno (Young) e externo (Vaisala). O objetivo foi verificar se as leituras feitaspelo sensor de referencia interno sao coerentes com as do sensor de referencia externo.

Foram selecionados dados referentes a 24h de leituras e realizada uma mediahoraria da pressao atmosferica (Figura 4). Para realizar o comparativo foi necessariocorrigir os efeitos causados pela diferenca de altitude de instalacao dos dois sensores(cerca de 1,5 metros), que equivale a 0.18 hPa, subtraıdos dos valores obtidos pelo sensorde referencia externo. Alem da altitude foi necessario se levar em consideracao a exa-tidao dos sensores. Segundo os fabricantes, as leituras podem variar ± 0.3 hPa e, dessaforma, a discrepancia entre os dois sensores nao deve ultrapassar ± 0.6 hPa. Observou-seque a diferenca maxima ficou em torno de ± 0.25 hPa. Logo, pode-se considerar que osensor de referencia interno Young esta validado com relacao ao sensor de referencia ex-terno Vaisala, o qual e periodicamente calibrado, pois seus valores sao utilizados para asoperacoes de decolagem e aterrizagem no aeroporto. Por conveniencia, na continuidadedeste trabalho, os dados referentes aos sensores de baixo custo (Bosch) e os resultadosobtidos pela fusao de seus valores serao comparados somente com o sensor de referenciainterno (Young), doravante chamado apenas de sensor de referencia.

Diversas analises foram realizadas para avaliar as tecnicas de fusao. Neste artigoapresenta-se a analise de uma amostra de dados que contem um sensor discordante (Figura5). Observa-se que este sensor sempre envia a mesma leitura de pressao atmosferica,o que pode ser entendido como um sensor com alta precisao (variancia zero). Porem,esta diferenca em relacao aos outros sensores aconteceu provavelmente pelo baixo nıvelde bateria no nodo em que o sensor estava acoplado. Na Figura 5 observa-se que osvalores do sensor Bosch4 permanecem distante dos demais, chegando a diferir 1.31 hPada referencia, enquanto os demais sensores diferem apenas 0.07 hPa.

A Figura 6 apresenta os resultados dos metodos de fusao aplicados a estes dados.O metodo da aplicacao da media aritmetica obteve os piores resultados pois este incluitodos os dados no calculo da fusao. Como nesta amostra ha um sensor com leituras


12

Figura 4. Comparacao entre sensores de referencia.

discordantes, a media e deslocada e esta tecnica nao permite dizer qual sensor apresentavalores discordantes.

Ao aplicar o metodo de Chauvenet, verifica-se que o mesmo nao detecta o sensor4 como discordante, obtendo os mesmos valores que a media aritmetica. Interessantenotar que se o sensor de referencia fizesse parte do conjunto de sensores usados para ocalculo da fusao, o metodo de Chauvenet conseguiria um melhor desempenho, eliminandoo sensor discordante e a realizando a media aritmetica com os sensores restantes.

O metodo de Peirce conseguiu detectar corretamente o sensor 4 como discordante.O maximo desvio entre o sensor de referencia e o valor obtido na fusao foi de 0.03 hPa.Diferente dos metodos de Chauvenet e Peirce, a Media Tolerante a Falhas (MTF) sempredescarta os valores de dois tercos dos sensores, mesmo estes tendo valores semelhantes.

O metodo proposto por Elmenreich (CWA) e o mais completo, no sentido em queleva em consideracao a qualidade do sensor. No entanto os dados de variancia devem es-tar disponıveis. Ha tres formas de executar o metodo: na primeira considera-se apenas avariancia informada pelos sensores (CWA); na segunda sao incluıdas as modificacoes pro-postas neste artigo (CWA com alteracoes) e, por fim, utilizando o algoritmo modificadoem conjunto com a media tolerante a falhas (CWA + MTF).

Pode-se observar nos resultados apresentados na Tabela 1 que o metodo proposto

Figura 5. Amostra de dados com sensor discordante.


13

Figura 6. Aplicacao dos metodos de Fusao de dados.

Tabela 1. Metodo de Elmenreich.Rounds Referencia CWA CWA+MTF CWA com alt.

1 1012,29 1013,37 1012,31 1012,302 1012,27 1013,38 1012,28 1012,263 1012,24 1013,35 1012,25 1012,234 1012,23 1013,36 1012,20 1012,235 1012,22 1013,36 1012,18 1012,206 1012,19 1013,38 1012,17 1012,187 1012,18 1013,39 1012,19 1012,178 1012,16 1013,36 1012,18 1012,189 1012,17 1013,37 1012,15 1012,16

10 1012,15 1013,35 1012,12 1012,15

por Elmenreich (CWA sem alteracoes) tem um desempenho ruim, obtendo a diferencamaxima em torno de 1,2 hPa do sensor de referencia. Este resultado evidencia que, casoum sensor tenha leituras sequenciais iguais, a variancia obtida e zero e o sistema tera suamaior confianca no sensor discordante.

Utilizando o metodo de CWA com alteracoes, assume-se que um sensor comvariancia constante, durante um determinado perıodo, proxima de zero e defeituoso, fa-zendo com que sua variancia seja elevada artificialmente a um valor maximo. Assim,apesar do sensor defeituoso participar da media ponderada, obtem-se um resultado maisaproximado do sensor de referencia. A terceira forma aplicada e do metodo de CWA +MTF, o que tambem faz com que os dados se aproximem da referencia.

Na Tabela 2 pode-se observar o resultado da aplicacao das tecnicas MTF e oCWA+MTF na amostra de dados. Pode-se verificar que o sensor 2 participou de todasas medias, enquanto o sensor 4 foi corretamente desconsiderado em todas. Ja o sensor1, apesar de ter leituras proximas das corretas foi desconsiderado em 80% dos casos,presentes nesta amostra. Comparando os resultados obtidos pela MTF com o sensor dereferencia, encontra-se o valor maximo de 0.02 hPa.

5. Conclusoes

As RSSF utilizando sensores de baixo custo para o monitoramento de grandezas fısicas,vem substituindo a tradicional abordagem centralizada que utilizam um unico sensorconfiavel de alto custo. Parte desta mudanca 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 #41o round ◦ • • ◦ 1o round ◦ • • ◦2o 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 • ◦ • ◦10oround • • ◦ ◦ 10oround • ◦ • ◦

(a) MTF (b) CWA com MTFLegenda: • Participa da fusao ◦ Nao participa da fusao

RSSF proporciona, como flexibilidade na implantacao da rede, melhor cobertura espa-cial, custo dos sensores etc. No entanto surgem novos desafios na medida que tais redescomecam a ser utilizadas na pratica. Por exemplo, elas geram uma grande quantidade dedados, precisam ter funcionamento adequado a quantidade de energia fornecida, alem defalhas e erros ocasionados por nodos de RSSF equipados com sensores de baixo custo.Assim a utilizacao de dados brutos, gerados pelos nodos sensores nao tem sido adequadapara as aplicacoes.

Desta forma, este trabalho foca nesses problemas, tratando-os sob o vies dosmetodos de fusao da informacao, ou seja, tecnicas que diminuem a quantidade de dadose aumentam sua confiabilidade. A arquitetura proposta foi aplicada no monitoramentode ambientes. Os sensores de baixo custo foram calibrados baseados em um sensor dereferencia, sem esta operacao, os metodos de fusao nao atingiriam o desempenho espe-rado devido ao desvio constante dos valores observados pelos sensores de baixo custo.Os timestamps foram adicionados, proporcionando que a fusao fosse realizada off-line.Os erros sistematicos e grosseiros, como valores “zero” por exemplo, foram correta-mente descartados antes de chegarem aos metodos de fusao. Dentre os metodos testa-dos, Peirce e CWA + MTF se mostraram mais adequados para a fusao dos sensores. Ja amedia aritmetica, Chauvenet e CWA sem modificacoes, nao tiveram bom desempenho napresenca de nodos falhos.

De forma geral a configuracao da RSSF utilizada, juntamente com sensores debaixo custo e a arquitetura proposta, teve desempenho superior do que quando utilizadoum sensor unico de alto custo. Acredita-se que futuros sistemas de monitoramento deambientes utilizando RSSF e sensores de baixo custo, possam dispor deste trabalho comoferramenta, tanto no que se refere ao levantamento bibliografico, no desempenho dosmetodos testados, bem como utilizar ou basear sua aplicacao na arquitetura proposta.

ReferenciasAkyildiz, 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 collaborativeapproach to in-place sensor calibration. pages 301–316.


15

Dargie, W. and Poellabauer, C. (2010). Fundamentals of wireless sensor networks: theoryand practice. John Wiley & Sons Ltda.

Dasarathy, B. (1997). Sensor fusion potential exploitation-innovative architectures andillustrative 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 usingconfidence-weighted averaging. Journal of Vibration and Control (incorporating Mo-dal Analysis), 13(9-10):1303–1312.

Fawzy, A., Mokhtar, H. M., and Hegazy, O. (2013). Outliers detection and classificationin wireless sensor networks. Egyptian Informatics Journal, 14(2):157 – 164.

Gould, B. A. (1855). On peirce’s criterion for the rejection of doubtful observations, withtables for facilitating its application. Astronomical Journal, 4:81–87.

Harris, C., Bailey, A., and Dodd, T. (1998). Multi-sensor data fusion in defence andaerospace. The Aeronautical Journal, 102(1015):229–244.

Kulik, J., Heinzelman, W., and Balakrishnan, H. (2002). Negotiation-based protocols fordisseminating information in wireless sensor networks. Wirel. Netw., 8(2/3):169–185.

Marzullo, K. (1990). Tolerating failures of continuous-valued sensors. ACM Trans. Com-put. Syst., 8(4):284–304.

Nakamura, E. F., Loureiro, A. A. F., and Frery, A. C. (2007). Information fusion forwireless sensor networks: Methods, models, and classifications. ACM Comput. Surv.,39(3).

Ross, S. (2003). Peirce’s criterion for the elimination of suspect experimental data. Jour-nal 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 datafusion in wireless sensor networks. ACM Trans. Sen. Netw., 9(3):28:1–28:27.

Taylor, J. R. (2012). Introducao a Analise 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 filteringdirty data based on temporal- spatial correlation in wireless sensor network. ProcediaEnvironmental 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

1FATEC - Faculdade de Tecnologia de Garça Av. Presidente Vargas, 2331 – Garça – SP - Brasil

2USP - 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. 153-158.

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/article-2520818/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 deambientes inteligentes com dispositivos móveis

Vandermi J. Silva1, Gustavo L. P. Silva1 ,Vicente F. De Lucena Jr.2

1Instituto de Ciências Exatas e Tecnologia ICET – Universidade Federal do Amazonas(UFAM)

Caixa Postal 69100-000 – Itacoatiara – AM – Brasil

Universidade Federal do Amazonas (UFAM){vandermi, vicente}@ufam.edu.br, [email protected]

Abstract. In this work an experimental architecture for automation andintegration smart environments with mobile devices is presented, consideringgathering and storage of data from sensors and actuators. After analyzing andfiltering data, the architecture will recommend services for users of smartenvironment. The proposal focuses on building an architecture that integratesinformation services based on context and presents a prototype for datacollection actions in actuators and sensors and a prototype embedded on amobile device (smart-phone) to interact with the sensors and actuatorsinstalled in an academic environment. The architecture is in testing withpossible future modifications and adaptations to the integration of cognitiveagents and context management module to manage and filter the data in thepreprocessing module.

Resumo. Neste trabalho é apresentada uma arquitetura experimental paraautomação e integração de ambientes inteligentes com dispositivos móveisconsiderando a coleta e armazenamento de dados de sensores e atuadores.Após a análise e filtragem de dados, a arquitetura permitirá recomendarserviços para usuários de um ambiente inteligente. A proposta concentra-sena construção de uma arquitetura que integre serviços baseados nasinformações de contexto e apresenta um protótipo para coleta de dados deações em atuadores e sensores e um protótipo embarcado em um dispositivomóvel (smartphone) para interagir com os sensores e atuadores instalados emum ambiente acadêmico. A arquitetura está em fase de teste com possíveismodificações e adequações futuras com a integração de agentes no módulocognitivo e gerência de contexto para gerenciar e filtrar os dados no módulode pré-processamento.

1. Introdução

O uso do contexto em aplicações interativas é cada vez mais presente no cenáriotecnológico e necessita ser estudado mais profundamente especialmente nos casos emque os cenários estão em constantes mudanças, por exemplo, os que envolvem AmbientIntelligence (AmI) e computação ubíqua [Abowd et. al. 1997]. A computação ubíquapermite reconhecer objetos e informações que estão em torno do usuário de formadinâmica e sem interferência humana e a união dos sistemas ubíquos com acontextualização permitirá ao usuário maior mobilidade, além de facilitar oreconhecimento 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 pessoaspor meio da automação residencial tanto através de tarefas corriqueiras como ligar oudesligar um sistema de iluminação, quanto as mais difíceis que envolvem identificar ocontexto em que uma tarefa deve ser executada.

Uma das atividades a ser desenvolvida em AmI se dá pela necessidade delocalizaçã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 detecnologias de redes sem fio para verificar o posicionamento de pessoas em umambiente utilizando Radio Frequency Identification (RFID) e outras tecnologias de redesem 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 asprincipais técnicas para localização indoor, que consiste basicamente em utilizar atriangulaçã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 nascoletas das rotas mais comuns do usuário, além da utilização do mapeamento de pontosde referência para ser aplicado na base de treinamento de um sistema de localizaçãoindoor.

Baseado na necessidade de integrar os dados de sensores e atuadores em umsistema context-wareness este trabalho propõe uma arquitetura para automação deambientes residenciais baseada em identificação de contexto em ambientes inteligentespara automatizar de forma transparente a identificação do usuário, sua localizaçãoindoor e suas preferências no contexto de uma residência automatizada. O trabalho foidividido em seis seções descritas a seguir: Na Seção 2 serão apresentados os conceitos edefinições sobre ambientes inteligentes AmI, context-aware e localização indoor, naSeção 3 serão apresentados os trabalhos relacionados, na Seção 4 será apresentada aarquitetura proposta na Seção 5 será apresentada a construção do protótipo finalizandocom 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 parafacilitar o entendimento das tecnologias e ferramentas utilizadas na pesquisa. A seçãofoi 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 AmIproporciona ambientes sensíveis e que respondem à presença de pessoas, dando ênfasena facilidade de utilização de serviços de apoio aos usuários e principalmente, no apoiodas interações humanas com interfaces inteligentes e intuitivas, embarcadas em todosos tipos de objetos em ambientes capazes de reconhecer e reagir a presença deindivíduos diferentes.

Em [Ramos, Augusto e Shapiro, 2008] AmI é apresentada como uma visão dasociedade da informação onde as pessoas convivem em ambientes inteligentes e cominterfaces intuitivas embarcadas em dispositivos ao seu redor, capazes de reconhecer oambiente e seus usuários e responder a diferentes estímulos por meio de sensores eacionadores. Esse novo paradigma proporciona a melhoria da qualidade de vida daspessoas 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 deInteligê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 permitemque os sistemas de AmI sejam capazes de interagir com o usuário a partir dos dadosobtidos 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 acomunicação de diversos dispositivos instalados em um ambiente residencialautomatizado, será melhorada.

2.2. Context-aware

Em [Schilit e Theimer 1994], é apresentado uma definição de contexto comolocalização e identificação de pessoas e objetos, no entanto, outras definições maisabrangentes são apresentadas em [Ryan et. al. 1997] e em [Dey, 1998] como sendo alocalização de usuários no ambiente, estado emocional do usuário, temperatura dousuário, temperatura do ambiente, comportamento, entre outras características.

Pode-se definir o contexto no sentido mais genérico como uma informaçãoqualquer que pode ser usada para caracterizar uma situação envolvendo pessoas, objetose 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çãoque melhor se adequará a determinada situação e pode ser aplicada de forma flexível emqualquer entidade móvel, visando à descoberta de padrões pessoais coletando,interpretando e respondendo ao usuário sobre os aspectos de outros dispositivos e doambiente [Zimmer 2004].

Um sistema é context-aware se usar um contexto para disponibilizarinformações ou serviços relevantes para o usuário onde a relevância depende da tarefasolicitada. Existem diferenças entre os conceitos de context-aware e contexto. Ocontexto trata das atividades, identidade, localização e tempo em que ocorreram asações, enquanto que o context-aware trata da apresentação, execução automática eentrega (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 conhecidodeles é usando o Global Position System (GPS). No entanto, para a localização indooresse método não é eficaz devida a dificuldade de recepção do sinal em um ambientefechado, [G. Sun, J. Chen, W. Guo, e K.J.R. Liu 2005].

Para minimizar esse problema surgiram técnicas que utilizam a potencia do sinalWI-FI para identificar acess points e fazer a trilateração do sinal na esperança dediminuir 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 paradeterminar o posicionamento do usuário por meio da distancia entre os pontos dereferê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 napotencia do sinal Wi-FI e técnicas probabilísticas para melhoria da aquisição doposicionamento do usuário dentro de um ambiente.


26

3. Trabalhos Relacionados

Em [Corchado, J.; Bajo, J.; Abraham 2008] foi apresentada uma arquitetura dehealthcare para monitorar idosos em uma casa de saúde. O sistema possibilitou oacompanhamento de pacientes com a doença de Alzheimer, por meio de etiquetasRadio Frequency Identi cation fi (RFID) instaladas na residência e no pulso de cadaidoso monitorado. Quando o idoso se aproximava de alguma porta ou janela, o sistemacapturava os dados do dispositivo RFID no seu pulso e enviava o sinal ao servidor delocalização instalado na administração da casa.

O sistema foi integrado em uma rede sem fios, que permitia que enfermeiros emédicos tivessem acesso à localização do paciente, usando um Personal DigitalAssistent (PDA). Os equipamentos utilizados para acessar os dados foram empregadoscomo clientes do sistema que acessavam uma base de dados comum a todos oscomponentes.

Em [Zamora-Izquierdo et. al. 2010] foi apresentado uma arquitetura para homeautomation (HAM), composta por um sistema de monitoramento e controle por meio devários dispositivos embarcados conectados a sensores e atuadores e centralizados emuma casa inteligente. O HAM possuía também, partes modularizadas que podiam serintegradas para monitorar todas as áreas de uma residência ou parte dela. A arquiteturasuportava a infraestrutura de segurança e acesso remoto via internet através de doismétodos de acesso externo, o protocolo HTTP, usado para o servidor gateway quepermitia monitorar o acesso a residência e o protocolo UDP para se comunicar commódulos de segurança e gateway remotos. O sistema ainda possuía entradas para ummódulo de comunicação que podia ser bluetooth, ZigBee ou barramento ControllerArea Network,(CAN-BUS), além de permitir a troca de mensagens por meio de ShortMessage System (SMS).

Em [Bonino e Corno 2010] foi apresentada uma contribuição para estender osambientes domóticos inteligentes (IDEs) para suportar inteligência baseada em regras,iniciando com um modelo formal em que regras são definidas para avaliar aspropriedades dos ambiente por meio de ontologias. Duas linguagens de regras foramutilizadas a Semantic Web Rule Language (SWRL) e a JenaRules, para formalização eavaliação da camada de razão do sistema. As engines nomeadas de Jess e Jena foramcomparadas e os resultados foram apresentados quanto à checagem de propriedades nosrequisitos de efetividade da base de inteligência para prevê comportamentos, porexemplo, adaptação e interação proativa com o usuário.

Os autores avaliaram as regras usando dois diferentes benchmarks, um ambientedoméstico pequeno composto por seis cômodos e um ambiente de escritório maiscomplexo composto por cinqüenta e duas salas. Como resultado, foi apresentado que oraciocínio baseado em regras pode ser efetivamente aplicado em ambientes inteligentespara 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ógicapara desenvolvimento de sistemas AmI. Foram analisadas as funcionalidade de umframework para um middleware de context-aware que fez uso de ontologias paramodelar as informações de contexto em ambiente de computação pervasiva, e inseriruma camada de razão em alto e baixo nível para auxiliar nas aplicações context-awareem sistemas de AmI. Foram definidos no artigo, contexto, context-awareness eontologia e proposto pelos autores uma arquitetura para um middleware sensível acontexto. 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, acamada de middleware de context-aware, usada para programar as funcionalidades derepresentação do contexto, gerência do contexto, armazenamento do contexto e ocompartilhamento das informações de contexto, a camada de aplicação, responsável pordisponibilizar as informações contextuais para consumidores finais.

No trabalho apresentado em [Altintas e Tacha 2012] os autores melhoraram osresultados do algoritmo KNN para uso em sistemas de localização indoor, integrandouma memória de curto prazo, Short Term Memory (STM), onde as leituras de potênciado sinal são armazenadas. Considerando a capacidade de movimento limitado de umusuário móvel em um ambiente interno, locais anteriores do usuário podem ser levadosem consideração para obter sua posição atual. Na abordagem proposta, as leituras depotência do sinal foram refinadas com os dados históricos anteriores e comparados como mapa de rádio do ambiente. Os resultados da avaliação indicam que o desempenho doKNN com as modificações apresentadas supera algoritmo KNN convencional.

Neste trabalho pretende-se apresentar uma arquitetura experimental paraautomação e integração de ambientes inteligentes com dispositivos móveisconsiderando a coleta e armazenamento de dados de sensores e atuadores para apósanálise e filtragem, recomendar serviços para usuários de um ambiente. A propostaconcentra-se na construção de uma arquitetura que integre serviços baseados nasinformações de contexto e apresenta um protótipo para coleta de dados de ações ematuadores e sensores.

4. Arquitetura proposta

A partir da avaliação inicial feita por meio da revisão dos trabalhos relacionados, foidesenvolvida uma arquitetura experimental para o desenvolvimento do trabalho que éapresentada na forma de diagrama de blocos divididos em quatro módulosinterconectados. Estes módulos permitem receber dados de entrada adquiridos porsensores e atuadores diversos instalados em uma residência ou escritório para emseguida fazer o pré-processamento e após essa fase, definir as políticas e estratégias paratomada de decisão. O resultado final serão os serviços disponíveis baseados nos dadosdos 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 omódulo cognitivo para recomendar serviços para o usuário de um sistema domótico demaneira a minimizar seu esforço e promover a configuração automática do ambientebaseado 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 aquicomo câmeras, sensores de presença, sensores de luminosidade, sensores de portas esensores 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 ambientesão as entradas e saídas de um usuário que por meio de um sensor de abertura efechamento de portas e uma micro câmera podem ser capturadas e armazenadas na basede 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 atuadorescomo no caso clássico de acionamento de lâmpadas por meio de relés são armazenadosna base de dados e poderão servir como ponto de partida para um sistema preditor decomportamento 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 brutoscoletados dos sensores e atuadores. São formados por atributos que podem representaruma pessoa, um objeto físico ou um local específico dentro do ambiente. Inicialmenteos dados são subdivididos em dados de sensores Ds e dados de atuadores Da. Essadivisão se dá para facilitar a classificação dos dados para serem armazenados nohistórico.

A partir da leitura e armazenamento de dados por meio do bloco de conjunto dedados de maneira separada, os dados de sensores e atuadores são armazenados emtuplas para posteriormente serem analisados e filtrados.

A representação formal dos dados pode ser feita por meio de uma matriz deobjetos dada por Xnx d onde n representa o número de objetos e d o númerode atributos de entrada de cada objeto. O valor de d define a dimensionalidade dosobjetos, espaço de entrada ou espaços de atributos. A Tabela 1 apresenta um exemplode tuplas de dados coletados de um sensor de movimento. Na tabela podem serobservados 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 basede 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, porexemplo, um arquivo XML. Durante a fase de pré-processamento é necessário definirtécnicas para análise e filtragem de dados e durante essa fase a caracterização dosdados, o tipo e a escala devem ser observadas [Faceli, et. al 2011]. Para coleta de dadosdeste 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 doconjunto de dados, o tipo, define se o atributo é qualitativo ou quantitativo e a escaladefine as operações que podem ser realizadas sobre os valores do atributo. A escalapode ser nominal, racional ou intervalar.

A análise consiste na preparação dos dados para descrever os objetos por meiode um vetor de características ou um conjunto de atributos de entrada. Por exemplo, umobjeto sensor de movimento tem como características, um id, local de instalação e adata/hora do disparo. A partir da análise e filtragem desses dados, pode-se definir quesensor disparou e quais os horários que normalmente ele dispara nesse caso isso é umacaracterística de escala intervalar.

A análise e filtragem de dados apresentada no bloco de pré-processamento serãofeitas visando à extração das características necessárias para identificação de grupos eobjetos semelhantes no conjunto de dados e regras de associação que relacionam essesgrupos.

4.3. Módulo Cognitivo

O módulo cognitivo representa a inteligência do sistema e está dividido em trêssubsistemas que são as políticas, que contém as regras para o subsistema de decisão e asestratégias, que contém os algoritmos para inferência das políticas. Um exemplosimples de políticas baseadas em regras IF THEN ELSE, que pode ser implementadaem 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 doresultado das operações anteriores combinadas entre si e nesse caso C será a respostapara as premissas. É obvio que um sistema inteligente não deve ser baseado apenasnesse 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 deconceito.

As estratégias para auxiliar na decisão que podem ser utilizadas na arquiteturaproposta variam desde o uso de algoritmos para agentes inteligentes baseados emutilidades [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 nosubsistema de estratégias.

O subsistema de decisão por meio das políticas e das estratégias estabelecidasdefine quais os serviços que podem ser disponibilizados para o usuário a partir dapercepçã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 comsuas 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 atemperatura 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 detreinamento.

Nos casos em que mais de um usuário esteja disputando o mesmo serviço osubsistema de decisão poderá fazer a média ponderada e recomendar a temperatura idealpara todos. Outro exemplo de serviços seria o de localização de periféricos maispróximos do usuário, por exemplo, uma impressora. Nesse caso se o usuário desejasseimprimir um trabalho em uma impressora diferente da que normalmente imprime, oserviço de impressão o avisaria por meio de um sistema de mensagens que haveria umaimpressora mais próxima a ele.

Diversos serviços podem ser desenvolvidos usando a arquitetura para isso bastaconstruir as políticas e estratégias baseadas nas análises dos dados de sensores eatuadores.

5. Desenvolvimento do Protótipo

Durante o desenvolvimento do trabalho foi necessário instalar e configurar o hardwaree o software usados no protótipo e para isso foram utilizados os dispositivos citados naTabela 2 os quais foram instalados nas dependências do laboratório de sistemas móveise 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 decomandos de modem AT via porta serial. Os comandos AT principais utilizados para aconfiguração dos nós XBee são apresentados na Tabela 3, esses comandos podem serdigitados diretamente em um terminal Linux. Um exemplo de comando para configurarum módulo XBee como servidor pode ser digitado da seguinte forma: "ATMY1,ATDL2, ATNIserver, ATWR, ATCN". É muito importante não esquecer que comexceção do comando +++ todos os outros comandos precisam da tecla <enter> para queo 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 noambiente, podendo ser sensores de luminosidade, temperatura, umidade, abertura efechamento de porta, sensores de presença, entre outros. Neste protótipo foi utilizadosensores de presença, informando e armazenando em banco de dados as ações depresença no ambiente e sensores de abertura e fechamento de portas. A Figura 3apresenta o banco de dados desenvolvido de acordo com o módulo depré-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 entidadesmapeadas a partir dos dados que se pretendia coletar na fase de experimentos. Porexemplo, horário de entrada, saída para almoço, saída para lanche, idas ao banheiro epermanência na mesa de trabalho. As entidades principais responsáveis peloarmazenamento são o usuário, ligado a um ou mais dispositivos, as entidades sensor eactuator, responsáveis por coletar dados de ação e de sensoriamento do ambiente, e aentidade 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 executarações nos atuadores e verificar a situação dos sensores que em seguida são armazenadasna entidade ação. Todas as ações armazenadas na base poderão ser avaliadas pelomódulo cognitivo para extrair características de contexto e recomendar serviços aousuá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 atuadoresque são relacionados com as ações executadas por eles. Cada usuários está relacionadocom os dispositivos móveis que utiliza e esses dispositivos também são interligados àsações por meio do endereço de MAC. Desta forma é fácil mapear as atividades dossensores e atuadores, dispositivos móveis e, por sua vez, os usuários donos dosdispositivos. No experimento foi utilizado o endereço MAC do dispositivo paracomparar com o endereço armazenado na base de dados somente para substituir o usodas tecnologias de localização porque da forma como a solução foi construída é possívelassociar na base de dados de sensores qual mesa de trabalho pertence a que usuário e seo 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 osistema busca obter o endereçamento físico local do dispositivo (endereço MAC local) eo envia ao servidor, como uma requisição do tipo string, por meio do protocolo dehipertexto HTTP usando o método POST. Por sua vez o servidor recebe a requisição epor meio da consulta à base de dados, confirma a existência do cadastro do dispositivodo usuário.

Figura 4. (A) Maquete utilizada no experimento (B) Aplicativo móvel desenvolvido emAndroid


33

Confirmada a permissão de acesso do dispositivo, o servidor retorna umamensagem de confirmação para que seja mostrada ao usuário. Após o acesso ao sistemao usuário tem a possibilidade de realizar controles do ambiente como ligar e desligarlâmpadas condicionador de ar e outros dispositivos que possam ser monitorados. Essasatividades feitas no ambiente por meio de um smartphone ou tablet, são armazenadas nabase de dados para posterior análise contextual.

Logo após a identificação e execução da ação, o servidor envia uma mensagemde confirmação informando que a ação solicitada foi executada. Caso haja erro deidentificaçã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 emuma maquete desenvolvida no laboratório para simular o acionamento de lâmpadas noscomôdos de uma residência e a Figura 5 apresenta o ambiente real da coleta de dadosfeita 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 aberturae 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 capturaro movimento nas mesas de trabalho dos usuários enquanto que o sensor de abertura deporta do tipo contato, foi instalado de modo a permitir a coleta dos dados das aberturas efechamentos da porta do laboratório. A Figura 5 C apresenta o log da inserção dosdados na base.

6. Resultados e Conclusões

O presente trabalho apresentou uma arquitetura experimental para automação eintegraçã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 paradispositivos móveis e um servidor para coletar dados de sensores e atuadores. Aarquitetura permitiu a integração desse dispositivos com sensores e atuadores paramonitorar um ambiente e disponibilizar serviços baseados no histórico de uso.

O conjunto de dados apresentado na arquitetura foi desenvolvido usando o bancode dados relacional MySQL e suportou o armazenamento de uma quantidadesignificativa de dados dos sensores, (40.000 tuplas) durante um mês de coleta diáriassem travamentos. Esses dados serão tratados na camada cognitiva na próxima fase doprojeto, por meio das ações baseadas em estratégias e regras tendo como resultado finala recomendação do uso de equipamentos de acordo com o perfil do usuário extraídos dabase de dados.

Um protótipo para dispositivos móveis simulando um ambiente residencial e deescritório foi desenvolvido para testar a inserção automática dos dados de sensores eatuadores bem como a identificação automática do dispositivo móvel do usuário pormeio do endereço físico de rede, permitindo simular a identificação da entrada e saídado usuário no ambiente monitorado.

Além da coleta de dados em ambiente real foi disponibilizado também umamaquete para teste de acionamentos de equipamentos eletrônicos para simular o uso delâmpadas e condicionadores de ar do ambiente.

Os resultados do trabalho foram a coleta de dados para a formação de uma basede conhecimento, a integração entre o hardware dos sensores e atuadores com aaplicação servidor e o acesso aos dados via rede sem fio com autenticação automáticafeita pelo dispositivo móvel através da verificação do endereço físico do dispositivo narede.

A Estratégia utilizada para armazenar os endereços e reconhecer o usuário pormeio de seu dispositivo, foi modelar os dados baseaando-se nas ações dos dispositivos enão na ação do usuário. Em outras palavras, os dispositivos é que executam as açõesassim 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çõesfuturas com a integração de agentes no módulo cognitivo e gerência de contexto paragerenciar e filtrar os dados no módulo de pré-processamento

Os próximos passos da pesquisa serão construir um preditor para analisar osdados coletados na base e traçar o perfil do usuário para recomendar os serviços de umaresidê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-UFAMpelo 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 Conference of the IEEE

Computer and Communications Societies, vol. 2, pp. 775-784, 2000.


36

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, mas

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 de

prateleira - COTS e interfaces de padrões abertos. Os objetivos do desenvolvimento do

modelo foi o de definir e desenvolver uma arquitetura capaz de suportar uma série de

plataformas de VANTs do Exército norte-americano demonstrando o desempenho do

sistema resultante em ambiente de laboratório.

3. RFCSA

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 homem-

má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. Tabela 1

Comparativo entre os principais trabalhos encontrados na literatura aberta e o LARISSA.

Camada / Projeto

MC

AP

Tra

bal

ho

de P

asto

r,

Lo

pez

e R

oy

o

RF

CS

A

LM

A

Tra

bal

ho

de

Ila

rsla

n, B

ayra

kce

ken

e A

riso

y

AN

KA

Lin

ux

-bas

ed

AR

INC

65

3

LA

RIS

SA

Física do segmento aéreo - parcial parcial parcial √ - - √

RTOS distribuída parcial √ parcial parcial parcial - parcial √

Abstração do sistema - - - √ - - - √

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 √


47

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 Recuperacao em Baterias deNodos em Redes de Sensores sem Fio

Leonardo M. Rodrigues1, Carlos B. Montez1, Paulo Portugal2, Francisco Vasques2

1 Programa de Pos-Graduacao em Engenharia de Automacao e Sistemas (PPGEAS)Universidade Federal de Santa Catarina (UFSC) – Florianopolis, SC – Brasil

2Faculdade 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 questao energetica emnodos de uma Rede de Sensores sem Fio (RSSF). Sao abordados alguns mode-los de bateria utilizados em simuladores para representar o comportamento deuma bateria ao longo do tempo, conforme o consumo energetico imposto pelosnodos. A importancia do escalonamento de tarefas nos nodos (escalonamentodo sono) tambem e discutida, assim como o chamado efeito recuperacao das ba-terias. Resultados de simulacoes sao usados para demonstrar a importancia doescalonamento na execucao de atividades em cada nodo, refletindo no aumentodo tempo de vida da rede.

1. Introducao

O desenvolvimento, seguido pela evolucao e reducao nos precos, de nodos sensorestem levado a uma popularizacao das Redes de Sensores sem Fio (RSSF). Esses no-dos – com capacidade de processamento, comunicacao e sensoriamento de grandezasdo ambiente (ex. temperatura, umidade, som, pressao atmosferica) – tem propiciado oemprego de RSSF nos mais diversos domınios de aplicacao [Buratti et al. 2009]. Ori-ginalmente, uma Rede de Sensores sem Fio era definida como aquela formada porum grande numero de nodos, espalhados de forma aleatoria e com capacidades deauto-gerenciamento [Akyildiz et al. 2002]. Atualmente, encontra-se esse tipo de redeempregado em um escopo muito mais amplo, desde aplicacoes em ambientes indus-triais [Gungor and Hancke 2009] - onde muitas vezes ha um numero limitado de no-dos os quais sao cuidadosamente implantados - ate em aplicacoes da agropecuaria[Aqeel-ur-Rehman et al. 2011] - onde e possıvel a existencia de milhares de nodos, al-guns com mobilidade.

Independente do domınio de aplicacao, em comum a todos os tipos de RSSF,existe o conceito de “esforco colaborativo” entre os nodos, no sentido de monitorar asgrandezas do ambiente. A ideia basica e que a confianca no monitoramento seja baseadaem um grupo de sensores, de baixo custo, em vez de se basear em sensores individuais.Ademais, geralmente ha uma redundancia no numero de nodos implantados, de formaque nem todos necessitam monitorar a mesma grandeza fısica simultaneamente. Outracaracterıstica importante nas RSSF e a necessidade de economia energetica. O uso debaterias nos nodos implica na preocupacao de se manter a rede operacional o maior tempopossıvel. Isso e decorrente do fato da substituicao de baterias, quando ocorrerem seus


55

esgotamentos, poder ser uma tarefa inviavel ou ter um custo financeiro proibitivo, quandoa rede, por exemplo, for implantada em locais inospitos ou tiver grande numero de nodos.

A redundancia em RSSF e a necessidade de se estender o tempo de vida da redeimplicam no estabelecimento de polıticas para se efetuar rodızio na utilizacao dos nodosde forma eficaz. Quando a voltagem da bateria atinge um determinado nıvel, conhecidocomo cutoff, as reacoes eletroquımicas internas deixam de acontecer, indicando que amesma esta descarregada. Alguns nodos cujas baterias estejam proximas aos seus esta-dos de cutoff podem ser encarregados de executar tarefas que consumam menos energia,podendo ate mesmo entrar em regimes ociosos (sleep mode) enquanto outros nodos, commaior capacidade atual em suas baterias, assumem as tarefas de monitoramento e proces-samento local na rede.

As tecnicas que realizam alternancia na execucao dos nodos muitas vezes sao de-nominadas de escalonamento do sono (sleep scheduling) [Jurdak 2010]. Contudo, muitosdos trabalhos sobre este assunto sao baseados em simulacoes nas quais assume-se queas baterias dos nodos tem comportamento simples, muitas vezes, lineares. Esse tipo desuposicao pode afetar os resultados obtidos pelas simulacoes, pois as baterias possuemcomportamentos bem mais complexos e difıceis de se modelar.

No contexto de modelagem de baterias, algumas pesquisas apontamsolucoes para estimar o tempo de vida de baterias sob diversos tipos de car-gas [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 preocupacaoem definir modelos que representem os efeitos da Taxa de Capacidade (Rate CapacityEffect) e o de Recuperacao (Recovery Effect), inerentes as baterias.

De uma forma simplificada, o Efeito Taxa de Capacidade representa o compor-tamento nao-linear da bateria quando submetida a diferentes descargas de corrente; en-quanto o Efeito Recuperacao representa a habilidade da bateria em se recuperar quandoesta ociosa ou submetida a cargas baixas. Estudos na literatura [Rakhmatov et al. 2002,Li et al. 2013] apontam a existencia de diferencas nos tempos de vida das baterias, de-correntes desses efeitos, conforme a ordem escolhida pelos nodos na execucao de suastarefas. Neste artigo e investigado, no contexto das RSSF, o tempo de vida dos nodos,conforme a escolha das atividades de transmissao e recepcao de dados, alem de atividadesde processamento. O objetivo e mostrar os efeitos da Taxa de Capacidade e Recuperacaonas baterias sob o ponto de vista do escalonamento de sono dos nodos da rede.

Este artigo esta organizado da seguinte forma. A Secao 2 trata sobre os conceitosbasicos envolvidos neste trabalho. A Secao 3 mostra algumas definicoes com relacao aomodelo utilizado. A Secao 4 apresenta as simulacoes realizadas, bem como alguns resul-tados preliminares obtidos neste trabalho. Na Secao 5, apresentam-se as consideracoesfinais sobre os assuntos discutidos neste artigo.

2. Fundamentacao TeoricaEsta secao tem como objetivo abordar alguns conceitos importantes que estao diretamenteligados ao conteudo deste artigo. Inicialmente, abordam-se as questoes basicas sobrebaterias, tal como funcionamento e caracterısticas fısicas. Em seguida, sao vistos osconceitos sobre modelos de baterias conhecidos na literatura. Por fim, e feita uma revisaosobre escalonamento de tarefas em nodos.


56

2.1. Conceitos sobre Baterias

As baterias sao fundamentais nos dias de hoje, sem as quais, o conceito de mobilidadenao existiria. Basicamente, baterias sao dispositivos que contem uma ou mais celulaseletroquımicas capazes de transformar energia quımica em energia eletrica. As celulas saoformadas por dois terminais (eletrodos): o positivo (ou catodo) e o negativo (ou anodo).Um eletrolito permite o fluxo de ıons entre os terminais da bateria.

VCátodo

Ânodo

e-

-+

Eletrólito

Figura 1. Modo de funcionamento de uma bateria.

De forma geral, ao descarregar uma bateria, ocorre a oxidacao do anodo, gerandoeletrons (que fluem pelo circuito externo) e ıons carregados positivamente (que, por di-fusao, movem-se pelo eletrolito em direcao ao catodo). Reacoes de reducao ocorrem nocatodo, gerando ıons carregados negativamente. A Figura 1 ilustra o funcionamento deuma bateria simples.

Alem disso, cada bateria tem duas caracterısticas proprias: VOC e a voltagem emcircuito aberto, ou seja, a carga total armazenada na bateria sem a presenca de nenhumacorrente de descarga; e Vcut e o limite que indica quando a bateria esta descarregada. Doisparametros importantes sao a capacidade teorica, que especifica qual a quantidade decarga maxima que uma bateria suporta, e a capacidade atual, que estabelece a quantidadede energia que uma bateria entrega sob uma determinada carga [Lahiri et al. 2002].

Existem diversos tipos de tecnologias de baterias recarregaveis: Ni-Cd (Nıquel-Cadmio), Ni-MH (Nıquel-Hidreto Metalico), Li-ion (Ions de Lıtio), Li-polymer (Lıtio-polımero). A tecnologia Ni-Cd foi amplamente utilizada em diversos dispositivoseletronicos (celulares e laptops, principalmente) devido ao seu baixo custo, entretanto,perdeu espaco devido a baixa capacidade de carga e ao “efeito memoria1”. A tecnologiaNi-MH tem densidade de energia duas vezes maior que a tecnologia Ni-Cd, porem, temmenor ciclo de vida, e mais cara e ineficiente com altas taxas de descarga. A bateria Li-ion e uma das mais utilizadas na atualidade, contando com maior densidade de energiae ciclo de vida cerca de duas vezes maior que as baterias Ni-MH. Por outro lado, temmaior sensibilidade a correntes de descarga e e mais cara que a tecnologia Ni-MH. Porfim, as baterias Li-polymer sao tao eficientes quanto a tecnologia Li-ion e ainda possuemum involucro flexıvel, o que as tornam adequadas para uso em dispositivos moveis comtamanho e peso reduzidos [Lahiri et al. 2002].

1Diminuicao da capacidade de carga com o passar do tempo.


57

2.1.1. Efeitos intrınsecos

Existem dois efeitos que estao presentes em qualquer bateria, independentemente datecnologia utilizada: Efeito da Taxa de Capacidade (Rate Capacity Effect) e EfeitoRecuperacao (Recovery Effect). Tais efeitos sao muito importantes para o tempo de vidae a capacidade de uma bateria.

• Efeito Taxa de Capacidade: esta relacionado a dependencia entre a capacidadeatual da bateria e a magnitude da corrente de descarga. Neste caso, ao aplicar altascorrentes de descarga, a capacidade da bateria e significativamente reduzida.• Efeito Recuperacao: refere-se a habilidade que as baterias tem 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 paraque a bateria tenha um maior tempo de vida [Li et al. 2013].

2.2. Modelos de Baterias

As questoes energeticas sao de extrema importancia no contexto das RSSF, uma vez queo tempo de vida da rede depende das baterias individuais dos nodos que dela participam.E desejavel que cada nodo maximize seu tempo de vida, podendo contribuir com a redepelo maior perıodo possıvel. Em um exemplo simples, onde um conjunto de nodos rea-liza o sensoriamento de uma determinada area, a falha de um nodo, por ter a sua bateriaexaurida, pode enfraquecer a precisao dos dados coletados naquela area especıfica. Issoprejudica a cobertura espacial da rede, tornando a captura de dados presente em apenasalguns locais e inexistente em outros. Dessa forma, o estudo de tecnicas que permitam oaumento no tempo de vida de baterias e contınuo, reforcando a busca por novas tecnolo-gias, algoritmos mais eficientes e modelos de bateria mais precisos.

2.2.1. Modelos de Bateria Analıticos

Os modelos de bateria analıticos sao fundamentacoes matematicas baseadas em equacoesque buscam considerar as caracterısticas fısicas das baterias. Servem para estimar, con-forme a carga aplicada, o tempo de vida das baterias. Esses modelos descrevem a bateriade forma abstrata, porem, suas propriedades sao modeladas utilizando apenas algumasequacoes [Jongerden and Haverkort 2008a]. Por envolverem a avaliacao de expressoesanalıticas, tornam-se computacionalmente flexıveis [Schneider et al. 2001]. Ou seja, epossıvel utilizar correntes como uma funcao de carga constante ou variavel, ou alterar otipo de bateria. Alem disso, podem modelar os efeitos eletroquımicos inerentes as bate-rias, tais como o Efeito Recuperacao e o Efeito da Taxa de Capacidade.

O modelo mais simples e a Lei de Peukert. Ele considera parte dos efeitos naolineares, relacionando o tempo de vida da bateria com a taxa de descarga. Porem, o EfeitoRecuperacao nao faz parte do modelo. Assim, os resultados obtidos com a Lei de Peukertsao considerados bons apenas para cargas contınuas constantes, sendo inadequado quandocargas variaveis ou interruptas sao usadas [Jongerden and Haverkort 2008a].

Em [Rakhmatov and Vrudhula 2011], os autores introduzem um novo modelo quedescreve o processo de difusao do material ativo na bateria. Esse modelo permite estimar


58

o tempo de vida da bateria, com uma boa aproximacao, para uma dada corrente de des-carga utilizando os dez primeiros termos de uma soma infinita.

I

ij

h2

h1

k

1 - c c

Carga DisponívelCarga Limite

Figura 2. Kinect Battery Model (KiBaM) [Manwell and McGowan 1993].

Outro modelo analıtico e o KiBaM [Manwell and McGowan 1993]. Este modeloabstrato e bastante intuitivo, sendo composto por dois tanques onde a carga da bateriae distribuıda, conforme ilustra a Fig. 2. O tanque Carga Disponıvel fornece energia aodispositivo ligado diretamente a bateria. Ja o tanque Carga Limite fornece carga ao tanqueCarga Disponıvel. Entretanto, a taxa a qual ocorre a transferencia de carga depende dadiferenca entre as alturas das cargas nos dois tanques (h1 e h2), alem do parametro k.O parametro c indica uma fracao 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 adiferenca 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 alturah1 seja novamente igual a altura h2. Assim, durante um perıodo ocioso, a bateria podeaumentar sua capacidade e, consequentemente, manter-se ativa por mais tempo. O fluxoentre os tubos e dado pelo sistema de equacoes diferenciais mostrado na Equacao 1.{

didt = −I + k(h2 − h1),djdt = −k(h2 − h1),

(1)

tendo como condicoes iniciais: i(0) = c·C e j(0) = (1−c)·C, onde C representa a capaci-dade total da bateria. Alem disso, h1 = i/c e h2 = j/(1−c). Tal sistema de equacoes podeser resolvido utilizando transformadas de Laplace [Jongerden and Haverkort 2008b]. AEquacao 2 mostra como calcular a quantidade de carga nos dois tanques.i = i0e

−k′t + (y0k′c−I)(1−e−k′t)k′ − Ic(k′t−1+e−k′t)

k′

j = j0e−k′t + y0(1− c)(1− e−k

′t)− I(1−c)(k′t−1+e−k′t)k′ ,

(2)

onde k′ e definido como:k′ =

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 desenvol-vido para modelar baterias Acido-Chumbo. Segundo [Jongerden and Haverkort 2008a],tal modelo nao e adequado para baterias modernas utilizadas em dispositivos moveis,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 Efeitoda Taxa de Capacidade quanto o Efeito Recuperacao.

2.2.2. Modelos de Bateria Estocasticos

Segundo [Jongerden and Haverkort 2008a], os primeiros modelos de bateria estocasticosforam desenvolvidos por Chiasserini e Rao, entre 1999 e 2001. Tais modelos sao baseadosem Cadeias de Markov com Tempo Discreto e produzem uma boa descricao qualitativado comportamento da bateria sob pulsos de descarga. Entretanto, o modelo proposto porChiasserini considera apenas o Efeito Recuperacao, nao conseguindo lidar com perfis decarga arbitrarios com descargas de corrente variavel (Efeito da Taxa de Capacidade).

Em 2005, [Rao et al. 2005] propos um modelo de bateria, tambem utilizando Ca-deias de Markov, baseado no modelo analıtico KiBaM [Manwell and McGowan 1993].No entanto, a formulacao foi alterada para baterias Ni-MH, comumente utilizadas emnodos de uma RSSF. Os resultados experimentais deste modelo indicam que o tempode vida da bateria de Ni-MH depende da frequencia da carga aplicada, o que nao ocorreno KiBaM original (para escalas de tempo menores que 30 minutos). A solucao envolvefazer com que a probabilidade de recuperar capacidade durante perıodos ociosos dependado tamanho do perıodo [Jongerden and Haverkort 2008a].

2.3. Tecnicas de Escalonamento

Escolher a ordem na qual as tarefas2 devem ser realizadas em um nodo influencia a taxade descarga da sua bateria, pois a submete a diferentes correntes, ativando os seus efeitosinerentes, tais como o Efeito Recuperacao e o Efeito da Taxa de Capacidade. Algumastarefas consomem mais energia que outras, exigindo mais corrente ou levando mais tempopara concluir. A escolha da ordem de execucao das tarefas e chamada de escalonamentode tarefas ou escalonamento do sono.

Apesar das pesquisas no escalonamento de tarefas ja terem bem mais do queuma decada, um desafio que ainda necessita ser superado e o de como escolher a or-dem de execucao das tarefas de forma que o tempo de vida das baterias seja maximi-zado [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 impactodo sequenciamento de tarefas para a bateria do nodo. Uma conclusao desse trabalho eque o tempo de vida da bateria e maximizado quando as tarefas sao escolhidas de formaque haja um decrescimento nas cargas de corrente das tarefas. Ou seja, enquanto a bateriatem mais carga, as tarefas do nodo que consomem mais carga sao escolhidas primeiro. Amedida que a capacidade da bateria do nodo e reduzida, as tarefas que consomem menoscarga sao as escolhidas para executar.

Em [Li et al. 2013], apresenta-se a formulacao do problema atraves de um simplesexemplo para transmissao de pacotes em aplicacoes de tempo real brandas (soft real-time).Alem disso, esse trabalho propoe um algoritmo de otimizacao local ciente de bateria queinsere perıodos ociosos entre tarefas adjacentes, tirando proveito do Efeito Recuperacao.Com isso, o objetivo e minimizar o consumo de carga total do sistema.

2O termo tarefa se refere a qualquer atividade do nodo que necessite de carga da bateria.


60

3. ModeloEsta secao apresenta o modelo de bateria utilizado nas simulacoes. Com relacao ao am-biente de simulacao, utiliza-se o GNU Octave [Eaton 2014]. Por se tratar de uma lin-guagem interpretada de alto nıvel, bem estabelecida e voltada para calculo numerico, aimplementacao de modelos matematicos e facilitada.

Como visto na Secao 2.2, existem diversos modelos de bateria, cada um comsuas caracterısticas. O objetivo deste trabalho e observar o aumento no tempo de vidade uma RSSF quando o Efeito Recuperacao faz parte da rotina dos nodos nesta rede.Alem disso, deseja-se simular adequadamente o Efeito da Taxa de Capacidade quandodiferentes cargas sao aplicadas nas baterias dos nodos da rede.

Diante desses motivos, um dos modelos de bateria que se encaixa no perfil descritoe o KiBaM. Tal modelo aborda com certa simplicidade e grande abstracao os conceitoscaracterısticos de uma bateria atraves da Equacao 2. Utiliza-se uma funcao, denominadakibam, que e chamada sempre que um nodo necessita executar uma tarefa (ou um conjuntode tarefas). O Algoritmo 1 descreve de forma simplificada o funcionamento da funcao.

Algoritmo 1: Funcao KiBaMEntrada: y0, i0, j0, I, timeInit, periodSaıda: y0

1 inıcio2 initializeConstantsAndVariables();3 enquanto t ≤ (timeInit + period) faca4 compute-i(y0, i0, j0, I, t);5 compute-j(y0, i0, j0, I, t);6 saveOutput(i, j, t);7 fim8 updateVariables();9 fim

De acordo com o Algoritmo 1, a funcao KiBaM tem parametros relacionados aonodo 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 teorica dabateria, i0 e a quantidade de carga no tubo Carga Disponıvel, j0 e a quantidade de cargano tubo Carga Limite, I e a corrente aplicada pela tarefa, timeInit e o tempo de inıcio dasimulacao e period e o tempo de execucao da tarefa.

O nucleo dessa funcao esta no calculo do conteudo dos tubos Carga disponıvel(i) e Carga Limite (j) (linhas 4 e 5, respectivamente). Para isso, utilizam-se as definicoesencontradas na Equacao 2. Por fim, o estado de cada tubo da bateria e salvo em umarquivo a parte para analises e geracao de graficos (linha 6).

4. ResultadosEsta secao visa apresentar as simulacoes realizadas e os resultados preliminares desta pes-quisa. O objetivo das simulacoes e fazer que o nodo execute ate que a carga em sua bateriaseja esgotada (ou alcance um valor mınimo predeterminado, cutoff ). O nodo e alimen-tado por uma bateria com capacidade teorica de 1000mAh (ou 3600 As) e conta com umconjunto de tarefas para executar, bem como seus respectivos tempos de execucao.


61

Tabela 1. Cargas utilizadas nas simulacoes.

Tarefa Carga (mA) Tempo de execucao (min)

A 40 10B 20 5C 5 0− 20

O conjunto de tarefas utilizadas em todas as simulacoes e composto por tres tarefas(Tabela 1). A primeira, denominada de A, tem consumo de 40mA e executa por 10min.A segunda, B, consome 20 mA e tem tempo de execucao igual a 5 min. Por fim, aterceira, C, consome 5 mA e e executada por tempos variando entre 0 − 20 min, deacordo com a simulacao.

Sob o ponto de vista do nodo, tais tarefas equivalem, por exemplo, a uma aplicacaode monitoramento ambiental. Neste contexto, a Tarefa A representa o processamentocontınuo por um determinado tempo (10 min) realizado por um nodo, correspondendo auma leitura de sensor, um pequeno processamento local e transmissao do resultado paraoutro nodo. A Tarefa B equivale ao perıodo que o radio receptor fica ligado a espera denovas comunicacoes de outro nodo. Finalmente, a Tarefa C representa um perıodo ocioso(sleep mode) que o nodo tem para fazer valer o Efeito Recuperacao em sua bateria.

A funcao KiBaM e usada para calcular a quantidade de carga consumida na ba-teria quando o nodo executa sua tarefa atual. Assim, a capacidade da bateria e reduzidaconforme a carga (corrente) aplicada ao realizar uma tarefa (Efeito da Taxa de Capaci-dade). Caso o nodo entre no sleep mode, o KiBaM e responsavel por modelar o ganhode capacidade na bateria do nodo (Efeito Recuperacao). Utilizam-se os seguintes valorespara as constantes da Equacao 2: k = 10−5 e c = 0, 625.

Os resultados das simulacoes sao mostrados em graficos que descrevem a descargano tubo Carga Disponıvel do nodo. Quatro cenarios de uso sao empregados para ilustrardiferentes situacoes de execucao das tarefas do(s) nodo(s).

Carg

a D

isponív

el (A

s)

Situação 1 Situação 2

Figura 3. Cenario 1: Nodo sem sleep mode (Situacao 1).Nodo com sleep mode de 8 horas (Situacao 2).


62

4.1. Cenario 1

O Cenario 1 e usado para ilustrar a diferenca nos tempos de execucao com e sem EfeitoRecuperacao. Com isso, consideram-se duas situacoes. A Situacao 1 investiga o funcio-namento 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 Situacao 2, o nodo opera normalmente(tal qual a Situacao 1) ate o momento que entra em sleep mode (em t = 850, aproxima-damente). Neste momento, o nodo passa a executar a tarefa C, tirando proveito do EfeitoRecuperacao por um determinado tempo (8 horas) e, entao, retorna a atividade realizadaanteriormente, isto e, execucao da tarefa A.

Na Figura 3, ao entrar em sleep mode (Situacao 2), a bateria do nodo tem maiortempo de vida. Na Situacao 1, o nodo consegue operar por um tempo3 de 1200 min(20 horas). Ja a Situacao 2, com sleep mode de 8 horas, o tempo alcancado e de1550 min (25, 833 horas) de funcionamento. Poder-se-ia pensar que o nodo deveriater um tempo de vida de pelo menos 28 horas, afinal, na situacao sem o sleep mode seutempo de vida foi de 20 horas. Porem, ao dormir por 8 horas, o nodo ainda esta consu-mindo energia, mesmo que seja uma carga bastante baixa (5 mA). E possıvel visualizaresse fenomeno na Figura 3 (Situacao 2), onde a bateria do nodo recupera parte de suacapacidade e, em determinado momento, chega a um limite onde nao consegue mais serecuperar. A partir desse ponto, e reiniciado o processo de descarga.

Carg

a D

isponív

el (A

s)

Situação 1

Situação 2

Situação 3

Situação 4

Figura 4. Cenario 2: Nodo sem sleep mode (Situacao 1).Com diferentes tempos em sleep mode (Situacao 2, 3 e 4).

4.2. Cenario 2

No Cenario 2, utilizam-se diferentes tempos para o sleep mode. Na primeira situacao, onodo executa a tarefa principal A sem que exista “descanso” para a bateria. Na segundasituacao, insere-se a tarefa C com perıodo em sleep mode igual a metade do tempo deexecucao da tarefa A, isto e, 5 min. Na terceira situacao, alem da tarefa A, executa-sea tarefa C pelo tempo de 10 min. Na quarta situacao, o perıodo da tarefa C sobe para

3O termo “tempo” nao se refere ao tempo real, mas sim a uma expectativa decorrente da simulacao.


63

o dobro do tempo de execucao da tarefa A, ou seja, 20 min. O nodo executa de formacıclica, isto e, executa sua tarefa principal e, em seguida, entra em sleep mode pelo tempodeterminado de acordo com a situacao simulada. O processo e reiniciado ao termino dosleep mode. A Figura 4 demonstra a execucao das situacoes citadas.

De acordo com a Figura 4, a execucao com sleep mode (Situacoes 2, 3 e 4) au-menta os tempos de vida do nodo. Na Situacao 1, sem sleep mode, o tempo de vida dabateria e de 1200 min (20 horas). Na Situacao 2, que utiliza um ciclo de execucao comas tarefa A e C (sleep mode de 5min), o tempo de duracao da bateria sobe para 1455min(24, 250 horas). Na Situacao 3, que executa as tarefas A e C (sleep mode de 10 min),o tempo de vida da bateria alcanca 1680 min (28 horas). Por fim, na Situacao 4, queexecuta as tarefas A e C (sleep mode de 20 min), o tempo de vida da bateria alcanca2070min (34, 5 horas).

Tabela 2. Tempos obtidos no Cenario 2.

Situacao Sleep Mode Tarefa(s) Tempo (min)

1 Nao A 1200 (20, 00 h)2 Sim (5min) AC 1455 (24, 25 h)3 Sim (10min) AC 1680 (28, 00 h)4 Sim (20min) AC 2070 (34, 50 h)

A Tabela 2 resume os resultados encontrados na simulacao. Neste cenario,percebe-se claramente que, ao inserir perıodos ociosos na realizacao das tarefas donodo, ocorre um aumento significativo no tempo de vida da sua bateria gracas ao EfeitoRecuperacao. Comparando as Situacoes 1 e 3 deste cenario, o aumento no tempo de vidada bateria do nodo e de 40%. No caso da Situacao 3, o tempo em sleep mode e igualao tempo de execucao da tarefa A. Ao comparar as Situacoes 1 e 4, onde o sleep modeequivale ao dobro do tempo de execucao da tarefa A, o aumento no tempo de vida dabateria sobe para 72, 5%.

4.3. Cenario 3

No Cenario 3, acrescenta-se outra tarefa (B). O objetivo e verificar a influencia da ordemde execucao das tarefas para o Efeito Recuperacao e, consequentemente, para o tempode vida da bateria. O nodo executa o conjunto de tarefas mostrado na Tabela 1 em umadeterminada ordem e de forma cıclica. Sao consideradas seis situacoes.

Tabela 3. Tempos obtidos no Cenario 3.

Situacao Sleep Mode Ordenacao Tempo (min)

1 Nao {AB} 555 (09, 25 h)2 Sim (10min) {ACB} 725 (12, 08 h)3 Sim (10min) {ABC} 750 (12, 50 h)4 Nao {BA} 570 (09, 50 h)5 Sim (10min) {BCA} 750 (12, 50 h)6 Sim (10min) {BAC} 750 (12, 50 h)

Na Situacao 1, o perıodo em sleep mode nao e considerado, sendo admitida aordem de execucao AB. Para a Situacao 2, o perıodo em sleep mode e acrescentado entre


64

as tarefas principais, com ordem de excucao ACB. Na Situacao 3, o perıodo em sleepmode e deslocado para o fim do ciclo, sendo sua ordem: ABC. Na Situacao 4, retira-se a tarefa C e a tarefa B e deslocada para o comeco do ciclo. Neste caso, a ordem deexecucao e BA. A Situacao 5 passa a considerar o sleep mode, com ordem de execucaoBCA. Por fim, na Situacao 6 o perıodo em sleep mode e deslocado para o fim do ciclo,com ordem de execucao BAC.

Os tempos de execucao podem ser observados na Tabela 3. E possıvel notar que aordem de execucao das tarefas pode influenciar o tempo de vida da bateria do nodo. Maisespecificamente, nas Situacoes 2 e 3 existe uma pequena diferenca nos tempos obtidospela simulacao. Ao observar as Situacoes 1 e 4, tambem e possıvel perceber uma pequenadiferenca nos tempos obtidos, sendo que nestes casos nao sao considerados os perıodosem sleep mode.

4.4. Cenario 4No Cenario 4, dois nodos sao utilizados para verificar a diferenca nos tempos de vida desuas baterias com e sem o Efeito Recuperacao. Os nodos tem baterias com a mesma capa-cidade teorica. Sao consideradas duas situacoes com diferentes formas de escalonamento.

t (min)

Nodo 1

Nodo 2

Nodo 1

Nodo 2

t (min)

t (min)

t (min)

Sit

uaçã

o 2

Sit

uaçã

o 1

0 10 20 30 40 50 60 70 80 90 100

Legenda: Executando Sleep Mode

Figura 5. Escalonamentos utilizados no Cenario 4.

Na Situacao 1, cada nodo executa a tarefa A de forma simultanea, sem haverperıodos em sleep mode. Na Situacao 2 adota-se um revezamento entre os nodos: en-quanto um nodo executa a tarefa A, o outro nodo entra em sleep mode (execucao da tarefaC pelo mesmo tempo da tarefa A, isto e, 10 min), valendo-se do Efeito Recuperacao dabateria. Esse ciclo e repetido ate que o nıvel mınimo de bateria (cutoff ) em ambos osnodos seja atingido. A Figura 5 mostra um esquema que resume o modo de execucao emcada uma das situacoes descritas anteriormente.

Na Figura 6 e ilustrada a execucao das situacoes 1 e 2, alem de uma situacaodenominada de ’∗’. A Situacao ’∗’ e equivalente a Situacao 2, porem, representa o com-portamento de um modelo de bateria que nao leva em conta o Efeito Recuperacao. Ba-sicamente, ao inves do nodo recuperar a capacidade da bateria no perıodo ocioso, elemantem a mesma capacidade da execucao anterior para a proxima tarefa. Essa situacaoe usada na figura para contrastar com a Situacao 2 e mostrar o Efeito Recuperacao e otempo adicional que esse efeito acrescenta no tempo de vida da bateria.

A bateria na Situacao ’∗’ alcanca um tempo de vida de 1382, 3min (23, 03 horas).Esse valor pode ser obtido de forma aproximada atraves de um simples calculo. O tubo


65

Carg

a D

isp

on

ível (A

s)

Situação 1 Situação 2

Nodo 1

Nodo 2

Situação *

Figura 6. Cenario 4: Nodos sem sleep mode (Situacao 1).Nodos intercalados com sleep mode (Situacao 2).Nodos intercalados com sleep mode mas

sem Efeito Recuperacao (Situacao ’∗’).

Carga Disponıvel tem capacidade de 625 mAh (ou 2250 As) e a carga executada e de40 mA. A razao entre esses valores (625 mAh/40 mA) resulta em 15, 625 horas, queequivale ao tempo total caso o nodo executasse continuamente. No entanto, como asituacao especıfica adota uma execucao intercalada, e preciso levar em consideracao ostempos em que o nodo nao executa. Em 1 hora o nodo tem tres perıodos ociosos (nestecaso, nao ha recuperacao da bateria). Por conseguinte, em 15, 625 horas, o nodo tem46, 875 perıodos ociosos. Como cada perıodo ocioso tem duracao de 10min, multiplica-se a quantidade de perıodos ociosos; o resultado e 468, 75min (7, 81 horas). Finalmente,(15, 625 + 7, 81) = 23, 4 horas.

De acordo com a Figura 6, observa-se que a Situacao 2 aumenta o tempo de vidada rede. No caso da Situacao 1, a execucao simultanea dos nodos atinge um tempo de1202 min (20, 03 horas). Nesta situacao, o grafico mostra as execucoes sobrepostas dosdois nodos, uma vez que as cargas das baterias no inıcio da simulacao sao iguais e aexecucao nao conta com sleep modes. Ja na Situacao 2, quando a execucao adota o reve-zamento na coleta de dados, a simulacao atinge um tempo de 1662, 76min (27, 71 horas).Isso significa um aumento de 38, 33% no tempo de vida da rede. O grafico dessa situacaomostra que, enquanto um nodo esta executando, o outro esta em sleep mode, recuperandocapacidade em sua bateria no perıodo disponıvel.

Como visto nos resultados simulados, adotar um sequenciamento (escalonamentode tarefas) inapropriado (sem utilizar o sleep mode, por exemplo) pode drenar a bateriade forma mais rapida. Assim, na medida do possıvel, deve-se incorporar perıodos oci-osos entre as tarefas. Isso permite que a bateria recomponha parte de sua capacidade,garantindo maior tempo de vida para o nodo.

5. ConclusaoO consumo energetico dos nodos de uma RSSF e um dos problemas mais pesquisados, de-vido a necessidade de se manter esse tipo de rede “viva” o maior tempo possıvel. Atraves


66

da busca por metodos eficientes de economia de energia nos nodos e possıvel estender otempo de vida de suas baterias, aumentando o perıodo ativo da rede como um todo. Prevero perıodo que ainda resta para um nodo se manter ativo, dependendo da carga de correnteaplicada em qualquer momento, facilita o emprego de tecnicas de escalonamento de sono,as quais estendem o tempo de vida da rede, atraves do Efeito Recuperacao.

O Cenario 4 mostra um caso simples, com apenas dois nodos. Porem, e possıvelgeneralizar esse cenario para representar uma RSSF contendo n nodos, sendo que apenasuma fracao desses nodos precisam estar ativos simultaneamente para monitorar o ambi-ente. Neste caso, poder-se-ia escolher os nodos que tenham maior capacidade em suasbaterias para realizar as leituras nos sensores e enviar tais dados para a estacao base. En-quanto isso, os outros nodos poderiam recuperar parte da capacidade em suas respectivasbaterias. Com isso, acredita-se que o Efeito Recuperacao faria grande diferenca no tempode vida da rede.

Como trabalhos futuros, novas simulacoes podem ser realizadas, incluindo maisnodos. Pretende-se integrar a presente modelagem em um ambiente voltado parasimulacao de RSSF, como o OMNeT++ [OMNet++ Community 2014]. Esta ferramentaconta com um modelo simples de bateria (linear), nao representando de forma apropriadaos efeitos discutidos neste trabalho.

Agradecimentos: Os autores agradecem a CAPES e FCT pelo apoio a este trabalho.

Referencias

Akyildiz, I. F., Su, W., Sankarasubramaniam, Y., and Cayirci, E. (2002). Wireless SensorNetworks: A Survey. Computer Networks, 38(4):393–422.

Aqeel-ur-Rehman, Abbasi, A. Z., Islam, N., and Shaikh, Z. A. (2011). A Review ofWireless Sensors and Networks’ Applications in Agriculture. CS&I.

Buratti, C., Conti, A., Dardari, D., and Verdone, R. (2009). An overview on wirelesssensor 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 Elec-tronics, 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 Perfor-mance Engineering Workshop, pages 76–88.

Jurdak, R. (2010). Radio sleep mode optimization in wireless sensor networks. MobileComputing, 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 Confe-rence on Sensor Technologies and Applications (SENSORCOMM), pages 525–530.

Lahiri, K., Raghunathan, A., Dey, S., and Panigrahi, D. (2002). Battery-Driven SystemDesign: A New Frontier in Low Power Design. 15th International Conference on VLSIDesign (VLSID’02), pages 261–267.

Li, H., Yi, C., and Li, Y. (2013). Battery-Friendly Packet Transmission Algorithms forWireless Sensor Networks. IEEE Sensors Journal, 13(10):202–207.

Manwell, J. F. and McGowan, J. G. (1993). Lead Acid Battery Storage Model for HybridEnergy Systems. Solar Energy, 50(5):399–405.

Nguyen, H. A., Forster, A., Puccinelli, D., and Giordano, S. (2011). Sensor Node Life-time: An Experimental Study. IEEE International Conference on Pervasive Compu-ting 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 Conferenceon VLSI Design, pages 57–63.

Rakhmatov, D. and Vrudhula, S. (2011). An Analytical High-Level Battery Model forUse in Energy Management of Portable Electronic Systems. IEEE-ACM InternationalConference on Computer Aided Design (ICCAD), pages 488–493.

Rakhmatov, D., Vrudhula, S., and Chakrabarti, C. (2002). Battery-Conscious Task Se-quencing for Portable Devices Including Voltage/Clock Scaling. 39th Design Automa-tion Conference, pages 189–194.

Rao, V., Singhal, G., Kumar, A., and Navet, N. (2005). Battery Model for Embedded Sys-tems. 18th Internation Conference on VLSI Design held jointly with 4th InternationaConference on Embedded Systems Designs (VLSID), pages 105–110.

Schneider, K. K., Sausen, P. S., and Sausen, A. (2001). Analise Comparativa do Tempo deVida de Baterias em Dispositivos Moveis a Partir da Utilizacao de Modelos Analıticos.Tendencias em Matematica 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

1Laborató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 cliente-servidor. 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 à implemen-taçã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 adapta-dores 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.

Tabela 1. Planejamento fatorial do experimento (23).

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. Destaca-se 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, disponível em:http://developer. android.com/guide/topics/connectivity/wifip2p.html 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


85

Í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

Documents

II Workshop de Comunicação em Sistemas Embarcados Críticos … · de Computadores e Sistemas Distribuídos (SBRC 2014) apresenta mais uma série de workshops, visando a discussão