Sistema embarcado para a coleta de dados de geração fotovoltaica para Campus Inteligente

(1)

VITOR OLIVEIRA MORAES

SISTEMA EMBARCADO PARA A COLETA DE DADOS DE GERAÇÃO FOTOVOLTAICA PARA CAMPUS INTELIGENTE

Sorocaba 2023

(2)

SISTEMA EMBARCADO PARA A COLETA DE DADOS DE GERAÇÃO FOTOVOLTAICA PARA CAMPUS INTELIGENTE

Trabalho de Conclusão de Curso apresentado ao Instituto de Ciência e Tecnologia de Sorocaba, Universidade Estadual Paulista (UNESP), como parte dos requisitos para obtenção do grau de Bacharel em Engenharia de Controle e Automação

Orientador:

Prof. Dr. Eduardo Paciência Godoy

Sorocaba 2023

(3)

Sistema de geração automática de fichas catalográficas da Unesp. Biblioteca do Instituto de Ciência e Tecnologia, Sorocaba. Dados fornecidos pelo autor(a).

Essa ficha não pode ser modificada.

M827s

Moraes, Vitor Oliveira

Sistema Embarcado para a Coleta de Dados de Geração Fotovoltaica para Campus Inteligente / Vitor Oliveira Moraes. -- Sorocaba, 2023

77 p. : tabs., fotos

Trabalho de conclusão de curso (Bacharelado - Engenharia de Controle e Automação) - Universidade Estadual Paulista (Unesp), Instituto de Ciência e Tecnologia, Sorocaba

Orientador: Eduardo Paciência Godoy

1. Internet das Coisas. 2. Automação. 3. Tecnologia da Informação.

I. Título.

(4)

SISTEMA EMBARCADO PARA A COLETA DE DADOS DE GERAÇÃO FOTOVOLTAICA PARA CAMPUS INTELIGENTE

BANCA EXAMINADORA:

Prof. Dr. EDUARDO PACIENCIA GODOY Orientador / UNESP - Campus de Sorocaba

Prof. Dr. Luis Armando de Oro Arenas UNESP - Campus de Sorocaba

Eng. Bruno Oliveira Zarpellon UNESP - Campus de Sorocaba

Janeiro de 2023

ESTE TRABALHO DE GRADUAÇÃO FOI JULGADO ADEQUADO COMO PARTE DO REQUISITO PARA A OBTENÇÃO DO GRAU DE

BACHAREL EM ENGENHARIA DE CONTROLE E AUTOMAÇÃO

Prof. Dr. Everson Martins Coordenador

(5)

dedicado ao meu avô Moacir, que me ensinou gentileza, paciência e razão.

(6)

Agradeço minha mãe Cláudia Soares, meu pai Samuel Moraes, meu irmão Pedro Moraes, minha avó Santa Moraes e meu avô Moacir Feltrin pelos ensinamentos e incentivos dados nos períodos que antecederam minha escolha de graduação. Hoje tenho certeza de que escolhi o curso certo para mim e dedico essa grande vitória a vocês. Agradeço minha namorada Ana Carolina por todo apoio emocional, felicidades e ao crescimento compartilhado durante todo o período. Não poderia ter sido incrível do jeito que foi sem você. Agradeço aos irmãos que fiz ao longo da minha trajetória no campus e morando na república HM, principalmente aos ilustres Natan Beraldi, Mateus Costa, Nilson Neves, Breno Galendi e Matheus de Paula. Vocês sempre terão um espaço na minha história e nas minhas conquistas. Agradeço ao professor Eduardo Paciencia pelas disciplinas ministradas com maestria e por todo o auxílio ao longo do projeto desenvolvido durante este trabalho. Sua atenção e disponibilidade para orientar as questões enfrentadas foram primordiais para os resultados que foram obtidos. Por fim, agradeço a instituição UNESP e aos seus técnicos pela oportunidade e suporte. Meu desenvolvimento como profissional e individuo da comunidade foi inspirado por vocês.

(7)

de Ciência e Tecnologia de Sorocaba, UNESP - Universidade Estadual Paulista, Sorocaba, 2022.

RESUMO

Ao longo das últimas décadas, a obtenção de dados e tomada de decisões baseada em suas análises vem se tornando mais presente, tornando conceitos como a Internet das Coisas (Internet of Things ou IoT) mais relevantes. Define-se a IoT como o análogo a internet das pessoas, onde entendia-se que as pessoas trocavam informações e tomavam decisões, agora os dispositivos e máquinas tomam esse papel. Campus inteligentes (smart campus) são aqueles que possibilitam a interação entre o digital e o espaço real por meio de variados recursos tecnológicos como a IoT.

Os diversos dispositivos utilizando IoT facilitam a vida da comunidade que convive no ambiente acadêmico, proporcionando aprendizado e interações dentro dos processos presentes, de forma moderna e sustentável. No entanto, sua implantação demanda esforços de tempo e recursos, os quais podem ser reduzidos pela adoção de soluções de software e hardware open source e desenvolvimento através de trabalhos acadêmicos. Dessa forma, buscando-se agregar ao ambiente do campus da UNESP de Sorocaba, este trabalho implementou um sistema embarcado para a coleta de dados de um sistema de geração fotovoltaica integrado à arquitetura IoT existente. O desenvolvimento do projeto foi baseado no uso de um computador de placa única (Raspberry Pi Zero W 2) conectado ao inversor fotovoltaico (HUAWEI SUN2000) para obtenção dos dados do sistema de geração solar. Os dados são recebidos do inversor via protocolo Modbus RTU e são enviados via comunicação sem fio por meio do protocolo MQTT à arquitetura IoT do campus inteligente. Para visualização e disponibilização dos dados à comunidade, telas de interface web interativa (dashboards) foram desenvolvidas e adicionadas ao website do campus inteligente. Além do acesso aos dados, a solução também é capaz de notificar problemas operacionais, como alertas de mal funcionamento.

Palavras-chave: Internet das Coisas, Inversor Fotovoltaico, Modbus RTU, MQTT.

(8)

Technology of Sorocaba, UNESP - Universidade Estadual Paulista, Sorocaba, 2022.

ABSTRACT

Over the last few decades, obtaining data and making decisions based on analysis has become more typical, making concepts such as the Internet of Things (IoT) more relevant. Internet of things is defined as the analogue of the people's internet, where it was understood that people exchanged information and made decisions, now devices and machines take this role. Smart campuses are those that enable interaction between digital and real space through various technological resources such as IoT. The various devices using IoT facilitate the life of the community that lives in the academic environment, providing learning and interactions within the present processes, in a modern and sustainable way. However, its implementation demands time and resources efforts, which can be reduced by the adoption of open-source software and hardware solutions and development through academic work. Thus, seeking to add to the environment of the campus of UNESP in Sorocaba, this work implemented an embedded system for collecting data from a photovoltaic generation system integrated with the existing IoT architecture. The development of the project was based on the use of a single board computer (Raspberry Pi Zero W 2) connected to the photovoltaic inverter (HUAWEI SUN2000) to obtain data from the solar generation system. Data is received from the inverter via Modbus RTU protocol and is sent via wireless communication via MQTT protocol to the smart campus IoT architecture. For viewing and making data available to the community, interactive web interface screens (dashboards) were developed and added to the smart campus website. In addition to data access, the solution is also capable of notifying operational problems, such as malfunction alerts.

Keywords: Internet of things. Photovoltaic Inverter, Modbus RTU, MQTT.

(9)

Figura 1 - Estimativa de crescimento dos dispositivos conectados a internet no globo ... 16

Figura 2 - Representação de aplicações nas cidades inteligentes ... 17

