Universidade Federal do Rio Grande do Norte Instituto ...€¦ · Opções: Conheça Natal,...

Universidade Federal do Rio Grande do Norte Instituto Metrópole Digital

SmartMetropolis – Plataformas e Aplicações para Cidades Inteligentes

WP2 - Aplicações

Resultados do Segundo Trimestre

Natal-RN, Brasil Agosto de 2016

Equipe Técnica Docentes Prof. Dr. Nélio Alessandro Azevedo Cacho (Coordenador) - DIMAp-UFRN Prof. Dr. Everton Ranielly de Sousa Cavalcante - DIMAp-UFRN Prof. Dr. Frederico Araújo da Silva Lopes - IMD-UFRN Prof. Dr. Ivanovitch Medeiros Dantas da Silva - IMD-UFRN Prof.ª Dra. Thais Vasconcelos Batista - DIMAp-UFRN Discentes Adelson Dias de Araujo Junior Bárbara Gabriella da Silva Soares Bruno Cipolla Moreira Jorge Pereira da Silva Juliana de Araújo Oliveira José Lucas Santos Ribeiro Marcel Luiz de Oliveira Mendonça Maychell Fernandes de Oliveira Ronaldo Gomes de Morais Júnior

Sumário

1 Introdução ................................................................................................................................ 5

2 Aplicação Guia Natal ............................................................................................................... 7

3 Aplicação ROTA ................................................................................................................... 51

3.1 Rota-Dashboard .............................................................................................................. 51

4 Aplicação Fala Natal .............................................................................................................. 69

4.1 Arquitetura ...................................................................................................................... 70

4.2 Especificações de Casos de Uso ..................................................................................... 71

5 Aplicação Smart Place ........................................................................................................... 96

5.1 Desenvolvimento do Sistema WEB ................................................................................ 97

5.1.1 Estrutura e Implementação do Sistema Web ........................................................... 97

5.1.2 Modelo ER da aplicação ........................................................................................ 106

5.2 Montagem e configuração do hardware ........................................................................ 108

5.2.1 DHT11 Sensor ....................................................................................................... 108

5.2.2 PIR Sensor ............................................................................................................. 111

5.3 Próximas atividades ...................................................................................................... 114

6 Aplicação de Monitoramento de Água e Energia ................................................................ 116

6.1 Objetivo ........................................................................................................................ 116

6.2 Contextualização ........................................................................................................... 116

6.3 Coleta de dados - Coletor Universal ............................................................................. 117

6.4 Diagrama de Classes ..................................................................................................... 118

6.5 Diagrama de Sequência ................................................................................................ 118

6.6 Hardware de Medição de Energia ................................................................................. 119

6.7 Aplicativo Android ....................................................................................................... 119

6.7.1 Metodologia de desenvolvimento .......................................................................... 120

6.8 Protótipo ........................................................................................................................ 121

6.9 Próximos Passos ........................................................................................................... 124

7 Considerações Finais ........................................................................................................... 125

Referências .............................................................................................................................. 126

Anexo A - Tutorial de configuração do Raspeberry Pi para execução do protótipo da aplicação de monitoramento de água e energia .................................................................. 129

1 Introdução

O WP2 - Aplicacoes do Projeto Smart Metropolis reune as atividades relativas ao planejamento e desenvolvimento de aplicacoes e/ou protótipos para aplicações com o intuito de possibilitar que os serviços oferecidos por uma cidade inteligente sejam mais eficientes. Tais aplicações tem como objetivo geral dar apoio aos cidadaos, a entidades responsaveis pela promocao de servicos publicos, entre outros possıveis interessados. Varias areas serao contempladas com aplicacoes durante a execucao do Projeto, tais como seguranca publica, turismo, transporte publico e privado, educacao, predios inteligentes, poluicao, servicos essenciais (agua, luz, gas etc.), dentre outros.

Para este segundo trimestre, que corresponde aos meses de maio, junho e julho de 2016, foi planejada a entrega de versões incrementais das aplicações apresentadas no primeiro trimestre, a saber: (i) Guia Natal, voltado para o setor turismo da cidade do Natal; (ii) ROTA, plataforma de software para suporte a segurança pública; (iii) Fala Natal, voltada para a comunicação entre a população e a Prefeitura Municipal do Natal no tocante ao registro de demandas não emergenciais; (iv) Smart Place, voltada para o gerenciamento inteligente de ambientes visando otimizar recursos disponíveis e contribuir com economia de energia elétrica, e; (v) uma aplicação para monitoramento de consumo de água e energia. Dentre os resultados alcançados no desenvolvimento dessas aplicações, pode-se citar:

● Aplicativo Guia Natal: finalização do desenvolvimento do aplicativo com a inclusão do serviço de localização, alerta de alarme de proximidade e funcionalidades relacionadas ao uso do mapa, além de melhorias feitas na apresentação da interface e validação dos serviços de nuvem utilizados pelo aplicativo;

● ROTA Dashboard: desenvolvimento de um novo ambiente de visualização de gráficos foi desenvolvido, através de tecnologias Web, além do melhoramento do front-end para receber mais dados temáticos em camadas de mapa e desenvolvimento de mecanismos de análises geográficas;

● Aplicativo ROTA-Viatura: através de testes de usabilidades com os policiais foi possível identificar alguns pontos a serem melhorados e incrementados na aplicação tanto no visual (frontend) quanto na parte interna do sistema (backend), em particular a criação de uma nova paleta de cores, visando o melhor uso e leitura das informações durante o dia ou em ambientes com muita luminosidade, e melhorias na comunicação em tempo real com os servidores da Polícia e no gerenciamento do GPS e bateria dos tablets;

● Aplicativo Fala Natal: desenvolvimento das principais telas e funcionalidades do aplicativo para a plataforma Android, mais especificamente cadastro de usuários, demandas, elogios e sugestões, bem como listagem das demandas cadastradas pelo usuário;

● Aplicação Smart Place: início do desenvolvimento um sistema Web de suporte ao gerenciamento dos recursos a serem controlados pela aplicação, além da montagem e configuração do hardware responsável por aferir dados de temperatura, umidade e presença meio ao ambiente monitorado;

● Aplicação de monitoramento de água e energia: desenvolvimento do Coletor Universal, ferramenta de comissionamento e a integração com o primeiro protótipo de hardware desenvolvido.

2 Aplicação Guia Natal

FindNatal é uma aplicação de turismo inteligente que visa enriquecer a experiência de viagem do turista, através de programas de software projetados para alavancar os mecanismos de infraestrutura da cidade. O aplicativo fornece tecnologia para coletar, processar, armazenar e analisar a vasta quantidade de dados proveniente de diversas fontes de sensoriamento, para tornar estes dados em poderosos insights. O FindNatal foi lançado em julho de 2014 e devido ao seu sucesso, os autores do projeto decidiram fazer um registro da marca. Tal registro demandou, inicialmente, uma mudança no nome do aplicativo de FindNatal para FindTrip. Porém, visando familiarizar o nome do aplicativo para a população, optou-se por chamar a instancia em execução em Natal de Guia Natal, mantendo a marca FindTrip, como a marca da plataforma responsável pelo desenvolvimento do mesmo. Esta mudança também visa facilitar a utilização do aplicativo em outras cidades. Assim, este e todos os outros relatórios seguintes irá se referir FindTrip como a plataforma de desenvolvimento e o aplicativo como sendo Guia Natal.

Nesse segundo trimestre do projeto foram implementadas as funcionalidades relacionadas ao mapa no aplicativo, para mostrar os locais mais próximo no mapa, na tela principal e para mostrar a rota até um local destino, na tela de detalhes do ponto turístico. Foi feita também, a adição do serviço de localização e do alarme de proximidade, que indica quando o usuário está a 500 metros de um local. Além disso, foram feitas diversas modificações na interface no aplicativo, como inclusão de uma tela sobre a plataforma FindTrip, inclusão da logomarca da Prefeitura Municipal do Natal no menu, adaptação da tela principal apara dispositivos com telas de 5 polegadas ou menos e melhorias da apresentação da interface em geral em todas as telas. Foram também realizadas também adição de novos campos nas telas de avaliação da cidade e reorganização destes campos, bem como a validação dos serviços de nuvem utilizados pelo aplicativo e tratamento dos dados de horários de fechamento e abertura dos pontos turísticos.

2.1 Objetivos da Aplicação

O Guia Natal, como uma aplicação de turismo inteligente tem como objetivos gerais oferecer uma ferramenta que proporcione aos turistas uma boa experiência de viagem e contribuir para geração de riqueza e lucro provenientes da atividade turística para as organizações e para a cidade. Mais especificamente, os objetivos do Guia Natal são oferecer ao turista um vasto conjunto de opções para visitação, onde ele pode consultar um ponto de interesse e obter informações, como: endereço, telefone, horário de funcionamento, site e

descrição. De forma a ajudá-lo a decidir o melhor local para conhecer na cidade. Além disso, o aplicativo tem por objetivo mostrar ao turista como chegar a determinado local, de acordo com sua posição atual, através da exibição da rota no mapa e através do alerta de proximidade. O Guia Natal oferece uma forma de consulta rápida aos locais através de um mecanismo de busca pelos locais cadastrados e uma visão geral dos pontos turísticos no mapa, de acordo com o interesse do turista. Outro objetivo do aplicativo, é monitorar e acessar a movimentação dos turistas na cidade, permitindo que gerentes e organizações governamentais possam entender o comportamento dos turistas. Isso auxilia diretamente processos de tomada de decisão e ajuda a identificar, por exemplo, os locais mais visitados, locais de maior concentração de turistas, entre outros.

Por fim o aplicativo tem o objetivo de reportar avaliações feitas pelos turistas, dos locais visitados e da cidade, para conhecimento do gestor e também dos usuários. Com esta informação o gestor tem um retorno direto sobre a experiência dos turistas em um determinado ponto turístico em relação ao acesso ao local, infraestrutura oferecida, forma de atendimento, segurança e preços. Além disso, o gestor consegue saber a experiência do turista ao visitar a cidade relacionada a diversos aspectos, como, qualidade de rodovias, segurança pública, restaurantes, serviço de táxi, etc. Para o turista o aplicativo exibe um valor que representa a média das avaliações feitas por outros turistas e serve como indicativo de qualidade do ponto turístico.

2.2 Especificações de Casos de Uso

A seguir, descrevemos casos de uso de especificação do Guia Natal. Os casos de uso

apresentados são:

● Buscar Ponto Turístico ● Entrar em Tipos ● Abrir Mapa Geral ● Fazer Avaliação da Cidade ● Ver Notificação de Proximidade ● Voltar à Tela Principal ● Modificar Configurações ● Ver Tela Sobre FindTrip ● Ver Rota para Ponto Turístico ● Ativar Alerta de Proximidade ● Desativar Alerta de Proximidade ● Fazer Avaliação do Ponto Turístico

O diagrama abaixo, mostra a organização destes casos de uso.

Figura 1. Diagrama de Casos de Uso do Guia Natal

2.2.1 Buscar Ponto Turístico

Caso de Uso: Buscar Ponto Turístico

Responsável: Equipe FindTrip

Descrição Geral: No caso de uso o usuário poderá realizar buscar por atrações turísticas utilizando a opção “Pesquise aqui” na tela principal do aplicativo.

Atores: Usuário Turista

Pré-Condição: Ter o aplicativo instalado no celular.

Pós-Condição: O aplicativo deve realizar uma busca no seu banco de dados interno de acordo com a palavra fornecida pelo usuário e retornar uma lista de atrações turísticas com esta palavra, apresentando esta lista em uma outra tela.

Fluxo Típico

No Ação

1 O usuário clica no campo “Pesquise aqui” e digita uma palavra que identifique a atração turística a ser buscada.

2 O usuário clica na imagem de lupa, que aparece à direita do campo de busca.

3 O aplicativo realiza uma busca em seu banco de dados interno de acordo com a palavra digitada e retorna uma lista de atrações turísticas com contém a palavra.

4 O aplicativo exibe esta lista em outra tela, para que o usuário possa selecionar um dos lugares mostrados.

5 O caso de uso termina.

Fluxo Alternativos

Alternativa 1: Ausência de pontos turísticos com contenham a palavra de busca

No Ação

1 O usuário clica no campo de busca e digita a palavra de busca.

2 O aplicativo faz uma busca em seu banco de dados interno de acordo

com a palavra digitada e retorna uma lista vazia.

3 O aplicativo exibe uma mensagem Toast para o usuário: Resultado não disponível.

Figura 2. Telas de Busca por Ponto Turístico

2.2.2 Entrar em Tipos

Caso de Uso: Entrar Tipos


Descrição Geral: No caso de uso o usuário poderá escolher uma das opções de tipos de atrações turísticas na tela principal ou menu lateral do aplicativo para visualizar os subtipos de cada tipo e acessar informações sobre o ponto turístico desejado.



Pós-Condição: O aplicativo deve realizar uma busca no seu banco de dados interno de acordo o ID do tipo selecionado pelo usuário e retornar uma lista de subtipos, apresentando esta lista em uma outra tela.

Fluxo Típico

No Ação

1 O usuário clica em uma das quatro primeiras opções do menu da tela principal do aplicativo. Opções: Conheça Natal, Alimentos e Bebidas, Hospedagem, Serviços.

2 O aplicativo faz uma busca no seu banco de dados interno, de acordo com o ID do tipo clicado pelo usuário e retorna uma lista de subtipos.

3 O aplicativo exibe essa lista em uma tela onde o usuário pode selecionar um dos subtipos, de acordo com seu interesse.


Fluxo Alternativos

Alternativa 1: Escolher o tipo através do menu lateral

No Ação

1 O usuário acessa o menu lateral do aplicativo, clicando no símbolo de três linhas no canto superior esquerdo, ou deslizando na tela da esquerda para a direita.

2 O usuário clica em uma das quatro opções abaixo do menu lateral. Opções: Conheça Natal, Alimentos e Bebidas, Hospedagem, Serviços.

3 O aplicativo faz uma busca no seu banco de dados interno, de acordo com o ID do tipo clicado pelo usuário e retorna uma lista de subtipos.

4 O aplicativo exibe essa lista em uma tela onde o usuário pode selecionar um dos subtipos, de acordo com seu interesse.

Interface do Usuário

Figura 3. Telas para Entrar em Tipos no Guia Natal 2.2.3 Abrir Mapa Geral

Caso de Uso: Entrar Tipos


Descrição Geral: No caso de uso o usuário poderá abrir o mapa para visualizar as atrações de acordo com os subtipos, utilizando o menu principal ou o menu lateral.


Pré-Condição: Ter o aplicativo instalado no celular, ativar o acesso à Internet, ativar o uso de GPS do celular.

Pós-Condição: O aplicativo deve exibir no mapa os marcadores dos lugares, de acordo com a opção de subtipo selecionada pelo usuário e ao clicar

num marcador específico, o aplicativo deve exibir um pop-up com informações básicas sobre o local e levar o usuário para a tela com as informações detalhadas sobre o local.

Fluxo Típico

No Ação

1 O usuário clica na opção “Mapa” do menu da tela principal do aplicativo.

2 O usuário seleciona uma das opções ao lado direito do campo “Filtrar por:”

3 O aplicativo faz uma busca no banco de dados interno de acordo com o ID do subtipo selecionado pelo usuário e retorna uma lista de lugares relacionados ao subtipo.

4 O aplicativo exibe no mapa, um marcador, de acordo com a latitude e longitude, para cada lugar na lista.

5 O usuário clica em um marcador no mapa.

6 O aplicativo abre um pop-up com o nome do local clicado, o endereço e uma seta azul.

7 O usuário clica na seta azul.

8 O aplicativo abre a tela com as informações detalhadas do local.


Fluxo Alternativos

Alternativa 1: Escolher o tipo através do menu lateral

No Ação

1 O usuário acessa o menu lateral do aplicativo, clicando no símbolo de três linhas no canto superior esquerdo, ou deslizando na tela da esquerda para a direita.

2 O usuário clica em na opção “Mapa”


