uma plataforma adaptável para localização em ambientes internos
Post on 20-Dec-2016
214 Views
Preview:
TRANSCRIPT
Universidade Federal do Rio Grande do Norte
Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada
Programa de Pós-Graduação em Sistemas e Computação
Mestrado Acadêmico em Sistemas e Computação
Uma Plataforma Adaptável para Localizaçãoem Ambientes Internos
Mário Andrade Vieira de Melo Neto
Natal-RN
Fevereiro/2016
Melo Neto, Mário Andrade Vieira de. Uma plataforma adaptável para localização em ambientesinternos / Mário Andrade Vieira de Melo Neto. - Natal, 2016. 110f: il.
Orientador: Prof. Dr. Gibeon Soares de Aquino Júnior.
Dissertação (Mestrado) - Universidade Federal do Rio Grandedo Norte. Centro de Ciências Exatas e da Terra. Programa de Pós-Graduação em Sistemas e Computação.
1. Engenharia de software. 2. Localização em AmbientesInternos. 3. Adaptabilidade. 4. IndoLoR. I. Aquino Júnior,Gibeon Soares de. II. Título.
RN/UF/CCET CDU 004.41
Catalogação da Publicação na FonteUniversidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Mário Andrade Vieira de Melo Neto
Uma Plataforma Adaptável para Localização em
Ambientes Internos
Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas eComputação do Departamento de Informá-tica e Matemática Aplicada da UniversidadeFederal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau deMestre em Sistemas e Computação.
Linha de pesquisa:Engenharia de Software
Orientador
Prof. Dr. Gibeon Soares de Aquino Jr.
PPgSC � Programa de Pós-Graduação em Sistemas e Computação
DIMAp � Departamento de Informática e Matemática Aplicada
CCET � Centro de Ciências Exatas e da Terra
UFRN � Universidade Federal do Rio Grande do Norte
Natal-RN
Fevereiro/2016
Dedico este trabalho com muito amor, a minha esposa Noelly e minha �lha So�a, que
são o meu porto seguro.
Agradecimentos
Agradeço à DEUS, pois a ele devo tudo.
Agradeço aos meus pais, Mauro e Emília, por todo amor, dedicação e ensinamentos.
Sem eles hoje não estaria aqui.
Agradeço as minhas irmãs, Camila e Marcela, pela torcida, força, amor e por acreditar
que eu seria capaz.
Agradeço a minha esposa, Noelly, pelo incentivo para que eu entrasse no mestrado,
pelo amor, pela compreensão nas horas em que não pude estar presente e pelo meu maior
presente, nossa �lha So�a.
Agredeço ao Prof. Gibeon, o qual considero um amigo, muito obrigado pelos conselhos,
ensinamentos e por acreditar no meu potencial.
Agradeço aos amigos da SINFO, Weksley, Marcelo, Eduardo, Mychell, Lindemberg,
Itamir e Cícero, pela amizade e pelos conselhos.
Agredeço aos meus grande amigos, Marquinhos, Paulo, Tony, Pablo e Adriano, mesmo
distantes �sicamente estão sempre presentes em minha vida.
En�m, à todos que direta ou indiretamente, in�uenciaram na realização deste trabalho.
Eu acredito demais na sorte. E tenho constatado que, quanto mais duro eu trabalho,
mais sorte eu tenho.
Thomas Je�erson
Uma Plataforma Adaptável para Localização emAmbientes Internos
Autor: Mário Andrade Vieira de Melo Neto
Orientador(a): Prof. Dr. Gibeon Soares de Aquino Jr.
Resumo
Os sistemas de localização têm se tornado cada vez mais parte integrante da vida das
pessoas. Em ambientes externos, o GPS se apresenta como tecnologia padrão, largamente
difundida e utilizada. No entanto, as pessoas costumam passar a maior parte do seu tempo
dentro de ambientes internos, como: hospitais, universidades, fábricas, edifícios, entre ou-
tros. Nesses ambientes, o GPS tem seu funcionamento comprometido não obtendo um
posicionamento preciso. Atualmente, para realizar a localização de pessoas ou objetos em
ambientes internos não existe nenhuma tecnologia que consiga atingir os mesmos resul-
tados obtidos pelo GPS em ambientes externos. Devido a isso, é necessário considerar a
utilização de informações provenientes de diversas fontes fazendo uso de diferentes tec-
nologias. Dessa forma, esse trabalho tem como objetivo geral construir uma plataforma
adaptável para localização em ambientes internos. Baseado nesse objetivo, é proposta
a plataforma IndoLoR. Essa plataforma tem como objetivos permitir o recebimento de
informações provenientes de diferentes fontes, além de realizar o processamento, fusão,
armazenamento e disponibilização dessas informações para o contexto da localização em
ambientes internos.
Palavras-chave: Localização em Ambientes Internos, Adaptabilidade, IndoLoR.
An Adaptable Platform for Indoor Location
Author: Mário Andrade Vieira de Melo Neto
Supervisor: Prof. Dr. Gibeon Soares de Aquino Jr.
Abstract
Location systems have become increasingly part of people's lives. For outdoor environ-
ments, GPS appears as standard technology, widely disseminated and used. However,
people usually spend most of their daily time in indoor environments, such as: hospitals,
universities, factories, buildings, etc. In these environments, GPS does not work properly
causing an inaccurate positioning. Currently, to perform the location of people or objects
in indoor environments no single technology could reproduce for indoors the same result
achieved by GPS for outdoors environments. Due to this, it is necessary to consider use
of information from multiple sources using di�erent technologies. Thus, this work aims
to build an Adaptable Platform for Indoor location. Based on this goal, the IndoLoR
platform is proposed. This platform aims to allow information reception from di�erent
sources, data processing, data fusion, data storage and data retrieval for the indoor loca-
tion context.
Keywords : Indoor Location, adaptability, IndoLoR.
Lista de �guras
1 Etapas da metodologia aplicada . . . . . . . . . . . . . . . . . . . . . . p. 21
2 Técnica de posicionamento utilizando a Triangulação (GU; LO; NIEMEGE-
ERS, 2009) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
3 Arquitetura em camadas do OSGi, adaptado de (ALLIANCE, 2015) . . . p. 27
4 OSGi Service Registry (TAVARES; VALENTE, 2008) . . . . . . . . . . . . p. 28
5 Processo de Mapeamento Sistemático da Literatura adaptado de Peter-
sen et Al. (PETERSEN et al., 2008) . . . . . . . . . . . . . . . . . . . . . p. 30
6 Processo de keywording adaptado de Mujtaba et al.(MUJTABA et al., 2008) p. 32
7 Lista de tecnologias e seus quantitativos . . . . . . . . . . . . . . . . . p. 38
8 Artigos Incluídos por Ano . . . . . . . . . . . . . . . . . . . . . . . . . p. 39
9 Quantitativo de artigos por tipo de pesquisa . . . . . . . . . . . . . . . p. 41
10 Distribuição dos tipos de contribuição . . . . . . . . . . . . . . . . . . . p. 41
11 Agrupamento de tecnologias por categoria . . . . . . . . . . . . . . . . p. 42
12 Distribuição dos artigos por ano em c ada cateogria . . . . . . . . . . . p. 43
13 Pesquisas que utilizam uma combinação de tecnologias por Categorias . p. 44
14 Evolução na utilização de abordagens híbridas . . . . . . . . . . . . . . p. 45
15 Esquema de adaptação dos componentes presentes na arquitetura . . . p. 49
16 Mecanismo para Fusão de Informações . . . . . . . . . . . . . . . . . . p. 50
17 Visão Geral da Plataforma IndoLoR . . . . . . . . . . . . . . . . . . . p. 53
18 Campos do bloco de dados suportado pela Plataforma . . . . . . . . . . p. 54
19 Visão de módulos da Arquitetura . . . . . . . . . . . . . . . . . . . . . p. 57
20 Apresentação da Arquitetura da Plataforma utilizando o estilo em camadas p. 58
21 API das camadas da plataforma . . . . . . . . . . . . . . . . . . . . . . p. 58
22 Visão Arquitetural de Componentes e Conectores . . . . . . . . . . . . p. 59
23 Forma de adaptação dos componentes . . . . . . . . . . . . . . . . . . . p. 61
24 Processo de Adaptabilidade . . . . . . . . . . . . . . . . . . . . . . . . p. 61
25 Diagrama de Classes da API . . . . . . . . . . . . . . . . . . . . . . . . p. 62
26 Estilo de Arquitetura Publish/Subscribe adaptado de Eugster et. Al.
(EUGSTER et al., 2003) . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65
27 Comunicação entre as camadas da Arquitetura da Plataforma IndoLoR p. 66
28 Diagrama de Classes Base Plataforma . . . . . . . . . . . . . . . . . . . p. 67
29 Bloco de dados exemplo para comunicação com a Plataforma . . . . . . p. 67
30 Diagrama de Classes genérico para um Componente Padrão . . . . . p. 70
31 Diagrama de Classes genérico para um Componente Adaptador . . p. 71
32 Cenário para a Prova de Conceito . . . . . . . . . . . . . . . . . . . . . p. 74
33 Dados de WIFI obtidos pelo Smartphone a serem enviados para a plata-
forma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 75
34 Dados enviados como resposta a solicitação dos clientes pelo dado de
posicionamento de um dispositivo . . . . . . . . . . . . . . . . . . . . . p. 75
35 Aplicativo utilizando a API e a Plataforma adaptável para localização
Indoor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 78
36 Cenário da Adaptação da Plataforma IndoLoR utilizando WIFI e RFID p. 80
37 Implementação das Adaptações para a plataforma IndoLoR . . . . . . p. 83
38 Processo do cálculo do posicionamento de um dispositivo utilizando uma
abordagem dados heterogêneos . . . . . . . . . . . . . . . . . . . . . . p. 84
39 Tela do Aplicativo Android exibindo o posicionamento do dispositivo no
ambiente de escritório . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85
40 Grá�co da relação entre a métrica OsAC e as funcionalidades adaptadas p. 93
41 Grá�co tempo médio de processamento das solicitações considerando
apenas o componentes padrões e apenas padrões e desconsiderando as
adaptações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 94
42 Grá�co tempo médio de processamento das solicitações considerando
apenas padrões e desconsiderando as adaptações e o tempo médio to-
tal de processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 94
43 Modelo Arquitetural da Location Stack (HIGHTOWER; BRUMITT; BORRI-
ELLO, 2002) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 97
Lista de tabelas
1 Lista de tecnologias utilizadas na faceta de tecnologia . . . . . . . . . . p. 33
2 Categorias da Faceta do Tipo de Contribuição principal . . . . . . . . . p. 34
3 Categorias da Faceta do Tipo de Pesquisa . . . . . . . . . . . . . . . . p. 34
4 Resultado a aplicação dos critérios de inclusão e exclusão . . . . . . . p. 35
5 Formulário de extração de dados . . . . . . . . . . . . . . . . . . . . . . p. 36
6 Síntese dos requisitos funcionais contemplados pelas soluções de mercado p. 52
7 Tabela com os possíveis tipos de solicitações e os componentes padrões
que as processam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55
8 Tabela contedo as quantidades de classes e linhas de código dos compo-
nentes adaptadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 87
9 Tempo de processamento das solicitações na plataforma IndoLoR utili-
zando apenas os componentes padrões . . . . . . . . . . . . . . . . . . p. 88
10 Tempo de processamento das solicitações na plataforma IndoLoR pelos
componentes padrões utilizando os componentes adaptadores . . . . . . p. 88
11 Tempo de processamento das solicitações pela plataforma IndoLoR uti-
lizando componentes padrões e componentes adaptadores . . . . . . . . p. 89
12 Lista de características presentes em cada uma trabalhos relacionados . p. 99
Lista de abreviaturas e siglas
GPS - Sistema de Posicionamento Global
OSGi - Open Services Gateway Initiative
RSS - Potência do Sinal Recebido
AOA - Ângulo de Chegada
TOA - Tempo de Chegada
GSM � Sistema Global para Comunicações Móveis
RFID � Identi�cação por radiofrequência
RF � Radiofrequência
CDMA � Acesso Múltiplo por Divisão de Código
UWB � Banda Ultralarga
VLC � Comunicação por Luz Visível
FM� Modulação em frequência
NFC � Near Field Communication
IoT � Internet das Coisas
RNF - Requisitos Não-Funcionais
RF - Requisitos Funcionais
IMD - Instituto Metrópole Digital
OSI - Open System Interconnect
Lista de listagens
1 Exemplo do Método getFilter de InternalIndoorService que cria um �ltro p. 68
2 Exemplo da implementação de Serviço Externo . . . . . . . . . . . . . p. 68
3 Exemplo da implementação de um serviço para um Componente Padrão p. 70
4 Exemplo da implementação de Activator para um Componente Padrão p. 71
5 Exemplo da implementação de Activator para um Componente Adap-
tador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 72
6 Dados dos access points coletados e enviados para a plataforma . . . . p. 81
7 Dados de WIFI coletados e enviados a plataforma . . . . . . . . . . . . p. 81
Sumário
1 Introdução p. 18
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
1.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20
1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21
1.5 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
2 Referencial Teórico p. 23
2.1 Localização em Ambientes Internos . . . . . . . . . . . . . . . . . . . . p. 23
2.1.1 Técnicas de Localização Indoor . . . . . . . . . . . . . . . . . . p. 24
2.1.1.1 Triangulação . . . . . . . . . . . . . . . . . . . . . . . p. 24
2.1.1.2 Fingerprinting . . . . . . . . . . . . . . . . . . . . . . p. 25
2.1.1.3 Proximidade . . . . . . . . . . . . . . . . . . . . . . . p. 25
2.1.1.4 Análise de Visão . . . . . . . . . . . . . . . . . . . . . p. 26
2.2 Open Services Gateway Initiative (OSGi) . . . . . . . . . . . . . . . . . p. 26
2.2.1 OSGI Services . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
3 Revisão do Estado da Arte p. 29
3.1 Planejamento e Execução de um Mapeamento Sistemático . . . . . . . p. 30
3.1.1 Estratégia de Busca . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
3.1.2 Critérios de Inclusão e exclusão . . . . . . . . . . . . . . . . . . p. 31
3.1.3 Estabelecendo o Esquema de Classi�cação . . . . . . . . . . . . p. 31
3.1.4 Esquema de Classi�cação . . . . . . . . . . . . . . . . . . . . . . p. 32
3.1.5 Processo de Seleção . . . . . . . . . . . . . . . . . . . . . . . . . p. 33
3.1.6 Extração de Dados . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
3.1.7 Ameaças à validade . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
3.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
3.2.1 Respostas às questões de pesquisa . . . . . . . . . . . . . . . . . p. 37
3.2.1.1 Resposta da Q1: Quais tecnologias são utilizadas na téc-
nica de localização indoor baseada em �ngerprints? . . p. 37
3.2.1.2 Resposta da Q2: Como esses artigos estão distribuídos
ao longo do tempo? . . . . . . . . . . . . . . . . . . . . p. 39
3.2.1.3 Resposta da Q3: Nos artigos encontrados, quais os tipos
de pesquisa utilizados? . . . . . . . . . . . . . . . . . . p. 40
3.2.1.4 Resposta da Q4: Qual a contribuição principal dos arti-
gos selecionados? . . . . . . . . . . . . . . . . . . . . . p. 41
3.2.2 Discussões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42
3.2.3 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45
4 Plataforma Proposta p. 47
4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47
4.2 Requisitos da Plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47
4.2.1 Não funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48
4.2.2 Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 50
4.3 Arquitetura Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52
4.3.1 Descrição da Arquitetura . . . . . . . . . . . . . . . . . . . . . . p. 56
4.3.1.1 Visão de Módulos . . . . . . . . . . . . . . . . . . . . . p. 57
4.3.1.2 Visão de Componentes e Conectores . . . . . . . . . . p. 59
4.3.2 Processo de Adaptação . . . . . . . . . . . . . . . . . . . . . . . p. 60
4.3.3 API para dispositivo móvel . . . . . . . . . . . . . . . . . . . . . p. 62
4.3.4 Padrões Arquiteturais Adotados . . . . . . . . . . . . . . . . . . p. 62
4.3.4.1 Arquitetura Orientada a Serviços . . . . . . . . . . . . p. 62
4.3.4.2 Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . p. 64
4.3.4.3 Padrão em Camadas . . . . . . . . . . . . . . . . . . . p. 65
4.4 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66
4.4.1 Componentes Comuns . . . . . . . . . . . . . . . . . . . . . . . p. 66
4.4.2 Componentes Padrões . . . . . . . . . . . . . . . . . . . . . . . p. 69
4.4.3 Componentes Adaptadores . . . . . . . . . . . . . . . . . . . . . p. 71
5 Avaliação da Plataforma p. 73
5.1 Exemplo de uso: Localização Indoor utilizando WIFI . . . . . . . . . . p. 73
5.1.1 Plataforma IndoLoR utilizando WIFI . . . . . . . . . . . . . . . p. 74
5.1.1.1 Data Publication Manager . . . . . . . . . . . . . . . . p. 75
5.1.1.2 Location Manager . . . . . . . . . . . . . . . . . . . . p. 76
5.1.1.3 Data Storage Manager . . . . . . . . . . . . . . . . . . p. 76
5.1.2 Aplicativo para dispositivo móvel . . . . . . . . . . . . . . . . . p. 77
5.1.3 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77
5.2 Estudo de Caso: Localização Indoor utilizando WIFI e RFID . . . . . . p. 78
5.2.1 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 79
5.2.1.1 Questões de pesquisa . . . . . . . . . . . . . . . . . . . p. 79
5.2.1.2 Sujeitos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 79
5.2.1.3 Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 79
5.2.1.4 Unidades de análise . . . . . . . . . . . . . . . . . . . p. 82
5.2.1.5 Coleta de dados . . . . . . . . . . . . . . . . . . . . . . p. 82
5.2.2 Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 82
5.2.3 Ameaças à validade . . . . . . . . . . . . . . . . . . . . . . . . . p. 89
5.2.4 Respostas às questões de pesquisa . . . . . . . . . . . . . . . . . p. 90
5.2.4.1 Questão de Pesquisa 1: Qual o grau de adaptabilidade
provida pela plataforma IndoLoR? . . . . . . . . . . . p. 90
5.2.4.2 Questão de Pesquisa 2: Criar uma adaptabilidade para
plataforma IndoLoR é uma tarefa de custosa? . . . . . p. 91
5.2.4.3 Questão de Pesquisa 3: O desempenho da plataforma é
prejudicado quando os componentes padrões têm suas
funcionalidades adaptadas? . . . . . . . . . . . . . . . p. 92
5.2.5 Considerações Finais sobre o estudo de caso . . . . . . . . . . . p. 94
6 Trabalhos Relacionados p. 96
7 Considerações �nais p. 100
7.1 Principais contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . p. 101
7.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 102
7.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 103
Referências p. 104
Apêndice A -- Listagem de Artigos avaliados e seus respectivos formu-
lários. p. 110
18
1 Introdução
Este capítulo tem por �nalidade situar aspectos do tema abordado neste trabalho.
Dessa forma, descreve-se a motivação para a realização do mesmo na Seção 1.1. Na Seção
1.2 é descrito o problema tratado no estudo. Por sua vez, a Seção 1.3 descreve o objetivo
geral da pesquisa e enumera os objetivos especí�cos dela. Em seguida, na Seção 1.4 é
explicada a metodologia utilizada no trabalho. Por �m, a Seção 1.5 apresenta a forma
como o mesmo está organizado.
1.1 Motivação
Nos dias atuais, percebe-se que os sistemas de localização estão cada vez mais presen-
tes na vida das pessoas. Esses sistemas podem ajudar as pessoas a resolver diversos tipos
de problemas em uma grande variedade de situações (HE et al., 2011). Tais como: localizar
a posição de pessoas ou objetos, calcular uma rota de um determinado ponto a outro, lo-
calizar os bombeiros em um prédio em chamas, entre outras (LIU et al., 2007). O problema
de localização é bastante relevante em diversas áreas da computação, em que essa localiza-
ção, usuários e dispositivos, é bastante valiosa e importante para diversas aplicações, em
especial as sensíveis ao contexto (HIGHTOWER; BORRIELLO, 2001)(SATYANARAYANAN,
2001) (WIN et al., 2011).
As pessoas, em geral, costumam gastar de 80-90% do tempo delas dentro de ambientes
internos (SIMONI et al., 2003). Estes ambientes incluem shoppings, bibliotecas, aeropor-
tos, universidades, escolas, escritórios, fábricas, hospitais, entre outros. Diante disso, os
serviços de localização em ambientes internos vêm obtendo uma atenção especial. Um
dos motivos para o aumento da popularidade deste tipo de aplicação deve-se, em grande
parte, a crescente popularização de dispositivos portáveis, como celulares, smartphones,
tablets e notebook, em que eles já possuem diversos hardwares embutidos como WIFI,
Bluetooth, GPS e diversos sensores.
19
Dada essa popularidade, existe uma necessidade crescente de buscar tecnologias que
atendam aos requisitos de alta performance com um baixo custo, de forma a disponibilizar
uma variedade de aplicações interessantes em espaços internos (DODGE, 2015). Além
disso, de acordo com a OpusResearch, (RESEARCH, 2015) até 2018 devem ser gastos
cerca de 10 bilhões de dólares, de forma direta ou indireta, na área de localização indoor.
Demonstrando assim, uma grande oportunidade de mercado. Dentre os tipos de aplicação
presentes na área, as que realizam a propaganda direcionada emergem como as mais
promissoras (RESEARCH, 2015).
Além disso, diversos problemas podem ser resolvidos através de aplicações que utili-
zam a informação da localização de uma pessoa ou objeto em um determinado ambiente
interno. Em que os principais tipos de aplicações que se bene�ciam destas informações
são:
• Realidade Aumentada (JUNAIO, 2015)
• Campus Escolar (MAZEMAP, 2015) (BEESTAR, 2015) (ANYPLACE, 2015)
• Tour em museus guiado (FRAUNHOFER, 2015)
• Shoppings (ANYPLACE, 2015)
• Navegação em Loja (LIPS, 2015) (POINTINSIDE, 2015)
• Depósitos (LIPS, 2015) (ANYPLACE, 2015)
• Estações de trem e ônibus, aeroportos e estações subterrâneas (HERE, 2015)
• Estacionamento
• Propaganda Direcionada (GLOPOS, 2015)
1.2 Problema
A localização em ambientes externos, possui uma tecnologia bem difundida e padrão
chamada Sistema de Posicionamento Global (GPS) (HOFFMANN-WELLENHOF; LICHTE-
NEGGER; COLLINS, 1994) cujo funcionamento é baseado na utilização de satélites, desta
forma oferece cobertura em todo o globo terrestre. No entanto quando se trata de ambien-
tes internos, o mesmo não possui um funcionamento preciso pois as ondas rádio emitidas
pelos satélites não conseguem penetrar pelas paredes dos ambientes, não permitindo assim
20
a determinação do posicionamento de maneira e�caz, tipicamente em uma ordem superior
a 10m (KAPLAN; HEGARTY, 2005)(EHSANI et al., 2003).
A localização de pessoas ou objetos em ambientes internos, vem sendo cada vez mais
demandada para que possa ser con�ável e precisa (LEMIC et al., 2015). Nesse sentido, as
grandes empresas de tecnologia atualmente como Google (GOOGLE, 2014) e Apple (AP-
PLE, 2015) estão investindo nessa área de pesquisa para o desenvolvimento de soluções
para a localização em ambientes internos (INSIDER, 2015) (SUMMIT, 2015). Isso demons-
tra que este problema permanece sem solução, ou seja, não existe uma tecnologia ou uma
combinação de tecnologias que resolva o problema de maneira aceitável e a baixo custo
(LYMBEROPOULOS et al., 2015). E uma das principais razões para isto é a alta complexi-
dade dos ambientes internos, em que existem uma série de impedimentos como paredes,
equipamentos e até pessoas (MELO; AQUINO, 2015b), diferente dos ambientes externos.
Dessa forma, é necessário que as soluções propostas para resolver o problema da loca-
lização em ambientes internos levem em consideração a complexidade desses ambientes.
Em Melo e Aquino (MELO; AQUINO, 2015a), é apresentado que existe uma tendência que
as soluções para obter a localização em ambientes internos utilizem uma combinação de
tecnologias com o objetivo de obter um posicionamento preciso e con�ável. Assim, as
soluções propostas para resolver esse problema devem garantir o suporte a adaptação
de suas funcionalidades para que seja possível utilizar diferentes tecnologias, fontes de
informações, técnicas de localização, entre outros aspectos relacionados com a área.
1.3 Objetivos
Este trabalho tem como objetivo geral a construção de uma plataforma adaptável
que possibilite a localização de pessoas ou objetos em ambientes internos. Dessa forma,
baseado neste objetivo enumera-se os seguintes objetivos especí�cos:
• Mapear o estado da arte das tecnologias e tendências de soluções utilizadas para a
obtenção do posicionamento em ambientes internos;
• Identi�car e especi�car os requisitos que fazem parte do contexto de sistemas de
localização em ambientes internos;
• Projetar e avaliar a plataforma adaptável chamada �IndoLoR�, acrônimo de Indoor
Location Radar, que deve ser capaz de lidar com dados relacionados a localização
de pessoas ou objetos em ambientes internos.
21
1.4 Metodologia
A metodologia aplicada nesta dissertação seguiu o processo de�nido na Figura 1.
Este processo é composto de 4 etapas, sendo elas: Mapeamento Sistemático, Revisão
Exploratória, Projeto e Implementação e Avaliação.
Figura 1: Etapas da metodologia aplicada
O início da pesquisa deu-se com a execução do mapeamento sistemático da literatura,
como forma de familiarizar o pesquisador na área de localização em ambientes internos.
Além disso, a partir desta execução foi possível identi�car as principais lacunas de pes-
quisas existentes na área. Identi�cou-se que existe uma tendência que as novas soluções
de localização em ambientes internos utilizem uma combinação de tecnologias, métodos e
técnicas para obter posicionamentos mais precisos e con�áveis. Além disso, notou-se que
há um enorme crescimento da utilização de sensores para obter informações, em especial
os sensores inerciais como acelerômetros e giroscópio presentes em grande parte da nova
geração de smartphones.
Uma vez identi�cada a lacuna de pesquisa, foi realizada uma revisão exploratória
analisando trabalhos acadêmicos e soluções de mercado a �m de identi�car os requisitos
mais comuns presentes nas soluções de localização em ambientes internos. Após essa fase
de elicitação, partiu-se para a de�nição de uma plataforma para localização de pessoas ou
objetos em ambientes que possibilitasse a adaptação de suas funcionalidades para atender
os diversos tipos de ambientes, tecnologias, aplicações e informações. Uma vez �nalizada
essa etapa, iniciou a etapa de projeto e implementação e como primeira atividade de�niu-
se os requisitos funcionais e não-funcionais que fariam parte da plataforma IndoLoR, assim
como realizou-se a de�nição do projeto de sua arquitetura e implementação, utilizando a
tecnologia Open Services Gateway Initiative (OSGi) , de forma que todos os requisitos
de�nidos fossem atendidos.
Como última etapa da metologia empregada, iniciou-se a etapa de Avaliação cuja
primeira atividade foi validar a arquitetura e implementação da plataforma proposta,
assim foi especi�cado um exemplo de uso em um ambiente real. Para este exemplo, foram
realizadas as implementações das adaptações das funcionalidades necessárias de forma que
fosse possível obter o posicionamento de um dispositivo em um ambiente interno. Para
22
possibilitar a utilização da plataforma e suas adaptacões foi implementado um aplicativo
para dispositivo móvel para atuar com os papéis de coleta das informações do ambiente
e como um cliente consumidor das informações geradas pela plataforma. Além disso, foi
realizado um estudo de caso em que a plataforma foi adaptada para obter a localização de
um dispositivo utilizando dados de WIFI e RFID. Esse estudo, teve como objetivo avaliar
a adaptabilidade provida pela plataforma e suas questões, além de seu desempenho.
1.5 Organização do trabalho
O restante deste trabalho encontra-se organizado da seguinte maneira:
• O Capítulo 2 apresenta a fundamentação teórica contendo os conceitos necessários
ao entendimento deste estudo;
• O Capítulo 3 apresenta o mapeamento sistemático da literatura realizado neste
trabalho, no qual o mesmo tinha os objetivos de familiarizar o pesquisador na área
de localização em ambientes internos e identi�car as principais lacunas de pesquisas
existentes na área.
• O Capítulo 4 apresenta a plataforma adaptável, chamada de IndoLoR, para localiza-
ção em ambientes internos. Além disso, são apresentados seus requisitos, arquitetura,
padrões arquiteturais utilizados e sua implementação.
• O Capítulo 5 apresenta um exemplo de uso da plataforma proposta em um am-
biente real de escritório. Para isso, foi utilizado os sinais de WIFI obtidos em um
dispositivo móvel para calcular a posição estimada do mesmo no ambiente. Além
disso, apresenta um estudo de caso utilizando uma combinação de tecnologias com
o intuito de avaliar a adaptabilidade e a performance da plataforma projetada.
• O Capítulo 6 apresenta os trabalhos diretamente relacionados com este estudo.
Além disso, são apresentadas as principais características de cada um deles e suas
diferenças em relação a plataforma proposta.
• O Capítulo 7 expõe as considerações �nais deste trabalho, destacando as principais
conclusões, contribuições, limitações e trabalhos futuros.
23
2 Referencial Teórico
Neste capítulo são apresentados os conceitos essenciais ao entendimento deste traba-
lho. Assim, a Seção 2.1 apresenta conceitos, de�nições e técnicas sobre localização em
ambientes internos. Além disso, para o entendimento da plataforma proposta no Capítulo
4 é apresentado na Seção 2.2 a tecnologia OSGI, que foi utilizada como base para sua
construção.
2.1 Localização em Ambientes Internos
A localização de um objeto consiste em veri�car a sua posição espacial em relação
a um sistema de coordenadas. Com o passar do tempo, muitas técnicas e instrumentos
foram criados para identi�car a localização de pessoas ou coisas (exemplo: orientação pelas
estrelas, bussola, entre outros). Cada tipo de instrumento proporcionava melhorias em
vários aspectos, porém eram pouco precisos e não cobriam todo o globo terrestre. Diante
disso, a solução para a localização em ambientes externos surgiu em 1970 com a proposta
do GPS. Sendo nos dias atuais é a tecnologia mais utilizada para o posicionamento em
qualquer parte do planeta (KAPLAN; HEGARTY, 2005).
O funcionamento do GPS é todo baseado na utilização de satélites, o que o torna
bastante preciso em ambientes externos. No entanto, para ambientes internos o mesmo se
torna inadequado pois essa limitação é causada pela inabilidade dos sinais de satélites se
propagarem em áreas cheias de obstáculos, causando falhas ou impossibilidade de calcular
o posicionamento de um determinado alvo. Para solucionar essa inabilidade surgem os
Sistemas de Localização Indoor, sendo de�nidos como sistemas que continuamente e em
tempo real podem determinar a posição de algo ou alguém em ambientes fechados como
hospitais, ginásios, escolas, shoppings e etc (VOSSIEK et al., 2003).
Existem muitas situações do mundo real em que estes tipos de sistemas podem ser
utilizados, como: Detecção e controle de produtos armazenados em um depósito, locali-
zação de pessoal médico ou equipamentos em hospitais, localização de bombeiros em um
24
prédio em chamas, a posição de cães policiais treinados para encontrar dispositivos em
prédios, entre outras diversas aplicações (LIU et al., 2007).
2.1.1 Técnicas de Localização Indoor
Para obter localização de coisas em ambientes internas foram desenvolvidas diversas
técnicas, sempre buscando obter o mesmo sucesso atingido pelo GPS. Para esse tipo de
localização existem quatro técnicas para estimar a posição de pessoas ou objetos em um
ambiente interno (GU; LO; NIEMEGEERS, 2009), tais técnicas são: Triangulação, Finger-
printing, Proximidade e Análise de Visão.
2.1.1.1 Triangulação
Esta técnica é baseada na propriedade geométrica dos triângulos, três métodos podem
ser utilizados para calcular o posicionamento, sendo eles:
• Potência do sinal recebido (RSS) :
Este método calcula a distância entre um emissor e um receptor através de equações
baseadas em perda de propagação do sinal. Dessa forma, é calculado a distância do
emissor até o receptor utilizando a potência do sinal recebido (VOSSIEK et al., 2003).
• Ângulo de chegada (AOA) :
Este método exige que possa ser calculada a distância entre um emissor e um receptor
é necessário que exista um conjunto de antenas direcionais (cobrindo 360o graus) em
cada receptor. Ao receber um sinal de um emissor, o receptor determina qual antena
recebe o sinal com maior amplitude, dessa forma indica a direção de onde o sinal
foi gerado, este procedimento é feito com outro receptor e nesse caso têm-se duas
linhas onde é possível identi�car a localização da estação através da intersecção das
linhas (TAHERI; SINGH; EMMANUEL, 2004).
• Tempo de chegada (TOA) :
Neste método calcula-se o tempo que o sinal necessita para percorrer a distância
entre um emissor e o receptor. Como a velocidade de propagação do sinal é conhe-
cida e constante (velocidade da luz), é possível calcular a distância entre emissor e
receptor (RODRIGUES, 2011).
25
O princípio básico do método de triangulação para o posicionamento em duas dimen-
sões é apresentado na Figura 2. Se as coordenadas geográ�cas (xi,yi) que representam
os três elementos A,B e C são conhecidas, a posição E1 poderá ser calculada usando o
tamanho ou a direção dos elementos R1, R2 e R3.
Figura 2: Técnica de posicionamento utilizando a Triangulação (GU; LO; NIEMEGEERS,2009)
2.1.1.2 Fingerprinting
Segundo Farid et. Al.(FARID; NORDIN; ISMAIL, 2013) e Bolliger (BOLLIGER, 2008) esta
é a técnica mais utilizada para se obter a localização de coisas em ambientes internos. A
localização indoor utilizando Fingerprinting é de�nida como a determinação da posição
através de um processo de mapeamento de aspectos dos ambientes, como a potência dos
sinais presentes no ar, o campo magnético em um determinado local ou qualquer outra
característica que possa auxiliar na identi�cação do posicionamento. Com o resultado
deste mapeamento e os pontos que foram mapeados, é possível realizar uma inferência
para obter a localização aproximada de pessoas ou objetos sem a necessidade de nenhum
equipamento especializado (KAEMARUNGSI, 2005).
2.1.1.3 Proximidade
A técnica de localização por Proximidade examina a localização de um objeto alvo
sempre em relação a uma posição ou área conhecida. Esta técnica necessita de detectores
em locais conhecidos. Assim, quando um objeto monitorado se aproxima de um detector e
26
o mesmo o detecta, a posição desse objeto é considerada como próxima a área do detector.
Um exemplo da utilização desse tipo de técnica é para veri�car se um determinado alvo
se encontra ou não em uma sala. Utilizando a técnica de proximidade pode-se especi�car
se o alvo se encontra na sala ou não.
2.1.1.4 Análise de Visão
A técnica de análise de visão estima a localização a partir de uma ou um conjunto de
imagens, processando-as. Esta técnica não necessita que os usuários que a estão utilizando
utilizem nenhum tipo de tecnologia adicional. Normalmente, um conjunto de câmeras são
colocadas na área monitorada de forma que se consiga cobrir todo o ambiente e prover
imagens em tempo real. Uma vez obtidas as imagens, é possível realizar o processamento
em busca de padrões de reconhecimento, podendo ser citado como exemplo os padrões de
reconhecimento facial.
2.2 Open Services Gateway Initiative (OSGi)
A tecnologia OSGi é um conjunto de especi�cações que de�ne componentes dinâmicos
de sistema para Java. Essas especi�cações têm como objetivo reduzir a complexidade dos
softwares provendo uma arquitetura modular para sistemas distribuídos de larga escala
assim como, pequenas aplicações (ALLIANCE, 2015). Essas especi�cações são mantidas por
um consórcio de empresas que foi fundado em março de 1999, chamado OSGi Alliance.
Atualmente esse conjunto de especi�ções encontra-se na versão 6, lançada em Junho
de 2014. Vários frameworks que implementam a especi�cação OSGi estão disponíveis
na comunidade de software livre, entre elas estão: Apache Felix (FELIX, 2015); Equinox
(EQUINOX, 2015); e Knop�er�sh (KNOPFLERFISH, 2015).
OSGi de�ne um modelo de componentes dinâmicos para Java, permitindo uma abor-
dagem de desenvolvimento na qual aplicações são compostas dinamicamente por diferen-
tes componentes reusáveis. Uma unidade modular em OSGi é chamada bundle. Estes são
arquivos .jar compostos por arquivos Java e outros recursos que juntos fornecem funciona-
lidades aos usuários (ALLIANCE, 2015). Além disso, bundles podem compartilhar pacotes
entre si e um software baseado em OSGi é composto por um conjunto de bundles que
interagem entre si.
O framework OSGi é dividido em várias camadas como apresentado na Figura 3. Tais
27
camadas são: Segurança, Modularização, Ciclo de Vida e Serviços.
Figura 3: Arquitetura em camadas do OSGi, adaptado de (ALLIANCE, 2015)
A camada de Segurança é baseada na camada de segurança do Java 2, porém adiciona
uma série de restrições e preenche alguns vazios deixados pelo Java. Ela de�ne um formato
seguro de empacotamento, assim como interage com a camada de segurança do Java 2 em
tempo de execução.
A camada de Modularização de�ne um modelo de modularização para o OSGI os
chamados bundles. Além disso, estabelece as regras para o compartilhamento e ocultação
de pacotes entre bundles. Além do mais, sua utilização é independente das camadas de
Ciclo de Vida e de Serviços.
Na camada de Ciclo de Vida uma API é de�nida para o gerenciamento do ciclo de vida
dos bundles do framework OSGi. Esta API provê um modelo em tempo de execução para
os bundles e de�ne como eles são iniciados, parados, instalados, atualizados e desinstalados
no framework. Adicionalmente, disponibiliza uma API de eventos que permite aos bundles
de gerenciamento controlarem operações do framework OSGi. A camada de Ciclo de Vida
requer a camada de Modularização, mas é independente da camada de Serviços.
Por �m, a camada de Serviços fornece um modelo de programação dinâmico simpli�-
cando o desenvolvimento de bundles de serviço por desacoplar as de�nições dos serviços
(interfaces) das implementações (classes). A seleção de uma implementação especí�ca
pode ser realizada em tempo de execução.
2.2.1 OSGI Services
O OSGI implementa uma arquitetura orientada a serviços centralizada com baixo
acoplamento entre os serviços. Na especi�cação OSGI, qualquer classe Java pode ser pu-
28
blicada como serviço para que possa ser utilizada por outros bundles existente no ambiente
de execução. Tipicamente, um serviço inclui uma implementação, ou seja, uma instância
de uma classe; uma ou mais interfaces cujos serviços são publicados e um conjunto de
propriedades.
Figura 4: OSGi Service Registry (TAVARES; VALENTE, 2008)
Uma importante funcionalidade provida pelo OSGI é o chamado Service Registry, es-
tão armazenados todos os serviços registrados dentro do framework. A Figura 4 apresenta
o funcionamento deste componente. No passo 1, o Service Registry suporta que um Bun-
dle registre a publicação de um serviço em seu diretório, assim como permite que outros
bundle possam recuperá-lo como é apresentado no passo 2. Uma vez que um bundle ob-
tém o serviço, representado pelo passo 3, o mesmo pode executar qualquer um métodos
presentes na interface do serviço disponibilizado.
29
3 Revisão do Estado da Arte
Este capítulo apresenta um mapeamento sistemático da literatura, teve como objetivo
obter uma visão geral em relação aos trabalhos publicados na área de localização em
ambientes internos. Além disso, buscou-se identi�car as abordagens e soluções propostas
e quais as tecnologias utilizadas por elas. Sendo assim, essa pesquisa serviu para identi�car
os principais avanços na área, assim como, identi�car as principais lacunas de pesquisa.
Este mapeamento limitou-se a cobrir apenas uma das técnicas de localização indoor.
A técnica escolhida foi a de �ngerprinting pois segundo Farid et. Al. (FARID; NORDIN;
ISMAIL, 2013), Bolliger (BOLLIGER, 2008) e Kaemarungsi (KAEMARUNGSI, 2005) é a mais
utilizada dentre todas.
De acordo com Petersen et. Al. (PETERSEN et al., 2008) um Mapeamento Sistemático é
utilizado para prover a estrutura dos trabalhos publicados e seus resultados, classi�cando-
os. Isso permite que se obtenha uma visão abrangente de uma determinada área. Esse
método de pesquisa tem como objetivo principal identi�car possíveis lacunas na pesquisa
atual, com intuito de sugerir novos temas de pesquisa.
Na Seção 3.1 será descrito o protocolo utilizado para executar o Mapeamento, apre-
sentando: questões de pesquisa, strings de busca, critérios de inclusão e exclusão, esquema
de classi�cação e processo de seleção dos artigos. Na sequência, a Seção 3.2 apresentará
os resultados obtidos e as respostas para as questões de pesquisa de�nidas. Vale salientar
que o planejamento e execução da metodologia utilizado foi baseado no guia descrito por
Petersen et. Al. (PETERSEN et al., 2008). Desta forma, o processo utilizado na condução
dessa pesquisa é apresentado na Figura 5.
30
Figura 5: Processo de Mapeamento Sistemático da Literatura adaptado de Petersen etAl. (PETERSEN et al., 2008)
3.1 Planejamento e Execução de um Mapeamento Sis-
temático
Para contexto dessa pesquisa, o mapeamento sistemático deve responder as seguintes
questões de pesquisa:
Q1: Quais tecnologias são utilizadas na técnica de localização indoor baseada em
�ngerprints?
Q2: Como esses artigos estão distribuídos ao longo do tempo?
Q3: Nos artigos encontrados, quais os tipos de pesquisa utilizados?
Q4: Qual a contribuição principal dos artigos selecionados?
3.1.1 Estratégia de Busca
Esta pesquisa iniciou-se identi�cando os principais termos chaves utilizadas na área
de estudo. Para isso, foram realizadas diversas consultas, utilizando diversas strings, nas
principais bases de pesquisa na tentativa de identi�car possíveis sinônimos e palavras-
chaves objetivando obter a maior lista de resultados possível. Como resultado das diversas
consultas realizadas os seguintes termos foram selecionados como string de busca:
("indoor location"OR "indoor localization"OR "indoor positioning") AND (�nger-
print)
Como estratégia de busca foram utilizadas as bases de pesquisa mais conhecidas e
com a maior quantidade de trabalhos na área de ciências da computação, as quais são
listadas abaixo:
• IEEEXplore
• ACM digital library
31
• Springerlink
• ScienceDirect
Almejando obter o maior número de trabalhos relevantes possíveis foi utilizada a
engine de busca Scopus 1. Essa ferramenta foi escolhida por consultar em todas bases
relevantes para o nosso estudo. Foi executada uma única pesquisa no dia 30/11/2014,
cujo resultado obtido foi 1003 artigos para avaliação.
3.1.2 Critérios de Inclusão e exclusão
Neste passo do protocolo, é necessário de�nir os critérios de avaliação a serem utili-
zados na avaliação de todos os artigos recuperados identi�cando se o mesmo deverá ou
não fazer parte do mapeamento. Diante disso, foram avaliados para todos os trabalhos o
título, resumo, palavras-chaves e, quando necessário, introdução e conclusão.
Os critérios de inclusão para indicar se um artigo deverá ser considerado no mapea-
mento são:
CI1: Propor ou avaliar tecnologias para localização indoor
CI2: Se o artigo já tiver sido reportado, apenas o mais atual será considerado.
Para que um artigo não faça parte do mapeamento, precisa estar incluído em pelo um
dos seguintes critérios:
CE1: Artigos não escritos em inglês.
CE2: Artigos que não puderem ser obtidos ou não possuam versão completa disponí-
vel.
3.1.3 Estabelecendo o Esquema de Classi�cação
Poucas classi�cações foram realizadas até o momento para área de localização indoor
baseada em �ngerprints, dentre elas podemos citar Deak et al. (DEAK; CURRAN; CONDELL,
2012) que realiza uma análise baseada em casos industriais e não aplica uma revisão da
literatura. Outras duas classi�cações são apresentadas nos trabalhos de Liu et Al. (LIU et
al., 2007) e Farid et Al. (FARID; NORDIN; ISMAIL, 2013) os quais apenas um viés da área é
coberto. Estes trabalhos abordam apenas tecnologias que utilizam ondas de rádio, como
1http://www.scopus.com
32
WIFI, ZigBee, Bluetooth, entre outras. Portanto, existe o risco de algumas categorias
importantes não terem sido relatadas ou analisadas causando prejuízo na categorização
dos trabalhos. Diante disso, com o intuito de obter uma classi�cação precisa e completa
foi utilizado o processo de keywording de�nido por Mujtaba et al.(MUJTABA et al., 2008).
Este processo é apresentado na Figura 6.
Figura 6: Processo de keywording adaptado de Mujtaba et al.(MUJTABA et al., 2008)
O processo de keywording é executado em dois estágios. No primeiro estágio, os revi-
sores devem ler os títulos e resumos em busca de palavras-chaves e conceitos que re�itam
a contribuição principal do artigo, o tipo de pesquisa utilizado e as tecnologias envolvidas
na pesquisa. Uma vez �nalizado esse trabalho, esse conjunto de palavras-chaves e concei-
tos obtidos são agrupados e categorizados com o intuito de desenvolver uma classi�cação
de alto nível. Em artigos em que o resumo seja de baixa qualidade, não permitindo assim
a extração de palavras-chaves importantes, o revisor pode optar por revisar a seções de
introdução e conclusão do trabalho.
3.1.4 Esquema de Classi�cação
Os artigos foram classi�cados em três diferentes facetas. Cada uma dessas faceta re-
presenta um conjunto de conceitos ou categorias em que cada trabalho pode ser mapeado.
Objetivando responder as questões de pesquisa de�nidas, as facetas de classi�cação são:
Tecnologia, contribuição principal e tipo de pesquisa.
Faceta de Tecnologia: Determina a(s) tecnologia(s) utilizadas na pesquisa. Essa clas-
si�cação foi obtida utilizando o processo de keywording. Na Tabela 1 é apresentado a lista
de tecnologias em que os artigos foram classi�cados.
Faceta de Contribuição Principal: Esta classi�cação determina o tipo de contribuição
principal obtida pelo pesquisador em seu artigo. Essa classi�cação foi obtida através do
33
Tabela 1: Lista de tecnologias utilizadas na faceta de tecnologiaID Tecnologia
1 WIFI2 Bluetooth3 Sistema Global para Comunicações Móveis (GSM)4 Identi�cação por radiofrequência (RFID)5 ZigBee6 Onda RF7 Acesso Múltiplo por Divisão de Código (CDMA)8 Banda Ultralarga (UWB)9 Som10 Comunicação por Luz Visível (VLC)11 Espectro de Cor12 Acelerômetro13 Processamento de Imagem14 Altimetro15 GPS16 Giroscópio17 Compasso Digital18 Infravermelho19 Magnetômetro20 Modulação em frequência (FM)21 Laser22 Sensor de Proximidade23 Barômetro24 Sensor Angular Rate25 Sensor de Gravidade26 Odômetro27 Sensor de Luminosidade
processo de Keywording e são apresentados na Tabela 2. Além de apresentar as categorias
obtidas, são apresentados uma descrição para cada uma delas e todas as palavras-chaves
que foram agrupadas para a categoria.
Faceta do Tipo de Pesquisa: Para esta faceta, foi utilizada a classi�cação proposta
por Wieringa et. Al. (WIERINGA et al., 2006) em que são de�nidas seis categorias em que
as pesquisas podem ser classi�cadas. Essas descrições são apresentadas em detalhes na
Tabela 3.
3.1.5 Processo de Seleção
Este estágio do protocolo foi dividido em duas fases. Na primeira fase, foram aplicados
os critérios de inclusão e exclusão para todos os artigos obtidos pela string de busca
34
Tabela 2: Categorias da Faceta do Tipo de Contribuição principalCategoria Descrição Palavras-Chaves
Solução Representa um software ou solução com-putacional.
Software, Solução, Sistema,Aplicação e Ferramenta.
Método Indica como as coisas devem ser executa-das, por exemplo, utilizar o Bluetooth paraobter a localização indoor
Algoritmos, Técnicas eAbordagens.
Esquema Descreve um plano ou protocolo para resol-ver problemas especí�cos. De�ne um con-junto de procedimentos e regras na pes-quisa proposta.
Esquema
Métrica De�nir métricas ou medidas para área delocalização indoor.
Métrica
Modelo De�ne ou descreve modelos ou conceitosmatemáticos aplicados a área de localiza-ção Indoor.
Modelo
Tabela 3: Categorias da Faceta do Tipo de PesquisaCategoria Descrição
Pesquisa de Validação As técnicas são novas, porém ainda não implementadas na prá-tica. Este é tipicamente um estudo de uma técnica em um am-biente de laboratório.
Pesquisa de Avaliação Técnicas ou soluções que são implementadas na prática e temsuas consequências investigadas.
Proposta de Solução A solução para um problema é proposto, a solução pode sernova ou uma extensão signi�cante de uma técnica ou solução jáexistente. Os potenciais benefícios e a aplicabilidade da soluçãosão discutidas. A diferença entre uma proposta de solução e umapesquisa de avaliação se dá pelo nível de abstração da pesquisa.Para as propostas de solução, este nível é maior.
Artigos Filosó�cos Estrutura a área na forma de taxonomia ou framework concei-tual portanto apresenta uma nova maneira de avaliar as coisasexistentes.
Artigos de Opinião Estes artigos expressam a opinião pessoal de alguém sobre umdeterminado assunto. Estes estudos não dependem de trabalhosrelacionados ou a utilização de metodologias de pesquisa.
Artigos de Experiência Inclui a experiência pessoal do autor em o que ou como deter-minado fenômeno acontece na prática.
de�nida. A Tabela 4 lista os resultados da aplicação dos critérios de�nidos, apresentando
seus respectivos totais restantes. Ainda nessa fase, foram identi�cadas as palavras-chaves
e conceitos-chaves aplicando o processo de Keywording.
Na segunda fase foi realizada a análise e classi�cação dos artigos baseado na de�nição
do processo de categorização identi�cado durante o desenvolvimento do sistema de clas-
35
Tabela 4: Resultado a aplicação dos critérios de inclusão e exclusãoEstágio Critério Restante
1 Artigos relevantes de acordo com o de�nidoem 3.1.1
1003
2 Exclusão por inacessibilidade 9973 Exclusão baseada na Linguagem 9554 Exclusão baseada na duplicidade 9485 Exclusão baseada no título 8316 Exclusão baseada no abstract 5397 Restante incluído no mapeamento 539
si�cação detalhado na Seção 3.1.4. Todos os artigos restantes incluídos no mapeamento
foram analisados e categorizados em cada uma das facetas. Para a faceta de tecnologia,
um artigo poderia ter mais de uma classi�cação, ou seja, no mesmo trabalho os outros
podem ter utilizados mais de tipo de tecnologia em suas pesquisas. Além disso, é impor-
tante ressaltar que durante o processo de seleção e classi�cação dos trabalhos nenhum
critério de inclusão utilizando níveis de qualidade foi aplicado. Isso se deu pelo fato deste
mapeamento buscar uma visão geral da área e aplicando esse critério poderia compromen-
ter todo o estudo. Além disso, pelo fato dos trabalhos não terem sidos lidos de maneira
completa a realização desta avaliação não teria grau de con�abilidade aceitável.
3.1.6 Extração de Dados
Durante a execução do mapeamento no estágio de avaliação dos trabalhos, aplicação
do processo de Keywording, aplicação dos critérios de inclusão e exclusão foi preenchido
um formulário prede�nido para cada um dos artigos avaliados. Este formulário é descrito
na Tabela 5 em que são apresentados todos os campos que foram preenchidos pelo ava-
liador. Vale ressaltar que a coluna de nome �obrigatório� indica se item do formulário
deve ser preechido independentemente do artigo ter sido ou não excluído do mapeamea-
mento. Com o preenchimento deste formulário foi possível obter os dados necessários para
que as questões de pesquisa de�nidas fossem respondidas. Além disso, de posse dessas
informações foi possível realizar outras análises e discussões sobre a área em questão.
3.1.7 Ameaças à validade
Existem algumas ameaças à validade deste mapeamento, que são descritas abaixo
juntamente com as estratégias utilizadas para mitigar cada uma delas.
36
Tabela 5: Formulário de extração de dadosAtributo Descrição Obrigatório
ID Identi�cador único do artigo SimAno Ano em que o trabalho foi publicado SimCritério Critério de exclusão aplicado SimTipo de Pesquisa Tipo de pesquisa de�nidos na Faceta correspon-
denteNão
Tipo de Contribuição A contribuição principal apresentada pelo artigo NãoTecnologias Lista de tecnologias utilizadas na pesquisa Não
• Viés de Publicação: Não é possível garantir que todos os estudos relevantes foram
obtidos, porém foram incluídos o máximo de trabalhos possíveis. Pode-se perceber
que alguns artigos podem estar faltando. No entanto, caso mais artigos fossem ob-
tidos e avaliados acredita-se os resultados apresentados na Seção 3.2 não seriam
su�cietemente diferentes para modi�car as conclusões obtidas no estudo.
• Condução da busca: Os termos utilizados na busca de�nidos na Subseção 3.1.1 po-
dem não conter todos os termos relativos a área de localização indoor baseada em
�ngerprints. Com o intuito de mitigar essa ameaça, diversas consultas foram reali-
zadas nas bases acadêmicas de forma que os resultados fossem validados e re�nados
com o objetivo de obter os termos que o mapeamento alcançasse o maior número de
artigos possíveis. Além disso, foram utilizados termos sinônimos com o objetivo de se
obter uma maior cobertura, em que alguns dos termos utilizados foram �localisation�
e �position�. Não tendo sido encontradas diferenças.
• Extração de dados: Durante o processo de extração de dados, os artigos foram classi-
�cados baseados no julgamento do avaliador. Para mitigar essa ameaça, foi realizada
uma dupla checagem nos artigos avaliados com o objetivo de garantir que a classi-
�cação de um artigo não estivesse incorreta.
• Faceta de contribuição: Este mapeamento apresentou que os trabalhos utilizam ter-
mos alguns termos chaves em suas pesquisas como: abordagem, método, algoritmo,
esquema, modelo, métrica, solução e sistema. No entanto, não existe uma padro-
nização ou de�nição formal para utilização de tais termos, para mitigar este risco,
foi adotado a nomenclatura original de�nida pelo autor sem se preocupar com as
de�nições formais inerentes a cada um dos termos. Esta mesma solução foi aplicada
em Zelkowitz e Wallace (ZELKOWITZ; WALLACE, 1998).
37
3.2 Resultados
Nesta seção são apresentados os resultados para subsidiar as respostas para as questões
de pesquisa de�nidas na Seção 3.1.4 a partir da leitura cuidadosa e da execução de todo
o protocolo de�nido para este mapeamento sistemático. Além disso, serão discutidos os
resultados encontrados e seus possíveis desdobramentos e, por último, serão apresentadas
as conclusões obtidas.
3.2.1 Respostas às questões de pesquisa
Nesta seção serão apresentados os dados e as respostas para as questões de pesquisa
de�nidas.
3.2.1.1 Resposta da Q1: Quais tecnologias são utilizadas na técnica de loca-
lização indoor baseada em �ngerprints?
Na Figura 7 são apresentados os dados necessários para responder a esta questão, são
listadas as tecnologias utilizadas nas pequisas avaliadas e suas quantidades. É possível
perceber que a quantidade do número de tecnologias utilizadas excede os números de
artigos avaliados isso acontece pois, em alguns casos, são utilizadas mais de uma tecnologia
na pesquisa.
É possível identi�car que a tecnologia mais utilizada é o WIFI a qual supera em
mais de seis vezes o segundo lugar. De acordo com In-Stat (IN-STAT, 2014), em 2014
cerca de 2 bilhões de dispositivos foram ativados utilizam o WIFI, esses dispositivos estão
incluídos qualquer tipo de dispositivo que possua uma interface de rede WIFI ativada
como: relógios, smartphones, computadores e outros tipos de dispositivos. Outro ponto
que pode representar alta utilização desta tecnologia é associado ao custo. Normalmente,
a infraestrutura necessária existe em praticamente em todos os ambientes. Desta forma,
na maioria dos casos não é necessário inserir ou modi�car dispositivos o que permite a
redução no custo das soluções.
Outra tecnologia que merece um destaque positivo pelo número de pesquisas realizadas
é o ZigBee. Apesar de ser bem parecida com oWIFI e Bluetooth, porém se propõe a possuir
um melhor gerenciamento de consumo de energia e baixa transmissão de dados (HUNG et
al., 2010). Apesar dessas características, existem alguns fatores que ainda impedem que o
mesmo seja utilizada em larga escala, como alto custo e baixo alcance.
38
Figura 7: Lista de tecnologias e seus quantitativos
Outro tecnologia que chama atenção pelo baixo número de pesquisas em relações as
demais é o Bluetooth, de acordo com o Bluetooth SIG (SIG, 2013), esta estará presente
em quase quatro bilhões de dispositivos em 2016. Sendo desse total, cerca de um bilhão
é de smartphones. Por este motivo, era esperado que esta tecnologia estivesse no mínimo
entre as cinco primeiras mais utilizadas. Algumas características do Bluetooth pode ter
in�uência direta na quantidade de artigos que o utiliza em suas pesquisas na área de
localização. Uma dessas caraterísticas é de sempre que se deseja encontrar dispositivos é
necessário executar o procedimento de descoberta. Essa execução tem um alto custo de
latência(10 � 30 s) e consumo de energia. Por esta razão, a tecnologia Bluetooth possui
esse impedimento para ultrapassar quando se trata de sistemas de posicionamento em
tempo real (FARID; NORDIN; ISMAIL, 2013).
A tecnologia RFID obteve um certo destaque nas pesquisas realizadas na área de
localização indoor, sendo a quarta mais utilizada. De acordo com o IDTechEx (IDTECHEX,
2014), em 2014 o mercado de RFID movimentou quase $9 bilhões e ainda segundo este
mesmo instituto, cerca de seis bilhões de tags dessa tecnologia foram vendidas em 2013.
Esses números demonstram a crescente popularidade que esta tecnologia vem obtendo no
mercado e nas pesquisas de uma maneira geral. Um dos grandes responsáveis por essa
popularização são os smartphones, pois nos dias atuais uma grande parcela deles possui
em seu hardware padrão um leitor de RFID integrado. No entanto para esses dispositivos,
a tecnologia sofreu uma evolução passando a ser conhecida comercialmente como Near
Field Communication (NFC) (HASELSTEINER; BREITFUSS, 2006).
39
Um exemplo de uma proposta de solução utilizando o RFID é apresentada por We-
gener et. al. (WEGENER et al., 2014) em que sua pesquisa consiste em um portal com a
função de leitor e uma tag acoplado a um objeto móvel. Quando este objeto se aproxima
do portal, o mesmo é detectado e identi�cado através de um ID único presente na tag
acoplada ao mesmo. O sinal obtido é armazenado com o intuito de calcular a posição
corrente para este objeto.
3.2.1.2 Resposta da Q2: Como esses artigos estão distribuídos ao longo do
tempo?
Para responder a esta questão, apresentamos`, na Figura 8, o total de artigos incluí-
dos por ano. É possível perceber que o valor máximo ocorreu no ano de 2013 com 141 de
artigos. Além disso, nota-se que houve uma pequena diminuição na quantidade de arti-
gos incluídos. Este fenômeno pode ser explicado pois esse mapeamento foi realizado em
Novembro/2014 então alguns artigos poderiam ainda não estar disponíveis nas bases de
pesquisas.
É possível perceber que nos últimos três anos, a quantidade de artigos obteve um alto
indíce de publicações. Para o período de 2012-2014 percebemos um aumento de 40% no
total de artigos em relação ao período de 2004-2011. Adicionalmente, a linha de tendência
apresenta a curva de crescimento de inclusão de artigos ao longo dos anos, cuja tendência
é que o ano de 2014 supere o número de trabalhos em relação ao ano de 2013.
Figura 8: Artigos Incluídos por Ano
40
3.2.1.3 Resposta da Q3: Nos artigos encontrados, quais os tipos de pesquisa
utilizados?
Com o objetivo de responder a questão de pesquisa Q3 é apresentada a Figura 9 que
apresenta a distribuição da classi�cação dos artigos avaliados nesse mapeamento para a
faceta de tipo de pesquisa de�nida na Subseção 3.1.4. Os resultados obtidos apontam
que cerca de 90% das pesquisas na área de localização indoor baseada em �ngerprints é
reportando propostas de soluções. Este número pode indicar que apesar de muitos estudos
estarem focados obter uma solução para tal problema, ainda existem algumas lacunas a
serem preenchidas como soluções de fácil instalação e utilização, con�áveis e precisas.
Para exempli�car uma proposta de solução, Mariakakis et. al. (MARIAKAKIS et al.,
2014) propõe um sistema para localização indoor que utiliza sinais de WIFI e sensores
presentes em um smartphone. Desta forma, com a solução descrita é possível obter a
localização de uma pessoa em um ambiente corporativo. O mesmo relata que a sua solução
consegue obter o posicionamento com uma precisão de cerca de 2.3 metros em média.
Os números dos tipos de pesquisa de validação e avaliação representam aproximada-
mente 10% do total. Este número demonstra a baixa condução de pesquisas em laborató-
rios com uma sistemática bem de�nida. Para o tipo de pequisa de artigos de experiência
não foram encontrados nenhum artigo que utilizasse esse tipo de pesquisa. Esse fato é
bem peculiar e chama a atenção por não haver relatos de experiência da utilização das
soluções de localização em ambientes internos já propostas.
Outro fato que chama bastante atenção é o número de trabalhos presentes na categoria
de artigos �losó�cos, apenas três artigos foram identi�cados no mapeamento. Este tipo de
artigo tende a prover importantes contribuições para os campos de pesquisa fudamentando
as bases conceituais ou ilustrando os principais problemas. Apresentando uma visão geral
desta categoria temos que Cheng et. al. (CHENG et al., 2012) e Ku et. al. (KUL; ÖZYER;
TAVLI, 2014) apresentam um survey focado apenas nas tecnologias sem �o como WIFI,
Bluetooth, ZigBee, entre outras. Essas pesquisas não cobrem as tecnologias envolvidas
na área como apresentado na Subseção 3.2.1.1, podendo levar a inúmeras lacunas pois
cobre apenas um viés de tecnologias envolvidas na área. Deak et. al. (DEAK; CURRAN;
CONDELL, 2012) apresenta um survey que apresenta as técnicas de localização indoor
divididas em duas categorias: ativos e passivas. Este estudo mostra-se mais consistente
que os apresentados anteriormente pois apresenta uma visão mais realista e uniforme
relacionados a contribuição e conceitos.
41
Figura 9: Quantitativo de artigos por tipo de pesquisa
3.2.1.4 Resposta da Q4: Qual a contribuição principal dos artigos seleciona-
dos?
A Figura 10 apresenta o total de artigos para cada tipo de contribuição principal
de�nida na Seção 3.1.4. Alguns números chamam atenção como, soluções e métodos que
juntos representam quase 97% do total. Estes números podem demonstrar que os pesqui-
sadores estão focados em obter o método, a maneira ou solução para resolver o problema
de localização em ambientes internos. A categoria de métodos representa mais de 63% do
total de artigos avaliados, esse número expressivo pode ser explicado pelo agrupamento
das subcategorias como algoritmos, técnicas e abordagens.
Figura 10: Distribuição dos tipos de contribuição
Outro importante fato sobre estes números é o de que apenas um trabalho propôs uma
nova métrica para a área de localização indoor. Em Sapumohotti et. al. (SAPUMOHOTTI;
ALIAS; TAN, 2014) é proposta uma métrica que quanti�ca a efetividade de localização
42
provida por um ponto de acesso WIFI.
3.2.2 Discussões
A partir da lista de tecnologias obtidas através deste estudo, é possível agrupá-las
em categorias. Na Figura 11 é apresentado o agrupamento das tecnologias, que foram
divididas em seis categorias representadas por: Radiofrequência, GPS, Ótica, Som, Pro-
cessamento de Imagem e Sensores. O critério utilizado para o agrupamento apresentado
é pelo meio de transmissão utilizado pela tecnologia para transmitir os seus dados. É
possível perceber que a categoria de Radio Frequência é a que possui a maior quantidade
tecnologias utilizadas em pesquisas, muito em virtude da presença do WIFI e do ZigBee.
Outra categoria que obteve números expressivos foi a de tecnologias baseadas em sensores,
obtendo o segundo lugar. Esses números demonstram o viés que vem sendo seguido pelos
pesquisadores no que diz respeito a localização em ambientes internos.
Figura 11: Agrupamento de tecnologias por categoria
Apesar de ser categorizada como uma tecnologia baseada em Radiofrequência, o GPS
foi separada em uma categoria principal pelo fato de ser uma tecnologia já estabelecida
no mercado e prover por si própria a localização em ambientes externos. Alguns estudos
encontrados utilizam o GPS combinado com outras tecnologias no intuito de obter um
posicionamento em ambientes internos com uma maior precisão. No entanto, Fluerasu et.
al. (FLUERASU et al., 2010) é o único caso em que o GPS é utilizado sem o auxílio de
nenhuma tecnologia adicional para obter a localização indoor.
Após uma análise e organização dados apresentados na categorização, é apresentado
na Figura 12 a distribuição dos artigos agrupados em cada categoria por ano. É possível
43
perceber a curva de crescimento da categoria de Radiofrequência quando a partir do ano de
2008 os seus números passaram a crescer rapidamente indicando que o foco das pesquisas
está muito ligada a esse tipo de categoria de tecnologia.
As categorias de Som, Óticas e o GPS não obtiveram números de pesquisas signi-
�cantes e estes números vem caindo ao longo dos anos. A categoria do processamento
de imagem, tem se mostrado estável ao longo dos anos. No entanto, no ano de 2014,
obteve um acréscimo signi�cativo no número de pesquisas o que pode indicar um novo
viés não explorado com um grande potencial, muito devido ao reconhecimento facial para
posicionamentos mais con�áveis.
Os números obtidos para a categoria de sensores, apresenta um grande aumento na
quantidade de pesquisas realizadas quando comparadas com os anos anteriores a 2012.
Esta categoria tem o início do seu auge no período de 2010-2012, no qual coincide exa-
tamente com o período em que aconteceu a popularização dos smartphones. O Gartner
(GARTNER, 2012) cita que cerca de 1.75 Bilhões de pessoas possuem smartphones com
capacidades avançadas. Esses dispositivos tipicamente possuem múltiplos sensores em-
butidos, como acelerômetros, giroscópios e etc. Diante disso, esta categoria se apresenta
como uma forte candidata expandir a sua popularidade entre os pesquisadores, porém
ainda possui uma distância bem considerável quando comparada aos números de pesquisa
da categoria de Radiofrequência.
Figura 12: Distribuição dos artigos por ano em c ada cateogria
É possível perceber tanto pela categorização apresentada na Figura 12 quanto pelo
quantitativo de tecnologias apresentado pela Figura 7 que em muitas pesquisas é utilizada
uma combinação de tecnologias. Seguindo essa linha de pensamento a Figura 13 apresenta
os números comparando a quantidade de pesquisas que utilizam apenas uma tecnologia
44
com as que utilizam uma combinação das mesmas.
Figura 13: Pesquisas que utilizam uma combinação de tecnologias por Categorias
Foi possível perceber que na maioria dos estudos a categoria de Radiofrequência é a
mais utilizada como tecnologia única nas pesquisas. Um dos motivos para esse número
tão expressivo quando comparado com os demais pode ser explicado pela presença da
tecnologia WIFI, uma vez que a mesma é mais utilizada dentre os trabalhos analisados.
Além disso, foi possível perceber que existe um grande número de pesquisas que buscam
tornar o WIFI a tecnologia padrão para a localização em ambientes internos pois é de
longe a mais utilizada em pesquisas envolvendo apenas uma tecnologia.
A categoria de sensores vai exatamente na direção contrária da maioria dos estudos da
categoria de Radiofrequência, em que cerca de 86% deles utilizam mais de uma tecnologia
em suas pesquisas. Essa tendência de combinar várias tecnologias utilizando sensores
vem crescendo ao longo dos anos e umas das razões para esse crescimento pode ser a
popularização da Internet das Coisas (IoT) e a Computação Ubíqua (GUBBI et al., 2013).
O restante das categorias como o GPS, Processamento de Imagem, Som e Ótica o número
de pesquisas que utilizam a combinação de tecnologias supera o número de pesquisas em
que apenas uma é utilizada. Sendo assim, apenas a categoria de Radiofrequência apresenta
como tendência principal a utilização de abordagens híbridas.
Analisando a utilização das abordagens híbridas nas pesquisas avaliadas, temos a Fi-
gura 14 apresenta o número das abordagens que utilizam uma combinação de tecnologias
obtidas a partir dos artigos avaliados comparada com o número de artigos incluídos por
ano. Para uma melhor análise, uma linha de tendência da relação desses dois valores é
apresentada. É possível perceber que entre os anos de 2004 e 2007, nenhuma pesquisa
foi publicada utilizando uma combinação de tecnologias. A partir do ano de 2008, algu-
45
mas pesquisas começaram a ser publicadas sendo responsáveis por cerca de 9% do total
publicados no período. Essa tendência se manteve estável até o ano de 2012, na qual
passou a crescer a um valor relativamente constante de cerca de 2% por ano. Apesar do
número ainda baixo de pesquisas com essas características, existe uma certa tendência
que nos próximos anos este número cresca e novas soluções e métodos que utilizam uma
combinação de tecnologias serão propostos.
Figura 14: Evolução na utilização de abordagens híbridas
3.2.3 Conclusões
A partir da realização do mapeamento sistemático foram obtidas diversas informações
a respeito das pesquisas estão sendo realizadas na área de localização indoor baseada em
�ngerprints. A interpretação dessas informações obtidas, auxiliaram no entendimento,
evolução, descobertas e problemas em aberto. Inicialmente, uma descoberta interessante
é o fato de a grande maioria das pesquisas realizadas na área apresentam propostas de
solução, o que demonstra a intensa perseguição dos pesquisadores em obter uma solução
que consiga resolver o problema de localização em ambientes internos.
Uma outra descoberta importante é que a tecnologia WIFI é de longe a mais utilizada
nas pesquisas avaliada porém, esse resultado já era esperado pelo simples fato de existir
APs de WIFI presentes normalmente nos ambientes. Outra tecnologia que chamou a
atenção pelos seus resultados expressivos foi o ZigBee que superou inclusive o Bluetooth
que é uma tecnologia mais acessível e não obteve um resultado tão interessante. Associado
as tecnologias foi possível realizar um agrupamento das tecnologias em seis categorias,
sendo elas: Radiofrequência, Sensores, Processamento de Imagem, Ótica, GPS e Som. O
critério utilizado para o agrupamento das tecnologias foi a partir do meio utilizado pelas
mesmas para transmitir as informações.
Essa categorização, possibilitou a avaliação de uma família de tecnologias em que
46
uma que obteve bastante destaque foi a de Sensores em que a partir dos anos dos anos
2011�2012 obtiveram um grande aumento no seu quantitativo de pesquisas, principamel-
mente, as tecnologias presentes na maioria dos smartphones como acelerômetro, giroscópio
e compasso digital. Essa descoberta aponta para um novo viés em utilizar os próprios dis-
positivos para coletar as informações do ambiente.
Outro achado importante é a tendência crescente da utilização de uma combinação de
tecnologias para obter o máximo de informações possíveis sobre um determinado ambiente
ou usuário com o objetivo de obter um posicionamento mais preciso e seguro. Uma das
razões que podem estar levando os pesquisadores utilizarem esse tipo abordagem se dá
pelo fato de ambientes internos serem bastante complexos e ainda não existir nenhuma
tecnologia que consiga adaptar-se a todos esses tipos de ambientes.
47
4 Plataforma Proposta
4.1 Introdução
Com base nos resultados da revisão da literatura, descrita no Capítulo 3, foi iden-
ti�cado que a grande maioria das pesquisas estão relacionadas a propostas de solução.
Esse fato demonstra que ainda não existe uma solução que consiga resolver o problema
da localização para todos os tipos de ambientes, dada a natureza complexa desse tipo de
ambiente (LYMBEROPOULOS et al., 2015). Além disso, percebeu-se que em diversas dessas
propostas de soluções existe uma tendência de se utilizar uma combinação de tecnologias.
Com essa utilização, espera-se obter soluções de localização em ambientes internos mais
precisas e con�áveis (MELO; AQUINO, 2015b).
Portanto, este capítulo apresenta a proposta da plataforma adaptável IndoLoR, cujo
objetivo é obter a localização em ambientes internos, além de permitir a utilização de
uma combinação de tecnologias, técnicas e abordagens. Essa plataforma de�ne uma série
de componentes que podem ter suas funcionalidades adaptadas com o intuito de permitir
a recepção, tratamento e armazenamento dos diversos dados heterogêneos que compõem
um ambiente interno. Além disso, a possibilidade da adaptação de seus componentes
permite que a plataforma seja adaptada aos diversos ambientes internos, podendo atender
a especi�cidade de cada um deles.
4.2 Requisitos da Plataforma
Com o intuito de construir uma plataforma que possibilite o recebimento de informa-
ções provenientes de diferentes fontes, além de realizar o processamento, fusão, armaze-
namento e disponibilização dessas informações, principalmente, garantir a adaptabilidade
de suas funcionalidades para atender a essa heterogoneidade de informações, foi necessá-
rio de�nir um conjunto de requisitos funcionais e não funcionais para que a plataforma
proposta possa atender a todas essas especi�cações.
48
4.2.1 Não funcionais
A de�nição dos requisitos não-funcionais (RNF) se deu através de uma análise de
trabalhos presentes na literatura diretamente relacionado a este trabalho, os quais são
apresentados no Capítulo 6. Durante essa análise, buscou-se identi�car os requisitos não-
funcionais contemplados em cada um destes trabalhos. No entanto, é importante ressaltar
que os requisitos contemplados pela plataforma proposta não se limitaram aos encon-
trados na análise dos trabalhos, outros que foram julgados essenciais para um melhor
funcionamento da plataforma foram incorporados.
Diante do exposto, os requisitos obtidos a partir dessa análise são apresentados em
detalhes abaixo:
• RNF1: Utilizar uma arquitetura modular e adaptável
Com este requisito, tem-se o objetivo de garantir que a plataforma obtenha uma
maior �exibilidade na de�nição de suas funcionalidades. Cada módulo da arquitetura
é chamado de componente. A utilização dessa abordagem visa melhorar o processo
de manutenção de funcionalidades da plataforma, garantindo assim que caso seja
necessário realizar uma correção ou uma melhoria em um determinado módulo da
plataforma não haja impacto em outros componentes. Essa característica permite
que seja possível de�nir responsabilidades especi�cas para cada um dos componen-
tes aumentando a facilidade de entendimento e manutenção pelos desenvolvedores.
Dessa forma, a modularização deve permitir o acoplamento ou desacoplamento de
adaptações aos componentes de maneira plug n' play.
A característica de adaptabilidade é a habilidade dos componentes de uma arquite-
tura de adaptar suas funcionalidades de maneira estática ou em tempo de execução
para atender a mudanças no ambiente ou nos requisitos de�nidos (TARVAINEN,
2008). Cada componente da arquitetura possui uma interface de adaptação, no en-
tanto nenhum componente adaptador a realiza pois podem existir diversos cená-
rios de adaptação. Então, os componentes adaptadores especi�cam uma interface
compatível com os componentes de�nidos na arquitetura plataforma. Dessa forma,
forma-se uma ligação entre os dois componentes sempre que seja necessário, na
qual é exempli�cado na Figura 15. Além disso, dada essa divisão da arquitetura em
componentes é possível realizar a adaptação de componentes especí�cos, não sendo
obrigatória a adaptação de todos os componentes da plataforma para a inclusão ou
alteração de capacidades.
49
Figura 15: Esquema de adaptação dos componentes presentes na arquitetura
• RNF2: Recepção e processamento de dados de fontes de informações heterogêneas
Este requisito visa garantir que a plataforma possibilite a manipulação de dados
heterogêneos permitindo como entrada qualquer tipo de informação, independente
da tecnologia, ou unidade utilizada. Um dos objetivos deste requisito é permitir a
combinação de diferentes tipos de informação para prover os vários tipos de serviços
de localização.
• RNF3: Prover mecanismos para a fusão de informações
Deve prover mecanismos para permitir a fusão de informações de domínios iguais ou
diferentes. Dessa forma, deve ser possível combinar dados brutos provenientes das
diferentes fontes de informação ou dados derivados obtidos através da utilização de
algoritmos de processamento.
Esse mecanismo pode ser melhor exempli�cado na Figura 16, em que o componente
B possui uma adaptação que necessita das informações A e B. Dessa forma, se
solicita ao componente A que detém os repositórios de dados, acesso os mesmos.
Uma vez de posse desse acesso, é repassado para componente que implementa a
adaptação possa realizar o processo de fusão obtendo os dados necessários para tal
a partir dos repositórios solicitados.
• RNF4: Garantir o suporte a diferentes repositórios para armazenamento de dados
A plataforma deverá suportar diferentes formas de armazenamento de dados ou seja,
ser adaptável no que tange a persistência de informações. Deve ser possível utilizar
bancos de dados relacionais, não relacionais, memória ou ainda o sistema de arquivos.
Além disso, cada componente poderá utilizar uma forma de armazanamento que
atenda às suas necessidade sem que haja um repositório padrão de�nido.
50
Figura 16: Mecanismo para Fusão de Informações
• RNF5: Garantir o controle de acesso as informações
Deve garantir que apenas os componentes que possuem a permissão para realizar
operações sobre um determinado tipo de dado tenham acesso ao mesmo.
• RNF6: Fornecer uma API
A plataforma deverá disponibilizar uma API contendo as interfaces bem de�nidas
para a utilização das funcionalidades providas, além de realizar a comunicação de
maneira transparente com a mesma, ou seja, os desenvolvedores que utilizarem a
API não necessitam precisam conhecer como é realizada a comunicação com a pla-
taforma. Este requisito foi categorizado como não-funcional devido ao fato da sua
utilização não ser obrigatória por parte dos desenvolvedores de aplicações que uti-
lizarão a plataforma proposta. Entende-se que a API é um facilitador para que o
desenvolvimento dessa comunicação aconteça de maneira mais simpli�cada.
4.2.2 Funcionais
Com o objetivo de identi�car os requisitos funcionais (RF) comumente presentes nas
soluções de localização em ambientes internos, foi realizada análise das principais soluções
presentes no mercado. Dentre elas é possível citar: Indoo.rs 1 , Nextome 2, AnyPlace 3,
inlocomedia 4 e Accuware 5. Essa análise envolveu a avaliação das descrições das soluções,
em que estas são providas pelos próprios fabricantes e informam quais funcionalidades
estão presentes em cada uma das soluções. Como resultado, os seguintes requisitos foram
1http://indoo.rs/2http://www.nextome.org3http://anyplace.cs.ucy.ac.cy/4http://www.ubee.in5http://www.accuware.com
51
identi�cados:
• RF1: Recuperar Mapa
Deve ser possível, realizar a recuperação de um mapa de um determinado ambiente
a partir de dados do ambiente enviados para a plataforma.
• RF2: Recuperar posição de um alvo no mapa
Deve ser possível recuperar a última posição estimada de um determinado alvo.
Opcionalmente, deve ser possível escolher o método de localização a ser utilizado pela
plataforma. Caso nenhum método seja selecionado, deverá ser utilizado o de�nido
por padrão.
• RF3: Recuperar coisas localizáveis próximas
Deve retornar uma lista contendo os itens e seu respectivo posicionamento. A pes-
quisa das coisas localizáveis será realizada dentro de um raio de�nido pelo usuário
ou utilizar o padrão de�nido pela plataforma.
• RF4: Cálculo do caminho entre dois pontos no mapa
Deve ser possível, calcular uma rota entre um ponto de origem até um ponto de
destino.
• RF5: Cadastrar coisas
Deve ser possível cadastrar, listar ou remover coisas. O termo coisas é bem genérico
e abrange vários tipos de ob jetos como smartphones, sensores, pessoas, equipamen-
tos, access points, dentre outros. Sendo assim, qualquer objeto que interaja com a
plataforma poderá ser cadastrado para posterior recuperação.
• RF6: Prover diferentes formas de cálculo de posicionamento
De acordo com (GRESSMANN; KLIMEK; TURAU, 2010) existem dois cenários para o
cálculo de posicionamento. Em que estes são:
� Auto posicionamento: Quando o objeto móvel é capaz de obter seu posicio-
namento através de informações coletadas a partir do ambiente em que está
inserido. De posse desse posicionamento, essa informação deverá ser enviada
para a plataforma para armazenamento.
52
� Posicionamento distribuído: Quando o objeto móvel não é capaz de determinar
seu próprio posicionamento por algum motivo, como baixo poder de proces-
samento ou inexistência de hardware capaz. A plataforma deverá realizar a
estimativa do posicionamento deste objeto através da utilização de informa-
ções provenientes de outras fontes ou de informações coletadas pelo próprio
dispositivo.
A plataforma proposta, suportará as duas formas de cálculo do posicionamento.
Uma vez de�nido os requisitos que serão contemplados na plataforma proposta, é apre-
sentado na Tabela 6 uma síntese de quais dessas funcionalidades cada uma das soluções
de mercado se propõe a atender.
Tabela 6: Síntese dos requisitos funcionais contemplados pelas soluções de mercadoRequisitos Indoo.rs Nextome AnyPlace inlocomedia AccuwareRecuperar Mapa Sim Sim Sim Sim SimRecuperar posição de umalvo no mapa
Sim Sim Sim Sim Sim
Recuperar coisas localizáveispróximas
Não Sim Não Não Não
Cálculo do caminho entredois pontos no mapa
Sim Sim Sim Não Não
Cadastrar coisas Sim Sim Sim Sim NãoProver diferentes formas decálculo de posicionamento
Não Não Não Não Sim
4.3 Arquitetura Proposta
Na Figura 17 é apresentada a arquitetura geral da Plataforma IndoLoR. Pode-se per-
ceber que a mesma foi projetada para garantir o suporte as diversas fontes de informações
presentes nos mais diversos ambientes, assim como o suporte a toda essa heterogeneidade
de informações. Nota-se que a arquitetura geral pode ser dividida em três grandes grupos,
sendo estes: dispositivos móveis, sensores e a própria plataforma IndoLoR.
É possível notar que para os dispositivos móveis será provida uma API como recurso
para otimizar a utilização da plataforma proposta. Essa API proverá uma maneira padro-
nizada das aplicações realizarem a comunicação com a plataforma, além disso, fornecerá
uma interface padronizada para atender as funcionalidades implementadas nos requisitos
53
funcionais RF1, RF2, RF3, RF4 e RF5. Os dispositivos móveis, além de grandes consu-
midores, também serão grandes provedores de informação pois em sua grande maioria
dispõem de hardwares capazes de obter informações relativas ao ambiente em que estão
inseridos. As informações provenientes dos sensores de ambiente permitem que as abor-
dagens e algoritmos utilizados para se obter a localização de coisas em ambientes internos
utilizem o próprio meio em que o alvo está inserido e com isso seja possível diminuir a
taxa de erro e aumentar a con�abilidade das soluções.
Figura 17: Visão Geral da Plataforma IndoLoR
Por �m, o último grupo refere-se a própria plataforma cuja função é receber, proces-
sar, armazenar e disponibilizar os dados obtidos das diversas fontes de informações com
o objetivo de obter a localização de pessoas ou objetos em ambientes internos. Esta pla-
taforma dispõe de um conjunto de componentes pré-de�nidos, no qual todos permitem a
adaptação de suas funcionalidades, sendo assim novas abordagens, algoritmos ou técnicas
podem ser adicionadas sem que haja a necessidade da arquitetura base ser modi�cada.
Além disso, percebe-se que é de�nido um �uxo de informações dentro da plataforma ga-
rantindo que os componentes mesmo que adaptados executem de acordo com os seus
objetivos pré-de�nidos.
A plataforma IndoLoR é composta por 9 componentes padrões, em que cada um des-
ses componentes pode ter suas funcionalidades adaptadas por componentes adaptadores.
Cada um destes componentes padrões possui uma responsabilidade especí�ca, sendo estas
54
apresentadas em detalhes abaixo:
• IO Manager
É o componente de entrada para a plataforma, diferente dos outros componentes
padrões, trata-se de um componente em que suas adaptações disponibilizam as
interfaces de acesso com o meio externo. Quando esses componentes recebem as
solicitações provenientes do meio externo, realizam seu processamento inicial e a
repassam para este componente. Além disso, tem como objetivo atender o requisito
RNF2 pois permite a adaptação de suas funcionalidades para o recebimento de dados
qualquer de tipo de fonte de informação e de diferentes tipos de tecnologia.
Cada solicitação recebida pela plataforma segue um formato bem de�nido. Este for-
mato é apresetado na Figura 18. Cada um dos campos possui uma função especí�ca
no processamento e execução das operações dentro da plataforma. Detalhando cada
desses campos tem-se:
� Requisição: Neste campo deverá ser indicado qual o tipo de solicitação da
requisição. Desta forma, uma vez de�nida o tipo da solicitação será possível
de�nir o componente padrão da camada de processamento a que essa solicitação
será repassada.
� Versão: Indica qual a versão da funcionalidade que está sendo requisitada,
pois as funcionalidades da plataforma podem necessitar de evolução, porém
nem todas as aplicações clientes podem ou devem evoluir em sincronia com a
plataforma.
� Tipo Dado: Este campo indicará ao componente de processamento, dentre os
serviços registrados no seu contexto qual deverá processar a solicitação.
� Operação: Indica qual operação deverá ser executada para realizar o proces-
samento da solicitação em um componente adaptador.
� Dados: Conterá os dados que devem ser utilizados no processamento das ope-
rações da Plataforma.
Figura 18: Campos do bloco de dados suportado pela Plataforma
• Request Manager
55
Este componente tem como função identi�car o tipo de solicitação enviada a pla-
taforma e a encaminhar para o componente padrão realizar seu processamento,
diferente do componente IO Manager que apenas recebe a solicitação do meio ex-
terno e a repassa. Por padrão, a plataforma disponibiliza cinco tipos de solicitações
possíveis, os quais são apresentados na Tabela 7 com os respectivos componentes
padrões que os processam.
Tabela 7: Tabela com os possíveis tipos de solicitações e os componentes padrões que asprocessam
Tipo de Solicitação Componente Padrão
MAP Map ManagerTHINGS Things ManagerLOCATION Location ManagerPUBLICATION Data Publication ManagerEVENT Event Manager
• Data Publication Manager
É o componente responsável por permitir que os dados produzidos na plataforma
possam ser acessados pelas aplicações clientes. Este componente realizará a dispo-
nibilização das informações recebidas e geradas pela plataforma fazendo uso dos
provedores de conteúdo providos pelo componente Data Storage Manager para
disponibilizar essas informações.
• Map Manager
Caso o tipo da solicitação seja relativa ao domínio de mapas, este é o componente
responsável por receber a solicitação, transformar a informação para este domínio e
invocar o serviço que irá realizar o processamento da solicitação. Este componente é o
responsável por prover os serviços para o cadastro de mapas, recuperá-los, cadastrar
e recuperar pontos de interesse (SIMON; FRÖHLICH; ANEGG, 2006) associados aos
mesmos, entre outros.
• Location Manager
Este é componente principal da plataforma sendo o responsável por realizar os re-
quisitos RF2, RF3, RF4 e RF6. As adaptações deste componente devem possuir três
comportamentos a serem executados. O primeiro é o de realizar a transformação das
informações recebidas em dados que possam ser processados pelo componente. A se-
gunda é uma vez que a informação está um formato em que o componente consegue
processá-la, o componente adaptador deverá identi�car a melhor estratégia para o
56
processamento dessas informações. Em que nesse processamento, pode-se utilizar
diferentes algoritmos de localização, a combinação deles ou apenas algoritmos para
fusão de informações gerando novos tipos de informações. Por último, as informações
recebidas e processadas devem ser enviadas para armazenamento para que outras
funcionalidades possam fazer uso delas.
• Event Manager
Este componente permite que seja utilizado o modo de interação Push, para enviar
informações para os dispositivos de maneira assíncrona, sendo possível realizar o
registro de serviços que permitam o cadastro de eventos. Quando o evento cadastrado
acontecer, é gerada uma noti�cação para os interessados. No intuito de otimizar a
utilização de recursos como tráfego de rede e processamento, essas noti�cações são
realizadas de maneira assíncrona.
• Things Manager .
Este componente é o responsável pela parte administrativa da plataforma sendo
o responsável pelo cadastro, alteração e remoção das �coisas� necessárias para o
funcionamento da plataforma. Essas coisas podem ser: Equipamentos dos ambientes,
dispositivos, dados administrativos, entre outros. Dessa forma, é o responsável por
realizar o requisito RF5.
• Data Storage Manager
Este componente tem como função servir como um repositório de serviços de arma-
zenamento. Os componentes padrões da plataforma informam o tipo de dado que
desejam manipular e recebem o serviço que realiza todos os procedimentos de per-
sistência. Dado o caráter adaptável da plataforma, é possível acoplar a cada serviço
uma estratégia de armazenamento diferente, ou seja, pode ser utilizada a estratégia
que melhor atender o tipo de dados a ser consumido ou armazenado. Dessa forma,
este componente auxilia para que possam ser atendidos os requisitos RNF3 e RNF4.
4.3.1 Descrição da Arquitetura
Com o objetivo de descrever a arquitetura proposta para a plataforma serão apresen-
tadas as principais visões arquiteturais de�nidas por Clements et. al. (CLEMENTS et al.,
2002), sendo elas: visão estrutural ou de módulos (do inglês, Module View) e a visão de
componentes e conectores (do inglês, Component-and-Connector View).
57
4.3.1.1 Visão de Módulos
Esta visão apresenta a arquitetura em módulos, em que estes podem ser unidades de
código que implementam alguma funcionalidade, da mais alta como pacotes até a mais
baixa granularidade como classe, interfaces, entre outros. Essa visão tem como objetivo
apresentar a organização das unidades de implementação e a relação de dependência que
existe entre elas. Na Figura 19 é apresentada a visão de módulos da Plataforma utilizando
a UML.
Figura 19: Visão de módulos da Arquitetura
O estereótipo �usa� é utilizado com o intuito de indicar que um módulo A usa de um
módulo B. Esse comportamento representa um relacionamento dependência em que A de-
pende do funcionamento correto de B para satisfazer seus próprios requisitos (CLEMENTS
et al., 2002). Com essa visão percebe-se claramente que existe uma separação em camadas
na arquitetura da plataforma, para representar essa visão Clements et. Al. (CLEMENTS
et al., 2002) de�ne o estilo arquitetural em camadas. A Figura 20 apresenta a arquitetura
utilizando o estilo em camadas.
A plataforma é dividida em três camadas, em que a camada de entrada e saída
possui a interface com o meio externo, obtendo e enviando informações. A camada de
processamento que recebe os dados provinientes da camada anterior, análisa que com-
ponente será o responsável pelo seu processamento e o encaminha. Esta última, tem como
58
Figura 20: Apresentação da Arquitetura da Plataforma utilizando o estilo em camadas
função realizar todos os procedimentos referentes ao processamento das solicitações rece-
bidas podendo necessitar dos componentes providos pela camada de armazenamento
para recuperação ou inserção de informações.
Ao de�nir as camadas, é necessário prover uma API para que haja a comunicação
entre elas. De forma que, uma camada fornece um serviço para a camada imediatamente
inferior. Diante disso, a Figura 21 apresenta o API de utilização disponibilizada para cada
uma das camadas . A camada de entrada e saída expõe um serviço que recebe o mapa
de dados proveniente das requisições, de modo que os recebidos por essa camada não
possuem tratamento algum, sendo repassados para a camada imediatamente superior, a
camada de processamento. Essa camada dispõe de uma interface que recebe os dados
brutos e o tipo de solicitação realizada. Internamente será feito o despache para que um
componente realize o processamento. A camada de armazenamento, dispõe de uma
interface que prover os repositórios de dados para que os componentes da camada de
processamento possam ter acesso aos mesmos.
Figura 21: API das camadas da plataforma
59
4.3.1.2 Visão de Componentes e Conectores
A visão de componentes e conectores apresenta como o sistema está estruturado em
seus conjuntos de elementos em relação ao comportamento e interações em tempo de exe-
cução (CLEMENTS et al., 2002). Essa visão possibilita o entendimento do funcionamento da
plataforma pois diversos componentes arquiteturais podem ser melhor entendidos quando
tem seu comportamento analisado considerando a sua execução. Na Figura 22 é apresen-
tado o diagrama UML que representa essa visão.
Figura 22: Visão Arquitetural de Componentes e Conectores
No momento em que a execução da plataforma é iniciada, cada componente é ini-
60
cializado pelo framework OSGI de maneira que existe apenas uma instância para cada
componente em tempo de execução. Além disso, todos os componentes da plataforma
não armazenam estado, ou seja, não armazenam informações entre uma execução e outra.
Essa característica minimiza o seu tempo de utilização, além de aumentar a escalabilidade
(ERL, 2008). Cada um desses componentes executa na thread principal, porém a plata-
forma tem seu ambiente de execução multithreading pois para cada solicitação recebida a
partir de um cliente externo a plataforma inicia uma thread que será a responsável por
percorrer todo �uxo no interior da plataforma, disponibilizando ao �nal a resposta para
o cliente.
O modo de comunicação entre os módulos da plataforma é realizado de maneira sín-
crona. Essa escolha se deu pelo fato de como cada solicitação proveniente dos clientes
externos já executar em uma thread especifíca não há como um bloqueio em uma deter-
minada solicitação afetar o desempenho ou a execução de outra.
4.3.2 Processo de Adaptação
Para que a plataforma possua a capacidade de permitir a adaptação de suas funcio-
nalidades dos seus componentes é necessário de�nir como esse processo deve acontecer. A
Figura 23 descreve o processo de adaptação.
Todos componentes apresentados são instâncias de serviços, sendo os que se encontram
ao lado esquerdo do componente Service Registry, os componentes padrões de�nidos
pela plataforma, e os apresentados no lado direito são exemplos de componentes adapta-
dores. O componente central Service Registry é provido pelo OSGI e atua como um
diretório de serviços, ou seja, ele contém a instância para todos os serviços registrados no
contexto da plataforma. Desta forma, uma vez que um determinado componente necessita
utilizar as funcionalidades implementadas por um serviço, solicitará a este componente e
o mesmo proverá a instância para o serviço solicitado. Dessa forma, nunca haverá acesso
direto entre os componentes da plataforma, garantindo que todos os componentes es-
tão desacoplados em termos de implementação. Essa garantia permite que a plataforma
possua um comportamento totalmente adaptável dado que apenas será conhecida a im-
plementação de determinada funcionalidade em tempo de execução.
O processo de adaptação das funcionalidades dos componentes padrões é apresentado
na Figura 24. Cada componente permite a adaptação de suas funcionalidades utilizando o
padrão de projeto conhecido como Whiteboard Pattern (KRIENS; HARGRAVE, 2004). Em
que ao invés do componente padrão buscar em um diretório o serviço que implementa
61
Figura 23: Forma de adaptação dos componentes
a funcionalidade solicitada, o mesmo registra o interesse em serviços que implementem
a adaptação de suas funcionalidades. Assim, sempre que um componente adaptador se
registrar no diretório de serviços, é veri�cado se existe algum componente padrão que
possua interesse no mesmo. Caso exista, este componente é noti�cado. Ao receber essa
noti�cação, o componente padrão garante o acesso a instância do serviço registrado pelo
componente adaptador.
Figura 24: Processo de Adaptabilidade
62
4.3.3 API para dispositivo móvel
Visando facilitar o desenvolvimento foi construída uma API para abstrair o processo
de comunicação entre o dispositivo móvel e a plataforma. Além disso, a mesma possuí as
diversas operações presentes na plataforma sem que haja a necessidade dos desenvolve-
dores conhecerem como realmente ocorre o �uxo de mensagens entre as aplicações cliente
e a plataforma. A Figura 25 apresenta o diagrama de classes da API construída para o
sistema operacional móvel Android.
Figura 25: Diagrama de Classes da API
A API disponibiliza as classes para acesso as funcionalidades de todos os componen-
tes padrões de processamento. Para a comunicação entre o dispositivo móvel e a plata-
forma foi implementada a classe Communication. Esta classe possuí a implementação do
método sendData, no qual é o responsável por enviar as solicitações para a plataforma.
Dessa forma, todas as classes especi�cas da API devem ser especialização dessa classe.
Para cada classe especializada existe um conjunto de métodos para operações implemen-
tadas pelos componentes adaptadores presentes na plataforma. É importante ressaltar
que é possível que os desenvolvedores de aplicações possam criar novos comportamentos
para a API de acordo com as novas funcionalidades disponibilizadas pela plataforma.
4.3.4 Padrões Arquiteturais Adotados
Esta seção apresenta os padrões arquiteturais utilizados na plataforma proposta.
4.3.4.1 Arquitetura Orientada a Serviços
Todos os componentes da plataforma são de�nidos como serviços utilizando os padrões
arquiteturais de�nidos para uma Arquitetura Orientada a Serviços. Em que essa tipo de
arquitetura propõe um estilo para construção de softwares através de uma combinação
de serviços (KOMODA, 2006). De acordo com OASIS (MACKENZIE et al., 2006) um serviço
63
é um mecanismo que permite acesso à uma ou mais capacidades, sendo o acesso provido
por uma interface pré-estabelecida e é exercido de acordo com as restrições e políticas
especi�cadas na descrição do serviços.
Uma arquitetura SOA de�ne um conjunto de princípios que devem ser seguidos como
(ERL, 2008):
• Padronização � Contratos de serviços devem seguir os mesmos padrões de projeto
estabelecendo um inventário de serviços padronizado;
• Baixo acoplamento � Serviços tendem a ser fracamente acoplados, ou seja, em geral,
são desacoplados de seu ambiente adjacente, não apresentando dependências com
outros serviços e consumidores;
• Abstração � Apenas informações realmente necessárias para que o serviço seja fun-
cionalmente útil aos consumidores são publicadas nos contratos de serviços. Serviços
abstraem uma lógica e aspectos funcionais de seus clientes;
• Reuso � Serviços contêm e expressam lógica e podem ser considerados recursos
reutilizáveis de uma organização;
• Autonomia � Devido às características anteriores, serviços têm a con�abilidade, o
desempenho e previsibilidade comportamental para suportar a execução autônoma,
exercendo um alto controle sobre a lógica e recursos em tempo de execução;
• Independência de Estado � Serviços são projetados para minimizar o tempo em
que eles existem em uma condição de dependência de informações de estado, de
modo que, a lógica do serviço leva à realização de uma ação com o estado atual da
informação, o que aumenta a escalabilidade do serviço;
• Visibilidade � Serviços são desenvolvidos para serem automaticamente descober-
tos e efetivamente interpretados, de modo que seu propósito e capacidades sejam
compreendidas claramente;
• Composibilidade � Serviços podem participar de composições, tornando �exível a
construção de processos independentemente do tamanho e complexidade.
Os serviços disponibilizados pela plataforma seguem a risca os princípios de�nidos, em
que todos os serviços possuem uma padronização através da utilização de uma interface
comum a todos. Os serviços possuem baixo ou nenhum acoplamento pois o componente
64
Service Registry é o responsável por prover as implementações dos serviços provedores
(componentes adaptadores) para os serviços consumidores (componentes padrões). Esses
consumidores não necessitam saber como é implementado um serviço, dessa forma é ex-
posto apenas as interface de acesso de�nida no momento de seu registro, garantindo a
abstração.
O reuso de serviço é realizado constantemente na plataforma, um exemplo é a utili-
zação dos serviços de armazenamento em que esses serviços são utilizados por diversos
componentes da arquitetura. Todos os serviços são autônomos e autocontidos o que ga-
rante a independência de execução do mesmo. A arquitetura da plataforma por padrão
suporta a composição de diversos serviços seja para processamento de dados, utilização de
diferentes algoritmos de posicionamento ou combinação dos mesmos, além disso possibilita
a utilização de algoritmos que permitem a fusão de informações.
4.3.4.2 Publish/Subscribe
O paradigma publish/subscribe fornece um fraco acoplamento de interação entre enti-
dade em larga escala (EUGSTER et al., 2003). Os Subscritores (subscribers) são entidades
que expressam interesse em um evento ou em um padrão de eventos, com o objetivo de ser
noti�cado quando um desses eventos acontecer. Normalmente gerado por um publicador
(publisher). Um evento é propagado de forma assíncrona para todos os subscritores que
registraram um interesse. Este estilo arquitetural de interação fornece um desacoplamento
entre produtores e consumidores de serviços. Garantindo dessa forma, a manutenção das
formas de interação nas seguintes dimensões: no tempo (publicadores e subscritores não
precisam estar ativos na interação ao mesmo tempo), espaço (publicadores e subscritores
não precisam conhecer um ao outro) e �uxo (publicadores e subscritores não precisam
estar sincronizados para interagir). A Figura 26 apresenta o estilo arquitetural publish/-
subscribe.
Fazendo uma analogia com os componentes presentes na arquitetura, os componentes
padrões são os subscritores pois registram o interesse em eventos do tipo registro de
serviços. Por sua vez, os componentes que realizem a adaptação de funcionalidades são os
publicadores pois ao serem instanciados e se registrarem como serviços ativos um evento de
registro será gerado. Dessa forma, o componente que armazenará, gerenciará e noti�cará
todos os envolvidos é o componente Service Registry atuando como o diretório de serviços.
65
Figura 26: Estilo de Arquitetura Publish/Subscribe adaptado de Eugster et. Al. (EUGSTERet al., 2003)
4.3.4.3 Padrão em Camadas
O padrão de arquitetura em camadas auxilia na estruturação de aplicações, agrupando
módulos com resposabilidades semelhantes em camadas lógicas (BUSCHMANN; HENNEY;
SCHIMDT, 2007). A comunicação entre as camadas deve ser unidirecional, e para isso
cada uma das camadas deve de�nir uma interface de acesso. Um dos princípios básicos
da arquitetura em camadas é que uma modi�cação em camadas inferiores não represente
impactos nas camadas superiores. Essa característica garante a independência entre as
camadas. As principais vatagens de utilizar este estilo de arquitetura são: Promove a
modi�cabilidade, portabilidade e reuso; Diminiu a complexidade das aplicações para as
modi�cações a serem realizadas pelos desenvolvedores e realiza a separação de interesses
para cada parte dos sistemas (CLEMENTS et al., 2002).
Na plataforma proposta é possível identi�car claramente a separação de interesses
entre os seus módulos, de forma que os módulos que possuem os mesmos interesses podem
ser agrupados uma mesma camada. Além disso, o �uxo de informação entre as camadas da
plataforma sempre acontece de maneira uniderecional, ou seja, nenhuma camada inferior
utiliza uma camada superior. A Figura 27 apresenta como se dá o �uxo de comunicação
entre as camadas da arquitetura.
66
Figura 27: Comunicação entre as camadas da Arquitetura da Plataforma IndoLoR
4.4 Implementação
Nesta seção são apresentados os detalhes da implementação da plataforma proposta, a
qual foi desenvolvida utilizando o framework OSGi. Essa tecnologia tem por característica
facilitar o desenvolvimento de software modulares na linguagem de programação Java
devido ao fato da mesma proporcionar vários benefícios relacionados aos aspectos de
adaptabilidade, além de proporcionar o modelo de implementação orientado a serviços
(HALL et al., 2011).
Logo, esta seção pretende fornecer um detalhamento da implementação da plata-
forma, no que tange seus componentes padrões e especí�cos. Dessa forma, a Seção 4.4.1
descreve os componentes comuns, a Seção 4.4.2 apresenta a descrição de implementação
dos módulos padrões e a Seção 4.4.3 especí�ca os componentes adaptadores.
4.4.1 Componentes Comuns
Para garantir a forma padronizada de acesso e disponibilização das funcionalidades
presentes na plataforma, foi construído um conjunto de interfaces e classes abstratas. A
Figura 28 apresenta o diagrama de classes que ilustra essas entidades e o relacionamento
entre elas. É importante ressaltar que todos os componentes da plataforma proposta,
sejam componentes padrões ou componentes adaptadores, dependem de algumas dessas
classes e interfaces.
Com o objetivo de de�nir uma forma de acesso comum a todos os serviços disponíveis
na plataforma foi de�nida uma interface base chamada de IndoorService. Para garantir
este comportamento foi de�nido o método executeService, em que o mesmo aceita como
parâmetro um objeto do tipo RawData. Os objetos desta classe, representam as infor-
67
Figura 28: Diagrama de Classes Base Plataforma
mações recebidas a partir do mundo externo, ou seja são os dados brutos recebidos pela
plataforma. Esses dados, porém, podem ser especializados para que os componentes pos-
sam manipula-los da forma correta. Sendo assim, a plataforma de�ne que os dados a serem
recebidos devem possuir o formato de�nido na Figura 18 para a troca de informações com
o meio externo.
Exempli�cando a utilização do pacote de�nido e esperado pela plataforma, é apresen-
tada a Figura 29. O campo Requisição possui o valor THINGS que representa a soli-
citação deverá ser tratada pelo componente padrão ThingsManager. No campo Tipo
Dado é informado o tipo de dado que deverá ser processado pela plataforma, sendo assim
deverá existir um serviço que suporte o mesmo. No exemplo abaixo, é informado que o
tipo de dado a ser processado é do tipo WIFI_AP. No campo de Operação é de�nido
o valor INSERT, sendo assim a operação a ser executada pelo componente adaptador é a
de inserção. O campo de Dados contém os dados necessários para a execução da opera-
ção, em que neste exemplo é o cadastro da localização �síca de um Access Point em um
determinado mapa.
Figura 29: Bloco de dados exemplo para comunicação com a Plataforma
Uma vez de�nida a interface base para todos os serviços a serem utilizados pela pla-
taforma, foi necessário de�nir uma forma de separar os serviços padrões providos pela
plataforma e os serviços que implementam funcionalidades para adaptar estes componen-
tes padrões. Sendo assim, a plataforma dividiu os serviços em duas categorias, os serviços
internos que devem obrigatoriamente estender a classe abstrata InternalIndoorService e
o serviços externos que obrigatoriamente devem estender a classe abstrata ExternalIndo-
68
orService.
Os serviços internos são disponibilizados pelos componentes padrões, no qual para
cada componente desse existe apenas um serviço interno disponibilizado. Esses serviços são
os responsáveis por receber as solicitações e identi�car para qual serviços externos a mesma
será repassada para processamento. Dessa forma, para a inclusão de novas capacidades
não é necessária nenhuma alteração no código-fonte da plataforma. Então para prover a
adaptação é necessário que o serviço interno indique quais os tipos de serviços ele suporta,
e isso deve ser feito a partir da implementação de um �ltro a ser provido pela operação
getFilter.
A Listagem 1 apresenta um exemplo da criação de um �ltro para o componente padrão
RequestManager. Este �ltro indica que todos os serviços que possuírem uma propri-
edade que seja exatamente igual a �requestManager.id� e forem registrados no Service
Registry, o componente RequestManager deverá ser noti�cado e receber a implementa-
ção desse serviço. A sintaxe utilizada nos �ltros de�nida pelo OSGI é baseada diretamente
dos �ltros de busca do LDAP (WAHL; HOWES; KILLE, 1997).
1 public Filter getFilter () throws Exception {
2 return getContext ().createFilter("(requestmanager.id=*)");
3 }
Listagem 1: Exemplo do Método getFilter de InternalIndoorService que cria um �ltro
Com o intuito de facilitar a reusabilidade de código, a classe abstrata InternalIndoor-
Service disponibiliza a implementação de uma operação protegida chamada de getServi-
ceListFiltered que retorna a lista de serviços registrados no componente ServiceRegistry
que satisfazem a condição de�nida pelo �ltro implementado no método getFilter.
Para ilustrar a construção de um serviço externo é apresentada a Listagem 2. Pelo
fato destes serviços serem �lhos da classe ExternalServiceIndoor é necessário prover a im-
plementação das operações abstratas. A operação getMapProperties deverá conter todas
as propriedades relativas ao serviço adaptador. Devendo ser informado obrigatoriamente
o tipo de componente padrão que este serviço irá adaptar (Linha 10) e o tipo de dado
que o mesmo irá processar (Linha 11). Opcionalmente, é possível de�nir quais serviços de
persistência esse componente adaptador necessita (Linha 12) para realizar o seu proces-
samento. Além disso, todo serviço externo deve indicar quais dados o mesmo deverá ter
permissão de acesso através da implementação da operação getPermissions.
1 public class ThingsManagerService extends ExternalIndoorService{
2
69
3 public ThingsManagerService(BundleContext context) {
4 super(context);
5 }
6
7 public Dictionary <String , Object > getMapProperties () {
8 Dictionary <String , Object > map = new Hashtable <String ,
Object >();
9
10 map.put("platforma.indoor.thingsmanager", this.getClass
().getName ());
11 map.put("platforma.indoor.datatype", "WIFI_AP");
12 map.put("platforma.dataProviderURL", "ThingsProvider");
13
14 return map;
15 }
16
17 public Dictionary <String , Object > getPermissions () {
18 Dictionary <String , Object > map = new Hashtable <String ,
Object >();
19 map.put("platforma.indoor.permissions", "ROLE_WIFI_AP");
20 return map;
21 }
22 }
Listagem 2: Exemplo da implementação de Serviço Externo
4.4.2 Componentes Padrões
Os componentes padrões possuem essa de�nição pois são aqueles que fazem parte
do �uxo padrão de processamento de informações na plataforma. Porém, eles não realizam
o processamento propriamente dito, cuja a atribuição é de competência dos componentes
Adaptadores registrados para cada um deles. Dessa forma, eles recebem as solicitações,
veri�cam se há algum serviço que processe a solicitação, veri�ca se o mesmo possuí a per-
missão para o tipo de dado da solicitação e caso a veri�cação seja verdadeira a solicitação
é repassada ao componente Adaptador para que possa ser processada.
A Figura 30 apresenta uma representação genérica do diagrama de classes para os
componentes padrões. De maneira geral, estes componentes de�nem o seu serviço
principal sendo o responsável por realizar todo o processo encaminhamento das solicitações
para processamento. Além disso, se subscrevem para serem noti�cados sempre que serviços
70
que implementem adaptacões de suas funcionalidades são registrados.
Figura 30: Diagrama de Classes genérico para um Componente Padrão
Um componente padrão possui um serviço principal sendo este uma especialização
de InternalIndoorService, o qual a Listagem 3 ilustra um exemplo desta implementação.
Além disso, é necessária a de�nição de uma classe Activator, a Listagem 4 ilustra um
exemplo desta de�nição, cuja função é criar a instância do serviço e registrá-lo no com-
ponente Service Registry para que a mesma possa ser acessada por outro componente
padrão da plataforma.
No entanto, existe um componente padrão que seu funcionamento difere em relação
aos demais, trata-se do IOManager pois diferente dos demais que recebem a solicitação e
repassam as solicitações os componentes adaptadores realizarem o processamento. No caso
deste componente o funcionamento será invertido, seus componentes adaptadores possuem
contato com o meio externo recebendo as solicitações e uma vez recebidas as mesmas são
repassadas para o IOManager e este repassa para a camada direcionamento.
1 public class InternalMapManagerService extends InternalIndoorService{
2
3 public InternalMapManagerService(BundleContext context) {
4 super(context);
5 }
6
7 public Object executeService(RawData data) {
8 ...
9 }
10
11 public Filter getFilter () throws Exception {
12 return getContext ().createFilter("(plataforma.indoor.
mapmanager =*)");
13 }
71
14 }
Listagem 3: Exemplo da implementação de um serviço para um Componente Padrão
1 public class Activator implements BundleActivator {
2
3 public void start(BundleContext context) throws Exception {
4 InternalMapManagerService service = new
InternalMapManagerService(bundleContext);
5 bundleContext.registerService(InternalMapManagerService.
class , service , null);
6 }
7
8 public void stop(BundleContext context) throws Exception {
9 }
10 }
Listagem 4: Exemplo da implementação de Activator para um Componente Padrão
4.4.3 Componentes Adaptadores
Esses componentes recebem esse nome pois realizam a adaptação de funcionalidades
para os módulos padrões da plataforma. Na Figura 31 é apresentado o diagrama de classes
para um componente adaptador genérico a ser utilizado pela plataforma.
Figura 31: Diagrama de Classes genérico para um Componente Adaptador
Um componente adaptador deve possuir uma classe Activator que será a respon-
sável por criar a instância do serviço, registrá-lo informando as propriedades que o mesmo
possuí. A Listagem 5 apresenta um exemplo da implementação de Activator para um
Componente Adaptador. Em que os serviços a serem registrado por este componente
deverão ser especializações da classe abstrata ExternalIndoorService. Além disso, essa
72
classe registrará o serviço no diretório de serviços para que o componente padrão ao qual
o mesmo está ligado possa acessá-lo. Um exemplo da implementação para criação de um
serviço para um Componente Adaptador foi apresentado na Listagem 2.
1 public class ExternalActivator implements BundleActivator {
2
3 public void start(BundleContext context) throws Exception {
4
5 ThingsManagerService service = new ThingsManagerService(
context);
6
7 context.registerService(ThingsManagerService.class ,
service , service.getMapProperties ());
8 }
9
10 public void stop(BundleContext context) throws Exception {
11 }
12
13 }
Listagem 5: Exemplo da implementação de Activator para umComponente Adaptador
73
5 Avaliação da Plataforma
Este capítulo apresenta a avaliação, sob diferentes aspectos, da plataforma IndoLoR
proposta no Capítulo 4. Com esse objetivo será descrito na Seção 5.1 um exemplo de
uso com o intuito de validar o funcionamento da plataforma IndoLoR para localização de
um dispostivo em um ambiente interno utilizando sinais de WIFI. Além disso, na Seção
5.2 é reportado um estudo de caso em que são avaliados aspectos de adaptabilidade e
performance da plataforma IndoLoR.
5.1 Exemplo de uso: Localização Indoor utilizandoWIFI
Para validar a implementação e avaliar o funcionamento da plataforma é proposto um
cenário em que a localização de coisas deverá acontecer através do uso da informação da
potência dos sinais de WIFI recebidos em um determinado dispositivo móvel. Para reali-
zar essa validação, são apresentados na Figura 32 todos os componentes Adaptadores
que foram implementados para esse propósito, sendo eles: WIFIService, LocationDataPu-
blicationService, WIFILocationStorage.
Para realizar este exemplo, além da implementação dos componentes adaptadores
da plataforma, foi necessária a implementação de um aplicativo para dispositivo móvel
com o objetivo de obter os dados de WIFI presentes no ambiente, os quais são apresentados
na Figura 33.
Detalhando cada uma dessas informações obtidas pelo dispositivo móvel, têm-se:
• timestamp - Indica a data e hora em que o dado foi obtido.
• frequency - Indica a frequência utilizada pelo access point para transmissão dos
dados.
• level - Indica a potência do sinal recebido.
• BSSID - Indica o endereço MAC da placa de rede presente no access point.
74
Figura 32: Cenário para a Prova de Conceito
• SSID - Indica o nome da rede utilizada pelo access point.
Uma vez obtidas essas informações, o dispositivo móvel as envia para a plataforma.
Desta forma, será possível obter a localização do dispositivo no ambiente apresentando a
sua rota percorrida. O ambiente escolhido para este exemplo, foi um dos andares do prédio
do Instituto Metrópole Digital (IMD) , o qual é uma unidade acadêmica pertencente a
Universidade Federal do Rio Grande do Norte. Este ambiente é bastante amplo, porém
dispõe de apenas 6 access points, de modo que foi aproveitada a infraestrutura existente
para a execução desse exemplo de uso. Vale salientar que nenhuma con�guração adicional
foi realizada, de maneira que utilizou-se os dados dos access points com sua con�guração
disponível ao público geral.
5.1.1 Plataforma IndoLoR utilizando WIFI
Para que fosse possível obter a localização utilizando a plataforma foi necessário reali-
zar a implementação dos diversos componentes adaptadores associados a cada um dos
componentes padrões, entre eles: Location Manager, Data Publication Manager e Data
Storage Manager. A seguir são apresentados os detalhes para cada um dos componentes
adaptadores construídos para este exemplo de uso.
75
Figura 33: Dados de WIFI obtidos pelo Smartphone a serem enviados para a plataforma
5.1.1.1 Data Publication Manager
O serviço Location Data Publication Service foi criado como adaptação a este compo-
nente, tendo como objetivo prover os dados de localização calculados para um dispositivo.
Sendo assim, será possível recuperar a posição atual de um determinado dispositivo, além
do seu histórico.
Na Figura 34 é apresentado o formato de saída produzido por este como resposta as
solicitações das aplicações clientes.
Figura 34: Dados enviados como resposta a solicitação dos clientes pelo dado de posicio-namento de um dispositivo
Onde:
76
• deviceId � Representa o identi�cador único do dispositivo.
• x � O posicionamento do dispositivo no eixo x.
• y � O posicionamento do dispositivo no eixo y.
• mapId � Representa o identi�cador único do mapa.
• histórico � Apresenta a lista dos últimos posicionamentos obtidos para o dispositivo.
5.1.1.2 Location Manager
Para este componente foi implementado o serviço adaptador chamado de WIFI Loca-
tion Manager que será responsável por processar os dados dos access points provenientes
do smartphone e executar um algoritmo com o objetivo de estimar a posição do mesmo.
O serviço WIFI Service necessita como entrada das informações do identi�cador do
mapa e da lista de informações dos access points sendo elas: SSID, MAC e potência dos
sinais presentes no ambiente. Além disso, a lista de access points conhecidos com as suas
respectivas posições é recuperado no mapa através do componente Data Storage Manager.
De posse dessas informações é executado o algoritmo Weighed Centroid (KONRAD,
2012) (HAN et al., 2009), em que o posicionamento estimado utilizando coordenadas (x,y)
é obtido a partir do cálculo do centroide geométrico formado por todos os access points.
Com essas coordenadas iniciais obtidas é realizado um ajuste de acordo com à intensidade
do sinal.
Por �m, são armazenados os valores do posicionamento calculado, assim como os
dados de entrada recebidos utilizando o serviço WIFI Location Storage. É retornado como
resposta para o cliente os dados das coordenados calculadas.
5.1.1.3 Data Storage Manager
Este componente é o responsável por realizar o armazenamento e recuperação das
informações presentes na plataforma. Dado o caráter adaptável da plataforma é possível
que cada componente possua sua próprio ambiente de persistência, ou seja, para cada
componente adaptador é possível existir uma forma de armazenamento diferente. Para
este exemplo de uso, todos os componentes utilizaram a mesma forma de persistência. A
forma escolhida foi utilizar de um banco de dados não-relacional chamado MongoDB
(MONGODB, 2015).
77
Uma vez de�nida a forma de persistência, foi implementado um componente adap-
tador chamado de WIFI Location Storage em que este será responsável por armazenar e
recuperar as informações de posicionamento calculadas pelo algoritmo de�nido no com-
ponente adaptador de localização (WIFI Service).
5.1.2 Aplicativo para dispositivo móvel
Como aplicação cliente e provedora de dados para o exemplo de uso, foi necessário
construir um aplicativo móvel que fosse capaz de obter os dados referentes aos sinais
de WIFI presentes no ambiente. Além disso, deve ser possível cadastrar mapas, access
points presentes no ambiente e apresentar a rota calculada pela plataforma IndoLoR para
um determinado dispositivo apresentando-a no mapa do ambiente inserido na própria
plataforma.
Para validar toda implementação realizada, foi executado um teste de caminhada
dentro do IMD. Na Figura 35 é apresentado o resultado da execução deste testes. É apre-
sentado o mapa do ambiente com duas rotas percorridas, cuja linha tracejada representa
a rota real percorrida pelo usuário. Já a linha sólida representa a localização calculada
pelo algoritmo descrito na Seção 5.1.1.2. É importante explicar que este exemplo de uso
não levou em consideração a precisão obtida pelo algoritmo e sim a validação do funciona-
mento da plataforma com a sua arquitetura proposta. No entanto, a Figura 35 apresenta
quatro pontos de checagem de�nidos pelas letras A,B,C e D, nos quais os verdes são os
esperados e os vermelhos os calculados.
5.1.3 Limitações
Esta prova de conceito apresentou algumas limitações, como o fato ter sido utilizado
apenas um local para sua execução. Dado que cada ambiente interno possui característi-
cas diferentes, a execução desta prova de conceito um ambiente diferente pode apresentar
valores bem diferentes dos encontrados. Uma outra limitação, se deu pelo fato apenas 6
access points terem sido utilizados, caso mais dispositivos desse tipo tivessem sido utili-
zados resultados diferentes poderiam ter sido encontrados. Além disso, a con�guração em
que os mesmos se encontram no ambiente, uns muitos próximos e outros muito afastados,
pode ser uma das causas do alto erro obtido no cálculo do posicionamento.
Um outro ponto limitante se deu por apenas uma tecnologia ter sido utilizada para
a obtenção do posicionamento de um dispositivo em ambiente interno. Este fato limitou
78
Figura 35: Aplicativo utilizando a API e a Plataforma adaptável para localização Indoor
a utilização de todas as capacidades providas pela plataforma. Além disso, apenas um
algoritmo de localização foi utilizado de modo que não é possível identi�car a causa do
alto erro encontrado.
No entanto, nenhuma das limitações mencionadas acima invalida a utilização da pla-
taforma IndoLoR, pois o seu objetivo principal foi alcançando. Em que foi possível enviar
e obter dados, realizar o cálculo do posicionamento de um dispositivo, além de possibilitar
o cadastro de mapas e dispositivos presentes no ambiente.
5.2 Estudo de Caso: Localização Indoor utilizandoWIFI
e RFID
Esta seção descreve um estudo de caso no qual a plataforma IndoLoR foi utilizada
com o objetivo de obter a localização de um dispositivo móvel em um ambiente interno
utilizando dados obtidos através de sinais de WIFI e RFID presentes no ambiente. Dessa
forma, este estudo tem como objetivo principal avaliar o grau de adaptabilidade, a faci-
lidade de criação adaptaões para atender novas funcionalidades e a capacidade de pro-
cessamento de solicitações. Por �m, o planejamento e descrição deste estudo seguiram
79
as diretrizes estabelecidas por (YIN, 2013), (KITCHENHAM; PICKARD; PFLEEGER, 1995) e
(RUNESON; HÖST, 2009).
5.2.1 Planejamento
O planejamento do estudo de caso inclui a descrição das questões de pesquisa, dos
sujeitos que participaram do mesmo, do objeto utilizado, das unidades de análise, dos
artefatos avaliados e dos critérios de avaliação, assim como dos procedimentos empregados
para coleta de dados.
5.2.1.1 Questões de pesquisa
Para alcançar o objetivo proposto, o estudo de caso deve responder às seguintes ques-
tões de pesquisa:
1. Qual o grau de adaptabilidade provida pela plataforma IndoLoR?
2. Criar uma adaptabilidade para plataforma IndoLoR é uma tarefa custosa?
3. O desempenho da plataforma é prejudicado quando os componentes padrões têm
suas funcionalidades adaptadas?
Objetivando responder as questões de pesquisa de�nidas, realizou-se a implementação
das adaptações para a plataforma IndoLoR, de modo que a mesma fosse capaz de obter
a localização de um determinado dispositivo utilizando sinais de WIFI e informações de
tags RFID presente no ambiente.
5.2.1.2 Sujeitos
A plataforma IndoLoR foi utilizada pelo próprio pesquisador, o qual possui experiência
no desenvolvimento de aplicações Java e OSGi. Portanto, o sujeito envolvido neste estudo
de caso é o próprio criador da plataforma.
5.2.1.3 Objeto
O objeto utilizado para esse estudo de caso foi a adaptação da plataforma IndoLoR
para obter a localização em ambientes internos utilizando dados WIFI e RFID, de maneira
combinada. Dessa forma, um dispositivo móvel obtém os dados de WIFI e RFID presentes
80
no ambiente, enviando-os para a plataforma a�m de que a mesma pudesse realizar o
processamento e calcular a posição estimada do dispositivo. Para tal, é necessário adaptar
os componentes de�nidos no Capítulo 4 de maneira que seja possível obter, armazenar,
processar e disponibilizar os dados provenientes das diferentes fontes. Uma vez que todo
o �uxo de processamento foi realizado pela plataforma, o novo posicionamento atual do
dispositivo móvel poderá ser obtido. A Figura 36 ilustra a descrição deste cenário.
Este cenário foi escolhido para este estudo pois trata-se da funcionalidade principal da
plataforma proposta. Além disso, esta funcionalidade é a operação que necessita de maior
processamento por parte da plataforma, pois além de obter as informações provenientes
do mundo externo, realiza a consulta a diversos dados e os processa. Assim, obtém a
localização de objetos ou pessoas.
Figura 36: Cenário da Adaptação da Plataforma IndoLoR utilizando WIFI e RFID
Para que este cenário possa funcionar corretamente, será utilizado um dispositivo mó-
vel que deverá coletar, através de um aplicativo, os dados dos sinais deWIFI disponibilizando-
os no formato JSON (CROCKFORD, 2006) contendo os atributos apresentados na Listagem
6. Dessa forma, é enviada a data e hora que o dado foi obtido, através do atributo times-
tamp; o atributo deviceID, representa o identi�cador único do dispositivo e uma lista de
informações a respeito de cada access point com os seguintes atributos: frequency informa
a frequência utilizada pelo access point para a transmissão dos dados, já o atributo level
contém a potência do sinal obtido pelo dispositivo, o atributo BSSID contém o endereço
81
MAC da placa de rede presente no access point e por último, o SSID indica o nome da
rede utilizada pelo access point.
1 {
2 "deviceID":"1",
3 "timestamp":1434325957601,
4 "aps":[
5 {
6 "frequency":2412,
7 "level":-52,
8 "BSSID":"c4:27:95:8c:7d:e8",
9 "SSID":"WIFI1"
10 },
11 {
12 "frequency":2417,
13 "level":-94,
14 "BSSID":"40:70:09:02:30:b0",
15 "SSID":"WIFI2"
16 },
17 ...
18 ]
19 }
Listagem 6: Dados dos access points coletados e enviados para a plataforma
Além dos dados coletados dos access points, o dispositivo móvel poderá coletar os da-
dos de tags RFID presentes no ambiente disponibilizando-as no formato JSON (CROCK-
FORD, 2006) contendo os atributos apresentados na Listagem 7. O atributo timestamp
e deviceID tem mesma descrição que os dados de WIFI coletados, já o atributo tagID
representa a o identi�cador único da tag cadastrada na plataforma IndoLoR.
1 {
2 "deviceID":"1",
3 "tagId":"123"
4 "timestamp":1434325957601
5 }
Listagem 7: Dados de WIFI coletados e enviados a plataforma
82
5.2.1.4 Unidades de análise
Este estudo de caso possui duas unidades de análise: a plataforma IndoLoR e a suas
adaptações para obter a localização em ambientes internos. A plataforma IndoLoR teve
seus componentes avaliados em relação a adaptabilidade provida. Além disso, teve ava-
liada a performance de seus componentes em relação ao tempo de processamento das
solicitações. As adaptações foram avaliadas em relação a facilidade de sua incorporação a
plataforma, além da avaliação do impacto da sua inclusão em relação ao desempenho da
plataforma IndoLoR.
5.2.1.5 Coleta de dados
Os seguintes dados foram coletados neste estudo de caso:
1. A quantidade de classes necessárias para realizar a adaptação de cada uma das
funcionalidades utilizadas neste estudo.
2. A quantidade de linhas de código totais e a quantidade de linhas que são necessárias
para incorporar os componentes adaptadores à plataforma.
3. Os tempos de processamento das solicitações pela plataforma IndoLoR sem que haja
nenhuma adaptação incorporada.
4. Os tempos de processamento das solicitações pela plataforma IndoLoR com todas
as adaptações incorporadas.
5. Os tempos de processamento das solicitações considerando apenas o tempo gasto
pelos componentes padrões quando há adaptações incorporadas.
5.2.2 Execução
Para obter a localização em um ambiente interno utilizando os dados WIFI e RFID
foi necessária a construção de componentes adaptadores, de forma que os mesmos fossem
incorporados à plataforma utilizando o processo de adaptabilidade de�nido na Seção 4.3.2.
A Figura 37 apresenta os componentes padrões da plataforma IndoLoR, juntamente com
os componentes adaptadores necessários para a correta execução deste estudo. Sendo eles:
WIFI Fusion Service, RFID Service, Location Data Publication Service, WIFI Location
Storage e RFID Location Storage
83
Figura 37: Implementação das Adaptações para a plataforma IndoLoR
Para tal, foi necessária a construção de componentes adaptadores para que fosse pos-
sível a plataforma receber, processar, armazenar e disponibilizar os dados do ambiente,
assim como os dados de posicionamento do dispositivo. Vale ressaltar, que os componen-
tes implementados seguem a estrutura de�nida na Seção 4.4.3. Detalhando cada um dos
componentes implementados, têm-se:
• Location Data Publication Service Este componente foi criado para prover a
adaptação da funcionalidade de disponibilização os dados de localização calculados
para um dispositivo. Sendo assim, será possível recuperar a posição atual de um
determinado dispositivo, além do seu histórico.
• RFID Service Este componente implementa a funcionalidade de processamento
dos dados obtidos pelo dispositivo das tags RFID presente no ambiente e enviados
para a plataforma. Em que os dados a serem processados devem possuir o formato
de�nido na Listagem 7. Ao receber essas informações, as mesmas são armazenadas
e um novo posicionamento é atribuído para o dispositivo.
• WIFI Fusion Service
Este componente realiza a implementação da funcionalidade de localização utili-
zando dados de WIFI e RFID. Em que para a sua correta execução, o mesmo como
entrada das informações de�nidas na Listagem 6.
Na Figura 38, é apresentado como se dá o processo do cálculo do posicionamento
do dispositivo utilizando dados de WIFI e RFID. O processo se inicia com o rece-
84
bimento dos dados de WIFI pela plataforma, em seguida é veri�cado se não existe
nenhum posicionamento obtido por RFID no último segundo, caso exista o cálculo
não é realizado e o posicionamento atual será o último obtido. Caso não exista, é
executado o algoritmo Weighed Centroid (KONRAD, 2012) (HAN et al., 2009), em
que o posicionamento estimado utilizando coordenadas (x,y) é obtido a partir do
cálculo do centroide do geométrico formado pelas coordenadas (x,y) de todos os
access points. Com essas coordenadas inicias obtidas, e um novo posicionamento é
atribuído para o dispositivo.
Figura 38: Processo do cálculo do posicionamento de um dispositivo utilizando uma abor-dagem dados heterogêneos
• WIFI Location Storage e RFID Location Storage Estes componentes tem
a função de realizar o armazenamento dos dados de WIFI e RFID recebidos pela
plataforma. A forma de persistência escolhida para armazenamento das informação
foi um banco de dados não-relacional chamado MongoDB (MONGODB, 2015).
Além da implementação dos componentes adaptadores, foi necessária a construção de
um aplicativo para dispositivo móvel Android cuja função é de obter os dados de WIFI
e RFID presentes no ambiente e enviá-los para a plataforma. Além disso, este aplicativo
funciona como um aplicativo cliente para a utilização dos dados providos pela plataforma
podendo dessa forma obter a sua localização provida pela mesma. A Figura 39 apresenta
este aplicativo com o resultado da localização do dispositivo no ambiente escolhido. Em
85
que este ambiente trata-se de um escritório com cerca de 115 m2 com 4 access points
previamente instalados e com con�gurações padrões. Além disso, em um dos cômodos foi
colocada uma tag RFID presa a uma das paredes.
Figura 39: Tela do Aplicativo Android exibindo o posicionamento do dispositivo no am-biente de escritório
É possível notar que na Figura 39 existe uma linha tracejada, esta linha representa a
rota efetivamente executada pelo dispositivo no ambiente. Além disso, é possível perceber
alguns pontos de destaque sendo representados pelas letras A,B,C,D e E. No qual estes
pontos representam os locais calculados pelo algoritmo utilizado neste estudo.
Após a implementação dos módulos adaptadores e o aplicativo para dispositivo móvel
responsável pela coleta dos dados do ambiente e consumo dos dados produzidos pela
plataforma, iniciou-se a etapa de avaliação da adaptabilidade e performance da plataforma
IndoLoR. Esta avaliação foi realizada em um computador com o sistema operacional
Windows 10, processador Intel (R) Core (TM) i7-4500U CPU @ 1.80GHz e 8,00 GB de
memória RAM.
Já adaptabilidade foi avaliada em duas facetas, em que a primeira é o grau de adapta-
bilidade provida pela plataforma IndoLoR, e a segunda leva em consideração a facilidade
de realizar a adaptação e a acoplar na plataforma. Para avaliar o grau de adaptabilidade
foi realizado o cálculo do Índice de Adaptabilidade da Arquitetura (Architecture Adaptabi-
lity Index (AAI)) de�nido por Subramanian e Chung (SUBRAMANIAN; CHUNG, 1999), em
que os autores de�nem que adaptabilidade de uma arquitetura de software pode acontecer
86
tanto para os componentes, quanto para os conectores, de maneira que estes elementos
tem o mesmo peso ou signi�cado na adaptabilidade. Diante disso, é de�nida a métrica do
Índice de Adaptabilidade do Elemento (Element Adaptability Index (EAI)), em que este
índice pode possuir dois valores: caso o elemento seja adaptável recebe uma unidade, caso
não recebe o valor zero. Sendo assim, o valor de AAI é dado pela Equação 5.1.
AAI =
∑ni=1 EAIi
Total de Elementos(5.1)
Onde:
• AAI - Índice de Adaptabilidade da Arquitetura
• EAI - Índice de Adaptabilidade do Elemento
• Total de Elementos - Soma do total de componentes e conectores
Então, a Equação 5.2 apresenta o resultado do cálculo do Índice de Adaptabilidade
da Arquitetura para a plataforma IndoLoR, em que a quantidade de conectores e compo-
nentes presentes na arquitetura foram obtidos na descrição da mesma na Seção 4.3. Como
a arquitetura da plataforma não permite que os conectores sejam adaptados, ou seja, a
comunicação entre os componentes é de�nida pela mesma não sofrendo modi�cação em
tempo de execução. Por outro lado, todos os componentes são passíveis de adaptação.
Diante disso, obteve-se como resultado do Índice de Adaptabilidade da Arquitetura da
plataforma IndoLoR o valor de 34%.
Conectores = 15
Componentes = 8
EAI = 8
AAI =8
15 + 8=
8
23= 0, 34 = 34%
(5.2)
Para avaliar a facilidade de adaptação de funcionalidades e incorporá-las na plata-
forma, foi coletado a quantidade de classes criadas em cada um dos componentes adap-
tadores utilizados neste estudo. Além disso, coletou-se a quantidade de linhas de códigos
totais para cada um dos componentes e o total de linhas de código necessário para a inco-
poração da funcionalidade provida pelo componente adaptador na plataforma. A Tabela
8 apresenta esses dados.
87
Tabela 8: Tabela contedo as quantidades de classes e linhas de código dos componentesadaptadoresComponente Classes Total de Linhas Total para Adaptação
WIFI Fusion Service 5 157 16WIFI Location Storage 4 127 9RFID Service 3 160 16RFID Location Storage 3 143 9Location Data PublicationService
4 117 14
Total 18 704 64
Para avaliar a performance da plataforma IndoLoR, foi realizada a medição do tempo
necessário para uma requisição ser totalmente processada em seu interior, sendo assim, é
medido o tempo despendido entre o momento em que a solicitação é recebida até a sua
resposta para o solicitante. Neste sentido, foi calculado o tempo médio que uma certa
quantidade de solicitações enviadas para a plataforma tem o seu processamento realizado.
Além disso, para cada quantidade de solicitações enviadas coletou-se dez amostras e, em
seguida, gerou-se a média geral para cada uma dessas amostras obedecendo a Equação
5.3.
m =10∑i=1
∑qsj=1 tj
qs(5.3)
Onde:
• m � representa a média geral;
• qs � representa a quantidade de solicitações;
• tj � representa o tempo de processamento para a solicitação j;
Desse modo, a Tabela 9 apresenta os valores do tempo médio (em milissegundos)
coletados para o processamento das solicitações com apenas os componentes padrões
da plataforma IndoLoR, ou seja, sem nenhum componente adaptador. Nas colunas são
mostrados os tempos médios referentes a cada quantidade de solicitações (Q.S.), a qual
varia de 1 até 1000000 solicitações. A linhas, por sua vez, indicam a amostra (Amost.)
em que tais tempos de processamento foram mensurados.
De maneira análoga, foi realizada um outro experimento coletando o tempo médio
apenas dos componentes padrões quando existem componentes adaptadores associados a
88
Tabela 9: Tempo de processamento das solicitações na plataforma IndoLoR utilizandoapenas os componentes padrões
Amost./Q.S. 1 10 100 1000 10000 100000 10000001 0,000 0,000 0,040 0,055 0,037 0,044 0,0422 0,000 0,000 0,030 0,053 0,043 0,042 0,0423 0,000 0,000 0,040 0,040 0,047 0,042 0,0414 0,000 0,000 0,030 0,041 0,040 0,043 0,0425 0,000 0,000 0,040 0,037 0,045 0,041 0,0426 0,000 0,000 0,040 0,043 0,042 0,042 0,0427 0,000 0,000 0,040 0,044 0,041 0,043 0,0428 0,000 0,000 0,030 0,035 0,040 0,042 0,0429 0,000 0,000 0,030 0,040 0,043 0,040 0,04210 0,000 0,000 0,020 0,028 0,041 0,042 0,042
Média 0,000 0,000 0,034 0,042 0,042 0,042 0,042
plataforma, sendo apresentados na Tabela 10. Nas colunas são mostrados os tempos refe-
rentes a cada quantidade de solicitações (Q.S.), a qual varia de 1 até 1000000 solicitações.
A linhas, por sua vez, indicam a amostra (Amost.) em que tais tempos de processamento
foram mensurados.
Tabela 10: Tempo de processamento das solicitações na plataforma IndoLoR pelos com-ponentes padrões utilizando os componentes adaptadores
Amost./Q.S. 1 10 100 1000 10000 100000 10000001 0,000 0,100 0,080 0,090 0,100 0,105 0,1012 0,000 0,000 0,120 0,095 0,098 0,101 0,1003 0,000 0,100 0,070 0,104 0,116 0,109 0,1094 0,000 0,000 0,130 0,106 0,106 0,105 0,1055 0,000 0,000 0,140 0,102 0,099 0,102 0,1026 0,000 0,100 0,140 0,098 0,106 0,103 0,1027 0,000 0,100 0,140 0,108 0,114 0,099 0,1058 0,000 0,100 0,090 0,113 0,108 0,107 0,1039 0,000 0,100 0,150 0,115 0,107 0,102 0,10110 0,000 0,000 0,080 0,091 0,098 0,103 0,113
Média 0,000 0,060 0,114 0,102 0,105 0,104 0,104
Por �m, a Tabela 11 apresenta o total de processamento das solicitações pela plata-
forma. Em que este tempo inclui os componentes padrões e componentes adaptadores.
Nas colunas são mostrados os tempos referentes a cada quantidade de solicitações (Q.S.),
a qual varia de 1 até 1000000 solicitações. A linhas, por sua vez, indicam a amostra
(Amost.) em que tais tempos de processamento foram mensurados.
89
Tabela 11: Tempo de processamento das solicitações pela plataforma IndoLoR utilizandocomponentes padrões e componentes adaptadores
Amost./Q.S. 1 10 100 1000 10000 100000 10000001 0,000 0,000 0,750 0,884 0,843 0,940 0,9152 0,000 0,000 0,780 0,954 0,927 0,888 0,9083 0,000 0,800 0,760 0,812 0,935 0,891 0,8994 0,000 0,000 0,790 0,841 0,924 0,889 0,9125 0,000 0,400 0,740 0,810 1,108 0,921 0,9086 0,000 1,100 0,790 0,844 0,919 0,905 0,8997 0,000 0,000 1,010 0,890 0,947 0,904 0,9268 0,000 0,700 0,880 0,822 0,996 0,898 0,9149 0,000 0,000 0,850 0,788 0,851 0,891 0,90710 0,000 0,600 0,750 0,811 0,912 0,925 0,899
Média 0,000 0,360 0,810 0,846 0,936 0,905 0,909
5.2.3 Ameaças à validade
Para o estudo de caso realizado foram avaliados os quatro tipos de validade:
1. Validade de construção: a captura dos dados do tempo de processamento deste
estudo de caso foi realizada de maneira automatizada por meio de software, o que
mitiga o risco de falha na captura do mesmo. Além disso, esse experimento foi execu-
tado utilizando uma única máquina evitando que fatores de diferença de hardwares
comprometessem os valores coletados no estudo.
2. Validade interna: o estudo de caso foi realizado pelo próprio criador da plataforma, o
que diminuiu o risco de que fatores relacionados a inexperiência dos programadores
no desenvolvimento de aplicações baseadas em OSGi e Java.
3. Validade externa: a implementação dos componentes adaptadores utilizados neste
estudo de caso foram realizadas pelo próprio desenvolvedor da plataforma, o qual
é um programador experiente. Dessa forma, programadores iniciantes ou que ainda
não dominem as tecnologias utilizadas na plataforma podem gerar componentes com
uma maior quantidade de linhas de código ou de baixa qualidade. Além disso, os
tempos de processamento das solicitações podem ser diretamente in�uenciados pelo
computador em que a plataforma está sendo executada.
4. Validade de conclusão: neste estudo foram utilizados dados quantitativos que cola-
boraram para o processo de avaliação da plataforma. No que diz respeito aos dados
dos tempos de processamento, os mesmos foram coletados em várias amostragens
90
para a realização do cálculo de uma média, impedindo que desvios especí�cos in�u-
enciassem o resultado �nal do estudo.
5.2.4 Respostas às questões de pesquisa
Conforme descrito na Seção 5.2.1, o sujeitos desse estudo de caso (próprio pesquisador)
desenvolveu os componentes adaptadores para que a plataforma IndoLoR pudesse permitir
a localização de um dispositivo utilizando dados de WIFI e RFID presentes no ambiente.
Em seguida, coletou-se as métricas necessárias às respostas das questões de pesquisa.
5.2.4.1 Questão de Pesquisa 1: Qual o grau de adaptabilidade provida pela
plataforma IndoLoR?
Apesar da adaptabilidade ser uma propriedade qualitativa, com a métrica de�nida
por Subramanian e Chung (SUBRAMANIAN; CHUNG, 1999) consegue-se obter o grau de
adaptabilidade de uma arquitetura de software. A métrica AAI representa o quanto, em
termos de elementos, uma arquitetura de software pode ter as suas funcionalidades adap-
tadas. Foi apresentado na Equação 5.2 que a arquitetura da plataforma IndoLoR possui
um grau de adaptabilidade de 34%. Visto que não existe neste estudo outra arquitetura
para que se pudesse realizar uma comparação, não se pode a�rmar que o valor obtido
trata-se de um valor baixo ou alto.
No entanto, essa métrica leva em consideração os dois tipos de elementos presen-
tes em uma arquitetura de software: Componentes e Conectores (CLEMENTS et al., 2002)
(SUBRAMANIAN; CHUNG, 1999). Adaptando essa métrica, de�nindo que a mesma só irá
considerar os componentes de uma arquitetura pois como os conectores são elementos
arquiteturais que apenas realizam as conexões entre os componentes ou seja não realizam
de fato processamento, serão desconsiderados do cálculo. Assim, pode-se de�nir essa mé-
trica como: Índice de adaptabilidade dos componentes da arquitetura (ACAI), tendo seu
cálculo de�nido pela Equação 5.4. A métrica Índice de Adaptabilidade do Componente
(ECAI), tem seu funcionamento igual ao de�nido na Seção 5.2.2 para a métrica EAI.
ACAI =
∑ni=1 ECAIi
Total de Componentes(5.4)
Onde:
• ACAI � Índice de adaptabilidade dos componentes da arquitetura
91
• ECAI � Índice de Adaptabilidade do Componente
• Total de componentes � Soma do total de componentes
A Equação 5.5 apresenta o resultado do cálculo dessa métrica para a arquitetura
proposta. Obteve-se como valor que todos os componentes da arquitetura são adaptáveis,
apesar de não existir outra arquitetura a título de comparação, pode-se de�nir então que
a arquitetura da plataforma IndoLoR possuí 100% de seus componentes adaptáveis. Dessa
forma, pode-se a�rmar que a arquitetura tem um alto grau de adaptabilidade.
Componentes = 8
ECAI = 8
ACAI =8
8= 1 = 100%
(5.5)
5.2.4.2 Questão de Pesquisa 2: Criar uma adaptabilidade para plataforma
IndoLoR é uma tarefa de custosa?
Criar uma adaptabilidade para a plataforma IndoLoR demonstrou que há indícios de
ser uma tarefa de baixo custo, pois é necessária uma baixa quantidade de linhas de código
e de classes para tal. Conforme apresentado na Tabela 8, foi necessário um total de 704
linhas de código e 18 classes para a completa construção dos componentes necessários
para este estudo. Vale salientar que essa contagem considerou todas as linhas de código,
incluindo as importações, declarações, etc.
Para avaliar o custo de incluir as adaptações na plataforma, conforme apresentado
na Tabela 8 foram necessárias um total de 64 linhas de código para que os componentes
adaptadores fossem acoplados a plataforma IndoLoR. Esse quantitativo levou em con-
sideração apenas as linhas que estão diretamente ligadas ao processo de adaptação de
funcionalidades. Dessa forma, tem-se que foi necessário apenas 9% do total de linhas para
incoporar as adaptabilidades a plataforma.
Além da avaliação da facilidade de incoporação de adaptações na plataforma pela
quantidade de código necessário realizar tal operação. Pode-se avaliar o crescimento estru-
tural das adaptações implementadas. Para tal, Raibulet e Masciadri (RAIBULET; MASCIA-
DRI, 2009) (RAIBULET; MASCIADRI, 2010) de�nem algumas métricas para esta avaliação,
sendo estas apresentadas na Equação 5.6.
92
OsAC = MsAC +n∑
i=2
sACFi
AvgGSE =OsAC
n
(5.6)
Onde:
• MsAC � representa o número mínimo de classes para uma adaptação.
• sACF � representa o número de classes necessárias para a adaptação da i-ésima
funcionalidade.
• OsAC � representa o custo geral estrutural de todas as adaptações.
• AvgGSE � representa crescimento estrutural médio de classes necessárias para uma
adaptação.
Utilizando os dados obtidos e apresentados na Tabela 8, a Figura 40 apresenta o
resultado do cálculo da métrica OsAC para cada uma das funcionalidades adaptadas.
Percebe-se que o grá�co obtido tende a uma função linear. Esse comportamento indica
que as funcionalidades adaptadas são independentes uma das outras, dessa forma não
é necessário que um programador que esteja desenvolvendo componentes adaptadores
conheça ou estude a implementação de outro componente. Além disso, encontrou-se que o
crescimento estrutural médio de classes para se obter uma adaptação é AvgGSE = 185=
3, 6. Portanto, são necessárias em média menos de 4 classes para se criar um componente
adaptador.
Diante do exposto, pôde-se concluir que há indícios de que a atividade de criar uma
adaptabilidade e a incorporar na plataforma é uma atividade de baixo custo, visto que são
necessárias poucas linhas de código para realizar a sua incoporação. Além disso, necessita-
se de poucas classes para se construir um componente adaptador e não necessita que o
programador conheça detalhes de implementações de outros componentes, podendo focar
apenas em resolver o problema a que seu componente se propõe.
5.2.4.3 Questão de Pesquisa 3: O desempenho da plataforma é prejudicado
quando os componentes padrões têm suas funcionalidades adaptadas?
Para avaliar o desempenho da plataforma quando existem componentes adaptadores
associados aos componentes padrões, ou seja, adaptando suas funcionalidades foram in-
terpretados os dados obtidos na Seção 5.2.2. Dessa forma, com base nos dados obtidos
93
Figura 40: Grá�co da relação entre a métrica OsAC e as funcionalidades adaptadas
na Tabela 9, que considera o tempo de processamento das solicitações pela plataforma
em que apenas existem os componentes padrões, e na Tabela 10, que considera o tempo
de processamento das solicitações pela plataforma em que existem as adaptações de suas
funcionalidades considerando o tempo gasto apenas pelos componentes padrões é apresen-
tada a Figura 41. Em que esta apresenta o grá�co com o tempo médio de processamento
para estas duas situações. Percebe-se que a inclusão de componentes adaptadores na pla-
taforma tem in�uência direta no tempo de processamento dos módulos padrões, fazendo
com que os mesmos aumentem o seu tempo de processamento total em cerca de 50%
em relação ao tempo despendido quando não há adaptações presentes. No entanto, a
arquitetura da plataforma se mostrou robusta e estável, pois mesmo com uma grande
quantidade de pacotes, manteve o seu tempo médio de processamento aproximadamente
estável, existindo ou não adaptações.
Se for realizada uma comparação entre os tempos de processamento gasto apenas
com os componentes padrões e o tempo total de processamento considerando compo-
nentes padrões e componentes adaptadores, apresentados na Tabela 11, percebe-se que o
tempo médio de processamento dos módulos padrões não ultrapassa 11% em relação ao
tempo médio total de processamento, conforme apresenta o grá�co na Figura 42. Diante
disso, pode-se concluir que o tempo de processamento dos componentes padrões tem um
impacto pouco signi�cativo no tempo médio de processamento das solicitações enviadas
para a plataforma IndoLoR. Isso é interessante porque demonstra que o tempo médio
94
Figura 41: Grá�co tempo médio de processamento das solicitações considerando apenaso componentes padrões e apenas padrões e desconsiderando as adaptações
gasto pelos componentes de gestão de plataforma é pouco signi�cativo. Desta forma, o
tempo efetivamente dominante trata-se da lógica de negócio associada aos componentes
adaptadores.
Figura 42: Grá�co tempo médio de processamento das solicitações considerando apenaspadrões e desconsiderando as adaptações e o tempo médio total de processamento
5.2.5 Considerações Finais sobre o estudo de caso
Com a execução deste estudo de caso, pode-se validar a utilização da plataforma
com dados heterogêneos, WIFI e RFID. Além disso, pode-se validar a implementação do
95
cálculo da localização em ambientes utilizando a fusão de dados provenientes das diferentes
fontes. Com a construção e utilização do aplicativo para dispositivo móvel, comprovou-se
que a plataforma cumpre o propósito de�nido em sua arquitetura geral, apresentado na
Figura 17, em que a mesma conseguiu obter informações de diferentes fontes, realizou
o processamento transformando-a em dados de localização e as disponibilizando para as
aplicações clientes.
Em relação à adaptação dos componentes padrões, foi realizada a implementação de
cinco componentes adaptadores comprovando o funcionamento do processo de inclusão
de adaptações às funcionalidades da plataforma. Além disso, comprovou-se que todos os
componentes da arquitetura permitem a sua adaptabilidade, demostrando nos resultados
e métricas apresentados na Seção 5.2.4. Ademais, foi possível traçar a rota percorrida por
um dispositivo em um determinado ambiente, isso demonstra o funcionamento dos outros
módulos padrões da plataforma IndoLoR e não apenas o de localização.
Por �m, este estudo de caso mostrou que o processo de criação e inclusão de adap-
tações a plataforma demonstrou apresentar indícios de ser um processo com um baixo
custo. Além disso, dado essa característica, os componentes adaptadores funcionam de
maneira independente, o que facilita o entedimento e utilização da plataforma pelos pro-
gramadores pois não é necessário que se conheçam detalhes de implementação de outros
componentes adaptadores. Outro importante aspecto avaliado foi a performance para
realizar o processamento das solicitações enviadas à plataforma, em que o tempo de pro-
cessamento despendido nos componentes padrões tem um impacto pouco signi�cativo no
processamento total das solicitações.
96
6 Trabalhos Relacionados
Neste capítulo serão apresentados os trabalhos que estão diretamente relacionados
ao proposto nesta dissertação. Destacamos as principais contribuições de cada um dos
trabalhos listados e tentamos mostrar as principais diferenças com a abordagem proposta.
O modelo Arquitetural Location Stack introduzido por Hightower et. al. (HIGHTOWER;
BRUMITT; BORRIELLO, 2002) apresenta um modelo padronizado para construção de siste-
mas de localização utilizando uma modelo arquitetural em camadas. Em que este modelo
se refere a formas padronizadas para realizar a combinação de dados de diferentes fontes
através de uma arquitetura de software baseada no modelo de comunicação de rede Open
System Interconnect (OSI) .
A Figura 43 apresenta o modelo arquitetural Location Stack. É possível notar que para
sua arquitetura foram de�nidas sete camadas, sendo elas: Sensors que possuí os aspec-
tos de hardware e software para o recebimento de informações; Measurement tem como
transformar dados obtidos em tipos de medidas; Fusion tem como função realizar a com-
binação das medidas obtidas na camada anterior; Arrangements é a camada responsável
pelo raciocínio através de probabilidades; Contextual Fusion tem como objetivo realizar a
combinação de informações de contextuais com não contextuais; Activities é a camada na
qual as aplicações ubíquas provêm a semântica sobre as informações previamente obtidas
e por último Intentions representa os desejos cognitivos que os usuários desejam fazer
com as informações ubíquas.
Como principais diferenças entre as arquitetutras do Location Stack e a plataforma
proposta neste trabalho, temos que pelo fato de de�nir camadas rígidas assim como no
modelo OSI, em que uma camada apenas recebe dados provenientes da camada imedia-
tamente inferior e exporta os dados processados para a camada imediatamente superior
torna a arquitetura pouco �exível, di�cultando a extensão das funcionalidades. O que
se diferencia bastante da arquitetura proposta cuja principal característica é permitir a
adaptabilidade de todos os componentes e não de�nir todas as responsabilidades ou infor-
97
Figura 43: Modelo Arquitetural da Location Stack (HIGHTOWER; BRUMITT; BORRIELLO,2002)
mações de entrada e saída que os mesmos devem obter/produzir. Além disso, apesar de sua
arquitetura também poder ser organizada em camadas, existe uma troca de informações
entre camada em dois sentidos como, entre os componentes da camada de processamento
e camada de persistência.
Em Najib et. Al. (NAJIB; KLEPAL; WIBOWO, 2011) é apresentado um middleware para
localização em ambientes internos chamado de MapUme. O MapUme permite a fusão de
dados provenientes de diversos tipos de sensores, em que esse processo acontece através
da implementação de uma engine de fusão que é construída através do padrão de fábrica
abstrata. Além disso, possuí a capacidade de processamento distribuído permitindo a
escalabilidade e a alta performance. A arquitetura utilizada é baseada na proposta por
Hightower et. al no qual a mesma é organizada em camadas. Além disso, utiliza o modelo
arquitetural orientado a serviços.
O MapUme possui como requisitos principais: escalabilidade, usabilidade e extensi-
bilidade. A escalabilidade será obtida a partir do processamento distribuído. O requisito
de usabilidade refere-se à �exibilidade necessária para ser utilizada nos mais diversos ti-
pos de aplicações, como prover localização físicas (sistema de coordenadas) ou simbólicas
(andar, corredor, sala e etc.). A extensibilidade se dá através de interfaces de�nidas pelo
middleware podendo adicionar novas funcionalidades, como novos tipos de tecnologias de
sensoriamento e novos algoritmos para a fusão de informações.
Apesar de ser baseado em uma arquitetura modular e divididas em camadas, este
middleware permite a extensibilidade de seus componentes. No entanto, a extensibilidade
é permitida para alguns componentes da arquitetura e mesmo em que o extensibilidade é
permitida a mesma de ocorrer com um alto grau de acoplamento pois deve-se construir a
nova implementação e a acoplar ao middleware. Essa característica a torna bem diferente
98
da plataforma proposta que permite a inserção de novas características sem a necessidade
realizar a interrupção da execução da plataforma. Associado a isso, existe o fato de que
a plataforma proposta utiliza o modelo arquitetural Publish/Subscribe o que garante que
os novos serviços ao serem instanciados e registrados estarão disponíveis para utilização
dentro da plataforma.
O LOC8 proposto por Stevenson et. Al (STEVENSON et al., 2010) é um framework
desenvolvido em JAVA para localização em ambientes internos e externos suportando um
modelo de contexto e espaço especí�co. Possui uma arquitetura baseada em camadas com
uma robusta separação de preocupações. Além disso, suporta diferentes tipos de informa-
ções provenientes dos sensores, assim como, a extensão e customização dos algoritmos de
fusão. Disponibiliza uma API para que os desenvolvedores possam utilizar as consultas
para obter as informações de posicionamento sem que seja necessário conhecer a maneira
como os dados dos sensores são obtidos. Assim como em Hightower et. al, a arquite-
tura proposta é baseada em camadas utilizando como base o modelo OSI. Possuí como
foco principal na realização de consultas aos dados presentes no modelo de localização
proposto.
O framework LOC8 difere bastante da plataforma proposta pois tem como foco em
criar um modelo para o espaço e as posições em ontologias, além de prover um mecanismo
de consulta para suportar o uso de localização em sistemas pervasivos. A plataforma
proposta possuí a característica pervasiva pois possibilita o uso das informações presentes
nos ambientes, porém não cria um modelo especí�co para espaços e não de�ne como serão
as consultas para obter a localização. Possuí um modelo totalmente �exível, no qual cada
tipo de aplicação poderá de�nir suas especi�cidades.
Em Ranganathan et. Al. (RANGANATHAN et al., 2004) é proposto um middleware
sensível a localização chamado de �MiddleWhere�. Esta plataforma integra múltiplas tec-
nologias de localização, assim como, apresenta as aplicações clientes dados de localização
consolidados. Para isso, utiliza uma arquitetura dividida em camadas para coletar as in-
formações dos sensores, persistir as informações em um banco de dados espacial, uma
engine de inteligência para realizar a fusão de dados para obter as informações de locali-
zação e uma camada de serviços para a disponibilização dessas informações. Além disso,
permite que o modo de interação pull e push para a comunicação com as aplicações.
Diferente da abordagem proposta neste trabalho, esse middleware permite um pe-
queno grau de adaptabilidade. Em que em tempo de execução apenas permite a inserção
e remoção de novas fontes de informações. A arquitetura da plataforma proposta além de
99
permitir a utilização de novos e diferentes fontes de informação em tempo de execução,
permite que seja modi�cado qualquer dos comportamentos presentes na plataforma.
Sumarizando a análise dos trabalhos, é apresentado na Tabela 12 quais requisitos
não-funcionais são atendidos pelos mesmos. Dessa forma, é possível obter uma visão mais
objetiva e direta das características presentes em cada um dos trabalhos analisados.
Tabela 12: Lista de características presentes em cada uma trabalhos relacionadosRequisitos Location Stack MapUme LOC8 MiddleWhere IndoLoRUtilizar uma arquite-tura modular e adaptá-vel
Não Sim Não Não Sim
Recepção e processa-mento de dados de fon-tes de informações hete-rogêneas
Sim Sim Sim Sim Sim
Prover mecanismos paraa fusão de informações
Sim Sim Sim Não Sim
Garantir o suporte adiferentes repositóriospara armazenamento dedados
Não Não Não Não Sim
Garantir o controle deacesso as informações
Não Não Não Não Sim
Fornecer uma API Não Não Sim Não Sim
100
7 Considerações �nais
Conforme apresentado no Capítulo 1, os sistemas de baseados em localização vêm
ganhando bastante espaço entre os pesquisadores e na indústria. Os sistemas de locali-
zação em ambientes externos estão bem consolidados devido à utilização do GPS que é
uma tecnologia madura e con�ável. No entanto, esta tecnologia não funciona de maneira
satisfatória em ambientes internos pois há o bloqueio dos sinais provenientes dos satélites.
Nesse contexto, os sistemas de localização em ambientes internos têm recebido bastante
atenção nos últimos anos, em grande parte por ainda não possuir uma tecnologia padroni-
zada para esse tipo localização. Além disso, ainda foi visto que este problema encontra-se
em aberto, e muitos pesquisadores têm buscado soluções para o mesmo conforme apre-
sentado no Capítulo 3.
De acordo com o que foi apresentado no Capítulo 2, percebe-se que o GPS é uma
tecnologia bastante precisa em ambientes externos pelo fato de utilizar sinais de satélite
para obter o posicionamento de um alvo. No entanto, em ambientes internos não conse-
gue reproduzir a mesma precisão dada a natureza complexa destes tipos de ambientes.
Buscando alternativas ao GPS, foram apresentadas as técnicas utilizadas para obter a lo-
calização em ambientes internos sendo estas: Triangulação, Fingerprinting, Proximidade
e Análise de Visão. Além disso, foi apresentado que, dentre todas, a mais utilizada é a
técnica de Fingerprinting e por este motivo foi a escolhida para o mapeamento sistemático
apresentado no Capítulo 3. Ainda neste capítulo, foram apresentados benefícios propor-
cionados pela utilização do framework OSGi como: modularidade, menor complexidade,
simpli�cação do deploy visto que se pode gerenciar cada módulo individualmente, facili-
tação da manutenção do sistema, suporte aos modelos arquiteturais publish/subscribe e
orientado a serviços.
No Capítulo 3 foi apresentado um mapeamento sistemático da literatura realizado
com o intuito de descobrir quais as principais lacunas de pesquisa existentes e reporta-
das na literatura. Com o conhecimento obtido pela conclusão do mapeamento sistemático
sistemática, identi�cou-se que existe uma tendência crescente em que as soluções para o
101
problema da localização de pessoas e objetos em ambientes internos utilizem uma combi-
nação de tecnologias com o intuito de obter um posicionamento mais preciso e con�ável.
Após essa identi�cação, no Capítulo 4 é apresentada a plataforma adaptável IndoLoR
para localização em ambientes internos. Na qual a mesma é dividida em componentes
padrões e componentes adaptadores. Estes componentes padrões são providos
pela arquitetura da plataforma e podem ter suas funcionalidades adaptadas pelos com-
ponentes adaptadores. Além disso, foi apresentado os padrões arquiteturais utilizadas
pela plataforma os quais são publish/subscribe e orientação a serviços. Foi apresentada
como foi realizada a implementação da plataforma cuja tecnologia base utilizada foi o
OSGI, o qual foi escolhida pelas facilidades de gerenciabilidade e manutenibilidade ofere-
cidas pela mesma, facilitando a construção de abordagens modulares e adaptáveis.
No Capítulo 5 foi apresentado um exemplo de uso da plataforma projetada com o ob-
jetivo de validar a arquitetura e implementação da plataforma em um ambiente real. Desta
forma, a mesma conseguiu atingir o seu objetivo de estender suas funcionalidades para ob-
ter o posicionamento de um smartphone utilizando sinais de WIFI presentes no ambiente.
Além disso, foi realizado um estudo de caso em que utilizou-se dados de WIFI e RFID para
localizar um dispositivo em um determinado ambiente. Dessa forma, comprovou-se que a
plataforma IndoLoR permite a utilização de diversas fontes de informações e tecnologias.
Além dessa comprovação, avaliou-se sua adaptabilidade e performance. Os resultados se
mostraram bastante satisfatórios, de maneira que a plataforma permite que todos os seus
componentes padrões sejam adaptados e mostrou que o processo de incorporação de uma
adaptação é uma tarefa simples e de baixo custo de implementação. Ademais, mostrou que
mesmo incluindo adaptações, o tempo médio de processamento das solicitações permanece
constante, demostrando a robustez da arquitetura proposta.
Por �m, no Capítulo 6 são apresentados os trabalhos diretamente relacionados ao pro-
posto neste estudo. De forma que em nenhum deles é contemplado uma plataforma que
disponibilize uma adaptação completa de funcionalidades. Normalmente, algumas funci-
onalidades são passíveis de adaptação, o que pode limitar a utilização em determinados
ambientes.
7.1 Principais contribuições
Como resultado do trabalho apresentado nessa dissertação, as seguintes contribuições
podem ser enumeradas:
102
1. Catálogo referentes as tecnologias, tipos de pesquisas e contribuições em relação a
área de localização em ambientes internos reportadas na literatura.
2. A de�nição de uma arquitetura adaptável para uma plataforma de localização em
ambientes internos.
3. A avaliação da plataforma projetada através de um estudo de caso, em que foram
avaliados a sua adaptabilidade provida, a facilidade de inclusão das adaptações e
sua performance.
Além disso, o presente trabalhou gerou duas publicações, na qual uma delas foi em
uma conferência internacional e outra em um simpósio nacional:
• International Conference on Systems and Networks Communications (ICSNC): Ca-
tegorization of Technologies used for Fingerprint-Based Indoor Localization
• Simpósio Brasileiro de Computação Ubíqua e Pervasiva (SBCUP): A Taxonomy of
Technologies for Fingerprint-Based Indoor Localization
7.2 Limitações
O Capítulo 3 apresenta um mapeamento sistemático da literatura, no entanto o mesmo
é limitado a técnica de �ngerprint. Dessa forma, trabalhos e resultados importantes podem
ter sido não considerados, limitando a generalização deste estudo. Esse limitação se deu
pelo alto número de artigos obtidos pela String de busca inicial. Então, objetivando obter
as informações mais relavantes da área, escolheu a técnica mais utilizada nas pesquisas.
No Capítulo 5 é apresentada a execução de um estudo em que são avaliados aspectos
de adaptabilidade e performance da plataforma projetada. No entanto, apenas o �uxo
principal da plataforma foi avaliado. Esse �uxo, de localizar um dispositivo, apesar de
ser o mais oneroso representa uma pequena parte da plataforma projetada. A inclusão
de novos �uxos podem gerar situações não encontradas, dado que apenas um �uxo foi
avaliado. Dessa forma, acredita-se que mais estudos de casos são necessários para validar
todo �uxo presentes na plataforma IndoLoR.
Uma outra limitação deste trabalho se dá pela metodologia de pesquisa utilizada no
Capítulo 6. A metodologia utilizada foi a de uma revisão exploratória, buscando trabalhos
semelhantes ao proposto, com o objetivo de compará-los. Dessa forma, di�cilmente a
103
metodologia empregada conseguirá ser reproduzida por outro pesquisador, dado o caráter
subjetivo que foi aplicado.
7.3 Trabalhos Futuros
Com relação a trabalhos futuros, pretende-se realizar uma revisão sistemática da li-
tetura com todas as técnicas de localização existentes. Dessa forma, será possível avaliar
qualitativamente os trabalhos da área e alcançando um nível de detalhamento maior,
podendo identi�car novas questões e requisitos para uma plataforma de localização em
ambientes internos.
Além disso, pretende-se realizar novos estudos de casos, e com isso, pretende-se avaliar
todos os �uxos de funcionamento e requisitos presentes na plataforma projetada, em que
esses estudos incluam a utilização das diferentes técnicas de localização existentes, assim
como, diferentes fontes de informação e formas de utilização. Almeja-se que outros desen-
volvedores construam suas adaptações de maneira a contribuir e avaliar o funcionamento
plataforma para que assim o resultado obtido possa ser generalizado.
Além dos aspectos relativos a adaptabilidade e performance já contemplados na im-
plentação atual, tem-se a intenção de avaliar outras características tais como: escalabi-
lidade e processamento distribuído. Além disso, pretende-se incrementar os conceitos de
sensibilidade ao contexto, cloud computing e big data a mesma.
104
Referências
ALLIANCE, O. OSGi Alliance. 2015. Disponível em: <http://www.osgi.org/>.
ANYPLACE. AnyPlace. 2015. Disponível em: <http://anyplace.cs.ucy.ac.cy/>.
APPLE. Footprint: Indoor Positioning with Core Location,http://developer.apple.com/library/ios/samplecode/footprint/. 2015. Disponívelem: <https://developer.apple.com/library/ios/samplecode/footprint>.
BEESTAR. Insight. 2015. Disponível em: <http://www.beestar.eu/>.
BOLLIGER, P. Redpin-adaptive, zero-con�guration indoor localization through usercollaboration. In: ACM. Proceedings of the �rst ACM international workshop on Mobileentity localization and tracking in GPS-less environments. [S.l.], 2008. p. 55�60.
BUSCHMANN, F.; HENNEY, K.; SCHIMDT, D. Pattern-oriented Software Architecture:On Patterns and Pattern Language. [S.l.]: John wiley & sons, 2007.
CHENG, L. et al. A survey of localization in wireless sensor network. InternationalJournal of Distributed Sensor Networks, Hindawi Publishing Corporation, v. 2012, 2012.
CLEMENTS, P. et al. Documenting software architectures: views and beyond. [S.l.]:Pearson Education, 2002.
CROCKFORD, D. The application/json media type for javascript object notation (json).Internet RFC 4627, July 2006.
DEAK, G.; CURRAN, K.; CONDELL, J. A survey of active and passive indoorlocalisation systems. Computer Communications, v. 35, n. 16, p. 1939�1954, 2012.
DODGE, D. Why Indoor Location will be bigger than GPS or Maps, and how it works.2015. Disponível em: <http://dondodge.typepad.com/thenextbigthing/2013/04/why −indoor − location− will − be− bigger − than− gps− or −maps.html>.
EHSANI, M. R. et al. Evaluating the dynamic accuracy of low-cost gps receivers. In:ASAE Meeting Paper. [S.l.: s.n.], 2003.
EQUINOX. Equinox. 2015. Disponível em: <http://www.eclipse.org/equinox/>.
ERL, T. Soa: principles of service design. [S.l.]: Prentice Hall Upper Saddle River, 2008.
EUGSTER, P. T. et al. The many faces of publish/subscribe. ACM Computing Surveys(CSUR), ACM, v. 35, n. 2, p. 114�131, 2003.
FARID, Z.; NORDIN, R.; ISMAIL, M. Recent advances in wireless indoor localizationtechniques and system. Journal of Computer Networks and Communications, v. 2013,2013.
105
FELIX, A. Apache Felix. 2015. Disponível em: <http://felix.apache.org/>.
FLUERASU, A. et al. Indoor positioning using gps transmitters: Experimental results.In: IEEE. Indoor Positioning and Indoor Navigation (IPIN), 2010 InternationalConference on. [S.l.], 2010. p. 1�9.
FRAUNHOFER. awiloc. 2015. Disponível em:<http://www.iis.fraunhofer.de/en/�/lok/tech/feldstaerke/rssi.html>.
GARTNER. Gartner Says Worldwide Mobile Phone Sales Declined 1.7 Percentin 2012, http://www.gartner.com/newsroom/id/2335616. 2012. Disponível em:<http://www.gartner.com/newsroom/id/2335616>.
GLOPOS. GloPos. 2015. Disponível em: <http://glopos.com/indoor-positioning.html>.
GOOGLE. Indoor Maps, http://www.google.com/intl/pt-BR/maps/about/partners/indoormaps/. 2014.
GRESSMANN, B.; KLIMEK, H.; TURAU, V. Towards ubiquitous indoor locationbased services and indoor navigation. In: Positioning Navigation and Communication(WPNC), 2010 7th Workshop on. [S.l.: s.n.], 2010. p. 107�112.
GU, Y.; LO, A.; NIEMEGEERS, I. A survey of indoor positioning systems for wirelesspersonal networks. Communications Surveys & Tutorials, IEEE, IEEE, v. 11, n. 1, p.13�32, 2009.
GUBBI, J. et al. Internet of things (iot): A vision, architectural elements, and futuredirections. Future Generation Computer Systems, Elsevier, v. 29, n. 7, p. 1645�1660,2013.
HALL, R. et al. OSGi in action: Creating modular applications in Java. [S.l.]: ManningPublications Co., 2011.
HAN, D. et al. Access point localization using local signal strength gradient. In: Passiveand Active Network Measurement. [S.l.: s.n.], 2009, (Lecture Notes in Computer Science,v. 5448). p. 99�108. ISBN 978-3-642-00974-7.
HASELSTEINER, E.; BREITFUSS, K. Security in near �eld communication (nfc). In:Workshop on RFID security. [S.l.: s.n.], 2006. p. 12�14.
HE, J. et al. A practical indoor toa ranging error model for localization algorithm. In:IEEE. Personal Indoor and Mobile Radio Communications (PIMRC), 2011 IEEE 22ndInternational Symposium on. [S.l.], 2011. p. 1182�1186.
HERE. Consumer. 2015. Disponível em: <https://company.here.com/consumer/>.
HIGHTOWER, J.; BORRIELLO, G. Location systems for ubiquitous computing.Computer, IEEE, n. 8, p. 57�66, 2001.
HIGHTOWER, J.; BRUMITT, B.; BORRIELLO, G. The location stack: a layered modelfor location in ubiquitous computing. In: Mobile Computing Systems and Applications,2002. Proceedings Fourth IEEE Workshop on. [S.l.: s.n.], 2002. p. 22�28.
106
HOFFMANN-WELLENHOF, B.; LICHTENEGGER, H.; COLLINS, J. Gps: theory andpractice. 3rd edSpringer-Verlag, New York, 1994.
HUNG, M.-H. et al. A zigbee indoor positioning scheme using signal-index-pair datapreprocess method to enhance precision. In: . [S.l.: s.n.], 2010. p. 548�553.
IDTECHEX. RFID MARKET EXCEEDS $9 BILLION IN 2014; RETAIL DRIVESSTRONG GROWTH. 2014.
IN-STAT. Wireless LAN Market Estimates and Forecast by Device. 2014. Disponível em:<http://www.instat.com/catalog/wcatalogue.asp?id=167IN1004856WS>.
INSIDER, B. Apple Is Launching A Vast Project To Map The Inside Of Every LargeBuilding It Can. 2015. Disponível em: <http://www.businessinsider.com/apple-indoor-mapping-project-and-ibeacon-2014-6>.
JUNAIO. Junaio Augmented Reality Browser. 2015. Disponí-vel em: <https://itunes.apple.com/br/app/junaio-augmented-reality-browser/id337415615?mt=8>.
KAEMARUNGSI, K. Design of Indoor Positioning Systems based on LocationFingerprinting Technique. Tese (Doutorado) � Univ. of Pittsburgh, 2 2005.
KAPLAN, E.; HEGARTY, C. Understanding GPS: principles and applications. [S.l.]:Artech house, 2005.
KITCHENHAM, B.; PICKARD, L.; PFLEEGER, S. L. Case studies for method andtool evaluation. IEEE software, IEEE, n. 4, p. 52�62, 1995.
KNOPFLERFISH. Knop�er�sh. 2015. Disponível em: <https://www.knop�er�sh.org/>.
KOMODA, N. Service oriented architecture (soa) in industrial systems. In: IEEE.Industrial Informatics, 2006 IEEE International Conference on. [S.l.], 2006. p. 1�5.
KONRAD, P. W. T. Wi� compass wi� access point localization with android devices.Dissertação (Mestrado) � Information Security program at St. Polten University ofApplied Sciences, 2012.
KRIENS, P.; HARGRAVE, B. Listeners considered harmful: The âwhiteboardâ pattern.Technical whitepaper, OSGi Alliance, 2004.
KUL, G.; ÖZYER, T.; TAVLI, B. Ieee 802.11 wlan based real time indoor positioning:Literature survey and experimental investigations. Procedia Computer Science, Elsevier,v. 34, p. 157�164, 2014.
LEMIC, F. et al. Web-based platform for evaluation of rf-based indoor localizationalgorithms. In: Communication Workshop (ICCW), 2015 IEEE International Conferenceon. [S.l.: s.n.], 2015. p. 834�840.
LIPS. Local Indoor Positioning System. 2015. Disponível em: <http://lips.si/>.
LIU, H. et al. Survey of wireless indoor positioning techniques and systems. IEEETransactions on Systems, Man and Cybernetics Part C: Applications and Reviews, v. 37,n. 6, p. 1067�1080, 2007.
107
LYMBEROPOULOS, D. et al. A realistic evaluation and comparison of indoor locationtechnologies: Experiences and lessons learned. ACM/IEEE International Conference onInformation Processing in Sensor Networks, ACM, p. 178�189, 2015.
MACKENZIE, C. M. et al. Reference model for service oriented architecture 1.0. OASISStandard, v. 12, 2006.
MARIAKAKIS, A. T. et al. Sail: single access point-based indoor localization. In: ACM.Proceedings of the 12th annual international conference on Mobile systems, applications,and services. [S.l.], 2014. p. 315�328.
MAZEMAP. Mazemap. 2015. Disponível em: <https://use.mazemap.com/?v=1>.
MELO, M.; AQUINO, G. Categorization of technologies used for �ngerprint-basedindoor localization. In: IEEE. Systems and Networks Communications, 2015. ICSNC'15.Eleventh International Conference on. [S.l.], 2015. p. 25�29.
MELO, M.; AQUINO, G. A taxonomy of technologies for �ngerprint-basedindoor localization. In: SBC. 7o SimpÃ3sioBrasileirodeComputa§£oUb-quaePervasiva(SBCUP2015).[S.l.], 2015.p.111−−120.
MONGODB. Available online: https://www.mongodb.org. 2015.
MUJTABA, S. et al. Software product line variability: A systematic mapping study.School of Engineering, Blekinge Inst. of Technology, 2008.
NAJIB, W.; KLEPAL, M.; WIBOWO, S. Mapume: Scalable middleware for locationaware computing applications. In: Indoor Positioning and Indoor Navigation (IPIN),2011 International Conference on. [S.l.: s.n.], 2011. p. 1�6.
PETERSEN, K. et al. Systematic mapping studies in software engineering. In: 12thInternational Conference on Evaluation and Assessment in Software Engineering. [S.l.:s.n.], 2008. v. 17, p. 1.
POINTINSIDE. storemode. 2015. Disponível em:<http://www.pointinside.com/storemode/indoor-mapping/>.
RAIBULET, C.; MASCIADRI, L. Evaluation of dynamic adaptivity through metrics:an achievable target? In: Software Architecture, 2009 European Conference on SoftwareArchitecture. WICSA/ECSA 2009. Joint Working IEEE/IFIP Conference on. [S.l.: s.n.],2009. p. 341�344.
RAIBULET, C.; MASCIADRI, L. Metrics for the evaluation of adaptivity aspects insoftware systems. International Journal on Advances in Software Volume 3, Number 1 &2, 2010, Citeseer, 2010.
RANGANATHAN, A. et al. Middlewhere: a middleware for location awareness inubiquitous computing applications. In: SPRINGER-VERLAG NEW YORK, INC.Proceedings of the 5th ACM/IFIP/USENIX international conference on Middleware.[S.l.], 2004. p. 397�416.
RESEARCH, O. Mapping the Indoor Marketing Opportunity. 2015. Disponível em:<http://opusresearch.net/wordpress/pdfreports/OpusIndoorReport24Jan2014.pdf>.
108
RODRIGUES, M. L. Localização em ambientes internos utilizando múltiplas tecnologiassem �o. Dissertação (Mestrado) � UFMG, 2011.
RUNESON, P.; HÖST, M. Guidelines for conducting and reporting case study researchin software engineering. Empirical software engineering, Springer, v. 14, n. 2, p.131�164, 2009.
SAPUMOHOTTI, C.; ALIAS, M.-Y.; TAN, S.-W. Low cost metric for comparing thelocalization e�cacy of wlan access points using rf site survey data. IEICE Transactionson Communications, E97-B, n. 7, p. 1403�1411, 2014.
SATYANARAYANAN, M. Pervasive computing: Vision and challenges. PersonalCommunications, IEEE, IEEE, v. 8, n. 4, p. 10�17, 2001.
SIG, B. Emerging Bluetooth Verticals. 2013. Disponível em:<https://www.bluetooth.org/en-us/Documents/Analyst
SIMON, R.; FRÖHLICH, P.; ANEGG, H. Beyond location based�the spatially awaremobile phone. In: Web and wireless geographical information systems. [S.l.]: Springer,2006. p. 12�21.
SIMONI, M. et al. Indoor air pollution and respiratory health in the elderly. EuropeanRespiratory Journal, European Respiratory Society, v. 21, n. 40 suppl, p. 15s�20s, 2003.ISSN 0903-1936.
STEVENSON, G. et al. Loc8: A location model and extensible framework forprogramming with location. Pervasive Computing, IEEE, v. 9, n. 1, p. 28�37, Jan 2010.ISSN 1536-1268.
SUBRAMANIAN, N.; CHUNG, L. Metrics for software adaptability. Applied TechnologyDivision, Anritsu Company, p. 95�108, 1999.
SUMMIT, D. Indoor Positioning and Beacons: Itâs All E-commerce Now. 2015. Disponívelem: <http://www.technologyreview.com/summit/14/digital/video/watch/indoor-positioning-and-beacons/>.
TAHERI, A.; SINGH, A.; EMMANUEL, A. Location �ngerprinting on infrastructure802.11 wireless local area networks (wlans) using locus. In: IEEE. Local ComputerNetworks, 2004. 29th Annual IEEE International Conference on. [S.l.], 2004. p. 676�683.
TARVAINEN, P. Adaptability evaluation at software architecture level. The OpenSoftware Engineering Journal, v. 2, n. 1, p. 1�30, 2008.
TAVARES, A. L.; VALENTE, M. T. A gentle introduction to osgi. ACM SIGSOFTSoftware Engineering Notes, ACM, v. 33, n. 5, p. 8, 2008.
VOSSIEK, M. et al. Wireless local positioning - concepts, solutions, applications. In:Radio and Wireless Conference, 2003. RAWCON '03. Proceedings. [S.l.: s.n.], 2003. p.219�224.
WAHL, M.; HOWES, T.; KILLE, S. Lightweight directory access protocol (v3). 1997.
109
WEGENER, M. et al. Localization of objects using passive r�d technology. In: . [S.l.:s.n.], 2014.
WIERINGA, R. et al. Requirements engineering paper classi�cation and evaluationcriteria: a proposal and a discussion. Requirements Engineering, Springer, v. 11, n. 1,p. 102�107, 2006.
WIN, M. Z. et al. Network localization and navigation via cooperation. CommunicationsMagazine, IEEE, IEEE, v. 49, n. 5, p. 56�62, 2011.
YIN, R. K. Case study research: Design and methods. [S.l.]: Sage publications, 2013.
ZELKOWITZ, M.; WALLACE, D. Experimental models for validating technology.Computer, v. 31, n. 5, p. 23�31, 1998.
110
APÊNDICE A -- Listagem de Artigos avaliados
e seus respectivos
formulários.
Neste apêndice são apresentados os formulários de extração de dados dos 1003 artigos
que �zeram parte do mapeamento sistemático descrito no Capítulo 3. Devido ao grande
volume de informações estas informações foram disponibilizadas no seguinte endereço
público na WEB:
https://docs.google.com/spreadsheets/d/1Z093hlo22QslLxtwX7pMVM5Qr−cLY lCUbV
EdJ40618/edit?usp = sharing
top related