Figura 3 - Sistema de monitoramento do smart campus da UNICAMP ... 17

Figura 4 - Sistema de reconhecimento da dimensão da fila do restaurante por aprendizado de máquina na UNICAMP... 18

Figura 5 - Diagrama de dispositivos interagindo na Internet das Coisas ... 20

Figura 6 - Exemplo de topologia de subdomínios para a implantação de um smart campus ... 23

Figura 7 - Exemplo de aplicação que contém sistemas embarcados ... 24

Figura 8 - Exemplos de aplicações contendo sistemas embarcados em suas composições ... 24

Figura 9 - Fluxo de funcionamento do protocolo de comunicação MQTT ... 25

Figura 10 - Inversor Huawei SUN2000 utilizado no projeto ... 27

Figura 11 - Conjunto de placas solares do sistema fotovoltaico do Bloco D da UNESP de Sorocaba ... 27

Figura 12 - Subdivisão das informações contidas no nome do inversor do projeto ... 28

Figura 13 - Portas para as possíveis conexões diretas com o inversor ... 29

Figura 14 - Aplicativo indicado pela fabricante para a consulta e configuração do inversor do projeto ... 30

Figura 15 - Configurações presentes no aplicativo do inversor no que se refere a transmissão dos dados pela porta COM ... 30

Figura 16 - Estrutura já presente no inversor para a coleta de informações pela CPFL ... 31

Figura 17 - Conector do tipo COM para a obtenção dos dados do inversor do projeto ... 31

Figura 18 - Diagrama da topologia pensada para a aplicação ... 34

Figura 19 - Raspberry Pi Zero W 2 ... 35

Figura 20 - Módulo Conversor de USB Para Serial RS485... 35

Figura 21 - Estrutura pensada para o hardware da solução do projeto ... 36

Figura 22 - Diagrama de fluxo simplificado do funcionamento do código implementado ... 38

Figura 23 - Estrutura de pastas e arquivos para o software da solução implementada ... 39

Figura 24 - Conteúdo presente nos arquivos docker-compose.yml.example e docker-compose.yml ... 41

Figura 25 - Conteúdo presente no arquivo Dockerfile... 41

Figura 26 - Conteúdo presente no arquivo requirements.txt ... 42

Figura 27 - Importações feitas para o arquivo main.py ... 42

Figura 28 - Constantes definidas para o arquivo main.py ... 43

Figura 29 - Informações puxadas das variáveis de ambientes para o arquivo main.py ... 43

Figura 30 - Principal rotina do código implementado presente no arquivo main.py ... 43

Figura 31 - Função que realiza a obtenção e envio das variáveis imediatas e calculadas pelo inversor. ... 44

Figura 32 - Função que retorna ou valores simbólicos para testes ou valores reais do inversor .. 45

(10)

Figura 34 - Função que realiza o envio no cliente MQTT com a conexão estabelecida ... 45

Figura 35 - Importações feitas para o arquivo mqtt.py ... 46

Figura 36 - Variáveis de ambientes utilizadas pelo arquivo mqtt.py ... 46

Figura 37 - Função para puxar o estabelecimento de conexão com o broker mqtt ... 46

Figura 38 - Função que realiza a conexão com o broker mqtt ... 46

Figura 39 - Função que retorna se a conexão com o broker mqtt foi um sucesso ou não ... 47

Figura 40 - Exemplo de formato em que os dados são percebidos pelo Grafana ... 49

Figura 41 - Exemplo de consulta utilizada como padrão para a obtenção dos dados no Grafana 49 Figura 42 - Exemplo de possíveis visualizações que poderia ser utilizada no Grafana para os dados obtidos ... 49

Figura 43 - Exemplo de código HTML e CSS utilizado para garantir a responsividade em diferentes telas ... 50

Figura 44 - Código utilizado para resolver a questão do caso de energia coletada no dia ... 51

Figura 45 - Código utilizado para resolver a questão do caso de energia coletada por dia do último mês até a data atual ... 52

Figura 46 - Código utilizado para resolver a questão do caso de energia coletada por mês do último ano ... 52

Figura 47 - Acompanhamento do alerta criado para o projeto no Grafana ... 53

Figura 48 - Forma que o Grafana sabe se o projeto está com algum problema ... 53

Figura 49 - Frequência com a qual o Grafana avalia o estado do projeto ... 54

Figura 50 - Resultado visual de como ficou a instalação do sistema embarcado no inversor ... 55

Figura 51 - Apresentação do projeto na tela principal ... 57

Figura 52 - Foto das placas solares, energia acumulada ao longo de certos períodos e último recebimento dos dados ... 58

Figura 53 - Dados instantâneos escolhidos para a tela principal ... 58

Figura 54 - Gráfico da energia acumulada hoje ao longo do tempo na tela histórica... 59

Figura 55 - Outros gráficos de energia ao longo do tempo, cada qual em seu período fixo ... 59

Figura 56 - Gráfico de energia coletada que varia conforme a configuração global da página do Grafana ... 60

Figura 57 - Gráficos de tensão, de corrente, potência ativa e reativa ao longo do tempo ... 60

Figura 58 - Gráficos de temperatura interna e eficiência do inversor ao longo do tempo ... 60

Figura 59 - Painel visto de um dispositivo mobile ... 62

(11)

Tabela 1 - Tipos de informações e descrições para o inversor do projeto referentes ao seu nome ... 28 Tabela 2 - Definições e funções das portas utilizadas pelo cabo adaptado presente no inversor do projeto ... 32 Tabela 3 – Exemplos de informações transmitidas por MODBUS pelo inversor do projeto ... 32 Tabela 4 - Funções dos arquivos presentes no software da aplicação do projeto ... 39

(12)

Quadro 1 - Características do Campus Digital e do Campus Inteligente ... 22 Quadro 2 - Tecnologias para o desenvolvimento do código ... 37 Quadro 3 - Resultados em relação ao software implementado ... 56

(13)

M2M - Machine to Machine IoT - Internet of Things

MQTT - MQ Telemetry Transport RFID - Radio-Frequency Identification IP - Internet Protocol

UNICAMP - Universidade Estadual de Campinas UNESP - Universidade Estadual Paulista

ICTS - Instituto de Ciência e Tecnologia - Câmpus de Sorocaba WLAN - Wireless Local Area Network

CPFL - Companhia Sul Paulista de Energia Wi-Fi - Wireless Fidelity

CPU - Central Processing Unit

SDRAM - Synchronous Dynamic Random Access Memory LAN - Local Area Network

BLE - Bluetooth Low Energy JSON - JavaScript Object Notation HTML - HyperText Markup Language CSS - Cascading Style Sheet

(14)

1. INTRODUÇÃO ... 16

1.1.JUSTIFICATIVA ... 16

1.2.OBJETIVOS ... 19

1.3.ORGANIZAÇÃO DESTE TRABALHO ... 19

2. REFERENCIAL TEÓRICO ... 20

2.1.INTERNET DAS COISAS (IOT) ... 20

2.2.SMART CAMPUS ... 21

2.3.SISTEMAS EMBARCADOS ... 23

2.4.PROTOCOLO MQTT ... 25

3. SISTEMA DE GERAÇÃO FOTOVOLTAICA ... 27

3.1.LOCALIZAÇÃO E CARACTERÍSTICAS GERAIS ... 27

3.1.COMUNICAÇÃO DOS DADOS ... 29

3.3.INFORMAÇÕES TRANSMITIDAS ... 32

4. DESENVOLVIMENTO DO SISTEMA EMBARCADO... 34

4.1.ABORDAGEM ... 34

4.2.SISTEMA EMBARCADO ... 34

