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

Smart Metropolis – Plataformas e Aplicações para Cidades Inteligentes

WP2 - Aplicações

Relatório de Atividades do Quarto Trimestre

Natal-RN, Brasil Fevereiro de 2017

Equipe Técnica Docentes Prof. Dr. Everton Ranielly de Sousa Cavalcante (Coordenador) - DIMAp-UFRN Prof. Dr. Frederico Araújo da Silva Lopes - IMD-UFRN Prof. Dr. Ivanovitch Medeiros Dantas da Silva - IMD-UFRN Prof. Dr. Nélio Alessandro Azevedo Cacho - DIMAp-UFRN Prof.ª Dra. Thais Vasconcelos Batista - DIMAp-UFRN Discentes Bárbara Gabriella da Silva Soares Bruno Cipolla Moreira Danilo Mikael Costa Barros Jorge Pereira da Silva Juliana de Araújo Oliveira José Lucas Santos Ribeiro Maíla da Cunha Alves Ronaldo Gomes de Morais Júnior

Sumário

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

2 Aplicação ROTA Viatura ...................................................................................................... 7

3 Aplicação ROTA Cidadão Seguro ........................................................................................ 9

3.1 Entendendo o problema .................................................................................................. 9

3.1.1 Resultados da pesquisa com a população ........................................................... 12

3.2 Módulo de Urgência ..................................................................................................... 14

3.2.1 Etapa do tipo da ocorrência ................................................................................. 15 3.2.2 Etapa de localização ............................................................................................ 15 3.2.3 Etapa das informações gerais .............................................................................. 16 3.2.4 Finalização da ocorrência.................................................................................... 17

3.3 Módulo de Denúncia .................................................................................................... 18

3.4 Implementações futuras ................................................................................................ 18

4 Aplicação Find Trip Natal ................................................................................................... 20

4.1 Modificações na versão para a plataforma iOS ............................................................ 20

4.1.1 Banco de dados ................................................................................................... 20 4.1.2 Auto Layout ........................................................................................................ 20 4.1.3 Envio de avaliações ............................................................................................. 21

4.2 Modificações na versão para a plataforma Android ..................................................... 21

4.3 Implementações futuras ................................................................................................ 24

5 Aplicação Fala Natal ........................................................................................................... 25

5.1 Desenvolvimento para a plataforma Android .............................................................. 25

5.2 Serviços ........................................................................................................................ 25

5.2.1 Principais serviços .............................................................................................. 26 6 Aplicação Smart Place ......................................................................................................... 28

6.1 Geração de gráficos ...................................................................................................... 29

6.2 Integração com o sistema de reservas .......................................................................... 31

6.3 Criação das novas interfaces gráficas ........................................................................... 34

6.4 Análise dos dados dos sensores de presença, umidade e temperatura ......................... 37

7 Coletor Universal ................................................................................................................ 44

7.1 Novas funcionalidades para comissionamento em campo ........................................... 44

7.2 Implantação do sistema ................................................................................................ 45

7.3 Especificação dos conceitos e dos dashboards de monitoramento ............................... 47

7.4 Acompanhamento do consumo de energia ................................................................... 50

7.5 Apresentação dos resultados aos gestores da UFRN.................................................... 52

1 Introdução

O WP2 - Aplicacoes do Projeto Smart Metropolis reúne as atividades relativas ao planejamento e desenvolvimento de aplicações 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 têm como objetivo geral dar apoio aos cidadãos, a entidades responsáveis pela promoção de serviços públicos, entre outros possíveis interessados. Varias áreas serão contempladas com aplicações durante a execução do Projeto, tais como segurança pública, turismo, transporte público e privado, educação, prédios inteligentes, poluição, serviços essenciais (agua, luz, gás etc.), dentre outros.

Para o quarto trimestre do primeiro ano do Projeto, que corresponde aos meses de novembro de 2016 a janeiro de 2017, foi planejada a entrega de versões incrementais das cinco aplicações que vêm sendo desenvolvidas pelo grupo, a saber: (i) ROTA, plataforma de software para suporte a segurança pública; (ii) Find Trip Natal, voltada para o setor de turismo da cidade do Natal; (iii) Fala Natal, voltada para a comunicação entre a população e a Prefeitura Municipal do Natal no tocante ao registro de demandas, sugestões, denúncias e elogios; (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) Coletor Universal, uma aplicação para monitoramento de consumo de água e energia.

Com relação ao desenvolvimento das aplicações mencionadas, durante o trimestre foi possível observar os seguintes avanços:

ROTA-Viatura (Seção 2). Com o sucesso de sua implantação em viaturas da Polícia Militar na cidade do Natal, o projeto foi estendido para implantação também na cidade de Mossoró, a segunda maior cidade do Estado do Rio Grande do Norte, por meio do programa Ronda Cidadã. Além disso, foram implementados, testados e implantados (i) o módulo de requisição de abastecimento de viaturas, que disponibiliza o status da requisição de abastecimento, e (ii) o sistema de cartões-programa, através do qual a viatura recebe uma lista de pontos geográficos na cidade para cumprir um determinado tempo em cada um. ROTA Cidadão Seguro (Seção 3). Como previsto desde a sua concepção, o projeto maior da plataforma ROTA engloba uma terceira aplicação, chamada Cidadão Seguro, voltada desta vez para o cidadão. O ROTA Cidadão Seguro é aplicativo móvel para as plataformas Android e iOS que tem como objetivo principal oferecer um canal adicional de comunicação direta entre o cidadão e os órgãos de Segurança Pública, contribuindo para o descongestionamento dos canais telefônicos tradicionalmente utilizados, além do enriquecimento das informações passadas à Polícia por meio de fotos, vídeos e áudios.

Durante o trimestre foi feito o projeto do aplicativo e foi iniciado o seu desenvolvimento propriamente dito, em particular cobrindo os módulos através dos quais o cidadão realiza o registro de urgências e denúncias. Find Trip Natal (Seção 4). Durante o trimestre, continuou-se o desenvolvimento da versão do aplicativo para a plataforma iOS, mais especificamente cobrindo (i) a obtenção e consumo de dados provenientes do sistema Web que gerencia os pontos turísticos, (ii) a elaboração de interfaces de usuário responsivas para a aplicação no intuito de se ajustarem aos diferentes tamanhos de tela de dispositivos, e (iii) o envio de avaliações da cidade e de pontos turísticos para o servidor. Já com relação à versão para a plataforma Android, foram realizadas alterações pontuais na interface com o usuário, correções em algumas funcionalidades e algumas alterações feitas a nível das classes de domínio da aplicação. Fala Natal (Seção 5). Além da continuidade da integração paulatina com o servidor da Secretaria Municipal de Planejamento (SEMPLA) da Prefeitura Municipal do Natal, foi feita uma categorização dos principais serviços que seriam exibidos como prioritários na lista de serviços a ser consultada pelo usuário, por serem os mais comuns dentre as demandas realizadas às diversas Secretarias Municipais.

Smart Place (Seção 6). Foi adicionada ao sistema Web de gerenciamento da aplicação a funcionalidade de geração de gráficos, que permite ao usuário visualizar a evolução dos dados aferidos pelos sensores ao longo do tempo e correlaciona-los entre si, bem como o desenvolvimento de novas interfaces com o usuário a serem futuramente inseridas no sistema. A fim de melhor gerenciar o controle dos aparelhos de ar condicionado, a aplicação Smart Place foi integrada ao sistema gerenciador de reservas de salas do Instituto Metrópole Digital (IMD), tornando possível considerar informações referentes aos dias e horários de reservas de salas ao se gerenciar os aparelhos.

Coletor Universal (Seção 7). Foram desenvolvidas novas funcionalidades para comissionamento em campo via aplicação Android, além do acompanhamento da execução do protótipo implantado anteriormente em um laboratório da Escola de Ciência e Tecnologia (ECT) da UFRN.

2 Aplicação ROTA Viatura

O ROTA-Viatura é um projeto de aplicação móvel para a plataforma Android. O objetivo principal desta aplicação é 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. Como destacado no Relatório de Atividades do Terceiro Trimestre do Projeto Smart Metropolis, a aplicação ROTA-Viatura começou a ser implantada nas viaturas da Polícia Militar da cidade de Natal. Houve grandes avanços na divulgação da aplicação, dentre os quais a apresentação oficial à Secretaria da Segurança Pública e da Defesa Social do Estado do Rio Grande do Norte (SESED) e aos comandantes da Polícia Militar, além da extensão do projeto para a cidade de Mossoró, por meio do Ronda Cidadã. O Ronda Cidadã é um programa do Governo Estadual que se destina às ações de polícia comunitária, promovendo abordagens com foco no acolhimento, na inclusão social e na cidadania, sem que haja prejuízo no policiamento repressivo.

