Universidade Federal do Rio Grande do Norte

Instituto Metrópole Digital

SmartMetropolis – Plataformas e Aplicações para Cidades Inteligentes

WP3 – Sensoriamento

Entregável 04

Natal-RN, Brasil

Janeiro de 2017

Equipe Técnica

Docentes

Prof. Dr. Ivanovitch Medeiros Dantas da Silva (Coordenador) – Instituto Metrópole Digital

Prof. Dr. Allan de Medeiros Martins - Departamento de Engenharia Elétrica

Prof. MSc Antonio Wallace Antunes Soares - Instituto Metrópole Digital

Prof. MSc Eduardo Nogueira Cunha - Instituto Metrópole Digital

Prof. Dr. Gustavo Girão Barreto da Silva - Instituto Metrópole Digital

Prof. Dr. Julio Cesar Paulino de Melo - Instituto Metrópole Digital

Prof. MSc Wellington Silva de Souza - Instituto Metrópole Digital

Discentes

Ciro Martins Pinto

Danilo Mikael Costa Barros

Leonardo Augusto de Aquino Marques

Juliette de Paula Felipe de Oliveira

Sillas Samyr Silveira de Moura

Conteúdo

1 Introdução

1.1 Objetivos e Histórico das Ações

2. Medidos Trifásico de Energia

2.1 Placas Desenvolvidas

2.2 Código do Hardware Medidor Trifásico

3 Módulo de Comunicação

3.1 Breve histórico de desenvolvimento

3.2 Configuração do Dongle 3G no Raspberry Pi

3.3 Disponibilidade e confiabilidade

4. Ferramenta de comissionamento

5. Análise dos testes

6. Próximos passos

1 Introdução

1.1 Objetivos e Histórico das Ações

O grupo de trabalho WP-03, nomeado de Sensoriamento, surgiu com a necessidade de desenvolver

soluções de hardware e software embarcados para o Projeto Smart Metropolis. De acordo com o

planejamento do projeto, como descrito na Figura 1, a meta no primeiro ano de execução do WP-

03 está vinculado ao desenvolvimento de uma solução para o monitoramento de água e energia.

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

Os seis primeiros meses de execução dessa solução foram vinculados à descrição geral da

arquitetura de desenvolvimento, contendo propostas de entidades de hardware e software, protótipo

com hardwares não customizados, software de comissionamento e testes. Os resultados dessas

etapas foram descritos nos Relatórios 01 e 02. Adicionalmente, as atividades relacionadas com o

meses 7, 8 e 9 de execução do projeto foram focadas no projeto e prototipação do sensor de energia

monofásico, projeto da placa de comunicação e adicionamento de funcionalidades na ferramentada

de comissionamento. Os resultados foram descritos no Relatório 03.

Durante os meses 10, 11 e 12 de execução do projeto as seguintes atividades foram desenvolvidas:

● Acompanhamento na execução do módulo monofásico pelo período de 3 meses;

● Implementação de novas funcionalidades no módulo de comissionamento.

● Prototipação do hardware trifásico (alguns componentes não foram adquiridos);

● Definição do procedimento para calibração do chip ADE7758;

● Projeto do módulo de comunicação com a tecnologia 3G (adicional);

2. Medidos Trifásico de Energia

O hardware medidor trifásico de energia utiliza o CI ADE7758 da Analog Devices. O

ADE7758 é um CI de medição de energia elétrica trifásica de alta precisão e fornece dados através

de uma interface serial SPI. Ele incorpora Conversores Analógico/Digital Sigma-Delta (ADCs Σ-

Δ) de segunda ordem, um integrador digital, circuitos de referência, um sensor de temperatura e

todo o processamento de sinal necessário para realizar medições de energia ativa, reativa e aparente

e cálculos RMS. O CI é adequado para medir energia ativa, reativa e aparente em várias

configurações trifásicas, como WYE ou DELTA, com três e quatro fios. Também fornece recursos

de calibração do sistema para cada fase, ou seja, correção de offset, calibração de fase e calibração

de energia.

2.1 Placas Desenvolvidas

Para esta última versão das placas desenvolvidas, focamos em duas das quais iriam

trazer todo o retorno técnico e com um espaço bem reduzido, assim, podendo realizar sua instalação

em qualquer lugar.

A primeira placa (figura 2.1), trata-se de uma placa de testes para o ADE7758, onde