4 O aplicativo faz uma busca no banco de dados interno de acordo com o ID do subtipo selecionado pelo usuário e retorna uma lista de lugares relacionados ao subtipo.

5 O aplicativo exibe no mapa, um marcador, de acordo com a latitude e longitude, para cada lugar na lista.

6 O usuário clica em um marcador no mapa.

7 O aplicativo abre um pop-up com o nome do local clicado, o endereço e uma seta azul.

8 O usuário clica na seta azul.

9 O aplicativo abre a tela com as informações detalhadas do local.

Alternativa 2: Não há subtipo cadastrado

No Ação

1 O usuário acessa o menu lateral do aplicativo ou acessa a página principal e clica na opção “Mapa”.


3 O aplicativo faz uma busca no banco de dados interno de acordo com o ID do subtipo selecionado pelo usuário e retorna uma lista vazia.

4 O aplicativo exibe uma mensagem para o usuário: “Não há item do tipo “X” cadastrado”.


Figura 4. Telas para Acessar Mapa de Locais

Figura 5. Telas para Acessar Mapa de Locais

2.2.4 Fazer Avaliação da Cidade

Caso de Uso: Fazer Avaliação da Cidade


Descrição Geral: No caso de uso o usuário poderá avaliar a cidade que está visitando.


Pré-Condição: Ter o aplicativo instalado no celular. Ter acesso à internet.

Pós-Condição: O aplicativo deve mostrar um conjunto de telas com opções de avaliação, e ao final deve enviar a avaliação do usuário para a nuvem.

Fluxo Típico

No Ação

1 O usuário clica na opção “Avaliação” do menu da tela principal do aplicativo ou do menu lateral.

2 O aplicativo exibe uma tela com uma mensagem explicativa sobre a avaliação que será feita pelo usuário e um botão “Começar”.

3 O usuário clica no botão “Começar”.

4 O aplicativo exibe a primeira tela de avaliação com os seguintes campos: Idade/Profissão, Nacionalidade, Gênero, Estado/Cidade, Motivo da Viagem e Como Viajou. Além disso, no final da tela o aplicativo exibe dois botões que o usuário pode utilizar para ir para a próxima tela ou retornar para a anterior, e um texto indicando em qual tela o usuário está.

5 O usuário preenche os campos da primeira tela.

6 O aplicativo salva as informações preenchidas.

7 O usuário clica no botão “Próximo”.

8 O aplicativo exibe a segunda tela de avaliação com os seguintes campos: Limpeza Pública, Segurança Pública, Acessibilidade, Serviço de Táxi e Transporte Público.

9 O usuário preenche os campos da segunda tela.



12 O aplicativo exibe a terceira tela de avaliação com os seguintes campos: Telecomunicações, Sinalização Turística, Infraestrutura Turística, Aeroporto e Rodovias.

13 O usuário preenche os campos da terceira tela.



O aplicativo exibe a quarta tela de avaliação com os seguintes campos: Restaurantes, Acomodação, Diversão Noturna, Rodoviária e Guia de Turismo.

16 O usuário preenche os campos da quarta tela.



19 O aplicativo exibe a quinta tela da avaliação com os seguintes campos: Informação Turística, Hospitalidade, Culinária Local, Preços e Bugueiro.

20 O usuário preenche os campos da quinta tela.



23 O aplicativo mostra a sexta tela da avaliação com os seguintes campos: Passeios Turísticos, Praias Urbanas, Atrativos Turísticos, Opções de Lazer em Geral e O Destino Natal.

24 O usuário preenche os campos da sexta tela.



27 O aplicativo exibe a última tela da avaliação da cidade. Esta tela contém um campo “Deixe seu comentário” onde o usuário pode ou

não digitar um comentário sobre a cidade. No final da tela o aplicativo exibe uma mensagem de agradecimento e um botão “Voltar à Tela Inicial”

28 O usuário clica no campo de texto e digita um comentário.

29 O aplicativo salva o comentário digitado.

30 O usuário clica no botão “Voltar à Tela Inicial”.

31 O aplicativo envia das informações da avaliação para a nuvem.

32 O aplicativo exibe a tela principal.


Fluxo Alternativos

Alternativa 1: O usuário clica em Anterior

No Ação

1 O usuário clica no botão “Anterior”.

2 O aplicativo salva as informações preenchidas até aquele momento e exibe a tela anterior.

3 O usuário altera algum campo já preenchido.

4 O aplicativo atualiza a informação salva anteriormente.

5 O usuário clica em “Próximo”.

6 O aplicativo exibe a próxima tela com os dados que o usuário havia começado a preencher.

Figura 6. Telas de Avaliação da Cidade

2.2.5 Ver Notificação de Proximidade

Caso de Uso: Ver Notificação de Proximidade


Descrição Geral: No caso de uso o usuário poderá visualizar um local no mapa quando estiver a 500 metros.


Pré-Condição: Ter o aplicativo instalado no celular. Ter acesso à internet. Estar com GPS ativado.

Pós-Condição: O aplicativo deve notificar o usuário quando estiver a 500 metros do local desejado e mostrar este local no mapa, para que o usuário possa acessar suas informações.

Fluxo Típico

No Ação

1 O aplicativo exibe um alerta de notificação na barra de tarefas do celular. Indicando que ele está próximo ao local.

2 O usuário clica no alerta.

3 O aplicativo exibe uma tela com o mapa e adiciona a rota até o local desejado.

4 O caso de uso termina. Interface do Usuário 2.2.6 Voltar à Tela Principal

Caso de Uso: Voltar à Tela Principal


Descrição Geral: No caso de uso o usuário poderá retornar à tela principal do aplicativo usando o menu lateral.



Pós-Condição: O aplicativo deve exibir sua tela principal.

Fluxo Típico

No Ação

1 O usuário acessa o menu lateral do aplicativo.

2 O usuário clica na opção “Principal”.

3 O aplicativo retorna à tela principal.


Figura 8. Telas para Voltar à Tela Principal

2.2.7 Modificar Configurações

Caso de Uso: Modificar Configurações


Descrição Geral: No caso de uso o usuário poderá alterar as configurações do aplicativo para permitir ou não que sua localização seja compartilhada.



Pós-Condição: O aplicativo deve exibir uma tela de configurações, onde o usuário pode ativar ou desativar a opção “Eu Aceito Compartilhar minha Localização”.

Fluxo Típico

No Ação


2 O usuário clica na opção “Configurações”.

3 O aplicativo exibe a tela de configurações do aplicativo. Nesta tela o usuário pode ativar ou desativar a opção “Eu Aceito Compartilhar minha Localização”, clicando na CheckBox ao lado desta frase.

4 O usuário mantém a opção ativada, não clicando na CheckBox.

5 O aplicativo salva essa informação.

6 O usuário clica no botão “Salvar”.

7 O aplicativo retorna a tela inicial.


Fluxo Alternativos

Alternativa 1: Usuário não permite compartilhamento de localização

No Ação

1 O usuário clica na CheckBox, não permitindo que sua localização seja

compartilhada

2 O aplicativo salva essa informação.

4 O usuário clica no botão “Salvar”.

3 O aplicativo retorna a tela inicial.

5 O aplicativo encerra o serviço de localização.

Figura 9. Telas para Alterar Configurações do Aplicativo

2.2.8 Ver Tela Sobre FindTrip

Caso de Uso: Ver Tela Sobre FindTrip


Descrição Geral: No caso de uso o usuário poderá acessar a tela sobre a plataforma FindTrip.



Pós-Condição: O aplicativo deve exibir uma tela explicativa sobre a plataforma.

Fluxo Típico

No Ação


2 O usuário clica na opção “Plataforma FindTrip”.

3 O aplicativo exibe uma tela com a logomarca da plataforma, um texto explicativo e as imagens da UFRN, IMD e do projeto SmartMetropolis. Ao final da tela, o aplicativo exibe o botão “Voltar à Tela Inicial”.


5 O aplicativo retorna à tela inicial.


Fluxo Alternativos

Alternativa 1: Usuário clica nas imagens.

No Ação

1 O usuário clica em uma das três imagens abaixo do texto explicativo.

2 O aplicativo abre o site correspondente à imagem.

3 O usuário clica no botão “Voltar” do celular.


5 O aplicativo retorna à tela inicial.

Figura 10. Telas para Acessar tela sobre FindTrip

2.2.9 Ver Rota para Ponto Turístico

Caso de Uso: Ver Rota para Ponto Turístico


Descrição Geral: No caso de uso o usuário poderá visualizar a rota até o ponto turístico, a partir da sua localização atual.



Pós-Condição: O aplicativo deve exibir a rota até o local no mapa, com dois marcadores, um indicando a posição atual do usuário e outro indicando o destino.

Fluxo Típico

No Ação

1 O usuário entra nos tipos, através do menu principal ou do menu lateral.

2 O aplicativo exibe na tela uma lista de subtipos.

3 O usuário clica em um subtipo da lista.

4 O aplicativo faz uma busca no banco de dados interno, de acordo com o ID do subtipo e retorna uma lista de lugares.

5 O usuário clica em um ponto turístico.

6 O aplicativo exibe a tela de detalhes de ponto turístico.

7 O usuário clica no ícone do mapa do lado direito do endereço do local.

8 O aplicativo exibe no mapa, dois marcadores, um indicando a posição atual do usuário e indicando o destino. E a traça a rota entre os dois marcadores.

9 O usuário clica no marcador que indica a posição atual.

10 O aplicativo exibe a mensagem “Você está aqui” acima do marcador.

11 O usuário clica no marcador do destino.

12 O aplicativo exibe uma mensagem com o nome do local, acima do marcador.


Fluxo Alternativos

Alternativa 1: O usuário não está com o GPS ativado

No Ação


2 O aplicativo exibe um pop-up com a mensagem: “Ative o GPS ou qualquer outro serviço de localização para encontrar a localização atual. Clique OK para ir para as configurações de localização para fazer isso.”

3 O usuário clica na opção OK.

4 O aplicativo abre as configurações de localização do celular.

O usuário ativa o GPS e clica na opção “Voltar” do celular.

Alternativa 2: O usuário não está com acesso à Internet


2 O aplicativo exibe um pop-up com a mensagem: “Para calcular a rota é necessária conexão com a internet, ative sua internet para prosseguir.”

3 O usuário clica em OK.


Figura 11. Telas para Visualização de Rota do Ponto Turístico 2.2.10 Ativar Alerta de Proximidade

Caso de Uso: Ativar Alerta de Proximidade


Descrição Geral: No caso de uso o usuário poderá ativar o alerta de proximidade para ser notificado pelo aplicativo quando estiver a uma distância de 500

metros.



Pós-Condição: O aplicativo deve exibir uma mensagem confirmando que o alerta foi ativado e alterar a cor do ícone de alerta.

Fluxo Típico

No Ação







7 O usuário clica no ícone de alerta, do lado direito ao endereço.

8 O aplicativo exibe um pop-up com a mensagem: “Quer ser avisado quando você estiver a 500 metros do destino escolhido?”. E dois botões para ativar o alarme ou cancelar a operação.

9 O usuário clica no botão “Ativar”.

10 O aplicativo alterar a cor do ícone, exibe a mensagem “O alerta de proximidade foi adicionado” e o pop-up desaparece.


Fluxo Alternativos

Alternativa 1: O usuário cancela operação

No Ação


2 O aplicativo exibe um pop-up com a mensagem: “Quer ser avisado quando você estiver a 500 metros do destino escolhido?”. E dois botões para ativar o alarme ou cancelar a operação.

3 O usuário clica no botão “Cancelar”.

4 O aplicativo fecha o pop-up.

Figura 12. Telas para Ativar Alerta de Proximidade

2.2.11 Desativar Alerta de Proximidade

Caso de Uso: Desativar Alerta de Proximidade


Descrição Geral: No caso de uso o usuário poderá desativar o alerta de proximidade.



Pós-Condição: O aplicativo deve exibir uma mensagem confirmando que o alerta foi desativado e alterar a cor do ícone de alerta.

Fluxo Típico

No Ação








8 O aplicativo exibe um pop-up com a mensagem: “Quer ser avisado quando você estiver a 500 metros do destino escolhido?”. E dois botões para desativar o alarme ou cancelar a operação.

9 O usuário clica no botão “Desativar”.

10 O aplicativo altera a cor do ícone, exibe a mensagem “O alerta de proximidade foi removido” e o pop-up desaparece.


Fluxo Alternativos


No Ação


2 O aplicativo exibe um pop-up com a mensagem: “Quer ser avisado

quando você estiver a 500 metros do destino escolhido?”. E dois botões para ativar o alarme ou cancelar a operação.



Figura 13. Telas para Desativar Alerta de Proximidade

2.2.12 Fazer Avaliação do Ponto Turístico

Caso de Uso: Fazer Avaliação do Ponto Turístico


Descrição Geral: No caso de uso o usuário poderá avaliar um ponto turístico que visitou.


Pré-Condição: Ter o aplicativo instalado no celular. Estar com acesso à internet.

Pós-Condição: O aplicativo deve exibir um pop-up de avaliação do ponto turístico.

Fluxo Típico

No Ação







7 O usuário clica no botão “Faça sua Avaliação”, abaixo do endereço.

8 O aplicativo exibe um pop-up para que o usuário possa fazer sua avaliação. No pop-up, o usuário pode avaliar o ponto turístico de acordo com: Acesso, Infraestrutura, Atendimento, Experiência, Segurança e Preço. Após definir os valores para essas características, o usuário pode deixar um comentário sobre o local. No final da tela, o aplicativo exibe dois botões para confirmar a avaliação ou cancelar a operação.

9 O usuário avalia o ponto turístico através das estrelas ao lado das opções.

10 O usuário digita um comentário no campo “Deixe seu comentário”.

11 O usuário clica no botão “Confirmar”.

12 O aplicativo salva os dados e envia para a nuvem.

13 O aplicativo exibe a mensagem “Avaliação Concluída”.


Fluxo Alternativos


No Ação

1 O usuário clica no botão “Faça sua Avaliação”, abaixo do endereço.

2 O aplicativo exibe um pop-up para que o usuário possa fazer sua avaliação. No pop-up, o usuário pode avaliar o ponto turístico de acordo com: Acesso, Infraestrutura, Atendimento, Experiência, Segurança e Preço. Após definir os valores para essas características, o usuário pode deixar um comentário sobre o local. No final da tela, o aplicativo exibe dois botões para confirmar a avaliação ou cancelar a operação.



Figura 14. Telas para Fazer Avaliação do Ponto Turístico 2.3 Arquitetura

A Figura X1 descreva a arquitetura do Guia Natal. O componente que representa a aplicação Web é responsável por fornecer e gerenciar os dados das informações turísticas, fornecer serviços que o aplicativo precisa utilizar para envio e recebimento de dados de localização e avaliação e também engloba as funções do componente de BI que foi removido da arquitetura original. A aplicação Web da arquitetura anterior foi implementada utilizando as tecnologias Java Servlets e GAE, para esta nova versão do aplicativo este componente foi reconstruído utilizando um novo conjunto de tecnologias. 2.3.1 Visão Geral

Nesta seção detalharemos a arquitetura do Guia Natal, mostrando uma visão de seus componentes e detalhando as classes que fazem parte de cada componente. O Guia Natal possui uma arquitetura formada por 9 componentes e se comunica com o componente Web App para envio e recebimento dos dados do usuário (GPS, idioma, avaliação) e das atrações. A Figura 15 descreve os componentes que compõem a arquitetura do aplicativo e as dependências entre os vários componentes. Nesta figura, as setas tracejadas são utilizadas para relacionar interfaces e dependências de chamada entre componentes.

Figura 15. Arquitetura do Guia Natal

● O componente FindTrip é responsável pela inicialização do aplicativo, criação do banco de dados interno e inicialização do serviço de localização. Este componente também é composto por classes responsáveis por implementar o alerta de proximidade dos pontos turísticos. Para executar tais atividades este componente depende do componente Service, Utils e do componente Model.