4.3.DESENVOLVIMENTO DE SOFTWARE ... 36

4.3.1. Fluxo de funcionamento adotado para o código ... 37

4.3.2. Estrutura de pastas e arquivos ... 38

4.3.3. Arquivos docker-compose.yml.example e docker-compose.yml ... 40

4.3.4. Arquivo Dockerfile ... 41

4.3.5. Arquivo requiriments.txt ... 42

4.3.6. Arquivo main.py ... 42

4.3.7. Arquivo mqtt.py ... 46

5. INTERFACE WEB DE VISUALIZAÇÃO ... 47

5.1.PRINCÍPIOS BÁSICOS PARA AS VISUALIZAÇÕES DOS DADOS ... 48

5.2.CASOS ESPECIAIS OBTIDOS ... 50

5.3.CONFIGURAÇÃO DE AVISO CASO O SISTEMA PARE DE ENVIAR DADOS ... 52

6. RESULTADOS ... 55

6.1.SISTEMA EMBARCADO ... 55

6.2.PAINEL E INTERAÇÕES DO USUÁRIO ... 57

6.2.1. Tela 1 – Informações instantâneas ... 57

6.2.2. Tela 2 – Informações históricas ... 58

7. CONCLUSÃO ... 63

REFERÊNCIAS... 64

ANEXOS ... 66

(15)

(16)

1. INTRODUÇÃO

1.1. Justificativa

Estima-se que o número de pessoas que possuem acesso à internet por um dispositivo remoto irá aumentar de 5,1 bilhões em 2018 para 5,7 bilhões em 2023, o que representaria um contexto em que mais de dois terços da população global (71%) estaria pesquisando informações e gerando dados (CISCO, 2020). Ainda, entende-se que, neste período, o número de máquinas trocando informações entre si – Machine to Machine (M2M) – passará de 33% para 50%, resultando em 14,6 bilhões de máquinas M2M conectadas, vide Figura 1 (CISCO, 2020).

Figura 1 - Estimativa de crescimento dos dispositivos conectados a internet no globo

Fonte: (CISCO, 2020)

Neste contexto, nota-se uma tendência de ampliação na presença de aplicações de Internet das Coisas – Internet Of Things (IoT) –, em que dispositivos eletrônicos de detecção e atuação devem proporcionar o compartilhamento de dados. Alguns exemplos de aplicações de IoT já existentes são o monitoramento de recursos industriais, as aplicações de cidades inteligentes e o acompanhamento logístico em tempo real (RAZA; KULKARNI; SOORIYABANDARA, 2017).

Ao passo em que novas aplicações de internet das coisas são inseridas em um mesmo ambiente – e ao passo que as os projetos implementados interagem entre si –, configura-se o local como um ambiente inteligente, ou, do inglês, um smart place. Com isso, estuda-se a implantação de cidades e casas inteligentes – denominadas de smart cities e smart homes, respectivamente.

Tais sistemas buscam a automatização de atividades e tomadas de decisões em áreas como

(17)

indústria, agricultura, saúde, entre outros. Alguns exemplos de áreas da cidade que poderão ser impactadas entram-se na Figura 2 (SOLUTIONS, 2019).

Figura 2 - Representação de aplicações nas cidades inteligentes

Fonte: (SOLUTIONS, 2019)

Seguindo a ideia de ambiente inteligentes, a Universidade Estadual de Campinas (UNICAMP), já possui uma iniciativa para transformar gradativamente o local acadêmico da instituição em um Smart Campus (UNICAMP, 2022). Um exemplo de uma aplicação que está implementada e coletando dados no ano de 2022 é o projeto “Estacionamento”. Nele, existem dois bolsões na UNICAMP que estão sendo monitoradas identificando quais são as vagas ocupadas ou livres durante os períodos do dia. O sistema em funcionamento pode ser visualizado na Figura 3 (UNICAMP, 2022).

Figura 3 - Sistema de monitoramento do smart campus da UNICAMP

Fonte: (UNICAMP, 2022)

(18)

Outro projeto implementado nas instalações da Universidade Estadual de Campinas foi a

“Fila dos Restaurantes” (UNICAMP, 2022). Nele, há o acompanhamento da dimensão da fila presente no restaurante universitário pela captura e análise das imagens utilizando uma técnica de aprendizado de máquina – Machine Learning –, vide Figura 4. O código exemplo é disponibilizado em um servidor público no Git da Konker (GitHub) e pode ser acompanhado em tempo real pelo site da instituição (UNICAMP, 2022).

Figura 4 - Sistema de reconhecimento da dimensão da fila do restaurante por aprendizado de máquina na UNICAMP

Fonte: (UNICAMP, 2022)

Tais projetos descrevem possíveis aplicações nas quais o Smart Campus pode se beneficiar, adquirindo dados e melhorando atividades das pessoas presentes no ambiente. Todavia, a implantação de um campus inteligente pode requerer um alto investimento (SARI; CIPTADI;

HARDYANTO, 2016).

Neste contexto, este trabalho visa o desenvolvimento de uma aplicação de internet das coisas para o campus da UNESP de Sorocaba, baseado na infraestrutura consolidada pela iniciativa

“Arquitetura IoT para Aplicação em Smart Campus” (PROENÇA, 2022). Especificamente, o projeto busca a captação das informações de um sistema de geração fotovoltaico e na montagem de visualizações sobre o seu funcionamento ao longo do tempo.

(19)

1.2. Objetivos

Os objetivos desse trabalho são:

 Aquisitar de forma flexível, escalável e segura as informações operacionais do sistema de geração fotovoltaica do Smart Campus da UNESP de Sorocaba.

 Projetar e implementar um sistema embarcado de aquisição de dados do inversor fotovoltaico e comunicação com a arquitetura IoT existente.

 Criar interfaces web interativas para visualizações das informações coletadas, considerando os dados de interesse do sistema para a comunidade acadêmica.

1.3. Organização deste trabalho

Este trabalho está organizado em 7 capítulos, tendo-se o primeiro capítulo destinado para a introdução do motivo do trabalho, com os objetivos gerais e específicos que foram buscados pelo seu desenvolvimento.

No segundo capítulo têm-se a apresentação do referencial teórico necessário para o entendimento do projeto, passando por conceitos de internet das coisas, sistemas embarcados e do funcionamento do protocolo MQTT.

Por sua vez, no terceiro capítulo apresenta-se a topologia e as características do inversor escolhido para a aplicação do sistema embarcado, abordando também a comunicação dos dados presentes e quais são as informações transmitidas.

No quarto capítulo, destrincha-se a solução projetada do hardware e software para que fosse possível captar os dados e enviar para a infraestrutura da arquitetura inteligente do campus tratado.

No quinto capítulo, elabora-se sobre como que foi o processo de montagem das visualizações e como obteve-se no Grafana os dados coletados perante as telas definidas.

O sexto e o sétimo capítulos são destinados para discussões dos resultados e conclusões obtidas pelo desenvolvimento do projeto, principalmente no ponto da implantação do sistema embarcado e da montagem das visualizações.

Por fim, são apresentados as referências bibliográficas e os anexos.

(20)

2. REFERENCIAL TEÓRICO

2.1. Internet das Coisas (IoT)

De acordo com S. Madakam, a Internet das Coisas, também chamado como Internet dos Objetos ou IoT, é “Uma rede aberta e abrangente de objetos inteligentes que têm a capacidade de auto-organizar, compartilhar informações, dados e recursos, reagindo e agindo diante de situações e mudanças no ambiente.” – Tradução livre (MADAKAM; RAMASWAMY;

TRIPATHI, 2015). Desta maneira, entende-se que um IoT procura conectar dispositivos eletrônicos de detecção e atuação, oferecendo a capacidade de compartilhar informações entre plataformas através de uma estrutura unificada, como ilustrado na Figura 5.