Figura 2.1 - Governador Robinson Faria (ao meio) e Gestores da Secretaria da Segurança Pública e da Defesa Social na inauguração do projeto Ronda Cidadã em Mossoró-RN. Imagem disponível em: http://mossorohoje.com.br/arquivos/materia/2017-01/mini-14658-1.jpg Durante o último trimestre foi implementado e testado o módulo de requisição de abastecimento da viatura, sendo disponibilizado o status da requisição do abastecimento, além de ser implantado o sistema de cartões-programa, através do qual a viatura recebe uma lista de pontos geográficos na cidade para cumprir um determinado tempo em cada um. Há ainda muitas funcionalidades a serem implementadas no aplicativo, porém foi necessário

primeiro analisar o desempenho e o comportamento da aplicação em um ambiente real de produção mediante essa expansão do projeto. As funcionalidades que serão implementadas após esse período de implantação e testes serão basicamente as últimas destacadas no relatório anterior, como: (i) um botão de apoio para a viatura; (ii) consulta do POP - Procedimento Operacional Padrão, para cada tipo de ocorrência, e; (iii) uma central de notificações vindas do CIOSP para deixar o policial da viatura atualizado sobre as operações que estão ocorrendo na cidade, últimas ocorrências e viaturas com pedido de apoio.

3 Aplicação ROTA Cidadão Seguro

ROTA Cidadão Seguro é uma nova aplicação móvel para as plataformas Android e iOS, que tem como principal objetivo oferecer um canal de comunicação direta entre o cidadão e o CIOSP - Centro Integrado de Operações de Segurança Pública para casos de denúncia e urgência. Além de permitir que o cidadão informe a Polícia acerca de denúncias e urgências, o ROTA Cidadão Seguro possibilita enriquecer as informações fornecidas para esses serviços, podendo conter dados adicionais como fotos, vídeos, áudios, informações de localização e descrições mais detalhadas sobre a denúncia ou ocorrência em questão.

Durante as etapas de análise e síntese do problema e de ideação, como melhor detalhado na Seção 3.1, foram percebidas algumas oportunidades frente a necessidades tanto dos órgãos de Segurança Pública quanto da própria população, dentre as quais:

● a possibilidade de o cidadão tornar-se mais participativo com a segurança da cidade, contribuindo para a comunicação e registro de ocorrências e denúncias;

● o envio de informações com maior qualidade aos órgãos de Segurança Pública, uma vez que poderiam ser enviados dados adicionais à denúncia ou ocorrência em questão;

● evitar chamadas múltiplas para a mesma ocorrência/denúncia; ● descongestionamento das linhas telefônicas de urgência (190) e denuncia (181); ● alternativa para pessoas com deficiência auditiva, as quais não podem utilizar o canal

telefônico, e; ● disponibilização de serviços adicionais.

3.1 Entendendo o problema Considerando que a aplicação ROTA Cidadão Seguro poderá ser usada pela grande parte da população da cidade do Natal, foi preciso buscar alguns métodos para imergir no problema e saber as necessidades reais tanto da população quanto dos gestores dos órgãos de Segurança Pública da cidade. Para isso, foi utilizado o design thinking como o processo principal de imersão no problema, pesquisa com a população, análise e síntese do problema, geração de ideias e teste de validação com os usuários. O design thinking pode ser definido como um conjunto de métodos e processos para abordar problemas, relacionados à aquisição de informações, análise de conhecimento e propostas de soluções. Com isso, a aplicação teve a oportunidade de ser desenvolvida, desde a sua concepção das ideias e funcionalidades até a implementação dos aplicativos, com a ajuda das ferramentas e da filosofia do design thinking, como mostrado na Figura 3.1.

Figura 3.1 - Processo da aplicação do Design Thinking. Imagem adaptada de: https://media.nngroup.com/media/editor/2016/07/29/designthinking_illustration_final-01-01.png

O primeiro passo foi realizar uma pesquisa para a imersão no problema, tanto no lado

do cidadão quanto no lado dos órgãos de Segurança Pública. Essas pesquisas foram feitas tanto por formulários online quanto presencialmente. Para entender as necessidades no caso da SESED, foram realizadas diversas reuniões com os gestores responsáveis por cada departamento envolvido, tendo a participação direta do Secretário de Segurança Pública, majores da Polícia Militar e delegados responsáveis pelo sistema do Disque-Denúncia.

No segundo passo, foi possível analisar e sintetizar os problemas e necessidades que os envolvidos ouvidos possuíam. Ao todo, foram 81 as pessoas que participaram da pesquisa

preliminar acerca da visão do cidadão sobre a segurança pública em Natal. Como mostram os gráficos da Seção 3.1.1, a pesquisa mostrou uma grande insatisfação da população com relação ao sentimento de segurança que eles possuem na cidade. Além disso, também foi entendido dessa pesquisa que o processo de denúncia deve mostrar, com grande destaque, que o sistema é totalmente sigiloso e seguro e que o sistema de urgência deve ser mais rápido, eficiente e eficaz.

O terceiro passo é um dos mais importantes e demanda criatividade e sensibilidade dos desenvolvedores, é a etapa da geração de ideias através dos problemas, necessidades e oportunidades percebidas nos passos anteriores. Basicamente, essa etapa foi realizada em conjunto com os integrantes do WP-Aplicações, além de contar com a ajuda dos gestores da Polícia Militar, como mostrado anteriormente. Foi percebida uma grande insatisfação e insegurança da população no uso dos serviços de teleatendimento disponíveis pela SESED. Para que não haja esses tipos de problemas no aplicativo Cidadão Seguro, foi definido que a aplicação terá uma forte divulgação da segurança das informações geradas, principalmente no Módulo de Denúncia, onde o denunciante deve ser totalmente anônimo. Uma das ideias foi criar um slide (o qual apareceria apenas uma vez, logo após a instalação do aplicativo) com ícones e informações sobre a autenticidade do aplicativo, mostrando que é uma aplicação oficial da SESED, e também sobre as medidas de segurança adotadas para que o usuário esteja ciente de que as informações de denúncias e ocorrências serão enviadas e processadas de forma segura. A tela inicial da aplicação também contará com ícones e informações sobre os serviços de cada módulo, com a intenção de, novamente, passar mais credibilidade e segurança para os usuários.

O quarto passo, de prototipação, foi realizado construindo as primeiras telas de interface do usuário, definindo a paleta de cores, disposição dos elementos da interface, design padrão para fontes e botões e o fluxo de telas. Após isso, deu-se início ao desenvolvimento da aplicação para as plataformas Android e iOS.

O último passo, de validação geral e testes das aplicações desenvolvidas será realizado nas primeiras semanas do mês de fevereiro de 2017. Durante a primeira etapa, de imersão no problema, na pesquisa realizada com a população, foram cadastradas 33 pessoas que se dispuseram a ser os beta-testers das primeiras versões do Cidadão Seguro. A ideia é que essa etapa seja validada de acordo com os testes de validação desses usuários.

Após toda essa imersão e entendimento do problema, foi possível notar que a adoção do design thinking como metodologia de concepção foi de grande importância para a organização de etapas e entendimento do projeto, fazendo com que o desenvolvimento seja voltado para as reais necessidades de todos os envolvidos.

3.1.1 Resultados da pesquisa com a população A pesquisa de imersão com os cidadãos foi realizada por meio de um formulário

online contando com a participação de 81 pessoas. A pesquisa foi formulada com 15 perguntas sobre a percepção geral da segurança pública que a população possui, sobre a satisfação e comportamentos em certos casos de urgência e denúncia, e também questões pessoais sobre o participante, como nome, bairro onde mora e endereço de e-mail.

A maioria das questões foi de natureza objetiva, tendo-se apenas que selecionar uma das opções que foram fornecidas. No entanto, também foram abordadas questões subjetivas, nas quais o participante teria que escrever sua resposta. Uma dessas questões teve o seguinte título: “Na sua opinião, o que poderia ser feito para melhorar a nossa Segurança Pública?”. Essa questão era opcional e teve a participação de 56 pessoas, tendo sido possível perceber com mais detalhes a visão e percepção da segurança que os participantes têm sobre a cidade.