● O componente Service é composto pela classe que implementa o serviço de localização, que é usado pelo aplicativo para envio da posição GPS do turista para a Web App, estes dados são armazenados na nuvem para uso posterior de gestores e órgãos públicos.

● As classes de domínio da aplicação fazem parte do componente Model. Estas classes refletem as entidades utilizadas pelo aplicativo para representar os pontos turísticos e sua categorização em tipos e subtipos.

● O componente Utils contém duas classes que auxiliam na criação do banco de dados, no momento da inicialização do aplicativo e uma classe de teste para o uso do GPS.

● Cada tela do aplicativo foi desenvolvida por meio do uso de Fragments. As classes que representam estas telas fazem parte do componente Fragment, que é responsável pela exibição dos dados do aplicativo na interface do celular e pelo tratamento de eventos provenientes da interação do usuário com o aplicativo.

● O componente Fragment faz uso de classes que estão no componente Adapter. Este componente é responsável por exibir dados em forma de lista na tela do celular, onde cada linha é clicável e leva o usuário para outra tela do aplicativo.

● Ao usar o aplicativo o usuário pode fazer dois tipos de avaliação: da cidade e de um ponto turístico. Esses dados, assim como os dados de localização são enviados para a Web App e para isso, o aplicativo faz uso do componente Api. Neste componente estão definidas classes que são responsáveis por implementar métodos para requisitar os serviços Web fornecidos pela Web App, através de requisições HTTP.

● O componente Dao fornece classes que proveem uma camada de abstração entre as classes do aplicativo e o banco de dados. Cada classe contém um conjunto de métodos para criar, acessar, atualizar, deletar ou buscar dados no banco de dados do Guia Natal.

● Este componente se relaciona com o componente Database, que representa o banco de dados do aplicativo. Este banco é criado pelo ActiveAndroid ORM [22].

● O componente Web App representa a aplicação Web com a qual o aplicativo interage, enviando e recebendo dados sobre os usuários e sobre as atrações turísticas.

2.3.1.1 Visão Detalhada do Componente Adapter

A Figura 16 descreve uma visão detalhada do componente Adapter. Este componente é formado por duas classes que são utilizadas pelos Fragments para exibir dados em lista. A classe PlaceAdapter estende a classe RecyclerView.Adapter<PlaceAdapter.PlaceViewHolder> do Android. Esta classe é responsável por exibir os pontos turísticos em lista na tela do celular. Para cada ponto turístico, a classe gera um CardView com a foto do local, o nome do local, uma mini-descrição e o valor atual da avaliação do local. A classe PlaceAdapter utiliza a classe PlaceViewHolder para inicializar seus componentes internos (ImageView, CardView, TextView, RatingBar) e tratar eventos de clique no CardView. Quando o PlaceAdapter é chamado pelo Fragment, ele recebe como parâmetros no seu construtor, a lista de lugares a serem exibidos e o contexto, que é o próprio Fragment. O método onBindViewHolder é usado para atribuir as informações de cada local na lista aos componentes internos da classe PlaceViewHolder.

A classe TypeAdapter também estende a classe RecyclerView.Adapter<PlaceAdapter.PlaceViewHolder> do Android e utiliza a classe TypeViewHolder para inicialização de componentes internos e tratamento de eventos. Ela tem

um comportamento semelhante à PlaceAdapter, o que muda é o tipo de informação que ela exibe na tela, apenas o nome do subtipo. Ambas as classes implementam o método onClick para tratar o clique do usuário e chamar um novo Fragment.

Figura 16:Visão detalhada do componente Adapter

2.3.1.2 Visão Detalhada do Componente Api

A Figura 17 descreve os detalhes do componente Api. Este componente é formado por três classes que são responsáveis por fazer as requisições aos serviços da Web App, para envio e recebimento de dados de localização e avaliação. A classe DaoServices disponibiliza métodos que fazem requisições a três tipos de serviço: GPS_TRACKER_TARGET, REVIEW_RATE_TARGET e CITY_REVIEW_TARGET. Estes serviços estão relacionados respectivamente ao envio de dados de localização, envio de dados de avaliação de um ponto turístico, recebimento da rate de um ponto turístico e envio de dados de avaliação da cidade.

A classe DaoCloud implementa os métodos que preparam as requisições GET e POST que são utilizados pelos métodos da classe DaoServices. Esta classe utiliza a classe ApiRequest, que é responsável por realizar a requisição, fazendo a conexão com o servidor da Web App.

Figura 17: Visão detalhada do componente Api

2.3.1.3 Visão Detalhada do Componente Dao

A Figura 18 descreve uma visão geral do componente Dao. Este componente contém classes DAO que representam uma camada entre a aplicação e o banco de dados interno. Para cada classe do componente Model, existe uma classe DAO que provê métodos para criar, acessar, deletar e atualizar este dado no banco de dados. Para criação e manipulação do banco de dados o Guia Natal utiliza o ActiveAndroid ORM, que encapsula a complexidade da criação e comunicação com o banco.

Todas as classes implementam as operações básicas para manipulação dos dados utilizando os métodos load, save e delete do ORM. O método save serve para salvar o dado no banco e também para atualizar este dado. Operações mais complexas podem ser implementadas nas classes de acordo com a necessidade, utilizado consultas mais complexas. Para o DaoType foram implementadas operações de busca de um tipo pelo nome e pelo ID e busca de tipos de acordo com a linguagem (Inglês ou Português). O DaoSubtype fornece métodos para buscar um subtipo pelo ID e pelo nome e para buscar subtipos de acordo com um tipo específico. O DaoReview, fornece, além das operações básicas, um método para pegar todos os Reviews de um lugar.

O DaoPlace possui métodos para buscar lugares de acordo com um subtipo e de acordo com o nome. Um lugar possui horários de abertura e fechamento, que são representados no Model pela classe OpeningTime. O DaoOpeningTime possui métodos para buscar horários de abertura e de fechamento de um lugar, de acordo com o dia da semana. Os outros Daos implementam as operações básicas, busca de acordo com ID e o método getAll.

Figura 18. Visão detalhada do componente Dao

2.3.1.4 Visão Detalhada do Componente FindTrip

A Figura 19 descreve os detalhes do componente FindTrip. Este componente contém as classes responsáveis pela inicialização do aplicativo, criação do banco de dados, gerenciamento das preferências do usuário no aplicativo (permissões, ID do usuário, linguagem), e classes que auxiliam na implementação do alerta de proximidade. A classe MyApplication é responsável pela criação do banco de dados e adição das classes do componente Model no banco de dados. A classe UserPreferences oferece um conjunto de métodos que salvam e recuperam dados de preferências do usuário.

A classe MainActivity é a principal classe do aplicativo, ela inicializa componentes de interface gráfica, como o NavigationDrawer, que representa o menu lateral do aplicativo. Chama a AsyncTask ProgressTask para popular o banco de dados com os dados dos pontos turísticos que estão armazenados em arquivos JSON, utilizando métodos da classe JSONTools do componente Utils. A MainActivity implementa o método onNavigationItemSelected, que chama um Fragment específico de acordo com o clique do usuário no menu lateral do aplicativo.

As classes ProximityActivity e NotificationViewActivity estão relacionadas à implementação do alerta de proximidade para um determinado ponto turístico. Elas são utilizadas pelo PlaceDetailsFragment do componente Fragment. A ProximityActivity cria uma notificação que é ativada quando o usuário está a 500 metros do local, através do serviço NotificationManager do Android. A classe NotificationViewActivity é chamada por esta classe quando o usuário clica na notificação na barra de tarefas do celular. A NotificationViewActivity chama o MapFragment para mostrar a rota até o local para o usuário.

Figura 19. Visão detalhada do componente FindTrip

2.3.1.5 Visão Detalhada do Componente Fragment

A Figura 20 descreve os detalhes do componente Fragment. Este componente contém as classes que representam as telas do aplicativo. O classe MainFragment representa a tela inicial do aplicativo e no método onCreateView, inicializa o serviço de localização do aplicativo, de acordo com as preferências do usuário, adapta os componentes de interface gráfica, quando o celular possui tela com o valor em polegadas inferior a cinco, chega e requisita algumas permissões do Android para o uso do mapa, em dispositivos com Android

6.0, inicializa todos os componentes da interface gráfica e trata os eventos de clique do usuário, chamando os outros Fragments do aplicativo.

Figura 20. Visão detalhada do componente Fragment

A classe SubTypeListFragment é responsável por mostrar na tela, a lista de subtipos disponíveis de acordo com a opção escolhida pelo usuário (Conheça Natal, Alimentos e Bebidas, Hospedagem, Serviços). Esta classe chama o DaoType e DaoSubType, para respectivamente, buscar o tipo de acordo com a opção clicada e buscar os subtipos de acordo com o tipo. Essa lista de subtipos é passada para o TypeAdapter, que carrega os dados na tela.

As classes GeneralMapFragment e MapFragment são responsáveis pela exibição do mapa no aplicativo. A primeira mostra no mapa marcadores para todos os subtipos de acordo com a seleção do usuário. E trata o evento de clique no marcador, mostrando um popup com nome e endereço do local e leva o usuário para a tela de detalhes deste local. O MapFragment é chamado pelo PlaceDetailsFragment para gerar a rota da localização atual do usuário até o local de destino.

O PlaceListFragment é responsável pela exibição dos pontos turísticos de acordo com o subtipo escolhido pelo usuário. Esta classe é chamada pelo TypeAdapter, quando o usuário clica em um dos itens da lista de subtipos. O ReviewFragment é responsável pela exibição de todas as telas de avaliação da cidade, pelo armazenamento e envio dos dados de avaliação para a nuvem. As classes SettingsFragment e FindTripPlatformFragment são responsáveis pela inicialização dos componentes gráficos e tratamento de eventos das telas de configurações e Plataforma FindTrip. Na tela de configurações o usuário pode permitir ou não o compartilhamento da sua localização, caso o usuário não permita, o aplicativo encerra o serviço de localização, consultando as preferências através da classe UserPreferences. 2.3.1.6 Visão Detalhada do Componente Model

A Figura 21 descreve os detalhes do componente Model. Este componente possui classes que representam o domínio do aplicativo, e refletem as entidades armazenadas no banco de dados do aplicativo. Todas as classes nesse componente estendem a classe com.activeandroid.Model do ActiveAndroid ORM, dessa forma o ORM cria internamente tabelas no banco de dados para armazenar estes objetos. As classes utilizam as anotações @Table e @Column para indicar para o ORM, a tabelas que deve ser criada e suas colunas.

As classes do Model representam: Type: Categoria de interesse do turista, por exemplo, Hospedagem. SubType: Subcategoria de Tipo, por exemplo, Albergue, Hotéis. Place: Representa um ponto turístico, por exemplo, Arituba Park Hotel.

CityReview: Representa o conjunto de dados gerado pela avaliação da cidade, de acordo com aspectos como, Segurança pública, Serviço de Táxi, etc. E dados do próprio usuário como, idade, profissão, etc.

GPSTracker: Representa a localização do usuário num determinado momento e é formado pela data, latitude, longitude, nacionalidade e ID do usuário.

Language: Representa o idioma do usuário. OpeningTime: Representa os horários de abertura e fechamento de um ponto turístico. Review: Representa a avaliação de um ponto turístico feita pelo usuário,

compreendendo um TouristicReviewType (acesso, preço), o local, a rate do tipo de revisão e um comentário.

TouristicReviewType: Representa um tipo de revisão (acesso, infraestrutura, atendimento, experiência, segurança e preço).

Figura 21. Visão detalhada do componente Model

2.3.1.7 Visão Detalhada do Componente Service

A Figura 22 descreve os detalhes do componente Service. Este componente contém a classe LocationService que estende a classe android.app.Service do Android. Esta classe utiliza o LocationManager para receber atualizações da posição do usuário de 5 em 5 metros a cada cinco minutos e envia esta localização para a nuvem chamando o método postGPSTracker do DaoServices. Este serviço é inicializado pelo MainFragment e executa em background.

Figura 22. Visão detalhada do componente Service

2.3.1.8 Visão Detalhada do Componente Utils

A Figura 23 descreve os detalhes do componente Utils. Este componente possui as classes GPSTest e JSONTools. A classe GPSTest é utilizada pelo MapFragment para testar se o aplicativo consegue acessar a localização do usuário via GPS, checando conexão com

internet e ativação do GPS no celular. A classe JSONTools oferece um conjunto de métodos para popular o banco de dados acessando os arquivos JSON armazenados no aplicativo. Esta classe interage diretamente com as classes do componente Dao, para salvar os dados no banco e é chamada pela MainActivity durante a inicialização do aplicativo.

Figura 23. Visão detalhada do componente Utils

3 Aplicação ROTA

Este capítulo apresenta detalhes do ROTA, plataforma em desenvolvimento para auxiliar atividades relacionadas à segurança pública. No Rota-Dashboard, o foco do segundo trimestre foi dar avanço às análises geoespaciais que possam dar valor à plataforma. Trazer informações que utilizam os dados disponíveis é a prioridade da descrição das atividades desenvolvidas, as quais buscaram agregar conhecimentos de banco de dados às necessidades dos dados geoespaciais. Ainda, o componente de visualização de gráficos foi iniciado, o qual representará grande importância ao longo do desenvolvimento da plataforma. No Rota-Viatura, através de testes de usabilidade com os policiais, foi possível identificar alguns pontos a serem melhorados e incrementados na aplicação tanto no visual (front-end) quanto na parte interna do sistema (back-end). Em particular, foi criada uma nova paleta de cores, visando o melhor uso e leitura das informações durante o dia ou em ambientes com muita luminosidade, e foram implementadas melhorias na comunicação em tempo real com os servidores da Polícia e no gerenciamento do GPS e bateria dos tablets.

3.1 Rota-Dashboard Dando continuidade à proposta de dar à aplicação ROTA um viés de análise dos dados que por ele circulam, o ROTA-Dashboard é uma plataforma que suporta camadas de mapa as quais trazem consigo informações sincronizadas sobre o andamento da patrulha das viaturas. Sendo assim, utilizando conceitos de banco de dados geoespaciais, esse Dashboard oferece a perspectiva da análise das trajetórias e ocorrências em relação à logradouros e AISPs, regiões estratégicas da segurança da cidade. Na figura 24, pode-se ter noção do ambiente de camadas temáticas da plataforma, em que pode-se visualizar um mapa de calor das ocorrências sob os polígonos das AISPs, os quais estão coloridos de acordo com a quantidade de veículos presentes naquele momento de rastreio.

Figura 24 - Captura de tela da funcionalidade temática do Dashboard.

Como seu viés é puramente analítico, o suporte para gráficos estatísticos também é de fundamental importância. Para isso, foram desenvolvidas informações relevantes que relacionem os dados espaciais entre si (trajetórias, ocorrências, logradouros e AISPs) de modo que seja possível retirar prognósticos menos intuitivos da situação das patrulhas, como padrões de dispersão das ocorrências, similaridades entre trajetórias e distribuição das patrulhas entre os logradouros. O estado atual da aplicação permite que boa parte dessas camadas temáticas (mapas) e gráficos já estejam funcionando de maneira síncrona com a base de dados. Para tanto, nesse período, além da sua folha de estilo ter sido organizada e aprimorada, foi desenvolvido em PHP o código-fonte que oferece essa dinamicidade à aplicação que antes funcionava de maneira estática; ou seja, agora ela tem os recursos para através da base de dados exibir camadas e gráficos de maneira sincronizada, mas ainda há muito de se avançar. Muitas outras análises implementadas no banco de dados geoespacial ainda estão por ser desenvolvidas dessa forma, no entanto, essas análises já representam funcionalidades notáveis da plataforma, outras, ficaram para implementação nos próximos trabalhos, mas boa parte delas foram desenvolvidas e são descritas nas próximas seções. 3. 1. 1. Detalhes de implementação