Figura 5 - Diagrama de dispositivos interagindo na Internet das Coisas

Fonte: (REDAÇÃO, 2021)

Analogamente à internet das pessoas, a internet das coisas proporciona uma relação rápida e constante de troca de informações entre as partes. Neste contexto, a aplicação de inteligências e a melhora da tomada de decisões nos ambientes onde está contida, se tornam notórios. Alguns exemplos em que tal ganho é perceptível são nas áreas de saúde, pessoal & social e ambientes inteligentes (KAUR; SINGH, 2016), seguem exemplos de aplicações em cada um destes âmbitos:

(21)

 Saúde: utilizando-se do rastreamento e da identificação se uma pessoa ou objeto está em movimento ou quais são as salas e andares com o maior número de pacientes ou recursos, a IoT consegue otimizar o fluxo hospitalar e evitar pontos de difícil acesso para áreas importantes.

Ainda, a internet das coisas consegue reduzir o tempo de processamento de burocracias e processos internos do hospital utilizando-se de RFID (radio-frequency identification) e outras interfaces móveis (smartfones, tablets e painéis) para a coleta e transferência automática de informações (KAUR; SINGH, 2016).

 Pessoal & Social: facilitando as consultas históricas de objetos e eventos ocorridos que estudam as suas tendências ao longo do tempo – como no uso de dispositivos de alarme e de identificação de rotinas de um grupo – a internet das coisas colabora para um entendimento mais concreto dos hábitos. Ainda, os dispositivos de IoT fornecem suporte para atividades e projetos como negócios comerciais e colaborações mútuas (KAUR; SINGH, 2016).

 Ambientes Inteligentes: pelo uso de sensores e atuadores distribuídos em locais como escritórios e casas, proporciona-se uma vida mais confortável para os indivíduos presentes.

Comodidades como um aquecimento adaptado ao clima da região e uma iluminação que corresponde ao necessário são exemplos disto. Adicionalmente, no contexto industrial, pode-se utilizar-se de etiquetas RFID para gestão do acesso dos funcionários e sensores internos de máquinas para o controle de qualidade e produtividade (KAUR; SINGH, 2016).

2.2. Smart Campus

De acordo com L. Xiong, um Campus Inteligente – do inglês, Smart Campus – é “... um ambiente de campus integrado contando com trabalho, estudo e vivência baseado na Internet das Coisas.” – Tradução livre (XIONG, 2016). Dessa forma, entende-se que a aplicação de IoT engloba tanto o trabalho, quanto o estudo e a vivência em geral dos indivíduos e máquinas presentes no ambiente acadêmico do campus em questão. Salienta-se que um campus inteligente se difere do conceito de campus digital (digital campus). No quadro 1, destaca-se pontos relevantes destas distinções (PROENÇA, 2022).

Nota-se que, respeitando o que foi estruturado no âmbito do digital campus, o smart campus move-se mais na direção da integração e escalabilidade, enfatizando o uso de tecnologias como internet móvel, big data e computação em nuvem (XIONG, 2016). Ainda, nota-se que

(22)

gradativamente o ambiente físico e o digital tornam-se cada vez mais indissociáveis, criando uma relação de dependência e otimização entre alunos, professores e servidores acadêmicos para com as redes de comunicação e armazenamento de dados computacionais (XIONG, 2016).

Quadro 1 - Características do Campus Digital e do Campus Inteligente

Fonte: (PROENÇA, 2022)

Tornando-se cada vez mais pesquisados, os smart campus são compostos por subdomínios como a aprendizagem inteligente – smart learning/education –, o gerenciamento inteligente – smart manegement – e construções inteligentes – smart building – (NAGOWAH; STA; GOBIN- RAHIMBUX, 2019). Em relação às construções inteligentes, entende-se que possuem em si incorporadas tecnologias que monitoram o funcionamento e as condições em que o local se encontra, tal qual como reagir a rotinas e circunstâncias adversas (NAGOWAH; STA; GOBIN- RAHIMBUX, 2019). Segue na Figura 6 um exemplo de uma topologia para a implantação de um

(23)

smart campus levando em consideração os subdomínios de smart management, smart classroom, smart learning e smart parking.

Figura 6 - Exemplo de topologia de subdomínios para a implantação de um smart campus

Fonte: (NAGOWAH; STA; GOBIN-RAHIMBUX, 2019)

2.3. Sistemas Embarcados

De acordo com Elecia White, sistemas embarcados são “... um sistema computadorizado construído visando o propósito de sua aplicação.” – Tradução livre (WHITE, 2012). Dessa forma, sistemas embarcados servem para realizar a redução de custos, volume, consumo de energia e complexidade de estruturas eletrônicas (hardware) tal como de tecnologia de informação (software / firmware) para que um objetivo em uma aplicação seja alcançado.

Como exemplos de sistemas embarcados que estão presentes na vida cotidiana têm-se os oxímetros digitais utilizados nos hospitais, os medidores de condições meteorológicas em balões para altas altitudes e sensores de proximidades dos carros modernos. Ainda, têm-se as placas que permitem que as lâmpadas inteligentes liguem e desliguem conforme um comando dado pelos smartphones, vide Figura 7.

(24)

Figura 7 - Exemplo de aplicação que contém sistemas embarcados

Fonte: (FINGAS, 2022)

Uma representação com exemplos de possíveis áreas de aplicação dos sistemas embarcados (do inglês, embedded systems) encontra-se na Figura 8. Nela, pode-se observar que já existem aplicações para tais dispositivos em diversas áreas como médica, equipamentos de manufatura, sensores de movimento e veículos.

Figura 8 - Exemplos de aplicações contendo sistemas embarcados em suas composições

Fonte: (LEARNING, [s.d.])

(25)

2.4. Protocolo MQTT

O Message Queuing Telemetry Transport ou MQTT - é um protocolo de comunicação amplamente utilizado para aplicações de Internet das Coisas, devido a sua eficiência energética, comunicação bidirecional (do dispositivo para a nuvem e da nuvem para o dispositivo) e escalabilidade (MQTT.ORG, 2022). O MQTT é estruturado de tal forma que os transportes de mensagens se dão pelo modelo de publicação e assinatura. Sendo assim, possui-se dois elementos na troca, um publisher e um subscriber, com o primeiro dispositivo enviando informação a um servidor – chamado de broker - e o segundo sendo o destinatário final - ou destinatários finais - da informação (MQTT.ORG, 2022).

Na Figura 9, pode-se observar um diagrama de um uso do protocolo MQTT para o envio da informação de temperatura de um sensor para uma aplicação back-end e um smartphone. Em tal figura, nota-se que um mesmo broker pode realizar a troca de informações com diversos Clients e que tais Clients não precisam ser necessariamente dispositivos do mesmo tipo. Ainda, salienta- se que a comunicação se dá por uma divisão em tópicos, em que o subscriber informa qual tópico deseja receber e o broker retorna o respectivo dado.

Figura 9 - Fluxo de funcionamento do protocolo de comunicação MQTT

Fonte: (MQTT.ORG, 2022)

Dentre as características presentes no uso do MQTT, destacam-se três aspectos consequentes da dissociação de mensagens pelo protocolo (PROENÇA, 2022):