nela é inserido o ADE7758 e assim realizamos todos os testes e calibrações necessário com o chip,

quando o chip tem um resultado satisfatório e atende todos os requisitos, utilizamos este chip na

placa final. Esta placa se torna necessária devido a quantidade de chips que obtivemos que não

apresentaram o resultado correto e para fazer as calibrações e testes sem ser necessário estar em

campo ainda.

Figura 2.1. Placa 1 ADE7758 no software Eagle

A segunda placa (figura 2.2) é a placa final do medidor inteligente, pronta para aplicar

no local a ser medido e com todo sistema produzido totalmente integrado. Esta placa é um Shield

para o raspberry (figura 2.3 e figura 2.4), em que nela já tem o próprio ADE7758, o ATmega328P,

todo o circuito divisor de tensão necessário para receber as 3 tensões da rede e tbm entradas para

os sensores de corrente. Muitos dos componentes desta placa estão em SMD justamente para

reduzir o tamanho total dela, e como podemos ver na imagem abaixo, ela se encaixa perfeitamente

no Raspberry e aumenta poucos centímetros além dela, tornando assim o mais compacta possível.

Ela também pode ser ligada sem o Raspberry, de modo que ela já possui um microcontrolador

embutido. Nesta placa a alimentação é feita através do Raspberry, e o mesmo é alimentado com

uma fonte 5V 2A, porém se não for utilizado um raspberry, a alimentação pode ser feito através

dos pinos vcc e gnd presente na placa com os mesmos 5V. Esta placa também possui um sistema

de segurança com fusíveis na entrada de cada fase, e na placa pode ser inserido as fases através de

transformadores 220V-12V ou ligando a fase diretamente com apenas divisores resistivos, porém

neste caso se faz necessário que a fonte que alimenta o Raspberry ou todo o sistema seja isolada,

todo o sistema foi feito e testado com as fases ligadas através de transformadores, mas a ideia é

deixar no futuro apenas o divisor resistivo para deixar tudo mais compacto. Para eventuais trocas

de recebimento de tensão da fase, se faz necessário a substituição dos resistores through hole

presentes na placa, calculando como um simples divisor de tensão, para assim garantir 250mVpp

na entrada do ADE7758.

Figura 2.2. Placa 2 ADE7758 no software Eagle

Figura 2.3. Placa 2 prototipada e acoplada no Raspberry Pi 2 Modelo B

Figura 2.4. Shield Medidor Trifásico de Energia para Raspberry Pi 2 Modelo B

2.2 Código do Hardware Medidor Trifásico

O microcontrolador ATmega328P foi programado utilizando linguagem C++

para fazer a leitura dos dados e calibração do ADE7758 através de uma interface serial

SPI e para repassar os dados para o Controlador Central através da interface I²C.

2.2.1 Calibração do ADE7758

Existem duas formas de calibrar o ADE7758: a primeira forma usa um medidor

de referência e a segunda forma usa uma fonte precisa e o método de acumulação de

ciclo de linha (Line Cycle Accumulation Mode). Ao usar um medidor de referência, as

freqüências de saída de calibração dos registradores APCF e VARCF são ajustadas para

coincidir com a saída de freqüência do medidor de referência. Nesse caso, cada fase

deve ser calibrada separadamente. Ao utilizar uma fonte precisa para calibração, pode-

se tirar proveito do modo de acumulação de ciclo de linha e calibrar as três fases

simultaneamente. Devido à facilidade de se calibrar as três fases simultaneamente, foi

escolhido o modo da fonte precisa para fazer a calibração.

O ADE7758 possui registradores que devem ser inicializados com valores

específicos para possibilitar uma interpretação correta dos conteúdos lidos por ele. O

objetivo da calibração é encontrar esses valores que são capazes de relacionar a entrada

com a saída e, assim, obter uma relação do que é lido nos registradores com valores

energéticos reais, tensões e correntes, além, também, de eliminar erros de offset e fase.

A calibração inicialmente está sendo feita de forma manual. O programa

desenvolvido possui um menu que possibilita selecionar a calibração desejada (offset,

fase, etc) e setar os valores dos registradores de acordo com o que é calculado seguindo

as instruções contidas no Datasheet do ADE7758.

Primeiramente deve ser feita a calibração de offset VRMS e IRMS de todas as

fases, em seguida a calibração do ganho de todas as fases, e, por fim a calibração de

fase de todas as fases, como mostra o Fluxograma 1 abaixo.