Como dito, já existia uma versão do Dashboard no final do primeiro trimestre, porém essa versão utiliza apenas dados estáticos que estavam definidos no próprio código utilizando JavaScript, planejava-se deixar o Dashboard dinâmico utilizando JavaServer Faces (JSF), porém ao ter contato com os sistemas utilizados na polícia e ao levantar os requisitos com o major decidimos que PHP seria a melhor tecnologia para a implementação, visto que supriria as necessidades e seria mais rápido para o desenvolvimento, devido a experiência com a linguagem. No geral o PHP é utilizado para fazer uma conexão com o banco PostgresSQL, rodar as queries necessárias e passar o resultado para ser exibido com o JavaScript, através do Leaflet.js[20] e Chart.js[35], dessa forma é possível exibir os dados que estão armazenados no banco no mapa e também pode-se mostrar gráficos como por exemplo a porcentagem de ruas patrulhadas em cada dia da semana. No caso de queries com maior demanda de processamento, como a das porcentagens das ruas patrulhadas citada anteriormente, decidiu-se que o sistema executaria uma query diariamente e salvaria no banco o resultado, dessa forma o código PHP só precisaria executar um SELECT no banco e pegar o resultado rapidamente, mais detalhes dessas queries serão explicados na próxima sessão. Para a implementação dessa funcionalidade foi preciso instalar o PGAgent, após configurá-lo criamos um Job, atribuindo um nome e classe para ele. Com isso pronto podemos atribuir uma query SQL para o Job e definir quando ele vai executar, no nosso caso o mesmo horário todos os dias. Ainda, nesse trimestre começou-se a ser implementado a parte dos gráficos que o Dashboard utilizará para mostrar estatísticas pertinentes. Após algumas buscas, decidiu-se usar o Chart.js como ferramenta de visualização dessas estatísticas, devido às fácil utilização e ótima funcionalidade, além de ter uma boa documentação disponível na sua página na Web de referência. Funciona parecido com vários outras APIs em JavaScript, ela trata com os dados em um formato similar à um JSON para exibir gráficos em barra, pizza, linear, radar, polar e de bolha. Na figura 25, pode-se perceber uma rápida implementação do Chart.js no Dashboard.

Figura 25 - Captura de tela da parte estatística do Dashboad, ainda em versão inicial. À esquerda, em pizza, porcentagem das principais ocorrências em uma AISP em um dia. à direita, o desenvolvimento da porcentagem das ruas patrulhadas durante uma semana

em uma AISP. 3. 1. 2. Análises geoespaciais

Para dar suporte ao desenvolvimento de dados relevantes a serem exibidos no Dashboard, foram desenvolvidas consultas no banco de dados com suporte geoespacial PostGIS [16], que é uma extensão do SGBD relacional PostgreSQL. Abaixo são listados e descritos as consultas e resultados feitos até então.

O foco das análises se fez nas feições de trajetórias e ocorrências, contrapondo-os em outras geometrias da própria cidade. Uma trajetória, por definição [9], se constitui como uma tupla de pontos e tempos, os quais se referem à amostragem de uma posição no tempo de um corpo específico. Uma ocorrência, por fim, trata-se de um evento relacionado à um crime ou problemática própria dos cidadãos com posição espacial e temporal.

Primeiro, se fez a importação dos dados para o banco. As trajetórias das viaturas e ocorrências policiais, em formato CSV, foram importadas para o banco de maneira comum, com um CREATE TABLE e um COPY, no entanto, houve de se fazer a adaptação das latitudes e longitudes para o tipo geometria, no caso dos tipos Point e Linestring. Para os dados de logradouros, os dados foram importados com o plugin PostGIS Shapefile and DBF loader. Ainda, os dados das AISPs tiveram de ser pré-processados para obter as latitudes e longitudes dos polígonos, que estavam em formato KML, esse pré-processamento consiste simplesmente

em retirar do KML essas coordenadas e convertê-las para o formato adequado à importação no PostgreSQL, com os dados de latitude e longitude que estavam nesse formato.

Definidas as granularidades espaciais (AISPs, poligonos e logradouros, linhas), e as feições espaciais (ocorrências, pontos e trajetórias, linhas), as granularidades temporais dos sets de dados, no entanto, precisam ser definidos previamente para mostrar os resultados. Assim foram utilizados 2 semanas de dados de trajetórias, e um grande set de dados de ocorrências de cerca de 10 anos. Ainda, para facilitar as descrições, a granularidade temporal default das análises é de 1 dia, as distâncias são medidas todas em metros, ou quando não, são especificadas na sua descrição.

Para começar, pode se consultar o grau de dispersão das ocorrências policiais entre si, calculando a distância média (em metros) entre as ocorrências por AISP.

Figura 26 - As 5 AISPs com menores distâncias médias entre as ocorrências

A segunda consulta se refere à porcentagem absoluta de ruas com ocorrência por AISP. Em um dia, por exemplo 0.72% das ruas da AISP 15 tiveram ocorrências.

Figura 27 - As 5 AISPs com maiores porcentagens de ruas com ocorrências

A terceira consulta é mais interessante e funciona como um teste de cobertura para as viaturas patrulhadas. A consulta retorna a porcentagem absoluta de ruas patrulhadas por AISP.

(a) (b)

Figura 28. (a) Cobertura de patrulha de 1 dia em porcentagem absoluta e (b) Efeito visual da cobertura no mesmo dia.

A próxima consulta conta as ocorrências em termos de AISPs. À esquerda, mostra-se a porcentagem bruta de ocorrências por AISP, com as 5 mais expressivas. À direita, mostra-se o índice de ocorrências por km² como uma métrica de contraste com a primeira. Poderia ser feito da mesma maneira trocando a granularidade de AISP por bairros, seria uma visualização ainda melhor para os cidadãos se este fosse o caso.

(a) (b)

Figura 29 .(a) Parcela em porcentagem de ocorrências na AISP do total e (b) Métrica de ocorrências por km² na AISP.

Então, para utilizar a granularidade de bairros e logradouros, a próxima consulta conta quantas ocorrências aconteceram e exibe, também, quantas trajetórias de viaturas por ali passaram. Essa consulta trata-se de um join entre duas outras, as quais calculam a primeira e a segunda

coluna separadamente. No caso da AISP que engloba o bairro de Ponta Negra, por exemplo, durante uma semana de análise, pode-se notar o seguinte:

Figura 30 - Ocorrências incidentes e viaturas que por ali passaram, por rua e bairro.

Assim, para analisar um pouco mais das trajetórias, tentou-se capturar o comprimento das trajetórias, tarefa difícil pelo fato de o intervalo de tempo da amostragem dos pontos que as compõem é variável e, com isso, apresenta-se o perigo de essas trajetórias possuírem distorção considerável em seus comprimentos. Para tentar resolver esse e outros problemas, fez-se uma consulta para partição da trajetória em subtrajetórias, e com isso, diminuir o erro de quando uma amostragem demora muito em relação à anterior. Essa partição constituiu-se em uma indexação das trajetórias de acordo com o intervalo entre a próxima amostragem, se esta passar de um valor de tempo definido, define-se uma nova subtrajetória, no caso, utilizou-se um valor de 5 minutos para a partição. Feito a partição das trajetórias, a abordagem ordinária de análise do comprimento das trajetórias foi utilizada, medindo o comprimento da geometria das linhas. Para desvalidar os absurdos, ainda pode-se mostrar a velocidade média daquela subtrajetória. O exemplo abaixo mostra a consulta ordenada pela velocidade média, a qual comparada com o intervalo em que aquela subtrajetória aconteceu, pode-se ter uma estimativa da veracidade da informação. No exemplo, o resultado de número 1 com certeza pode ser eliminado da análise.

Figura 31 - Comprimento e velocidade das subtrajetórias das viaturas. A coluna

intervalo se refere ao tempo de atividade daquela subtrajetória.

Continuando na análise das trajetórias, pode-se ainda estudar o grau de dissimiralidade entre as trajetórias e assim conhecer o quão destoante elas são entre si. Uma métrica já implementada no PostGIS é a da distância de Hausdorff [21], que trabalha com pares de geometrias do tipo ponto (ou conjunto deles). Essa métrica calcula a maior distância de um ponto de uma trajetória até o ponto mais próximo da outra trajetória. É melhor definida por :

em que Sua implementação no PostGIS é bastante trivial, pois já está implementada na biblioteca padrão. O resultado para nosso set de dados de trajetórias em um dia possui 210 linhas, comparando trajetória com trajetória para obter um grau de dissimilaridade anteriormente definido.

Figura 32 - Maiores valores de dissimilaridade entre trajetórias.

Para os futuros trabalhos referentes ao Dashboard, o principal foco será torná-lo 100% dinâmico, totalmente integrado ao banco de dados para que o usuário possa decidir o que quer visualizar na seção dos gráficos, e decidir a granularidade de tempo das camadas temáticas na seção dos mapas. Ainda, outras análises poderão ser trazidas, como análise em clusters de ocorrências policiais e trajetórias das viaturas, trazendo informações relevantes visando a melhoria no patrulhamento de uma cidade inteligente e humana. Por fim, espera-se começar a trabalhar com o módulo de predição de ocorrências no Dashboard, em que poderá trabalhar com patrulhamento preditivo através da plataforma, fazendo com que ela tenha uma importância muito maior para o usuário final, que é a segurança pública da cidade.

3.2 Rota Viatura O ROTA-Viatura é um projeto de aplicação móvel para a plataforma Android. O objetivo principal é melhor atender às necessidades do policial em serviço, facilitando e agilizando a realização de suas tarefas, viabilizando assim a melhoria do atendimento policial na cidade. O aplicativo foi desenvolvido especialmente para os tablets que serão usados nas viaturas, com toda a sua interface adaptada para a melhor experiência e usabilidade do policial. Houve muitos avanços no desenvolvimento em comparação à versão apresentada no primeiro trimestre de 2016. Através de testes de usabilidades com policias foi possível identificar alguns pontos a serem melhorados e incrementados na aplicação. As novas implementações foram tanto no visual (front-end) quanto na parte interna do sistema (back-end). No front-end houve uma total reformulação do visual, adicionando uma nova paleta de cores para toda a aplicação visando o melhor uso e leitura das informações durante o dia ou em ambientes com muita luminosidade. Mensagens e notificações ao usuário também foram alteradas, uma vez que o a aplicação retornava, em alguns casos, mensagens que não condiziam com a situação simulada, por exemplo, mensagens de erro no login. Já no back-end a maior parte das mudanças ocorreram no melhoramento da comunicação em tempo real com os servidores da Polícia e no melhor gerenciamento do GPS e bateria do tablet. Nas sessões seguintes todas essas implementações e melhorias são abordadas com mais detalhes. 3. 2. 1. Novas Implementações

Durante o segundo trimestre do ano 2016 foram realizados os primeiros testes de usabilidade do aplicativo com alguns policiais e foi constatado alguns problemas tanto na parte visual quanto no próprio sistema. O principal problema visual do aplicativo era que as telas não estavam otimizadas para a visualização em um ambiente onde tenha muita incidência do Sol ou com muita luminosidade. A detecção desse problema foi durante um teste dentro da viatura durante o dia, o tablet foi colocado em um suporte específico que fica grudado na tela, porém a tela dele fica exposta ao Sol e todo o layout do aplicativo, até então, era em um tom escuro. Os policiais mal conseguiam ver o aplicativo e suas notificações, inviabilizando o uso do mesmo em operações reais nessas condições de ambiente. Para resolver esse problema foi desenvolvido um layout para o dia com uma paleta de cores Claras para o fundo e cores que destaquem mais as letras, painéis de notificações e botões. O aplicativo faz a troca de layouts automaticamente de acordo com o horário do dia. A partir das 6h da manhã fica ativo o design claro e após as 18h o layout volta para o design escuro. Outras questões foram levantadas a partir disso pelos próprios policiais, pensando em situações de operações reais, a viatura pode estar em um ambiente escuro durante o dia, por exemplo dentro de um túnel ou em uma garagem, nesse caso o layout claro poderia atrapalhar, pois a luz da tela clara diretamente voltada para os policiais poderia diminuir o campo de visão dos mesmos. Com isso, foi desenvolvido um modo manual da troca de layouts onde basta apenas ir no menu principal, acessar a opção de configurações e selecionar o tipo de tela manualmente.

Figura 33 - Telas de login com os layouts claro e escuro, respectivamente.

Figura 34 - Telas de Status com os layouts claro e escuro, respectivamente. Após o

cadastramento da viatura, a tela de status faz a comunicação em tempo real com os servidores da polícia para verificar se há alguma ocorrência atribuída para a viatura.

Figura 35 - Telas de Status com ocorrência atribuída à viatura

Figura 36 - Telas de Atendimento da Ocorrência com os layouts claro e escuro,

respectivamente.

Figura 37 - Telas do Menu Principal com os layouts claro e escuro, respectivamente.

Figura 38 - Telas da Busca de Identificação Civil com os layouts claro e escuro,

respectivamente.

Figura 39 - Telas dos resultados da Busca de Identificação Civil com os layouts claro e

escuro, respectivamente.

Figura 40 - Telas dos resultados da Busca de Identificação Civil e a listagem das

informações do cidadão selecionado com os layouts claro e escuro, respectivamente.

Figura 41 - Telas da Busca de Placas com os layouts claro e escuro, respectivamente.

Figura 42 - Telas da Busca de Placas com um exemplo de aviso nos layouts claro e

escuro, respectivamente.

Figura 43 - Telas da Busca de Placas com o resultado da busca nos layouts claro e escuro,

respectivamente.

Figura 44 - Telas Configurações nos layouts claro e escuro, respectivamente.

Figura 45 - Telas de Cadastro de Sugestões nos layouts claro e escuro, respectivamente.

Figura 46 - Telas de Informações do Usuário nos layouts claro e escuro, respectivamente. Outra sugestão dos policiais durante esse teste foi a adição de um sinal sonoro de alerta para avisar quando uma notificação chegasse no aplicativo. Os mesmos relataram que apenas usando uma tela de notificações poderia ter a chance de passar despercebida a ocorrência e como consequência o atendimento tardio da mesma. Com isso, foi adicionado um som de alerta, parecido com um toque de celular, para alertar os policiais da viatura. Esse sinal sonoro é ativado independente da tela que está ativa no aplicativo, tornando mais ágil o atendimento da ocorrência. Os últimos problemas relatados quanto ao visual foram referentes aos avisos que o aplicativo retornava para o usuário. Por exemplo, quando o policial acessava a opção de busca de placas, mas estava sem conexão com a internet, a mensagem que o aplicativo mostrava era: "Placa não encontrada". Esse tipo de aviso pode ser perigoso durante uma operação dos policiais na rua, pois podem imaginar que a pessoa está usando uma placa falsa. Outros problemas com mensagens erradas foram encontrados em outras telas, a maioria era com um problema parecido com o da busca de placas, pela a falta de conexão, mostrava a mensagem errada. Já na parte do backend do aplicativo também foram requisitadas algumas mudanças. Uma delas foi a necessidade da ativação do GPS antes que o policial entrasse na aplicação. Pois praticamente toda comunicação que o aplicativo faz com o servidor são enviados como parâmetros a latitude e longitude, mas quando o GPS não estava ativado nas próprias configurações do tablet, os valores eram zero para a latitude e longitude, impossibilitando a localização da viatura. Através de alguns testes foi notado que o tablet desabilita o GPS caso a bateria acabe, após recarregar e ligar o tablet novamente, o GPS continua desabilitado. Sendo assim, foi de muita importância implementar a obrigatoriedade do GPS antes de entrar na conta.

Figura 47 - Simulação do usuário tentando fazer o login com o GPS desabilitado no

tablet. Alguns testes também foram realizados na Coordenadoria de Tecnologia da Informação (CTINF), onde foi possível ter o acesso completo no servidor da polícia que faz a comunicação direta com o aplicativo. A oportunidade de ver de perto como estavam se comportando todas as requisições do aplicativo mostrou alguns outros problemas, que não dariam para resolver sem esse acesso ao servidor. O maior desses problemas era em relação à comunicação em tempo real que o aplicativo faz para consultar as ocorrências ativas para a viatura. Foi constatado que a aplicação estava fazendo requisição mesmo após o policial finalizar o serviço da viatura. Houveram também casos em que o aplicativo estava fazendo conexões em tempo bem menores que o pré-estabelecido, de dez segundos, podendo gerar um overhead de consultas no servidor. Todos esses problemas de conexão em tempo real foram resolvidos utilizando a classe Handler [34] que o próprio Android disponibiliza. Após a resolução desse problema testes foram feitos, buscando explorar os mais diversos casos, e todos foram satisfeitos com sucesso. Durante o período de treinamento dos policiais despachantes (descrito na sessão "Implantação nas primeiras viaturas") foram encontradas algumas limitações que o policial na viatura

