Uma Plataforma Adaptável para Localização em Ambientes Internos

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


Garantir o controle deacesso as informações


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

Uma Plataforma Adaptável para Localização em Ambientes Internos

Documents

Transcript of Uma Plataforma Adaptável para Localização em Ambientes Internos