Fluxograma 1. Calibração usando uma fonte precisa.

A calibração de Offset IRMS e VRMS é feita seguindo os seguintes passos:

primeiro é carregado o valor 0x38 no registrador LCYCMODE para setar os registros de

configuração de todas as fases para "zero-crossings". Depois é carregado o valor 0xE00

no registrador MASK para que o registrador interrupt mask seja definido para detecção

de "zero-crossing". Em seguida, o sistema de calibração é configurado para a condição

de teste 1 mostrada no "step 3" do Fluxograma 2. Depois disso, para obter leituras RMS

mais estáveis, os registradores RMS (xIRMS e xVRMS) são lidos 10 vezes após a

interrupção zero-crossing e é feita a média dos valores lidos. Os valores lidos nos

registradores xIRMS são usados na Equação 1 para o cálculo dos valores que serão

escritos nos registradores xIRMSOS e os valores lidos nos registradores xVRMS são

usados na Equação 2 para o cálculo dos valores que serão escritos nos registradores

xVRMSOS. O Fluxograma 2 abaixo ilustra o algoritmo necessário para a calibração de

Offset IRMS e VRMS de todas as fases.

Equação 1. Cálculo do xIRMSOS

Equação 2. Cálculo do xVRMSOS

Fluxograma 2. Calibração de Offset RMS

A calibração de ganho é feita seguindo o Fluxograma 3 abaixo: antes de iniciar

a calibração de ganho são escritos nos registradores APCFNUM/APCFDEN e

VARCFNUM/VARCFDEN seus respectivos valores de acordo com o Datasheet. Depois

disso, os registradores xWG, xVARG e xVAG são limpos. Em seguida, seleciona-se Fase

A, Fase B ou Fase C para uma medição de período de linha com os bits FREQSEL[1:0]

no registrador MMODE. Depois o ADE7758 é configurado para o mode de acumulação

de linha escrevendo 0xBF no registrador LCYCMODE. Isso habilita o modo de

acumulação de linha nos registradores xWATTHR, xVARHR e xVAHR e permite a

detecção de zero-crossing em todas as fases. Além disso, o bit FREQSEL, LCYCMODE

[7], é definido de modo que o registrador FREQ armazene o período de linha. Ao usar o

modo de acumulação de linha, o bit RSTREAD do registrador LCYCMODE deve ser

definido como 0 para desabilitar a leitura com modo reset. A fase para a medição do

período de linha é selecionada em MMODE[1:0]. Feito isso, o número de acumulação de

ciclos de meio período é escrito no registrador LINECYC. Então, o bit LENERGY,

MASK[12], é ajustado para habilitar a interrupção sinalizando o fim da acumulação de

ciclo de linha. Em seguida, é definido o sistema de teste e o fator de potência. A leitura

do registrador FREQ é lida se a frequência for desconhecida. Depois o registrador

RSTATUS é resetado e, então, é feita a leitura dos registradores xWATTHR e xVAHR

após a interrupção de LENERGY. Os valores lidos são usados nas Equações 3, 4, 5 e 6

para obtenção de valores que são escritos nos registradores xWG e nas equações 7 e 8

para obtenção dos valores que são escritos nos registradores xVAG.

Equação 3. Cálculo do WATTHR Esperado

Equação 4. Cálculo do AccumTime

Equação 5. Cálculo da Frequência de Linha

Equação 6. Cálculo do xWG

Equação 7. Cálculo do VAHR Esperado

Equação 8. Cálculo do xVAG

Depois de escrever os valores de xWG e xVAG. O sistema de teste é

configurado de acordo com o "step 11" do Fluxograma 3, o registrador FREQ é lido

novamente se a frequência não for conhecida e, então, os valores dos registradores

xVARHR são lidos depois da interrupção em LENERGY. Os valores lidos são usados

para calcular, usando as Equações 9 e 10, os valores dos registradores xVARG.

Equação 9. Cálculo do VARHR Esperado

Equação 10. Cálculo do xVARG

Por fim, são calculadas as constantes Wh/LSB, VAh/LSB e VARh/LSB de

acordo com as equações 11, 12 e 13.

Equação 11. Cálculo da Constante Wh/LSB

Equação 12. Cálculo da Constante VAh/LSB

Equação 13. Cálculo da Constante VARh/LSB

Fluxograma 3. Calibração de Ganho

Após a calibração de ganho, é feita a calibração de fase de acordo com o