poderia encontrar, basicamente as requisições feitas durante esse período foram: A implementação de um boletim da ocorrência no ato da finalização da mesma, a implementação da funcionalidade de cancelar a ocorrência e o envio do status da bateria afim de evitar o desligamento do tablet. A implementação do boletim da ocorrência foi de muita importância, pois sem isso o policial poderia finalizar a ocorrência pelo aplicativo sem registrar como foi concluída a mesma. O desenvolvimento dessa nova funcionalidade foi simples, adicionando apenas dois parâmetros no serviço de finalização: o código da finalização do serviço e uma mensagem que poderá ser escrita com as próprias palavras do policial. O outro serviço, de envio do status da bateria, se fez também muito importante, pois como já citado, o GPS é desabilitado pelo tablet caso a bateria acabe e isso pode acarretar em alguns problemas. O tablet é de uso exclusivo para fins de trabalho na viatura, com isso, foi instalado um launcher que bloqueia todas as atividades que não sejam relacionadas ao trabalho dos policiais, sendo assim, o acesso às configurações do tablet também foi bloqueado. Nessa situação, se o policial ligar o tablet e o mesmo estiver com o GPS desabilitado, ele não poderá ativá-lo, pois não tem acesso às configurações, e também não poderá entrar na aplicação do ROTA, pois a mesma exige a conexão ativa com o GPS. Para isso, foi implementado o serviço que envia o status da bateria periodicamente. Agora com essa funcionalidade, a central pode ter acesso ao status da bateria, sabendo se o tablet está ligado ou não a alguma fonte de energia e também o nível, em porcentagem, da bateria. Com isso, os policiais despachantes, responsáveis pelo gerenciamento das informações do aplicativo, poderiam entrar em contato com a viatura, via rádio, e requisitar que o tablet fosse ligado imediatamente a uma fonte de energia. 3. 2. 2. Primeira Implantação em Ambiente de Produção

As últimas avaliações do aplicativo em ambiente de testes foram realizadas no dia 22 de julho de 2016, em uma sexta-feira. Logo em seguida, no dia 25 de julho de 2016, segunda-feira, deram-se início aos treinamentos dos policiais despachantes com a aplicação já se comunicando com o servidor de produção da Polícia Militar.

O treinamento inicial com esses policiais é de muita importância, uma vez que eles são os responsáveis pelo gerenciamento do sistema que se comunica com o ROTA. Ao todo foram 42 policiais que receberam esse treinamento, e segundo relatos do Major Constantino

Emiliano Loiola, todos os testes de comunicação com o aplicativo através do sistema de despacho de ocorrências obtiveram sucesso. A partir do dia 1º de agosto de 2016 serão iniciados os treinamentos com os policiais das viaturas, que serão os usuários finais do aplicativo. Esse treinamento será realizado apenas em uma AISP (Áreas Integradas de Segurança Pública), afim de implementar e testar o desempenho do ROTA antes da implantação em todas as viaturas. 3. 2. 3. Funcionalidades para a próxima versão Por se tratar de um aplicativo inovador no atendimento e despacho de ocorrências e afim de torná-lo uma referência para operações policiais no Brasil, muitas outras funcionalidades são desejadas para a próxima versão. As principais são: O desenvolvimento de um "Cartão-Programa" para a listagem e acompanhamento de locais obrigatórios que a viatura deve passar na cidade e também uma opção para a atualização automática do aplicativo quando forem geradas novas atualizações.

4 Aplicação Fala Natal

Fala Natal será o aplicativo oficial da Prefeitura Municipal de Natal, em parceria com a Ouvidoria Geral do Município e as Secretarias Municipais, com o objetivo de facilitar a comunicação entre a população e a prefeitura durante a solicitação de demandas. O aplicativo possibilita ao cidadão uma nova alternativa, além das já existentes -- disponível na Web através do endereço http://www.natal.rn.gov.br/siigpmn/ouvidoria/, no telefone (84) 3232-6389 e no e-mail [email protected], mais simples de enviar demandas para a prefeitura. Através dele, o cidadão pode enviar denúncias, solicitação de serviços, elogios e sugestões.

No segundo trimestre do projeto foram desenvolvidas as funcionalidades de cadastrar usuário, cadastrar nova demanda, cadastrar novo elogio, cadastrar nova sugestão e listar e exibir todas as demandas cadastradas pelo usuário. Na funcionalidade de cadastrar nova demanda ainda serão feitos alguns ajustes como captura da localização do usuário, de forma que ele não tenha sempre que preencher os dados de localização da demanda manualmente. Também foram desenvolvidas as telas do aplicativo. Além disso, o grupo está discutindo a categorização das possíveis demandas que podem ser levantadas pelos cidadãos. Isso é necessário uma vez que atualmente o cidadão deve ter o pleno conhecimento sobre que secretaria municipal deve atender a sua demanda. Entretanto, é notoriamente sabido que, de um modo geral, o cidadão não conhece todas as secretarias e quais as responsabilidades de cada uma. Assim, com a categorização que está sendo realizada, o cidadão apenas selecionará a sua demanda, cabendo ao sistema decidir para qual secretaria cada demanda será enviada.

Como entraves atuais, o projeto está evoluindo de forma mais lenta que o planejado, pois o desenvolvimento está ligado diretamente ao desempenho da Secretaria Municipal de Planejamento (SEMPLA). A SEMPLA é a responsável pelo sistema Web que detém todos os cadastrados pelo aplicativo, uma ferramenta tão importante quanto o aplicativo.

http://www.natal.rn.gov.br/siigpmn/ouvidoria/

http://www.natal.rn.gov.br/siigpmn/ouvidoria/

4.1 Arquitetura A arquitetura proposta foi definida depois de se observar diversas cidades com

iniciativas parecidas, como Boston, Washington DC e Chicago. Todas elas possuem um aplicativo para celular que facilita ao cidadão a solicitação de serviços não emergências para o governo local. Essas cidades utilizam Open311, que é uma especificação para plataformas abertas [18], um modelo colaborativo e padrão aberto para acompanhamento de problemas civis não emergenciais [19].

Seguindo o modelo dessas cidades, teremos os aplicativos, tanto para a plataforma Android quando para iOS, disponíveis para os cidadãos. Os aplicativos farão chamadas a um Webservice que estará integrado ao banco de dados da ouvidoria, como mostra a Figura 4.1. O Webservice seguirá os padrões de requisição de serviço especificados pela plataforma Open311, possibilitando assim que outros aplicativos que seguem o mesmo padrão possam solicitar serviços a prefeitura sem modificação em seu código fonte.

Figura 4.1. Arquitetura do Fala Natal

O Webservice será desenvolvido seguindo o padrão Open311 e serão adicionados alguns serviços para atender as especificidades da prefeitura do Natal, que são o envio de denúncia, sugestão e elogio. O Webservice fará a integração dos dados entre os aplicativos e a

prefeitura, para isso será necessário o acesso ao banco de dados da ouvidoria, de modo que o sistema atual usado pela Ouvidoria Municipal de Natal seja compatível com os dados gerados pelos aplicativos, facilitando o trabalho do servidor público.

4.2 Especificações de Casos de Uso No Fala Natal existem os seguintes casos de uso:

● Cadastro via Facebook e Google +, além do cadastro de forma padrão. ● Registro de uma nova solicitação. ● Registro de uma sugestão. ● Registro de uma denúncia. ● Registro de um elogio. ● Listagem das demandas cadastradas pelo usuário. ● Acompanhamento de uma solicitação específica através da tela de consultar demanda. ● Listagem das demandas mais recentes cadastradas pelos usuários do Fala Natal. ● Acesso a tela de perfil do usuário. ● Acesso a tela de informações sobre o aplicativo.

4.2.1 Cadastro de Usuário

Caso de Uso: Cadastro de Usuário

Responsável: Equipe Fala Natal

Descrição Geral: No caso de uso o usuário poderá se cadastrar para usar o aplicativo com mais praticidade.

Atores: Usuário


Pós-Condição: O aplicativo encaminhará os dados do usuário para o sistema Web que guardará seus dados como um novo usuário.

Fluxo Típico

No Ação

1 O usuário clica no campo “Faça seu cadastro” e é direcionado para o formulário de cadastro.

2 O usuário preenche os dados de cadastro e clica em “Cadastrar”.

3 O aplicativo redireciona o usuário para a tela principal do aplicativo.

Fluxo Alternativos

Alternativa 1: Cadastro via Facebook

No Ação

1 O usuário clica no botão de “Entrar com Facebook” e um pop up do Facebook aparece para que o usuário entre com suas credenciais.

2 O aplicativo coletará os dados que estão disponíveis ao acesso de terceiros, como nome do usuário, e-mail e data de nascimento e redireciona para a tela de formulário de cadastro.

3 O aplicativo exibe a tela de formulário de cadastro com alguns dados preenchidos de acordo com as permissões de acesso do Facebook, o usuário preenche os dados restantes e clica em “Cadastrar”.

Fluxo Alternativos

Alternativa 1: Cadastro via Google +

No Ação

1 O usuário clica no botão de “Fazer login” e um pop up do Google aparece para que o usuário entre com suas conta já cadastrada no aparelho.

2 O aplicativo coletará os dados que estão disponíveis ao acesso de terceiros, como nome do usuário, e-mail e data de nascimento e redireciona para a tela de formulário de cadastro.

3 O aplicativo exibe a tela de formulário de cadastro com alguns dados preenchidos de acordo com as permissões de acesso do Google, o usuário preenche os dados restantes e clica em “Cadastrar”.

Fluxo de Exceção

Exceção 1: Acesso direto sem cadastro

No Ação

1 O usuário clica em “Pular essa etapa”.

2 O usuário é direcionado para a tela principal do aplicativo. Interface do Usuário

Figura 4.2.1.1 Tela inicial Figura 4.2.1.2. e 4.2.1.3 Tela de cadastro de usuário

4.2.2 Registro de uma nova solicitação

Caso de Uso: Registro de uma nova solicitação


Descrição Geral: No caso de uso o usuário poderá registrar uma nova solicitação de serviço.

Atores: Usuário


Pós-Condição: O aplicativo encaminhará os dados da solicitação cadastrada para o sistema Web.

Fluxo Típico

No Ação

1 Na tela principal do aplicativo, o usuário clica no botão “Registre sua demanda” e é redirecionado para a tela com as opções de demanda.

2 O usuário clica em “Solicitação/Reclamação” e é redirecionado para a tela das categorias de solicitações.

3 O usuário escolhe uma das categorias, clica na mesma e é redirecionado para a tela de tipos de solicitações para a categoria selecionada.

4 O usuário escolhe um tipo de solicitação, clica na mesma e é redirecionado para a tela de cadastro da nova solicitação daquele tipo.

5 O usuário preenche os campos disponíveis, optando ou não por enviar uma foto capturada na hora ou salva na galeria e optando ou não por mandar uma solicitação anônima, clica em “Enviar” e recebe uma mensagem do sistema mostrando o status da operação, se foi bem-sucedida ou não, em seguida é redirecionado para a tela principal do aplicativo.

Fluxo Alternativos

Alternativa 1: Usuário não cadastrado

No Ação


2 O usuário clica em “Solicitação/Reclamação” e é redirecionado para a tela das categorias de solicitações.

3 O usuário escolhe uma das categorias, clica na mesma e é redirecionado para a tela de tipos de solicitações para a categoria selecionada.

4 O usuário escolhe um tipo de solicitação, clica na mesma e é redirecionado para a tela de cadastro da nova solicitação daquele tipo.

5 Além dos campos padrão para serem preenchidos, a tela de

cadastro da nova solicitação mostrará os campos de cadastro de usuário, uma vez que o mesmo não está cadastrado no sistema ainda. O usuário preenche os campos disponíveis, optando ou não por enviar uma foto capturada na hora ou salva na galeria e optando ou não por mandar uma solicitação anônima, clica em “Enviar” e recebe uma mensagem do sistema mostrando o status da operação, se foi bem-sucedida ou não, em seguida é redirecionado para a tela principal do aplicativo.


Figura 4.2.2.1 Tela principal Figura 4.2.2.2 Opções de demanda

Figura 4.2.2.3 Categorias de serviços Figura 4.7. Lista de serviços

Figura 4.8. Tela do formulário de cadastro da nova solicitação para o usuário cadastrado

Figura 4.8. Tela do formulário de cadastro da nova solicitação para o usuário não cadastrado

4.2.3 Registro de uma nova sugestão

Caso de Uso: Registro de uma nova sugestão


Descrição Geral: No caso de uso o usuário poderá registrar uma nova sugestão.

Atores: Usuário


Pós-Condição: O aplicativo encaminhará os dados da sugestão cadastrada para o sistema Web.

Fluxo Típico

No Ação


2 O usuário clica em “Sugestão” e é redirecionado para a tela de cadastro da nova sugestão.

3 O usuário preenche o formulário da nova sugestão e clica no botão “Enviar” e é redirecionado para a tela principal do aplicativo.


Figura 4.2.3.1. Tela principal Figura 4.2.3.2 Opções de demanda

Figura 4.2.3.3 Tela de nova sugestão

4.2.4 Registro de uma nova denúncia

Caso de Uso: Registro de uma nova denúncia


Descrição Geral: No caso de uso o usuário poderá registrar uma nova denúncia.

Atores: Usuário


Pós-Condição: O aplicativo encaminhará os dados da denúncia cadastrada para o sistema Web.

Fluxo Típico

No Ação


2 O usuário clica em “Denúncia” e é redirecionado para a tela de cadastro da nova denúncia.

3 O usuário preenche o formulário da nova denúncia e clica no botão “Enviar” e é redirecionado para a tela principal do aplicativo.



Figura 4.2.4.3 Tela de nova denúncia

4.2.5 Registro de um novo elogio

Caso de Uso: Registro de um novo elogio


Descrição Geral: No caso de uso o usuário poderá registrar uma nova denúncia.

Atores: Usuário


Pós-Condição: O aplicativo encaminhará os dados da denúncia cadastrada para o sistema Web da Sempla.

Fluxo Típico

No Ação


2 O usuário clica em “Denúncia” e é redirecionado para a tela de cadastro da nova denúncia.

3 O usuário preenche o formulário da nova denúncia e clica no botão “Enviar” e é redirecionado para a tela principal do aplicativo.



Figura 4.2.5.3 Tela de novo elogio

4.2.6 Listagem das demandas cadastradas pelo usuário

Caso de Uso: Listagem das demandas cadastradas pelo usuário


Descrição Geral: No caso de uso o usuário poderá listar todas as demandas cadastradas por ele.

Atores: Usuário

Pré-Condição: Ter o aplicativo instalado no celular e ter cadastrado ao menos uma demanda.

Pós-Condição: O aplicativo fará uma requisição ao sistema Web que retornará todas as demandas cadastradas pelo usuário.

Fluxo Típico

No Ação

1 Na tela principal do aplicativo, o usuário clica no botão de menu lateral posicionado no lado esquerdo superior da tela principal.

2 O usuário clica em “Minhas demandas” e é direcionado para a tela com a lista de demandas cadastradas.


Figura 4.2.6.1. Tela principal Figura 4.2.6.2 Menu lateral Figura 4.2.6.3 Lista de demandas

4.2.7 Acompanhamento de uma solicitação específica através da tela de consultar demanda

Caso de Uso: Acompanhamento de uma solicitação específica através da tela de consultar demanda


Descrição Geral: No caso de uso o usuário poderá acessar os detalhes de uma demanda através de um número de demanda.

Atores: Usuário