Figura 3.2 - Resultados de uma questão do formulário online sobre a visão da segurança pública pelos cidadãos

Figura 3.3 - Resultados de uma questão do formulário online sobre a segurança dos cidadãos no transporte público da cidade

Figura 3.4 - Resultados de uma questão do formulário online sobre a disposição dos cidadãos em denunciar atividades ilícitas

Figura 3.5 - Resultados de uma questão do formulário online sobre o sentimento de segurança dos cidadãos ao utilizarem o disque-denúncia

Figura 3.6 - Resultados de uma questão do formulário online sobre o comportamento dos cidadãos ao se depararem em uma situação de risco

Figura 3.7 - Resultados de uma questão do formulário online a fim de analisar se os cidadãos saberiam informar sua localização pelas ruas da cidade 3.2 Módulo de Urgência

O Módulo de Urgência será o primeiro a aparecer quando o usuário abre o aplicativo. A intenção é que, por se tratar de ocorrências de urgência, o usuário possa realizar o cadastro da ocorrência o mais rápido possível. O fluxo é dividido em três principais etapas, a saber, (i) escolher o tipo da ocorrência, (ii) definir a localização onde está acontecendo a ocorrência e (iii) inserir as informações específicas para o tipo de ocorrência que o usuário escolheu. Após o cadastro das informações dessas etapas o aplicativo se comunica com o servidor do CIOSP através de uma API. A Figura 3.8 mostra as telas iniciais da aplicação.

Figura 3.8 - Telas iniciais da aplicação

3.2.1 Etapa do tipo da ocorrência Na primeira etapa, para o usuário escolher o tipo da ocorrência, foi definido pelos

próprios gestores da SESED que o aplicativo, inicialmente, terá apenas duas modalidades de ocorrências, sendo elas furto e som alto. Um dos principais motivos dessa escolha foi o grande número desses dois tipos de ocorrências registradas através do canal telefônico 190. Dessa forma, por se tratarem de ocorrências que podem ser resolvidas com mais tempo pela Polícia, priorizá-las no aplicativo deixaria o canal telefônico livre para ocorrências mais urgentes em que o atendente possa ter um papel mais importante, como no caso de sequestro, homicídio, assalto, etc. No entanto, a aplicação também oferece suporte caso o usuário queira informar sobre outro tipo de ocorrência, através da opção “Outros”, como mostrado na Figura 3.9. Ao selecionar essa opção, o aplicativo inicia uma chamada para o 190, fazendo com que o usuário não perca tempo abrindo o aplicativo em uma situação de perigo e não encontrando a opção necessária.

Figura 3.9 - Tela para selecionar o tipo da ocorrência

3.2.2 Etapa de localização A etapa de localização aparece para o usuário a partir do momento em que ele escolhe o tipo de ocorrência que deseja cadastrar. É uma etapa muito importante para a identificação do local pelos despachantes da polícia no CIOSP. Ao carregar esse módulo, a aplicação identifica a posição geográfica do usuário e a coloca como padrão na opção “Estou no local da ocorrência”, como mostrado na Figura

3.10, além de preencher automaticamente os campos de endereço, bairro e município utilizando a API de Geocoding do Google. Através dessa API, são utilizados como entrada os valores da latitude e longitude e a API se encarrega em retornar todas as informações sobre o endereço referente ao ponto geográfico. Caso a ocorrência não esteja acontecendo na mesma localização geográfica do usuário, ele pode desmarcar a opção “Estou no local da ocorrência”. Com isso, abre-se uma nova tela para o usuário posicionar o marcador na posição exata da ocorrência, como também mostrado na Figura 3.10. Após pressionar o botão “Pronto” para definir a nova localização, o aplicativo volta para a tela principal da localização da ocorrência, na qual é ativado o botão “Mudar o local da ocorrência”, em que o usuário pode, novamente, ter acesso ao mapa e definir um novo ponto geográfico de localização. Como requisito dos próprios gestores da SESED, o usuário deve informar, ao menos, um ponto de referência, a fim de facilitar o despacho da ocorrência para os policiais na viatura.

Figura 3.10 - Tela principal da localização da ocorrência (esquerda), tela para marcar um novo local da ocorrência (centro) e tela da localização com o botão para mudar o local da ocorrência ativado (direita) 3.2.3 Etapa das informações gerais Nessa etapa, o usuário deve inserir todas as informações necessárias para uma melhor análise do policial despachante. A Figura 3.11 mostra a interface dessa etapa, com um campo para o usuário descrever a ocorrência. Porém, fazer com que o usuário descreva manualmente a ocorrência pode gerar alguns problemas, como (i) falta de interesse ou de instruções necessárias para escrever toda a ocorrência, (ii) o usuário não saber informar as informações básicas necessárias para a análise da ocorrência pelo policial despachante, ou (iii) pode tornar o processo de cadastrar a ocorrência no aplicativo muito mais lento. Tendo

isso em vista, reuniões estão sendo feitas com os gestores da SESED a fim de definir campos e opções previamente preenchidas para resolver os problemas de usabilidade encontrados, melhorando tanto a experiência do usuário na aplicação como a qualidade das informações enviadas ao CIOSP.

Figura 3.11 - Tela para inserir as informações gerais sobre a ocorrência

3.2.4 Finalização da ocorrência A tela de finalização da ocorrência, mostrada na Figura 3.12, é a última tela, em que o usuário obtém informações sobre a ocorrência. Nela é mostrada uma informação visual para que o usuário saiba que sua ocorrência foi enviada com sucesso para os órgãos responsáveis pela Segurança Pública. Nessa tela o usuário também poderá ter acesso ao número do protocolo gerado para sua ocorrência.

Figura 3.12 - Tela de finalização da ocorrência

3.3 Módulo de Denúncia Outro serviço principal da aplicação é o módulo de denúncias, através do qual o

usuário poderá realizar uma denúncia completa, podendo informar a localização das pessoas e locais denunciados no próprio mapa da aplicação, bem como enviar mídias digitais (fotos, vídeos e áudios) para complementar a denúncia. Por motivos de prioridades e integração, este módulo estará disponível na aplicação apenas nas próximas versões. Ainda se encontra em análise com a equipe de Tecnologia da Informação da SESED a integração desse módulo com o sistema oficial de denúncias, o SIGED - Sistema de Gerenciamento de Denúncias. 3.4 Implementações futuras A aplicação tem espaço para o desenvolvimento de outros módulos, complementando ainda mais o serviço prestado à população. Um dos módulos futuros a ser implementado é a Central de Notificações, por meio da qual o usuário poderá receber informações e alertas direto da SESED. A ideia é que o cidadão possa acompanhar o andamento de sua demanda (denúncia ou ocorrência) por essa Central de Notificações, recebendo, por exemplo, o feedback sobre a sua demanda, o código da viatura que foi despachada para a ocorrência, etc. O projeto está apenas no início e acredita-se que, com os testes de usabilidade e as primeiras versões sendo liberadas para a população, novas demandas possam surgir, contribuindo para a melhoria e agilidade na identificação e resolução de problemas relacionados à Segurança Pública na cidade do Natal.

4 Aplicação Find Trip Natal

A aplicação Find Trip Natal é um aplicativo móvel que possui a finalidade de auxiliar os turistas a aproveitar melhor a sua viagem para a cidade do Natal. Para isso, o serviço oferece um conjunto de funcionalidades que auxiliam o usuário nas atividades turísticas. A principal funcionalidade do aplicativo é apresentar ao turista uma gama de atrações turísticas categorizadas em tipos e subtipos, servindo assim como um guia turístico prático e de fácil acesso dentro do dispositivo móvel.

Como o propósito e a base do aplicativo já foram explicadas completamente nos relatórios anteriores, neste relatório serão descritos os avanços do desenvolvimento no último trimestre. Os principais esforços envidados referem-se ao desenvolvimento do banco de dados e sua interação, bem como telas responsivas para a aplicação e envio de avaliações da cidade e seus pontos turísticos para o servidor.

4.1 Modificações na versão para a plataforma iOS

4.1.1 Banco de dados Na versão do aplicativo detalhada no relatório anterior, a maioria das telas possuía

apenas com dados estáticos. No último trimestre, foram implementadas todas as classes de acesso ao banco, seguindo como base o modelo do banco de dados utilizado no sistema Web para cadastro de atrações turísticas, também descrito em relatórios anteriores.