(26)

 Espaço: não é necessário que o publisher e o subscriber estejam em um mesmo espaço físico ou com uma conexão de cabo direta. Pelo intermédio do broker é apenas necessário que haja um hostname / IP e uma porta em comum (THE HIVEMQ TEAM, 2015).

 Tempo: não necessariamente é preciso que a comunicação seja feita ao mesmo tempo, mesmo com a conexão geralmente ocorrendo em tempo real. É possível armazenar mensagens para que os clientes a consumam posteriormente, ao se restaurar a conexão com o broker (THE HIVEMQ TEAM, 2015).

 Sincronização: não necessariamente é preciso que a comunicação seja feita de forma síncrona. Dessa forma, as partes não precisam esperar que o envio de uma mensagem seja feito para que se possa receber uma nova. (THE HIVEMQ TEAM, 2015).

(27)

3. SISTEMA DE GERAÇÃO FOTOVOLTAICA

3.1. Localização e características gerais

De forma resumida, um sistema de geração de energia fotovoltaica é composto pelo inversor fotovoltaico e pelo conjunto de placas solares. O sistema de geração fotovoltaica alvo deste projeto está alocado no bloco D do Instituto de Ciência e Tecnologia de Sorocaba (ICTS) – UNESP Sorocaba e possui 20 KW de potência, com 59 placas solares. O inversor utilizado para o desenvolvimento e implantação do sistema embarcado foi um Weg Huawei SUN2000-20KTL- M0. Encontra-se na Figura 10 uma foto do inversor em questão e na Figura 11 uma imagem do conjunto de painéis solares em que ele está acoplado.

Figura 10 - Inversor Huawei SUN2000 utilizado no projeto

Fonte: autoria própria

Figura 11 - Conjunto de placas solares do sistema fotovoltaico do Bloco D da UNESP de Sorocaba

(28)

O nome dado ao dispositivo indica quatro dados sobre o seu funcionamento. Para identificação destes parâmetros, o nome do dispositivo pode ser dividido de acordo com o indicado na Figura 12, com uma explicação mais detalhada do que cada trecho do texto significa na tabela 1. (HUAWEI TECHNOLOGIES CO., 2019).

Figura 12 - Subdivisão das informações contidas no nome do inversor do projeto

Tabela 1 - Tipos de informações e descrições para o inversor do projeto referentes ao seu nome

Identificador Tipo de informação Descrição

1 Produto SUN2000: inversor de cadeia PV trifásico ligado à

rede elétrica

2 Nível de potência 20K: potência nominal de 20 KW

3 Topologia TL: sem transformador (do inglês, transformerless)

4 Código do produto M0: série de produtos com tensão de entrada de

1.100 V CC

Fonte: adaptado de (HUAWEI TECHNOLOGIES CO., 2019)

Ainda, características do inversor podem ser encontradas no manual oficial – presente em (HUAWEI TECHNOLOGIES CO., 2019) – e conferidas de acordo com a etiqueta da fabricante presente no corpo do dispositivo, segue lista com as informações julgadas mais relevantes sobre o seu funcionamento:

 Máxima tensão de entrada: 1080 V DC

 Máxima corrente de entrada: 22 A / 22 A

 Tensão de saída nominal: 230 / 400 Va.c; 3(N)

 Frequência de operação nominal: 50 / 60 Hz

 Potência de saída nominal: 20 kVA

 Máxima potência aparente de saída: 22 kVA

(29)

 Máxima corrente de saída: 33,5 A

 Fator de potência: 0,8 (atrasado) até 0,8 (adiantado)

 Temperatura de operação: -25 até 60 ºC

 Comunicação: RS485 / WLAN

3.1. Comunicação dos dados

Uma das maneiras de comunicar com o inversor é por meio do aplicativo de celular proprietário da empresa, o "Fusion Solar", utilizado para realizar configurações remotas e status da máquina. Além do aplicativo que permite realizar configurações e verificar o status da máquina, existem apenas duas possibilidades de comunicação direta com o inversor indicadas pela fabricante, a comunicação por WLAN e por RS485. A WLAN advém do uso de um dongle acoplado na porta (GPRS/4G/WLAN-FE) que, no caso do inversor selecionado, não estava disponível, vide Figura 13.

Figura 13 - Portas para as possíveis conexões diretas com o inversor

Desta forma, optou-se por utilizar a porta de comunicação COM – Figura 13. Para isso, foi necessário identificar como a porta estava configurada para transmitir os dados, principalmente no que se referia no tipo de protocolo utilizado e a taxa de transmissão (do inglês, protocol type e baud rate).

(30)

Na Figura 14 encontra-se o aplicativo para smartphones Android, o “Fusion Solar”, no qual foi possível obter acesso as configurações presentes no inversor. Na Figura 15 pode-se observar os parâmetros colocados na taxa de transmissão, no tipo de protocolo e nas opções “Com address” e “RS485 Bus Frame Capture”.

Figura 14 - Aplicativo indicado pela fabricante para a consulta e configuração do inversor do projeto

Fonte: do aplicativo Fusion Solar, autoria própria

Figura 15 - Configurações presentes no aplicativo do inversor no que se refere a transmissão dos dados pela porta COM

Fonte: do aplicativo Fusion Solar, autoria própria

Entretanto, a porta de comunicação já estava sendo utilizada por um logger da Companhia Sul Paulista de Energia (CPFL), que estava coletando as informações mas que a UNESP não tinha acesso direto aos dados puros (tabelas e registros). Ao entrar em contato com o campus, abriu-se a página onde o logger enviava as informações e descobriu-se os momentos em que havia trocas entre o inversor e o dispositivo da CPFL – basicamente as minutagens múltiplas de 10 durante o período de Sol no dia (Exemplos: ...; 13:00; 13:10; 13:20; 13:30; 13:40; ...). Vale salientar que mesmo podendo visualizar os dados presentes no logger, eles não são acessíveis e, dessa forma, não são úteis para aplicações em si.

(31)

Na Figura 16 pode-se observar a estrutura já presente acoplada ao inversor para a coleta de informações. Nela, nota-se que o cabo de comunicação foi adaptado para que de um lado seja o conector IS10W00002 do inversor (Figura 17) e que do outro seja um conector Ethernet (RJ-45).

Vale salientar que os dados coletados pela CPFL não são de acesso direto pela UNESP Sorocaba e, dessa maneira, não podems ser acessados para as aplicações direcionadas ao smart campus.

Figura 16 - Estrutura já presente no inversor para a coleta de informações pela CPFL

Figura 17 - Conector do tipo COM para a obtenção dos dados do inversor do projeto

Fonte: (HUAWEI TECHNOLOGIES CO., 2019)

Realizou-se então um estudo para o entendimento de quais eram os terminais de COM que estavam efetivamente sendo utilizadas pela porta Ethernet e, pelo manual de utilização do inversor, e o que elas realizavam. Entendeu-se então que as únicas portas utilizadas eram as portas 1 e 3.

Suas definições e funções encontram-se na Tabela 2.

(32)

Tabela 2 - Definições e funções das portas utilizadas pelo cabo adaptado presente no inversor do projeto

Fonte: adaptado de (HUAWEI TECHNOLOGIES CO., 2019)

3.3. Informações transmitidas

Para a obtenção de quais são os dados transmitidos pelo inversor pela porta COM, foram realizadas pesquisas no manual (HUAWEI TECHNOLOGIES CO., 2019), no guia de comunicação Modbus (HUAWEI TECHNOLOGIES CO., 2021) e em fontes de bibliotecas da comunidade (CORDERO, 2021; VANHERP; W, 2020). O Guia de comunicação Modbus foi o principal arquivo explorado, podendo ser encontrado no endereço < https://javierin.com/wp- content/uploads/sites/2/2021/09/Solar-Inverter-Modbus-Interface-Definitions.pdf >, nele há o mapa de memória Modbus do inversor.