Fluxograma 4: primeiro é feita novamente a configuração dos registradores LCYCMODE

e LINECYC do mesmo jeito que foi feita na calibração de ganho. Depois o sistema de

teste é configurado de acordo com o "Step 2" do Fluxograma 4. Então o registrador

RSTATUS é resetado e os registradores xWATTHR são lidos depois da interrupção

LENERGY para serem usados nas Equações 14, 15 e 16 para cálculo do valor dos

registradores xPHCAL.

Equação 14. Cálculo do xWHATTHR Error

Equação 15. Cálculo do Erro de Fase

Equação 16. Cálculo do xPHCAL

Fluxograma 4. Calibração de Fase

2.2.2 Aquisição dos Valores

Depois de calibrado, o ADE7758 fornece os valores lidos em cada fase sem

necessidade de cálculo extra. Os valores lidos nos registradores do ADE7758 são

repassados para o ATmega328P utilizando o protocolo de comunicação SPI sempre que

requisitados. As funções responsáveis pela requisição desses valores são:

● getVRMS(char PHASE): a função retorna o valor VRMS da fase passada como

argumento.

● getIRMS(char PHASE): a função retorna o valor IRMS da fase passada como

argumento.

● getWattHR(char PHASE): a função retorna o valor da Potência Ativa da fase

passada como argumento.

● getVARHR(char PHASE): a função retorna o valor da Potência Reativa da fase

passada como argumento.

● getVAHR(char PHASE): a função retorna o valor da Potência Aparente da fase

passada como argumento.

● getFrequency(char PHASE): a função retorna o valor da Frequência da fase

passada como argumento.

● getAll(): os valores VRMS, IRMS, das potências Ativa, Reativa e Aparente e da

Frequência de todas as fases são atualizados nas respectivas variáveis.

Os dados atualizados ficam armazenados nas variáveis e são repassados para

o Controlador Central via protocolo I²C sempre que requisitados.

2.2.3 Comunicação I²C Com o Controlador Central

2.2.3.1 Programação do protocolo I²C no Raspberry Pi

O Controlador Central é constituído por um Raspberry Pi 2 Modelo B. Esse

hardware controla toda a comunicação e, por isso, foi configurado como dispositivo

mestre do sistema. O Raspberry Pi terá o controle de todos os escravos conectados ao

barramento I²C. O programa mestre foi escrito em Java e, para isso, foi preciso instalar

algumas bibliotecas e realizar algumas configurações extras. Primeiramente foi

necessário habilitar o I²C para utilização do barramento no Raspberry Pi. Após o I²C ser

habilitado, foi preciso instalar a biblioteca WiringPi para dar acesso ao GPIO. A instalação

da biblioteca Pi4J foi também necessária para flexibilizar o desenvolvimento de Java na

Raspberry Pi.

2.2.3.1.1 API Java de comunicação I²C mestre

A biblioteca Pi4J é fruto de um projeto que tem por objetivo tornar mais

amigável implementações usando Java no Raspberry, ela usa internamente o WiringPi

para o acesso de baixo nível às entradas e saídas da GPIO e sua API possui um package

para comunicação usando o protocolo I²C.

A API Java escrita para a comunicação com o módulo central (dispositivo

mestre) utiliza as interfaces I2CBus e I2CDevice da Pi4J para criar o barramento de

comunicação, criar os dispositivos conectados a esse barramento e ter acesso a métodos

de leitura e escrita no barramento. Foram escritos métodos get para leitura dos dados

dos sensores. Para essa versão teremos os métodos responsáveis por pegar os valores

dos dados fornecidos pelo sensor de energia:

● getVrms(int phase): retorna o valor VRMS da fase passada como argumento do

sensor de energia conectado ao barramento I²C.

● getIrms(int phase): retorna o valor IRMS da fase passada como argumento do

sensor de energia conectado ao barramento I²C.

● getActiveEnergy(int phase): retorna o valor da Potência Ativa da fase passada

como argumento do sensor de energia conectado ao barramento I²C.

● getReactiveEnergy(int phase): retorna o valor da Potência Reativa da fase

passada como argumento do sensor de energia conectado ao barramento I²C.

● getApparentEnergy(int phase): retorna o valor da Potência Aparente da fase

passada como argumento do sensor de energia conectado ao barramento I²C.

● getFrequency(int phase): retorna o valor da Frequência da fase passada como