Pré-Condição: Ter o aplicativo instalado no celular e ter um número de demanda.

Pós-Condição: O aplicativo fará uma requisição ao sistema Web utilizando o número de demanda como argumento, recebendo como retorno um objeto de demanda para ser exposto.

Fluxo Típico

No Ação

1 Na tela principal do aplicativo, o usuário clica no botão “Consulte a sua demanda” e é direcionado para a tela de consulta de demanda.

2 O usuário entra com o número de demanda no campo indicado e clica no botão “Consultar”.


Figura 4.2.7.1. Tela principal Figura 4.2.7.2 Consulta de demanda

Figura 4.2.7.3 Tela de demanda

4.2.8 Listagem das demandas mais recentes cadastradas pelos usuários

Caso de Uso: Listagem das demandas mais recentes cadastradas pelos usuários.


Descrição Geral: No caso de uso o usuário poderá acessar uma lista das demandas mais recentes cadastradas pelos usuários do Fala Natal.

Atores: Usuário


Pós-Condição: O aplicativo fará uma requisição ao sistema Web e receberá uma lista das demandas mais recentes em ordem de mais recente para mais antiga.

Fluxo Típico

No Ação


2 O usuário clica em “Recentes” e é direcionado para a tela com a lista de demandas recentes em ordem de mais recentes para mais antigas.


Figura 4.2.8.1. Tela principal Figura 4.2.8.2 Menu lateral

Figura 4.2.8.3 Tela de demandas recentes

4.2.9 Acesso a tela de perfil do usuário

Caso de Uso: Acesso a tela de perfil do usuário


Descrição Geral: No caso de uso o usuário poderá acessar sua tela de perfil do usuário.

Atores: Usuário

Pré-Condição: Ter o aplicativo instalado no celular e estar cadastrado no aplicativo.

Pós-Condição: O aplicativo fará uma requisição ao sistema Web e receberá os dados do usuário para exibir na tela de perfil.

Fluxo Típico

No Ação


2 O usuário clica em “Perfil” e é direcionado para a tela de perfil do usuário.



Figura 4.2.9.3 Tela de perfil ● Acesso a tela de informações sobre o aplicativo

4.2.10 Acesso a tela de informações sobre o aplicativo

Caso de Uso: Acesso a tela de informações sobre o aplicativo


Descrição Geral: No caso de uso o usuário poderá acessar a tela de informações sobre o aplicativo.

Atores: Usuário


Pós-Condição: O aplicativo direcionará para a tela de informações sobre o aplicativo.

Fluxo Típico

No Ação


2 O usuário clica em “Sobre” e é direcionado para a tela de informações sobre o aplicativo.



Figura 4.2.10.3 Tela sobre o aplicativo

5 Aplicação Smart Place

Como mencionado no relatório anterior deste projeto (RT1-WP2), a aplicação Smart Place (anteriormente denominada de Smart Lab), tem como objetivo realizar, de forma automática, o gerenciamento de recursos, tais como aparelhos de ar condicionado, lâmpadas e computadores, em determinados locais da universidade, contribuindo, assim, para economia de energia, além de proporcionar mais conforto e praticidade a seus usuários. Como definido no relatório anterior, a aplicação deve realizar as seguintes tarefas:

(i) controle (ligar e desligar) dos aparelhos de ar-condicionado, (ii) controle das lâmpadas (ligar e desligar), (iii) gerenciamento dos recursos computacionais (configuração dos computadores

disponíveis, softwares instalados), e (iv) registro de presença dos alunos em sala de aula. Para a realização desta última tarefa, a aplicação Smart Place deve comunicar-se com

outros sistemas existentes na universidade, que são: ● o sistema de gerenciamento de reserva de salas (Keys), para recuperar informações

sobre os horários de aulas e agendamentos de salas; e, ● o sistema acadêmico (Sigaa), para recuperar e registrar informações sobre as aulas

frequentadas pelos alunos. Neste relatório, são descritas as atividades realizadas durante os meses de maio a julho

de 2016, a fim de atender parte dos requisitos relacionados ao gerenciamento automático dos aparelhos de ar-condicionado das salas. Os demais requisitos serão implementados e descritos em futuros relatórios.

Um dos principais objetivos do controle automático dos aparelhos de ar-condicionado é poupar energia. Assim sendo, os aparelhos deverão ser acionados somente quando houver pelo menos uma pessoa na sala e, desligados, caso contrário. A temperatura da sala deve ser mantida conforme as preferências do professor que ministra a aula. Caso não exista nenhuma preferência de temperatura registrada para a pessoa responsável pela sala, a temperatura deve ser mantida ao valor padrão de 24 ºC.

Para manter esse controle, duas verificações serão feitas: 1. a presença de pelo menos uma pessoa na sala, e 2. a variação de temperatura e umidade conforme o número de pessoas presentes na

sala/laboratório.

Para isso, serão utilizados/instalados, inicialmente, dois sensores na sala/laboratório: o sensor de temperatura e umidade (DHT11 Sensor) [29], e o sensor de presença (PIR sensor - Passive Infrared Sensor) [30]. Esses sensores serão responsáveis por verificar esses dados (temperatura, umidade e presença) na sala, a fim de que, com base neles, seja realizado o controle dos aparelhos de ar-condicionado.

Para atender aos requisitos da aplicação, foi desenvolvido um sistema Web para registro e consulta das informações referentes aos sensores, medições e os locais onde os mesmos estão instalados. Além de fornecer uma interface Web, o sistema oferece uma API REST a ser utilizada pelos provedores de informações para envio das medições aferidas pelos sensores. Também foi realizada a montagem e configuração do hardware responsável por aferir as medidas de temperatura, umidade e presença, além de enviar essas informações a API REST do sistema Web.

Nas próximas seções serão apresentados o desenvolvimento do sistema Web (seção 5.1), abordando detalhes relacionados à sua arquitetura, implementação e tecnologias utilizadas. A seção 5.2 aborda detalhes relacionados a montagem e configuração do hardware, que apresentará o hardware utilizado e as configurações necessárias para a aferição dos dados.

5.1 Desenvolvimento do Sistema WEB O sistema Web foi desenvolvido utilizando a linguagem de programação Java, fazendo

uso também do framework JSF (Java Server Faces) versão 2.2. O Web contêiner escolhido para realização do deploy da aplicação foi o Apache TomCat versão 8.0 [14]. O SGBD (Sistema Gerenciador de Banco de Dados) utilizado para persistência dos dados foi o PostgreSQL [25]. Para facilitar a persistência dos dados também foi utilizado o framework Hibernate [26], que oferece um conjunto facilidades para mapeamento de classes Java para tabelas de bancos de dados relacionais, além de facilitar a persistência e recuperação dos objetos instanciados a partir dessas classes.

5.1.1 Estrutura e Implementação do Sistema Web

A aplicação foi estruturada seguindo o padrão MVC (Model View Controller) [27], conforme mostra a figura 5.1. Nessa figura, parte das classes forma suprimidas para facilitar a visualização das camadas. Na arquitetura MVC, as camadas superiores utilizam os serviços oferecidos pelas camadas subjacentes. A camada mais inferior é composta pelas classes responsáveis por persistir os dados no banco de dados. A persistência é realizada com o auxílio do framework Hibernate e utilizando o padrão de projeto DAO (Data Access Object)

[28], que tem por objetivo abstrair e encapsular os mecanismos de acesso a dados, escondendo os detalhes da execução da origem dos mesmos.

Figura 5.1. Estrutura do sistema Web

Na camada intermediária (camada de Controller) estão as classes responsáveis por

encapsular toda a lógica de negócio da aplicação. Nessa camada são realizadas todas as validações dos dados antes que sejam persistidos no banco de dados, como por exemplo, verificação se os atributos dos objetos foram preenchidos corretamente, se não foram passados valores nulos, etc. Nessa camada são implementadas as regras que decidirão, por exemplo, quando acionar ou desligar um aparelho de ar-condicionado, com base nos atributos aferidos pelos sensores. Essa camada utiliza os serviços oferecidos pela camada inferior para persistência e recuperação dos dados.

Na camada superior estão as classes que interagem com as páginas Web, a fim de receber os dados informados pelos usuários e realizar as operações tais como: consultas de dados, remoção, alteração, etc. Nessa camada também estão localizadas as classes que implementam os métodos da API REST disponibilizada pelo sistema. Ambas as classes dessa camada reutilizam as operações disponibilizadas na camada de controller, uma vez que nessa camada está localizada toda a lógica de negócio da aplicação e a validação dos dados.

O Diagrama de sequência da Figura 5.2 ilustra a interação entre as classes das diversas camadas, desde o momento em que uma aferição de um sensor é recebida por uma classe da API REST, até o momento em que o dado é persistido pelas classes da camada de persistência dos dados.

Figura 5.2. Recebimento, validação e persistência de uma medição proveniente de

um Sensor

Conforme mostra o diagrama, os valores das medições enviadas pelos sensores são

recebidos pela classe MeasurementResource, que é responsável por receber os dados das medições enviadas através do protocolo HTTP (Hypertext Transfer Protocol) e repassar o valor das medições para a camada de controller, que realiza a validação dos dados antes de

solicitar à camada de persistência que os mesmos sejam gravados no banco de dados. Durante a validação dos dados de uma medição a classe MeasurementController irá verificar se todos os dados obrigatórios foram devidamente informados, e se o valor do identificador do sensor ao qual a medição pertence realmente existe no banco de dados. Após a validação, caso não seja identificada nenhuma inconsistência nos dados informados, a classe MeasurementResource solicita à classe MeasurementDao que realize a persistência dos dados da medição enviado pelo sensor.

Após todo esse processo uma resposta é retornada ao cliente informando se a requisição foi ou não realizada corretamente. Essa resposta utiliza os códigos definidos no próprio protocolo HTTP para informar os status da requisição. O código 200 (OK), por exemplo, indica que a requisição foi bem-sucedida, o código 500 (Internal Erro) indica que houve algum erro interno no servidor ao processar a requisição, o código 400 (Bad Request) indica que a requisição não foi feita corretamente pelo cliente, e desse modo não pôde ser intendida pelo servidor. A Figura 5.3 ilustra um trecho do código da classe MeasurementResource, que mostra como a resposta HTTP e os respectivos status code retornados ao cliente quando o mesmo realiza alguma requisição.

Figura 5.3. Método da classe MeasurementResource, responsável por receber os

valores das medições enviadas pelos sensores Conforme mostra a Figura 5.3, caso a requisição seja corretamente processada e os

valores da medição sejam devidamente salvos no banco de dados, uma resposta com código 200 (OK) será retornada ao cliente (linha 99). Caso seja identificado algum erro interno durante a persistência dos dados (linha 102), uma resposta com o código 500 (Internal Server Erro) será retornada ao cliente. Por fim, caso seja identificado algum erro durante a validação dos dados informados pelo usuário, uma resposta com código 400 (Bad Request) será retornada ao usuário.

A linha 81 do código ilustrado na Figura 5.3 também mostra que os valores das medições envidas pelos sensores podem ser representados no formato XML (eXtensible Markup Language) ou Json (JavaScript Object Notation). Além desses formatos, o usuário também tem a opção de enviar os dados de uma medição na própria query da requisição

HTTP. Nesse caso, os dados serão processados por um outro método da classe MeasurementResource.

De acordo com o protótipo (Figura 5.4) definido no relatório anterior, o gerente poderá, entre outras coisas, realizar o registro de todos os sensores existentes no prédio (opção Registros). O gerente também poderá realizar consultas acerca desses equipamentos e das medições registradas por eles (opção Lab).

Figura 5.4. Protótipo da tela do gerente do laboratório.

Para atender a esses requisitos, foram desenvolvidas algumas páginas Web em

XHTML (eXtensible Hypertext Markup Language). Para registrar ou consultar informações sobre os sensores é necessário que antes sejam registradas informações sobre os prédios e salas onde os mesmos estão localizados. Para isso, foram criadas páginas Web para registrar tais informações. No total, 4 páginas Web foram desenvolvidas. A primeira delas (Figura 5.5) permite registrar os prédios da universidade onde serão instalados os sensores. Essa página permite registar, listar, editar e deletar informações sobre um prédio da universidade. Para registrar um prédio deve ser informado obrigatoriamente o nome do prédio, e opcionalmente, as suas coordenadas geográficas (latitude e longitude).

Figura 5.5. Interface Web para registro/listagem/edição/remoção de informações

sobre os prédios onde serão instalados os sensores

A Figura 5.6 ilustra a interface Web desenvolvida para o registro, listagem, remoção e

edição de informações relacionadas às salas onde serão instalados os sensores. Para registrar informações sobre uma sala devem ser informados obrigatoriamente o nome da sala de aula e o prédio no qual a sala está localizada.

Figura 5.6. Interface Web para registro/listagem/edição/remoção de informações

sobre as salas onde serão instalados os sensores

A Figura 5.7 ilustra a interface Web desenvolvida para registro, listagem, edição e

remoção de informações relacionadas aos sensores instalados no prédio. Para registrar informações sobre um sensor é necessário que, obrigatoriamente, sejam informados o tipo do sensor (umidade, presença, temperatura ou outro), o prédio no qual o sensor está localizado. Ao selecionar um dos prédios previamente cadastrados, as salas existentes no prédio são listadas no combobox Sala, uma sala deve ser então selecionada. Opcionalmente, pode ser registrada alguma informação adicional sobre o sensor através do campo descrição.

Figura 5.7. Interface Web para registro/listagem/edição/remoção de informações sobre sensores

Por fim, a Figura 5.8 ilustra a interface Web desenvolvida para consultas acerca do

histórico das medições aferidas pelos sensores. Para consultar informações sobre as medições de um sensor é necessário primeiramente selecionar o prédio no qual o sensor está localizado. Ao selecionar um prédio, as salas existentes no prédio são listadas no combobox Sala e o usuário deve selecionar uma sala. Ao selecionar uma sala, os sensores existentes na sala são listados no combobox Sensor. Ao selecionar um dos sensores, as medições aferidas pelo sensor selecionado são então exibidas na tabela, que mostra o valor da medição além da data e hora na qual a medição foi aferida.

Figura 5.8. Interface Web para consultas acerca das medições aferidas pelos

sensores

Para o próximo relatório serão desenvolvidas outras interfaces para consulta às

informações aferidas pelos sensores. As novas interfaces permitirão realizar filtros que delimitem a data das aferições a serem listadas e que permitam também plotar gráficos que mostrem a variação das medições aferidas ao longo do tempo.

5.1.2 Modelo ER da aplicação

Como mencionado anteriormente, a aplicação Smart Place utiliza, para persistência de dados, o SGBD PostgreSQL, que trabalha com banco de dados relacionais. Nesse tipo de banco de dados as informações são organizadas através de tabelas e relacionamentos entre as mesmas. A Figura 5.9 ilustra o modelo ER (Entidade Relacionamento) do banco de dados construído para armazenamento das informações da aplicação Smart Place. É importante ressaltar que esse modelo foi desenvolvido para atender apenas parte dos requisitos da aplicação Smart Place, a medida em que novos requisitos forem implementados novas tabelas e relacionamentos serão incluídas a esse modelo.

Figura 5.9. Modelo ER do banco de dados da aplicação Smart Place

Como mostra a figura, foram criadas tabelas para representar as seguintes entidades:

1. usuário do sistema (tabela User), com os atributos login (chave primária, que identifica de forma única cada usuário), password, preference temperature e name;

2. sensores (tabela Sensor), com os atributos id (chave primária), sensor type, description, e as chaves estrangeiras: room_roomName e room_localName, que associam um sensor a determinada sala de um prédio da universidade;

3. aparelhos de ar-condicionado (tabela AirConditioner), com os atributos id (chave da tabela), current temperature, e as chaves estrangeiras: room_roonName e room_localName, que associam um aparelho de ar condicionado a uma das salas de um prédio da universidade;