Dessa forma, pode-se levantar quais eram os campos, o tipo de dado, a unidade, a posição do byte e o tamanho da informação enviada, possuindo-se 264 possíveis valores de serem obtidos do inversor. Dentre tais, existem campos referentes às placas solares, ao inversor e à rede elétrica.

Alguns exemplos dos campos que são possíveis de serem obtidos encontram-se na Tabela 3. A lista completa está no Anexo A.

Tabela 3 – Exemplos de informações transmitidas por MODBUS pelo inversor do projeto Nome do campo Tipo Unidade Posição do registrador Quantidade de registradores

rated_power u32 W 30073 2

P_max u32 W 30075 2

S_max u32 VA 30077 2

Q_max_out i32 VAr 30079 2

Q_max_in i32 VAr 30081 2

input_power i32 W 32064 2

grid_voltage u16 V 32066 1

Pin Definição Função

1 485A1-1 Sinal + diferencial RS485

3 485B1-1 Sinal - diferencial RS485

(33)

line_voltage_A_B u16 V 32065 1

line_voltage_B_C u16 V 32067 1

line_voltage_C_A u16 V 32068 1

phase_A_voltage u16 V 32069 1

phase_B_voltage u16 V 32070 1

phase_C_voltage u16 V 32071 1

grid_current i32 A 32072 2

phase_A_current i32 A 32072 2

phase_B_current i32 A 32074 2

phase_C_current i32 A 32076 2

day_active_power_peak i32 W 32078 2

active_power i32 W 32080 2

reactive_power i32 VA 32082 2

grid_frequency u16 Hz 32085 1

efficiency u16 % 32086 1

internal_temperature i16 °C 32087 1

Dessa forma, realizou-se conversas com o professor orientador e os interessados nos dados do inversor e membros da comunidade acadêmica do ICTS e foram definidos quais seriam os dados mais relevantes a serem armazenados no banco de dados do smart campus, vide Anexo B.

(34)

4. DESENVOLVIMENTO DO SISTEMA EMBARCADO

4.1. Abordagem

Após o estudo do inversor e do entendimento da melhor maneira viável de realizar o recebimento dos dados, estudou-se a implementação de um sistema embarcado que, ao receber os dados do inversor via protocolo MODBUS RS485, realizaria a estruturação dos dados de forma que possa usufruir do trabalho desenvolvido para a arquitetura IoT do smart campus da UNESP de Sorocaba (PROENÇA, 2022).

Adotou-se atuações para duas partes: “envio dos dados” e “consumo das informações para a montagem das visualizações”. A ideia da topologia pensada para a aplicação está presente na Figura 18, com a atuação sendo no ponto do “Sistema embarcado” e na montagem do “Painel”.

Figura 18 - Diagrama da topologia pensada para a aplicação

Ainda na Figura 18, vale ressaltar que a conexão entre o inversor solar e o sistema embarcado se deu por cabo, mas entre o sistema embarcado e o servidor será utilizado o protocolo MQTT (por Wi-Fi). Posteriormente, para o painel, teve-se explorado um sistema WEB que irá consultar o banco de dados no servidor.

4.2. Sistema embarcado

O sistema embarcado escolhido para a implantação no projeto foi uma Raspberry Pi Zero W 2 – Figura 19 (RASPBERRY PI, [s.d.]). Sendo de fácil acesso e de relativo baixo preço, o dispositivo ainda conta com:

 CPU Arm Cortex-A53 quad-core de 64 bits de 1 GHz

 SDRAM de 512 MB

(35)

 LAN sem fio 802.11 b/g/n de 2,4 GHz

 Bluetooth 4.2, Bluetooth Low Energy (BLE), antena integrada

 Porta mini HDMI e porta micro USB On-The-Go (OTG)

 slot para cartão microSD

 Conector da câmera CSI-2

 Cabeçalho de 40 pinos compatível com HAT (não preenchido)

 H.264, decodificação MPEG-4 (1080p30); Codificação H.264 (1080p30)

 Gráficos OpenGL ES 1.1, 2.0

 Alimentação micro USB

 Vídeo composto e pinos de reset por meio de pontos de teste de solda

 Dimensões de 65 mm x 30 mm

Figura 19 - Raspberry Pi Zero W 2

Fonte: (RASPBERRY PI, [s.d.])

Para facilitar a utilização da Raspberry para o protocolo de comunicação MODBUS, utilizou-se um módulo conversor de USB para Serial RS485. Tal dispositivo pode ser observado na Figura 20.

Figura 20 - Módulo Conversor de USB Para Serial RS485

Fonte: (“Módulo Conversor De Usb Para Serial Rs485”, [s.d.])

(36)

Dessa forma, para a implementação do hardware da solução utilizou-se os seguintes materiais:

 Raspberry Pi Zero W 2

 Fonte de alimentação micro USB 5V 2A

 Cartão de memória para o sistema operacional, possuindo 32GB

 Case Raspberry Pi Zero W

 Adaptador micro USB para USB

 Módulo conversor de USB Para Serial RS485

 Cabo de rede RJ45

 Conector extensor duplicador RJ45

O resultado das conexões para possibilitar a obtenção das informações do inversor para o sistema embarcado escolhido está representado na Figura 21. Da forma que foi pensado, a solução em hardware não impedirá o funcionamento do logger presente, já que a ligação permite um funcionamento em paralelo. Apenas basta atentar-se a não fazer as consultas do MODBUS no mesmo instante que o logger as está realizando.

Figura 21 - Estrutura pensada para o hardware da solução do projeto

4.3. Desenvolvimento de software

(37)

Para a implementação da parte do software da solução, utilizam-se as tecnologias presentes no quadro 2. Nele, pode-se entender a finalidade e os principais benefícios para o uso de cada uma das escolhas.

Quadro 2 - Tecnologias para o desenvolvimento do código

Tecnologias para o Desenvolvimento do Código

Raspbian (Linux)

 É um sistema operacional presente na Raspberry Pi escolhida

 Open source, leve e possibilita a interação simples com o hardware

 Seguro e completamente customizável, com ótimo suporte da comunidade para eventuais problemas

Docker

 É uma plataforma open source que facilita a criação e administração de ambientes isolados

 Realiza o controle e o versionamento das bibliotecas necessárias para o funcionamento do código

 Possibilita a configuração para que a Raspberry Pi inicie com o código rodando sempre que ligada, fornecendo logs dos dados recebidos

Visual Studio Code

 É um editor de código do tipo open source desenvolvido pela Microsoft

 Oferece grande flexibilidade para

desenvolvimento ágil e testes do código pelo uso de extensões

 Sendo leve, pode rodar dentro da Raspberry Pi escolhida e possui integrações com todas as outras tecnologias escolhidas para o projeto

Python

 É uma linguagem de programação de alto nível, orientada a objetos

 Possui sintaxe simples, grande estabilidade e funciona bem na Raspberry Pi escolhida

 Possui bibliotecas implantadas pela

comunidade que facilitam o desenvolvimento da solução

Git

 É um sistema de controle de versionamento de código do tipo open source

 Oferece formas de guardar todas as alterações e escolhas técnicas feitas em repositórios remotos como o Github e o Gitlab

 Facilita a passagens de novas versões do código entre o computador pessoal e a Raspberry Pi escolhida e vice-e-versa

4.3.1. Fluxo de funcionamento adotado para o código

O funcionamento do código foi definido após a realização de testes para entender quais eram as melhoras formar de obter as informações do inversor, manter a infraestrutura do hardware

(38)

alinhado com o software funcionando – minimizando problemas – e como realizar o envio da melhor forma. Ainda, teve-se em mente como facilitar o entendimento de qual seria um eventual problema e se os dados estariam fazendo sentido com o que é esperado. O diagrama de blocos simplificado demonstrando as etapas de funcionamento do código implementado encontram-se na Figura 22.