argumento do sensor de energia conectado ao barramento I²C.

Cada método utiliza um byte específico para se comunicar com o

ATmega328P (escravo) de acordo com a tabela abaixo:

Tabela 1. Bytes Comunicação I²C

Os métodos get enviam o byte para o dispositivo usando o método writeData()

e o dispositivo escravo, depois que recebe o byte de requisição, fica aguardando a

requisição de leitura (readData()) para enviar para o mestre o dado solicitado.

Além dos métodos get, há um método que escaneia o barramento em busca

de dispositivos conectados (i2cBusScanner()) e pode ser usado para saber se os

dispositivos estão conectados e prontos para comunicação.

2.2.3.2 Programação do protocolo I²C no ATmega328P

Para a comunicação I²C com o Raspberry foi utilizada a biblioteca Wire do

Arduino no modo escravo. O ATmega328P foi configurado com um endereço fixo (0x04)

e esse endereço é entendido pelo Raspberry Pi como endereço do sensor de energia.

Foram escritos dois métodos: um para receber dados e outro para enviar. O método

receber dados guarda o byte que indica qual dado o mestre está solicitando e o método

enviar dados envia dados requisitados pelo mestre. O mestre que decide quando a

comunicação vai iniciar e terminar e o ATmega328P fica apenas aguardando os

comandos no barramento.

3 Módulo de Comunicação

3.1 Breve histórico de desenvolvimento

O módulo de comunicação passou por várias modificações depois de sua

concepção inicial, por causa de mudanças no projeto e também devido a problemas

encontrados no decorrer do desenvolvimento. Inicialmente, o projeto previa a utilização

de microcontroladores para a gestão dos periféricos de comunicação possibilitando assim

a modificação do sistema de comunicação sem mudanças drásticas na Placa Integradora

de Sensores. Assim, optou-se, inicialmente, pelo módulo GPRS SIM-800L [6] (figura 1),

que pode ser interligado com microcontroladores que dispusessem de, ao menos, uma

porta serial com o protocolo UART.

Figura 3.1 Módulo GPRS SIM 800L

Com o desenvolvimento do projeto, optou-se por utilizar o Raspberry Pi, uma

plataforma como Placa Integradora de Sensores. Porém, pela falta de uma porta serial

disponível, houve a necessidade de utilizar um conversor USB-Serial, sendo projetado

um módulo (figura 3.2) com o objetivo de integrar o módulo GPRS, o conversor USB-

Serial e também a alimentação elétrica para ambos e independente do Raspberry Pi,

para não comprometer as suas portas USB’s.

Figura 3.2 Módulo GPRS SIM 800L.

Percebeu-se que, devido à utilização do Raspberry Pi, o módulo 3G era obrigado

a utilizar um conversor USB-Serial para conectar-se com o sistema, sendo assim uma

obrigatoriedade da placa integradora o protocolo USB. Por isso, resolveu-se utilizar um

Modem 3G comercial que funciona, na prática, de forma similar ao nosso módulo

desenvolvido tendo apenas o protocolo USB como requisito principal.

O Modem 3G escolhido, principalmente pelo baixo custo, foi o D-Link DWP 157 [1]

(figura 3.3), que pode ser encontrado comercialmente pelo valor de aproximadamente

R$50,00. Com o hardware escolhido, o próximo passo então, seria a configuração do

Raspberry Pi para que o mesmo possa usá-lo como conexão com a internet.

A configuração do Modem 3g se mostrou uma tarefa não trivial, pois foi encontrada

uma lista de dispositivos compatíveis com o Raspberry Pi[2], onde o modem não era

listado. No entanto, após as pesquisas iniciais, foram seguir alguns tutoriais e exemplos

de configurações, utilizando a libpppd[3] e wvdial[4] que mostraram resultados positivos.

Figura 3.3 Dongle 3G modelo D-Link DWP 157

3.2 Configuração do Dongle 3G no Raspberry Pi

Para a correta configuração do dongle 3G no Raspberry Pi com o sistema

operacional Raspbian instalado, foi necessário a instalação dos seguintes pacotes: ppp

e wvdial com os seguintes comandos.

● sudo apt-get install ppp

● sudo ape-get install wvdial

Em seguida, após a inserção do Modem 3G em uma das portas USB do Raspberry Pi,

checa-se se o Raspberry o reconheceu como um dispositivo serial, para isso, verificamos

se consta na lista de dispositivos conectados bastando o comando:

● ls /dev/tty*

Deve aparecer uma lista de dispositivos conectados, entre eles algo como “ttyUSBx”,

onde o ‘x’ é um valor numérico não negativo.

Para verificar se o Modem 3G está funcionando, foi preciso testar a comunicação

utilizando o protocolo AT. A verificação do modem deu-se através do software screen[5],

por ser um software que permite se comunicar com dispositivos conectados a portas

seriais, sejam elas portas físicas ou virtuais (utilizando-se as portas USB). Após a

instalação do screen a porta serial pode ser checada através do comando:

● screen /dev/PORTA 115200

Onde “PORTA” é a alguma das portas seriais onde o modem foi instalado, no caso

ttyUSB0. Após isto, foi inserido no terminal o comando “AT”, o dongle 3G deve responder

“OK”, caso contrário, outra porta deve ser experimentada.

Uma vez checado a conexão com o Modem 3G, foram criados dois arquivos, “wcdma” e

“wcdma-chat-connect” devidamente modificados com os dados da conexão, no diretório

/etc/ppp/peers/, em seguida é dado o comando para a conexão:

● sudo pppd defaultroute call wcdm

3.3 Disponibilidade e confiabilidade

Uma vez feita toda a configuração e testes de conexão, foi necessário configurar

o Raspberry Pi para que efetue automaticamente a conexão no momento do boot do

sistema. Para que isto aconteça, foi necessário, modificar o arquivo /etc/rc.local ,

inserindo logo após o comando de conexão logo após a última linha iniciada com “#”.

Dessa forma, o Raspberry irá se conectar via 3G sempre que o dongle 3G estiver

conectado em uma das portas USB.

Na possibilidade de o dongle 3G não ser reconhecido ou não operar corretamente,

pode ser possível que o Raspberry Pi não esteja fornecendo corrente necessária pela

porta USB. Segundo a documentação do Raspberry Pi 2, cada porta USB pode fornecer

com segurança até 100mA de corrente, sendo que não há garantias para dispositivos

que consumam correntes maiores. Como não foi encontrado material que informe a

corrente consumida ou potência do Modem 3G escolhido, pode ser necessário a

utilização de uma fonte de energia externa. Essa fonte pode ser de um Hub USB

comercial ou um cabo como o mostrado na figura 3.4. A fonte utilizada deve fornecer 5

volts com uma corrente compatível com o Modem 3G, de preferência acima de 1 ampere

(é desejável 2 amperes).

Figura 3.4. Esquema para alimentação externa da Raspberry Pi.

4. Ferramenta de comissionamento

A ferramenta de comissionamento, que tem como objetivo principal, configurar a placa

integradora e, além disso, fazer o monitoramento em tempo real, foi completamente desenvolvida.

Para esta parte do projeto, os principais objetivos eram: adição da funcionalidade de remover tag e

o monitoramento de dados em tempo real no aplicativo. Abaixo estão todas as definições que são

importantes para que o usuário compreenda e saiba como utilizar a ferramenta.

4.1 Definições

● Coletor - O Coletor presenta a placa integradora, ou seja, aquele a quem a ferramenta de

comissionamento se comunica via o protocolo de comunicação IEEE 802.15.1 (Bluetooth).

Cada coletor possui um nome de identificação e escolha do coletor também é feita durante

o uso da aplicação, pois pode-se haver mais de um coletor disponível na área.

● Nuvem - Lugar para onde as informações são salvas (servidor), durante o uso da ferramenta

e após a escolha do Coletor, comissionar a nuvem é o primeiro passo. Cadastrar uma Nuvem

é obrigatório, portanto, assim que se inicia a aplicação pela primeira vez, a tela de

configuração da Nuvem é mostrada para que o usuário possa adicionar as informações

necessárias, tais como IP e porta do servidor.

● Fonte de Coleta - é um grupo criado pelo usuário onde ele pode cadastrar sensores (tags)

para que a placa integradora possa coletar os dados. O monitoramento desses dados pode

ser visto em tempo real no aplicativo. As Fontes de Coleta tem como informações

necessárias: um nome (dado pelo usuário), um identificador (dado pelo usuário, serve para

representar a fonte em específico) e o tipo da fonte (este, o usuário irá selecionar alguma

opção que esteja disponível).

● Tags - As Tags representam os sensores que são adicionados na placa integradora, tais como

