Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DOOR BLE

230 views

Published on

A importância do presente projeto prende-se com a atual ausência de sensores de ângulos de abertura de uma porta/janela. As alternativas identificadas no mercado permitem apenas detetar se a porta/janela se encontra aberta ou fechada, não dando outras informações. Além da falta de informação sobre os graus de abertura, os dispositivos atuais acarretam um alto custo de produção, uma vez que são comercializados como parte integrante de um sistema. A solução proposta passa pelo desenvolvimento de um dispositivo BLE de baixo consumo energético e de baixo custo de produção e manutenção, que permita medir com precisão o ângulo de abertura de uma porta, assim como uma aplicação Open Services Gateway initiative (OSGI) que consegue comunicar com os nós sensoriais e distribuir as leituras recolhidas com outros bundles ou aplicações que demonstrem interesse.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

DOOR BLE

  1. 1. Mestrado em Engenharia Informática – Computação Móvel Mobilidade em Sistemas Computacionais DOOR BLE Estudantes: Bruno Horta, David Alecrim e Pedro Casqueiro Professor: Nuno Costa 1 Junho 2018
  2. 2. Abstract A importância do presente projeto prende-se com a atual ausência de sensores de ângulos de abertura de uma porta/janela. As alternativas identificadas no mercado permitem apenas detetar se a porta/janela se encontra aberta ou fechada, não dando outras informações. Além da falta de informação sobre os graus de abertura, os dispositivos atuais acarretam um alto custo de produção, uma vez que são comercializados como parte integrante de um sistema. A solução proposta passa pelo desenvolvimento de um dispositivo BLE de baixo consumo energético e de baixo custo de produção e manutenção, que permita medir com precisão o ângulo de abertura de uma porta, assim como uma aplicação Open Services Gateway initiative (OSGI) que consegue comunicar com os nós sensoriais e distribuir as leituras recolhidas com outros bundles ou aplicações que demonstrem interesse. 2
  3. 3. Índice Capítulo 1 - Introdução 3 1.1. Enquadramento 3 1.2. Motivação 3 1.3. Objetivos 4 1.4. Estrutura 4 Capítulo 2 - Trabalho Relacionado 6 2.1. Produtos relacionados 6 2.2. Projetos 6 Capítulo 3 - Arquitetura 8 3.1 Hardware 10 3.2 Software 12 3.2.1 Software e transmissão Beacon 12 3.2.2 Software e transmissão Pair 14 Capítulo 4 - Implementação 15 4.1 Tecnologias Utilizadas 15 4.1.1 Hardware do Nó Sensorial 15 4.1.2 Firmware do Nó Sensorial 16 4.1.3 Software Bundle OSGI 18 Capítulo 5 - Avaliações e testes 19 5.1. Cenário de testes 19 5.2. Listagem de testes 20 5.3. Avaliação 21 Capítulo 6 - Conclusão e trabalho futuro 28 6.1 Trabalho Futuro 29 6.1.1 Perspetivas 29 6.1.2 Proposta de Solução 29 Capítulo 7 - Referências 30 Manual de Instalação 31 Servidor 31 Sensor 32 Compilação e Instalação do TinyB. 38 1
  4. 4. Instalação do Apache Felix no Raspberry Pi 40 Problemas e resoluções 45 2
  5. 5. Capítulo 1 - Introdução 1.1. Enquadramento Atualmente assiste-se a um crescimento considerável em computação ubíqua em todas as vertentes de produtos sejam estes comerciais ou open source. Um dos principais motivos deste crescimento tem por base a Internet Of Things[2], que pretende trazer uma comunicação transparente entre diferentes dispositivos físicos presentes numa casa, num transporte público, numa paragem de autocarro, numa cidade e de alguma forma conseguir que todos estes terminais consigam comunicar entre si. Para tal comunicação suceder têm que existir meios de transmissão de dados wireless/cabo que consigam com qualidade e com eficiência transmitir estes dados de uns terminais para os outros, bem como protocolos leves e abertos. Aqui entram os standards de comunicação existentes para executar a comunicação nestas redes, como o Bluetooth, que desde 1998 é uma forma de comunicação oficial. O Bluetooth é uma tecnologia de transmissão de dados de curto alcance que transmite na banda ISM entre 2.4GHz e 2.485GHz.[3] Outro standard é o IEEE 802.11 que permite executar transmissão de dados wireless numa rede local em diferentes frequências como 900MHz, 2.4GHz, 3.6GHz, etc.[4] Estes standards são já algo antigo tendo em conta a data da sua adoção. Recentemente, em 2010 surge a versão 4.0 com novo conceito de comunicação denominada de Bluetooth Low Energy, ou BLE como sigla, que comparativamente ao seu antecessor, consome menos energia e acrescenta uma arquitectura baseada em serviços e características, ainda face ao anterior este dispensa a necessidade de emparelhamento entre os terminais para troca de mensagens.[3] 1.2. Motivação No mercado de segurança existem alguns exemplos de produtos em kit que englobam como parte integrante um sensor que permite detectar se uma porta está aberta ou fechada. No entanto estes kits são relativamente caros, devido a fazerem parte de um sistema de segurança complexo. Estes sistemas por norma são fechados e não comunicam com outros sistemas externos. Existem também protótipos realizados com este intuito mas que ainda estão longe de se converterem em produtos comerciais. 3
  6. 6. Como tal é pertinente conseguir chegar a uma solução de baixo custo que consiga de forma eficiente e eficaz medir com precisão os graus de abertura de uma porta/janela, algo que poderia mais tarde ser integrado em sistemas de segurança. 1.3. Objetivos O objetivo principal deste projeto é desenvolver um dispositivo de baixo consumo energético que utilize Bluetooth Low Energy (BLE) versão 4.0 para comunicar o valor calculado em graus da abertura de uma porta à qual este se encontra afixado. Para tal é pretendido que a comunicação BLE seja suportada em dois modos de transmissão de dados distintos: em modo Beacon e em modo Pair, um que não requer uma conexão permanente e outro que requer trazendo assim algo que o primeiro modo não traz que consiste numa comunicação segura. O segundo objetivo deste projeto é desenvolver uma aplicação baseada na tecnologia Open Services Gateway initiative (OSGI) que comunique com o dispositivo BLE desenvolvido e que consiga mostrar/notificar/publicar os graus de abertura da porta lidos do mesmo. 1.4. Estrutura O primeiro capítulo pretende descrever o estado atual das comunicações em redes locais de curto alcance, o seu custo e a sua eficiência comparativa, assim como indicar a motivação para o projeto que este documento relata. Neste capítulo encontra-se ainda descritos os objetivos do projeto. O segundo capítulo faz um apanhado das diferentes aplicações/soluções existentes que de alguma forma se assemelham ou em objetivos ou em implementação a este projeto. O terceiro capítulo refere a arquitetura da solução proposta. Primeiro de uma perspetiva mais geral, apanhando todas as áreas da solução partindo depois para as arquiteturas mais detalhadas tanto da parte do software como da parte do hardware/firmware necessário para desenvolver a solução proposta. O quarto capítulo descreve a implementação por parte do grupo desta solução, referindo também um manual de utilização para poder replicar os resultados obtidos pelo grupo. O quinto capítulo refere os testes realizados, uma análise sobre os resultados obtidos e ainda possíveis soluções de como resolver alguns casos em que os testes falharam. 4
  7. 7. O sexto capítulo retira conclusões sobre todo o trabalho efetuado considerando também os pontos fracos e fortes e propostas futuras para melhorar a solução obtida com base em toda a investigação realizada durante o processo de desenvolvimento e testes. No final está ainda disponível um manual de instalação onde se pode confirmar todos os passos realizados pela equipa nos diferentes constituintes da solução assim como uma resolução de problemas que surgiram.
 5
  8. 8. Capítulo 2 - Trabalho Relacionado 2.1. Produtos relacionados Xiaomi Door / Window Sensor Atualmente no mercado a marca Xiaomi tem disponível um conjunto de sensores que permitem detectar se uma porta está aberta ou fechada, esta solução utiliza ZigBee para comunicar com um Gateway Wi-Fi, este também disponibilizado pela marca. O preço médio de cada sensor ronda os 19 euros e a Gateway custa cerca de 40 euros. A Xiaomi garante que as baterias duram em média 2 anos, no entanto não existe forma de abrir o equipamento sem danificar para trocar as mesmas após o prazo supra citado. É possível ver a página promocional e informativa do produto no website da marca.[1] 2.2. Projetos Como projetos relacionados, foi analisado um desenvolvido por 3 estudantes do IPLEIRIA, David Safadinho, João Ramos e Roberto Ribeiro, sobre a coordenação do Professor Nuno Costa em 2017. Os investigadores utilizaram um smartphone para simular o sensor BLE e desenvolveram uma aplicação desktop para consumir os dados do sensor. 6 FIG.1 - IMAGEM PROMOCIONAL DO PRODUTO XIAOMI DOOR / WINDOW SENSOR
  9. 9. No entanto do smartphone apenas estavam a utilizar sensor magnético e o acelerómetro. Os resultados foram promissores e como desenvolvimento futuro tinham como perspectiva desenvolver um sensor físico Low Cost e Low Energy de forma a não ser necessário utilizar um smartphone.[5]
 7 FIG.2 - IMAGEM DE REFERÊNCIA DO PROJETO REFERIDO ANTERIORMENTE
  10. 10. Capítulo 3 - Arquitetura A arquitetura da solução proposta assenta em duas componentes distintas: a componente de software e a de hardware. As duas componentes anteriormente citadas vão em conjunto formar a solução final para o projeto que este documento pretende relatar. A solução de software assenta numa framework designada Open Services Gateway initiative (OSGI) e mais especificamente, numa implementação por parte da organização Apache, designada de Felix. A tecnologia OSGI é composta por um conjunto de especificações, uma referência de implementação para cada especificação e um conjunto de testes de aceitação para cada especificação. Todos os elementos anteriores formam um sistema de módulos dinâmicos, que é o objetivo final desta tecnologia: criar um sistema que possa ser alterado, instalando e removendo módulos que acrescentam ou retiram funcionalidades ao sistema global. Estes podem comunicar entre si através de serviços que são registados nos módulos instalados e que registam como dependências outros serviços. Apesar de não ser uma tecnologia muito referenciada no mundo da produção de software, é usada num conjunto amplo de aplicações open source e comerciais, desde aplicações de negócio até aplicações críticas de saúde. Hoje em dia é uma tecnologia que é adoptada para criar soluções em IoT, Smart Homes, aplicações médicas, aplicações automóveis, sistemas de controlo, entre outros. Ao adotar OSGI para criar aplicações, reduz-se a complexidade da solução como um todo, permitindo criar micro aplicações reutilizáveis, facilitando assim também a bateria de testes devido aos sistemas serem modulares. Fazer a implementação torna-se também mais fácil devido à característica de o sistema se manter sempre em funcionamento, mesmo quando se está a desinstalar um módulo ou a instalar um novo.[6] A solução consiste em desenvolver hardware com suporte de comunicação Bluetooth Low Energy (BLE), que possa ser afixado numa porta/janela de forma a calcular os graus de abertura da mesma, disponibilizando assim essa informação para o Bundle OSGI. O dispositivo de hardware denominado de Nó Sensorial suporta dois modos de transmissão: o modo Beacon e o modo Pair. Estes modos e as suas especificidades serão detalhadas no capítulo 3.1 Hardware. A segunda parte da solução consiste em ter uma aplicação OSGI a correr num Raspberry PI para que a aplicação consiga comunicar 8
  11. 11. com o Nó Sensorial e receber as leituras dos graus de abertura da porta tanto no modo Beacon como no modo Pair. As especificações da componente de software serão abrangidas no capítulo 3.2. A figura 3 demonstra a arquitetura geral da solução, onde se pode ver a relação entre os diferentes componentes e como eles interagem um com o outro. 9 FIG. 3 - ARQUITETURA GERAL DA SOLUÇÃO PROPOSTA PAIRBEACON
  12. 12. 3.1 Hardware A solução de hardware assenta num micro controlador ARM desenvolvido pela Nordic, que vem equipado com um rádio de 2.4GHz, o que permite a utilização da tecnologia BLE. Este dispositivo de hardware possui a capacidade de comunicar através de BLE em dois modos: o modo Beacon e o modo Pair. Quando o dispositivo está a transmitir em modo Beacon, os graus de abertura da porta são transmitidos juntamente com o Advertising Data que possui um tamanho de 31 bytes onde são partilhadas outras informações, como por exemplo o ID do dispositivo e o RX Power. Quando o dispositivo está em modo Pair, então a forma de receber os dados altera-se. Primeiro o dispositivo negoceia a ligação, após o sucesso do passo anterior é criado um túnel cifrado em que apenas o transmissor e o receptor podem aceder aos dados. O dispositivo recetor tem que pedir ao emissor quais são os serviços que ele possui, e consequentemente que características é que esses serviços têm. Quando o mesmo encontra o serviço que pretende e a característica desse serviço que ele pretende consumir, então realiza um pedido de leitura/escrita para poder obter os dados do dispositivo transmissor ou escrever para o mesmo. 10 FIG.4 - ARQUITETURA DO MICRO CONTROLADOR NRF51822 DA NORDIC
  13. 13. 11 FIG.6 - ARQUITECTURA DO FIRMWARE FIG.5 - ARQUITECTURA DE COMUNICAÇÃO INTERNA DO NÓ SENSORIAL i2c
  14. 14. Para realizar as leituras magnéticas é utilizada um bússola digital HMC5883L que comunica com o NRF51822 através do protocolo I2C. 3.2 Software A solução de software assenta como já foi mencionado numa aplicação OSGI. No entanto uma particularidade na solução obtida é que esta aplicação OSGI está a correr num Raspberry PI, que possui já o módulo de comunicação BLE incorporado. A biblioteca utilizada para servir de interface entre o software e o modulo BLE é o TinyB. A arquitetura da aplicação assenta em dois módulos ou bundles OSGI cada um com um serviço registado. O primeiro bundle é o bundle transmissor, cujo serviço é responsável por comunicar com o dispositivo BLE que transmite os graus de abertura da porta. Este serviço ao receber os graus da porta vai também publicitar os dados que recebeu para qualquer outro serviço que o tenha registado como dependência. O segundo bundle nesta aplicação é o bundle consumidor que tem também um único serviço registado. Este serviço é responsável por registar o serviço transmissor como dependência e ler os dados que o mesmo transmite de segundo a segundo. Ao ler estes dados, este serviço publica para a consola do sistema os graus recebidos. O serviço do bundle transmissor pode então comunicar de duas formas distintas com o dispositivo BLE referido no capítulo 3.1 Hardware, sendo nos capítulos seguintes referidos os detalhes da comunicação em cada modo. 3.2.1 Software e transmissão Beacon Na figura 7 pode-se ver a relação entre a aplicação OSGI e o dispositivo BLE que transmite as leituras dentro do Adverting Data (31 bytes), que como foi explicado num capítulo anterior estas vão incorporados com outro tipo de informação também disponibilizado pelo modo, ex: ID, POWER TX etc.
 12
  15. 15. 13 FIG. 7 - ARQUITETURA DA APLICAÇÃO OSGI QUANDO EM COMUNICAÇÃO BEACON COM O DISPOSITIVO BLE FIG.8 - EXEMPLO DE DADOS DE ADVERTISING
  16. 16. 3.2.2 Software e transmissão Pair Na figura 9 pode-se verificar a relação entre a aplicação OSGI e o dispositivo BLE que neste caso transmite os graus de abertura da porta em modo Pair, que requer a criação de um canal de comunicação segura entre os dois terminais, o reconhecimento de serviços e características e a leitura consequente das ações anteriores. Este é o modo tradicional de fazer a comunicação entre dois dispositivos, que é o modo como o antecessor do BLE faz a sua comunicação. 14 FIG. 9 - ARQUITETURA DA APLICAÇÃO OSGI QUANDO EM COMUNICAÇÃO DE MODO PAIR COM O DISPOSITIVO BLE. SÃO VISÍVEIS TAMBÉM DETALHES SOBRE A LIGAÇÃO BLE ESTABELECIDA.
  17. 17. Capítulo 4 - Implementação A solução implementada envolve o desenvolvimento de um Nó Sensorial com capacidades de comunicação através de Bluetooth Low Energy e um Servidor OSGI para a leitura dos dados provenientes de cada Sensor, servidor este que corre num Raspberry Pi. 4.1 Tecnologias Utilizadas Como tecnologias foram utilizadas: Linguagem C++ para desenvolvimento de firmware Compilador MBed da Nordic para desenvolver e compilar o firmware SDK BLE da Nordic Micro Controlador ARM NRF51822 Bússola Digital HMC5883L Protocolo I2C para estabelecer a comunicação entre o NRF e a HMC5883L Eagle para desenvolver a PCB 4.1.1 Hardware do Nó Sensorial Para a comunicação, interpretação e processamento de dados, utilizou-se um micro- controlador da Nordic NRF51822. Ligado a este foi utilizada uma bússola digital HMC5883L, todo o sistema é alimentado com uma Coin Cell de 3v 1000mA CR2477T. 15 FIG.10 - NÓ SENSORIAL DESENVOLVIDO
  18. 18. 4.1.2 Firmware do Nó Sensorial O firmware foi desenvolvido em C++, para camada de comunicação foi utilizado o SDK da Nordic e para interpretar os valores da bússola foi necessário rescrever uma biblioteca já existente para Arduino para que fosse capaz de funcionar em ARM com NRF51822. A comunicação entre os dois é realizada através do protocolo I2C.[8,9] O código fonte utilizado para criar estes excertos pode ser encontrado na página do Github do aluno Bruno Horta.[7] 16 FIG.12 - CONSTITUINTES DO NÓ SENSORIAL DESENVOLVIDO FIG.11 - PCB VERSÃO BETA
  19. 19. 17 FIG.12 - PARAMETRIZAÇÃO DA BUSSOLA DIGITAL AZIMUTH FIG.13 - ALGORITMO PARA CALCULAR O AZIMUTH
  20. 20. 4.1.3 Software Bundle OSGI O Bundle foi desenvolvimento em Java, com base num projeto Maven OSGI. Sempre que este inicia, pesquisa por sensores DOOR BLE e assim que encontra um verifica se está em modo Pair, se sim, são pesquisados os serviços e características onde o sensor disponibiliza as leituras. O sensor começa então a notificar os estados com um período de 1 segundo e o Bundle consume os mesmo de forma automática. Para efeitos de teste os resultados estão a ser impressos na consola do Apache Felix.
 18 FIG.14 - POM.XML DA APLICAÇÃO FIG.15 - OUTPUT RESULTANTE DA EXECUÇÃO DO BUNDLE QUE
  21. 21. Capítulo 5 - Avaliações e testes Para garantir que a solução funciona da forma esperada e que cumpre os requisitos mínimos para que se considere uma solução funcional, foram efetuados diversos testes de modo a garantir este mesmo facto. 5.1. Cenário de testes Foi desenvolvida uma mini porta para acoplar o sensor permitindo assim testar em diferentes pontos da terra. Nesta fase a calibração do sensor ainda é por meio de um botão fisico. De forma a calibrar o estado Fechado da porta o utilizador deve fechar a mesma a pressionar o botão, esta acção faz com que o sensor guarde a posição atual como referência de origem, permitindo assim realizar os cálculos necessários quando a porta se movimenta. 19 FIG.16 - CENÁRIO DE TESTE
  22. 22. 5.2. Listagem de testes 1. No estado fechado ausência de falsos positivos. 1.1. Estado a porta totalmente fechada detectar de o leitor após calibrado envia leituras diferentes de 0º. 2. Tempo de obtenção de dados inferior a 1 segundo 2.1. Sempre que a porta altera o seu angulo é expectável visualizar essa alteração no output do bundle num espaço de tempo inferior a 1 segundo. 3. Tempo de reconexão inferior a 2 segundos 3.1. Já com o Bundle a correr o nó sensorial em modo de conexão é desligado e iniciado novamente, neste procedimento é expectável que o bundle volte a enviar dados num espaço de tempo inferior a 2 segundos. 3.2.Já com o Bundle a correr o nó sensorial em modo Beacon é desligado e iniciado novamente, neste procedimento é expectável que o bundle volte a enviar dados num espaço de tempo inferior a 2 segundos. 20 FIG.17 - MEDIÇÃO FISICA
  23. 23. 4. Precisão face ao ângulo real da porta inferior a 5 graus. 4.1. Realizando uma medição física com um transferidor e com a correcta calibração do sensor esperasse obter leituras com um erro inferior ou igual a 5 graus. 5. Funcionamento em portas de metal 5.1.O sensor será colocado numa porta de metal é expectável que as leituras magnéticas realizadas pela bússola digital não sejam interferidas pela composição da porta. 6. Sujeitar o dispositivo a campos magnéticos parasitas 6.1.O sensor será colocado numa porta de madeira e serão realizadas várias leituras umas com um íman perto do sensor e afastando o mesmo, é expectável que as leituras não sejam completamente erráticas. 7. Duração da bateria CR2477 1000mAh superior a 200 dias 7.1. Face ao tempo de entrega do projeto não é possível realizar o teste durante um longo período de dias, no entanto este teste terá como base a medição média de consumo durante a movimentação da porta e o seu estado em standby, o resultado terá apenas bases probabilísticas. 8. Instalação bem sucedida do bundle BLE 8.1. Abrir a consola Web do Apache Felix e instalar o Bundle Door BLE e iniciar o mesmo, é considerado que o Bundle foi instalado com sucesso se este ficar em modo Active. 9. Instalação bem sucedida do ConsumerService 9.1.Abrir a consola Web do Apache Felix e instalar o Bundle que irá consumir o Bundle Door BLE e iniciar o mesmo, é considerado que o Bundle foi instalado com sucesso se este ficar em modo Active e imprimir na consola os leituras geradas pelo Bundle Door BLE. 5.3. Avaliação 1. No estado fechado ausência de falsos positivos. Análise: Sem qualquer tipo de tratamento no código para eliminar ruído, pode-se verificar pelos resultados que existem algumas leituras diferentes de 0º , apesar de serem variações muito pequenas devem ser tratadas para evitar alarmes erráticos de porta aberta. 21
  24. 24. Teste Inicial: FALHOU Possível Resolução: Adicionar um intervalo entre [0,1] para considerar um movimento de porta válido (DEBOUNCE). Decidir se deve ser feito do lado do sensor ou do consumidor. 2. Tempo de obtenção de dados inferior a 1 segundo Análise: Pode-se verificar pelo intervalo entre leituras que se obtém uma variação em menos de um segundo (1527960101842-1527960100867 = 975 milisegundos). 22 TESTE 1 - RUÍDO NAS LEITURAS
  25. 25. Teste Inicial: PASSOU 3. Tempo de reconexão inferior a 2 segundos 3.1 Análise: Ao desligar o sensor da bateria em modo Pair e voltar a colocar, o Bundle OSGI não foi capaz de reconectar novamente ao dispositivo. No entanto ao fazer a reinicialização manual do bundle, este reconectou de imediato. Considera-se que o problema está no modo como o Bundle OSGI lida com falhas de execução. Teste Inicial: FALHOU Possível Resolução: Verificar na documentação se existe forma de o Bundle se auto regenerar face a exceções que podem ocorrer durante a ligação ao Sensor. 3.2 Análise: Ao desligar o sensor em modo Beacon da bateria e voltar a colocar o Bundle OSGI continuou a apresentar as leituras de imediato. Teste Inicial: PASSOU 4. Precisão face ao ângulo real da porta inferior a 5 graus. Análise: Pode-se verificar que o sensor está a ler 94.64º e na realidade o ângulo formado é de aproximadamente 90º, pelo que se conclui que numa montagem mais rigorosa ou com uma bússola de melhor qualidade este erro possa ainda ser menor. 23 TESTE 2 - LATÊNCIA
  26. 26. Teste Inicial: PASSOU 5. Funcionamento em portas de metal Teste não realizado por motivos de ausência de cenário estático de teste. 6. Sujeitar o dispositivo a campos magnéticos parasitas Análise: Pode-se verificar que o sensor sempre que fica exposto a um campo magnético altera de imediato os valores sem que a porta se movimente, pelo que o grupo considera que este é um dos testes mais importantes a nível de segurança, de certa forma pode-se divergir as leituras de forma externa, no caso do smartphone apenas existem anomalias quando este de 5 em 5 segundos faz o scan de rede. Assim que o sensor deixa de estar exposto ao campo magnético volta ao estado normal sem ser necessário recalibração. 24 TESTE 4 - PRECISÃO
  27. 27. Teste Inicial: FALHOU Possível Resolução: Será necessário encontrar uma forma de proteger o Nó Sensorial de campos magnéticos parasitas, por exemplo criar um escudo. 25 TESTE 6 - INTERFERÊNCIA MAGNÉTICA (ÍMAN) TESTE 6 - INTERFERÊNCIA MAGNÉTICA (TELEMÓVEL)
  28. 28. 7. Duração da bateria CR2477 1000mAh superior a 200 dias Análise: Pode-se verificar que o sensor consome em média 2mA, existe uma pequena poupança quando o Bundle OSGI não está a consumir os dados, no entanto se se considerar uma utilização de 24 horas / 360 dias com uma pilha de 1000mA apenas se consegue obter uma autonomia máxima de aproximadamente 20 dias. Teste Inicial: FALHOU Possível Resolução: Será necessário implementar um mecanismo que adormeça o sensor caso este esteja imóvel. Ex: Usar um sensor magnético na porta que caso esta 26 TESTE 7 - CONSUMO ENERGÉTICO (BUNDLE DESCONECTADO) TESTE 7 - CONSUMO ENERGÉTICO (BUNDLE CONECTADO)
  29. 29. esteja fechada o sensor desliga ou encontrar uma bússola digital com sinalização por interrupção para acordar o sensor sempre que existe uma leitura nova. 8. Instalação bem sucedida do bundle BLE Análise: Pode-se verificar que o bundle está correctamente instalado e ativo. Teste Inicial: PASSOU 9. Instalação bem sucedida do ConsumerService Teste não realizado, não foi desenvolvido nenhum Bundle Consumer.
 27 TESTE 8 - CONFIGURAÇÃO
  30. 30. Capítulo 6 - Conclusão e trabalho futuro Neste projeto foi construído um eco sistema composto por um Sensor capaz de medir o ângulo de abertura de uma porta, um servidor que permite instalar Bundles OSGI em Java e ainda foi desenvolvido um Bundle específico para interpretar as leituras do Sensor e disponibilizar as mesmas para outros Bundles no sistema. Concluí-se que o sensor é o pilar central de todo o sistema, daí ter-se investido mais tempo de investigação, desenvolvimento e testes no mesmo de forma a perceber se é possível torná-lo num dispositivo IoT com um baixo consumo, de fácil instalação e acima de tudo estável. A escolha de um micro controlador já com rádio 2.4Ghz com BLE simplificou em muito a tarefa. O Sensor pode ser alimentado apenas com uma Coin Cell de 3V, permitindo assim ficar ligado durante longos períodos de tempo. O Bundle OSGI permitiu fazer a comunicação entre o Sensor e Servidor. O facto de se ter utilizado um sistema de Plugins vai permitir evoluir o sistema de forma simples e dinâmica. Após a correcta configuração do sistema, para poder suportar uma rede distribuída de sensores que podem até estar espalhados em diferentes pontos e a comunicar entre si é possível evoluir para soluções que lançam alertas ou disparam automações. O ambiente de testes montado permitiu tirar várias conclusões sobre a eficácia e qualidade da solução desenvolvida, de facto, com os testes efetuados, pode-se dizer que a solução é efetivamente funcional desde que não esteja exposta a campos magnéticos parasitas. Para aquilo que este projeto propõe como objetivos, que são o de desenvolver um dispositivo BLE de baixo consumo que consiga medir os graus de abertura de uma porta em termos académicos é uma solução possível, no entanto as anomalias magnéticas a que o sensor fica exposto e a falha na auto regeneração do Bundle OSGI deve ser tomada em conta e futuramente devem ser analisadas e testadas soluções que possam efetivamente deixar o sensor imune a entidades externas e com capacidade de auto recuperação. Por último não se chegou a desenvolver um consumidor para o Bundle, pelo que a apresentação das leituras foi directamente realizada no terminal do Apache Felix. Tal escolha prendeu-se com o facto de o grupo achar que não seria um ponto crítico na solução já que o Felix implementa por si só serviços de notificações do tipo PUB/SUB e 28
  31. 31. qualquer aplicação que esteja disposta a obter os dados do sensor BLE pode subscrever ao tópico de interesse. Em suma termina-se com um sistema funcional que permitiu chegar a uma solução BLE integrada com OSGI que pode funcionar muito bem e tornar a integração de um sistema de sensores simples e dinâmica, como também se conclui que uma solução baseada numa bússola que existe à mais de 2 mil anos pode ainda ser a solução para os sensores modernos e trazer mais valias a sistemas de segurança onde quer que estes estejam implementados. 6.1 Trabalho Futuro 6.1.1 Perspetivas 1 - Como prioridade seria interessante desenvolver um escudo que protegesse o sensor de outros campos magnéticos. 2 - De forma a tornar o produto comercial e capaz de ser utilizado por pessoas que nada entendem de tecnologia, seria interessante desenvolver uma Gateway User Friendly em que o utilizador apenas tivesse que a ligar à tomada e interagir com esta via Web. 3 - O Sensor também pode ser melhorado de forma a reduzir o seu tamanho e a forma como é configurado o modo de comunicação. 4- Seria importante terminar algumas funcionalidades que permitem cifrar a informação disponibilizada pelo Sensor de forma a garantir que os valores são de fontes seguras. 5- Ainda relacionado com a segurança, garantir que o Gateway só recebe informações de sensores proprietários e não de sensores fantasma/clones. (Esta implementação apenas faria sentido caso o sistema tivesse como objetivo ser fechado). 6.1.2 Proposta de Solução Desenvolvimento de uma Web App para o Raspberry Pi que permita o utilizador gerir todos os seus Sensores e ainda criar alertas ou automações com base nas leituras dos mesmos.
 29
  32. 32. Capítulo 7 - Referências [1] Página web da Xiaomi para o produto Door & Window sensor, “. [Online]. Disponível: https://xiaomiportugal.com/shop/home/240-xiaomi-mi-smart-home-door- window-sensors.html. [Acedido a: Maio, 31, 2018]. [2] E. Dave, “The Internet of Things - How the Next Evolution of the Internet Is Changing Everything”, Abril, 2011. [Online]. Disponível: https://www.cisco.com/c/dam/en_us/about/ ac79/docs/innov/IoT_IBSG_0411FINAL.pdf. [Acedido a Maio. 30, 2018]. [3] Página web do Bluetooth SIG, Inc, “. [Online]. Disponível: https://www.bluetooth.com/bluetooth-technology/radio-versions. [Acedido a: Maio, 30, 2018]. [4] D. Edgar, “IEEE 802.11 - The Internet Protocol Journal - Volume 5, Number 1”. Cisco, [documento online], 2018. Disponível: https://www.cisco.com/c/en/us/about/press/ internet-protocol-journal/back-issues/table-contents-21/ieee.html [Acedido a: Maio 31, 2018]. [5] Nota: O relatório pode ser consultado no Instituto Politécnico de Leiria, na Escola Superior de Tecnologia e Gestão, sob o cuidado do professor Nuno Costa. [6] Página web da OSGI Alliance, “. [Online]. Disponível: https://www.osgi.org/developer/what-is-osgi. [Acedido a: Maio, 31, 2018]. [7] Página web do repositório do projeto no Github do aluno Bruno Horta, “. [Online]. Disponível: https://os.mbed.com/users/brunohorta/code/DOOR_BLE_PROGRAM/. [Acedido a: Junho, 1, 2018]. [8] V. Josefin, “Detection of breaking and entering using an eCompass”. [documento online], 2018. Disponível: http://bme.lth.se/fileadmin/biomedicalengineering/ Examensarbeten/1505_Voigt__art.pdf [Acedido a: Maio 21, 2018]. [9] V. Josefin, “Angular positioning of a door or window - using a MEMS accelerometer and a magnetometer”. [documento online], 2018. Disponível: http://lup.lub.lu.se/luur/ download?func=downloadFile&recordOId=5276512&fileOId=5276513 [Acedido a: Maio 20, 2018].
 30
  33. 33. Manual de Instalação Hardware Necessário Servidor Raspberry Pi Model B PVP médio - 37€ Transformador 5.1V 2.5A Micro USB PVP médio - 9€ Cartão SD 16GB PVP médio - 37€ 31
  34. 34. Caixa Protectora (Opcional) PVP médio - 9€ Sensor Micro-controlador ARM NRF51822 2.4G PVP médio - 2,5€ Bussola Digital HMC5883L 32
  35. 35. PVP médio - 1,5€ CR2477 Battery Holder PVP médio - 0,6€ Bateria CR2477T 3V PVP médio - 3€ Switch PVP médio - 0,1€ PCB para montagem 33
  36. 36. PVP médio - 0,6€ Software necessário: Imagem do S.O. Raspbian Stretch Lite https://www.raspberrypi.org/downloads/raspbian/ Software ETCHER para gravação da Imagem do S.O no cartão SD https://etcher.io Apache Felix http://felix.apache.org/downloads.cgi TinyB https://github.com/intel-iot-devkit/tinyb Source http://iotdk.intel.com/docs/master/tinyb/java/ Documentation 34
  37. 37. Instalação do Sistema Operativo Raspbian Utilizar o ETCHER para gravar a imagem. 1. Selecionar o ficheiro 2018-04-18-raspbian-stretch-lite.img da pasta para onde foi transferido 2. Escolher o Cartão SD previamente inserido no adaptador de cartões Carregar em FLASH e aguardar que a imagem seja gravada no cartão e posteriormente verificada. Após a conclusão do processo, antes de retificar o cartão vamos acrescentar um ficheiro extra que vai permitir ter acesso via SSH ao Raspberry. “Em alguns equipamentos é necessário retirar o cartão do leitor e voltar a inserir para que seja reconhecido pelo SistemaS” 35
  38. 38. 1. Criar um ficheiro vazio e sem extensão e gravar o mesmo na Raiz do cartão 2. Colocar o cartão do Raspberry Pi ligar o cabo de Rede e o Transformador. 3. Após alguns minutos o sistema fica pronto para realizar o Login, nesta fase podemos aceder ao sistema do Raspberry por SSH a partir do nosso computador. Este método torna todo o processo mais rápido porque podemos copiar os links e comando do Browser Web e colar directamente no cliente SSH. Preparação do Cliente SSH Em sistemas Linux/Mac o utilizador apenas tem que abrir um terminal de escrever o comando: ssh pi@raspberrypi.local Ao pressionar a tecla Enter vai ser pedida a password default que é: raspberry Após a correcta inserção ficarmos na prompt do sistema. Em sistemas Windows o utilizador tem de utilizar o Putty para realizar conexões SSH. PuTTY https://www.putty.org 36
  39. 39. 37
  40. 40. Compilação e Instalação do TinyB. O TinyB é uma excelente biblioteca que nos permite de forma simples interagir com o Bluetooth. No entanto é necessário compilar o código fonte para a arquitectura alvo. No processo de compilação podemos ainda decidir se queremos que o output seja em C ou Java. No nosso caso queremos que a arquitectura seja ARM e que o Output seja Java. Para a arquitectura apenas temos que compilar o código fonte no Raspberry e automaticamente o cmake coloca como target o ARM, para ser que possam ser gerados os ficheiros em Java temos de usar a flag -DBUILDJAVA=ON Vamos abrir outro terminal ou outro cliente PuTTY no caso de estar a utilizar Windows e estabelecer novamente a ligação SSH com o Raspberry. 1. Fazer download do código fonte do TinyB Instalar o Git para descarregar o código fonte pi@raspberrypi:~ $ sudo apt-get install git Descarregar o código fonte pi@raspberrypi:~ $ git clone https://github.com/intel-iot-devkit/tinyb.git Atualizar o sistema pi@raspberrypi:~ $ sudo apt-get update Instalar dependências necessárias pi@raspberrypi:~ $ sudo apt-get install openjdk-8-jdk libglib2.0-dev cmake bluez Especificar o caminho onde está instalava a VM Java pi@raspberrypi:~ $ export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-armhf/ 38
  41. 41. Entrar dentro do diretório que contem o código fonte pi@raspberrypi:~ $ cd tinyb/ Criar um diretório com o nome build para receber o resultado da compilação pi@raspberrypi:~/tinyb $ mkdir build Navegar para dentro do directorio build pi@raspberrypi:~/tinyb $ cd build/ Executar o campe para gerar o ficheiros de compilação pi@raspberrypi:~/tinyb/build $ sudo -E cmake -DBUILDJAVA=ON - DCMAKE_INSTALL_PREFIX=/usr .. Compilar o código fonte pi@raspberrypi:~/tinyb/build $ sudo make Instalar o TinyB pi@raspberrypi:~/tinyb/build $ sudo make install Teste da instalação pi@raspberrypi:~/tinyb/build $ sudo java -cp examples/java/HelloTinyB.jar:/usr/lib/lib/ java/tinyb.jar HelloTinyB 0 The discovery started: true Address = 3C:15:C2:C4:10:0F Name = 3C-15-C2-C4-10-0F Connected = false Address = 08:66:98:8D:AA:65 Name = 08-66-98-8D-AA-65 Connected = false Address = 2C:FA:92:B6:D8:E3 Name = 2C-FA-92-B6-D8-E3 Connected = false Address = 75:23:4A:24:2C:47 Name = 75-23-4A-24-2C-47 Connected = false 39
  42. 42. Instalação do Apache Felix no Raspberry Pi Navegar para a Home do utilizar pi pi@raspberrypi:~ $ cd~ Fazer download da ultima distribuição utilizando o link copiado na imagem acima p i @ r a s p b e r r y p i : ~ $ w g e t h t t p : / / m i r r o r s . u p . p t / p u b / a p a c h e / / f e l i x / org.apache.felix.main.distribution-5.6.10.tar.gz Descompactar pi@raspberrypi:~ $ tar xvzf org.apache.felix.main.distribution-5.6.10.tar.gz Navegar para a pasta que contem os binários pi@raspberrypi:~ $ cd felix-framework-5.6.10/ Iniciar o Apache Felix pi@raspberrypi:~/felix-framework-5.6.10 $ sudo java -jar bin/felix.jar ____________________________ Welcome to Apache Felix Gogo g! 40
  43. 43. Comandos uteis para utilizar no Apache Felix help — Mostra todos os comandos disponíveis lb — Lista todos os bundles instalados install — Instala um bundle a partir de um URL uninstall — Desinstala um bundle start — Inicia um bundle stop — Para um bundle Instalação de alguns Bundles extra que vão facilitar a utilização do Apache Felix Event Admin g! install http://mirrors.up.pt/pub/apache//felix/org.apache.felix.eventadmin-1.5.0.jar Configuration Admin g! install http://mirrors.up.pt/pub/apache//felix/org.apache.felix.configadmin-1.9.2.jar HTTP Service Jetty g! install http://mirrors.up.pt/pub/apache//felix/org.apache.felix.http.jetty-4.0.0.jar HTTP Servlet 2.6 + 3.0 API g! install http://mirrors.up.pt/pub/apache//felix/org.apache.felix.http.servlet-api-1.1.2.jar Web Console (all-in-one bundle) g! install http://mirrors.up.pt/pub/apache//felix/org.apache.felix.webconsole-4.3.4-all.jar Listar todos os bundles instalados g! lb   START LEVEL 1 ID|State |Level|Name 0|Active | 0|System Bundle (5.6.10)|5.6.10 1|Active | 1|jansi (1.16.0)|1.16.0 2|Active | 1|JLine Bundle (3.5.1)|3.5.1 3|Active | 1|Apache Felix Bundle Repository (2.0.10)|2.0.10 4|Active | 1|Apache Felix Gogo Command (1.0.2)|1.0.2 41
  44. 44. 5|Active | 1|Apache Felix Gogo JLine Shell (1.0.10)|1.0.10 6|Active | 1|Apache Felix Gogo Runtime (1.0.10)|1.0.10 7|Installed | 1|Apache Felix EventAdmin (1.5.0)|1.5.0 8|Installed | 1|Apache Felix Configuration Admin Service (1.9.2)|1.9.2 9|Installed | 1|Apache Felix Http Jetty (4.0.0)|4.0.0 10|Installed | 1|Apache Felix Servlet API (1.1.2)|1.1.2 11|Installed | 1|Apache Felix Web Management Console (All In One) (4.3.4.all)|4.3.4.all Iniciar todos os bundles instalados “nota os ID’s pode ser diferentes de instalação para instalação” g! start 7 g! start 8 g! start 9 g! start 10 g! start 11 Nesta fase já temos a “Web Management Console” a funcionar, para aceder a mesma devemos abrir o browser e colocar o seguinte endereço: http://raspberrypi.local:8080/system/console Vão ser pedidas as credencias, por defeito o username é admin e a password admin. 42
  45. 45. Depois da correcta autenticação podemos visualizar e gerir o Apache Felix a partir do browser. Instalação do Bundle TinyB no Apache Felix g! install /usr/lib/lib/java/tinyb.jar g! lb START LEVEL 1 ID|State |Level|Name 0|Active | 0|System Bundle (5.6.10)|5.6.10 1|Active | 1|jansi (1.16.0)|1.16.0 2|Active | 1|JLine Bundle (3.5.1)|3.5.1 3|Active | 1|Apache Felix Bundle Repository (2.0.10)|2.0.10 4|Active | 1|Apache Felix Gogo Command (1.0.2)|1.0.2 5|Active | 1|Apache Felix Gogo JLine Shell (1.0.10)|1.0.10 6|Active | 1|Apache Felix Gogo Runtime (1.0.10)|1.0.10 7|Active | 1|Apache Felix EventAdmin (1.5.0)|1.5.0 8|Active | 1|Apache Felix Configuration Admin Service (1.9.2)|1.9.2 9|Active | 1|Apache Felix Http Jetty (4.0.0)|4.0.0 10|Active | 1|Apache Felix Servlet API (1.1.2)|1.1.2 11|Active | 1|Apache Felix Web Management Console (All In One) (4.3.4.all)|4.3.4.all 12|Active | 1|tinyb (0.5.1)|0.5.1 43
  46. 46. O ID atribuido foi o 12 neste caso, para iniciar o Bundle executamos o comando: g! start 12 Podemos ainda verificar na consola Web a Instalação do TinyB Ao clicar sobre ele podemos visualizar ainda mais alguns detalhes. 44
  47. 47. Problemas e resoluções Problema: Após a instalação do Bundle BLE, sempre que é executado dá NULL POINTER EXCEPTION Causa: Aparentemente o Blundle TinyB não consegue inferir a verão correcta do Java. 45
  48. 48. Resolução: Editar o ficheiro BluetoothManager.java. pi@raspberrypi:~/tinyb $ nano /home/pi/tinyb/java/BluetoothManager.java Comentar o bloco de código que verifica a versão do Java. Guardar as alterações e voltar a recompilar pi@raspberrypi:~/tinyb/build $ cd ~/tinyb/ pi@raspberrypi:~/tinyb $ sudo rm -Rf build/ pi@raspberrypi:~/tinyb $ mkdir build pi@raspberrypi:~/tinyb $ cd build/ pi@raspberrypi:~/tinyb/build $ sudo -E cmake -DBUILDJAVA=ON - DCMAKE_INSTALL_PREFIX=/usr .. pi@raspberrypi:~/tinyb/build $ sudo make pi@raspberrypi:~/tinyb/build $ sudo make install 46
  49. 49. Problema: Após o inicio do Bundle BLE este da detecta qualquer Sensor. Causa: O serviço Bluetooth ainda não suporta nativamente o BLE Resolução: Editar o ficheiro de configuração do Serviço Bluetooth e ativar as funcionalidades experimentais. pi@raspberrypi:~/tinyb/build $ sudo nano /lib/systemd/system/bluetooth.service pi@raspberrypi:~/felix-framework-5.6.10 $ sudo cp /home/pi/tinyb/build/src/libtinyb* /usr/ lib/ pi@raspberrypi:~/felix-framework-5.6.10 $ sudo cp /home/pi/tinyb/build/java/jni/ libjavatinyb* /usr/lib/ pi@raspberrypi:~/tinyb/build $ sudo reboot 47

×