universidade federal do rio grande do norte ... - imd...
TRANSCRIPT
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