sensor de água e energia. Estes são cadastrados e organizados nas Fontes de Coleta. Para

cada Tag, é necessário adicionar um nome para sua identificação (dado pelo usuário) e o

tipo, NUMERIC ou TEXT.

● Eventos - Os eventos são todos os alertas, erros e informações que são enviadas para a

aplicação. Desta forma, o usuário poderá acompanhar tudo que acontece durante o uso da

ferramenta de comissionamento, assim como, ajudar a identificar algum possível problema.

4.2 Funcionalidades

Aqui estão listadas todas as funcionalidades disponíveis na aplicação e uma breve descrição

sobre cada uma delas.

● Escolher Coletor - esta função permite que o usuário possa selecionar em qual Coletor será

feito o comissionamento.

● Adicionar Nuvem - esta função permite cadastrar uma Nuvem.

● Editar Nuvem - esta função permite editar uma Nuvem já cadastrada.

● Listar IP - esta função mostra o IP da placa integradora.

● Adicionar Fonte de Coleta - esta função permite que o usuário possa adicionar uma Fonte

de Coleta.

● Editar Fonte de Coleta - esta função permite Editar uma Fonte de Coleta já cadastrada.

● Remover Fonte de Coleta - esta função permite excluir uma Fonte de Coleta já cadastrada.

● Adicionar Tag - esta função permite adicionar uma Tag a uma Fonte de Coleta.

● Listar todos os Eventos - esta função permite ver todos os eventos já ocorridos.

● Listar últimos Eventos - esta função permite ver apenas os 10 (dez) últimos eventos

ocorridos.

● Ver Tags de uma Fonte de Coleta - esta função permite listar todas as Tags referentes a

Fonte de Coleta selecionada.

● Remover Tag (Nova funcionalidade) - esta função permite excluir uma Tag já cadastrada.

● Monitorar Tag (Nova funcionalidade) - esta função permite acompanhar os dados da Tag

que estão sendo coletados em tempo real.

Durante a implementação das novas funcionalidades, ajustes da forma de interação entre o

usuário e a aplicação se mostraram necessários, pois a ferramenta de comissionamento tem como

objetivo, também, ser o mais intuitivo possível para o que o usuário possa explorar ao máximo a

ferramenta com o mínimo de orientação. Os ajustes feitos foram na parte das Tags, agora o usuário

poderá monitorar a tag com um clique rápido sobre ela, e para removê-la basta que pressione-a por

um tempo até que a opção apareça. As figura 4.1 e 4.2 descrevem tais funcionalidades,

respectivamente.

Figura 4.1. Monitorando Tags.

Figura 4.2. Removendo Tags.

A ferramenta de comissionamento, após finalizada a adição das novas funcionalidades,

passou por diversos testes e alguns problemas foram encontrados, tais como não atualização das

tags após a remoção e problemas na adição de Fonte de Coleta. Todos os bugs e erros encontrados

foram solucionados, mas a necessidade de mais testes e validações sempre são bem-vindas e

necessárias. Desta forma, conclui-se que a ferramenta de comissionamento atendeu as demandas e

expectativas e está pronta para o uso em ambiente real, com o objetivo de executar mais testes para

garantir seu funcionamento e cumprir seu papel de comissionar a placa integradora de

sensoriamento.

5. Análise de funcionamento

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

25/10/2016 até 23/01/2017, que corresponde a 91 dias. Nesse período ocorreram faltas

de energia mas mesmo assim o hardware e o sistema embarcado 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 acreditamos que pelo longo período de tempo em execução a

memória e o processamento permaneceram estáveis, pois se tivesse um vazamento de

memória por menor que seja teria causado a interrupção da coleta nesses 91 dias.

Na Figura 5.1 pode ser visto o consumo atual de energia do laboratório. Como pode ser

observado no dia 21 de dezembro de 2016 ocorreu um grande crescimento do consumo.

Figura 6.1. Dashboard com o consumo de energia em 23/01/2017.

Diante do grande consumo ocorrido no dia 21/12/2016 foi feito uma análise dos dados desse

período a fim de identificar a causa do aumento do consumo. Foi analisado a potência ativa, tensão

e corrente, já que o consumo de energia é diretamente proporcional a potência ativa e a potência

ativa é diretamente proporcional a tensão e corrente. Na Figura 5.2 é mostrado o gráfico de análise

para o dia 21/12/2016. Como pode ser visto a potência ativa (série em azul) teve uma grande

