Anais WoCCES SBRC 2014 - Universidade Federal de Santa
Transcrição
Anais WoCCES SBRC 2014 - Universidade Federal de Santa
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 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: Sociedade Brasileira de Computação (SBC) Av. Bento Gonçalves, 9500- Setor 4 - Prédio 43.412 - Sala 219 Bairro Agronomia - CEP 91.509-900 -Porto Alegre- RS Fone: (51) 3308-6835 E-mail: [email protected] Workshop de Comunicação em Sistemas Embarcados Críticos (2: 2014: Florianópolis, SC) Anais / II Workshop de Comunicação em Sistemas Embarcados Críticos; organizado por Adriano Mauro Cansian... [et al.] - Porto Alegre: SBC, c2014 96 p. WoCCES 2014 Realização: Universidade Federal de Santa Catarina ISSN: 2177-496X 1. Redes de Computadores - Congressos. 2. Sistemas Distribuídos- Congressos. I. Cansian, Adriano Mauro. II. Sociedade Brasileira de Computação. III. Título. i Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Promoção Sociedade Brasileira de Computação (SBC) Diretoria Presidente Paulo Roberto Freire Cunha (UFPE) Vice-Presidente Lisandro Zambenedetti Granville (UFRGS) Diretora Administrativa Renata de Matos Galante (UFRGS) Diretor de Finanças Carlos André Guimarães Ferraz (UFPE) Diretor de Eventos e Comissões Especiais Altigran Soares da Silva (UFAM) Diretora de Educação Mirella Moura Moro (UFMG) Diretor de Publicações José Viterbo Filho (UFF) Diretora de Planejamento e Programas Especiais Claudia Lage Rebello da Motta (UFRJ) Diretor de Secretarias Regionais Marcelo Duduchi Feitosa (CEETEPS) Diretor de Divulgação e Marketing Edson Norberto Caceres (UFMS) Diretor de Relações Profissionais Roberto da Silva Bigonha (UFMG) Diretor de Competições Científicas Ricardo de Oliveira Anido (UNICAMP) Diretor de Cooperação com Sociedades Científicas Raimundo José de Araujo Macêdo (UFBA) Diretor de Articulação de Empresas Avelino Francisco Zorzo (PUC-RS) ii Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Promoção Sociedade Brasileira de Computação (SBC) Conselho Mandato 2013-2017 Alfredo Goldman (IME/USP) José Palazzo Moreira de Oliveira (UFRGS) Maria Cristina Ferreira de Oliveira (ICMC/USP) Thais Vasconcelos Batista (UFRN) Wagner Meira Junior (UFMG) Mandato 2011-2015 Ariadne Carvalho (UNICAMP) Carlos Eduardo Ferreira (IME - USP) Jose Carlos Maldonado (ICMC - USP) Luiz Fernando Gomes Soares (PUC-Rio) Marcelo Walter (UFRGS) Suplentes - 2013-2015 Alessandro Fabrício Garcia (PUC-Rio) Aline Maria Santos Andrade (UFBA) Daltro José Nunes (UFRGS) Karin Koogan Breitman (PUC-Rio) Rodolfo Jardim de Azevedo (UNICAMP-IC) iii Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Promoção Laboratório Nacional de Redes de Computadores (LARC) Diretoria 2012-2014 Diretor do Conselho Técnico-Científico Elias P. Duarte Jr. (UFPR) Diretor Executivo Luciano Paschoal Gaspary (UFRGS) Vice-Diretora do Conselho Técnico-Científico Rossana Maria de C. Andrade (UFC) Vice-Diretor Executivo Paulo André da Silva Gonçalves (UFPE) Membros Institucionais SESU/MEC, INPE/MCT, UFRGS, UFMG, UFPE, UFCG (ex-UFPB Campus Campina Grande), UFRJ, USP, PUC-Rio, UNICAMP, LNCC, IME, UFSC, UTFPR, UFC, UFF, UFSCar, CEFET-CE, UFRN, UFES, UFBA, UNIFACS, UECE, UFPR, UFPA, UFAM, UFABC, PUCPR, UFMS, UnB, PUC-RS, UNIRIO, UFS e UFU. iv Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Carlos André Guimarães Ferraz (UFPE) v Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Realização Organização Local Carlos Barros Montez (UFSC) Edison Tadeu Lopes Melo (UFSC) Guilherme Eliseu Rhoden (PoP-SC) Leandro Becker (UFSC) Mário A. R. Dantas (UFSC) Michelle Wangham (Univali) Ricardo Felipe Custódio (UFSC) Roberto Willrich (UFSC) Rodrigo Pescador (PoP-SC) Rômulo Silva de Oliveira (UFSC) Secretaria do SBRC 2014 Juliana Clasen (UFSC) Jade Zart (UFSC) vi Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Mensagem do Coordenador de Workshops do SBRC 2014 Confirmando a consolidação nos últimos anos, este ano o Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC 2014) apresenta mais uma série de workshops, visando a discussão de temas novos e/ou específicos, como Internet do Futuro e Tolerância a Falhas. Os workshops envolvem comunidades focadas e oferecem oportunidades para discussões mais profundas e ampliação de conhecimentos, envolvendo pesquisadores e muitos estudantes em fase de desenvolvimento de seus trabalhos em andamento. Neste ano tivemos novas submissões, além dos workshops já considerados tradicionais parceiros do SBRC, o que representa o dinamismo da comunidade de Redes de Computadores e Sistemas Distribuídos no Brasil. Infelizmente, estas novas submissões não puderam ainda ser acomodadas, mas certamente serão consideradas para próximas edições do SBRC. Neste SBRC 2014, temos a realização de workshops já consolidados no circuito nacional de divulgação científica nas várias subáreas de Redes de Computadores e Sistemas Distribuídos, como o WGRS (Workshop de Gerência e Operação de Redes e Serviços), o WTF (Workshop de Testes e Tolerância a Falhas), o WCGA (Workshop de Computação em Clouds e Aplicações), o WP2P+ (Workshop de Redes P2P, Dinâmicas, Sociais e Orientadas a Conteúdo), o WRA (Workshop de Redes de Acesso em Banda Larga), o WoCCES (Workshop of Communication in Critical Embedded Systems), o WoSiDA (Workshop on Autonomic Distributed Systems) e o WPEIF (Workshop de Pesquisa Experimental da Internet do Futuro). Há que se mencionar a importante parceria com o WRNP (Workshop da Rede Nacional de Ensino e Pesquisa), que em sua 15a edição, cumpre o importante papel de fazer a ponte entre as comunidades técnica e científica da área. Não tenho dúvida que a qualidade técnica e científica dos workshops se manterá em alta compatível com o SBRC. Agradeço aos Coordenadores Gerais, Joni da Silva Fraga e Frank Siqueira (UFSC), pelo convite para coordenar os workshops do SBRC 2014 e por todo o apoio recebido. Desejo muito sucesso e excelente participação nos Workshops do SBRC 2014! Carlos André Guimarães Ferraz( UFPE) Coordenador de Workshops do SBRC 2014 vii Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Mensagem dos Coordenadores do WoCCES O II Workshop of Communication in Critical Embedded Systems (WoCCES) em conjunto com o 32º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC 2013), em Florianópolis, SC, tem por objetivo atuar como um fórum para apresentações técnicas de pesquisas em andamento e atividades relevantes nas áreas de comunicação em sistemas embarcados críticos, congregando pesquisadores e profissionais que atuam ativamente nessas áreas. O workshop também procura estabelecer redes colaborativas multi-institucionais e grupos de competência técnicocientífica, bem como fortalecer atividades em andamento. Sendo assim, o workshop se concentra em importantes inovações e avanços recentes na especificação, projeto, construção e utilização da comunicação em sistemas embarcados críticos, sendo que o objetivo do mesmo é o de reunir pesquisadores e profissionais da indústria e da academia e proporcionar-lhes uma oportunidade para se informar sobre os últimos desenvolvimentos, implantações, tendências tecnológicas e resultados de pesquisa, bem como iniciativas relacionadas com sistemas embarcados e suas aplicações em uma variedade de ambientes industriais. Finalmente, a coordenação do workshop gostaria de agradecer a todos os autores e participantes pela apresentação dos trabalhos e contribuições de pesquisa em comunicação em sistemas embarcados e aplicações, agradecer a todos os revisores e membros dos comitês de programa e de organização pelo apoio na elaboração do programa do workshop e nas atividades, e adicionalmente agradecer os apoios da USP, UNESP e SBC. Adriano Mauro Cansian, co-coordenador e co-editor UNESP – São José do Rio Preto ACME! Computer Security Research Laboratory Alex Roschildt Pinto, co-coordenador e co-editor UNESP – São José do Rio Preto 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 UNESP – São José do Rio Preto Laboratório de Automação e Computação Evolutiva – LACE Kalinka R. L. J. C. Branco, co-coordenadora e co-editora Universidade de São Paulo – ICMC Laboratório de Sistemas Embarcados Críticos – LSEC Paulo H. M. Gurgel, co-coordenador e co-editor Universidade de São Paulo – ICMC Laboratório de Sistemas Embarcados Críticos – LSEC viii Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Comitê de Programa do WoCCES 2014 Adriano Mauro Cansian - IBILCE - UNESP São José do Rio Preto Alex Sandro Roschildt Pinto - IBILCE - UNESP São José do Rio Preto Carlos Barros Montez - Universidade Federal de Santa Catarina Célia Leiko Ogawa Kawabata - IFSP - Campus São Carlos Daniel Fernando Pigatto - ICMC-USP Denis Fernando Wolf - ICMC-USP Edson dos Santos Moreira - ICMC-USP Ellen Francine Barbosa - ICMC-USP Fábio Dacêncio Pereira - UNIVEM Fernando Santos Osório - ICMC-USP Gustavo Pessin - Vale Horácio Antonio Fernandes de Oliveira - UFAM Jacir Luiz Bordim - UNB João Cunha - Instituto Politécnico de Coimbra José Márcio Machado - IBILCE - UNESP São José do Rio Preto Kalinka Regina Lucas Jaquie Castelo Branco - ICMC-USP Luciana Martimiano - UEM Luiz Henrique Castelo Branco - IFSP - Campus Araraquara Marco Vieira - Universidade de Coimbra Marcos Fagundes Caetano - UNB Mario Antonio Ribeiro Dantas - UFSC Mário Meireles Teixeira - UFMA Paulo Portugal - Universidade do Porto Raimundo Barreto - UFAM ix Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Sumário Sessão Técnica 1 ........................................................................................................... 1 Uma Arquitetura para Fusão de Dados e Detecção de Outliers em Sensores de Baixo Custo de Redes de Sensores sem Fio Rafael Callegaro (UFSC), Carlos B. Montez, Alex R. Pinto e Ricardo Moraes... 3 Proposta de um Sistema Aberto de Controle em Hardware e Software para VANT Direcionado à Entrega Confiável de Cargas Luiz Carlos Querino Filho (FATEC) e Kalinka R. L. J. C. Branco...................... 17 Arquitetura experimental para automação e integração de ambientes inteligentes com dispositivos móveis Vandermi J. Silva (UFAM), Gustavo L. P. Silva, e Vicente F. de Lucena Jr. ..... 24 Sessão Técnica 2 ........................................................................................................... 39 Modelo de Arquitetura em Camadas para Interconexão de Sistemas em VANT Emerson A. Marconato (USP) e Kalinka R. L. J. C. Branco................................ 41 Escalonamento de Sono e Efeito Recuperação em Baterias de Nodos em Redes de Sensores sem Fio Leonardo M. Rodrigues (UFSC), Carlos B. Montez, Paulo Portugal e Francisco Vasques................................................................................................. 55 Position Paper................................................................................................................ 69 Uma Rede de Compartilhamento de Conteúdo Multimídia em Dispositivos Móveis Baseados na Plataforma Android Felipe Alexandre O. Machado (UFMA), Adriano V. Pinto e Mário M. Teixeira................................................................................................. 71 Índice por Autor............................................................................................................ 85 x 32º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Florianópolis - SC II Workshop de Comunicação em Sistemas Embarcados Críticos (WoCCES 2014) Sessão Técnica 1 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Uma Arquitetura para Fusão de Dados e Detecção de Outliers em Sensores de Baixo Custo de Redes de Sensores sem Fio Rafael Callegaro1 , Carlos Montez1 , Alex R. Pinto3 , Ricardo Moraes12 1 Pós-Graduação em Eng. de Automação e Sistemas – PGEAS 2 Laboratório de Segurança em Computação - LabSEC 3 Campus Blumenau UFSC – Universidade Federal de Santa Catarina {rafael.callegaro, carlos.montez, arpinto, ricardo.moraes}@ufsc.br Resumo. As aplicações nas áreas de Agricultura de Precisão, Engenharia Ambiental, frequentemente, utilizam sensores para o monitoramento de ambientes, como por exemplo, no controle de pragas, no processo de irrigação, na determinação de mapas de solo e produtividade, no acompanhamento de áreas florestais e de rios urbanos, etc. As Redes de Sensores sem Fio (RSSF) vêm sendo propostas como infraestruturas para essas aplicações. Essas redes produzem um grande volume de dados e utilizam sensores de baixo custo e com baixa confiabilidade, gerando dados anômalos (outliers) e afetando a qualidade final do monitoramento. Essas condições implicam na necessidade de utilização de métodos de fusão de informações que viabilizem o funcionamento da rede e aumente a confiança nos dados monitorados. Este artigo propõe uma arquitetura para a fusão de informação voltada para sensores de baixa confiabilidade. A arquitetura foi avaliada através de um estudo de caso envolvendo sensores de pressão atmosférica de baixo custo, compatı́veis com a plataforma Arduino, cujos dados monitorados foram tratados por técnicas de fusão de informação. Os resultados obtidos mostram que alguns dos métodos de fusão de baixo nı́vel e técnicas para detecção de outliers, quando combinados e organizados segundo a arquitetura proposta, conseguem substituir um único sensor centralizado e de alto custo, mantendo a confiabilidade obtida nos dados monitorados. 1. Introdução Uma Rede de Sensores Sem Fio (RSSF) consiste em uma rede composta por nodos de baixo custo, com pequenas dimensões e com alguma capacidade de processamento e transmissão. Desta forma os nodos têm capacidades que vão além da simples coleta de informação, eles têm funcionalidades que permitem analisar e fundir seus próprios dados ou dados de outros nós sensores, sendo ainda equipados com algum tipo de sensor com capacidade de monitoramento de grandezas fı́sicas. Além disso, normalmente os nodos não se comunicam somente entre si, mas também com uma estação base, a fim de que os dados possam ser divulgados, processados, analisados ou armazenados [Dargie and Poellabauer 2010]. As aplicações variam desde os ambientes industriais, hospitalares, domótica, monitoramento urbano e de áreas rurais até os ambientes militares [Akyildiz et al. 2002]. 3 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 As RSSF começam a ser amplamente utilizadas nos processos de automatização de monitoramento de diversas grandezas fı́sicas. Estas redes substituem as tradicionais aplicações de monitoramento que assumem a abordagem centralizada, onde há um sensor único monitorando cada grandeza observada. Este sensor, por ser único, necessita ser de alta confiabilidade, robusto e, consequentemente, de alto custo. As obras de instalação para garantir a confiabilidade das medições também costumam ter um alto custo associado. Essa abordagem centralizada também implica em manutenção dispendiosa, pois, via de regra, o armazenamento dos dados é feito em dataloggers, que são dispositivos dedicados para armazenar localmente dados coletados pelos sensores. O alto custo de manutenção também é um problema, pois, muitas vezes há o requisito que estes sensores sejam implantados em locais inóspitos e de difı́cil acesso, inviabilizando a substituição constante de suas baterias e dificultando o acesso aos dataloggers. Consequentemente, diversas aplicações que empregam uma infraestrutura de RSSF, como por exemplo as de monitoramento ambiental, vêm deixando de ocupar, exclusivamente, a atenção da academia e gradualmente está sendo adotada por empresas, substituindo as soluções tradicionais [Elmenreich 2007]. Essa ampliação de uso dá-se pelas vantagens que as RSSF trazem, no que diz respeito à flexibilidade na implantação da rede, maior cobertura espacial, custo dos sensores etc. No entanto, essa adoção só não é maior porque ainda existem diversos desafios que precisam ser superados, a destacar: (i) há uma geração de grande quantidade de dados, (ii) o consumo energético dos nodos precisa ser reduzido e (iii) há dificuldades na detecção de dados anômalos (outliers) e tolerância à falhas. Este trabalho foca nos problemas (i) e (iii), tratando-os sob o viés dos métodos da fusão da informação, ou seja, técnicas que lidam com grande quantidade de dados, que podem reduzir o consumo energético, além de serem capazes de aumentar a confiabilidade nos dados monitorados pela rede, a partir de manipulação matemática no conjunto de dados monitorados. Mais especificamente, este trabalho propõe que esses problemas sejam tratados de forma sistemática, através de uma arquitetura de fusão de informações, que organiza o fluxo de dados e as diversas atividades necessárias para integração dos diferentes tipos de fusão. A principal questão que motiva este trabalho reside em saber se um conjunto de sensores de baixo custo consegue substituir os tradicionais sensores centralizados e de alto custo, mantendo, ou mesmo superando, a confiabilidade obtida nos dados monitorados. No desenvolvimento deste trabalho foi realizada uma pesquisa bibliográfica com o objetivo de encontrar e avaliar uma arquitetura de comunicação adequada para este processo. Os aspectos relevantes sobre fusão da informação, no contexto deste trabalho, são apresentados na seção 2. Porém, como não foi encontrada uma arquitetura a ser aplicada diretamente no processo de monitoramento ambiental, propõe-se uma arquitetura para a fusão de dados de sensores de baixo custo em RSSF (seção 3). Posteriormente, na seção 4, descreve-se um estudo de caso, que utiliza sensores barométricos de baixo custo e compatı́veis com a plataforma Arduino, que avalia a arquitetura. Por fim, algumas considerações finais e trabalhos futuros são apresentados. 2. Fusão da Informação - Aspectos relevantes O termo fusão da informação é amplamente utilizado na literatura. Para [Elmenreich 2007] a fusão da informação é um termo abrangente que cobre todos os as- 4 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 pectos do campo de fusão (exceto fusão nuclear ou fusão no mundo da música). É definida por (Henrik Boström 2013) como o estudo de métodos eficientes para automaticamente ou semi-automaticamente transformar informações de diferentes fontes e diferentes pontos no tempo em uma representação que fornece apoio efetivo para tomada de decisão humana ou automatizada. A fusão de dados comumente faz referência a métodos de fusão de dados brutos ou de sinal muito utilizado na fusão de sensores. Já o termo agregação de dados, comum em RSSF, consiste em um subconjunto da fusão da informação e trata basicamente de técnicas de transferência de dados [Kulik et al. 2002]. As vantagens de se realizar o sensoriamento utilizando vários sensores ao invés de um único sensor está no aumento da disponibilidade, cobertura espacial, cobertura temporal e exatidão, podendo ainda diminuir a ambiguidade das observações e possibilitar auto-ajustes. No entanto, caso as entradas de informações sejam de má qualidade ou existirem muitas falhas de forma que a quantidade de dados incorretos superem os corretos, o desempenho global do sistema poderá ser afetado [Nakamura et al. 2007]. Quando se utiliza uma RSSF, como insfraestrutura no processo de monitoramento de grandezas fı́sicas, é comum o uso de uma grande quantidade de nodos com sensores de baixo custo. Basicamente os métodos de fusão podem utilizar a capacidade de processamento dos nodos para explorar a correlação espaço temporal das informações observadas diretamente pelos sensores para reduzir a quantidade de dados trafegados. Além disso, podem ser utilizados para e detectar/corrigir dados discordantes (outliers) e falhas [Zhou et al. 2011]. As falhas e erros são fontes de outliers ou dados discordantes, ou seja, os outliers são dados atı́picos em uma aplicação de monitoramento, e podem ter origens de ataques maliciosos, eventos, falhas e erros. Os ataques maliciosos acontecem por exemplo quando o atacante consegue obter vantagens ao manipular os dados dos sensores, como nas aplicações militares e são tratados com técnicas de tolerância a intrusão [Fawzy et al. 2013]. 2.1. Classificação da Fusão de Informações [Dasarathy 1997] dividiu a fusão de informações segundo o nı́vel de abstração dos dados. Na fusão de baixo nı́vel os dados brutos são fornecidos como entradas, combinadas diretamente em novos dados que são melhores que as entradas individuais e que podem ser utilizados com os demais nı́veis de fusão. A nı́vel médio ou de caracterı́sticas, acontece a abstração dos dados de forma que seja possı́vel representar um objeto de forma precisa e concisa. Na fusão de alto nı́vel ou de decisão, acontece a tomada de decisão baseada nas informações provenientes das camadas de nı́veis baixo e médio, onde podem ser incorporados conhecimentos a priori e informações especı́ficas sobre a tomada de decisão. [Durrant-Whyte 1988] distingue a fusão baseada na configuração dos sensores. Na configuração complementar, os sensores não dependem diretamente um do outro, mas se complementam para obter uma imagem mais completa do fenômeno observado. Na configuração redundante, são fornecidas medições independentes da mesma propriedade em instantes diferentes ou por duas ou mais origens no mesmo instante a fim de proporcionar melhor precisão e/ou exatidão das observações. Na configuração cooperativa, as informações são fornecidas por mais de um sensor para derivar informações que não estariam disponı́veis se fosse utilizado apenas um. Normalmente, neste tipo de fusão há 5 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 perda de precisão e confiabilidade. 2.2. Modelos Os modelos de fusão de informações na maioria das vezes descrevem um conjunto de processos e como estes se relacionam, abstraindo-se de implementações ou instâncias especı́ficas. Muitos modelos foram propostos para auxiliar no projeto de sistemas de fusão de informações. Os mais comuns são: JDL Process Model [Steinberg 1999], DFD Model [Dasarathy 1997] e Waterfall Model [Harris et al. 1998]. Estes modelos fornecem um esquema teórico e podem ser usados para facilitar a compreensão dos requisitos e limitações introduzidas por métodos de fusão, mostram como os dados se relacionam e especificam tarefas. Na maioria dos casos, a classificação da fusão é baseada em nı́veis e os modelos são genéricos, com exceção ao JDL que é aplicável diretamente na área militar. Embora tais modelos não considerem os aspectos de rede (natureza distribuı́da) das RSSF, eles funcionam como um guia para especificar quais métodos podem ser usados e como eles podem ser integrados em uma arquitetura. 3. Arquitetura para Fusão de Dados de Sensores de Baixo Custo Neste artigo propõe-se uma arquitetura para aplicações de monitoramento com RSSF e divide as atividades executadas em três camadas: Camada de Fusão Local, Camada de Fusão de Baixo Nı́vel e Camada de Gerenciamento e Interface com Usuário (Fig. 1). Figura 1. Arquitetura proposta para fusão de dados de sensores em RSSF. A principal contribuição deste artigo está na definição e avaliação da Camada de Fusão de Baixo nı́vel, que é responsável pelo recebimento dos dados provenientes da RSSF, processamento e encaminhamento à Camada de Gerenciamento e Interface com usuário, a qual é responsável por executar tarefas correspondentes à fusão de médio e de alto nı́veis (conforme classificação apresentada em [Dasarathy 1997]). Essas tarefas - que costumam envolver interações com usuários e acessos a bases de dados - são usualmente empregadas nas tomadas de decisão e são dependentes de cada aplicação e, portanto, estão 6 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 fora do escopo deste artigo. Apresenta-se também neste artigo as técnicas comumente empregadas na Camada de Fusão Local. 3.1. Camada de Fusão Local O objetivo deste nı́vel de processamento é configurar os sensores para coletar dados sobre o ambiente onde o mesmo está inserido, realizar algum tipo de fusão local e encaminhar os dados para transmissão. Um dos primeiros passos é verificar junto ao fabricante do sensor quais são as taxas de amostragens recomendadas. Também é necessário conferir se existe algum tipo de ajuste a ser realizado no sensor, como por exemplo, a microcalibração. Dependendo da taxa de amostragem adotada, pode-se aplicar localmente aos dados algum tipo de fusão, como por exemplo, a média aritmética. Alguns métodos de fusão das camadas superiores da arquitetura podem utilizar outras informações no seu processamento, tais como a variância ou desvio padrão, gerados pela fusão local. Para o cálculo desses valores, uma boa opção é realizar a fusão no intervalo entre beacons1 , como exemplificado na Figura 2, onde os nodos sensores realizam os cálculos de média aritmética e/ou variância a cada 30 ou 60 segundos (intervalo entre os seus respectivos beacons). Figura 2. Fusão local dos dados. 3.2. A Camada de Fusão de Baixo Nı́vel A Camada de Fusão de Baixo Nı́vel foi subdividida em: calibração; timestamping; detecção de erros grosseiros e sistemáticos; métodos de fusão e realimentação (Fig. 1). 3.2.1. Calibração A calibração de sensores é um problema fundamental em RSSF [Tan et al. 2013]. Ela consiste no conjunto de operações que estabelece e corrige a diferença existente entre um valor medido e o verdadeiro valor. Em alguns casos, pode consistir de uma correção aditiva ou multiplicativa da indicação com uma incerteza de medição associada. Como ignora-se o verdadeiro valor, a calibração tende a minimizar a diferença entre o valor lido e o verdadeiro valor da grandeza. 1 Os beacons são sinalizadores, que também podem ser definidos como pacotes de controle, gerados periodicamente pelo coordenador para sincronizar a rede além de delimitar e descrever a estrutura do superframe das redes IEEE 802.15.4. 7 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 A calibração de cada dispositivo, individualmente e manualmente, conhecida como micro-calibração pode ser intratável quando a rede possuir um grande número de sensores [Tan et al. 2013]. Logo, a autocalibração ou calibração autodidata podem ser empregadas neste processo. Um método convencional de auto calibração é a correção de leituras de cada sensor para um referencial comum baseado em um sensor de referência que se tenha confiança, ou baseado na referência de um grupo de sensores [Bychkovskiy et al. 2003]. 3.2.2. Timestamping Na arquitetura proposta, a fusão de baixo nı́vel pode ocorrer de forma on-line ou off-line. No caso da fusão off-line, os coordenadores PAN não cumprem o papel de Centros de Fusão, apenas encaminham os dados recebidos na direção do coordenador PAN Principal, onde a fusão será executada. A fusão off-line pode ser utilizada para um estudo posterior aprofundado do ambiente observado. Neste caso, é necessário associar marcações de tempo referentes ao momento da observação em cada dado armazenado. Os Centros de Fusão desempenham importante papel na Camada de Fusão de Baixo Nı́vel quando ocorre a fusão on-line, sendo primordial em redes de sensores que também possuam atuadores, para que seus resultados sejam utilizados imediatamente. 3.2.3. Detecção de erros grosseiros e sistemáticos A detecção e eliminação de erros grosseiros é uma tarefa simples, porém, necessária no processo de monitoraramento com RSSF, principalmente quando se admite o uso de sensores de baixo custo. A detecção pode ser baseada, por exemplo, na simples inspeção da faixa de operação dos sensores, ou seja, os dados obtidos e que se encontram fora da faixa operacional de um sensor devem ser descartados. Erros sistemáticos são mais difı́ceis de serem detectados. Correções básicas podem ser efetuadas já na implantação (deployment) do sensor, quando estas influenciam no valor final. As demais correções podem ser feitas baseando-se, por exemplo, em um sensor de referência, no qual já se tenha confiança; ou baseando-se em um grupo de sensores, nos quais, coletivamente, acredita-se que seus valores médios sejam confiáveis. 3.2.4. Métodos de Fusão Neste nı́vel os dados dos sensores são comparados, a fim de detectar possı́veis sensores discordantes. Diversos algoritmos podem ser utilizados. Nesta arquitetura, considera-se um algoritmo apropriado aquele com a capacidade de comparar os dados obtidos pelos sensores envolvidos na fusão e seguindo um critério realizar ou não a supressão dos seus dados. A eliminação das observações de sensores, mesmo quando estes realizam leituras corretas tende a descartar observações desnecessariamente, o que não é desejável. Ainda, é conveniente que quando uma observação for descartada, de alguma forma o algoritmo tenha capacidade de marcar ou mostrar de forma clara qual sensor e qual o motivo que levou o dado a ser rejeitado. Igualmente, devido a dúvida sobre a qualidade dos sensores 8 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 de baixo custo, é desejável que o algoritmo tenha mecanismos capazes de computar a qualidade do sensor durante o processo de fusão. Um método muito utilizado para a fusão de dados é a média aritmética, que não é adequada para a grande maioria das aplicações. Nas subseções abaixo descrevem-se as principais caracterı́sticas dos métodos avaliados neste artigo. É importante destacar que há diversas outras técnicas que poderiam ser avaliadas, como por exemplo as técnicas baseadas em Filtro de Kalman [Nakamura et al. 2007]. No entanto, essas abordagens são statefull, pois necessitam do histórico das mensagens anteriores de cada sensor e os métodos estudados neste trabalho são stateless. A. Média Tolerante a Falhas Um dos métodos de fusão de sensores com simples aplicação, e bons resultados é a média tolerante a falhas (MTF) proposto por [Marzullo 1990]. Basicamente o método divide um conjunto ordenado de dados em três partes, eliminando as extremidades. O primeiro passo desta técnica é ordenar o conjunto de dados enviados pelos nodos sensores. Tomando t=N/3, onde N é o tamanho do conjunto, descartam-se os extremos da amostra ordenada, ou seja as t maiores e as t menores medidas. O valor final é o cálculo da média e desvio padrão dos valores restantes. B. Confidence-weighted Averaging - CWA [Elmenreich 2007] propôs um método de fusão relacionando a confiança nos sensores pelo inverso da respectiva variância. A variância é uma medida útil em muitos casos porque são aditivas, podendo-se comparar diferentes grupos de dados. O desvio-padrão, por sua vez, tem a vantagem de ser expresso na mesma unidade que a variável medida, tornando mais fácil de comparar resultados. Para [Elmenreich 2007], no melhor caso a variância é próxima de zero, tendo assim a máxima confiança e no pior caso o sensor gera valores aleatórios dentro da sua faixa de operação. A variância de pior caso pode ser calculada como a variação de uma função aleatória uniformemente distribuı́da entre os limites a e b, onde a e b são os valores mı́nimos e máximos de uma função aleatória, uniformemente distribuı́da. C. CWA + MTF O CWA pode ser utilizado juntamente com outros métodos, como por exemplo a MTF proposta por [Marzullo 1990], o que foi proposto por Elmenreich [Elmenreich 2007]. Assim o método se torna tolerante a falhas e considera a qualidade do sensor na fusão. O método consiste em calcular a média ponderada incluindo todos os sensores através do método CWA e, posteriormente, elimina-se 2/3 dos sensores conforme especificado no MTF e calcula-se novamente a média ponderada. D. CWA com alterações O método proposto em [Elmenreich 2007] para fundir informações de sensores diferentes, prioriza os sensores com menor variância. Uma exceção apontada pelo próprio autor do algoritmo é que, caso a variância seja zero, passa a ser necessário algum tratamento especial para evitar a divisão por zero. Contudo, em experimentos preliminares efetuados neste trabalho observou-se um outro problema, pois, como a arquitetura proposta é voltada para RSSFs que utilizam sensores de baixo custo. Foi observado em alguns 9 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 cenários de execução, que leituras de dados coletados por um único sensor podiam apresentar valores iguais por um longo perı́odo de tempo, caracterizando um sensor defeituoso e “travado”. Esse travamento do sensor poderia ser definitivo ou temporário, por um curto ou longo tempo. Esse sensor “travado”, pela sua baixa variância, fazia com que seus dados incorretos contribuı́ssem com um maior peso no cálculo da média ponderada do que os sensores corretos. Assim foi necessária uma alteração simples do algoritmo original na implementação realizada. Basicamente, quando um sensor apresentar variações entre leituras abaixo de um valor estipulado (e dependente do tipo e da especificação do sensor), sua variância calculada será artificialmente aumentada para o máximo valor possı́vel, contribuindo assim minimamente para o cálculo da média ponderada. E. Critério de Chauvenet O critério de Chauvenet é um método estatı́stico que foi desenvolvido para a detecção de outliers, podendo ser utilizado para detecção de falhas bizantinas. Ele baseia-se na hipótese de que uma medição arbitrária pode ser rejeitada se a probabilidade de obter o desvio da média para este valor é menor do que o inverso do dobro do número de medições [Taylor 2012]. O tamanho da amostra é muito importante na utilização do método, pois com uma amostra grande, há poucas chances de que um dos valores afetem a média de forma significativa. Um valor divergente em uma amostra grande deve estar muito longe da média para “mover” a distribuição. Isso faz com que a utilização de poucos dados tenha exigências mais rı́gidas. F. Método de Peirce O método de Pierce é uma técnica estatı́stica para detecção de outliers, em uma amostra com comportamento normal. O artigo original data de 1852, contudo é amplamente utilizado nos dias atuais. [Ross 2003] descreve o método de detecção de dados suspeitos proposto por Peirce como segue: “as observações devem ser rejeitadas quando os desvios reais da média obtidos por mantê-los, é menor do que os desvios obtidos por sua rejeição, multiplicada pela probabilidade de fazer tantos e não mais, observações anormais”. Explicando de outra forma, o objetivo de sua técnica era gerar probabilidades de erro que ocorrem no sistema onde todas as n observações são mantidas versus as k amostras rejeitadas. Ele então rejeita k observações e verifica se a amostra é mais próxima da normal que a anterior. O Critério de Peirce, prevê a detecção de mais de um dado discordante na amostra. O método de cálculo utilizado por Peirce é matematicamente complexo de usar. Desta forma Gould levou o método a ser apresentado em um formato mais facilmente empregável com tabelas derivadas do trabalho de Peirce [Gould 1855]. 3.2.5. Realimentação As realimentações são informações obtidas de banco de dados, do usuário e outras fontes, incluindo os métodos de fusão de dados brutos. Por exemplo, informações sobre o descarte dos dados de um sensor em especı́fico podem ser utilizadas para a calibração do respectivo sensor. 10 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 4. Avaliação Nesta seção avalia-se a arquitetura proposta através de um estudo de caso. Uma aplicação de monitoramento ambiental, que usa a pressão atmosférica (PA) como grandeza principal, é utilizada para ilustrar o uso da arquitetura. A PA é uma grandeza relevante para diversas áreas de aplicação, como a meteorologia, altimetria, engenharia sanitária e ambiental. Comumente para o sensoriamento da PA no monitoramento ambiental, emprega-se um único sensor barométrico de alta qualidade, confiável, com especificações rı́gidas no que tange à instalação e operação e, consequentemente, de alto custo. O local escolhido para a realização das medições foi nas proximidades do Aeroporto Hercı́lio Luz na cidade de Florianópolis, Santa Catarina. Na Figura 3 pode-se observar que foi utilizado um sensor de referência externo para questões comparativas (identificado neste trabalho como Vaisala), este sensor externo é operado pela aeronáutica e está localizado nas proximidades da cabeceira da Pista 14, a 5 metros de altitude com referência ao nı́vel do mar. A distância entre o sensor do aeroporto e o local dos experimentos é de 1300 metros. Ainda com a finalidade de comparar os dados obtidos com os sensores de baixo custo, utilizou-se um segundo sensor de referência preciso e de alto custo (identificado neste trabalho como sensor de referência interno Young). Figura 3. Local do experimento. A comunicação entre os sensores do experimento foi realizada através de uma RSSF IEEE 802.15.4 com topologia em estrela. Quatro sensores de baixo custo foram usados nos experimentos, o que satisfaz o critério mı́nimo de sensores exigido pelas técnicas de fusão apresentadas anteriormente. O quinto nodo foi configurado para atuar como nodo coordenador PAN/Centro de Fusão, sendo o computador responsável por armazenar os dados gerados. A rede foi configurada para ser utilizada em modo com beacon ativado, e este nodo, cumprindo seu papel de Coordenador PAN, é responsável por sincronizar a rede através do envio de beacons. Para configurar a periodicidade da aplicação foi utilizado o valor do Beacon Order (BO) = 11, o que define um Beacon Interval (BI) de aproximadamente 30 segundos. 11 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Os demais nodos foram equipados com sensores de baixo custo Bosch. O software de rede utilizado nos nodos foi implementado sobre a camada MAC. Assim não foram utilizados sistemas operacionais especı́ficos para RSSF, tais como o TinyOS ou FreeRTOS. A alimentação dos nodos de 1 a 4 equipados com sensores Bosch foi realizada por 2 baterias do tipo AA, sendo que os nodos também alimentavam os sensores Bosch. O nodo 5, equipado com o sensor Young, utilizou fonte de alimentação AC/DC. O nodo 5 foi interligado ao microcomputador utilizando comunicação serial com cabo USB e os dados coletados pelos nodos foram armazenados em arquivo texto, acrecidos dos timestamps no seguinte formato: < timestamp, nodo[1 − 10], variância [1 − 10] >. O microcomputador do experimento teve seu horário sincronizado através do protocolo NTP, assim como ocorre com o microcomputador do aeroporto. Optou-se por realizar a fusão a posteriori, pela existência de limitações de permanência no local do experimento e na obtenção dos dados on-line do sensor de referência externo. 4.1. Resultados Experimentais A primeira análise de dados realizada foi sobre os dados obtidos pelos sensores de referência interno (Young) e externo (Vaisala). O objetivo foi verificar se as leituras feitas pelo sensor de referência interno são coerentes com as do sensor de referência externo. Foram selecionados dados referentes a 24h de leituras e realizada uma média horária da pressão atmosférica (Figura 4). Para realizar o comparativo foi necessário corrigir os efeitos causados pela diferença de altitude de instalação dos dois sensores (cerca de 1,5 metros), que equivale a 0.18 hPa, subtraı́dos dos valores obtidos pelo sensor de referência externo. Além da altitude foi necessário se levar em consideração a exatidão dos sensores. Segundo os fabricantes, as leituras podem variar ± 0.3 hPa e, dessa forma, a discrepância entre os dois sensores não deve ultrapassar ± 0.6 hPa. Observou-se que a diferença máxima ficou em torno de ± 0.25 hPa. Logo, pode-se considerar que o sensor de referência interno Young está validado com relação ao sensor de referência externo Vaisala, o qual é periodicamente calibrado, pois seus valores são utilizados para as operações de decolagem e aterrizagem no aeroporto. Por conveniência, na continuidade deste trabalho, os dados referentes aos sensores de baixo custo (Bosch) e os resultados obtidos pela fusão de seus valores serão comparados somente com o sensor de referência interno (Young), doravante chamado apenas de sensor de referência. Diversas análises foram realizadas para avaliar as técnicas de fusão. Neste artigo apresenta-se a análise de uma amostra de dados que contém um sensor discordante (Figura 5). Observa-se que este sensor sempre envia a mesma leitura de pressão atmosférica, o que pode ser entendido como um sensor com alta precisão (variância zero). Porém, esta diferença em relação aos outros sensores aconteceu provavelmente pelo baixo nı́vel de bateria no nodo em que o sensor estava acoplado. Na Figura 5 observa-se que os valores do sensor Bosch4 permanecem distante dos demais, chegando a diferir 1.31 hPa da referência, enquanto os demais sensores diferem apenas 0.07 hPa. A Figura 6 apresenta os resultados dos métodos de fusão aplicados a estes dados. O método da aplicação da média aritmética obteve os piores resultados pois este inclui todos os dados no cálculo da fusão. Como nesta amostra há um sensor com leituras 12 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Figura 4. Comparação entre sensores de referência. discordantes, a média é deslocada e esta técnica não permite dizer qual sensor apresenta valores discordantes. Ao aplicar o método de Chauvenet, verifica-se que o mesmo não detecta o sensor 4 como discordante, obtendo os mesmos valores que a média aritmética. Interessante notar que se o sensor de referência fizesse parte do conjunto de sensores usados para o cálculo da fusão, o método de Chauvenet conseguiria um melhor desempenho, eliminando o sensor discordante e a realizando a média aritmética com os sensores restantes. O método de Peirce conseguiu detectar corretamente o sensor 4 como discordante. O máximo desvio entre o sensor de referência e o valor obtido na fusão foi de 0.03 hPa. Diferente dos métodos de Chauvenet e Peirce, a Média Tolerante a Falhas (MTF) sempre descarta os valores de dois terços dos sensores, mesmo estes tendo valores semelhantes. O método proposto por Elmenreich (CWA) é o mais completo, no sentido em que leva em consideração a qualidade do sensor. No entanto os dados de variância devem estar disponı́veis. Há três formas de executar o método: na primeira considera-se apenas a variância informada pelos sensores (CWA); na segunda são incluı́das as modificações propostas neste artigo (CWA com alterações) e, por fim, utilizando o algoritmo modificado em conjunto com a média tolerante a falhas (CWA + MTF). Pode-se observar nos resultados apresentados na Tabela 1 que o método proposto Figura 5. Amostra de dados com sensor discordante. 13 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Figura 6. Aplicação dos métodos de Fusão de dados. Rounds 1 2 3 4 5 6 7 8 9 10 Tabela 1. Método de Elmenreich. Referência CWA CWA+MTF CWA com alt. 1012,29 1013,37 1012,31 1012,30 1012,27 1013,38 1012,28 1012,26 1012,24 1013,35 1012,25 1012,23 1012,23 1013,36 1012,20 1012,23 1012,22 1013,36 1012,18 1012,20 1012,19 1013,38 1012,17 1012,18 1012,18 1013,39 1012,19 1012,17 1012,16 1013,36 1012,18 1012,18 1012,17 1013,37 1012,15 1012,16 1012,15 1013,35 1012,12 1012,15 por Elmenreich (CWA sem alterações) tem um desempenho ruim, obtendo a diferença máxima em torno de 1,2 hPa do sensor de referência. Este resultado evidencia que, caso um sensor tenha leituras sequenciais iguais, a variância obtida é zero e o sistema terá sua maior confiança no sensor discordante. Utilizando o método de CWA com alterações, assume-se que um sensor com variância constante, durante um determinado perı́odo, próxima de zero é defeituoso, fazendo com que sua variância seja elevada artificialmente a um valor máximo. Assim, apesar do sensor defeituoso participar da média ponderada, obtém-se um resultado mais aproximado do sensor de referência. A terceira forma aplicada é do método de CWA + MTF, o que também faz com que os dados se aproximem da referência. Na Tabela 2 pode-se observar o resultado da aplicação das técnicas MTF e o CWA+MTF na amostra de dados. Pode-se verificar que o sensor 2 participou de todas as médias, enquanto o sensor 4 foi corretamente desconsiderado em todas. Já o sensor 1, apesar de ter leituras próximas das corretas foi desconsiderado em 80% dos casos, presentes nesta amostra. Comparando os resultados obtidos pela MTF com o sensor de referência, encontra-se o valor máximo de 0.02 hPa. 5. Conclusões As RSSF utilizando sensores de baixo custo para o monitoramento de grandezas fı́sicas, vem substituindo a tradicional abordagem centralizada que utilizam um único sensor confiável de alto custo. Parte desta mudança está relacionada com as vantagens que a 14 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Tabela 2. MTF e CWA+MTF aplicados na amostra com sensor 4 discordante. Sensor Sensor #1 #2 #3 #4 #1 #2 #3 #4 1o round ◦ • • ◦ 1o round ◦ • • ◦ o 2 round ◦ • • ◦ 2o round ◦ • • ◦ 3o round ◦ • • ◦ 3o round ◦ • • ◦ 4o round ◦ • • ◦ 4o round • ◦ • ◦ 5o round ◦ • • ◦ 5o round • ◦ • ◦ 6o round • • ◦ ◦ 6o round • ◦ • ◦ 7o round ◦ • • ◦ 7o round ◦ • • ◦ 8o round ◦ • • ◦ 8o round ◦ • • ◦ 9o round ◦ • • ◦ 9o round • ◦ • ◦ 10o round • • ◦ ◦ 10o round • ◦ • ◦ (a) MTF (b) CWA com MTF Legenda: • Participa da fusão ◦ Não participa da fusão RSSF proporciona, como flexibilidade na implantação da rede, melhor cobertura espacial, custo dos sensores etc. No entanto surgem novos desafios na medida que tais redes começam a ser utilizadas na prática. Por exemplo, elas geram uma grande quantidade de dados, precisam ter funcionamento adequado à quantidade de energia fornecida, além de falhas e erros ocasionados por nodos de RSSF equipados com sensores de baixo custo. Assim a utilização de dados brutos, gerados pelos nodos sensores não tem sido adequada para as aplicações. Desta forma, este trabalho foca nesses problemas, tratando-os sob o viés dos métodos de fusão da informação, ou seja, técnicas que diminuem a quantidade de dados e aumentam sua confiabilidade. A arquitetura proposta foi aplicada no monitoramento de ambientes. Os sensores de baixo custo foram calibrados baseados em um sensor de referência, sem esta operação, os métodos de fusão não atingiriam o desempenho esperado devido ao desvio constante dos valores observados pelos sensores de baixo custo. Os timestamps foram adicionados, proporcionando que a fusão fosse realizada off-line. Os erros sistemáticos e grosseiros, como valores “zero” por exemplo, foram corretamente descartados antes de chegarem aos métodos de fusão. Dentre os métodos testados, Peirce e CWA + MTF se mostraram mais adequados para a fusão dos sensores. Já a média aritmética, Chauvenet e CWA sem modificações, não tiveram bom desempenho na presença de nodos falhos. De forma geral a configuração da RSSF utilizada, juntamente com sensores de baixo custo e a arquitetura proposta, teve desempenho superior do que quando utilizado um sensor único de alto custo. Acredita-se que futuros sistemas de monitoramento de ambientes utilizando RSSF e sensores de baixo custo, possam dispor deste trabalho como ferramenta, tanto no que se refere ao levantamento bibliográfico, no desempenho dos métodos testados, bem como utilizar ou basear sua aplicação na arquitetura proposta. Referências Akyildiz, I. F., Su, W., Sankarasubramaniam, Y., and Cayirci, E. (2002). Wireless sensor networks: A survey. Comput. Netw., 38(4):393–422. Bychkovskiy, V., Megerian, S., Estrin, D., and Potkonjak, M. (2003). A collaborative approach to in-place sensor calibration. pages 301–316. 15 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Dargie, W. and Poellabauer, C. (2010). Fundamentals of wireless sensor networks: theory and practice. John Wiley & Sons Ltda. Dasarathy, B. (1997). Sensor fusion potential exploitation-innovative architectures and illustrative applications. Proceedings of the IEEE, 85(1):24–38. Durrant-Whyte, H. F. (1988). Sensor models and multisensor integration. Int. J. Rob. Res., 7(6):97–113. Elmenreich, W. (2007). Fusion of continuous-valued sensor measurements using confidence-weighted averaging. Journal of Vibration and Control (incorporating Modal Analysis), 13(9-10):1303–1312. Fawzy, A., Mokhtar, H. M., and Hegazy, O. (2013). Outliers detection and classification in wireless sensor networks. Egyptian Informatics Journal, 14(2):157 – 164. Gould, B. A. (1855). On peirce’s criterion for the rejection of doubtful observations, with tables for facilitating its application. Astronomical Journal, 4:81–87. Harris, C., Bailey, A., and Dodd, T. (1998). Multi-sensor data fusion in defence and aerospace. The Aeronautical Journal, 102(1015):229–244. Kulik, J., Heinzelman, W., and Balakrishnan, H. (2002). Negotiation-based protocols for disseminating information in wireless sensor networks. Wirel. Netw., 8(2/3):169–185. Marzullo, K. (1990). Tolerating failures of continuous-valued sensors. ACM Trans. Comput. Syst., 8(4):284–304. Nakamura, E. F., Loureiro, A. A. F., and Frery, A. C. (2007). Information fusion for wireless sensor networks: Methods, models, and classifications. ACM Comput. Surv., 39(3). Ross, S. (2003). Peirce’s criterion for the elimination of suspect experimental data. Journal of Engineering Technology, 20(2). Steinberg, Alan N Bowman, C. L. W. F. E. (1999). Revisions to the jdl data fusion model. International Society for Optics and Photonics, pages 430–441. Tan, R., Xing, G., Yuan, Z., Liu, X., and Yao, J. (2013). System-level calibration for data fusion in wireless sensor networks. ACM Trans. Sen. Netw., 9(3):28:1–28:27. Taylor, J. R. (2012). Introdução à Análise de Erros - o Estudo de Incertezas. BOOKMAN, 2a ed. edition. Zhou, C.-H., Chen, B., Gao, Y., Zhang, C., and Guo, Z.-J. (2011). A technique of filtering dirty data based on temporal- spatial correlation in wireless sensor network. Procedia Environmental Sciences, 10, Part A:511 – 516. 16 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Proposta de um Sistema Aberto de Controle em Hardware e Software para VANT Direcionado à Entrega Confiável de Cargas Luiz Carlos Querino Filho1, Kalinka R. L. J. C. Branco2 1 FATEC - Faculdade de Tecnologia de Garça Av. Presidente Vargas, 2331 – Garça – SP - Brasil 2 USP - ICMC - Instituto de Ciências Matemáticas e de Computação Av. Trabalhador Sãocarlense, 400 - São Carlos - SP - Brasil [email protected], [email protected] Abstract. As a consequence of the evolutionary process of the miniaturization of electronic components, sensors and wireless communication devices, UAVs (Unmanned Aerial Vehicles) have become more accessible and present in several types of applications. One of the recent possibilities of use for these kind of devices is the delivery of parcels and cargo, and such use have began to be tested by retail and transportation companies. This paper presents a proposal of a UAV model using open hardware and softwares components, allowing the transport and delivery of parcels in a quadcopter with route planning, payload coupling, obstacle avoidance, package tracking during the path and safe delivery with confirmation of identity of the receptor. Resumo. Como consequência do processo evolucionário da miniaturização de componentes eletrônicos, sensores e dispositivos de comunicação sem fio, os VANTs (Veículos Aéreos Não Tripulados) se tornaram mais acessíveis e presentes em diversos tipos de aplicações. Uma das mais recentes possibilidades de uso para esses equipamentos é na entrega de pacotes e encomendas, e tal utilização já começa a ser testada por empresas de varejo e transportes. Este artigo apresenta uma proposta de um modelo de VANT com uso de componentes de hardware e software abertos, proporcionando o transporte e entrega de pacotes em um quadricóptero com planejamento de rota, acoplamento de carga, desvio de obstáculos, rastreamento do pacote durante o trajeto e entrega segura com confirmação da identidade do receptor. 1. Introdução Os VANTs (Veículos Aéreos Não Tripulados) são aeronaves que não necessitam de um piloto a bordo para seu controle e que são construídas geralmente em escala menor que as tradicionalmente tripuladas [Braga et al. 2011]. Podem ser elaborados como aviões, dirigíveis e helicópteros, sendo que para este último há as variações com mais de dois rotores, os chamados multirotores [Balas 2007]. Com a miniaturização dos componentes eletrônicos que equipam esses veículos, e seu consequente barateamento, sua utilização nos mais diversos campos de atividade aumentou significativamente. Vigilância, análise ambiental e missões militares são 17 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Bouabdallah, S., Siegwart, R. Full Control of a Quadrotor. In:. IEEE/RSJ international conference on Intelligent robots and systems, 2007. IROS 2007. IEEE, 2007. p. 153158. Braga, R. T. V., Branco, K. R. C., Trindade Jr, O., Gimenes, I. M. S. Evolving Tiriba Design towards a Product line of Small Electric-Powered UAVs, In: 1a Conferência Brasileira de Sistemas Embarcados Críticos, 2011, São Carlos. Anais do 1º CBSEC. São Paulo, EDUSP, 2011. p. 67-72. Branco, K. R. L. J. C. ; Pelizzoni, J. ; Neris, L O ; Trindade, O. Jr ; Osório, F S ; Wolf, D. F. Tiriba: A New Approach of UAV based on Model Driven Development and Multiprocessors. In: IEEE International Conference on Robotics and Automation ICRA Communications, 2011, Shangai. IEEE International Conference on Robotics and Automation - ICRA Communications, 2011. p. 1-4. DailyMail. "DHL tests delivery drone as airborne robots could be used to deliver medicine", Disponível em: <http://www.dailymail.co.uk/sciencetech/article2520818/DHL-tests-delivery-drone-airborne-robots-used-deliver-medicine.html> Acesso em 28 Fev 2014 Lehtonen, M., Staake, T., Michahelles, F. and Fleisch, E. "From Identification to Authentication – A Review of RFID Product Authentication Techniques", In: Networked RFID Systems and Lightweight Cryptography, Edited by Peter H. Cole and Damith C. Ranasinghe, Springer Berlin Heidelberg, 2008 p. 169-187 Neris, L. O. Um Piloto Automático para as Aeronaves do Projeto ARARA. Dissertação de Mestrado. Universidade de São Paulo. Dezembro, 2001. Ribeiro, L. R., Oliveira, N. M. F. UAV Autopilot Controllers Test Platform Using Matlab/Simulink and X-Plane. In: 40th ASEE/IEEE Frontiers in Education Conference. Washington, DC. 2010. Ruppen, A., Pasquier, J., & Hürlimann, T. A RESTful architecture for integrating decomposable delayed services within the web of things. International Journal of Internet Protocol Technology, 6(4), 247-259. 2011. Thomas, J., Polin, J., Sreenath, K., & Kumar, V. Avian-inspired grasping for quadrotor micro UAVs. In ASME International Design Engineering Technical Conference (IDETC), Portland, Oregon. 2013. Trindade Jr., O., Neris, L. O., Barbosa, L., Branco, K. R. L. J. C. . A Layered Approach to Design Autopilots. In: IEEE-ICIT 2010 International Conference on Industrial Technology, 2010, Viña del Mar. IEEE-ICIT 2010 International Conference on Industrial Technology. Santiago do Chile: IEEE Press, 2010. v. v1. p. 1395-1400. Yakimenko, O. A., Bourakov, E. A., Hewgley, C. W., Slegers, N. J., Jensen, R. P., Robinson, A. B., ... & Heidt, P. E. Autonomous Aerial Payload Delivery System "Blizzard". In: Proceedings of the 21st Aerodynamic Delivery Systems Technology Conference, AIAA, Dublin, Ireland (pp. 23-26). 2011. 23 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Arquitetura experimental para automação e integração de ambientes inteligentes com dispositivos móveis Vandermi J. Silva1, Gustavo L. P. Silva1 ,Vicente F. De Lucena Jr.2 Instituto de Ciências Exatas e Tecnologia ICET – Universidade Federal do Amazonas (UFAM) Caixa Postal 69100-000 – Itacoatiara – AM – Brasil 1 Universidade Federal do Amazonas (UFAM) {vandermi, vicente}@ufam.edu.br, [email protected] Abstract. In this work an experimental architecture for automation and integration smart environments with mobile devices is presented, considering gathering and storage of data from sensors and actuators. After analyzing and filtering data, the architecture will recommend services for users of smart environment. The proposal focuses on building an architecture that integrates information services based on context and presents a prototype for data collection actions in actuators and sensors and a prototype embedded on a mobile device (smart-phone) to interact with the sensors and actuators installed in an academic environment. The architecture is in testing with possible future modifications and adaptations to the integration of cognitive agents and context management module to manage and filter the data in the preprocessing module. Resumo. Neste trabalho é apresentada uma arquitetura experimental para automação e integração de ambientes inteligentes com dispositivos móveis considerando a coleta e armazenamento de dados de sensores e atuadores. Após a análise e filtragem de dados, a arquitetura permitirá recomendar serviços para usuários de um ambiente inteligente. A proposta concentra-se na construção de uma arquitetura que integre serviços baseados nas informações de contexto e apresenta um protótipo para coleta de dados de ações em atuadores e sensores e um protótipo embarcado em um dispositivo móvel (smartphone) para interagir com os sensores e atuadores instalados em um ambiente acadêmico. A arquitetura está em fase de teste com possíveis modificações e adequações futuras com a integração de agentes no módulo cognitivo e gerência de contexto para gerenciar e filtrar os dados no módulo de pré-processamento. 1. Introdução O uso do contexto em aplicações interativas é cada vez mais presente no cenário tecnológico e necessita ser estudado mais profundamente especialmente nos casos em que os cenários estão em constantes mudanças, por exemplo, os que envolvem Ambient Intelligence (AmI) e computação ubíqua [Abowd et. al. 1997]. A computação ubíqua permite reconhecer objetos e informações que estão em torno do usuário de forma dinâmica e sem interferência humana e a união dos sistemas ubíquos com a contextualização permitirá ao usuário maior mobilidade, além de facilitar o reconhecimento e localização de objetos e pessoas, que poderão ser acessados de 24 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 qualquer lugar através de um enlace de comunicação [Krohn 2004]. Ambientes inteligentes estão cada vez mais sendo inseridos na vida das pessoas por meio da automação residencial tanto através de tarefas corriqueiras como ligar ou desligar um sistema de iluminação, quanto as mais difíceis que envolvem identificar o contexto em que uma tarefa deve ser executada. Uma das atividades a ser desenvolvida em AmI se dá pela necessidade de localização de usuários em um determinado ambiente. Essa técnica de localização é descrita com o termo em inglês indoor location [Yang 2007] e permite o uso de tecnologias de redes sem fio para verificar o posicionamento de pessoas em um ambiente utilizando Radio Frequency Identification (RFID) e outras tecnologias de rede sem fio tais como os padrões IEEE 802.15.1, Bluetooth e IEEE 802.15.4, ZigBee. Em [Yang 2007] e [Honkavirta 2009], são apresentados os conceitos e as principais técnicas para localização indoor, que consiste basicamente em utilizar a triangulação do sinal de rádio e aplicar algoritmos da vizinhança mais próxima, KNN, seguido de modificações do algoritmo aplicando técnicas de predição baseadas nas coletas das rotas mais comuns do usuário, além da utilização do mapeamento de pontos de referência para ser aplicado na base de treinamento de um sistema de localização indoor. Baseado na necessidade de integrar os dados de sensores e atuadores em um sistema context-wareness este trabalho propõe uma arquitetura para automação de ambientes residenciais baseada em identificação de contexto em ambientes inteligentes para automatizar de forma transparente a identificação do usuário, sua localização indoor e suas preferências no contexto de uma residência automatizada. O trabalho foi dividido em seis seções descritas a seguir: Na Seção 2 serão apresentados os conceitos e definições sobre ambientes inteligentes AmI, context-aware e localização indoor, na Seção 3 serão apresentados os trabalhos relacionados, na Seção 4 será apresentada a arquitetura proposta na Seção 5 será apresentada a construção do protótipo finalizando com as discussões e as conclusões do trabalho que serão apresentadas na Seção 6. 2. Definições Nesta seção serão apresentados os conceitos principais utilizados no trabalho para facilitar o entendimento das tecnologias e ferramentas utilizadas na pesquisa. A seção foi subdividida em ambientes inteligentes, context-aware e localização indoor. 2.1. Ambientes inteligentes Uma definição de ambientes inteligentes descrito por [Aarts, 2004] é que AmI proporciona ambientes sensíveis e que respondem à presença de pessoas, dando ênfase na facilidade de utilização de serviços de apoio aos usuários e principalmente, no apoio das interações humanas com interfaces inteligentes e intuitivas, embarcadas em todos os tipos de objetos em ambientes capazes de reconhecer e reagir a presença de indivíduos diferentes. Em [Ramos, Augusto e Shapiro, 2008] AmI é apresentada como uma visão da sociedade da informação onde as pessoas convivem em ambientes inteligentes e com interfaces intuitivas embarcadas em dispositivos ao seu redor, capazes de reconhecer o ambiente e seus usuários e responder a diferentes estímulos por meio de sensores e acionadores. Esse novo paradigma proporciona a melhoria da qualidade de vida das pessoas por meio de sistemas e de serviços que usam dispositivos inteligentes, 25 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 personalizados e interconectados. A extração de dados baseados em contexto utiliza dentre outras, técnicas de Inteligência Artificial, Redes Neurais Artificiais, Agentes Inteligentes e Lógicas Fuzzy [Hoon e Ramos 2010], [Sampaio et. al. 2012] e [Fariba 2011]. Tais técnicas permitem que os sistemas de AmI sejam capazes de interagir com o usuário a partir dos dados obtidos do contexto e das regras inferidas por componentes inteligentes do sistema. Assim, usando essas técnicas ou um subconjunto delas, provavelmente a integração e a comunicação de diversos dispositivos instalados em um ambiente residencial automatizado, será melhorada. 2.2. Context-aware Em [Schilit e Theimer 1994], é apresentado uma definição de contexto como localização e identificação de pessoas e objetos, no entanto, outras definições mais abrangentes são apresentadas em [Ryan et. al. 1997] e em [Dey, 1998] como sendo a localização de usuários no ambiente, estado emocional do usuário, temperatura do usuário, temperatura do ambiente, comportamento, entre outras características. Pode-se definir o contexto no sentido mais genérico como uma informação qualquer que pode ser usada para caracterizar uma situação envolvendo pessoas, objetos e lugares que são considerados relevantes para a interação entre o usuário e o sistema. Já o conceito de sensibilidade ao contexto define que tipos de processo ou informação que melhor se adequará a determinada situação e pode ser aplicada de forma flexível em qualquer entidade móvel, visando à descoberta de padrões pessoais coletando, interpretando e respondendo ao usuário sobre os aspectos de outros dispositivos e do ambiente [Zimmer 2004]. Um sistema é context-aware se usar um contexto para disponibilizar informações ou serviços relevantes para o usuário onde a relevância depende da tarefa solicitada. Existem diferenças entre os conceitos de context-aware e contexto. O contexto trata das atividades, identidade, localização e tempo em que ocorreram as ações, enquanto que o context-aware trata da apresentação, execução automática e entrega (tagging) das informações contextuais [Abowd et. al. 1997]. 2.3. Localização Indoor Existem diversos métodos na literatura para calcular a localização e o mais conhecido deles é usando o Global Position System (GPS). No entanto, para a localização indoor esse método não é eficaz devida a dificuldade de recepção do sinal em um ambiente fechado, [G. Sun, J. Chen, W. Guo, e K.J.R. Liu 2005]. Para minimizar esse problema surgiram técnicas que utilizam a potencia do sinal WI-FI para identificar acess points e fazer a trilateração do sinal na esperança de diminuir a distancia entre o objeto ou pessoa a ser localizado no ambiente [P. Bahl e V. N. Padmanabhan, 2000]. A localização indoor baseada na potencia do sinal de rádio (RSS), pode ser implementada por meio de algoritmos e métodos probabilísticos para determinar o posicionamento do usuário por meio da distancia entre os pontos de referência e o sinal obtido, no qual se aplicando o método K-Nearest Neighbor (KNN), pode-se melhorar o desempenho da técnica de localização [Altintas e Tacha 2011]. Neste trabalho o tópico referente à localização indoor foi explorado baseado na potencia do sinal Wi-FI e técnicas probabilísticas para melhoria da aquisição do posicionamento do usuário dentro de um ambiente. 26 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 3. Trabalhos Relacionados Em [Corchado, J.; Bajo, J.; Abraham 2008] foi apresentada uma arquitetura de healthcare para monitorar idosos em uma casa de saúde. O sistema possibilitou o acompanhamento de pacientes com a doença de Alzheimer, por meio de etiquetas Radio Frequency Identification (RFID) instaladas na residência e no pulso de cada idoso monitorado. Quando o idoso se aproximava de alguma porta ou janela, o sistema capturava os dados do dispositivo RFID no seu pulso e enviava o sinal ao servidor de localização instalado na administração da casa. O sistema foi integrado em uma rede sem fios, que permitia que enfermeiros e médicos tivessem acesso à localização do paciente, usando um Personal Digital Assistent (PDA). Os equipamentos utilizados para acessar os dados foram empregados como clientes do sistema que acessavam uma base de dados comum a todos os componentes. Em [Zamora-Izquierdo et. al. 2010] foi apresentado uma arquitetura para home automation (HAM), composta por um sistema de monitoramento e controle por meio de vários dispositivos embarcados conectados a sensores e atuadores e centralizados em uma casa inteligente. O HAM possuía também, partes modularizadas que podiam ser integradas para monitorar todas as áreas de uma residência ou parte dela. A arquitetura suportava a infraestrutura de segurança e acesso remoto via internet através de dois métodos de acesso externo, o protocolo HTTP, usado para o servidor gateway que permitia monitorar o acesso a residência e o protocolo UDP para se comunicar com módulos de segurança e gateway remotos. O sistema ainda possuía entradas para um módulo de comunicação que podia ser bluetooth, ZigBee ou barramento Controller Area Network,(CAN-BUS), além de permitir a troca de mensagens por meio de Short Message System (SMS). Em [Bonino e Corno 2010] foi apresentada uma contribuição para estender os ambientes domóticos inteligentes (IDEs) para suportar inteligência baseada em regras, iniciando com um modelo formal em que regras são definidas para avaliar as propriedades dos ambiente por meio de ontologias. Duas linguagens de regras foram utilizadas a Semantic Web Rule Language (SWRL) e a JenaRules, para formalização e avaliação da camada de razão do sistema. As engines nomeadas de Jess e Jena foram comparadas e os resultados foram apresentados quanto à checagem de propriedades nos requisitos de efetividade da base de inteligência para prevê comportamentos, por exemplo, adaptação e interação proativa com o usuário. Os autores avaliaram as regras usando dois diferentes benchmarks, um ambiente doméstico pequeno composto por seis cômodos e um ambiente de escritório mais complexo composto por cinqüenta e duas salas. Como resultado, foi apresentado que o raciocínio baseado em regras pode ser efetivamente aplicado em ambientes inteligentes para avaliar on-line o contexto e provê comportamentos proativos para o ambiente. Em [Li e Wang, 2011] foi apresentada uma proposta para uma arquitetura lógica para desenvolvimento de sistemas AmI. Foram analisadas as funcionalidade de um framework para um middleware de context-aware que fez uso de ontologias para modelar as informações de contexto em ambiente de computação pervasiva, e inserir uma camada de razão em alto e baixo nível para auxiliar nas aplicações context-aware em sistemas de AmI. Foram definidos no artigo, contexto, context-awareness e ontologia e proposto pelos autores uma arquitetura para um middleware sensível a contexto. A arquitetura apresentada possuía três camadas: Camada de informação de 27 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 acesso, composta por uma base de dados comum obtida por sensores e atuadores, a camada de middleware de context-aware, usada para programar as funcionalidades de representação do contexto, gerência do contexto, armazenamento do contexto e o compartilhamento das informações de contexto, a camada de aplicação, responsável por disponibilizar as informações contextuais para consumidores finais. No trabalho apresentado em [Altintas e Tacha 2012] os autores melhoraram os resultados do algoritmo KNN para uso em sistemas de localização indoor, integrando uma memória de curto prazo, Short Term Memory (STM), onde as leituras de potência do sinal são armazenadas. Considerando a capacidade de movimento limitado de um usuário móvel em um ambiente interno, locais anteriores do usuário podem ser levados em consideração para obter sua posição atual. Na abordagem proposta, as leituras de potência do sinal foram refinadas com os dados históricos anteriores e comparados com o mapa de rádio do ambiente. Os resultados da avaliação indicam que o desempenho do KNN com as modificações apresentadas supera algoritmo KNN convencional. Neste trabalho pretende-se apresentar uma arquitetura experimental para automação e integração de ambientes inteligentes com dispositivos móveis considerando a coleta e armazenamento de dados de sensores e atuadores para após análise e filtragem, recomendar serviços para usuários de um ambiente. A proposta concentra-se na construção de uma arquitetura que integre serviços baseados nas informações de contexto e apresenta um protótipo para coleta de dados de ações em atuadores e sensores. 4. Arquitetura proposta A partir da avaliação inicial feita por meio da revisão dos trabalhos relacionados, foi desenvolvida uma arquitetura experimental para o desenvolvimento do trabalho que é apresentada na forma de diagrama de blocos divididos em quatro módulos interconectados. Estes módulos permitem receber dados de entrada adquiridos por sensores e atuadores diversos instalados em uma residência ou escritório para em seguida fazer o pré-processamento e após essa fase, definir as políticas e estratégias para tomada de decisão. O resultado final serão os serviços disponíveis baseados nos dados dos sensores, atuadores e preferências do usuário. Figura 1. Overview da Arquitetura proposta 28 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 A contribuição principal da arquitetura proposta neste trabalho é desenvolver o módulo cognitivo para recomendar serviços para o usuário de um sistema domótico de maneira a minimizar seu esforço e promover a configuração automática do ambiente baseado nas informações processadas. A Figura 1 apresenta o overview que será discutido nas subseções a seguir. 4.1. Módulo de Entrada O módulo de entrada é composto por diversos sensores e atuadores representados aqui como câmeras, sensores de presença, sensores de luminosidade, sensores de portas e sensores de temperatura, responsáveis por coletar os dados do ambiente e do usuário. Um exemplo de dados relacionados a sensores que podem ser coletados no ambiente são as entradas e saídas de um usuário que por meio de um sensor de abertura e fechamento de portas e uma micro câmera podem ser capturadas e armazenadas na base de dados. Outro exemplo são os atuadores representados aqui por fechaduras eletrônicas, relés, controles remotos e acionadores de cortinas automatizadas. Os dados de atuadores como no caso clássico de acionamento de lâmpadas por meio de relés são armazenados na base de dados e poderão servir como ponto de partida para um sistema preditor de comportamento após a análise e filtragem. 4.2. Módulo de Pré-processamento do Conjunto de Dados O conjunto de dados apresentado na arquitetura trata-se de uma base de dados brutos coletados dos sensores e atuadores. São formados por atributos que podem representar uma pessoa, um objeto físico ou um local específico dentro do ambiente. Inicialmente os dados são subdivididos em dados de sensores Ds e dados de atuadores Da. Essa divisão se dá para facilitar a classificação dos dados para serem armazenados no histórico. A partir da leitura e armazenamento de dados por meio do bloco de conjunto de dados de maneira separada, os dados de sensores e atuadores são armazenados em tuplas para posteriormente serem analisados e filtrados. A representação formal dos dados pode ser feita por meio de uma matriz de objetos dada por Xn x d onde n representa o número de objetos e d o número de atributos de entrada de cada objeto. O valor de d define a dimensionalidade dos objetos, espaço de entrada ou espaços de atributos. A Tabela 1 apresenta um exemplo de tuplas de dados coletados de um sensor de movimento. Na tabela podem ser observados os dados de um sensor de abertura de portas com a ação executada, a data, hora e local do acionamento, onde cada linha da tabela corresponde a uma tupla da base de dados. Tabela 1. Exemplo de tuplas em uma matriz Ação Data Hora Local 0 21/06/2013 07:42:32 Porta principal 1 21/06/2013 08:09:16 Porta principal 0 21/06/2013 08:11:06 Porta principal 1 21/06/2013 08:34:16 Porta principal O conjunto de dados pode ser codificado em um banco relacional, em uma 29 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 estrutura de dados de vetores e matrizes ou em documentos bem formados, por exemplo, um arquivo XML. Durante a fase de pré-processamento é necessário definir técnicas para análise e filtragem de dados e durante essa fase a caracterização dos dados, o tipo e a escala devem ser observadas [Faceli, et. al 2011]. Para coleta de dados deste trabalho foi desenvolvido um banco de dados modelo relacional que será apresentado na Seção 5. A caracterização dos dados consiste em mapear os atributos dos objetos do conjunto de dados, o tipo, define se o atributo é qualitativo ou quantitativo e a escala define as operações que podem ser realizadas sobre os valores do atributo. A escala pode ser nominal, racional ou intervalar. A análise consiste na preparação dos dados para descrever os objetos por meio de um vetor de características ou um conjunto de atributos de entrada. Por exemplo, um objeto sensor de movimento tem como características, um id, local de instalação e a data/hora do disparo. A partir da análise e filtragem desses dados, pode-se definir que sensor disparou e quais os horários que normalmente ele dispara nesse caso isso é uma característica de escala intervalar. A análise e filtragem de dados apresentada no bloco de pré-processamento serão feitas visando à extração das características necessárias para identificação de grupos e objetos semelhantes no conjunto de dados e regras de associação que relacionam esses grupos. 4.3. Módulo Cognitivo O módulo cognitivo representa a inteligência do sistema e está dividido em três subsistemas que são as políticas, que contém as regras para o subsistema de decisão e as estratégias, que contém os algoritmos para inferência das políticas. Um exemplo simples de políticas baseadas em regras IF THEN ELSE, que pode ser implementada em um protótipo para alimentar um sistema de decisão pode ser visto na Figura 2 A. Figura 2. Exemplo de um encadeamento de regras O resultado final de um encadeamento de regras desse tipo pode gerar uma árvore de inferência conectando todas as regras utilizadas. A Figura 2 B apresenta a árvore gerada a partir das três regras IF THEN ELSE. Nesse exemplo pode se observar que o resultado final C, será possível a partir do resultado das operações anteriores combinadas entre si e nesse caso C será a resposta para as premissas. É obvio que um sistema inteligente não deve ser baseado apenas nesse tipo de regras, entretanto o exemplo serve para enriquecer a visão da arquitetura 30 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 que está sendo apresentada e para implementar um protótipo simples como prova de conceito. As estratégias para auxiliar na decisão que podem ser utilizadas na arquitetura proposta variam desde o uso de algoritmos para agentes inteligentes baseados em utilidades [Russell e Norvig, 2004] até métodos probabilísticos e modelos descritivos [Faceli, et. al, 2011], isso depende da escolha do método a ser implementado no subsistema de estratégias. O subsistema de decisão por meio das políticas e das estratégias estabelecidas define quais os serviços que podem ser disponibilizados para o usuário a partir da percepção atual e do histórico gerando uma lista de serviços disponíveis. 4.4. Módulo de Saída As saídas esperadas do sistema são os serviços disponíveis ao usuário de acordo com suas preferências que passam a ser as ações nos atuadores retroalimentando o sistema. Um exemplo de serviço pode ser a climatização do ambiente de acordo com a temperatura ideal para uma determinada pessoa ocupante de um ambiente inteligente. Nesse caso o ambiente pode se ajustar para os padrões aprendidos durante as fases de treinamento. Nos casos em que mais de um usuário esteja disputando o mesmo serviço o subsistema de decisão poderá fazer a média ponderada e recomendar a temperatura ideal para todos. Outro exemplo de serviços seria o de localização de periféricos mais próximos do usuário, por exemplo, uma impressora. Nesse caso se o usuário desejasse imprimir um trabalho em uma impressora diferente da que normalmente imprime, o serviço de impressão o avisaria por meio de um sistema de mensagens que haveria uma impressora mais próxima a ele. Diversos serviços podem ser desenvolvidos usando a arquitetura para isso basta construir as políticas e estratégias baseadas nas análises dos dados de sensores e atuadores. 5. Desenvolvimento do Protótipo Durante o desenvolvimento do trabalho foi necessário instalar e configurar o hardware e o software usados no protótipo e para isso foram utilizados os dispositivos citados na Tabela 2 os quais foram instalados nas dependências do laboratório de sistemas móveis e Automação do ICET-UFAM e do CETELI-UFAM. Tabela 2. Hardware e Software utilizados no experimento Material Quantidade Kit Placa Rogercom Zigbee e COM USB Rogercom e Xbee Pro Series 2 Roteador TPLink TL-WR1043ND com taxa de transferência 300Mbts 1 Servidor WEB 1.6 GHz 2MB L3 cache, 2Gb de RAM, HD 500Gb 1 Smartphone Android 4.4.2 KitCat 1 Tablet Tab3 4.1.2 Jelly Beam 1 Sensor Infravermelho passivo 2000CF/IVP 2000SF 2 31 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 5.1. Configuração dos Módulos de Transmissão sem fio Xbee Os módulos XBee utilizados no experimento podem ser configurados por meio de comandos de modem AT via porta serial. Os comandos AT principais utilizados para a configuração dos nós XBee são apresentados na Tabela 3, esses comandos podem ser digitados diretamente em um terminal Linux. Um exemplo de comando para configurar um módulo XBee como servidor pode ser digitado da seguinte forma: "ATMY1, ATDL2, ATNIserver, ATWR, ATCN". É muito importante não esquecer que com exceção do comando +++ todos os outros comandos precisam da tecla <enter> para que o módulo XBee responda. Tabela 3. Comandos AT para configuração do módulo XBee Comando AT Resposta do módulo Significado +++ OK Pronto para receber comandos ATMY 5001 Número identificado do nó de origem ATDL 5000 Número identificado do nó de destino ATNI Servidor Nome do nó ATWR OK Grava as alterações no módulo Xbee ATAP 0 Módulo API desabilitado ATCN OK Sai do módulo de comando 5.2. Desenvolvimento do experimento do lado Servidor A aplicação servidor tem como objetivo receber informações dos sensores dispostos no ambiente, podendo ser sensores de luminosidade, temperatura, umidade, abertura e fechamento de porta, sensores de presença, entre outros. Neste protótipo foi utilizado sensores de presença, informando e armazenando em banco de dados as ações de presença no ambiente e sensores de abertura e fechamento de portas. A Figura 3 apresenta o banco de dados desenvolvido de acordo com o módulo de pré-processamento apresentado na arquitetura proposta. Figura 3. Base de Dados Desenvolvida no Experimento 32 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 A modelagem do banco de dados apresentado na Figura 3 contem oito entidades mapeadas a partir dos dados que se pretendia coletar na fase de experimentos. Por exemplo, horário de entrada, saída para almoço, saída para lanche, idas ao banheiro e permanência na mesa de trabalho. As entidades principais responsáveis pelo armazenamento são o usuário, ligado a um ou mais dispositivos, as entidades sensor e actuator, responsáveis por coletar dados de ação e de sensoriamento do ambiente, e a entidade action, responsável por armazenar as ações dos atuadores e sensores. O sistema de coleta de dados foi implementado da seguinte maneira: O usuário é previamente cadastrado na base com seus respectivos dipositivos que podem executar ações nos atuadores e verificar a situação dos sensores que em seguida são armazenadas na entidade ação. Todas as ações armazenadas na base poderão ser avaliadas pelo módulo cognitivo para extrair características de contexto e recomendar serviços ao usuário baseado no histórico da base e nas regras definidas no módulo cognitivo. A base de dados permite o armazenamento dos dados de sensores e atuadores que são relacionados com as ações executadas por eles. Cada usuários está relacionado com os dispositivos móveis que utiliza e esses dispositivos também são interligados às ações por meio do endereço de MAC. Desta forma é fácil mapear as atividades dos sensores e atuadores, dispositivos móveis e, por sua vez, os usuários donos dos dispositivos. No experimento foi utilizado o endereço MAC do dispositivo para comparar com o endereço armazenado na base de dados somente para substituir o uso das tecnologias de localização porque da forma como a solução foi construída é possível associar na base de dados de sensores qual mesa de trabalho pertence a que usuário e se o dispositivo dele encontra-se no escritório. 5.3. Desenvolvimento do experimento do lado Cliente Para acesso ao sistema de controle, o usuário deve ter um dispositivo móvel (smartphone, tablet ou notebook) conectado a rede sem fio. Ao iniciar a aplicação o sistema busca obter o endereçamento físico local do dispositivo (endereço MAC local) e o envia ao servidor, como uma requisição do tipo string, por meio do protocolo de hipertexto HTTP usando o método POST. Por sua vez o servidor recebe a requisição e por meio da consulta à base de dados, confirma a existência do cadastro do dispositivo do usuário. Figura 4. (A) Maquete utilizada no experimento (B) Aplicativo móvel desenvolvido em Android 33 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Confirmada a permissão de acesso do dispositivo, o servidor retorna uma mensagem de confirmação para que seja mostrada ao usuário. Após o acesso ao sistema o usuário tem a possibilidade de realizar controles do ambiente como ligar e desligar lâmpadas condicionador de ar e outros dispositivos que possam ser monitorados. Essas atividades feitas no ambiente por meio de um smartphone ou tablet, são armazenadas na base de dados para posterior análise contextual. Logo após a identificação e execução da ação, o servidor envia uma mensagem de confirmação informando que a ação solicitada foi executada. Caso haja erro de identificação do dispositivo o servidor informa e reporta à aplicação o erro ocorrido. A Figura 4 apresenta o resultado da aplicação móvel acessando os sensores em uma maquete desenvolvida no laboratório para simular o acionamento de lâmpadas nos comôdos de uma residência e a Figura 5 apresenta o ambiente real da coleta de dados feita usando sensores e atuadores em mesas e portas de um laboratório da universidade. Figura 5. (A) Mesa de trabalho com sensor de presença (B) Porta com sensor de abertura e fechamento (C) Coleta de Dados dos sensores e atuadores Na Figura 5 A e B, pode se vê que os sensores estão posicionados para capturar o movimento nas mesas de trabalho dos usuários enquanto que o sensor de abertura de porta do tipo contato, foi instalado de modo a permitir a coleta dos dados das aberturas e fechamentos da porta do laboratório. A Figura 5 C apresenta o log da inserção dos dados na base. 6. Resultados e Conclusões O presente trabalho apresentou uma arquitetura experimental para automação e integração de ambientes inteligentes com dispositivos móveis. A arquitetura foi dividida 34 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 em módulos na qual foram construídos dois protótipos experimentais, um cliente para dispositivos móveis e um servidor para coletar dados de sensores e atuadores. A arquitetura permitiu a integração desse dispositivos com sensores e atuadores para monitorar um ambiente e disponibilizar serviços baseados no histórico de uso. O conjunto de dados apresentado na arquitetura foi desenvolvido usando o banco de dados relacional MySQL e suportou o armazenamento de uma quantidade significativa de dados dos sensores, (40.000 tuplas) durante um mês de coleta diárias sem travamentos. Esses dados serão tratados na camada cognitiva na próxima fase do projeto, por meio das ações baseadas em estratégias e regras tendo como resultado final a recomendação do uso de equipamentos de acordo com o perfil do usuário extraídos da base de dados. Um protótipo para dispositivos móveis simulando um ambiente residencial e de escritório foi desenvolvido para testar a inserção automática dos dados de sensores e atuadores bem como a identificação automática do dispositivo móvel do usuário por meio do endereço físico de rede, permitindo simular a identificação da entrada e saída do usuário no ambiente monitorado. Além da coleta de dados em ambiente real foi disponibilizado também uma maquete para teste de acionamentos de equipamentos eletrônicos para simular o uso de lâmpadas e condicionadores de ar do ambiente. Os resultados do trabalho foram a coleta de dados para a formação de uma base de conhecimento, a integração entre o hardware dos sensores e atuadores com a aplicação servidor e o acesso aos dados via rede sem fio com autenticação automática feita pelo dispositivo móvel através da verificação do endereço físico do dispositivo na rede. A Estratégia utilizada para armazenar os endereços e reconhecer o usuário por meio de seu dispositivo, foi modelar os dados baseaando-se nas ações dos dispositivos e não na ação do usuário. Em outras palavras, os dispositivos é que executam as ações assim que se conectam na rede sem fio, sem a necessidade de intervenção humana. A arquitetura está em fase de teste com possíveis modificações e adequações futuras com a integração de agentes no módulo cognitivo e gerência de contexto para gerenciar e filtrar os dados no módulo de pré-processamento Os próximos passos da pesquisa serão construir um preditor para analisar os dados coletados na base e traçar o perfil do usuário para recomendar os serviços de uma residência ou escritório automatizados. Agradecimentos Agradecemos a Fundação de Amparo à Pesquisa do Estado do Amazonas, FAPEAM, a CAPES ao CNPq ao PPGI-UFAM ao CETELI-UFAM e ao ICET-UFAM pelo apoio financeiro, materiais e laboratórios de pesquisa. Referências Abowd, G.D., Dey, A.K., Orr, R., Brotherton, J. Context-Awareness in Wearable and Ubiquitous Computing. 1 International Symposium on Wearable Computers (1997) 179-180. 35 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Altintas, B., & Serif, T. (2011). Improving RSS-Based Indoor Positioning Algorithm via K-Means Clustering. Wireless Conference 2011-Sustainable. Altintas, B., & Serif, T. (2012). Indoor Location Detection with a RSS-based Short Term Memory Technique (KNN-STM), (March), 794–798. Aarts, E.; , "Ambient intelligence: a multimedia perspective," Multimedia, IEEE , vol.11, no.1, pp. 12- 19, Jan.-March 2004. Bonino, Dario; Fulvio, Corno. Rule-based intelligence for domotic environments, Automation in Construction, Volume 19, Issue 2, March 2010. Corchado, J.; Bajo, J.; Abraham, Gerami: Healthcare Delivery IN Geriatric Residences. IEEE Intelligent Systems, 23(2):19-25, 2008. Dey, A.K. Context-Aware Computing: The CyberDesk Project. AAAI 1998 Spring Symposium on Intelligent Environments, Technical Report SS-98-02 (1998) 51-54 Faceli, Katti; Ana, Carolina, Lorena; João, Gama; André, C., P., L., F., de Carvalho. Inteligência Artificial uma Abordagem de Aprendizado de Máquina. LTC 2011. Fariba Sadri. 2011. Ambient intelligence: A survey. ACM Comput. G. Sun, J. Chen, W. Guo, and K.J.R. Liu, “Signal processing techniques in network-aided positioning: a survey of state-of the-art positioning design.” IEEE Signal Processing Magazine, vol. 22, no. 4, pp 12-23, 2005 Hoon Ko; Ramos, C.; , "A Survey of Context Classification for Intelligent Systems Research for Ambient Intelligence,"Complex, Intelligent and Software Intensive Systems (CISIS), 2010 International Conference on, vol., no., pp.746-751, 15-18 Feb. 2010. Honkavirta, V., Perala, T., Ali, S. and Piche, R. 2009 A comparative survey of WLAN location fingerprinting Methods. Proceedings of the 6th Workshop on Positioning, Navigation and Communication. Li, H., & Wang, J.. Application Architecture for Ambient Intelligence Systems Based on Context Ontology Modeling. 2011 International Conference on Internet Technology and Applications. Krohn, A.; , "Ubiquitous computing and the Internet," Applications and the Internet, 2004. Proceedings. 2004 International Symposium on , vol., no., pp. 9, 2004. P. Bahl and V. N. Padmanabhan, “RADAR: an in-building RF-based user location and tracking system”. NFOCOM 2000. 19th Annual Joint Computer and Communications Societies, vol. 36 Conference of the IEEE 2, pp. 775-784, 2000. Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 38 32º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Florianópolis - SC II Workshop de Comunicação em Sistemas Embarcados Críticos (WoCCES 2014) Sessão Técnica 2 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 o controle ou gerenciamento de informação. Graças aos avanços da tecnologia esses sistemas contam hoje com maior capacidade de processamento, memória e adaptação a diferentes necessidades, podendo inclusive se comunicar com qualquer outro dispositivo, embarcado ou não. Um VANT constitui uma aplicação típica de um sistema embarcado crítico. O termo VANT foi adotado pela FAA (Federal Aviation Administration) e pela comunidade acadêmica internacional para designar sistemas que incluem não apenas os aviões, ma s todos os elementos associados, tais como o payload, a estação de controle terrestre e os links de comunicação (GAO, 2008). VANTs têm sido amplamente utilizados na agricultura de precisão, segurança nacional (missões militares) e monitoramento ambiental. Diversos trabalhos já foram publicados nessa área, demonstrando a viabilidade do uso desses veículos como ferramentas importantes para realização da agricultura de precisão e no monitoramento ambiental (TRINDADE JR, et al., 2010), (BRANCO, et al., 2011), (TRINDADE, et al., 2012) por exemplo. Existem diferentes tipos de VANTs que apresentam, inclusive, diferentes capacidades. Algumas aeronaves podem voar de forma autônoma, seguindo uma trajetória de voo préprogramada (baseada em um grid ou uma sequência de waypoints) (TRINDADE JR, et al., 2010), enquanto outras voam recebendo comandos a partir de estações terrestres operadas por pilotos. O tamanho da aeronave pode variar desde o micro até o grande, e a estação de controle terrestre pode ser implementada em smartphones, tablets, notebooks ou redes de estações de trabalho (estações de controle distribuídas). Desse modo, a aeronave pode variar não apenas em tamanho, mas também na forma, no tipo de propulsão e no desempenho. A interface homem-máquina pode variar desde um joystick até uma interface de usuário tangível (por exemplo, uma mesa tangível com realidade aumentada). O desempenho dos links de comunicação e o tipo de carga também são muito importantes para cumprir a missão destinada ao sistema, dentre as quais pode-se citar, dentre outras, a utilização em agricultura de precisão, vigilância de fronteiras e o transporte de cargas (RODRIGUES, et al., 2011a),(BRANCO, 2012),(DOD, 2002), (DOD, 2005), (DOD, 2007) e (DOD, 2009). Em um futuro um pouco mais distante espera-se que as únicas aeronaves tripuladas que deverão permanecer atuantes são as que transportam passageiros, a exemplo do que ocorre em outros sistemas de transporte, por exemplo, o metroviário no qual o condutor precisa atuar somente em emergências. Esse uso crescente dos VANTs deve fazer com que eles se tornem comuns, passando a ser comercializados de forma mais ampla. Nesse cenário, arquiteturas que permitam a organização e a definição mais específica dos componentes que compõem esses sistemas embarcados (os VANTs), facilitarão o desenvolvimento de hardware e software que os compõem, permitindo que esses veículos possam ser inseridos e incorporados mais facilmente ao espaço aéreo e contribuindo para a sua disseminação. Uma vez que os componentes de um VANT podem ser divididos em segmento aéreo e segmento terrestre, e que cada um desses segmentos pode ser subdividido, a subdivisão desses segmentos em camadas permite que o sistema seja dividido em subsistemas que 42 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 3. TRABALHOS RELACIONADOS É imprescindível observar o estado da arte dos VANTs em relação aos modelos arquiteturais, arquiteturas e suas variantes adotadas. Sendo assim, seguem os que se destacaram durante a revisão bibliográfica devido tanto às semelhanças com o modelo proposto quanto ao fato de abordarem tópicos relevantes para o trabalho. A. Arquiteturas Tradicionais (Federadas) O NIST (National Institute of Standards and Technologies) provê um modelo de referência para VANTs (NIST, 2002). Este modelo de arquitetura é conhecido como modelo convencional ou Federado, onde cada unidade de processamento tem seu projeto e finalidade de uso específicos ou seja não compartilhados. Os trabalhos que seguem, utilizam esta abordagem. 1. O Trabalho de Pastor, Lopez e Royo O trabalho proposto em (PASTOR; LOPEZ; ROYO, 2007) baseia-se em uma arquitetura de hardware e software desenhada para operar o controlador de missão e payload de mini/micro VANTs. Segundo os autores a inovação da proposta está no uso de uma arquitetura de hardware distribuída facilmente escalável pelo uso de LAN, arquitetura de software baseada em subscrição de serviços, abstração da camada de comunicação e fluxo de execução baseado no planejamento de missão. Segundo os autores, o alto nível de modularidade oferecido por uma LAN provê flexibilidade para acoplar o tipo de microprocessador mais adequado ao uso do módulo, atendendo seus requisitos funcionais. 2. MCAP Em (OLSON; BURNS, 2005) é proposto um modelo de arquitetura. Trata-se da fase III do projeto denominado MCAP (Manned / Unmanned Common Architecture Program), utilizado pelo Exército norte-americano para uso em VANTs dos tipos FCS (Future Combat Systems - Sistemas de Combate do Futuro) e C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance - Comando, Controle, Comunicações, Computadores, Inteligência, Vigilância e Reconhecimento). A arquitetura MCAP, fase III, é baseada em componentes eletrônicos e software prateleira - COTS e interfaces de padrões abertos. Os objetivos do desenvolvimento modelo foi o de definir e desenvolver uma arquitetura capaz de suportar uma série plataformas de VANTs do Exército norte-americano demonstrando o desempenho sistema resultante em ambiente de laboratório. 3. RFCSA de do de do Em (DENG; MA; ZHU, 2012) os autores propõem um projeto denominado Reconfigurable Flight Control System Architecture (RFCSA) ou arquitetura reconfigurável para sistemas de controle de voo. O desenvolvimento do projeto foi realizado seguindo os seguinte pré-requisitos: Interface entre módulos simples e unificada - O módulo funcional deve ser fácil de ser adicionado, removido ou substituído para aplicações específicas; Projeto fácil para aplicações de alto nível - Baixo nível de necessidade de implementar detalhes permite que o usuário desenvolva aplicações de alto nível facilmente; Reutilização de Hardware e Software - O hardware e software desenvolvidos para uma aplicação podem ser portados para outra sem necessidade de grandes modificações; Baixo custo - O produto 44 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 que são mais leves se comparadas às baterias de chumbo-ácido ou níquel-metal, mais comuns de serem encontradas. Os objetivos do projeto são rever os conceitos da arquitetura de sistemas aviônicos e desenvolver algoritmos de controle de voo. Os autores entendem que além do conceitos básicos da IMA, são ainda pré-requisitos desta arquitetura a aplicação de padrões abertos e uso de módulos comuns hardware e software, desde o barramento de dados até linguagem de software, o uso de equipamento de prateleira Commercial-of-the-shelf (COTS) em todos os níveis, o uso de Sistemas Operacionais de Tempo Real - Real Time Operating Systems (RTOS) comercialmente disponíveis que suportem proteção (DO-178C), segurança (MILS - Multiple Independent Levels of Security/Safety ) e padrões de particionamento (ARINC-653) e o desenvolvimento de softwares que atendam os padrões exigidos. 2. ANKA Outro projeto que faz uso da arquitetura IMA é o da estação de controle terrestre utilizado no Sistemas de VANTs da força área da Turquia, conhecido como programa ANKA (KAYAYURT, et al., 2011). Este trata-se da estação de controle terrestre utilizada em conjunto com um VANT da categoria MALE (Medium Altitude Long Endurance Altitude média e longa duração) que voa a 30.000 pés de altitude - cerca de 9.144m e um raio de alcance de 200 Km. A estação de controle terrestre utiliza dois tipos de softwares, os de tempo real, responsáveis pelo controle de voo, telemetria e interface homemmáquina, que são desenvolvidos em linguagem ANSI C e são executados em dois computadores PowerPC, trabalhando em sistema de redundância tipo Mestre/Escravo e os de não tempo real, responsáveis pela gravação da telemetria e imagens, teste de pré-voo e outra funcionalidades, que são desenvolvidos com metodologia orientada a objetos e linguagem C# e .Net. O desenvolvimento de ambos os tipo de software seguem alguns padrões: - Uso da arquitetura geral e mensagem de interfaces para estações de controle terrestre, especificados no documento OTAN STANAG 4586 (NATO/OTAN, 2007); - Guia para desenvolvimento de softwares críticos para aviônicos, que define processos, objetivos e atividades para cada nível de criticidade, padronizados pelo DO-178B emitido pela RTCA (Radio Technical Commission for Aeronautics) (PANICKER, 2001); - Desenvolvimento de software com particionamento de tempo e espaço, utilizando os padrões IMA e ARINC-653. Segundo os autores, o uso da IMA no projeto de software de tempo real empregado na estação de controle terrestre auxiliou na modularização, proteção e divisão de tempo nos componentes do software. A utilização deste modelo permitiu um desenvolvimento no qual cada desenvolvedor era responsável por um módulo e um deles foi responsável pela integração destes, o que facilitou o desenvolvimento e verificação do produto final. 3. Linux-based ARINC 653 O trabalho apresentado em (JIN, et al., 2012) os autores optaram pela IMA como alternativa à arquitetura Federada devido ao crescente uso de recursos computacionais nos aviônicos estarem gerando problemas de SWaP (Size, Weight, and Power - Tamanho, Peso e Energia). 46 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Os autores entendem que o uso dos conceitos da IMA são aplicáveis na construção de um pequeno VANT de baixo custo, permitindo fácil desenvolvimento e extensão, e que permite também a utilização de hardware de prateleira - COTS e software livre que implemente a ARINC 653, que era objetivo proposto no projeto. Esta seção apresentou os conceitos e definições de arquiteturas, modelos, modelos de referência. Vários foram os trabalhos apresentados que auxiliam na definição das razões para a construção de um novo modelo arquitetural para interconexão de sistemas para veículos aéreos não tripulados. Ademais, os artigos relacionados a VANTs encontrados na literatura apresentam VANTs implementados usando abordagens tradicionais (VALAVANIS, 2007), (DOD, 2002), (DOD, 2005), (DOD, 2007) e (DOD, 2009). Por outro lado, Existem roadmaps que ilustram os avanços esperados para os VANTs, publicados periodicamente por organizações militares, como a Força Aérea dos Estados Unidos (USAF, 2009) e, nesses, citam-se que para o futuro deve-se adotar uma arquitetura aberta, padronizada e escalável que permitirá a adição rápida de funcionalidades modulares. Mesmo existindo vários modelos e arquiteturas na literatura aberta, nenhum dos modelos apresentados contempla todos os requisitos necessários para a confecção de um VANT que não seja específico. Um resumo dos requisitos atendidos por cada um dos trabalhos é apresentado na Tabela 1. - - √ parcial √ parcial parcial parcial - parcial √ - - - - - √ Monitoramento e controle parcial - parcial parcial parcial - √ √ Navegação e serviços parcial √ parcial √ √ parcial parcial √ Missão √ √ parcial √ √ - √ √ Física do segmento terrestre - - - parcial - √ - √ Estação de controle terrestre - parcial - parcial √ √ parcial √ RTOS distribuída Abstração do sistema - 47 √ LARISSA √ Linux-based ARINC 653 parcial parcial ANKA parcial Física do segmento aéreo LMA Trabalho de Pastor, Lopez e Royo - Camada / Projeto RFCSA MCAP Trabalho de Ilarslan, Bayrakceken e Arisoy Tabela 1 Comparativo entre os principais trabalhos encontrados na literatura aberta e o LARISSA. Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 (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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Escalonamento de Sono e Efeito Recuperação em Baterias de Nodos em Redes de Sensores sem Fio Leonardo M. Rodrigues1 , Carlos B. Montez1 , Paulo Portugal2 , Francisco Vasques2 1 Programa de Pós-Graduação em Engenharia de Automação e Sistemas (PPGEAS) Universidade Federal de Santa Catarina (UFSC) – Florianópolis, SC – Brasil 2 Faculdade de Engenharia da Universidade do Porto (FEUP) Porto – Portugal [email protected], [email protected], [email protected], [email protected] Resumo. Neste artigo é apresentado um estudo sobre a questão energética em nodos de uma Rede de Sensores sem Fio (RSSF). São abordados alguns modelos de bateria utilizados em simuladores para representar o comportamento de uma bateria ao longo do tempo, conforme o consumo energético imposto pelos nodos. A importância do escalonamento de tarefas nos nodos (escalonamento do sono) também é discutida, assim como o chamado efeito recuperação das baterias. Resultados de simulações são usados para demonstrar a importância do escalonamento na execução de atividades em cada nodo, refletindo no aumento do tempo de vida da rede. 1. Introdução O desenvolvimento, seguido pela evolução e redução nos preços, de nodos sensores tem levado à uma popularização das Redes de Sensores sem Fio (RSSF). Esses nodos – com capacidade de processamento, comunicação e sensoriamento de grandezas do ambiente (ex. temperatura, umidade, som, pressão atmosférica) – têm propiciado o emprego de RSSF nos mais diversos domı́nios de aplicação [Buratti et al. 2009]. Originalmente, uma Rede de Sensores sem Fio era definida como aquela formada por um grande número de nodos, espalhados de forma aleatória e com capacidades de auto-gerenciamento [Akyildiz et al. 2002]. Atualmente, encontra-se esse tipo de rede empregado em um escopo muito mais amplo, desde aplicações em ambientes industriais [Gungor and Hancke 2009] - onde muitas vezes há um número limitado de nodos os quais são cuidadosamente implantados - até em aplicações da agropecuária [Aqeel-ur-Rehman et al. 2011] - onde é possı́vel a existência de milhares de nodos, alguns com mobilidade. Independente do domı́nio de aplicação, em comum a todos os tipos de RSSF, existe o conceito de “esforço colaborativo” entre os nodos, no sentido de monitorar as grandezas do ambiente. A ideia básica é que a confiança no monitoramento seja baseada em um grupo de sensores, de baixo custo, em vez de se basear em sensores individuais. Ademais, geralmente há uma redundância no número de nodos implantados, de forma que nem todos necessitam monitorar a mesma grandeza fı́sica simultaneamente. Outra caracterı́stica importante nas RSSF é a necessidade de economia energética. O uso de baterias nos nodos implica na preocupação de se manter a rede operacional o maior tempo possı́vel. Isso é decorrente do fato da substituição de baterias, quando ocorrerem seus 55 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 esgotamentos, poder ser uma tarefa inviável ou ter um custo financeiro proibitivo, quando a rede, por exemplo, for implantada em locais inóspitos ou tiver grande número de nodos. A redundância em RSSF e a necessidade de se estender o tempo de vida da rede implicam no estabelecimento de polı́ticas para se efetuar rodı́zio na utilização dos nodos de forma eficaz. Quando a voltagem da bateria atinge um determinado nı́vel, conhecido como cutoff, as reações eletroquı́micas internas deixam de acontecer, indicando que a mesma está descarregada. Alguns nodos cujas baterias estejam próximas aos seus estados de cutoff podem ser encarregados de executar tarefas que consumam menos energia, podendo até mesmo entrar em regimes ociosos (sleep mode) enquanto outros nodos, com maior capacidade atual em suas baterias, assumem as tarefas de monitoramento e processamento local na rede. As técnicas que realizam alternância na execução dos nodos muitas vezes são denominadas de escalonamento do sono (sleep scheduling) [Jurdak 2010]. Contudo, muitos dos trabalhos sobre este assunto são baseados em simulações nas quais assume-se que as baterias dos nodos têm comportamento simples, muitas vezes, lineares. Esse tipo de suposição pode afetar os resultados obtidos pelas simulações, pois as baterias possuem comportamentos bem mais complexos e difı́ceis de se modelar. No contexto de modelagem de baterias, algumas pesquisas apontam soluções para estimar o tempo de vida de baterias sob diversos tipos de cargas [Panigrahi et al. 2001, Rakhmatov et al. 2002, Jongerden and Haverkort 2008b, Kerasiotis et al. 2010, Nguyen et al. 2011]. Em comum a esses trabalhos, a preocupação em definir modelos que representem os efeitos da Taxa de Capacidade (Rate Capacity Effect) e o de Recuperação (Recovery Effect), inerentes às baterias. De uma forma simplificada, o Efeito Taxa de Capacidade representa o comportamento não-linear da bateria quando submetida à diferentes descargas de corrente; enquanto o Efeito Recuperação representa a habilidade da bateria em se recuperar quando está ociosa ou submetida à cargas baixas. Estudos na literatura [Rakhmatov et al. 2002, Li et al. 2013] apontam a existência de diferenças nos tempos de vida das baterias, decorrentes desses efeitos, conforme a ordem escolhida pelos nodos na execução de suas tarefas. Neste artigo é investigado, no contexto das RSSF, o tempo de vida dos nodos, conforme a escolha das atividades de transmissão e recepção de dados, além de atividades de processamento. O objetivo é mostrar os efeitos da Taxa de Capacidade e Recuperação nas baterias sob o ponto de vista do escalonamento de sono dos nodos da rede. Este artigo está organizado da seguinte forma. A Seção 2 trata sobre os conceitos básicos envolvidos neste trabalho. A Seção 3 mostra algumas definições com relação ao modelo utilizado. A Seção 4 apresenta as simulações realizadas, bem como alguns resultados preliminares obtidos neste trabalho. Na Seção 5, apresentam-se as considerações finais sobre os assuntos discutidos neste artigo. 2. Fundamentação Teórica Esta seção tem como objetivo abordar alguns conceitos importantes que estão diretamente ligados ao conteúdo deste artigo. Inicialmente, abordam-se as questões básicas sobre baterias, tal como funcionamento e caracterı́sticas fı́sicas. Em seguida, são vistos os conceitos sobre modelos de baterias conhecidos na literatura. Por fim, é feita uma revisão sobre escalonamento de tarefas em nodos. 56 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 2.1. Conceitos sobre Baterias As baterias são fundamentais nos dias de hoje, sem as quais, o conceito de mobilidade não existiria. Basicamente, baterias são dispositivos que contêm uma ou mais células eletroquı́micas capazes de transformar energia quı́mica em energia elétrica. As células são formadas por dois terminais (eletrodos): o positivo (ou cátodo) e o negativo (ou ânodo). Um eletrólito permite o fluxo de ı́ons entre os terminais da bateria. + - V Ânodo Cátodo e- Eletrólito Figura 1. Modo de funcionamento de uma bateria. De forma geral, ao descarregar uma bateria, ocorre a oxidação do ânodo, gerando elétrons (que fluem pelo circuito externo) e ı́ons carregados positivamente (que, por difusão, movem-se pelo eletrólito em direção ao cátodo). Reações de redução ocorrem no cátodo, gerando ı́ons carregados negativamente. A Figura 1 ilustra o funcionamento de uma bateria simples. Além disso, cada bateria tem duas caracterı́sticas próprias: VOC é a voltagem em circuito aberto, ou seja, a carga total armazenada na bateria sem a presença de nenhuma corrente de descarga; e Vcut é o limite que indica quando a bateria está descarregada. Dois parâmetros importantes são a capacidade teórica, que especifica qual a quantidade de carga máxima que uma bateria suporta, e a capacidade atual, que estabelece a quantidade de energia que uma bateria entrega sob uma determinada carga [Lahiri et al. 2002]. Existem diversos tipos de tecnologias de baterias recarregáveis: Ni-Cd (Nı́quelCádmio), Ni-MH (Nı́quel-Hidreto Metálico), Li-ion (Íons de Lı́tio), Li-polymer (Lı́tiopolı́mero). A tecnologia Ni-Cd foi amplamente utilizada em diversos dispositivos eletrônicos (celulares e laptops, principalmente) devido ao seu baixo custo, entretanto, perdeu espaço devido à baixa capacidade de carga e ao “efeito memória1 ”. A tecnologia Ni-MH tem densidade de energia duas vezes maior que a tecnologia Ni-Cd, porém, tem menor ciclo de vida, é mais cara e ineficiente com altas taxas de descarga. A bateria Liion é uma das mais utilizadas na atualidade, contando com maior densidade de energia e ciclo de vida cerca de duas vezes maior que as baterias Ni-MH. Por outro lado, tem maior sensibilidade a correntes de descarga e é mais cara que a tecnologia Ni-MH. Por fim, as baterias Li-polymer são tão eficientes quanto a tecnologia Li-ion e ainda possuem um invólucro flexı́vel, o que as tornam adequadas para uso em dispositivos móveis com tamanho e peso reduzidos [Lahiri et al. 2002]. 1 Diminuição da capacidade de carga com o passar do tempo. 57 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 2.1.1. Efeitos intrı́nsecos Existem dois efeitos que estão presentes em qualquer bateria, independentemente da tecnologia utilizada: Efeito da Taxa de Capacidade (Rate Capacity Effect) e Efeito Recuperação (Recovery Effect). Tais efeitos são muito importantes para o tempo de vida e a capacidade de uma bateria. • Efeito Taxa de Capacidade: está relacionado à dependência entre a capacidade atual da bateria e a magnitude da corrente de descarga. Neste caso, ao aplicar altas correntes de descarga, a capacidade da bateria é significativamente reduzida. • Efeito Recuperação: refere-se à habilidade que as baterias têm de recuperar parte de sua capacidade nos intervalos que deixa de receber cargas (correntes) externas. Dessa forma, indica-se que sejam inseridos perı́odos ociosos entre as cargas para que a bateria tenha um maior tempo de vida [Li et al. 2013]. 2.2. Modelos de Baterias As questões energéticas são de extrema importância no contexto das RSSF, uma vez que o tempo de vida da rede depende das baterias individuais dos nodos que dela participam. É desejável que cada nodo maximize seu tempo de vida, podendo contribuir com a rede pelo maior perı́odo possı́vel. Em um exemplo simples, onde um conjunto de nodos realiza o sensoriamento de uma determinada área, a falha de um nodo, por ter a sua bateria exaurida, pode enfraquecer a precisão dos dados coletados naquela área especı́fica. Isso prejudica a cobertura espacial da rede, tornando a captura de dados presente em apenas alguns locais e inexistente em outros. Dessa forma, o estudo de técnicas que permitam o aumento no tempo de vida de baterias é contı́nuo, reforçando a busca por novas tecnologias, algoritmos mais eficientes e modelos de bateria mais precisos. 2.2.1. Modelos de Bateria Analı́ticos Os modelos de bateria analı́ticos são fundamentações matemáticas baseadas em equações que buscam considerar as caracterı́sticas fı́sicas das baterias. Servem para estimar, conforme a carga aplicada, o tempo de vida das baterias. Esses modelos descrevem a bateria de forma abstrata, porém, suas propriedades são modeladas utilizando apenas algumas equações [Jongerden and Haverkort 2008a]. Por envolverem a avaliação de expressões analı́ticas, tornam-se computacionalmente flexı́veis [Schneider et al. 2001]. Ou seja, é possı́vel utilizar correntes como uma função de carga constante ou variável, ou alterar o tipo de bateria. Além disso, podem modelar os efeitos eletroquı́micos inerentes às baterias, tais como o Efeito Recuperação e o Efeito da Taxa de Capacidade. O modelo mais simples é a Lei de Peukert. Ele considera parte dos efeitos não lineares, relacionando o tempo de vida da bateria com a taxa de descarga. Porém, o Efeito Recuperação não faz parte do modelo. Assim, os resultados obtidos com a Lei de Peukert são considerados bons apenas para cargas contı́nuas constantes, sendo inadequado quando cargas variáveis ou interruptas são usadas [Jongerden and Haverkort 2008a]. Em [Rakhmatov and Vrudhula 2011], os autores introduzem um novo modelo que descreve o processo de difusão do material ativo na bateria. Esse modelo permite estimar 58 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 o tempo de vida da bateria, com uma boa aproximação, para uma dada corrente de descarga utilizando os dez primeiros termos de uma soma infinita. 1-c c h2 h1 j i I k Carga Limite Carga Disponível Figura 2. Kinect Battery Model (KiBaM) [Manwell and McGowan 1993]. Outro modelo analı́tico é o KiBaM [Manwell and McGowan 1993]. Este modelo abstrato é bastante intuitivo, sendo composto por dois tanques onde a carga da bateria é distribuı́da, conforme ilustra a Fig. 2. O tanque Carga Disponı́vel fornece energia ao dispositivo ligado diretamente à bateria. Já o tanque Carga Limite fornece carga ao tanque Carga Disponı́vel. Entretanto, a taxa a qual ocorre a transferência de carga depende da diferença entre as alturas das cargas nos dois tanques (h1 e h2 ), além do parâmetro k. O parâmetro c indica uma fração da carga total (inserida no tanque Carga Disponı́vel) encontrada na bateria [Jongerden and Haverkort 2008a]. Ao consumir uma corrente I, a bateria reduz sua carga disponı́vel, aumentando a diferença entre as alturas nos dois tanques. Caso o consumo da corrente seja interrompido, inicia-se o fluxo de carga entre o tanque Carga Limite e Carga Disponı́vel até que a altura h1 seja novamente igual à altura h2 . Assim, durante um perı́odo ocioso, a bateria pode aumentar sua capacidade e, consequentemente, manter-se ativa por mais tempo. O fluxo entre os tubos é dado pelo sistema de equações diferenciais mostrado na Equação 1. ( di dt dj dt = −I + k(h2 − h1 ), = −k(h2 − h1 ), (1) tendo como condições iniciais: i(0) = c·C e j(0) = (1−c)·C, onde C representa a capacidade total da bateria. Além disso, h1 = i/c e h2 = j/(1−c). Tal sistema de equações pode ser resolvido utilizando transformadas de Laplace [Jongerden and Haverkort 2008b]. A Equação 2 mostra como calcular a quantidade de carga nos dois tanques. 0 0 i = i e−k0 t + (y0 k0 c−I)(1−e−k t ) − Ic(k0 t−1+e−k t ) 0 k0 k0 0 j = j e−k0 t + y (1 − c)(1 − e−k0 t ) − I(1−c)(k0 t−1+e−k t ) , 0 0 (2) k0 onde k 0 é definido como: k0 = k , c(1 − c) sendo i0 e j0 , respectivamente, as quantidades de Carga Disponı́vel e Limite nos tanques, no tempo t = 0. Para y0 (carga total), tem-se: y0 = i0 + j0 . O KiBaM foi desenvolvido para modelar baterias Ácido-Chumbo. Segundo [Jongerden and Haverkort 2008a], tal modelo não é adequado para baterias modernas utilizadas em dispositivos móveis, como as baterias Li-ion. Por outro lado, se o interesse recai apenas no tempo de vida da 59 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 bateria, o KiBaM pode ser utilizado, uma vez que descreve adequadamente tanto o Efeito da Taxa de Capacidade quanto o Efeito Recuperação. 2.2.2. Modelos de Bateria Estocásticos Segundo [Jongerden and Haverkort 2008a], os primeiros modelos de bateria estocásticos foram desenvolvidos por Chiasserini e Rao, entre 1999 e 2001. Tais modelos são baseados em Cadeias de Markov com Tempo Discreto e produzem uma boa descrição qualitativa do comportamento da bateria sob pulsos de descarga. Entretanto, o modelo proposto por Chiasserini considera apenas o Efeito Recuperação, não conseguindo lidar com perfis de carga arbitrários com descargas de corrente variável (Efeito da Taxa de Capacidade). Em 2005, [Rao et al. 2005] propôs um modelo de bateria, também utilizando Cadeias de Markov, baseado no modelo analı́tico KiBaM [Manwell and McGowan 1993]. No entanto, a formulação foi alterada para baterias Ni-MH, comumente utilizadas em nodos de uma RSSF. Os resultados experimentais deste modelo indicam que o tempo de vida da bateria de Ni-MH depende da frequência da carga aplicada, o que não ocorre no KiBaM original (para escalas de tempo menores que 30 minutos). A solução envolve fazer com que a probabilidade de recuperar capacidade durante perı́odos ociosos dependa do tamanho do perı́odo [Jongerden and Haverkort 2008a]. 2.3. Técnicas de Escalonamento Escolher a ordem na qual as tarefas2 devem ser realizadas em um nodo influencia a taxa de descarga da sua bateria, pois a submete à diferentes correntes, ativando os seus efeitos inerentes, tais como o Efeito Recuperação e o Efeito da Taxa de Capacidade. Algumas tarefas consomem mais energia que outras, exigindo mais corrente ou levando mais tempo para concluir. A escolha da ordem de execução das tarefas é chamada de escalonamento de tarefas ou escalonamento do sono. Apesar das pesquisas no escalonamento de tarefas já terem bem mais do que uma década, um desafio que ainda necessita ser superado é o de como escolher a ordem de execução das tarefas de forma que o tempo de vida das baterias seja maximizado [Panigrahi et al. 2001, Rakhmatov et al. 2002, Nguyen et al. 2011, Li et al. 2013]. Em [Rakhmatov et al. 2002], apresenta-se um exemplo demonstrando o impacto do sequenciamento de tarefas para a bateria do nodo. Uma conclusão desse trabalho é que o tempo de vida da bateria é maximizado quando as tarefas são escolhidas de forma que haja um decrescimento nas cargas de corrente das tarefas. Ou seja, enquanto a bateria tem mais carga, as tarefas do nodo que consomem mais carga são escolhidas primeiro. À medida que a capacidade da bateria do nodo é reduzida, as tarefas que consomem menos carga são as escolhidas para executar. Em [Li et al. 2013], apresenta-se a formulação do problema através de um simples exemplo para transmissão de pacotes em aplicações de tempo real brandas (soft real-time). Além disso, esse trabalho propõe um algoritmo de otimização local ciente de bateria que insere perı́odos ociosos entre tarefas adjacentes, tirando proveito do Efeito Recuperação. Com isso, o objetivo é minimizar o consumo de carga total do sistema. 2 O termo tarefa se refere a qualquer atividade do nodo que necessite de carga da bateria. 60 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 3. Modelo Esta seção apresenta o modelo de bateria utilizado nas simulações. Com relação ao ambiente de simulação, utiliza-se o GNU Octave [Eaton 2014]. Por se tratar de uma linguagem interpretada de alto nı́vel, bem estabelecida e voltada para cálculo numérico, a implementação de modelos matemáticos é facilitada. Como visto na Seção 2.2, existem diversos modelos de bateria, cada um com suas caracterı́sticas. O objetivo deste trabalho é observar o aumento no tempo de vida de uma RSSF quando o Efeito Recuperação faz parte da rotina dos nodos nesta rede. Além disso, deseja-se simular adequadamente o Efeito da Taxa de Capacidade quando diferentes cargas são aplicadas nas baterias dos nodos da rede. Diante desses motivos, um dos modelos de bateria que se encaixa no perfil descrito é o KiBaM. Tal modelo aborda com certa simplicidade e grande abstração os conceitos caracterı́sticos de uma bateria através da Equação 2. Utiliza-se uma função, denominada kibam, que é chamada sempre que um nodo necessita executar uma tarefa (ou um conjunto de tarefas). O Algoritmo 1 descreve de forma simplificada o funcionamento da função. Algoritmo 1: Função KiBaM 1 2 3 4 5 6 7 8 9 Entrada: y0, i0, j0, I, timeInit, period Saı́da: y0 inı́cio initializeConstantsAndVariables(); enquanto t ≤ (timeInit + period) faça compute-i(y0, i0, j0, I, t); compute-j(y0, i0, j0, I, t); saveOutput(i, j, t); fim updateVariables(); fim De acordo com o Algoritmo 1, a função KiBaM tem parâmetros relacionados ao nodo que lhe invoca. Com isso, é possı́vel definir a capacidade atual da bateria do nodo, sua tarefa e seus perı́odos de funcionamento. Neste caso, y0 é a capacidade teórica da bateria, i0 é a quantidade de carga no tubo Carga Disponı́vel, j0 é a quantidade de carga no tubo Carga Limite, I é a corrente aplicada pela tarefa, timeInit é o tempo de inı́cio da simulação e period é o tempo de execução da tarefa. O núcleo dessa função está no cálculo do conteúdo dos tubos Carga disponı́vel (i) e Carga Limite (j) (linhas 4 e 5, respectivamente). Para isso, utilizam-se as definições encontradas na Equação 2. Por fim, o estado de cada tubo da bateria é salvo em um arquivo à parte para análises e geração de gráficos (linha 6). 4. Resultados Esta seção visa apresentar as simulações realizadas e os resultados preliminares desta pesquisa. O objetivo das simulações é fazer que o nodo execute até que a carga em sua bateria seja esgotada (ou alcance um valor mı́nimo predeterminado, cutoff ). O nodo é alimentado por uma bateria com capacidade teórica de 1000 mAh (ou 3600 As) e conta com um conjunto de tarefas para executar, bem como seus respectivos tempos de execução. 61 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Tabela 1. Cargas utilizadas nas simulações. Tarefa Carga (mA) Tempo de execução (min) A B C 40 20 5 10 5 0 − 20 O conjunto de tarefas utilizadas em todas as simulações é composto por três tarefas (Tabela 1). A primeira, denominada de A, tem consumo de 40 mA e executa por 10 min. A segunda, B, consome 20 mA e tem tempo de execução igual a 5 min. Por fim, a terceira, C, consome 5 mA e é executada por tempos variando entre 0 − 20 min, de acordo com a simulação. Sob o ponto de vista do nodo, tais tarefas equivalem, por exemplo, à uma aplicação de monitoramento ambiental. Neste contexto, a Tarefa A representa o processamento contı́nuo por um determinado tempo (10 min) realizado por um nodo, correspondendo a uma leitura de sensor, um pequeno processamento local e transmissão do resultado para outro nodo. A Tarefa B equivale ao perı́odo que o rádio receptor fica ligado à espera de novas comunicações de outro nodo. Finalmente, a Tarefa C representa um perı́odo ocioso (sleep mode) que o nodo tem para fazer valer o Efeito Recuperação em sua bateria. A função KiBaM é usada para calcular a quantidade de carga consumida na bateria quando o nodo executa sua tarefa atual. Assim, a capacidade da bateria é reduzida conforme a carga (corrente) aplicada ao realizar uma tarefa (Efeito da Taxa de Capacidade). Caso o nodo entre no sleep mode, o KiBaM é responsável por modelar o ganho de capacidade na bateria do nodo (Efeito Recuperação). Utilizam-se os seguintes valores para as constantes da Equação 2: k = 10−5 e c = 0, 625. Carga Disponível (As) Os resultados das simulações são mostrados em gráficos que descrevem a descarga no tubo Carga Disponı́vel do nodo. Quatro cenários de uso são empregados para ilustrar diferentes situações de execução das tarefas do(s) nodo(s). Situação 1 Situação 2 Figura 3. Cenário 1: Nodo sem sleep mode (Situação 1). Nodo com sleep mode de 8 horas (Situação 2). 62 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 4.1. Cenário 1 O Cenário 1 é usado para ilustrar a diferença nos tempos de execução com e sem Efeito Recuperação. Com isso, consideram-se duas situações. A Situação 1 investiga o funcionamento do nodo sem utilizar o sleep mode até que sua bateria alcance o nı́vel de cutoff. Neste caso, o nodo executa apenas a tarefa A. Na Situação 2, o nodo opera normalmente (tal qual a Situação 1) até o momento que entra em sleep mode (em t = 850, aproximadamente). Neste momento, o nodo passa a executar a tarefa C, tirando proveito do Efeito Recuperação por um determinado tempo (8 horas) e, então, retorna à atividade realizada anteriormente, isto é, execução da tarefa A. Carga Disponível (As) Na Figura 3, ao entrar em sleep mode (Situação 2), a bateria do nodo tem maior tempo de vida. Na Situação 1, o nodo consegue operar por um tempo3 de 1200 min (20 horas). Já a Situação 2, com sleep mode de 8 horas, o tempo alcançado é de 1550 min (25, 833 horas) de funcionamento. Poder-se-ia pensar que o nodo deveria ter um tempo de vida de pelo menos 28 horas, afinal, na situação sem o sleep mode seu tempo de vida foi de 20 horas. Porém, ao dormir por 8 horas, o nodo ainda está consumindo energia, mesmo que seja uma carga bastante baixa (5 mA). É possı́vel visualizar esse fenômeno na Figura 3 (Situação 2), onde a bateria do nodo recupera parte de sua capacidade e, em determinado momento, chega a um limite onde não consegue mais se recuperar. A partir desse ponto, é reiniciado o processo de descarga. Situação 1 Situação 2 Situação 3 Situação 4 Figura 4. Cenário 2: Nodo sem sleep mode (Situação 1). Com diferentes tempos em sleep mode (Situação 2, 3 e 4). 4.2. Cenário 2 No Cenário 2, utilizam-se diferentes tempos para o sleep mode. Na primeira situação, o nodo executa a tarefa principal A sem que exista “descanso” para a bateria. Na segunda situação, insere-se a tarefa C com perı́odo em sleep mode igual à metade do tempo de execução da tarefa A, isto é, 5 min. Na terceira situação, além da tarefa A, executa-se a tarefa C pelo tempo de 10 min. Na quarta situação, o perı́odo da tarefa C sobe para 3 O termo “tempo” não se refere ao tempo real, mas sim à uma expectativa decorrente da simulação. 63 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 o dobro do tempo de execução da tarefa A, ou seja, 20 min. O nodo executa de forma cı́clica, isto é, executa sua tarefa principal e, em seguida, entra em sleep mode pelo tempo determinado de acordo com a situação simulada. O processo é reiniciado ao término do sleep mode. A Figura 4 demonstra a execução das situações citadas. De acordo com a Figura 4, a execução com sleep mode (Situações 2, 3 e 4) aumenta os tempos de vida do nodo. Na Situação 1, sem sleep mode, o tempo de vida da bateria é de 1200 min (20 horas). Na Situação 2, que utiliza um ciclo de execução com as tarefa A e C (sleep mode de 5 min), o tempo de duração da bateria sobe para 1455 min (24, 250 horas). Na Situação 3, que executa as tarefas A e C (sleep mode de 10 min), o tempo de vida da bateria alcança 1680 min (28 horas). Por fim, na Situação 4, que executa as tarefas A e C (sleep mode de 20 min), o tempo de vida da bateria alcança 2070 min (34, 5 horas). Tabela 2. Tempos obtidos no Cenário 2. Situação Sleep Mode Tarefa(s) Tempo (min) 1 2 3 4 Não Sim (5 min) Sim (10 min) Sim (20 min) A AC AC AC 1200 (20, 00 h) 1455 (24, 25 h) 1680 (28, 00 h) 2070 (34, 50 h) A Tabela 2 resume os resultados encontrados na simulação. Neste cenário, percebe-se claramente que, ao inserir perı́odos ociosos na realização das tarefas do nodo, ocorre um aumento significativo no tempo de vida da sua bateria graças ao Efeito Recuperação. Comparando as Situações 1 e 3 deste cenário, o aumento no tempo de vida da bateria do nodo é de 40%. No caso da Situação 3, o tempo em sleep mode é igual ao tempo de execução da tarefa A. Ao comparar as Situações 1 e 4, onde o sleep mode equivale ao dobro do tempo de execução da tarefa A, o aumento no tempo de vida da bateria sobe para 72, 5%. 4.3. Cenário 3 No Cenário 3, acrescenta-se outra tarefa (B). O objetivo é verificar a influência da ordem de execução das tarefas para o Efeito Recuperação e, consequentemente, para o tempo de vida da bateria. O nodo executa o conjunto de tarefas mostrado na Tabela 1 em uma determinada ordem e de forma cı́clica. São consideradas seis situações. Tabela 3. Tempos obtidos no Cenário 3. Situação Sleep Mode Ordenação Tempo (min) 1 2 3 4 5 6 Não Sim (10 min) Sim (10 min) Não Sim (10 min) Sim (10 min) {AB} {ACB} {ABC} {BA} {BCA} {BAC} 555 (09, 25 h) 725 (12, 08 h) 750 (12, 50 h) 570 (09, 50 h) 750 (12, 50 h) 750 (12, 50 h) Na Situação 1, o perı́odo em sleep mode não é considerado, sendo admitida a ordem de execução AB. Para a Situação 2, o perı́odo em sleep mode é acrescentado entre 64 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 as tarefas principais, com ordem de excução ACB. Na Situação 3, o perı́odo em sleep mode é deslocado para o fim do ciclo, sendo sua ordem: ABC. Na Situação 4, retirase a tarefa C e a tarefa B é deslocada para o começo do ciclo. Neste caso, a ordem de execução é BA. A Situação 5 passa a considerar o sleep mode, com ordem de execução BCA. Por fim, na Situação 6 o perı́odo em sleep mode é deslocado para o fim do ciclo, com ordem de execução BAC. Os tempos de execução podem ser observados na Tabela 3. É possı́vel notar que a ordem de execução das tarefas pode influenciar o tempo de vida da bateria do nodo. Mais especificamente, nas Situações 2 e 3 existe uma pequena diferença nos tempos obtidos pela simulação. Ao observar as Situações 1 e 4, também é possı́vel perceber uma pequena diferença nos tempos obtidos, sendo que nestes casos não são considerados os perı́odos em sleep mode. Situação 1 4.4. Cenário 4 No Cenário 4, dois nodos são utilizados para verificar a diferença nos tempos de vida de suas baterias com e sem o Efeito Recuperação. Os nodos têm baterias com a mesma capacidade teórica. São consideradas duas situações com diferentes formas de escalonamento. Nodo 1 t (min) Nodo 2 Situação 2 t (min) Nodo 1 t (min) Nodo 2 0 10 Legenda: 20 30 40 50 Executando 60 70 80 90 100 t (min) Sleep Mode Figura 5. Escalonamentos utilizados no Cenário 4. Na Situação 1, cada nodo executa a tarefa A de forma simultânea, sem haver perı́odos em sleep mode. Na Situação 2 adota-se um revezamento entre os nodos: enquanto um nodo executa a tarefa A, o outro nodo entra em sleep mode (execução da tarefa C pelo mesmo tempo da tarefa A, isto é, 10 min), valendo-se do Efeito Recuperação da bateria. Esse ciclo é repetido até que o nı́vel mı́nimo de bateria (cutoff ) em ambos os nodos seja atingido. A Figura 5 mostra um esquema que resume o modo de execução em cada uma das situações descritas anteriormente. Na Figura 6 é ilustrada a execução das situações 1 e 2, além de uma situação denominada de ’∗’. A Situação ’∗’ é equivalente à Situação 2, porém, representa o comportamento de um modelo de bateria que não leva em conta o Efeito Recuperação. Basicamente, ao invés do nodo recuperar a capacidade da bateria no perı́odo ocioso, ele mantém a mesma capacidade da execução anterior para a próxima tarefa. Essa situação é usada na figura para contrastar com a Situação 2 e mostrar o Efeito Recuperação e o tempo adicional que esse efeito acrescenta no tempo de vida da bateria. A bateria na Situação ’∗’ alcança um tempo de vida de 1382, 3 min (23, 03 horas). Esse valor pode ser obtido de forma aproximada através de um simples cálculo. O tubo 65 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Carga Disponível (As) Nodo 1 Nodo 2 Situação 1 Situação 2 Situação * Figura 6. Cenário 4: Nodos sem sleep mode (Situação 1). Nodos intercalados com sleep mode (Situação 2). Nodos intercalados com sleep mode mas sem Efeito Recuperação (Situação ’∗’). Carga Disponı́vel tem capacidade de 625 mAh (ou 2250 As) e a carga executada é de 40 mA. A razão entre esses valores (625 mAh/40 mA) resulta em 15, 625 horas, que equivale ao tempo total caso o nodo executasse continuamente. No entanto, como a situação especı́fica adota uma execução intercalada, é preciso levar em consideração os tempos em que o nodo não executa. Em 1 hora o nodo tem três perı́odos ociosos (neste caso, não há recuperação da bateria). Por conseguinte, em 15, 625 horas, o nodo tem 46, 875 perı́odos ociosos. Como cada perı́odo ocioso tem duração de 10 min, multiplicase a quantidade de perı́odos ociosos; o resultado é 468, 75 min (7, 81 horas). Finalmente, (15, 625 + 7, 81) = 23, 4 horas. De acordo com a Figura 6, observa-se que a Situação 2 aumenta o tempo de vida da rede. No caso da Situação 1, a execução simultânea dos nodos atinge um tempo de 1202 min (20, 03 horas). Nesta situação, o gráfico mostra as execuções sobrepostas dos dois nodos, uma vez que as cargas das baterias no inı́cio da simulação são iguais e a execução não conta com sleep modes. Já na Situação 2, quando a execução adota o revezamento na coleta de dados, a simulação atinge um tempo de 1662, 76 min (27, 71 horas). Isso significa um aumento de 38, 33% no tempo de vida da rede. O gráfico dessa situação mostra que, enquanto um nodo está executando, o outro está em sleep mode, recuperando capacidade em sua bateria no perı́odo disponı́vel. Como visto nos resultados simulados, adotar um sequenciamento (escalonamento de tarefas) inapropriado (sem utilizar o sleep mode, por exemplo) pode drenar a bateria de forma mais rápida. Assim, na medida do possı́vel, deve-se incorporar perı́odos ociosos entre as tarefas. Isso permite que a bateria recomponha parte de sua capacidade, garantindo maior tempo de vida para o nodo. 5. Conclusão O consumo energético dos nodos de uma RSSF é um dos problemas mais pesquisados, devido à necessidade de se manter esse tipo de rede “viva” o maior tempo possı́vel. Através 66 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 da busca por métodos eficientes de economia de energia nos nodos é possı́vel estender o tempo de vida de suas baterias, aumentando o perı́odo ativo da rede como um todo. Prever o perı́odo que ainda resta para um nodo se manter ativo, dependendo da carga de corrente aplicada em qualquer momento, facilita o emprego de técnicas de escalonamento de sono, as quais estendem o tempo de vida da rede, através do Efeito Recuperação. O Cenário 4 mostra um caso simples, com apenas dois nodos. Porém, é possı́vel generalizar esse cenário para representar uma RSSF contendo n nodos, sendo que apenas uma fração desses nodos precisam estar ativos simultaneamente para monitorar o ambiente. Neste caso, poder-se-ia escolher os nodos que tenham maior capacidade em suas baterias para realizar as leituras nos sensores e enviar tais dados para a estação base. Enquanto isso, os outros nodos poderiam recuperar parte da capacidade em suas respectivas baterias. Com isso, acredita-se que o Efeito Recuperação faria grande diferença no tempo de vida da rede. Como trabalhos futuros, novas simulações podem ser realizadas, incluindo mais nodos. Pretende-se integrar a presente modelagem em um ambiente voltado para simulação de RSSF, como o OMNeT++ [OMNet++ Community 2014]. Esta ferramenta conta com um modelo simples de bateria (linear), não representando de forma apropriada os efeitos discutidos neste trabalho. Agradecimentos: Os autores agradecem a CAPES e FCT pelo apoio a este trabalho. Referências Akyildiz, I. F., Su, W., Sankarasubramaniam, Y., and Cayirci, E. (2002). Wireless Sensor Networks: A Survey. Computer Networks, 38(4):393–422. Aqeel-ur-Rehman, Abbasi, A. Z., Islam, N., and Shaikh, Z. A. (2011). A Review of Wireless Sensors and Networks’ Applications in Agriculture. CS&I. Buratti, C., Conti, A., Dardari, D., and Verdone, R. (2009). An overview on wireless sensor networks technology and evolution. Sensors (Basel, Switzerland), 9(9):6869– 96. Eaton, J. W. (2014). GNU Octave. https://www.gnu.org/software/octave/. Gungor, V. and Hancke, G. (2009). Industrial Wireless Sensor Networks: Challenges, Design Principles, and Technical Approaches. IEEE Transactions on Industrial Electronics, 56(10):4258–4265. Jongerden, M. R. and Haverkort, B. R. (2008a). Battery Modeling. Technical report, University of Twente. Jongerden, M. R. and Haverkort, B. R. (2008b). Which Battery to Use? 24th UK Performance Engineering Workshop, pages 76–88. Jurdak, R. (2010). Radio sleep mode optimization in wireless sensor networks. Mobile Computing, IEEE . . . , 9(7):955–968. 67 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Kerasiotis, F., Prayati, A., Antonopoulos, C., Koulamas, C., and Papadopoulos, G. (2010). Battery Lifetime Prediction Model for a WSN Platform. Fourth International Conference on Sensor Technologies and Applications (SENSORCOMM), pages 525–530. Lahiri, K., Raghunathan, A., Dey, S., and Panigrahi, D. (2002). Battery-Driven System Design: A New Frontier in Low Power Design. 15th International Conference on VLSI Design (VLSID’02), pages 261–267. Li, H., Yi, C., and Li, Y. (2013). Battery-Friendly Packet Transmission Algorithms for Wireless Sensor Networks. IEEE Sensors Journal, 13(10):202–207. Manwell, J. F. and McGowan, J. G. (1993). Lead Acid Battery Storage Model for Hybrid Energy Systems. Solar Energy, 50(5):399–405. Nguyen, H. A., Forster, A., Puccinelli, D., and Giordano, S. (2011). Sensor Node Lifetime: An Experimental Study. IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops), pages 202–207. OMNet++ Community (2014). OMNeT++ Homepage. http://www.omnetpp.org. Panigrahi, D., Chiasserini, C., Dey, S., Rao, R., Raghunathan, A., and Lahiri, K. (2001). Battery Life Estimation of Mobile Embedded Systems. 14th International Conference on VLSI Design, pages 57–63. Rakhmatov, D. and Vrudhula, S. (2011). An Analytical High-Level Battery Model for Use in Energy Management of Portable Electronic Systems. IEEE-ACM International Conference on Computer Aided Design (ICCAD), pages 488–493. Rakhmatov, D., Vrudhula, S., and Chakrabarti, C. (2002). Battery-Conscious Task Sequencing for Portable Devices Including Voltage/Clock Scaling. 39th Design Automation Conference, pages 189–194. Rao, V., Singhal, G., Kumar, A., and Navet, N. (2005). Battery Model for Embedded Systems. 18th Internation Conference on VLSI Design held jointly with 4th Internationa Conference on Embedded Systems Designs (VLSID), pages 105–110. Schneider, K. K., Sausen, P. S., and Sausen, A. (2001). Análise Comparativa do Tempo de Vida de Baterias em Dispositivos Móveis a Partir da Utilização de Modelos Analı́ticos. Tendências em Matemática Aplicada e Computacional, 12(1):43–54. 68 32º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Florianópolis - SC II Workshop de Comunicação em Sistemas Embarcados Críticos (WoCCES 2014) Position Paper Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Uma Rede de Compartilhamento de Conteúdo Multimídia em Dispositivos Móveis Baseados na Plataforma Android Felipe Alexandre Oliveira Machado1 , Adriano Viana Pinto1 e Mário Meireles Teixeira1 1 Laboratório de Sistemas Avançados da Web (LAWS) Departamento de Informática – Universidade Federal do Maranhão (UFMA) CEP: 65080-805 – São Luís – MA – Brasil [email protected], [email protected], [email protected] Abstract. Traditionally, P2P networks have used common computers, but more recently, with the widespread use of mobile devices, we note the growing trend of convergence of technologies in these devices, which should be accompanied by P2P networks. This article specifies and implements a P2P network architecture based on mobile devices running on the Android platform. It also developed an application for sharing multimedia content via streaming on this P2P network. Performance tests have shown that the connection speed and video coding rate were important factors on the response time and throughput of the system, and the CPU utilization varied from 20 to 50% depending on these factors. Resumo. Tradicionalmente, redes P2P têm funcionado em computadores, porém mais recentemente, com a disseminação do uso de dispositivos móveis, nota-se a crescente tendência de convergência de tecnologias nesses aparelhos, que deve ser acompanhada pelas redes P2P. Este trabalho especifica e implementa uma arquitetura de rede P2P baseada em dispositivos móveis operando sobre a plataforma Android. É também desenvolvida uma aplicação de compartilhamento de conteúdo multimídia via streaming sobre essa rede P2P. Testes de desempenho demonstraram que a velocidade de conexão e a taxa de codificação de vídeo foram fatores preponderantes sobre o tempo de resposta e a vazão do sistema, tendo a utilização da CPU variado de 20 a 50% conforme esses fatores. 1. Introdução As redes Peer-to-Peer (P2P) já fazem parte do cotidiano de muitas pessoas há mais de uma década. Surgiram inicialmente com o objetivo de compartilhar conteúdo entre usuários sem a necessidade de um servidor central, como no caso do paradigma clienteservidor. As redes P2P evoluíram rapidamente na direção do compartilhamento de conteúdo relacionado a entretenimento, como músicas, vídeos, jogos, etc., sendo frequentemente associadas à pirataria, visto que que muitos usuários compartilhavam, e ainda compartilham, os arquivos armazenados em seus discos sem a devida atenção à questão dos direitos autorais. Com este intuito de compartilhamento de arquivos, surgiram arquiteturas famosas como Napster, Gnutella e Kazaa. Outro uso das redes P2P consiste na utilização de ciclos ociosos das CPUs dos equipamentos conectados à rede, que passam a ser utilizados como nós de uma máquina 71 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 • • • • • • com.playinbuddy.util - Encapsula as classes para resolução de tarefas corriqueiras como conversões de tipos de objetos, definição e gerenciamento de variáveis de escopo da aplicação, funções de callback, etc. com.playinbuddy.players - Encapsula as classes necessárias para a reprodução dos conteúdos de mídia requeridos (áudio e vídeo) nos dispositivos receptores. com.playinbuddy.mediaserver - Encapsula as classes necessárias à implementação das funções cliente/servidor de conteúdo de mídia UPnP. com.playinbuddy.activities - Encapsula as classes que gerenciam a interface com o usuário do aplicativo, além das chamadas aos serviços. com.playinbuddy.objects - Encapsula as classes que representam os objetos manipulados pela aplicação (Dispositivo e Conteúdo de Mídia). com.playinbuddy.adapters - Encapsula as classes que funcionam como adaptadores entre os dados e as visões (GridView, ListView e TabView) utilizadas. A Figura 4 ilustra o diagrama de classes do aplicativo PlayingBuddy desenvolvido: Figura 4. Diagrama de Classes do aplicativo PlayingBuddy No diagrama, observa-se que uma das principais classes é o MediaServer, do qual dependem as três activities (interfaces com o usuário) da aplicação (StartActivity, 79 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 6.3.1 Planejamento dos Experimentos Como cenário, considera-se um aparelho celular da fabricante Motorola modelo Razr i XT890 rodando a versão 4.1.2 do sistema Android e um tablet da fabricante Samsung Galaxy Tab 2 modelo GT-P3110 rodando a versão 4.0.3 do sistema Android, ambos conectados a uma rede Wi-Fi através de um Nano Station M5 que possibilita a limitação do oferecimento de banda. Figura 5. Descoberta de conteúdo multimídia disponível para streaming Como fatores que podem influenciar o resultado do experimento, tem-se a Codificação do vídeo (Fator A), a Velocidade da conexão (Fator B) e o Tipo do dispositivo (Fator C). Para cada fator são definidos dois níveis (valores distintos do fator) resultando em um experimento 23 conforme ilustrado na Tabela 1. 3 Tabela 1. Planejamento fatorial do experimento (2 ). Quanto a codificação de vídeo, H.264 360p e H.264 720p como níveis para este fator representam vídeos com baixa e alta qualidade de imagem, respectivamente. A velocidade de conexão tem níveis definidos por uma rede 802.11b (até 11 Mbps) para redes com baixa taxa de banda e uma rede 802.11n (até 300 Mbps) para redes com alta taxa de banda. Por fim, como níveis para o tipo de dispositivo foram escolhidos, smartphone com capacidade de processamento e resolução de tela mais baixa e tablet com processamento e resolução de tela mais elevada. Cada experimento foi repetido cinco vezes e durou 30 segundos desde o início da reprodução do conteúdo. Importante frisar também que o aplicativo Playinbuddy sempre esteve executando em primeiro plano em cada dispositivo. 81 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Como métricas de desempenho, foram utilizados o tempo de resposta (R), utilização (U), vazão (X) e taxa de erro (E). O tempo de resposta representa o intervalo entre o inicio das solicitações da entidade requisitante e o atendimento destas pela entidade provedora de conteúdo. A taxa de throughput (vazão) define o número de requisições que são atendidas por unidade de tempo. A utilização representa o uso dos processadores disponíveis em cada dispositivo do experimento. Por fim, a taxa de erro define o percentual de pacotes perdidos na rede. As medições foram feitas utilizando-se o utilitário Android Debug Bridge (ADB), que fornece um shell de depuração para o sistema operacional Android através de um cabo USB conectado ao dispositivo ou através de uma porta TCP/IP, permitindo executar em segundo plano comandos de monitoramento, como top e vmstat, enquanto o aplicativo Playinbuddy estiver em execução na tela principal do dispositivo. A coleta de dados se deu em intervalos regulares de 5 segundos. O sistema operacional Android fornece a maioria das estatísticas de desempenho nos arquivos de sistema armazenados no diretório /proc e os dados de desempenho são armazenados no diretório /proc/stat. 6.3.2 Resultados e Discussão Esta seção mostra e discute os resultados mais relevantes, assim como a influência dos diferentes fatores A, B e C, individualmente, nos resultados e também das combinações destes sobre as métricas avaliadas conforme mostrado na Tabela 2. Tabela 2. Influência dos fatores no desempenho do aplicativo. Nota-se que a velocidade de conexão (B) é o fator mais influente sobre o tempo de resposta, com percentual de 56,05% e também é responsável por parte importante da vazão (variação de 31,39%), juntamente com a taxa de codificação do vídeo (A), com influência de 27,64%, o que leva a uma influência conjunta desses dois fatores (AB) da ordem de 26,74% na vazão do sistema. A codificação do vídeo tem influência importante sobre a utilização da CPU (26,42%), a qual também apresenta certa dependência do tipo do dispositivo (10,71%), principalmente quando considerada conjuntamente com a codificação de vídeo (22,73%). O tipo do dispositivo (C) teve pouca influência nas métricas avaliadas quando considerado individualmente. Destacase também a influência da combinação dos fatores A e B em todas as variáveis de resposta (linha qAB). Os percentuais de dependência obtidos para o erro (E) não têm muita relevância devido ao fato do erro aferido ter sido muito pequeno. 82 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 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 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 A rede P2PDroid, no seu estágio de desenvolvimento atual permite a descoberta e interconexão de dispositivos portáteis baseados em Android, em uma rede P2P não dependente de uma infraestrutura Wi-Fi. Além disso, permite a transferência de arquivos de dados entre os dispositivos conectados. Como exemplo de aplicação, foi desenvolvida sobre o P2PDroid uma solução de compartilhamento de recursos multimídia por streaming. Esta aplicação, denominada PlayingBuddy utiliza o protocolo UPnP para a troca efetiva do conteúdo multimídia e a rede P2PDroid serve como meio de interconexão dos dispositivos. A descoberta dos dispositivos se dá de forma rápida e instantânea e é possível tocar músicas e assistir a vídeos em outros dispositivos de forma contínua, sem necessidade de baixar o conteúdo para o dispositivo local. Testes de desempenho realizados demonstraram que a aplicação PlayingBuddy opera em diferentes tipos de dispositivo, a variadas taxas de codificação de mídia e tem um impacto de até 50% na utilização da CPU dos dispositivos envolvidos. Como trabalhos futuros, pretende-se produzir uma versão do aplicativo PlayingBuddy baseada no protocolo Wi-Fi Direct e desenvolver outros tipos de aplicações sobre a rede P2PDroid. Referências Android Developers. Acesso em 03 de Setembro de 2013, em:http://developer. android.com/guide/topics/connectivity/wifip2p.html disponível Bubblesoft UPnP server. Acesso em 01 de janeiro de 2014, disponível em: . http://www. bubblesoftapps.com/bubbleupnpserver/. Digital Living Network Alliance (DLNA). Acesso em 03 de Setembro de 2013, disponível em: http://www.dlna.org/. Dynamic Airserver 5.0. Acesso em 03 de dezembro de 2013, disponível em: http://www. airserver.com/. Machado, F. A. O. Aplicações Seguras Sobre Uma Rede Peer-To-Peer Baseada na Plataforma Android, Monografia de Graduação. UFMA, 2013. Open Handset Alliance (OHA). Acesso em 03 de Setembro de 2013, disponível em: http://www.openhandsetalliance.com/. Ps3 media server. Acesso em 10 de outubro de 2013, disponível em: http://www. ps3mediaserver. org/. Universal Plug and Play (UPnP). Acesso em 03 de Setembro de 2013, disponível em: http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf. 84 Anais do II Workshop de Comunicação em Sistemas Embarcados Críticos - WoCCES 2014 Índice por Autor B Branco, K.R.L.J.C. .......................17, 41 C Callegaro, R. ........................................3 L Lucena Jr., V.F. ..................................24 M Machado, F.A.O. ................................71 Marconato, E.A. .................................41 Montez, C.B. ..................................3, 55 Moraes, R. ............................................3 P Pinto, A.R. ...........................................3 Pinto, A.V. .........................................71 Portugal, P. .........................................55 Q Querino Filho, L.C. ............................17 R Rodrigues, L.M. .................................55 S Silva, G.L.P. .......................................24 Silva, V.J. ...........................................24 T Teixeira, M.M. ...................................71 V Vasques, F. .........................................55 85