4. medições aferidas pelos sensores (tabela Measurements), com os atributos id (chave primária), time, value e a chave estrangeira sensor_id, que associa a medição ao sensor ao qual a mesma pertence;salas onde estão localizados os sensores e aparelhos de ar-condicionado (tabela Room), composta pelos atributos roomName e a chave estrangeira localName, que associa uma sala ao prédio no qual ela se localiza. Uma vez que dois prédios distintos podem conter salas com o mesmo nome, cada sala é

identificada unicamente por uma chave composta formada pela tupla <roomName, localName>;

5. agendamentos das horários de aula nas salas de aula (tabela Scheduling), composta pelos atributos id (chave primária), date, description e as chaves estrangeiras roomName, localName e user_login, que associam um agendamento à sala ao qual a atividade agendada sera realizada e ao usuário responsável pela atividade;

6. uma tabela para representar os prédios onde estão localizadas as salas onde os sensores foram instalados (tabela Local), com os atributos local name (chave primária), latitude e longitude A tabela Room_Scheduling associa uma sala aos agendamentos de aula, enquanto a

tabela Room_Sensor associa um sensor a uma sala.

5.2 Montagem e configuração do hardware Nesta seção serão descritos os hardwares utilizados no projeto, bem como detalhes

relacionados a sua montagem e configuração. A seção 5.2.1 descreve como foi montado e configurado o sensor de umidade e temperatura (DHT11 Sensor). A seão 5.2.2 descreve como foi montado e configurando o sensor de presença (PIR Sensor). A plataforma de prototipagem eletrônica Arduino [32] foi utilizada para suporte à montagem e configuração desses sensores.

5.2.1 DHT11 Sensor

Para esse projeto, está sendo utilizado o sensor DHT11, que é um sensor digital que permite uma leitura rápida e ágil da temperatura e umidade relativa do ar. O valor da umidade relativa é expressa em percentagem (%), de 20 a 95 %, e a temperatura é expressa em graus Celsius (°C), de 0 a 50 °C, com uma taxa de erro de aproximadamente 5 % e 2 °C, respectivamente.

O DHT11 calcula a umidade relativa medindo a resistência elétrica entre dois eletrodos. A mudança nessa resistência é proporcional à umidade relativa. Já a leitura da temperatura vem de um termistor (NTC) incorporado ao DHT11.

O propósito de se utilizar esse sensor em uma sala é para, juntamente com o PIR sensor, evitar o uso inadequado dos aparelhos de ar condicionado. A ideia é que quando os aparelhos estiverem ligados, possa-se manter uma temperatura padrão que seja alterada quando a temperatura/umidade da sala mudar. Por exemplo, supondo que a temperatura padrão seja de 22 °C, conforme mais pessoas adentrarem na sala, o sensor identificará uma mudança de temperatura/umidade. Logo, essa temperatura padrão não será suficiente para

manter o clima da sala agradável. Então, haverá um controle para baixar a temperatura caso isso ocorra. O inverso também é verdadeiro.

A leitura da umidade e temperatura desse sensor é relativamente simples. É necessário apenas definir, no Arduino, um pino de entrada e saída, onde é feita a leitura dos dados. A Figura 5.10 mostra o sistema real.

Figura 5.10: Sistema representando o sensor DHT11 no Arduino Uno

O código, referente a leitura dos dados do sensor, é apresentado na Figura 5.11. Foi

definido o pin 7 como pino da leitura dos dados (entrada e saída). Como a leitura pode demorar mais que o esperado, foi inserida uma condição para verificar se a leitura foi realizada com sucesso ou não. Em caso de sucesso, as medidas da umidade e temperatura serão apresentadas no serial monitor da IDE Arduino [31]. Caso contrário, uma mensagem de falha será apresentada. Há um atraso de 10 segundos entre cada leitura.

Figura 5.11: Código na IDE Arduino do DTH11 sensor

5.2.2 PIR Sensor

Para verificar se há a presença de alguém na sala/laboratório visando se fazer o controle de ligar/desligar o sistema de ar condicionado do ambiente em questão, está sendo utilizado um PIR sensor. O PIR sensor é um detector de radiação infravermelha e é composto, geralmente, por dois detectores internos e uma lente Fresnel (externa). A função dos detectores é gerar dois feixes, zonas de detecção. Uma zona indica que há o movimento e a outra serve de referência (em um sentido), em outro sentido acontece o inverso. Já a lente Fresnel, que geralmente tem o formato esférico, tem o papel de ampliar o campo de visão do detector (tanto em distância quanto em ângulo). A Figura 5.12 dá uma melhor visão de como o sensor funciona.

Figura 5.12: Funcionalidade do PIR sensor

Dessa forma, quando o sensor detectar que há um indivíduo na sala/laboratório, o(s)

aparelho(s) de ar-condicionado será(ão) acionado(s), e quando estiver vazia, será(ão) automaticamente desligado(s). Este processo evitará o desperdício de energia.

A análise dos dados para esse sensor é um pouco mais complexa, porque tem que levar em consideração um período de tempo antes de afirmar que não há mais movimento no ambiente em questão. Antes de tudo, o sensor precisa de um tempo para calibrar (indicado no datasheet) uma variável para indicar quando o sensor deixou de indicar movimentos e um tempo de pausa antes de assumir que não há mais movimentos. Após indicar que o sensor está no modo LOW (modo inicial), ou seja, não há movimentos, dar-se-á um tempo para calibração do sensor (nesse exemplo de 30 segundos). Então, uma mensagem é impressa no serial monitor da IDE Arduino informando que o sensor está ativo e pronto. Após isso, ele entra em um loop onde é verificado em que momento houve movimento, assim como o momento em que esse movimento acabou. Todas essas informações são impressas no serial monitor. A Figura 5.14 mostra o código utilizado e a Figura 5.13 apresenta o sistema real.

Figura 5.13: Sistema representando o PIR sensor no Arduino Uno

Figura 5.14: Código na IDE Arduino do DTH11 sensor

O próximo passo, que está em fase de implementação, consiste em enviar as

informações do DHT11 Sensor e do PIR Sensor para o sistema Web desenvolvido, onde os dados serão tratados. Os dados serão enviados através da API REST fornecida pelo sistema Web. Desse modo, haverá o registro dos dados dos sensores (DHT11 e PIR sensor) de cada sala, para poder manter o acompanhamento e tomar decisões como por exemplo ligar/desligar o ar-condicionado conforme presenças sejam detectadas. Para fazer esse envio dos dados, do Arduino para o sistema Web, está sendo utilizado um Ethernet Shield [33], que é responsável por enviar os dados via rede.

5.3 Próximas atividades

Embora a API REST para receber os dados dos sensores esteja atualmente implementada e a configuração do hardware para aferir as medições de temperatura, umidade e presença já tenha sido realizada, a equipe de desenvolvimento desse projeto enfrenta dificuldades para enviar, via rede, os dados aferidos pelos sensores para o sistema Web. Essa dificuldade é devido à falta de experiência do grupo em trabalhar com o recém adquirido Ethernet Shield. O Ethernet Shield adquirido é acoplado no Arduino a fim de permitir que dados possam ser enviados via rede. O dispositivo exige o uso de algumas bibliotecas e configurações específicas de rede que estão sendo estudadas pela equipe para que, através do dispositivo, os dados sejam enviados ao sistema Web.

Portanto, atualmente está sendo investigado o uso do Ethernet Shield para, através dele, enviar os dados aferidos pelos sensores para o sistema Web. A tarefa seguinte a essa consistirá em controlar os aparelhos de ar-condicionado com base nos valores dessas medições. Para isso estão sendo implementadas, na camada de controller do sistema Web, as regras que decidirão quando acionar, desligar ou alterar a temperatura dos aparelhos de ar-condicionado.

A forma como os aparelhos de ar-condicionado serão controlados ainda está sendo investigada pela equipe. Atualmente estamos investigando uma abordagem que se baseia no uso de LEDS que emitem um sinal infravermelho similar ao que é emitido pelo controle remotos dos aparelhos de ar-condicionado. Tais LEDS podem ser acoplados em um Raspberry pi [34], um microcomputador prográmavel de baixo custo. Ao identificar a necessidade de alterar as configurações do aparelho de ar-condicionado em determinada sala, o sistema Web deve enviar, via rede, um sinal para o Raspberry pi com a instrução a ser realizada (ligar o ar-

condicionado, desligar ou alterar a temperatura). Ao receber a instrução o dispositivo enviará para o parelho de ar-condicionado o sinal infravermelho correspondente a instrução recebida.

Contudo, essa abordagem ainda está sendo investigada, e ainda deve ser posta em prática. Caso adotada, será descrita em detalhes no próximo entregável deste projeto. Para o próximo entregável deve ser investigado também como utilizar sensores de iluminação a fim de que, com base neles, as lâmpadas sejam acionadas ou desligadas, conforme a necessidade. Para realizar essa tarefa as regras que tomarão essas decisões deverão ser implementadas na camada de controller do sistema Web. Os dispositivos que serão usados para acionar as lâmpadas também serão investigados.

6 Aplicação de Monitoramento de Água e Energia

6.1 Objetivo A título de histórico, no primeiro entregável foi enfatizado os sistemas que através do

qual será baseado a aplicação e as modificações, ajustes necessários, instalação da infraestrutura de comunicação.

Em consonância com o “WP3 Sensoriamento” o respectivo relatório visa descrever as ações referentes ao desenvolvimento do “Coletor Universal”, ferramenta de comissionamento e a integração com o primeiro protótipo de hardware desenvolvido.

Cronologicamente, as iniciativas descritas na Figura 6.1 serão desenvolvidas ao longo de todo o projeto em consonância ao WP 3.

Figura 6.1. Cronograma das ações a serem desenvolvidas.

6.2 Contextualização O Laboratório de Informática Industrial (LII) do IMD/NPITI/UFRN (atualmente

coordenado pelo Prof. Ivanovitch Medeiros Dantas da Silva) em parceria com a Petrobras desenvolveram os sistemas, BR-PlantViewer e BR-PlantHistorian, que em conjunto formam uma suıte de produtos denominada BR-Plant. Inicialmente, o intuito do projeto era desenvolver um sistema voltado para o armazenamento, processamento e disponibilização de dados provenientes de processos de automação industrial, mas ao decorrer do tempo, percebeu-se a sua utilidade em outros tipos de aplicações e processos (que também gerem informações temporais). Um desses casos é a iniciativa do projeto SmartMetropolis para o monitoramento de água e energia.

6.3 Coleta de dados - Coletor Universal

Foi desenvolvido um software intitulado, Coletor Universal, para gerenciar a coleta de dados do hardware de medição de energia e água (atualmente apenas o sensor de energia está desenvolvido). A estrutura desse software foi pensada de forma a possibilitar a coleta de dados não somente do hardware desenvolvido pelo grupo, mas também de protocolos comerciais já existentes como OPC, Hart, WirellesHart, bastando para isso o desenvolvimento de um driver.

Na Figura 6.2 é mostrado um esboço dos componentes do Coletor Universal, que conta com as seguintes partes:

● Interface de comunicação bluetooth: possibilita a configuração/comissionamento do coletor em campo através de uma aplicação Android.

● Interface de aquisição de dados: faz a comunicação com os driver de comunicação afim de realizar a coleta do dado.

● Interface servidor: responsável por realizar a comunicação com a nuvem, atualmente a comunicação pode ser realizar por Wifi ou GPRS, essa última em fase de consolidação ainda.

● Negócio: núcleo do coletor, responsável por gerenciar todo o processo de coleta de dados e realizar a integração entre os demais componentes. Conta com um banco de dados embarcado para salvar as configurações feitas pelo usuário.

Figura 6.2. Componentes do coletor universal.

6.4 Diagrama de Classes

A Figura 6.3 mostra o diagrama de classe referente as entidades de domínio do coletor universal.

Figura 6.3. Diagrama de classes do domínio do Coletor Universal.

A entidade RepositorioNuvem contém os dados do repositório/servidor onde será armazenado os dados coletados. FonteColeta possui as informações da fonte de dados de onde será coletado os dados, cada fonte pode conter múltiplas Tag’s. As informações de cada tag são representadas pela classe Tag e o valor da tag é representado por ValorTag.

6.5 Diagrama de Sequência

A Figura 6.4 exibe o principal fluxo do Coletor Universal que é a coleta de dados. Mostra a sequência de passos desde a aquisição dos dados do hardware até o seu envio para o servidor do BR-PlantHistorian.

Figura 6.4. Diagrama de sequência do fluxo de aquisição de dados.

A classe ColetaDados inicia o processo de aquisição com o driver adequado para a tag (variável) que deseja-se coletar o dado através da classe GerenciadorComunicacaoFonteDados. Após isso é invocado o método getValor(), para se obter o valor da tag. A classe ColetaDados armazena esses valores em memória e em seguida envia esses dados para a nuvem através da classe ComunicacaoNuvem.

6.6 Hardware de Medição de Energia

O hardware de medição de energia está descrito no Relatório 02 do WP-3 Sensoriamento.

6.7 Aplicativo Android

O sistema de comissionamento para medição de energia é um aplicativo desenvolvido para a plataforma Android. Ele tem como funcionalidades comissionar e gerenciar um hardware capaz de monitorar a medição de energia. A aplicação se comunica com o hardware utilizando

o protocolo de comunicação 802.15.1 (Bluetooth). Também é capaz de enviar comandos de configuração não só para efeitos de hardware, mas também, configurar toda a comunicação com hardware com nuvem onde serão armazenadas as informações. O aplicativo basicamente envia e recebe dados, fazendo com que o hardware e a medição de energia em si estejam em constante gerenciamento. Uma vez comissionado o hardware, a aplicação é capaz de coletar as informações salvas assim como editá-las caso necessário. O uso desse sistema é apenas feito em loco, já que sua principal função é comissionar o hardware para o funcionamento a distância.

6.7.1 Metodologia de desenvolvimento Para o desenvolvimento do projeto foi-se utilizado um computador com capacidade para o desenvolvimento de aplicativos Android, assim como toda a plataforma necessitada. Primeiro foi-se desenvolvido um protótipo inicial que se assemelhava a um terminal de envio de comandos, esta parte serviu como base de teste da comunicação bluetooth com o hardware. Uma vez que a comunicação estava funcionando da maneira correta, foi dado início ao desenvolvimento de novas funcionalidades, como o comissionamento da nuvem, que foi capaz de configurar o armazenamento de dados do hardware na nuvem para futuros diagnósticos. Por fim, as funcionalidades de configuração do hardware foram implementadas, como a escolha do dado, que tipo de informação coletar, escolher qual sensor utilizar, cadastrar sensores e dentre outras mais. Com a aplicação finalizada, seguiu-se para a etapa de testes, onde foi possível testar a aplicação na prática e em ambiente real. A etapa de testes foi bastante útil para encontrar problemas e consertá-los. 6.7.2 Funcionalidades suportadas Abaixo seguem imagens da aplicação e suas etapas de usabilidade e configuração.

● Cadastro de Nuvem: Essa é a primeira etapa a ser feita e é a primeira tela que deve aparecer ao se iniciar a aplicação. Nela será configurada a comunicação com o servidor(Nuvem) para que os dados coletados sejam enviados e armazenados para uma futura análise das informações.

● Menu de Opções: Após a configuração da Nuvem, um menu com algumas opções estará disponível para que seja feito o comissionamento tanto da coleta das informações como também dos sensores e fontes de coleta de dados. A primeira opção fonte Coleta serve para atualizar as informações, ou seja, para que as configurações sejam rebuscadas e atualizadas. A segunda opção Cadastrar Fonte serve para que se possa cadastrar uma fonte de coleta onde serão acoplados sensores que irão prover dados para Nuvem. A terceira opção Nuvem serve para que se possa editar as informações salvas do comissionamento da nuvem.

● Cadastrar Fonte: Aqui acontece quando se escolhe essa opção do menu de opções. Uma janela abrirá pedindo algumas informações da fonte de coleta para que ela possa ser cadastrada. O primeiro campo refere-se ao nome da fonte de coleta. O segundo

campo é o identificador, ou seja, um valor que irá sempre representar aquela fonte em específico. No último campo, que é de seleção, o usuário irá escolher que tipo de fonte de coleta ele quer, seja Energia, água ou alguma outra opção que esteja disponível.