Ao abrir o aplicativo em algum dispositivo rodando o sistema iOS (tais como iPhone ou iPad) pela primeira vez, ele irá criar o banco de dados executando uma consulta através da qual todas as tabelas, colunas e referências são definidas. Após a criação do banco de dados, ele é populado através do processamento de arquivos JSON contendo os dados turísticos que foram cadastrados no sistema Web. Para implementar isso, foi utilizado o framework SwiftyJSON1, que facilita a manipulação de arquivos JSON em Swift. Para cada arquivo JSON processado, é preciso apenas percorrer elemento por elemento do array e salvar no banco as informações encontradas. 4.1.2 Auto Layout O Auto Layout é um sistema que calcula o tamanho e a posição de todos os elementos presentes na tela, baseado em restrições (constraints) colocados nesses elementos. Por exemplo, é possível criar um botão, centralizá-lo horizontalmente e definir que ele tem 10% 1 https://github.com/SwiftyJSON/SwiftyJSON

da altura da tela de distância do topo. Assim será possível posicionar o botão corretamente com base no tamanho da tela do dispositivo.

As telas da versão passaram por uma reformulação, pois no trimestre anterior elas haviam sido implementadas apenas para o tamanho da tela do iPhone 5. Agora, todas as telas estão trabalhando com Auto Layout e se adaptando ao tamanho da tela do dispositivo, desde a pequena tela do iPhone 4 até a tela do iPad Pro. Para que isso fosse possível, foi necessário utilizar Scroll View em algumas partes do aplicativo, pois nem sempre é possível apenas redimensionar os elementos. Por exemplo, na tela de avaliação da cidade, por mais que houvesse redimensionamentos dos elementos do design, tudo ficaria muito pequeno na tela do iPhone 4, que, portanto, fará uso do Scroll View nessa situação.

4.1.3 Envio de avaliações A versão atual do aplicativo já está enviando as avaliações sobre a cidade para o

servidor do Find Trip, a ordem das questões da avaliação seguindo o mesmo padrão presente na versão para a plataforma Android. Na implementação, foi utilizado o framework Alamofire2 para fazer as requisições ao servidor, facilitando o envio das avaliações. Com o Alamofire, é possível enviar uma requisição POST com os parâmetros no formato esperado pelo servidor com poucas linhas de código.

4.2 Modificações na versão para a plataforma Android Esta seção descreve as alterações realizadas neste trimestre para a versão para a plataforma Android do aplicativo Find Trip Natal. Tais mudanças estão relacionadas a alterações pontuais na interface gráfica, correções de algumas funcionalidades e a alteração feita nas classes de modelo do aplicativo. As mudanças na interface gráfica se concentraram na tela principal do aplicativo, como pode ser visto na Figura 4.1. A tela principal atual está do lado direito da Figura 4.1. Na versão anterior, o nome “Guia Natal” ficava no topo dessa tela. Esse nome foi alterado para indicar o nome da cidade na qual o Find Trip está sendo utilizado, fazendo com que o aplicativo não fique restrito apenas a cidade do Natal, mas possa ser implantado em outras cidades. Outra mudança foi a logomarca do aplicativo, que voltou a ser Find Trip, por questões de registro de marca. Na parte inferior da tela principal foi alterado o texto que antes só indicava a versão do aplicativo; nesta nova versão, o texto enfatiza que o aplicativo será o aplicativo de turismo oficial da Prefeitura da cidade.

Através de realização de testes do aplicativo em diferentes dispositivos, identificou-se que a alteração das configurações de tamanho de letra do dispositivo impactava negativamente no tamanho dos textos presentes nas telas do aplicativo, quando a letra estava 2 https://github.com/Alamofire/Alamofire

configurada para tamanho grande. Por isso, para todas as telas do aplicativo, o tamanho do texto foi alterado para dp (density-independent pixels), ao invés de sp (scale-independent pixels). Dessa forma, o texto fica no tamanho padrão do aplicativo, independentemente das configurações do usuário.

Figura 4.1 - Alterações na tela principal do aplicativo Find Trip Natal para a plataforma Android

Além das mudanças na interface gráfica da tela principal, algumas correções foram feitas para o correto funcionamento do aplicativo, a saber: (i) a adição de tratamento de exceção para evitar a ocorrência de NumberFormatException; (ii) correção de fluxo no Fragment de avaliação da cidade, e; (iii) correção no envio da avaliação da cidade para o serviço de nuvem. Alterações pontuais foram feitas no sentido de redirecionar o usuário para os sites ao clicar nas logomarcas na tela da Plataforma Find Trip, além de modificações nas preferências do aplicativo, para que o mesmo inicialize sem enviar a localização até que o usuário assim permita. A maior alteração feita no aplicativo foi nas classes de modelo do aplicativo. A equipe da SETUR, que cadastra os dados, percebeu que era interessante vincular pontos turísticos a mais de um subtipo de informação, de forma que um ponto turístico possa fazer parte de diferentes subcategorias. Dessa forma, o banco de dados do sistema Web através do qual os pontos turísticos são cadastrados sofreu algumas alterações. Para que o aplicativo ficasse em conformidade com essas mudanças, as classes de modelo foram alteradas internamente. A Figura 4.2 mostra o novo diagrama de classes do componente Model.

Figura 4.2 - Diagrama de Classes do componente Model

Algumas classes do modelo anterior foram mantidas nessa nova organização do banco (GPSTracker, CityReview, OpeningTime, Language, Review, TouristicReviewType), enquanto outras tiveram seus atributos modificados (Type e SubType). A classe Place, que representava o ponto turístico que estava ligado a um subtipo, que por sua vez se ligava a um tipo, foi substituída da seguinte forma:

● Attraction: Representa um ponto turístico e seus atributos estáticos, como latitude, longitude, telefone, e-mail e website.

● AttractionDetails: Representa os detalhes de um ponto turístico. Esses atributos podem estar em diferentes idiomas, por isso esta tabela no banco está relacionada à tabela Language, de modo que seus atributos (nome, endereço e descrição) são variáveis.

● AttractionSubType: Representa a ligação de um ponto turístico aos subtipos de informação do aplicativo, uma vez que uma atração pode estar relacionada a vários subtipos;

● TypeLanguages: Os tipos de informação no aplicativo podem ter diferentes traduções, dependendo dos idiomas aos quais o aplicativo ofereça suporte. Portanto, esta classe representa a ligação dos tipos com a tabela Language, que guarda os diferentes idiomas suportados pelo aplicativo.

● SubTypeLanguages: Da mesma forma, esta classe representa a ligação dos subtipos de informação aos diferentes idiomas suportados.

4.3 Implementações futuras A versão para a plataforma iOS do aplicativo Find Trip Natal está cobrindo quase todas as funcionalidades da versão Android. Para o próximo trimestre, pretende-se lançar uma versão para ambas as plataformas e, para que isso seja possível, alguns requisitos ainda precisam ser implementados na versão para a plataforma iOS:

1. Ao abrir o aplicativo, requisições devem ser feitas ao servidor para atualizar as avaliações dos pontos turísticos que estão no banco do aplicativo.

2. O aplicativo também deve oferecer ao usuário a opção de calcular rotas para os destinos turísticos escolhidos, ajudando assim a encontrar os pontos escolhidos.

3. Ao entrar na tela que mostra as informações de alguma atração turística, o aplicativo deverá calcular e mostrar os horários de atendimento daquele local baseado no dia atual do dispositivo.

5 Aplicação Fala Natal