Figura 22 - Diagrama de fluxo simplificado do funcionamento do código implementado

4.3.2. Estrutura de pastas e arquivos

(39)

Buscando um software de maior intuitividade e escalabilidade no que se propõe, realizou- se a divisão de arquivos e pastas dentro da aplicação conforme o presente na Figura 23.

Figura 23 - Estrutura de pastas e arquivos para o software da solução implementada

Fonte: VS Code, autoria própria

O papel a ser desempenhado pelos arquivos, presentes na Figura 23, encontram-se descritas na Tabela 4. A biblioteca utilizada como base para o arquivo de conexão com o inversor por MODBUS (base_solar.py), baseia-se nos arquivos “Solar Inverter Modbus Interface” (HUAWEI TECHNOLOGIES CO., 2021) e “Huawei Solar Integration” (CORDERO, 2021).

Tabela 4 - Funções dos arquivos presentes no software da aplicação do projeto

Nome do arquivo Papel / Serventia dentro da aplicação

mqtt.py Responsável por estabelecer a conexão MQTT com a arquitetura do

campus inteligente da Unesp de Sorocaba

inverter_data.py Local onde as constantes que definem quais variáveis serão coletadas são definidas. Também contém a função que chama a biblioteca e faz referência à porta que está recebendo os dados do inversor

offline.py Arquivo que possibilita testes com valores simbólicos, mesmo quando não há conexão com o inversor

(40)

possible_variables.txt Listagens de todos os valores possíveis de ser coletado pelo inversor já em formato de lista do Python

base_solar.py Biblioteca adaptada que realiza a comunicação MODBUS com o

inversor

docker_log.py Realiza a impressão dos logs dentro do container do Docker

wait_to_certain_time.py Espera até os momentos ideais para a obtenção dos dados de tal forma a não causar conflitos com o logger

main.py Onde está a principal parte do corpo do código, onde as constantes estão sendo definidas e chamadas e as funções são aplicadas, vide figura 22 .gitignore Arquivo para que arquivos indesejados não sejam passados para o Git,

principalmente as constantes de configuração e de ambiente contendo informações sigilosas

docker-compose.yml Arquivo onde estão configurados os serviços da aplicação, como versão, configurações do container e variáveis / constantes do ambiente

docker-compose.yml.example Arquivo contendo o modelo para a configuração do docker-compose.yml Dockerfile Arquivo contendo a configuração das imagens que serão geradas pelo

Docker para a aplicação

README.md Arquivo de texto para escrever detalhes do projeto que apareceram como documentação no Git

requirements.txt Arquivo consultado pelo Docker para fazer a instalação das dependências do projeto

Seguem descritos nos tópicos de 4.3.3. até 4.3.7. o conteúdo presente e o código desenvolvido dentro dos arquivos mais relevantes para o funcionamento da aplicação. Os que não estão descritos, possuem sua finalidade presente somente na tabela 4.

4.3.3. Arquivos docker-compose.yml.example e docker-compose.yml

Os arquivos docker-compose.yml.example e docker-compose.yml contém as linhas de código presentes na Figura 24. Nela, pode-se perceber que há a definição do nome do container do Docker, que ele deve sempre reiniciar com a última imagem criada com o usuário raiz e que haverá a conexão com a porta serial “dev/ttyUSB0” do Linux.

(41)

Ainda, na Figura 24, têm-se as variáveis de ambiente que foram definidas para facilitar a passagem do código estruturado para outros inversores da mesma fabricante, no tópico

“environment”.

Figura 24 - Conteúdo presente nos arquivos docker-compose.yml.example e docker-compose.yml

4.3.4. Arquivo Dockerfile

O arquivo Dockerfile possui uma série de comandos procedurais que serão realizados pelo Docker para configurar as dependências e principalmente as imagens que serão parte da aplicação assim que estiver rodando. Pode-se observar na figura 25 que as dependências são puxadas do arquivo requiments.txt.

Figura 25 - Conteúdo presente no arquivo Dockerfile

(42)

4.3.5. Arquivo requiriments.txt

As dependências utilizadas pelo projeto encontram-se descritas no arquivo requirementes.txt, vide Figura 26.

Figura 26 - Conteúdo presente no arquivo requirements.txt

4.3.6. Arquivo main.py

O arquivo main.py é o principal da aplicação e é o primeiro que será rodado assim que o projeto se iniciar - respeitando o fluxograma estipulado na Figura 22. Pode-se então entender da Figura 27 até 34 as partes que compõem esta série de comandos.

Primeiramente, na Figura 27, pode-se observar quais são as importações que são necessárias para o funcionamento do arquivo.

Figura 27 - Importações feitas para o arquivo main.py

(43)

Por outro lado, nas Figuras 28 e 29, pode-se visualizar quais são as constantes definidas para os intervalos de tempo presentes nas etapas dentro do laço do funcionamento do código e quais são as variáveis de ambiente para o tipo de recebimento e o tópico MQTT de envio dos dados, respectivamente.

Figura 28 - Constantes definidas para o arquivo main.py

Figura 29 - Informações puxadas das variáveis de ambientes para o arquivo main.py

Já na Figura 30, pode-se notar o instante inicial do software criado, onde o programa espera até momentos que não coincidam com os que o logger para fazer uma requisição de dados ao inversor – momentos que não sejam inteiros durante o dia (13:00, 13:10, 13:20, por exemplo) – e depois inicia a coleta de informações.

Figura 30 - Principal rotina do código implementado presente no arquivo main.py

(44)

Na Figura 31, encontra-se a função que realiza a coleta e envio das variáveis imediatas – que foram medidas diretamente pelo inversor, sem nenhum cálculo em cima – e das variáveis calculadas. Pode-se observar que existem momentos de log para acompanhamento no container do Docker e que há também a formatação do dado em JSON serializado, com funções para controlar os tempos de envios e esperas dentro da rotina.

Figura 31 - Função que realiza a obtenção e envio das variáveis imediatas e calculadas pelo inversor.

Na Figura 32 consta a função que, dependendo da variável de ambiente, retorna ou o dado real obtido do inversor ou um valor simbólico para testes quando o inversor está offline. Está

(45)

presente na Figura 33 a parte do código que formata o dado recebido de forma a estar na estrutura esperada pela arquitetura do campus inteligente da UNESP de Sorocaba e como JSON serializado.

Ainda, na Figura 34 nota-se a função que envia o JSON serializado para o tópico descrito no broker do protocolo de comunicação MQTT.

Figura 32 - Função que retorna ou valores simbólicos para testes ou valores reais do inversor

Figura 33 - Função que transforma os dados no formato adequado para o envio na arquitetura do campus inteligente

Figura 34 - Função que realiza o envio no cliente MQTT com a conexão estabelecida

(46)

4.3.7. Arquivo mqtt.py

O arquivo mqtt.py cuida das partes do software da solução que estabelecem a conexão com o broker, inserindo as credenciais necessárias e realizando o informe adequado do estado dessas etapas pelo log do Docker. Dessa forma, nas Figuras 35 e 36, observa-se as importações necessárias e as variáveis de ambientes que são utilizadas, respectivamente.

Figura 35 - Importações feitas para o arquivo mqtt.py

Figura 36 - Variáveis de ambientes utilizadas pelo arquivo mqtt.py

Nas Figuras 37 e 38, encontram-se a função que retorna o estado da conexão – que está sendo utilizado pelo arquivo main.py – e a função que o realiza de fato, respectivamente. Ainda, na Figura 39, nota-se a parte que seta a flag para informar que tudo o correu como o planejado ou não, informando por logs do Docker a situação.