● Menu de Fontes: Uma vez adicionada uma fonte, o usuário poderá contar com um menu contendo a lista de todas as fontes já cadastradas podendo selecionar para ver os sensores já cadastrados na fonte ou adicionar outros sensores, que chamamos de TAGS.

● Cadastro de TAGS: Quando se adiciona uma fonte de coleta, é preciso habilitar os sensores que estão conectados a essa fonte, no caso, as TAGS. Para isso, basta segurar o botão item referente a fonte de coleta na lista apresentada e irá aparecer uma janela onde se poderá entrar com os dados da TAG (sensor). O primeiro campo é o nome da TAG. O segundo campo é uma seleção do tipo do sensor, no caso, ele pode ser NUMERIC (numérico) ou TEXT (texto).

Figura 6.5. Telas de configuração da aplicação de comissionamento.

6.8 Protótipo

Para validar todos os conceitos e abordagens propostas foi desenvolvido um protótipo para realizar a medição de energia. Como teste, foi utilizado um carregador de celular e monitorado algumas variáveis referentes ao seu consumo de energia. A Figura 6.6 mostra o protótipo do hardware de medição de energia.

Figura 6.6. Protótipo do Hardware de medição de energia.

O link https://goo.gl/BEFU5I contém um vídeo mostrando a configuração do hardware de medição de energia através do aplicativo Android, no qual são configuradas as informações da nuvem, da fonte de dados e das tags monitoradas.

Após a configuração do hardware e do software de coleta, os dados passam a ser enviados para a nuvem, podendo ser visualizados através do BR-PlantViewer e BR-PlantHistorian, como pode ser visto nas Figuras 6.7 e 6.8 e no vídeo https://goo.gl/RbPbM1.

https://goo.gl/BEFU5I

https://goo.gl/RbPbM1

Figura 6.7. Monitoramento das variáveis associadas ao consumo de energia de um carregador

de celular.

Figura 6.8. Monitoramento das variáveis associadas ao consumo de energia de um carregador

de celular.

Na Figura 6.7, o primeiro gráfico (superior esquerdo) apresenta os valores de tensão rms por corrente rms. O segundo (a direita do primeiro) é a análise dos valores de pico de tensão por valores de pico de corrente. Na Figura 6.8 o primeiro (superior esquerdo) apresenta

a análise da energia ativa, aparente e reativa. O segundo (a direita do primeiro) é uma análise de frequência.

6.9 Próximos Passos

Após a integração de todas as partes, hardware de medição de energia, driver de aquisição de dados, software de coleta de dados, aplicativo Android e sistema na nuvem, os seguintes passos são objetivos do próximo entregável:

● Finalização do desenvolvimento do módulo de comunicação GPRS; ● Testes e melhorias no coletor universal à fim de torná-lo mais robusto; ● Melhorar a usabilidade do aplicativo Android de configuração do hardware. ● Miniaturizar o hardware de medição de energia. ● Realizar cálculos no BR-Plant para mostrar para os gestores o consumo de energia

consolidado. ● Entrevistas com a superintendência de infraestrutura da UFRN afim de identificar

possíveis índices de qualidade para o problema de monitoramento de água e energia. ● Desenvolvimento do hardware de medição de água.

7 Considerações Finais

Este relatório apresentou os resultados alcançados pelo WP2-Aplicações do segundo trimestre do Projeto Smart Metropolis. Os resultados mostram resultados bem animadores, já com sistemas desenvolvidos no âmbito do projeto sendo implantados na cidade. Embora não citado diretamente no relatório, o trimestre também foi produtivo na esfera de publicações científicas uma vez que o work package obteve três artigos aprovados na Second IEEE International Smart Cities Conference (ISC2 2016), evento a ser realizado em Trento, Itália, no período de 12 a 14 de setembro de 2016. Além disso, o grupo teve um artigo publicado no International Journal of Tourism Cities. Maiores informações sobre as publicações do projeto podem ser encontradas no endereço http://smartmetropolis.imd.ufrn.br/?page_id=23.

http://smartmetropolis.imd.ufrn.br/?page_id=23

Referências

[1] Mark Murphy. 2009. Beginning Android. Apress, Berkeley, CA, USA. [2] Mell, Peter, and Tim Grance (2011). "The NIST definition of cloud

computing."NIST Special Publication. National Institute of Standarts and Technology, USA.

[3] Erl, Thomas, Ricardo Puttini, and Zaigham Mahmood. Cloud computing: concepts, technology, & architecture. Pearson Education, 2013.

[4] Wang, Dan, Xiang Robert Li, and Yunpeng Li. "China's “smart tourism destination” initiative: A taste of the service-dominant logic." Journal of Destination Marketing & Management 2.2 (2013): 59-61.

[5] Fowler, Martin. Patterns of enterprise application architecture. Addison-Wesley Longman Publishing Co., Inc., 2002.

[6] OpenStreetMap, http://www.openstreetmap.org/. [7] Leaflet, an open-source JavaScript library for mobile-friendly interactive maps,

http://leafletjs.com/. [8] Omnivore, universal format parser for Leaflet & Mapbox.js,

https://github.com/mapbox/leaflet-omnivore/. [9] N. Pelekis and Y. Theodoridis, Mobility data management and explo-ration.

USA: Springer New York, 2014. [10] Barros, Vanessa Tavares de Oliveira. Avaliação da interface de um aplicativo

computacional através de teste de usabilidade, questionário ergonômico, análise gráfica do design. Florianópolis: 2003. Dissertação (Mestrado em Engenharia de Produção) – Universidade Federal de Santa Catarina.

[11] API Guides ListView. "ListView" (2015). Disponível em http://developer.android.com/intl/pt-br/guide/topics/ui/layout/listview.html. Acessado em 29/04/2016.

[12] Android Develop RecyclerView. "Creating Lists and Cards" (2015). Disponível em http://developer.android.com/training/material/lists-cards.html. Acessado em 29/04/2016.

[13] Android Reference. "CardView" (2015). Disponível em http://developer.android.com/intl/pt-br/reference/android/support/v7/widget/CardView.html. Acessado em 29/04/2016.

http://www.openstreetmap.org/

http://leafletjs.com/

https://github.com/mapbox/leaflet-omnivore

[14] Android Reference RatingBar. "RatingBar" (2015). Disponível em http://developer.android.com/intl/pt-br/reference/android/widget/RatingBar.html. Acessado em 29/04/2016.

[15] Android Develop Drawer. "Creating a Navigation Drawer" (2015). Disponível em http://developer.android.com/intl/pt-br/training/implementing-navigation/nav-drawer.html. Acessado em 29/04/2016.

[16] PostGIS, Spatial and Geographic objects for PostgreSQL. http://postgis.net [17] GSON. “A Java serialization/deserialization library that can convert Java Objects into

JSON and back." (2016).https://github.com/google/gson. Acessado em 30/04/2016. [18] Open311 is a Specification for an Open Platform. Disponível em

http://www.open311.org/2009/09/open311-is-a-specification-for-an-open-platform/. Acessado em 29/04/2016.

[19] Open311. Disponível em http://www.open311.org/. Acessado em 24/04/2016. [20] Leaflet.heat. A tiny, simple and fast heatmap plugin for Leaflet.

http://leaflet.github.io/Leaflet.heat/demo [21] The Hausforff Distance. Disponível em

http://www.ceng.metu.edu.tr/~e1202654/report/node2.html. Acesso em 10/07/2016. [22] ActiveAndroid ORM site. "Activeandroid ORM" (2015). Disponível em

http://www.activeandroid.com/. Acessado em 28/07/2016. [23] Apache TomCat. Disponível em: http://tomcat.apache.org/ acessado em julho de 2016 [24] PostgreSQL. Disponivel em: https://www.postgresql.org/ acessado em julho de 2016 [25] Hibernate. Disponível em: http://hibernate.org/ acessado em julho de 2016 [26] Kircher, Michael, and Prashant Jain. PATTERN ORIENTED SOFTWARE

ARCHITECTURE. Vol. 3. John Wiley & Sons, 2005. [27] CARNEIRO, Davi Luan. "Introdução ao pattern DAO." São Paulo, out (2006). [28] Sensor DHT11. Disponível em: http://www.micropik.com/PDF/dht11.pdf acessado em

julho de 2016. [29] PIR sensor. disponível em: https://cdn-learn.adafruit.com/downloads/pdf/pir-passive-

infrared-proximity-motion-sensor.pdf. acessado em julho de 2016. [30] IDE Arduino. Disponível em: https://www.arduino.cc/en/Main/Software. acessado em

julho de 2016. [31] Arduino. Disponível em: https://www.arduino.cc/. Acessado em julho de2016 [32] Arduino Ethernet Shield. Disponível em:

https://www.arduino.cc/en/Main/ArduinoEthernetShield. Acessado em julho de 2016. [33] Raspberry pi. Disponível em: https://www.raspberrypi.org/. acessado em julho de 2016. [34] Handler | Android Developers. Disponível em:

https://developer.android.com/reference/android/os/Handler.html

http://postgis.net/

http://www.open311.org/2009/09/open311-is-a-specification-for-an-open-platform/

http://www.open311.org/

http://leaflet.github.io/Leaflet.heat/demo

http://www.ceng.metu.edu.tr/%7Ee1202654/report/node2.html

https://developer.android.com/reference/android/os/Handler.html

[35] Chart.js. Disponível em: http://www.chartjs.org. Acesso em 19 de julho de 2016.

http://www.chartjs.org/

Anexo A - Tutorial de configuração do Raspeberry Pi para execução do protótipo da aplicação de monitoramento de água e energia

1. COMO MONTAR O RASPBERRY PI Para poder configurar o Raspberry é necessário que ele esteja conectado a rede através

de um cabo Ethernet, seja alimentado por uma fonte e também esteja conectado a um monitor, teclado e mouse, por meio de um cabo HDMI e dois cabos USB, respectivamente. O Raspberry também deverá conter um cartão SD onde será armazenado o SO a ser instalado.

2. INSTALANDO O SISTEMA OPERACIONAL Quando a montagem for finalizada, irá aparecer uma janela na tela onde o usuário irá

escolher qual sistema operacional deverá ser instalado. Basta selecionar o checkbox correspondente ao SO desejado e clicar em install. Feito isso uma janela irá aparecer mostrando o progresso da instalação.

3. CONFIGURANDO TECLADO O Raspberry Pi vem configurado para utilizar o teclado inglês genérico, portanto

devemos configura-lo para o teclado brasileiro. Após o fim da instalação, irá aparecer na tela um menu de configuração. Neste tutorial

não iremos configurar utilizando esse menu, então com o botão tab selecione Finish e aperte enter.

Obs.: Se for pedido login e senha, elas são pi e raspberry, respectivamente. Para inicializar a interface gráfica digite o comando startx.

Com a interface gráfica inicializada podemos configurar o teclado. Abra o terminal do Raspberry e digite:

Onde o primeiro comando serve para fazer backup do arquivo que vamos modificar. Um arquivo será aberto no terminal, altere o arquivo para deixá-lo com a imagem abaixo:

Feita as mudanças salve o arquivo e saia do editor com os comandos Ctrl+x e em seguida ‘y’. Após modificar o arquivo reinicie o sistema com “sudo reboot”. Após reiniciar, o sistema irá pedir login e senha, elas são pi e raspberry, respectivamente. Para inicializar a interface gráfica digite o comando startx.

4. CONFIGURANDO O WIFI É necessário configurar o Wifi, pois ele não irá funcionar automaticamente. Para isto

digite no terminal:

Onde o primeiro comando serve para fazer backup do arquivo que vamos modificar. Um arquivo será aberto no terminal, altere o arquivo para deixa-lo com a imagem abaixo:

Obs.: Se a rede possuir senha, ela deve ser colocada dentro de aspas duplas no campo psk que deve substituir o campo key_mgmt.

Feita as mudanças salve o arquivo e saia do editor com os comandos Ctrl+x e em seguida ‘y’. Após modificar o arquivo reinicie o sistema com “sudo reboot”.

Após reiniciar o sistema irá pedir login e senha, elas são pi e raspberry, respectivamente. Para inicializar a interface gráfica digite o comando startx.

5. ATUALIZE O SISTEMA

Para atualizar o sistema digite no terminal:

6. ACESSO REMOTO Para poder acessar o Raspberry sem o uso do monitor:

● Habilite o SSH.

● Configure o IP do Raspberry para estático.

Por garantia faça um backup do arquivo que vamos modificar.

Para configurar o IP estático corretamente devem-se obter alguns dados sobre suas configurações de rede. Para isso execute os comandos abaixo e anote as informações necessárias.

O primeiro comando a ser utilizado é o “ifconfig”. Anote as informações destacadas abaixo.

Em seguida execute o comando “netstat -nr”. Anote as informações destacadas abaixo.

Com os dados anotados, abra o arquivo “/etc/network/interfaces”.

Altere a linha:

Para:

Adicione as informações anotadas que obtemos como segue a imagem abaixo.

Salve o arquivo e saia do editor com os comandos Ctrl+x e em seguida ‘y’. Reinicie o serviço de rede com o comando:

Ou reinicie o SO, utilizando o comando:

Agora o Raspberry possui um IP fixo.

7. ACESSO REMOTO UTILIZANDO SSH Para acessar o Raspberry do seu computador, basta colocar no terminal:

Por padrão o nome do usuário e senha são pi e raspberry, respectivamente.

8. DESLIGANDO O RASPBERRY Para desligar o Raspberry com segurança, execute o comando:

9. INSTALANDO JAVA Primeiramente vá até o site da Oracle e faça o download do JDK, escolha a versão Linux

32-bits.

Descompacte e instale o download no diretório /opt , com os seguintes comandos:

Em seguida o java 8 pode ser instalado, executando os seguintes comandos:

10. INSTALANDO A BIBLIOTECA RXTX Para instalar a biblioteca em questão basta executar o seguinte comando no terminal:

11. INSTALANDO A BIBLIOTECA PI4J Antes de instalar a biblioteca em questão é necessário instalar o JRE e JDK no raspberry

e o conectar a internet. Feito isso a biblioteca pode ser instalada através do comando:

12. INSTALANDO E CONFIGURANDO O BLUETOOTH A instalação do bluetooth no raspberry pi deve ser feita pelos comandos:

Obs: O dispositivo bluetooth deve estar conectado ao raspberry durante todo o processo de instalação.

Para que o bluetooth fique sempre visível após ligar o raspberry basta modificar o arquivo rc.local presente em /etc/init.d . Deve-se colocar o comando:

13. CONFIGURANDO DATA/HORA Para que a data e hora do raspberry atualize corretamente assim que o mesmo é iniciado,

basta configurá-lo para funcionar como um ntp cliente.

Primeiramente deve-se instalar o ntp, com o comando:

Após isso, abra o arquivo ntp.conf.

E coloque o IP do servidor ntp local no arquivo, como mostrado abaixo:

Salve a configuração e saia do nano. Agora reinicie o ntp service com:

Após essa configuração o seu raspberry estará com a data e hora correta.

14. Instalação do Coletor Universal

Para realizar a instalação do Coletor Universal obtenha o instalador, que consiste em uma pasta com todos os arquivos necessários a execução do programa, e copie ele para algum diretório no Raspberry.

Para inicializar o serviço de coleta de dados assim que o Raspberry é inicializado é necessário modificar o arquivo rc.local presente em /etc/init.d. Deve-se adicionar o caminho da pasta onde está o coletor universal da seguinte forma:

O diretório raiz do coletor possui as seguintes pastas: /config, que possui todos os arquivos que determinam o modo de funcionamento do coletor; /lib, contém todos as bibliotecas necessárias para o funcionamento da aplicação; /logs, contém todos os logs do coletor gerados durante a sua execução.

Universidade Federal do Rio Grande do Norte Instituto ...€¦ · Opções: Conheça Natal,...

Documents

Transcript of Universidade Federal do Rio Grande do Norte Instituto ...€¦ · Opções: Conheça Natal,...