O 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. O aplicativo oferecerá ao cidadão uma nova alternativa para a realização de demandas, sugestões, elogios e denúncias, em adição às já existentes na Web (através do endereço http://www.natal.rn.gov.br/siigpmn/ouvidoria/), por telefone ou via e-mail. 5.1 Desenvolvimento para a plataforma Android

Neste trimestre o aplicativo recebeu apenas a adição da listagem dos principais serviços. A integração com o servidor da SEMPLA - Secretaria Municipal de Planejamento está em andamento, mas apenas uma função nova foi implementada, a que retorna os principais serviços. O aplicativo está bem próximo de alcançar uma versão de testes, mas para isso será necessário que as funções de cadastro de solicitações sejam implementadas no servidor e que a lista de grupos seja atualizada, já que ainda não está de acordo com a lista atualizada de serviços. 5.2 Serviços

Os serviços providos pelo servidor Web da SEMPLA até o presente momento são: Descrição Endpoint Tipo de requisição Retorno

Lista os tipos de serviços

http://natal.rn.gov.br/siigpmn/ouvidoria/ws/web/services.json

HTTP GET Lista com todos os serviços de todos os grupos cadastrados

Listar todos os grupos

http://natal.rn.gov.br/siigpmn/ouvidoria/ws/web/groups.json

HTTP GET Lista com todos os grupos cadastrados no sistema

Retornar id de um serviço pelo token

http://natal.rn.gov.br/siigpmn/ouvidoria/ws/web/tokens/{token}.json

HTTP GET Objeto JSON com todos os dados do serviço identificado pelo token fornecido

Retornar o status de um

http://natal.rn.gov.br/siigpmn/ouvidoria/ws/web/requests/30

HTTP GET Objeto JSON com todos os dados do serviço

serviço solicitado

.json

identificado pelo identificador fornecido

Lista as sugestões feitas

http://natal.rn.gov.br/siigpmn/ouvidoria/ws/web/suggestions.json

HTTP GET Lista de objetos com todas as sugestões cadastradas no sistema

Lista os elogios feitos

http://natal.rn.gov.br/siigpmn/ouvidoria/ws/web/compliments.json

HTTP GET Lista de objetos com todos os elogios cadastrados no sistema

Cadastrar elogio

http://natal.rn.gov.br/siigpmn/ouvidoria/ws/web/compliments.json

HTTP POST Objeto JSON com o identificador do elogio cadastrado (zero caso ocorra erro no cadastro) e identificador da conta de usuário cadastrada

Cadastrar sugestão

http://natal.rn.gov.br/siigpmn/ouvidoria/ws/web/compliments.json

HTTP POST Objeto JSON com o identificador da sugestão cadastrada (zero caso ocorra erro no cadastro) e identificador da conta de usuário cadastrada

Listar principais serviços

http://natal.rn.gov.br/siigpmn/ouvidoria/ws/web/hotservices.json

HTTP GET Objeto JSON com com o master code (identificador de grupo de principais serviços), master name (nome do grupo de principais serviços), service code (identificador do serviço), service name (nome do serviço) e order (informação para uso do aplicativo)

5.2.1 Principais serviços Para facilitar o uso do aplicativo, foram elencados os serviços mais requisitados pela população: Serviço Secretaria

Fiscalização SEMSUR

Limpeza de galerias URBANA

Limpeza de margens de lagoa de captação URBANA

Limpeza de terrenos URBANA

Iluminação pública deficiente SEMSUR

Lâmpada apagada/acesa/piscando SEMSUR

Luminária quebrada/virada SEMSUR

Ornamentação pública SEMSUR

Manutenção de iluminação geral/campo de futebol/praças/canteiros centrais/postes de pétalas

SEMSUR

Refletor aceso/quebrado/apagado SEMSUR

Via pública com buraco SEMOV

Construção irregular SEMURB

Poluição da água e solo SEMURB

Poluição do ar SEMURB

Poluição sonora SEMURB

Poluição visual SEMURB

Acessibilidade SEMURB

Dengue SMS

6 Aplicação Smart Place

A aplicação Smart Place tem como objetivo realizar, de forma automática, o gerenciamento de recursos tais como aparelhos de ar condicionado e lâmpadas em prédios, contribuindo para a economia de eletricidade e proporcionando mais conforto e praticidade a seus usuários. A aplicação também tem como objetivo gerenciar, de forma automática, a presença de pessoas em ambientes, além de manter o registro dos recursos computacionais existentes em tais locais.

O relatório trimestral anterior tratou sobre: (i) a adição do módulo Measurement BlackBoard, responsável por processar as medições provenientes dos sensores e, com base nelas, decidir quando acionar ou desativar os aparelhos de ar condicionado gerenciados; (ii) a comunicação entre os sensores e a API REST provida pelo Smart Place; (iii) a montagem e configuração do hardware e software que interage com o aparelho de ar condicionado a fim de acioná-lo, desativá-lo e regular a temperatura do ambiente; (iv) um novo protótipo de interface gráfica para o sistema que permitirá que usuários com diferentes papéis e níveis de permissões possam interagir com o sistema, e; (v) os resultados iniciais da implantação, para fins de testes e validação, do sistema em um dos laboratórios do IMD - Instituto Metrópole Digital.

No decorrer do último trimestre, as seguintes atividades foram realizadas: 1. Foi adicionada ao sistema a funcionalidade de geração de gráficos, que permite ao

usuário visualizar a evolução dos dados aferidos pelos sensores ao longo do tempo e correlaciona-los entre si.

2. A fim de melhor gerenciar o controle dos aparelhos de ar condicionado, o sistema foi integrado ao sistema gerenciador de reservas do IMD (Keys). Com essa integração, o Smart Place também leva em consideração informações referentes aos horários de reservas das salas ao gerenciar os aparelhos de ar condicionado.

3. Foi iniciado o desenvolvimento de novas interfaces gráficas que futuramente serão inseridas no sistema. As novas interfaces têm por objetivo oferecer um ambiente visualmente mais agradável para os usuários além de permitir o acesso ao sistema por parte de usuários com diferentes perfis e níveis de acesso.

O restante desta seção está dividido da seguinte forma: a Seção 6.1 descreve os detalhes técnicos relacionados à funcionalidade de geração de gráficos que recentemente foi adicionada ao Smart Place; a Seção 6.2 descreve a integração do Smart Place com os sistema gerenciador de reservas de salas e laboratórios (Keys); a Seção 6.3 descreve um pouco sobre as novas interfaces gráficas que estão em fase de desenvolvimento quais serão e

sobre os diferentes perfis de usuários que terão acesso ao sistema; e, por fim, a Seção 6.4 faz uma discussão a respeito dos dados mensurados pelos sensores em um dos laboratórios, correlacionando-os entre si e mostrando como o sistema influencia para manter o laboratório dentro dos parâmetros de temperatura desejados.

6.1 Geração de gráficos A fim de permitir ao gerente das salas e laboratórios acompanhar a evolução dos

dados mensurados pelos sensores para melhor gerenciá-los, foi adicionada a Smart Place a funcionalidade de geração de gráficos. Os gráficos gerados pelo sistema mostram a evolução dos dados mensurados pelos sensores em um intervalo de tempo informado pelo usuário. Através dos gráficos, o usuário pode verificar, por exemplo, quando a sala/laboratório foi frequentada, se de fato a temperatura está sendo mantida dentro dos valores esperados quando existem pessoas na sala, etc. A Figura 6.1 mostra a interface gráfica por meio da qual o usuário pode especificar os dados que irão compor o gráfico.

Figura 6.1 - Interface gráfica utilizada para a geração de gráficos

Como é possível observar na imagem, para que o gráfico seja plotado é necessário que o usuário informe: (i) o prédio onde fica localizada a sala/laboratório; (ii) a sala ou laboratório onde estão localizados os sensores; (iii) quais tipos de dados serão plotados, tais como dados provenientes dos sensores de temperatura, presença ou umidade; (iv) o intervalo de tempo escolhido, entre 1 hora, 3 horas, 6 horas, 1 dia e 1 semana, e; (v) a data inicial, que indica o dia e horário a partir do qual os dados devem ser recuperados. A Figura 6.2 ilustra o gráfico que plota os dados de presença e temperatura da sala B318 durante um intervalo de tempo de três horas decorridos a partir do dia 16/01/2017 às 13h. Os valores dos dados de presença, true (quando é detectado algum movimento na sala) e false (quando nenhum movimento é detectado) são representados pelos valores 20 e 0, respectivamente, para

permitir a sua plotagem no gráfico junto com os demais dados.

Figura 6.2 - Gráfico contendo os dados de presença e temperatura

Os gráficos são gerados com o auxílio da biblioteca Primefaces3, uma biblioteca de código aberto para a linguagem de programação Java que provê um conjunto de componentes gráficos que podem ser utilizados por aplicações Web baseadas no framework JSF - JavaServer Faces. No Primefaces, as informações plotadas no gráfico são encapsuladas em um objeto do tipo LineModel que pode agregar diversos outros objetos do tipo ChartSeries, que, por sua vez, agrega os diversos pontos (tuplas <x, y>, em que x representa a data em que o valor foi medido pelo sensor e y representa o valor da medição) a serem plotados no gráfico. No gráfico da Figura 6.2 é possível observar que foram plotadas duas séries de dados distintas, temperatura e presença, para as quais os dados correspondentes foram recuperados do banco de dados levando-se em consideração os critérios de busca (tipo de dado, sala, intervalo de tempo, etc.) informados pelo usuário. Após recuperados, os dados de presença e temperatura foram inseridos em dois objetos do tipo ChartSeries distintos, cada um deles representando uma série de dados diferente. Os mesmos foram inseridos em um objeto do tipo LineModel que é utilizado pela biblioteca para plotagem do gráfico. Como a quantidade de pontos que pode ser plotada em um gráfico é limitada, um pré-processamento dos dados é realizado antes que os mesmos sejam plotados. O intuito do pré-processamento é agrupar os dados que foram aferidos em um intervalo de tempo próximo para que sejam plotados como um único ponto, diminuindo assim o subconjunto de pontos a serem plotados. Tomando como exemplo o gráfico da Figura 6.2, o intervalo de tempo 3 http://www.primefaces.org/

mínimo adotado entre dois pontos é de cinco minutos. Dessa forma, ao recuperar a lista os dados de temperatura aferidos pelos sensores, os mesmos foram agrupados em subconjuntos de dados, o primeiro subconjunto compreendendo os dados que foram aferidos entre às 13h e 13h05 e o segundo compreendendo os dados aferidos entre 13h05 e 13h10, e assim por diante. A média aritmética entre todos os dados de temperatura contidos em cada subconjunto é calculada e o valor resultante é plotado no gráfico como um único ponto. Para os dados de presença, que são representados por valores booleanos, o pré-processamento realizado acontece de forma semelhante. Os dados recuperados também são agrupados em subconjuntos de cinco minutos, dentre as medições contidas em cada subconjunto. Caso pelo menos uma delas possua o valor true, um valor inteiro e positivo (no caso 20) será plotado no gráfico, indicando que durante os cinco minutos compreendidos no intervalo em questão foi registrado algum movimento na sala. Caso nenhum dos valores compreendidos no intervalo indique a presença de movimento na sala, o valor zero será plotado no gráfico, indicando que naquele intervalo não foi registrado nenhum movimento na sala. Para os gráficos que mostram a evolução dos dados durante um período igual ou inferior a um dia, o intervalo de tempo adotado para a realização do pré-processamento dos dados é de cinco min, ou seja, os dados são recuperados e agrupados levando-se em consideração um intervalo de cinco min. Para os gráficos que mostram a evolução dos dados durante um período de uma semana esse intervalo de tempo é de 20 minutos.

6.2 Integração com o sistema de reservas A fim de melhor gerenciar os aparelhos de ar condicionado do IMD, o Smart Place

passou a consumir a API provida pelo sistema Keys, que gerencia o controle das reservas das salas disponíveis no prédio. O intuito da integração é evitar constantes ativações e desativações dos aparelhos de ar condicionado, pois além de desgastar o aparelho, constantes ativações e desativações acarretam em maior consumo de eletricidade. Dessa forma, antes de desativar um aparelho de ar condicionado de uma sala, o Smart Place realiza uma consulta a fim de verificar se existe uma reserva em um intervalo de tempo próximo para a sala em questão. Caso seja verificado que existe, o Smart Place pode optar por manter o aparelho ligado ao invés de desativá-lo e em seguida ativá-lo poucos minutos depois quando novas pessoas entrarem na sala.

A API provida pelo Keys segue o estilo REST e contém duas operações: ● GET http://testes.imd.ufrn.br/keys/services/reserva/todas

○ Esta operação permite recuperar os registros de todas as reservas existentes para todas as salas

● GET http://testes.imd.ufrn.br/keys/services/reserva/sala/<codigo da sala> ○ Esta operação permite recuperar todos os registros de reservas existentes para

determinada sala. Em ambos os casos, a resposta é composta por um array estruturado sob o formato

JSON contendo as informações referentes às reservas. A Figura 6.3 ilustra parte da resposta referente a consulta GET http://testes.imd.ufrn.br/keys/services/reserva/sala/B206. Como é possível observar, para cada uma das reservas o sistema Keys retorna as seguintes informações: Justificativa para a reserva da sala, título da reserva, data, horário de início da reserva, horário de fim da reserva, código da sala, tipo da sala reservada, responsável pela reserva, solicitante da reserva e, por fim, situação da reserva, que pode ser: pendente,

aprovada ou rejeitada. Figura 6.3 - Resposta do Keys a uma consulta acerca das reservas da sala B206

Como descrito no relatório anterior, o Smart Place possui um módulo denominado

Measurement BlackBoard, responsável por processar todas as informações oriundas dos sensores e com base nelas coordenar as ações dos atuadores que em resposta aos dados sensoriados irão realizar alguma ação sobre o ambiente (por exemplo, acionar/desativar um aparelho de ar condicionado). Além de processar os dados oriundos dos sensores no momento em que são recebidos pelo sistema, esse módulo também verifica constantemente (a cada 15 minutos) o registro dos dados de presença das salas gerenciadas a fim de desativar os aparelhos de ar condicionado caso seja verificado que foi decorrido um intervalo de tempo considerável sem a presença de pessoas na sala. Esse módulo foi alterado a fim de consumir a API provida pelo Keys para que as informações referentes às reservas das salas também

sejam consideradas nas tomadas de decisões do sistema. A Figura 6.4 ilustra um diagrama de atividades que descreve como são controlados os aparelhos de ar condicionado com base nos dados de presença recebidos pelo Smart Place e nos dados de reservas fornecidos pelo Keys.

Figura 6.4 - Controle dos aparelhos de ar condicionado

Ao receber um dado de presença, o Smart Place verifica inicialmente se o dado

indica a presença de pessoas na sala no momento e se o aparelho de ar condicionado está desativado. Caso essas duas afirmativas sejam verdadeiras, o sistema irá acionar os aparelhos de ar condicionado presentes na sala. Caso o dado indique que não existem pessoas no momento, o sistema irá verificar se foi registrada a presença de pessoas na sala nos últimos 15 minutos; caso seja verificado que não houve presença de pessoas na sala nos últimos 15 minutos e não existam reservas aprovadas para a sala em questão nos próximos 15 minutos, o aparelho de ar-condicionado será desativado. Desse modo, o sistema evita que o aparelho seja desativado e posteriormente ativado poucos minutos depois. No módulo Measurement BlackBoard as classes responsáveis por monitorar periodicamente os dados de presença das salas a fim de desativar os aparelhos de ar condicionado quando a sala não está sendo usada também foram alteradas a fim de utilizarem as informações referentes às reservas nos processos de tomada de decisões.

Conforme ilustra o diagrama de sequência da Figura 6.5, a thread MonitoreAirConditioner verifica a cada 15 minutos os dados de presença e reservas das salas gerenciadas. Inicialmente a thread recupera uma lista contendo todas as salas gerenciadas pelo sistema e, para cada uma delas, é verificado se houve o registro de presença de pessoas nos últimos 15 minutos e se existe registrada no Keys uma reserva com status aprovada, programada para os próximos 15 minutos. Caso essas duas afirmativas sejam falsas, um comando determinando a desativação dos aparelhos de ar condicionado da sala em questão será emitido.

Figura 6.5 - Interação entre o Keys e as classes responsáveis por monitorar os dados de presença nas salas

6.3 Criação das novas interfaces gráficas Conforme descrito no relatório anterior, a interface gráfica do Smart Place será

atualizada. O intuito é oferecer uma interface visualmente mais atraente para o usuário e permitir que usuários com diferentes perfis possam ter acesso ao sistema. Quanto aos perfis de usuários que existirão no sistema, serão dois, usuário comum e administrador, cada um com diferentes responsabilidades e diferentes níveis de acesso. No perfil de usuário comum estão compreendidas as pessoas que utilizam as salas/laboratórios para ministrar aulas, palestras, reuniões, estudo em grupo, estudo individual, etc. Professores, alunos ou outros funcionários da universidade que utilizam as salas ou laboratórios para algum fim podem ser

registrados no sistema com o perfil de usuário comum. Esse perfil de usuário poderá, através do sistema:

● Visualizar os recursos computacionais (quantidade de computadores, configuração de hardware dos computadores existentes, software instalado, etc.) em cada sala ou laboratório. Essa funcionalidade será útil, por exemplo, para os professores que antes de decidir ministrar uma aula poderão verificar se os recursos existentes na sala ou laboratório são suficientes para a turma.

● Solicitar a instalação ou manutenção de algum aparelho presente no laboratório. Por exemplo, será possível solicitar a manutenção de determinado computador, sensor ou atuador que esteja precisando de reparo ou que não esteja funcionando corretamente.

● Realizar o registro de suas informações pessoais, incluindo preferências de temperatura. Quando determinada sala estiver reservada para determinado usuário, a informação de preferência de temperatura do usuário será utilizada pelo sistema para manter a temperatura de acordo com as preferências do usuário em questão. A Figura 6.6 ilustra uma das telas as quais usuários com perfil de usuário comum

poderão ter acesso, através dessa tela o usuário poderá consultar os recursos computacionais presentes nas salas e laboratórios ou solicitar a manutenção de algum equipamento.

Figura 6.6 - Interface “Recursos do Laboratório”

Usuários com perfil de administrador são responsáveis pelo gerenciamento e manutenção dos recursos existentes nas salas e laboratórios. Esses usuários poderão:

● Visualizar todas as solicitações registradas no sistema, bem como atualizar o status de cada uma na medida em que as mesmas forem atendidas;

● Visualizar tabelas e gráficos que mostram o registro das medições dos sensores para cada sala, a fim de verificar se de fato os sensores instalados estão funcionando corretamente;

● Visualizar o histórico dos das ações (acionar, desativar, aumentar temperatura, diminuir temperatura) para cada um dos aparelhos de ar condicionado gerenciado pelo sistema;

● Visualizar, em tempo real, o status (ligado/desligado) das lâmpadas e aparelhos de ar condicionado gerenciados pelo sistema;

● Registrar, atualizar, remover registro de salas, sensores, atuadores, aparelhos de ar-condicionado, computadores e outros equipamentos existentes nas salas e laboratórios.

Para ter acesso ao sistema todos os usuários precisarão estar devidamente registrados

e logados. A Figura 6.7 mostra a interface por meio da qual os usuários poderão realizar o login no sistema. Após efetuar o login, o perfil do usuário será identificado pelo sistema e o mesmo será direcionado para a página inicial. A partir da página inicial o usuário poderá ter acesso à todas as funcionalidades permitidas para o seu perfil de usuário.

Figura 6.7 - Tela de Login

Após a conclusão da implementação das interfaces gráficas do sistema, elas

serão integradas com o back-end do Smart Place a fim de substituir as interfaces atuais. Também será implementado, no back-end do sistema, o código responsável por gerenciar a

autenticação e autorização dos usuários no sistema, a fim de garantir que somente usuários devidamente autenticados possam ter acesso ao mesmo e que os usuários só poderão acessar as telas permitidas para o seu perfil de usuário.

6.4 Análise dos dados dos sensores de presença, umidade e temperatura Para permitir o acompanhamento dados aferidos nas salas e laboratórios, foi

adicionada ao sistema a funcionalidade de geração de gráficos a partir dos dados mensurados pelos sensores. A partir dos gráficos é possível, por exemplo, identificar quando ocorreram mudanças significativas na temperatura e umidade nas salas ou laboratórios ou quando houve registro de presença de indivíduos.

Como foi explicado no relatório anterior, o sistema foi implantado para fins de testes e validação em um dos laboratórios do IMD. Analisando os gráficos que foram gerados a partir dos dados mensurados pelos sensores no laboratório, foi possível verificar que, após um certo período de tempo, quando o sensor de movimento não detecta presença no laboratório, a temperatura tende a aumentar assim como ela tende a diminuir quando a presença retorna a ser detectada na sala. Esse comportamento já era esperado, uma vez que o controle do aparelho de ar condicionado presente no laboratório é gerenciado pelo Smart Place com base nos dados aferidos pelos sensores de temperatura e umidade (DHT11 Sensor) e sensores de movimento (PIR Sensor). No laboratório, o controle dos dispositivos acontece da seguinte forma:

● Decorridos 15 minutos sem que nenhum movimento seja detectado pelo sensor de movimento, o ar condicionado recebe um comando para ser desligado;

● No momento em que o sensor de movimento detecta presença, caso o ar condicionado esteja desligado, o mesmo receberá um comando para ser acionado;

● O sistema foi configurado para manter o laboratório à temperatura de 23oC, quando o ar está ligado;

● Os dados de temperatura e umidade são enviados a cada cinco minutos; ● O sensor de movimento envia o dado true sempre que detecta um movimento e false

quando não há presença no local.

Na Figura 6.8, vê-se que entre os dias 06/12/2016 e 07/12/2016, nenhuma presença foi detectada após às 10h26, acarretando no desligamento do ar condicionado. Como consequência, temos o aumento da temperatura e umidade do laboratório. Esses dados podem ser vistos nas Figuras 6.9 e 6.10, que mostram elevados valores antes da presença ser detectada novamente no dia 07/12/2016 às 8h15. Após o sensor verificar movimento no laboratório, a temperatura começa a diminuir, convergindo para 23oC.

Figura 6.8 - Gráfico do sensor de presença

Figura 6.9 - Gráfico do sensor de presença e temperatura

Figura 6.10 - Gráfico do sensor de umidade

No dia 07/12/2016, é possível observar na Figura 6.11 que, após às 15h26, somente

às 17h19 foi detectada presença de indivíduos no laboratório. Como o período foi curto (apenas duas horas), a temperatura não variou muito. Esse resultado também é satisfatório pelo fato do laboratório se manter fechado quando não há indivíduos na sala.

Figura 6.11 - Gráfico do sensor de presença

Figura 6.12 - Gráfico do sensor de temperatura

Como última verificação dos dados, vê-se nas Figuras 6.13 a 6.15 que um valor false

foi enviado pelo sensor de presença às 21h35 do dia 12/12/2016 e um valor true às 8h21 do dia 13/12/2016. Esperava-se também que a temperatura estivesse alta antes das 8h20, o que pode ser verificado na Figura 6.15.

Figura 6.13 - Gráfico do sensor de presença e temperatura

Figura 6.14 - Gráfico do sensor de presença e temperatura

Figura 6.15 - Gráfico com os dados do sensor de umidade

As Figuras 6.16 e 6.17 servem como amostra de que os sensores (e consequentemente registro de seus dados) continuam a ser utilizados mesmo no período da não frequente utilização do laboratório.

Figura 6.16 - Gráfico do sensor de presença e temperatura

Figura 6.17 - Gráfico do sensor de umidade

7 Coletor Universal

O Coletor Universal é um software projetado de forma modular que possibilita realizar a coleta de dados em campo de diversos tipos de fontes de dados. Esse software faz parte da aplicação de monitoramento de energia que contempla ainda: (i) um hardware de medição de energia e comunicação GPRS, que está sendo desenvolvido nesse projeto no WP3 - Sensoriamento; (ii) BR-PlantHistorian, para processamento e armazenamento dos dados, e; (iii) BR-PlantViewer, para criação de dashboards, ambos os softwares de propriedade da UFRN e Petrobras.

No último trimestre foram realizadas as seguintes atividades: 1. Desenvolvimento de novas funcionalidades para melhorar o comissionamento

em campo via aplicação Android; 2. Acompanhamento da execução do sistema no laboratório LAR do prédio da

ECT - Escola de Ciência e Tecnologia.

7.1 Novas funcionalidades para comissionamento em campo Durante a operação do sistema de monitoramento de energia, foi identificada a

necessidade de desenvolvimento de novas funcionalidades no Coletor Universal, para que o operador tenha autonomia no comissionamento da ferramenta em campo. O Coletor Universal é um serviço executado em um Raspberry PI e nem sempre em campo será possível um monitor e teclado para acessá-lo e inspecionar o funcionamento da coleta de dados. Diante disso foram desenvolvidas novas funcionalidades disponibilizadas via Bluetooth: (i) Remover Tag, que permite remover/desabilitar a coleta de uma tag via ferramenta de comissionamento, e; (ii) ver dados da tag, que permite ver na ferramenta de comissionamento o último valor lido da tag.

A título de conhecimento, já haviam sido desenvolvidas as seguintes funcionalidades: ● Configurar servidor: permite informar ao Coletor Universal o IP, porta,

usuário e senha do BR-PlantHistorian. ● Listar servidor: possibilita visualizar os dados de configuração do servidor. ● Cadastrar fonte de coleta: permite cadastrar uma fonte de coleta, informando

o tipo da fonte se é OPC – Open Platform Communications ou Cidades_Inteligentes. Também são configurados em qual barramento e endereço o hardware de coleta está conectado ao Raspberry.

● Listar fontes de coleta: lista todas as fontes de coleta cadastradas.

● Cadastrar tag: permite realizar o cadastro de uma tag no Coletor Universal, automaticamente realizando o cadastro e configuração da tag no servidor que irá receber os dados.

● Log eventos: armazena eventos de erro ou alerta disponibilizados pelo Coletor Universal via Bluetooth. Por questões de limitação de hardware são armazenadas apenas os últimos cem eventos.

● Listar IP: informa os IPs do tipo IPv4 do Raspberry PI. Isso é importante para o agente de campo informar a um centro de comando o IP do Coletor Universal para que seja possível fazer um acesso remoto via SSH e realizar alguma vistoria necessária.

● Remover fonte de coleta: remove uma fonte de coleta cadastrada.

Todas as funcionalidades disponibilizadas via Bluetooth são consumidas pelo aplicativo Android desenvolvido no WP3 - Sensoriamento.

7.2 Implantação do sistema Para fins de testes, a aplicação foi implantada no laboratório LAR da ECT. O local

foi escolhido devido possuir painéis elétricos que facilitam a instalação do protótipo. O hardware de medição de energia desenvolvido no WP3 - Sensoriamento foi implantando no quadro de energia da sala e foi conectado a ele o Raspberry PI que possui o Coletor Universal, tornando assim a medição de energia inteligente. O Coletor Universal é responsável por requisitar os dados ao hardware de medição de energia e enviá-los para o BR-PlantHistorian, localizado no datacenter do IMD. O BR-PlantHistorian, por sua vez, irá processar, armazenar e disponibilizar os dados para outras aplicações. Esse ambiente é ilustrado no diagrama de implantação da Figura 7.1. O Apache Server foi inserido na implantação para filtrar o acesso ao BR-PlantViewer e ao BR-PlantHistorian de requisições externas à UFRN.

Figura 7.1 - Diagrama de implantação da medição de energia

A configuração de hardware do Raspberry PI utilizado na implantação foi:

Processador 4 núcleos de processamento modelo ARMv7

Memória RAM 948.016 KB

Disco aproximadamente 7 GB

Sistema Operacional Linux raspberrypi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux

7.3 Especificação dos conceitos e dos dashboards de monitoramento As variáveis disponibilizadas pelo hardware de medição de energia que são

armazenadas pelo BR-PlantHistorian são: ● Potência ativa: potência que efetivamente realiza trabalho gerando calor, luz,

movimento, etc. É medida em kW. ● Potência reativa: potência usada apenas para criar e manter os campos

eletromagnéticos das cargas indutivas. É medida em kvar. ● Potência aparente: também chamada de fator de potência, representa a relação entre

potência ativa e potência reativa. Indica a eficiência com a qual a energia está sendo usada.

● Tensão (Vrms): também chamado de tensão eficaz é a raiz do valor quadrático médio da tensão.

● Corrente (Irms): também chamado de corrente eficaz é raiz do valor quadrático médio da corrente.

● Frequência: frequência da harmônica. A variação da frequência indica diretamente a saúde da rede elétrica.

● Tensão de pico: é o maior valor instantâneo da tensão. ● Corrente de pico: é o maior valor instantâneo da tensão.

O usuário final deseja saber o consumo de energia, porém nenhuma dessas variáveis

fornece o consumo diretamente. Para extrair essa informação foi criada uma tag no BR-PlantHistorian chamada de “Consumo de energia - LAR - C&T” que realiza o cálculo da energia em função da Potência ativa. O consumo de energia é dado pela fórmula:

𝐸𝐸 = 𝑃𝑃 ∗ 𝛥𝛥𝛥𝛥 em que E = Energia, unidade de medida Joules. P = Potência, unidade de medida Watts. 𝛥𝛥𝛥𝛥 = Período de tempo, unidade de medida Segundos.

Contudo, o usuário final está familiarizado em ver o consumo de energia em kWh (Quilowatt-hora). Para isso é necessário realizar um outro cálculo envolvendo a energia (E), da seguinte forma:

� �� = �/3600 � ��� = � �� /1000

Com isso tem-se o consumo de energia em KWh. Esse consumo é armazenado na variável “Consumo de energia - LAR - C&T” que funciona como um medidor de energia convencional, no qual, o consumo vai sendo acumulado.

A Figura 7.2 mostra a configuração do cálculo da tag que representa o consumo de energia. As triggers adicionadas indicam quando o cálculo deve ser acionado. Neste caso o cálculo é ativado quando há uma mudança de valor na variável “ect1_lar_activeenergy”, que é a potência ativa. O script indica o cálculo a ser realizado, que implementa as fórmulas de consumo de energia com base na potência ativa medida e no período de tempo desde a última medição.

Figura 7.2 - Tela com a configuração da tag que calcula o consumo de energia

Após toda a configuração do processamento e armazenamento dos dados, foi o BR-

PlantViewer foi utilizado para a criação de um dashboard de monitoramento do consumo de

energia do laboratório LAR. Vale frisar que poderia ser utilizada qualquer outra aplicação, desde que implemente a API do BR-PlantHistorian.

O dashboard é mostrado na Figura 7.3. Nele são exibidas as informações de consumo acumulado (em kWh) e o valor gasto de energia, que consiste na multiplicação do consumo pela taxa de energia paga por kWh, considerando o valor da taxa como sendo R$ 0,55.

Figura 7.3 - Dashboard de monitoramento do consumo de energia

Foi adicionado a esse mesmo dashboard um outro gráfico que mostra o

comportamento da potência, como pode ser observado na Figura 7.4. Ao analisar o gráfico, observa-se que nas regiões destacadas em vermelho a potência é baixa, ou seja poucos equipamentos estão sendo utilizados. Isso ocorre por ser o período das 23h até às 07h em que não há alunos no laboratório. Já os períodos destacados em amarelo, a potência é alta e varia bastante, justamente por corresponder ao período das 07h às 23h, quando há a presença de alunos no laboratório.

Figura 7.4 - Gráfico do comportamento da potência ativa do laboratório

7.4 Acompanhamento do consumo de energia O monitoramento de energia está sendo executado no laboratório LAR da ECT desde

de 25/10/2016 até 23/01/2017 (91 dias). Nesse período ocorreram faltas de energia, mas mesmo assim o Coletor Universal conseguiu se recuperar e voltar a funcionar sem intervenção humana. Não foi coletado o histórico de uso de CPU e memória RAM, mas acredita-se que pelo longo período de tempo em execução a memória e o processamento permaneceram estáveis, pois se houvesse um vazamento de memória por menor que fosse teria causado a interrupção da coleta nesses 91 dias.

Na Figura 7.5 pode ser visto o consumo atual de energia do laboratório. Como pode ser observado, no dia 21/12/2016 ocorreu um grande crescimento do consumo.

Figura 7.5 - Dashboard com o consumo de energia em 23/01/2017

Diante do grande consumo ocorrido no dia 21/12/2016, foi feita uma análise dos

dados desse período a fim de identificar a causa do aumento do consumo. Foram analisadas a potência ativa, tensão e corrente, já que o consumo de energia é diretamente proporcional à potência ativa e a potência ativa é diretamente proporcional a tensão e corrente. Na Figura 7.6 é mostrado o gráfico de análise para o dia 21/12/2016, em que a potência ativa (série em azul) teve uma grande elevação por volta das 21h e continuou até o final do dia. Era esperado que ocorresse uma elevação similar na tensão (série em verde) e/ou na corrente (série em preto), o que não ocorreu. Pelos valores de pico de potência, que chegaram a 800.000 Watts e pelo não acompanhamento do aumento das variáveis de tensão e corrente, chegou-se à conclusão que ocorreu um erro de medição nesse período devido a alguma perturbação externa.

Figura 7.6 - Análise do alto consumo em 21/12/2016

7.5 Apresentação dos resultados aos gestores da UFRN No último trimestre, os resultados obtidos neste trabalho foram apresentados aos

gestores da UFRN a fim de obter um retorno sobre a utilidade da ferramenta. Os gestores demonstraram interesse na adoção da ferramenta para melhorar a gestão do consumo de energia na Universidade. Porém, foi consenso entre os gestores e o grupo de pesquisa que, para expandir o protótipo, desenvolver algoritmos preditivos de análise do consumo de energia, integração ao SIPAC - Sistema Integrado de Patrimônio, Administração e Contratos e implantação em toda a Universidade, é necessário investimento para que tais ações sejam viáveis. Todas essas ações seriam agrupadas em um sistema intitulado SIGEnergia que iria compor a família de sistemas SIG da UFRN.