Figura 37 - Função para puxar o estabelecimento de conexão com o broker mqtt

Figura 38 - Função que realiza a conexão com o broker mqtt

(47)

Figura 39 - Função que retorna se a conexão com o broker mqtt foi um sucesso ou não

5. INTERFACE WEB DE VISUALIZAÇÃO

Definiu-se que as visualizações dos dados obtidos do inversor estariam alojadas em duas telas, cada qual contendo prioritariamente um tipo de modo de apresentar as informações. Cada escopo de cada tela pode ser descrito por:

 1ª tela: consiste prioritariamente de dados instantâneos e da apresentação do projeto em si.

Deve ser simples e intuitivo, apresentando somente informações relevantes – de forma responsiva com a tela do usuário.

 2ª tela: consiste prioritariamente em dados distribuídos ao longo do tempo, ou seja, de informações históricas obtidas do inversor. Deve ser também simples, intuitivo e responsivo com a tela do usuário.

Definiu-se então, que na primeira tela estaria contido:

 Apresentação do projeto

 Energia convertida desde o último dia

 Energia convertida desde o último mês

(48)

 Energia convertida desde o último ano

 Quando foi o último recebimento dos dados

 Qual é a eficiência no atual momento

 Qual é a potência ativa no atual momento

 Qual é a potência reativa no atual momento

 Qual é a temperatura interna do inversor no atual momento

 Botão para a segunda tela

De forma análoga, para a finalidade esperada, colocou-se como pontos importantes para a segunda tela do projeto:

 Botão para voltar a primeira tela

 Energia hoje ao longo do tempo

 Energia acumulada por dia de um mês atrás até hoje

 Energia acumulada por mês de um ano atrás até hoje

 Tensão e corrente transmitidas a rede ao longo do tempo

 Potência ativa e reativa do inversor ao longo do tempo

 Temperatura do inversor ao longo do tempo

 Eficiência do inversor ao longo do tempo

A primeira tela foi nomeada como “Tela Principal” ou “Tela de Apresentação e dos Dados Instantâneos” e a segunda tela como “Tela Histórica” ou “Tela dos Dados Históricos”. Tais aspectos considerados estavam em mente para os princípios básicos que foram seguidos na montagem das visualizações dos dados, imagens e textos presentes no resultado do capítulo 6 do trabalho.

5.1. Princípios básicos para as visualizações dos dados

Para a montagem das visualizações, seguiu-se principalmente as estruturas já presentes no Grafana e a sua interação com o InfluxDB. Primeiramente entendendo-se como os dados são vistos pelo Grafana – Figura 40 – e então, considerando a estrutura de dados que está salva no InfluxDB,

(49)

com a criação de um modelo de consulta simples em InfluxData, como a que está presente no exemplo da Figura 41.

Figura 40 - Exemplo de formato em que os dados são percebidos pelo Grafana

Fonte: Grafana, autoria própria

Pode-se notar que, para a aplicação do modelo da Figura 41 para diferentes tipos de dados, basta alterar o nome do texto presente no filtro “variável” pelo nome correspondente ao que tal dado foi salvo pelo sistema embarcado implementado.

Figura 41 - Exemplo de consulta utilizada como padrão para a obtenção dos dados no Grafana

Por outro lado, para a montagem das visualizações, existem certos modelos distintos como o stat – formas de mostrar um número calculado –, o gauge – uma maneira de mostrar um medidor com ponteiro de o nível de um valor – e o time series – uma forma de mostrar uma variável e seus valores ao longo do tempo. Na Figura 42, pode-se notar alguns exemplos de possíveis gráficos e visões que o Grafana permite e que foram testados durante essa parte do trabalho.

Figura 42 - Exemplo de possíveis visualizações que poderia ser utilizada no Grafana para os dados obtidos

(50)

Para garantir a responsividade das telas elaboradas e a qualidade da entrega das visualizações do trabalho, houve atenção na montagem dos elementos que compõem ambas as telas montadas. Principalmente pelo uso de técnicas de responsividade de HTML e CSS – vide Figura 43 – buscou-se que os elementos fizessem sentido em telas de tamanhos distintos e em diferentes dispositivos (como por exemplo entre desktop, tablet e smartfone).

Figura 43 - Exemplo de código HTML e CSS utilizado para garantir a responsividade em diferentes telas

5.2. Casos especiais obtidos

Houve alguns casos especiais na montagem das visualizações que exigiram que cálculos fossem realizados por parte do Grafana / InfluxDB para que se pudesse obter a visão requerida.

Foram os que precisavam de “Energia convertida desde o último dia”, “Energia convertida desde o último mês” e “Energia convertida desde o último ano”.

(51)

Isto se deu, principalmente, pois a informação de energia coletada instantaneamente pelo inversor não é fornecida como um valor em um período, somente o que está sendo acumulado ao longo do dia pela variável “daily_yield_energy” e desde o início da instalação do inversor por

“accumulated_yield_energy”, entre outros neste âmbito.

Dessa forma, para obter o valor da energia acumulada ao longo de X minutos, foi necessário pegar o valor que estava em uma das variáveis citadas em um instante anterior e o valor respectivamente atual, subtrair e tratar o dado para que ele correspondesse com a realidade.

Para obter a energia coletada ao longo de períodos durante o dia, primeiramente, desenvolveu-se o código presente em influxdata na Figura 44. Pode-se perceber que o início do código realiza a extração da variável “daily_yield_energy” e a salva em raw_data. Então, posteriormente, separa-se o último valor coletado em 10 min e o primeiro em 10 min em uma janela definida em dois vetores separados, os upper_value e lower_value. Por fim, realiza-se a união dos valores, subtraindo a diferença e aplicando um filtro para caso algum destes fique sem par – evitando assim que o último valor da lista fique isolado e demonstre um valor irreal na visualização.

Figura 44 - Código utilizado para resolver a questão do caso de energia coletada no dia

Fonte: Bloco de notas, autoria própria

Analogamente ao desenvolvido na Figura 44, resolveu-se também a questão para conseguir energia coletada por dia do último mês até a data presente, pelo código na Figura 45. Nela, pode- se perceber o uso dos dados coletados no último mês, realizando uma união por dia e pegando o último valor da variável daily_yield_energy. Para obter então a energia no mês, bastou configurar no próprio Grafana para somar todos os valores obtidos por essa transformação com InfluxData.

(52)

Figura 45 - Código utilizado para resolver a questão do caso de energia coletada por dia do último mês até a data atual

De forma semelhante, realizou-se o que foi feito na Figura 45 para resolver a problemática de possuir a energia coletada por mês do último ano até a data atual, vide Figura 46. As únicas distinções são que o InfluxData considera 365 dias ao invés de um mês e que é somado a janela do último valor de cada dia com o total por mês.

Figura 46 - Código utilizado para resolver a questão do caso de energia coletada por mês do último ano

5.3. Configuração de aviso caso o sistema pare de enviar dados

Uma das preocupações que houve no desenvolvimento do trabalho foi garantir que o administrador do painel pudesse verificar se o sistema embarcado com a sua integração com a arquitetura está funcionando. E que, caso houvesse algum problema, que fosse enviado um alerta de que algo está errado. Dessa forma, optou-se por utilizar a própria funcionalidade de alerta do Grafana que, como é a última interface em que o dado está, caso haja algum problema nessa parte quer dizer que algo não está funcionando corretamente.

Observa-se na Figura 47 as configurações que foram feitas para o envio da mensagem para o administrador. Pode-se notar que o próprio Grafana possibilita montar uma mensagem