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.

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. 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. Í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. Instalação do Apache Felix no Raspberry Pi 40
Problemas e resoluções 45
2

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. 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. 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. 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. 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. 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. 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. 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. 11
FIG.6 - ARQUITECTURA DO FIRMWARE
FIG.5 - ARQUITECTURA DE COMUNICAÇÃO INTERNA DO NÓ SENSORIAL
i2c

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. 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. 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. 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. 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. 17
FIG.12 - PARAMETRIZAÇÃO DA BUSSOLA DIGITAL
AZIMUTH
FIG.13 - ALGORITMO PARA CALCULAR O AZIMUTH

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Caixa Protectora (Opcional)
PVP médio - 9€
Sensor
Micro-controlador ARM NRF51822 2.4G
PVP médio - 2,5€
Bussola Digital HMC5883L
32

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. 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. 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. 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. 37

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