elevação por volta das 21:00 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, chegamos a conclusão que ocorreu um erro de medição

nesse período devido a alguma perturbação externa. Diante disso está sendo feito uma análise para

descobrir as causas porém sabe-se que alguns equipamentos foram ligados no laboratório no

período.

Figura 5.2. Análise do alto consumo em 21/12/2016.

6. Próximos passos

Orginalmente, o último semestre de execucação do projeto seria focado exclusivamente para a fase

de testes e modificações elencadas nas etapas anteriores. Devido a aceleração da implementação

na fase anterior, houve uma abertura de janela onde foi dado ênfase ao projeto do módulo de

sensoriamento trifásico. A implementação será realizada em etapas futuras do projeto haja vista

que não foi possível adquirir os componentes para o teste da placa prototipada. Todavia, o projeto

da placa foi entregue com sucesso, faltando a soldagem dos componentes no PCB e os possíveis

testes em campo. Em fases posteriores será dado também os testes no módulo de comunicação

utilizando tecnologias 3G.

De uma maneira geral, os testes realizados durante o período de 91 dias foi êxitoso. O hardware se

comportou a contento. Durante o período houve falta de energia e foi observado que o sistema

como um todo conseguiu automaticamente retornar ao estado operacional. Adicionalmente, a

ferramenta de comissionamento demonstrou sua aplicabilidade durante a configuração do módulo

de hardware e para análise de funcionamento em tempo real no local da instalação do teste.

O grupo considera que a iniciativa desenvolvida durante os 12 meses foi um sucesso. Os próximos

passos do projeto são focados diretamente na prototipação em larga escala dos hardwares

desenvolvidos e a integração dos módulos de software com os Sistemas Sigs da UFRN. Tais passos

dependem de um orçamento compatível com a compra dos equipamentos de hardware e

financiamento de pessoal para o desenvolvimento dos softwares. Em relação a disseminação do

conhecimento, o grupo pretende submeter um artigo de periódico sobre as ações desenvolvidas e

duas patentes sobre as placas desenvolvidas.

Referências:

[1] D-Link Dongle 3G, Expecificações. Disponível em: <https://dlink.com.br/produto/dwm-

157>. Acesso em 13 de janeiro de 2017

[2] RPi VerifiedPeripherals. Disponível em

<http://elinux.org/RPi_VerifiedPeripherals#USB_3G_Dongles>. Acesso em 10 de janeiro de

2017.

[3] Point to Point Protocol Daemon – PPPD, Disponível online em

https://linux.die.net/man/8/pppd,. Último acesso em 26 de janeiro de 2017.

[4] PPP Dialer with built in inteligence – wvdial, disponível online em

https://linux.die.net/man/1/wvdial. Último acesso em 26 de janeiro de 2017.

[5] Screen, Um Pouco Sobre o Screen. Disponível em: https://www.vivaolinux.com.br/dica/Um-

pouco-sobre-o-screen. Acesso em 10 de dezembro de 2016.

[6] Sim800L. Disponível em: <http://simcomm2m.com/En/module/detail.aspx?id=138> Acesso

em 5 de dezembro de 2016.

ANEXOS

Conteúdo do arquivo “wcdma”

#/etc/ppp/peers/cdma

# This is pppd script for China liantong

# Usage: root>pppd call cdma

hide-password

noauth

connect '/config/chat -s -v -f /etc/ppp/peers/wcdma-chat-connect'

disconnect '/config/chat -s -v -f /etc/ppp/peers/wcdma-chat-disconnect'

debug

/dev/ttyUSB0 < porta onde o dongle 3G está conectado

115200

defaultroute

noipdefault

novj

novjccomp

noccp

ipcp-accept-local

ipcp-accept-remote

local

#lock

dump

nodetach

user "" < inserir o usuário da conexão ou deixar em branco

password "" < inserir a senha para a conexão ou deixar em branco

crtscts

remotename 3gppp

ipparam 3gppp

usepeerdns

Conteúdo do arquivo “wcdma-chat-connect”

ABORT "BUSY"

ABORT "NO CARRIER"

ABORT "NO DIALTONE"

ABORT "ERROR"

ABORT "NO ANSWER"

TIMEOUT 120

"" AT

OK ATZ

OK AT+CFUN=1

OK AT+CGDCONT=1,"IP","INSERIR_APN",,0,0

OK AT

OK ATDT*99***1#

CONNECT \d\c