Sistema de monotorização wi-fi orientado a uma unidade de produção de energia eólica

Faculdade de Engenharia da Universidade do Porto Sistema de Monitorização Wi-Fi Orientado a Uma Unidade de Produção Eólica Francisco dos Reis de Melo Branquinho VERSÃO DEFINITIVA Dissertação realizada no âmbito do Mestrado Integrado em Engenharia Electrotécnica e de Computadores Major Automação Orientador: Prof. Dr. João Carlos Ramos Junho de 2014 © Francisco dos Reis de Melo Branquinho, 2014 Resumo Hoje em dia, a necessidade urgente de investir em energias renováveis não representa por certo, uma novidade para ninguém. A sua utilização, cada vez mais crescente, é transversal à maioria dos países desenvolvidos, e Portugal não foge a essa tendência. De acordo com dados do INEGI e APREN, que reportam a dezembro de 2012, o nosso país possui atualmente cerca 4,5 GW de capacidade geradora de base eólica, distribuída por mais de 2500 aerogeradores em todo o território continental. Impõe-se pois, retirar desta fonte de energia limpa o melhor proveito, investindo em infraestruturas e serviços que minimizem as perdas (económicas) e maximizem os lucros das entidades envolvidas. Proporcional ao crescente uso deste tipo de produção, surgem naturalmente, exigências cada vez maiores. Como consequência disso, torna-se imperativo controlar e monitorizar com todo o rigor possível o processo produtivo, visando assim obter a melhor qualidade da energia gerada, a melhor eficiência, e o menor encargo para a entidade produtora. Para esta última concretamente, os sistemas de monitorização sem fios prestam hoje em dia um enorme apoio, permitindo a leitura remota de todos os dados de um aerogerador sem necessidade de ligação física à máquina. Desta forma, proporciona-se aos operadores a liberdade de uma leitura em qualquer dispositivo móvel (PC, tablet ou telemóvel), bem como uma resposta ágil e célere no terreno, tanto em cenários de produção regulares, como em situações de falha, anomalia, avaria, etc. O propósito fundamental desta dissertação vai de encontro, precisamente, à necessidade de desenvolver um sistema de monitorização sem fios orientado a uma unidade de produção eólica, instalada no topo da biblioteca da FEUP. Pretende-se que este sistema seja capaz de requisitar ao aerogerador todos os seus sinais elétricos (4 correntes e 3 tensões), que os envie via sem fios para um PC nas proximidades da biblioteca, e por fim, que neste último sejam visualizados todos os sinais, juntamente com alguns parâmetros de QEE introduzida na rede. A razão última deste documento, é, nesse sentido, detalhar todo o desenvolvimento do sistema de monitorização descrito e fundamentar os passos dados na busca dos objetivos traçados. Abstract Nowadays, the urgent need to invest in renewable energy is certainly not great new to anyone. Increasingly growing among all developed contries, included Portugal, according to recent studies from INEGI and APREN - which relate to December 2012 - our country currently has almost 4.5 GW of wind generating capacity, spread over more than 2,500 wind turbines across the mainland. Therefore, we must draw this clean energy source the best advantage by investing in infrastructure and services that minimize losses (economic) and maximize the profits of the entities involved. Commensurate with this trend, an increased use of this type of production, increasing demands naturally arises. As a result, it becomes imperative to control and monitor the full rigor possible the production process, thus aiming to get the best quality of generated power, better efficiency, and the lowest cost to the producing agency. For the latter specifically, wireless monitoring systems nowadays provide tremendous support, enabling remote reading of all data from a wind turbine without the need for physical connection to the machine. Thus, there is provided operators the freedom of a read on any mobile device (PC, tablet or mobile phone), as well as a flexible and rapid response on the ground, both in regular production scenarios, such as in situations of failure, malfunction, breakdowns. The fundamental purpose of this dissertation meets precisely the need to develop a monitoring system wireless walked to a wind generation unit, installed at the top of the FEUP library. It is intended that this system be able to request the turbine all their electrical signals (4 currents and voltages 3), which send them wirelessly to a PC near the library, and finally, that the latter are viewed all signs, along with some of PQ parameters fed into the grid. The last reason this document is, in this sense, detailing the whole development of the monitoring system described and explains the steps taken in pursuit of stated objectives. Agradecimentos Ao meu pai, a quem devo parte do meu trajeto académico. Ao meu orientador, Prof. Dr. Carlos João Ramos, por todo o apoio e aconselhamento com que me guiou até agora, pela disponibilidade total que me reservou durante os últimos meses e pela flexibilidade e tolerância que teve para comigo nos momentos delicados do projeto. Aos meus colegas mais próximos nesta derradeira fase do curso - laboratório I002 – que me deram a mão nos momentos de maior aperto e me ajudaram a dominar um sem número de matérias. À minha namorada, a minha confidente de sempre, o meu diário de bordo durante todo o projeto, que sempre me motivou e procurou ajudar em todos os sentidos. Nos melhores e nos piores momentos, o denominador comum foste sempre tu. Obrigado Inês. À Engenharia Radio, com quem colaboro desde 2009, e cujo estúdio serviu diversas vezes como “pano de fundo” para as minhas madrugadas de trabalho. Muito grato a todos aqueles com quem me cruzei nessa casa e com quem partilhei a paixão de fazer radio. Ao meu círculo de amigos, com quem cresci e me fiz uma pessoa melhor, e que sempre me presenteou com os melhores momentos. Foram eles o eletrão de valência ao qual liguei o meu durante toda esta odisseia, e com quem partilhei um número incontável de experiências, indispensáveis à minha formação académica, e não só. A todos eles, que figuram no prefácio deste documento, mas principalmente ao meu amigo Gustavo, um glorioso obrigado! Ao pessoal docente e não docente da Faculdade de Engenharia da Universidade do Porto, com quem tive o prazer de privar e de me instruir. Se hoje estou prestes a graduar-me como engenheiro, também foi à custa deles. Bem-haja. Abreviaturas e Símbolos AC Arternating Current ADC Analog-to-Digital Converter API Application Programming Interface APREN Associação das Energias Renováveis ASCII American Standard Code for Information Interchange CRC Cyclic redundancy check DC Direct Current DEEC Departamento de Engenharia Eletrotécnica e de Computadores DFT Discret Fourier Transform DSSS Direct-sequence Spread Spectrum INEGI Instituto de Engenharia Mecânica e Gestão Industrial IEC International Eletrotechnical Commission FEUP Faculdade de Engenharia da Universidade do Porto FFD Full Function Device FFT Fast Fourier Transform GUI Graphic User Interface HTML Hyper-Text MarkUp Language IEEE Institute of Electrical and Eletronics Engineers OSI Open Systems Interconnection QEE Qualidade de Energia Elétrica RDF Reduce Funcion Device SMEE Sistema de Monitorização de Energia Elétrica SPI Serial Peripheral Interface THD Total harmonic distortion UART Universal Asynchronous Receiver/Transmitter UML Unified Modeling Language USB Universal System Bus VB Visual Basic Wi-Fi Wireless Fidelity Capítulo 1 Introdução A ameaça proeminente do aquecimento global podia muito bem ser o rótulo do século XXI. Todos os anos são divulgados novos estudos que revelam as suas consequências nefastas, denunciando a sua origem e os principais autores das agressões ao meio ambiente. Uma das origens identificada há mais tempo, e cujo debate já se arrasta há décadas (ainda antes do protocolo de Quioto 1 ) é o uso dos combustíveis fósseis. Altamente poluentes, com implicações diretas no meio ambiente e na saúde pública das populações, o uso massivo dos combustíveis fósseis tornou-se assim uma preocupação premente e universal. Isso conduziu à procura de alternativas mais sustentáveis e ecológicas, para colmatar a dependência energética mundial desse tipo de fonte poluidora, donde emergiu uma solução (não inteiramente nova, mas) cujo aproveitamento no terreno podia ser melhorado: as energias de fonte renovável. Esta solução mostrou-se a mais atrativa sob todos os pontos de vista, tendo desencadeado uma aplicação crescente e global. Portugal, em particular, não ficou imune a esta tendência, tendo por isso reforçado, desde finais da década de 90, o aproveitamento dos seus recursos renováveis, com particular destaque para o setor hídrico e eólico. Setores dos quais, convém referir, depende atualmente cerca de 50% da produção energética nacional – como revela a figura abaixo: Figura 1.1 – Produção da eletricidade por fonte em Portugal Continental em 2013 [1] 1 Protocolo de Quioto – protocolo internacional que impôs a redução de emissões agressoras. 2 Introdução 1.1. Enquadramento geral Como se referiu no último parágrafo, as energias renováveis desempenham, atualmente, um papel preponderante na produção energética do nosso país. No que concerne à produção eólica, esta atinge cerca de 23% do total, tendo subido exponencialmente desde do final do século XX, motivo pelo qual totaliza hoje, um valor de 4,5 GW de capacidade geradora – tal como evidencia a figura abaixo: Em trajetória paralela com esta realidade, figuram os sistemas de supervisão e controlo, cuja necessidade e requisitos têm aumentado na mesma proporção. Para tal, tem contribuído uma alteração no conceito de exploração das redes de energia, por força do aparecimento de diversas entidades produtoras privadas, que se acrescentaram à rede ao longo dos anos. Na verdade, o crescente aparecimento destes novos produtores na rede de distribuição, impôs como necessária uma vigilância e controlo mais apertados, por forma a salvaguardar a qualidade do serviço aos consumidores e evitar problemas de congestionamento nas redes. A mudança de paradigma foi verdadeiramente profunda, obrigando a uma revisão do conceito inicialmente implementado, build and connect, tendo este sido suplantado pelo connect and manage. Em virtude desta alteração, que promoveu o aparecimento das smartgrids, e devido ao aumento de volume da produção dispersa, impôs-se portanto uma gestão mais rigorosa e cuidada do trânsito de potência nas redes de distribuição. Para tal, contribuíram os sistemas de monitorização de energia, permitindo uma leitura em tempo real dos dados, tanto ao nível do processo produtivo, como em vários pontos da rede elétrica, fornecendo assim dados de interesse para matérias de decisão, controlo, armazenamento, análise, etc. O aparecimento deste tipo de sistemas proporcionou uma observação mais pormenorizada e atenta por parte das entidades produtoras e reguladoras, e, em última análise, uma maior sensibilidade para aferir a qualidade da energia na rede. Com reflexo direto no serviço prestado na saúde da rede, uso destes sistemas permitiu ainda às entidades produtoras uma gestão cada vez mais eficiente dos seus recursos, minimizando os custos envolvidos, e melhorando a sua eficiência. Figura 1.2 - Capacidade geradora acumulada por ano [1] Objetivos e requisitos do sistema 3 1.2. Objetivos e requisitos do sistema A proliferação da eletrónica de potência introduziu melhorias substanciais no capítulo do processamento de energia, tornando-o mais eficiente, rentável e económico. Todavia, o facto da maioria dos dispositivos semicondutores usados ser não lineares, conduziu à introdução de perturbações muito significativas na energia gerada, degradando assim a sua qualidade. Uma das principais causas para esse degradamento de qualidade, relaciona-se com a introdução de correntes não sinusoides na rede, que por sua vez originam a formação de harmónicos. Estas perturbações, podem ser fatais tanto para os próprios dispositivos que as introduzem (pois estes são, regra geral, muito sensíveis às variações), como para o consumo de energia, que deve sempre ser tido em conta. No âmbito desta questão, os sistemas de monitorização anteriormente referidos dão uma resposta categórica, permitindo não só a leitura e registo dos dados requisitados, bem como a análise de vários parâmetros de qualidade, relevantes para os consumidores e para a rede. Isto permite às entidades produtoras verificar se a produção está dentro dos conformes e agir com vista à gestão de recursos mais vantajosa. 1.2.1. Objetivos gerais Pretende-se com a presente dissertação, conceber um sistema de monitorização sem fios, orientado a um pequeno sistema de produção eólico instalado no topo da biblioteca da FEUP. Para tal, deve ser possível requisitar a este, mediante a “sensorização” adequada, os sinais:  3 correntes AC:  2 tensões AC: VRS e VST  1 corrente DC: IDC  1 tensão DC: VDC; Estes sinais, devem depois ser enviados por um módulo de comunicação sem fios para um qualquer PC, sendo neste último representados (com a maior latência possível) através de uma aplicação concebida para o efeito. Esta, deve incluir uma análise em frequência de cada sinal, o cálculo do THD, uma análise fasorial dos sinais AC, bem como disponibilizar os valores médios, eficazes, máximos e mínimos de todas as grandezas elétricas inerentes. Além disso, deve ainda ser capaz de armazenar todos os dados recebidos e possibilitar a sua consulta em diferentes periódicos temporais. 1.2.2. Requisitos do sistema Em linha com os principais objetivos traçados acima, podem-se definir logo à partida três vetores de desenvolvimento no âmbito deste trabalho: módulo de comunicação wireless e seu protocolo, a plataforma de hardware responsável pela aquisição de dados, e uma plataforma software a executar no PC. Para cada delas, fez-se o levantamento dos requisitos funcionais procurando ir de encontro às necessidades reais do operador. Nesse sentido, começamos por classificar as três áreas gerais de funcionamento do sistema da seguinte forma:  Módulo de comunicação wireless e protocolo: responsável por transmitir os dados entre a turbina eólica e o PC (ou outro dispositivo capaz de suportar a plataforma software), de acordo com o protocolo que melhor sirva os interesses de leitura;  Plataforma hardware (bloco de aquisição ou nó-sensor): encarregue de sensorizar os sinais através de uma carta de aquisição de dados e de converter-los através de 4 Introdução ADCs; responsável por reencaminhar os dados para o módulo de comunicação sem fios em condições destes serem transmitidos sequencialmente;  Plataforma software (aplicação gráfica): responsável por receber e processar os dados do módulo de comunicação sem fios, com base nos quais deve mostrar os valores, gráficos e diagramas num formato intuitivo, contemplando todas as funções enumeradas no ponto anterior; Tendo isto em consideração, determinaram-se os requisitos funcionais e não funcionais do sistema de monitorização. No que diz respeito aos requisitos funcionais, foram tomados em consideração os objetivos descritos no ponto anterior (1.2.1), e algumas questões formais de aspeto, essenciais a uma melhor captura da informação por parte do utilizador. Tabela 1.1 — Requisitos funcionais Requisitos funcionais Justificação Efetuar a leitura de todos os sinais AC e DC da turbina eólica: IR, IS IT VRS VST IDC e VDC a partir dos conversores analógico-digitais do bloco de aquisição de dados Apresentar a forma de onda de um, ou de vários sinais recebidos em simultâneo, no Time Domínain da aplicação Permitir a visualização dos sinais em real time Incluir a função de zoom no painel Time Domain, tanto na dimensão temporal como nas grandezas elétricas Consultar com maior detalhe os sinais lidos Apresentar os valores médios, eficazes, máximos e mínimos no painel Values da aplicação Conferir os valores recebidos Efetuar cálculo da frequência, potência ativa, reativa e fator de potência, bem como respetivos mínimos, máximos e médios, e apresentar no painel Values Verificar os valores gerais de produção e sua validade Efetuar o cálculo dos fasores IR, IS IT VRS VST, desfasamento por fase, e sua representação no painel Phasor Diagram Verificar o equilíbrio das fases e seu desvio Apresentar a discretização dos sinais e calcular a taxa de distorção harmónica total no painel Frequency Domain Aferir a qualidade das ondas e os harmónicos Armazenar todos os valores recebidos na aplicação, em disco local, de forma permanente Permitir a consulta dos dados armazenados em histórico (até 1 ano), apresentando-os na janela History Window Verificar a produção em períodos críticos; Permitir a exportação de imagens dos diferentes painéis (Time Domain, Frequency Domain, Phasor Diagram) Facilitar a gravação e envio a outros Permitir a receção e consulta de todas os dados referidos, remotamente, até uma distância máxima de 200 metros Arquitetura geral do sistema 5 Já no domínio dos requisitos não funcionais, estes foram definidos com base em funções que o próprio sistema devia assegurar e sem as quais todo o processo de monitorização ficaria comprometido: qualidade de ligação, estabilidade, robustez, performance, etc. Tabela 1.2 – Requisitos não funcionais Requisitos não funcionais Justificação Apresentar uma conexão estável com bloco de aquisição de dados e exibir o seu estado atual no Control Panel Manter o operador ligado e informado Efetuar o armazenamento de dados em formato binário Poupar espaço no disco e compactar leituras Manter o tempo de resposta da aplicação, entre atualizações sucessivas, menor que 10 s Não permitir consulta de dados para períodos temporais superiores a 48 horas Evitar processos muito demorados Efetuar o cálculo de todos os valores médios, eficazes, máximos e mínimos ainda no bloco de aquisição de dados (ou seja, antes do envio para a aplicação) Otimizar o tempo de processamento na aplicação e aquisição Incluir em todas as comunicações entre bloco de aquisição e a aplicação um método de verificação de erros: checksum Inspecionar o conjunto de dados recebidos e evitar leituras erradas Mostrar a força do sinal recebido do bloco de aquisição de dados no Control Panel Evitar o afastamento excessivo do PC e a ruptura da ligação Configurar a comunicação entre o bloco de aquisição e aplicação como mestre-escravo Usar ADCs com um mínimo de 12 bits de resolução Permitir leituras com maior precisão Efetuar uma análise discreta dos sinais recebidos, no mínimo, até ao 24º harmónico Imposto pelos padrões de qualidade da EDP Permitir a predefinição do tempo de funcionamento do sistema – entre 1 hora e 15 dias Definir um limite temporal para operar sem consulta Criar condições de extensibilidade do sistema a um ou mais DTEs, através de uma rede de comunicações local 1.3. Arquitetura geral do sistema Uma vez definidos os requisitos do sistema funcionais e não funcionais, esboçou-se então a arquitetura geral do sistema, com base em tudo o que foi referido no ponto 1.2. Na figura seguinte apresenta-se, muito simplificadamente, a arquitetura do sistema de monitorização a implementar – muito embora os vários elementos não constem à devida escala: 6 Introdução Figura 1.3 - Arquitetura simplificada do sistema de monitorização sem fios Como se referiu atrás, o sistema de monitorização sem fios deverá incluir uma plataforma hardware, composta por um microcontrolador e diferentes sensores (transdutores de corrente e tensão), conectados a jusante à turbina eólica, e a montante ao módulo de comunicações sem fios. Por sua vez, o terminal oposto do módulo de comunicações sem fios deve ser ligado a um PC onde a plataforma software se desenvolva, de modo a visualizar os sinais requeridos. Importa todavia referir que, no âmbito desta dissertação, não se irá operar diretamente com a turbina eólica, sendo a monitorização e todo o sistema testado na prática com valores da rede elétrica. Por outro lado, a aplicação da rede de comunicação Wi-Fi estendeu-se ao módulo Xbee, que, veremos mais adiante, se adapta melhor aos requisitos em causa. 1.4. Estrutura do documento O propósito central da elaboração deste documento é fundamentar todos os passos dados na execução do projeto e com isso provar a validade das decisões tomadas. Nesse sentido, o presente encontra-se organizado em seis capítulos e quatro anexos. 1.4.1. Capítulos O capítulo 1, que finda com o ponto presente, é inteiramente dedicado à introdução; nele pretende-se enquadrar o assunto no contexto atual da sociedade, definir os objetivos que se visam atingir com o projeto, e definir a estrutura geral do sistema a desenvolver no mesmo. O capítulo 2, por seu lado, apresenta o ponto de situação do estado da arte, dissecando com profundidade os sistemas de monitorização de energia, os módulos de comunicação sem fios e seus principais protocolos, as ferramentas/ambientes de desenvolvimento vulgarmente usada para as aplicações de monitorização, e os parâmetros de qualidade de energia elétrica universalmente aceites, em particular, no contexto da energia eólica No capítulo 3 é explorado o primeiro dos três principais vetores de desenvolvimento desta dissertação: a plataforma hardware. Em primeiro lugar, é escolhido o microcontrolador/ADCs a usar para a aquisição dos sinais, abordada a sua implementação, dimensionada a carta de aquisição de dados a servir de interface entre a turbina eólica (ou rede) e o microcontrolador e, por fim, escolhido o módulo comunicação sem fios que melhor se enquadra na aplicação desenvolvida. Estrutura do documento 7 Mais adiante, o capítulo 4, dedica-se à componente nuclear de todo o projeto, ou seja, à plataforma software e o ambiente de desenvolvimento onde se programa/implementa toda a aplicação gráfica. Neste capítulo apresentam-se alguns dos diagramas UML onde se sustentou a implementação, explicado em detalhe o método de processamento e calculo adotado, bem como exibidas as várias áreas de interesse da interface gráfica da aplicação. O capítulo 5, dedica-se por inteiro à componente experimental do projeto, na qual são descritos os procedimentos laboratoriais que conduziram aos resultados apresentados. Este é um capítulo tripartido em: teste com a carta de aquisição, teste da aplicação, teste de todo o sistema em conjunto, sendo que em todos eles são comparados os resultados esperados com os efetivamente obtidos (principalmente no teste conjunto). Por fim, o capítulo 6, serve para agregar todas as conclusões retiradas de cada um dos capítulos anteriores, criticar os resultados obtidos, aferir a sua consistência e validade face aos resultados reais, bem como assinalar alguns percalços verificados no decorrer do projeto. Por outro lado, este capítulo serve igualmente para traçar os principais vetores de melhoria do projeto no futuro, equacionar novas funções que este possa vir a integrar, ou novas áreas de interesse em que este possa ser útil. 1.4.2. Anexos A organização dos diferentes anexos segue basicamente a mesma estrutura que o resto do documento, sendo divididos em quatro subcapítulos. Nesta secção do documento apresentamse algumas informações complementares, necessárias à compreensão plena do que é exposto nos restantes capítulos, ou, por outro lado, folhas de caraterísticas que sustentam as opções tomadas durante o mesmo. Capítulo 2 Estado da arte Tal como foi explorado no capítulo anterior, o atual cenário energético mundial suscita grandes preocupações, tanto ao nível económico, como ambiental. Ao longo dos tempos, isto tem alterado o modo como encaramos a utilização dos recursos energéticos, sensibilizando as populações e empresas para uma gestão mais eficiente, e questionando a sociedade para as soluções possíveis no âmbito deste problema. Em virtude desta situação, e com o objetivo de controlar o nível de emissões agressoras para o ambiente (e reduzir a dependência global dos combustíveis fosseis) foi promovido no Japão a dezembro de 1997 o protocolo de Quioto. Este protocolo impôs uma redução dos gases responsáveis pelo efeito de estufa, para valores 5% abaixo dos registados em 1990, e exigiu o acordo conjunto de 55 países – razão última, pela qual entrou em vigor apenas em meados de 2005, após muita discórdia e polémica. Da adesão ao protocolo de Quioto1, resultaram reduções bastante significativas ao nível do consumo de energia primária, bem como sólidos investimentos no setor das energias renováveis, dado que se tratam de fontes ecologicamente benéficas e sem emissões [2]. Isto desencadeou o progressivo e crescente aparecimento de novas unidades de produção dispersa, sendo em Portugal mais notório no setor hídrico e eólico. A integração da produção dispersa nas redes elétrica, tornou-se assim cada vez mais um fenómeno generalizado, surgindo como medida de redução das emissões de CO2 através do aumento da produção de base renovável. Este tipo de produção representa o desafio mais importante que se coloca ao sistema elétrico, pois, efetivamente, a geração dispersa é a única maneira de explorar fontes de energia renováveis para produção de energia elétrica [3]. À semelhança de qualquer outro setor produtivo, um dos processos críticos para assegurar uma boa gestão de recursos e evitar prejudiciais perdas, é a monitorização. O caso do sector energético não é exceção, e no seu contexto, os sistemas de monitorização desempenham um papel absolutamente nuclear, uma vez que permitem registar todos os dados de produção em tempo real e deles retirar ilações quanto à qualidade da energia gerada. O registo e controlo dessa qualidade é, na verdade, uma das finalidades centrais dos sistemas de monitorização, procurando assim pôr cobro ao crescente degradamento da energia produzida, em virtude do crescente da produção dispersa e do aumento de dispositivos sensíveis na rede. Importa por isso perceber, no âmbito do setor energético de produção, quais as soluções adotadas para os SMEE, e em particular, aquelas que se orientam aos sistemas produtores de base eólica. Qualidade de energia elétrica (QEE) 15 A sua origem está relacionada com defeitos na rede de transporte e distribuição, ligação de grandes cargas e arranque de motores de grande potência. As suas consequências podem ser o disparo de disjuntores e de relés eletromecânicos, perda de rendimento nas máquinas rotativas, paragem de sistemas de controlo industrial baseados em microprocessador, entre outras. Os parâmetros de qualidade calculados no âmbito destas variações de tensão constam das normas IEC 61400-21 (com ride through fault) e IEC 61000-3-7, que fornecem a expressão para a variações de tensão, e os valores limite para amplitudes de variação de tensão [11]: ( ) ( ) Onde ku(Ψk) é o fator de variação da tensão calculado para um ângulo de rede Ψk. Convém ainda referir, por último, que sob condições fracas de vento, uma turbina eólica pode ainda parar e recomeçar diversas vezes, cenário no qual o flicker resultante das várias cavas de tensão pode ser calculada por: √( ) N.B.: este índice é considerado de longa duração (lt, long term) pois se verifica com mais persistência e maior frequência em longos períodos temporais. C. Distorção harmónica A distorção harmónica consiste na deformação da onda sinusoide caraterística da corrente alternada, por força das frequências múltiplas da fundamental (em Portugal – 50 Hz) que são injetadas – tal como mostra a figura 2.6: Esta distorção pode ser provocada por cargas capacitivas ou indutivas presentes na rede (baterias de condensadores, transformadores, motores) ou por dispositivos cuja resposta não linear no tempo (semicondutores) contribua para a introdução de correntes não sinusoides no sistema elétrico. Como resultado, cria-se um trânsito de potência adicional que pode levar ao aquecimento das cargas indutivas, transformadores, baterias de condensadores e neutros. Nesse sentido, e atendendo às consequências imprevisíveis de propagação dos harmónicos nas redes, exige-se uma limitação destas perturbações. De acordo com a norma IEC 61800-3, os limites para a emissão de harmónicas, tanto em tensão como em corrente, são os que se apresentam nas tabelas abaixo: Figura 2.6 – Exemplo de uma sinusoide deformada com harmónicos [9] 16 Estado da arte Tabela 2.1 – Limites para harmónicos em corrente Isc/IL <20A 20<50A 50<100A 100<1000A >1000A <11 4.0 7.0 10.0 12.0 15.0 11<h<17 2.0 3.5 4.5 5.5 7.0 17<h<23 1.5 2.5 4.0 5.0 6.0 23<h<35 0.6 1.0 1.5 2.0 2.5 35>h 0.3 0.5 0.7 1.0 1.4 THD 5.0 8.0 12.0 15.0 20.0 Onde Isc representa a corrente de curto-circuito e IL a corrente (por fase) da componente fundamental da frequência e h a ordem harmónica. Tabela 2.2 - Limites para harmónicos em tensão Ordem harmónica Vn<1kV 1kV <Vn<13,8kV 13,8kV <Vn<69kV 69kV <Vn<230kV Ímpares não múltiplas de 3 5 7.5 6.0 4.5 2.5 7 6.5 5.0 4.0 2.0 11 4.5 3.5 3.0 1.5 13 4.0 3.0 2.5 1.5 17 2.5 2.0 1.5 1.0 19 2.0 1.5 1.5 1.0 23 2.0 1.5 1.5 1.0 25 2.0 1.5 1.5 1.0 >25 1.5 1.0 1.0 0.5 Ímpares multiplas de 3 3 6.5 5.0 4.0 2.0 9 2.0 1.5 1.5 1.0 15 1.0 0.5 0.5 0.5 21 1.0 0.5 0.5 0.5 >21 1.0 0.5 0.5 0.5 Pares 2 2.5 2.0 1.5 1.0 4 1.5 1.0 1.0 0.5 6 1.0 0.5 0.5 0.5 8 1.0 0.5 0.5 0.5 10 1.0 0.5 0.5 0.5 12 1.0 0.5 0.5 0.5 >12 1.0 0.5 0.5 0.5 THD 5 % 2,5% (<161kV) 1,5% (>161kV) Para o cálculo do THD a expressão que vulgarmente se aplica para corrente e tensão é: √∑ √( ) √∑ √( ) Com h o índice harmónico do sinal, normalmente limitado a 50, Ief e Vef corrente e tensão eficaz, I1 e V1 corrente e tensão do primeiro harmónico. Redes de comunicações wireless 17 2.3 Redes de comunicações wireless 2.3.1. Introdução As redes wireless locais começaram a divulgar-se no final da década de 90 e, desde cedo, se aplicaram aos mais variados planos: industriais, domésticos, etc. Como a própria tradução assim o indica - sem fio – o desenvolvimento desta tecnologia procurou ser uma alternativa às redes convencionais, usufruindo de uma mais fácil implementação e fornecendo as mesmas funcionalidades que as redes por cabo. Dependendo da aplicação a que é submetida uma rede sem fios, esta pode realizar a comunicação entre os seus equipamentos através de diferentes tipos de transmissão de sinais: radiofrequência, micro-onda, laser e infravermelho, etc. 2.3.2. Enquadramento no tema Como se deu conta na fase introdutória do estado da arte, a produção dispersa é hoje um dos desafios a que temos de responder face à necessidade vigente de investir nas energias de base renovável. No âmbito da sua utilização, os sistemas de monitorização revelam-se como um verdadeiro aliado de peso, não só pela leitura de todos os parâmetros de produção que disponibiliza ao operador, de forma intuitiva e cómoda, mas por força também das smartgrids – referidas mais atrás - onde frequentemente se insere. Porém, para produção dispersa, a monitorização habitualmente implementada foge um pouco ao convencional (onde a camada de ligação de dados é física) devido ao facto de se tratarem muitas vezes de locais remotos, onde esta ligação representa gastos muito avultados de instalação e manutenção. Como tal, nestes casos é vulgarmente implementada uma rede de comunicações wireless, assegurando a troca de dados entre o nó sensor – no caso do SMEE a desenvolver, uma turbina eólica - e o terminal de leitura, fixo ou móvel, onde a aplicação gráfica se desenvolve. 2.3.3. Classificação das redes wireless As recomendações do IEEE 3 , nomeadamente as que dizem respeito à série 802, servem de modelo para a implementação de protocolos em redes sem fios. Segundo os padrões definidos pela organização científica, as redes sem fios subdividem-se em quatro grupos distintos [13]:  WPAN (Wireless Personal Area Network) – em que se enquadram as redes sem fios de pequeno / médio alcance (conforme o local de implementação), orientadas ao uso de dispositivos portáteis e móveis, tais como: PCs, PDAs, telemóveis, etc.  WLAN (Wireless Local Area Network) – onde se consideram as tecnologias sem fios destinadas à interligação de redes locais com médio alcançe, complementando as redes tradicionais por cabo, funcionando como extensão ou alternativa;  WMAN (Wireless Metropolitan Area Network) – onde constam as tecnologias usadas pelos operadores de telecomunicações, com alcance aproximado de 6 a 10km;  WWAN (Wireless Wide Area Network) – grupo que abrange tecnologias orientadas a redes de longa distância, usadas em redes de interligação para os serviços de voz e alguns serviços de dados. 3 IEEE (Institute of Electrical and Eletronics Engineers) organização profissional sem fins lucrativos dedicada à pesquisa e promoção de conhecimento na área da eletrotécnia 18 Estado da arte A esmagadora maioria das implementações de redes de comunicação sem fios que operam hoje em dia, estão afetas aos grupos WLANs, WMANs e WWANs, sendo todas elas orientadas a utilizadores finais, pequenas e grandes empresas, onde o objetivo fulcral é a transferência de grandes volumes de dados e voz em altas velocidades. Em contraste, as redes sem fios PAN, destinadas exclusivamente ao controlo de dispositivos como relés, ventilação, aquecimento, geradores e motores são ainda pouco comuns. De igual forma, mesmo ao nível doméstico, são poucas as redes sem fio utilizadas no controlo de pequenos eletrodomésticos, brinquedos e na aquisição de dados de sensores, como temperatura, luminosidade, humidade, pressão, etc. No seio das redes WPAN existentes, a mais recente e promissora é a que usa o protocolo ZigBee 4 IEEE 802.15.4 (que veremos no ponto seguinte), sobre o qual recai, convém referir, um enorme interesse no âmbito desta dissertação. 2.3.4. Protocolos de comunicação No âmbito desta norma, IEEE 802, diversos padrões para redes sem fio são classificados de acordo com a distância máxima de transmissão, a taxa de dados, entre outros fatores. Estes padrões são na verdade, ramificações da norma IEEE 802, estando diretamente associados aos diferentes grupos do ponto anterior. Na tabela apresentada acima, apenas constam os protocolos 802.15 e 802.11, aplicados às redes WPAN e WLAN, respetivamente. A análise efetuada incidiu apenas sobre estas, uma vez 3 ZigBee – Protocolo de comunicação (analogia entre o modo de funcionamento da rede em malha e o modo como as abelhas) Figura 2.7 - Protocolos de comunicações sem fios Tabela 2.3 - Classificação de protocolos de comunicação wireless [14] Redes de comunicações wireless 19 que no contexto desta dissertação não se proporcionava explorar as duas restantes – WMAN e WWAN, que se orientam a outro tipo de aplicações. A. Protocolo IEEE 802.11 (Wi-Fi) O IEEE 802.11 é caracterizado por ser uma família de protocolos de comunicação de redes wireless que foram e continuam a ser melhorados, com o intuito de simplificar a comunicação entre dispositivos sem fios de diferentes fabricantes – evitando problemas de compatibilidade entre equipamentos. Esta família de protocolos é dividida em vários sub-padrões, os quais os mais utilizados atualmente são o IEEE 802.11a, IEEE 802.11b e IEEE 802.11g. O padrão 802.11 b foi a primeiro das ramificações da família IEEE 802.11 a ser aprovada. Também conhecido como Wireless Fidelity (Wi-Fi), este utiliza a técnica de difusão espectral DSSS para realizar a comunicação entre os dispositivos, operando na faixa de frequência da banda de 2,4 GHz. Este padrão utiliza quatro velocidades para a transmissão e receção de dados, sendo elas um, dois, 5.5 e 11 Mbps e possibilita um máximo de 32 clientes conectados. As restantes ramificações deste protocolo permitem velocidades de transmissão bastante superiores (no caso do 11.g, até o máximo de 600 Mbps), operando em gamas de frequências distintas, e com variações ao nível do número de clientes máximo admitido e alcance espacial envolvente. B. Protocolo IEEE 802.15 (ZigBee) O IEEE 802.15, corresponde ao protocolo ZigBee, permite comunicações robustas e opera na frequência ISM3, não requerendo qualquer tipo de licenciamento. Abrange a faixa de 2,4 GHz em todo o mundo, 915Mhz na América e 868Mhz na Europa. As taxas de transferência de dados são de 250kbps, 40kbps e 20kbps para 2,4GHz, 915Mhz e 868Mhz, respetivamente. As redes implementadas com base no protocolo ZigBee oferecem excelente imunidade a interferências e dispõem de uma grande capacidade de hospedar milhares de dispositivos ligados na mesma rede (até 65.000 dispositivos por canal). O protocolo ZigBee é normalmente aplicado em ambientes industriais, tendo em conta que as características destas redes não requerem grandes velocidades, o que se enquadra perfeitamente nas suas caraterísticas. O protocolo ZigBee desfruta das seguintes caraterísticas:  Consumo energético baixo e implementação simples, a baixo custo;  Dois estados de funcionamento: active para transmissão e receção e sleep;  Simplicidade de configuração e redundância de dispositivos (operação segura);  Densidade elevada de nós suportados pela rede: camadas PHY 5 e MAC6 permitem que as redes funcionem com grande número de dispositivos ativos. Este atributo é crítico para aplicações com sensores nas redes de controlo;  Protocolo simples que permite a transferência fiável de dados com segurança. 2.3.5. Estrutura do protocolo Zigbee A arquitetura do protocolo ZigBee, tal como em tantos outros protocolos, é composta por camadas, formando uma estrutura hierárquica. Cada camada fornece uma interface para a camada superior através do ponto de acesso ao serviço SAP 6 . Cada SAP, por sua vez, suporta um determinado número de primitivas de serviço para ativar a funcionalidade solicitada pela 5 PHY (Physical) - Camada física do protocolo ZigBee 6 SAP - Service Access Point 20 Estado da arte camada imediatamente superior. Apesar do protocolo ZigBee se basear no modelo OSI 7 (que é definido por sete camadas), a arquitetura do protocolo ZigBee define somente cinco camadas como necessárias para atingir o conjunto de funcionalidades desejadas [15]: A. A pilha protocolar As duas camadas inferiores, a camada física (PHY) e a camada de controlo de acesso ao meio (MAC), foram definidas pelas norma IEEE 802.15.4. As restantes camadas de rede foram concebidas especificamente para o protocolo ZigBee, sendo elas: a camada de rede NWK e o Framework para a camada de aplicação (API). Nesta camada estão incluídas a subcamada de suporte aplicacional (APS), que asseguram a ligação da camada de aplicação, e o objeto de dispositivo ZigBee (ZDO - ZigBee Device Object) [15].  IEEE 802.15.4 PHY: camada física (PHY) projetada para acomodar as necessidades de interfaces de baixo custo, permitindo níveis elevados de integração. O uso da técnica de transmissão de Sequência Direta 8 permite que os equipamentos sejam muito simples, possibilitando implementações com custos reduzidos.  IEEE 802.15.4 MAC: camada de controlo de acesso ao meio, prevista para permitir topologias múltiplas com baixa complexidade (abordadas na página seguinte) onde a gestão de energia, por exemplo, não requer modos de operação complexos. Esta camada também permite que um dispositivo com funcionalidade reduzida (RDF 9 ) opere na rede sem a necessidade de grandes quantidades de memória disponíveis, 7 - OSI (Open Systems Interconnection) 8 - DSSS - Transmissão de sequência direta (Direct-sequence Spread Spectrum) 9 - RDF – Dispositivo com funcionalidade reduzida (Reduce Function Device) Figura 2.8 – A pilha de protocolos ZigBee [15] Redes de comunicações wireless 21 podendo controlar também um grande número de dispositivos sem a necessidade de colocá-los on hold, como ocorre em algumas tecnologias sem fio.  ZigBee NWK: camada de rede que usa um algoritmo que permite implementações da pilha de protocolos, visando equilibrar os custos das unidades com aplicações específicas. Caso das baterias, que se procura conceber soluções específicas para a aplicação, com boa relação preço qualidade.  API: formada pela subcamada de suporte à aplicação, que fornece uma interface entre a camada de rede e a camada de aplicação através de um conjunto geral de serviços que são usados pelo ZDO 10 e os outros objetos da aplicação definidos pelo fabricante. Os serviços fornecidos no suporte à aplicação são:  Descovery – serviço que verifica a existência de outros pontos ativos na área de alcance do dispositivo, para serviços de troca de dados;  Binding – serviço que liga os vários dispositivos, tendo em conta as necessidades e serviços. B. Tipos de dispositivos O protocolo 802.15.4 distingue os dispositivos com base no seu hardware e capacidade. De acordo com este padrão, existem duas classes de dispositivos: Full Function Device (FFD) e Reduce Function Device (RFD). Os FFD são dispositivos robustos a nível de hardware, e foram concebidos para suportar maiores funcionalidades do protocolo, assumindo por isso múltiplas responsabilidades na rede para além de poderem comunicar com outras redes. Têm um consumo energético superior às RFD, porque os dispositivos lógicos não podem ser colocados em modo de sleep, enquanto nas RFD essa funcionalidade é possível. As RFD, em contraste com as FFD, apresentam uma maior simplicidade a nível de hardware, sendo compatíveis com vários microcontroladores de 8 bits e comunicam apenas com dispositivos físicos FFD. Neste contexto, o protocolo ZigBee diferencia três tipos de dispositivos lógicos, que são o coordenador, o router e o end-device. A tabela seguinte resume um pouco as funções que cada um destes dispositivos pode desempenhar na rede: Tabela 2.4 – Tipos e funções de dispositivos na rede ZigBee [16] Dipositvo Cordeenador Router Endpoint Tipo FFD FFD RFD ou FFD Funções na rede Forma a rede, atribui endereços, suporta binding table. Existe apenas um por rede. Permite que mais nós se juntem à rede, ao aumentar o seu alcance físico. Pode também efetuar funções de controlo ou monitorização. Efetua ação de controlo ou monitorização através de dispositivo que lhe esteja associado (sensor, controlador, atuador…). C. Topologia da rede ZigBee Com uma vasta área de aplicação, desde o controlo industrial à domótica, o protocolo ZigBee possui características que o tornam absolutamente único. Dada a sua polivalência e 10 ZDO - ZigBee Device Object 22 Estado da arte versatilidade, ambas já sustentadas ao longo deste capítulo, o ZigBee pode ser utilizado em diferentes topologías de rede, oferecendo um vasto leque de soluções: estrela (star), malha (mesh) ou árvore (cluster tree), bem como permitindo o estabelecimento de redes de nós Adhoc 11 . Para além disso, o ZigBee oferece outras vantagens que, no contexto das redes, são muito valorizadas: por exemplo, possui um tempo de ligação à rede menor que os outros protocolos, apresenta uma maior rapidez na passagem do modo standby a ativo, e possui latência baixa. Na figura abaixo estão ilustradas as principais topologías: A topologia em estrela (à esquerda) é a mais simples das topologias numa rede ZigBee e contém um único coordenador com até 65.536 terminais. O coordenador é responsável por inicializar e manter os terminais na rede. Uma vez inicializada a comunicação os terminais só podem trocar dados com o coordenador. Na topologia em árvore (ao centro) a relação parent-child é directamente utilizada. Cada nó pertencente a nível hierárquico superior é designado por parent, pelo que o nó que lhe fica associado é designado por child. Este tipo de topologia é adequado para aplicações tolerantes a latência. Como desvantagem, no caso de um nó intermédio falhar, a mensagem não alcançará o destino porque não existe um caminho alternativo (links). De modo a garantir a fiabilidade numa rede ZigBee, a topologia malha (à direita) é a mais adequada. A configuração em malha permite a formação de múltiplos caminhos (links) entre os nós utilizando o protocolo de encaminhamento Table-driven - protocolo que obriga a que cada nó conserve em memória uma ou mais tabelas de encaminhamento, referentes aos nós existentes na rede [17]. Dado que esta topologia apresenta múltiplos caminhos, pelos quais a informação pode fluir, constata-se que é a topologia mais tolerante em caso de haver falhas, sejam provenientes dos nós ou dos caminhos pois apresenta um caminho alternativo para que a informação chegue ao destinatário. D. Modo de operação / comunicação Existem dois modos para operar entre diferentes dispositivos Xbee: o modo transparente, (AT) e o modo comando (API - Application Programming Interface). O modo transparente é o modo pré-definido de todos os Xbee, permitindo que os módulos transmitam de uma forma direta, via porta série, a informação que lhes chega. Devido ao seu baixo nível de robustez, é uma forma bastante ineficiente de comunicar com computadores. Por contraste, o modo de comando é bastante mais complexo, realizando uma reformatação dos dados inicialmente enviados. Esta alteração tem como objetivo que dados trocados sejam mais estruturados e “legíveis” para os dispositivos eletrónicos que interagem com os módulos, criando assim na camada de aplicação do Xbee, uma sequência de dados (frames), que incluem bytes capazes de identificar a sequência de dados em termos do seu início, tamanho, tipo e soma total [18]. 11 Ad hoc – rede espontânea em que todos os nós / terminais funcionam como routers. Figura 2.9 – Topologias em rede [16] Plataforma software / Ambiente de desenvolvimento 23 2.4 Plataforma software / Ambiente de desenvolvimento O estudo e desenvolvimento de sistemas de monitorização em ambiente académico, numa lógica DIY (que se explica em 2.1.3) não é recente e já são bastantes os projetos relacionados com este tema. Importa compreender, no âmbito dos mesmos, quais as soluções vulgarmente adotadas para o seu ambiente de desenvolvimento, e estabelecer o balanço entre vantagens e desvantagens de que cada um usufrui. Esta análise é de sobejo interesse para a presente dissertação, pois dela depende a escolha sobre a plataforma software a usar - que representa o núcleo duro do sistema que se pretende conceber. Vejamos alguns exemplos: 2.4.1. Labview Desenvolvido em 2003 por um grupo de investigadores da U. Minho, denomina-se “Sistema de Monitorização da Qualidade da Energia Elétrica Baseado em PC” e é um sistema low cost, orientado à monitorização de parâmetros de qualidade da rede elétrica e gestão de energia. Este sistema usa uma aplicação em linguagem de programação gráfica LabView, responsável por registar todos os dados adquiridos da rede, fornece-los em formato de tabelas ou gráficos e exportar relatórios em formato HTML. Esta aplicação LabView, executa ininterruptamente a aquisição de quatro sinais de tensão e corrente e, em simultâneo, processa toda a informação necessária para elaborar os gráficos, detetar sags, swells e distorções na forma de onda. Apesar de fiável e sobejamente evoluído a nível gráfico, o desenvolvimento de aplicações em ambiente LabView - como a que se ilustra acima - tem a desvantagem de impor a licenças ao seu uso. O facto de não ser um software de desenvolvimento livre, torna-o pouco atrativo para empresas e particulares em geral, pois representa um custo adicional que muitas vezes Figura 2.10 – Exemplo de aplicação Labview para sistema de monitorização [19] 24 Estado da arte não se justifica face a outras opções no mercado. Apesar disso, este compensa com inúmeras funcionalidades, sendo bastante prático e intuitivo no capítulo da implementação. 2.4.2. Java Desenvolvida pela OEM, a aplicação orientada à monitorização de energia elétrica dá pelo nome “VISampler”. O ambiente de desenvolvimento usado para esta aplicação, em contraste com o anterior, foi Java, sendo um pouco mais pobre a todos os níveis (sobretudo visual) Esta aplicação não executa de forma contínua a aquisição de sinais de corrente e tensão, ficando dependente da ordem do operador para receber uma amostra. Uma vez recebida a amostra, e consultados os valores calculados de potência, fator, picos, etc, o operador tem o poder de decidir se pretende exportar os dados para um ficheiro txt ou receber nova amostra. Como se pode constatar da figura acima, a aplicação Java é caraterizada por uma menor qualidade gráfica e um aspeto em geral mais arcaico. Contudo, muito embora não ofereça as mesmas soluções de visualização que a aplicação LabView, o ambiente Java tira partido do facto de não requerer um software licenciado para correr, permitindo, ao mesmo tempo, as mesmas funções de monitorização. Um outro argumento forte desta linguagem, é o facto de usar uma "máquina virtual" para emular aplicações, podendo assim adaptada ara qualquer OS (linux, windows, tablets, androids, etc). Em contrapartida, e ainda por comparação com o LabView, exige um conhecimento mais profundo de programação orientada a objetos. 2.4.3. Visual Basic Desenvolvida em 2008 por investigadores da Universidade de Trás-os-Montes e Alto Douro, um sistema de monitorização com o mesmo propósito dos dois anteriores, batizado “Sistema de Aquisição e Tratamento de Dados para Monitorização da Qualidade da Energia” foi criado em linguagem VB. Este sistema, muito similar ao nível das funções com o visto em LabView, não operando porém, de forma interrupta - o software requer dados ao microcontrolador, no máximo, de 2,5 em 2,5 segundos. Figura 2.11 – Exemplo de aplicação Java para sistema de monitorização – EOM [20] Microcontrolador / Aquisição 31 3.1.3. Amostragem e tramas de envio Como se explicou logo após o fluxograma do programa a implementar no Arduino, há dois tipos de amostras diferentes, cujo conteúdo, apesar de ter a mesma origem, serve diferentes funções do sistema geral: amostra normal e amostra de inspeção de rede. Ambas armazenam os valores adquiridos em binário, divididos em 2 bytes (2 x 8 = 16 bit), por força da resolução de cada ADC - que se pretende aproveitar ao limite. Para tal, alocamse os 6 bits mais significativos num dos bytes e os 6 bits menos significativos no outro byte. Por exemplo, o valor 1600, correspondente a 2,6 V no ADC, seria alocado da seguinte forma: No que respeita à constituição de cada amostra, porém, há diferenças muito significativas - tal como se referiu no ponto anterior 3.3.2, e agora se explica com mais detalhe. A. Amostra normal - AN A amostra normal é constituída 146 tramas, cada uma com 7 leituras sucessivas dos ADCs, para cada um dos sinais pretendidos: IR, IS IT VRS VST IDC e VD. Cada uma destas leituras é depois alocada em dois bytes, donde se obtém: ( ) ( ) ( ) O número de tramas e quantidade de informação estipulada para cada uma - 100 bytes - foi determinado com base no limite de payload do módulo de comunicação sem fios por um lado, e pelas limitações dos ADCs, por outro. Na verdade, a aquisição e conversão de todos os ADCs demora cerca de 20 ciclos de clock (de 1 MHz) a concretizar-se, ou seja, cerca de 768 μs. Individualmente, isto corresponde a uma taxa de amostragem “real” de 25 kHz por canal, (40μs) que, por se considerar reduzida, procurou-se ainda aumentar por via da alteração do registo STARTUP dos ADCs. Assim, foi possível obter uma conversão 10 vezes mais rápida: 4 μs por sinal. Donde: ( ) ( ) ( ) Contudo, este número de pontos considerou-se inútil, atendendo à necessidade de calculo do FFT na aplicação de destino, que requereu uma amostra de dimensão potência de 2. Deste modo, foi necessário introduzir delays (na ordem de µs) entre aquisições sucessivas, de modo a fazer cair ligeiramente a frequência de amostragem por sinal e assim diminuir o número de pontos até ao valor de 1024 pontos por sinal – pois 210 = 1024. Assim, calculou-se: ( ) Por outro lado, aos 98 bytes de cada trama, acresceram ainda mais dois: um start byte e o checksum. O primeiro serve para sinalizar o início da trama, permitindo à aplicação destino separar as várias tramas da mesma amostra. O checksum, por seu lado, é usado como método de verificação de erros, cujo valor calculado no Arduino (e enviado a partir do mesmo) deve corresponder aquele que é calculado no software gráfico de destino. Este byte é de capital 32 Plataforma hardware importância para o correto funcionamento de todo o sistema, uma vez que permite a deteção de erros na transmissão e evita leitura de dados corrompidos. B. Amostra de inspeção de rede - AIR Como se explicou atrás, esta amostra tem como objetivo ler da rede os mesmo sinais que a amostra normal, durante o tempo de espera entre o envio e nova requisição do dispositivo mestre, e, através deles, calcular os valores de pico e médio durante esse período. Contudo, esta amostra tem que ser de pelo menos um ciclo de rede ou múltiplo inteiro do mesmo, de modo a permitir o cálculo de valores credíveis e consistentes com a realidade. Se assim não for, as rotinas implementadas para o cálculo dos valores atrás, corriam o risco de se revelar inconsistentes e pouco credíveis, conduzindo a valores desviados (se por exemplo, se usasse apenas um ciclo e meio da rede). Uma vez requisitada pelo mestre uma nova amostra normal, são determinados os valores de pico, eficaz e médio, e alocados numa única trama de envio com dois bytes cada um, ou seja: ( ) ( ) A esta quantidade de informação, acrescem também os mesmos dois bytes que no caso da amostra normal: um start byte e o checksum – por uma questão de processamento futuro. 3.1.4. Rotina de cálculo: valores pico, médio e eficaz A rotina de cálculo, incluída na amostra de inspeção da rede, é implementada com base numa biblioteca específica de Arduino, Statistic, que permite criar listas de valores e a estas adicionar o que bem se entender. A partir de cada lista, por sua vez, é possível calcular os valores: médio, máximo, mínimo, o desvio padrão, somatório e a sua contagem. Na sequência do raciocínio explanado na alínea anterior, à taxa de amostragem máxima dos ADCs 250kHz, são necessários 715 pontos de cada sinal para perfazer um ciclo. Como tal, o número mínimo de valores a adquirir neste período de amostra de inspeção é 715, fazendo uso das seguintes expressões: ∑ ∑ 3.2. Interface com o módulo de comunicação Para além de todas as vantagens já assinaladas, o Arduino e a sua família de componentes tira também partido do facto de ser amplamente abrangente e oferecer inúmeras soluções de compatibilidade com diferentes equipamentos. Orientado ao uso de módulos de comunicação sem fios vulgarmente comercializados - ZigBee e Xbee - os Arduinos dispõem de um SD Shield, ajustado à dimensão e requisitos dos referidos módulos, que configura uma comunicação via porta série com o microcontrolador. Por acréscimo, esta plataforma interface permite incluir um cartão micro SD, com o qual o microcontrolador pode operar em protocolo SPI 16 , bastante útil para fins de armazenamento temporário ou definitivo - o que no âmbito do projeto se considerou relevante e potencialmente necessário. 16 SPI (Serial Peripheral Interface) - protocolo que permite a comunicação entre um microcontrolador e diversos outros componentes, formando uma rede – orientado a funções multimestre e redes sensores Carta de aquisição 33 Outro pormenor bastante atrativo da shield, é o facto de possuir um interruptor capaz de comutar entre uma de duas opções (apenas possíveis se integrada numa board Arduino):  USB: para programar o microcontrolador e trocar dados via porta série;  Micro: para o módulo Xbee comunicar com o Arduino e trocar dados com os outros módulos que suportem Zigbee. 3.3. Carta de aquisição Como se deu a entender ao longo deste documento, a carta de aquisição é objeto central neste sistema de monitorização, assim como em qualquer outro. Esta assegura a ligação entre o aerogerador e o Arduino, procurando anular a discrepância de magnitudes entre os sinais a “sensorizar” e os sinais admissíveis pelos ADCs. Para tal, foi necessário arranjar uma solução para compatibilizar ambas as partes, fazendo baixar as tensões lidas para uma gama de 0 a 3.3V, (máximo suportável pelo Arduino Due), ou seja, anulando a bipolaridade dos sinais AC. Todavia, devido a alguns atrasos e imprevistos, revelou-se impossível operar diretamente com a turbina eólica da biblioteca da FEUP, o que limitou a fase experimental do projeto e levou à procura de soluções. Nesse sentido, recorreu-se a uma carta de aquisição orientada à monitorização da rede elétrica, apenas com dois canais (monofásica), de modo a simplificar a fase experimental do projeto e validar da aplicação desenvolvida na prática. Esta carta de aquisição fez uso dos seguintes transdutores - cujas caraterísticas se apresentam no anexo A: 3.1. Transdutor de corrente: HY 5-P Figura 3.7 - Arduino Wireless SD Shield Figura 3.8 – LEM de corrente HY 5-P 34 Plataforma hardware 3.2. Transdutor de tensão: LV 25-P 3.3. Circuitos de condicionamento O condicionamento de sinal usado na carta de aquisição foi desenvolvido e implementado por Agostinho Rocha, colega da curso, cujo esquemático se apresenta no anexo B. Esta carta, em PCB, permitiu obter uma gama de tensão de saída compreendida entre 0.2 e 2.56V, e uma gama de corrente entre 0 e 3V. À saída desta carta foi ainda acrescentado um filtro analógico anti-aliasing passa-baixo de primeira ordem (para cada canal), a fim de atenuar altas frequências que poderiam introduzir erros na amostragem. O dimensionamento deste filtro com frequência de corte de 5kHz, para ambos os canais, consta igualmente do mesmo anexo B. 3.4. Módulo de comunicação sem fios O módulo de comunicação sem fios escolhido para servir de interface entre o Arduino e a aplicação gráfica foi o ZigBee – razão pela qual esteve em foco no capítulo do estado da arte. A escolha recaiu sobre este módulo de comunicação, por força do protocolo IEEE 802.15 que utiliza e as vantagens que lhe são subjacentes: comunicação com a turbina eólica num raio de 200 a 300 metros, baixos consumos, compatibilidade com Arduino, fácil implementação: No contexto de utilização descrito, o módulo Xbee revelou-se como a opção mais válida e adaptada ao sistema de monitorização, tendo como principais caraterísticas o alcançe de 300 metros em espaço exterior, a taxa de transmissão de 250 kbps (mais do que suficiente para o volume de dados em causa), uma alimentação de 2,1 a 3,6V e a possibilidade de integrar uma solução topológica em rede ponto-a-ponto ou ponto-multiponto. Figura 3.10 – Exemplo de um transceiver Xbee Figura 3.9 - LEM de tensão LV 25-P Módulo de comunicação sem fios 35 3.4.1. Configuração da rede Uma vez escolhido o módulo Xbee para a implementação da comunicação sem fios entre o aerogerador e a aplicação gráfica do PC, seguiu-se a sua configuração. Esta representou uma das etapas fulcrais do projeto, pois da sua conclusão dependeu a troca de dados entre os dois módulos Xbees (Arduino e PC). Neste contexto e na sequência do que foi referido ao longo do documento, a rede implementada baseou-se numa topologia coordenador/end-device, tendo para isso programado cada módulo Xbee para as funções respetivas:  Xbee coordenador (mestre): conectado via USB ao PC, onde corre a aplicação;  Xbee end-device (escravo): conectado ao Arduino via porta série, UART; A configuração das funções de cada XBee foi conseguida através da aplicação firmware XCTU, fornecida pela empresa Digi e com a ajuda do adaptador USB Explorer, que permitiu a definição dos endereços de destino, encriptação, segurança, etc. Através deste software, foi ainda possível alterar ou atualizar o firmware, bem como reconhecer cada Xbee no PC e saber a sua configuração atual: Para além das funções de cada módulo Xbee no âmbito da rede, foi necessário definir a forma como se regeu a interação entre os módulos mestre e escravo. Neste contexto, duas hipóteses de operação se equacionaram: modo transparente (AT) e modo comando (API-Application Programming Interface). No entanto, a decisão foi tomada no sentido de operar em modo transparente, por ser a que melhor se adequava a comunicações ponto a ponto (redes de arquitetura simples), em que o fluxo de dados é unidirecional. Figura 3.11 – Print do software X-CTU Capítulo 4 Plataforma software Uma vez encerrada a componente hardware, a etapa que se seguiu foi o desenvolvimento da plataforma software. Esta resumiu-se essencialmente à criação de uma aplicação gráfica, capaz de suportar a comunicação sem fios com o Arduino, via módulo Xbee, e nela apresentar os principais dados de produção do aerogerador sob a forma de gráficos, diagramas e tabelas. A estratégia de processamento adotada e o esquema de visualização de tais dados, foram, no âmbito da aplicação desenvolvida, os dois vetores de desenvolvimento base, procurando ir de encontro aos índices de QEE usados no setor de produção eólico: harmónicos, flicker e cavas - citados no estado da arte. 4.1. Linguagem de programação A primeira grande questão que se enfrentou à partida para este capítulo, foi a escolha da linguagem de programação e respetivo ambiente de desenvolvimento a utilizar para o projeto e conceção da aplicação gráfica. Tal como foi objeto de análise anteriormente, as principais linguagens de programação equacionadas foram Visual Basic, Java, LabView e uma aplicação em web em browser (JavaScript). De entre estas, a que se apresentou mais vantajosa foi a linguagem Java, por permitir uma aplicação e execução em plataforma universal, (todo o tipo de dispositivos fixos e móveis) o que se traduz em versatilidade e flexibilidade do utilizador final, e, por outro lado, por não exigir um software licenciado para se desenvolver. 4.1.1. Ambiente de desenvolvimento O desenvolvimento de uma aplicação Java pode ser feito com apoio em dois softwares, de uma maneira geral: o Eclipse e NetBeans. Ambos são muito similares ao nível da rapidez e debugging, porém o NetBeans é o mais intuitivo para utilizadores inexperientes em Java, pelo que neste caso a opção acabou por recair sobre ele. Esta ferramenta de desenvolvimento possui uma interface bastante simples e fortemente orientada à criação de GUI 17 , o que para a aplicação desenvolvida se revelou naturalmente muito útil. Na figura seguinte mostra-se um exemplo do workspace em ambiente Netbeans 7.4: 17 GUI (Graphic User Interface): interface que permite aos utilizadores interagir com dispositivos eletrónicos através de icones e indicadores visuais, bem como conferir seus valores e registos Arquitetura da aplicação 37 4.2. Arquitetura da aplicação A aplicação gráfica destinada à visualização dos dados do aerogerador esboçou-se, numa primeira fase, com base nos requisitos funcionais e não funcionais – vistos na fase introdutória do documento. A partir destes foi possível definir os casos de uso UML 18 para a aplicação que se desenvolveu, servindo como guia de orientação e sustentação à elaboração do diagrama de classes. Por sua vez, este último foi o suporte de todo o processo de implementação, do qual se compreendeu:  Definição das várias janelas da aplicação e seu conteúdo;  Formatação de gráficos, tabelas ou valores nas mesmas;  Configuração da comunicação sem fios com o Arduino via Xbee;  Processamento dos dados recebidos e sua descompactação;  Controlo e verificação de erros de comunicação;  Modo de operação geral do software (interrupt);  Método de armazenamento de dados;  Sinalização ativa dos índices de QEE; A validação e teste de todos os pontos elencados teve como aliado o software NetBeans, já referido atrás, para o qual se enviaram valores fictícios de ADCs do Arduino, numa primeira fase, (ainda sem o projeto do PCB), e numa fase posterior, valores reais da rede. 18 UML (Unified Modeling Language) - linguagem de modelagem usada no desenvolvimento de software, que simplifica a sua concepção e projeto através de vários diagramas; Figura 4.2 – Sessão de trabalho em NetBeans Figura 4.1 – Sessão de trabalho em NetBeans 38 Plataforma software 4.2.1. Casos de uso Conforme se referiu no ponto anterior, o primeiro passo no desenvolvimento da aplicação foi a definição dos casos de uso. Com base nos requisitos funcionais expostos mais atrás e atendendo à relação master <-> slave que se pretendeu implementar entre o PC e Arduino, respetivamente, definiram-se como atores do processo de monitorização: o operador e o nó sensor. Por outro lado, este diagrama refletiu também alguns pormenores de processamento tanto no lado do Arduino (já vistos atrás), como no lado da aplicação Java que se desenvolveu – senão vejamos na figura abaixo: Como se pode constatar, ao nível da aplicação Java, há três zonas de ação em destaque, no que concerne à visualização dos dados: cavas, fases, e harmónicos. Para cada um dos três, foram destinados diferentes espaços no interface gráfico, nos quais, sob diferentes formatos, se apresentaram os dados de interesse ao operador. Importa relembrar, que tais dados e seu tratamento se traduzem em indicadores de QEE relativos à produção do aerogerador, e que a sua melhor visualização e apreensão foram tidos em conta para a sua configuração do espaço gráfico da aplicação desenvolvida. Nesse sentido, como se sugeriu no capítulo da introdução - aquando dos requisitos funcionais - definiram-se três áreas de visualização principais:  Time Domain: área destinada à visualização em tempo real dos 7 sinais da turbina eólica, possibilitando a deteção e análise de cavas, sobretensões ou do flicker;  Frequency Domain: área destinada ao conteúdo harmónico dos 7 sinais lidos em tempo real - síncrono com o Time Plot - e onde se disponibiliza o valor %THD;  Phasor Diagram: área dedicada à representação dos sinais AC em fasor e à análise do seu desvio; Figura 4.3 – Diagrama de casos de uso da aplicação Java Arquitetura da aplicação 39 Para complementar a informação fornecida nas áreas atrás, uma quarta zona foi definida, com o fim de mostrar os valores máximo, mínimo, médio e eficaz de cada sinal monitorizado, bem como a potência, seu fator e frequência. Ou seja, definiram-se por isso quatro zonas de ação distintas na aplicação, cada uma com a sua função específica. 4.2.2. Diagrama de atividade Definidos os vários elementos visuais a incluir na aplicação e a função por de trás de cada um, equacionaram-se então os algoritmos e rotinas a implementar. O seu alcance foi possível – em boa parte – graças ao diagrama de atividade UML, que serviu de ponto de partida para o processo de implementação em NetBeans. Este, à semelhança do flowchart esboçado para o programa em Arduino, segue as mesmas regras e sintaxe, como se vê de seguida: (*) – “determinação de valores” engloba os valores máximo, mínimo, médio e eficaz para todos os sinais, bem como para potência ativa, reativa, fator de potência e frequência; Figura 4.4 – Diagrama de atividade da aplicação 40 Plataforma software A elaboração do diagrama acima apresentado, teve como princípio separar as rotinas de setup - e configuração dos vários elementos visuais - do ciclo de processamento propriamente dito. Nesse sentido, caso se pretenda inicializar a aplicação, esta apenas vai criar condições à receção e processamento aos sinais, ficando em modo standby, e aguardando a ordem do operador para proceder à requisição das amostras. No que diz respeito à rotinas de setup, estas refletem em grande medida a componente visual que se detalhou nos casos de uso, incidindo sobre 4 zonas de acção distintas, às quais acresce a configuração dos buffers de receção das amostras (para cada sinal), uma rotina de zoom e o clock que serve de referência à aplicação. Por sua vez, no que toca ao processamento das amostras (componente de visualização e calculo) e ao armazenamento, estes ficam condicionados por três de “filtros” - representados simbolicamente pelas figuras triangulares – implementados com o fim de ler amostras válidas e sem erros de transmissão. Em detalhe, estes representam:  Deteção de amostra valida: caraterizada pela leitura do startbyte e pela extensão da trama; caso um não corresponda ao previamente definido (payload: 100 bytes & startbyte * ou #) a amostra é rejeitada;  Seleção de amostra normal / inspeção de rede: caraterizada pela leitura do startbyte que, caso corresponda a um caracter ASCII 19 :  “#”: determina que é recebida uma amostra de inspeção de rede;  “*”: uma amostra normal;  Verificação do checksum: verificação individual do byte checksum de cada trama da amostra, e sua comparação com o valor calculado na aplicação; caso não haja correspondência, a trama é rejeitada e nova requisição efetuada; Uma vez passados todos os “filtros” aplicados à amostra, esta é descompactada em várias sub-tramas correspondentes a cada sinal, e preenchidos os buffers inicializados no início de todo o processo. Cessado esse preenchimento, são realizadas duas tarefas em paralelo:  Gráfico dos dois ciclos de rede para cada um dos sinais, no Time Domain;  Discretização cada um dos sinais no Frequency Domain; Por fim, os valores dos buffers são armazenados em formato binário no disco rígido local, previamente datados e com os valores médio, máximo, mínimo e eficaz de cada um dos sete sinais monitorizados. Se o operador nada decidir em contrário, o processo é reiniciado, e uma nova amostra requisitada ao Arduino (e assim sucessivamente). 4.2.3. Diagrama de classes Como foi referido, o diagrama de classes sustentou-se em larga medida no diagrama de atividade visto no ponto anterior. A classe nuclear do diagrama classificou-se como Arduino, sendo responsável pelo estabelecimento da comunicação via porta série, a leitura de dados, alocação nos buffers e determinação de todos os valores máx, eficaz, etc. Para além desta, também com capital importância para a aplicação, definiram-se as classes responsáveis pelas 3 áreas de visualização (Time Domain, Frequency Domain e Phasor Panel) e uma classe geral, MainFrame, com vista a organização de todos os elementos visuais numa janela principal. 19 ASCII (American Standard Code for Information Interchange) - é uma codificação de caracteres de sete bits baseada no alfabeto inglês Capítulo 5 Procedimento experimental Concluídas com sucesso as duas etapas anteriores, hardware e software, o passo seguinte foi testar e validar todo o sistema em conjunto, na prática. Nesse sentido, e tal como foi dito mais atrás, - dada a impossibilidade de operar fisicamente com o aerogerador - foi usada para a plataforma hardware uma carta de aquisição monofásica, com o propósito de “sensorizar” a corrente e tensão da rede elétrica. À saída de cada canal desta carta (de corrente e tensão), acrescentou-se o, também já referido, filtro passa-baixo anti-aliasing de 5kHz, cuja saída por sua vez a um dos 7 ADCs que se configuraram no Arduino. 5.1. Teste da carta de aquisição O primeiro teste realizado experimentalmente foi à carta de aquisição, procurando aferir se a gama de valores de saída em cada canal correspondia de facto aos valores calculados no dimensionamento – anexo A. Este foi um teste preventivo, para não correr o risco de danificar o Arduino com tensões nos ADCs superiores a 3.3V. A carta de aquisição apresenta-se abaixo: Figura 5.1 – Carta de aquisição testada 48 Procedimento experimental Esta carta de aquisição foi alimentada com uma fonte de tensão a ±15 V, tendo obtido na saída do canal de tensão: valores entre 0.200 e 2.56 V – tal como mostram a figura seguinte: Verificou-se contudo, que esta gama de valores não era constante no tempo, o que levou a leituras mínimas que atingiram os 160 mV e máximas de 2,54 V. Esta situação viria a ser determinante aquando do teste com a aplicação, influenciando o processamento dos sinais na aplicação e deturpando muito residualmente os valores máximo, mínimo, eficaz e médio de cada sinal lido – algo a comprovar mais adiante. A par desta leitura no domínio temporal, realizou-se também uma leitura ao domínio das frequências, procurando verificar a magnitude dos harmónicos presentes na rede, e servindo como termo de comparação para testes futuros - com a aplicação Java. O gráfico FFT que se obteve a partir do osciloscópio foi então o seguinte: A partir deste FFT foi possível verificar que a frequência fundamental (50 Hz) era de facto a predominante, sendo que o segundo, terçeiro e quinto harmónicos eram os que se seguiam com maior representação (juntamente com o 6º, 7º e 9º, ainda que com menor magnitude). No caso do canal de corrente por seu lado, este acabou por não ser efetivamente testado, dando prioridade à validação do sistema no seu todo apenas com o canal de tensão, uma vez que a aquisição de mais um sinal não alteraria muito em relação à performance geral da Figura 5.2 – Onda de tensão lida no osciloscópio Figura 5.3 – FFTs obtidos a partir da onda de tensão (diferentes escalas) Teste da aplicação Java 49 aplicação gráfica. Deste modo, os testes experimentais subsequentes foram realizados apenas com os valores da tensão da rede elétrica, poupando assim tempo, e procurando alcançar os resultados práticos esperados com a maior celeridade. 5.1. Teste da aplicação Java Validada a carta de aquisição e os sinais de cada canal, o passo que se seguiu foi validar a aplicação Java. Esta validação foi conseguida através de valores fictícios, criados por rotinas dentro do próprio programa, que simularam a recepção de ondas sinusoide e o preenchimento dos vários buffers. A partir destes, foram processados e apresentados todos os dados relativos às várias áreas do Main Frame da aplicação: Time Domain, Values, etc – como de resto se viu no ponto 4.4, com a apresentação do interface gráfico. Nas próximas figuras resume-se - à semelhança do ponto 4.4 - uma simulação preliminar à aplicação Java, em que se visualizam duas ondas sinusoides, correspondentes aos sinais IS e VRS. A partir destes sinais são calculados todos os valores revistos: máximo, mínimo, médio, eficaz, frequência (de VRS), potência aparente, fator, etc. O Main Frame do qual se extraíram todas as imagens que se seguem consta em anexo, F, no seu formato original. A. Time Domain Figura 5.4 – Simulação do Time Domain com duas sinusoides Figura 5.5 – Values relativo aos sinais da figura acima 50 Procedimento experimental B. Frequency Domain C. Phasor Panel Como se pode constatar das figuras anteriores, todos os valores coincidiram com o que se esperava, salvo algumas aproximações que rondaram as décimas: caso do ângulo fasorial que se definiu inicialmente como 90 graus e foi calculado como 90.1, o valor eficaz da onda seno de maior amplitude que resultou não em 230 mas em 229.8, o THD% que deveria ser 0 exato e foi determinado como 0.1, entre outros casos marginais. Fora estes desvios mínimos, todas as funções se revelaram funcionais, tanto a discretização, como a janela temporal, os cálculos implementados e os fasores desenhados. Esta simulação preliminar serviu assim, para provar que a aplicação estava de facto funcional e devolvia resultados consistentes com aquilo que se previa, ou seja, preparada para ser testada experimentalmente com a carta de aquisição. Figura 5.6 – Frequency Domain relativo às sinusoides Figura 5.7 – Phasor Diagram que representa os dois fasores das sinusoides Teste de todo o sistema 51 5.2. Teste de todo o sistema Por fim, procedeu-se ao teste conjunto de todo sistema: Arduino, XBee e aplicação Java. Para tal ligou-se a saída do canal de tensão da carta de aquisição ao ADCs 0 do Arduino, por forma a simular o sinal IS do aerogerador e realizar o seu respetivo processamento/envio para a aplicação Java. Na figura seguinte mostra-se o setup de todo o sistema testado: Convém relembrar que, na utilização desta carta, foi necessária a inclusão de um filtro de 1ª ordem passa-baixo, razão pela qual consta da figura acima uma board com um circuito RC. Os resultados obtidos na aplicação Java - objetivo último de toda a componente experimental - podem ser vistos no ponto que se segue, no qual são discutidos individualmente por área da aplicação: Time Domain, Frequency Domain, Phasor, etc. 5.3.1. Time Domain Figura 5.8 – Setup do sistema de monitorização completo Figura 5.9 – Time Domain relativo ao sinal de tensão obtido da carta 52 Procedimento experimental Esta foi apenas uma de muitas amostras que se receberam na aplicação Java, e, tal como se pode verificar, coincide perfeitamente com o que se esperava. Se atentarmos na forma de onda que se obteve no osciloscópio (figura 5.2), esta corresponde exatamente ao que se viu na aplicação Java, subtraída apenas do ruído que se pode observar na zona de pico da onda – fruto do filtro introduzido. No que diz respeito aos valores, estes apresentam-se desviados apenas marginalmente do que se esperava, sendo que a causa mais provável para este desvio está relacionada com a variação da gama de tensão saída da carta. Esta variação, registada entre 30/40 mV, afeta o offset do sinal de tensão de saída da carta e, por consequência, são lidos na aplicação valores ligeiramente desviados para os picos máximo e mínimo. Por sua vez, isto conduz a um desvio no cálculo do valor eficaz, médio, e na frequência (ainda que com menor influência) tal como se observa na figura acima. 5.3.2. Frequency Domain Figura 5.10 – Valores calculados para a onda recebida da carta Figura 5.11 – Frequency Domain relativo ao sinal de tensão obtido da carta Teste de todo o sistema 53 No que toca à componente das frequências, estas também coincidiram com aquilo que se obteve através do osciloscópio digital (figura 5.3), sendo que a frequência de magnitude 230 V foi de facto a de 50 Hz - fundamental. Os restantes harmónicos registados com magnitude expressiva foram o 2º, 3º e 5º, o que foi perfeitamente de encontro ao que se observou na figura 5.3. O valor de tensão obtido para estes harmónicos rondou os 11, 8 e 5V, para cada um dos referidos, respetivamente. Por outro lado, o valor calculado para a taxa de distorção harmónica total (em %) relativo à onda de tensão lida, foi de 1.6 %, o que se considerou plausível face à distribuição das magnitudes registadas, e perfeitamente dentro dos padrões de qualidade exigidos para a rede pública – extraídos do capítulo 2 ponto 1.7, alínea D). 5.3.3. History Por fim, no que concerne ao histórico e seus valores, foi possível consultar os valores que foram armazenados durante uma hora, e conferir os picos da rede para o sinal de tensão lido, a frequência, bem como a hora em que ocorreram – como se mostra abaixo: Figura 5.12 – Time Domain do History Frame relativo a 1 hora de amostras Figura 5.13 History Values correspondentes aos gráficos da figura 5.12 Capítulo 6 Conclusões 6.1. Alcance dos objetivos A realização desta dissertação tinha como propósito fundamental desenvolver um sistema de monitorização capaz de ler os valores de produção do aerogerador da biblioteca da FEUP, e, com base nestes, aferir a qualidade da energia injetada na rede. Embora sem operar fisicamente com o mesmo, os dois objetivos referidos foram alcançados com sucesso, sendo monitorizada a rede elétrica pública diretamente no laboratório. Esta monitorização levou a resultados coincidentes com aquilo que são os valores da rede elétrica pública, tendo-se registados apenas ligeiros desvios em relação ao expectável, o que não terá sido unicamente consequência da aquisição e processamento do sinal adquirido. Na verdade, os resultados obtidos nos testes do capítulo anterior permitiram concluir, a partir dos valores dados no interface gráfico, que a aquisição fora implementada de forma correta, a transmissão sem fios estável e sem erros, e o processamento na aplicação feito da forma desejada. Os desvios registados foram muito marginais face ao esperado, sendo prova disso os valores armazenados em histórico, que para o período em que se registaram, determinaram os seguintes desvios relativos máximos:  Frequênciamin: 49.6 / 50 = 0.8 %  VRS, MAX = 326.3 / 325 = 0.4 %  VRS, MIN = -332.8 / -325 = 2.4 % Estes desvios, principalmente o mais significativo, o pico máximo do sinal de tensão lido a partir da carta, deveu-se às flutuações na carta de aquisição e à variação (explicada atrás) de tensão que o canal da carta fornecia, registada em 30/40 mV. Por este motivo, os valores que se processaram na aplicação e se mostraram no interface não corresponderam exatamente ao esperado (325Vpico, 230Vrms, 50 Hz, etc). Em todo o caso, a performance geral da aplicação foi satisfatória, permitindo visualizar o sinal de tensão com todo o pormenor através do zoom implementado, conferir as magnitudes dos diferentes harmónicos e o valor do THD do sinal. Todos estes resultados foram concordantes com os que se registaram no ínicio deste capítulo, atestando dessa forma a validade da implementação realizada e o sistema em geral.Apesar disso, e no que toca ainda aos testes realizados, foi monitorizada apenas a tensão da rede, a partir da qual se calcularam a frequência, THD%, valores de pico, eficaz e médio, ficando por Dificuldades e contratempos 55 testar o canal de corrente, também presente na carta de aquisição utilizada, que inviabilizou o cálculo da potência aparente e ativa, respetivo ângulo de fase – componente em falta. A aplicação gráfica desenvolvida para servir de interface gráfico ao operador foi feita em linguagem Java, por se revelar a melhor escolha no capítulo da compatibilidade com sistemas operativos diversos (android, PC, Mac, etc), por dispor das ferramentas gráficas necessárias à implementação e, sobretudo, por não requerer um software licenciado para se executar. No que respeita à sua validação experimental, esta foi praticamente completa, com excepção ao Phasor Diagram, devido à ausência do teste com o canal de corrente da carta de aquisição - o que impossibilitou o cálculo do ângulo e sua representação face ao fasor tensão. No que toca à restante implementação, Arduino e Xbee, esta correspondeu na prática ao que se previa, sendo que todas as funções e rotinas configuradas deram uma resposta cabal face àquilo para que foram definidas: aquisição, envio, verificação de erros, etc. 6.2. Dificuldades e contratempos No decorrer do desenvolvimento do sistema de monitorização foram várias as dificuldades e obstáculos encontrados, alguns ultrapassados com sucesso, outros não. De entre todos estes, o que mais se destacou e condicionou o andamento projeto foi a linguagem de programação escolhida, (Java) e respetivo ambiente de desenvolvimento para a aplicação: a componente central do sistema. A total ausência de contacto e rotinas com esta linguagem foi por ventura a maior dificuldade, que se arrastou praticamente durante todo o desenvolvimento. No entanto, a persistência em usar esta linguagem (por todas as vantagens que se enumeraram até agora) acabou por se sobrepor a todas as dificuldades e, com alguma aprendizagem em paralelo, o interface gráfico em Java acabou por ser uma realidade. Para além disso, o pouco ou nenhum contacto com PCBs e seu software de projeto acabou também por arrastar o desenvolvimento da solução para a carta de aquisição, acabando por ser descartada a hipótese de se desenvolver uma (orientada ao aerogerador), e adotada uma solução já existente para monitorização da rede pública: carta de aquisição monofasica. Em terçeiro lugar, com peso menor, alguns conceitos sobre aquisição e processamento de sinal, em falta, representaram também dificuldades durante o desenvolvimento do sistema, o que condicionou em alguns momentos o avanço das implementações e levou ao estudo quase contínuo de matérias. Por fim, a implementação da FFT responsável pela discretização dos sinais adquiridos foi também um passo complicado, principalmente por esta requerer uma amostra de dimensão em potência de 2, e, paralelamente, uma precisão altíssima para a gama temporal adquirida. 6.3. Trabalho futuro O passo seguinte a ser dado no desenvolvimento deste sistema seria - tal como já foi dito atrás - o teste do canal de corrente e sua validação. Para além disso, procurar-se-ia também reformular a aplicação para possibilitar a sua execução em SO Android, ou, alternativamente, desenvolver um applet para que fosse possível recorrer à aplicação através de um browser, desde que conetado à web. Nesta lógica de utilização, a base de dados poderia passar de um disco rígido fixo para uma base de dados online, a partir da qual se requisitassem os registos por via PHP. Equacionar a aplicação deste tipo de sistema de monitorização para o ambiente industrial, também seria vantajoso e útil, quando ajustado à qualidade de produção. Anexos Nesta secção são fornecidas informações e conteúdos complementares ao que foi exposto ao longo do documento, nomeadamente excertos de fichas técnicas dos componentes usados, esquemáticos, cálculos, diagramas e prints do GUI da aplicação Java. Anexo A: Carta de aquisição A1. Circuitos de condicionamento O circuito de condicionamento presente na carta de aquisição, em particular no canal de tensão, foi o seguinte: Este circuito permitiu adquirir a tensão da rede, transformando a gama de valores de -3V a +3V, saída do sensor, em 0-3V, valores toleráveis pelos ADCs do Arduino. O circuito usado para o condicionamento da corrente foi, por sua vez, o seguinte: Figura 6.1 – Circuito de condicionamento do transdutor de tensão Figura 6.2 – Circuito de condicionamento do transdutor de corrente Figura 6.7 – Aplicação Java completa Anexo F: Simulação da aplicação gráfica Java 65 Figura 6.8 – Simulação da aplicação Java com sinais virtuais Referências [1] APREN e INEGI. “Parques Eólicos em Portugal”, Dezembro 2012. [2] Vitor M. Ribeiro. “Eolitor: Sistema de monitorização em micro-geração eólica”, 2009. [3] Rui P. Barbosa. “Sistema de supervisão e controlo de unidade de produção eólica”, 2011 [4] Rui P. Moreira, Henrique Gonçalves, J.G. Pinto, João L. Afonso. “Monitorização da Qualidade da Energia Elétrica”, Revista Robótica, nº 90, pp. 60-62, 2013. [5] Ricardo Querido Henriques. “Desenvolvimento de um Sistema de Monitorização Remota do Consumo de Energia Elétrica e da Presença Humana em Edifícios”, 2012 [6] Pedro B. S. Gomes. “Sistema de Monitorização de Energia Eléctrica”, 2012 [7] Nuno G. D. Fernandes. “Impacto da Ligação de Geradores Eólicos na Rede de Distribuição”, Abril 2010 [8] EDP “Regulamento da Qualidade de Serviço”, 2013 [9] Júlio S. Martins, Carlos Couto, João Luiz Afonso. “Qualidade de Energia Elétrica” 3º Congresso Luso-Moçanbicano de Engenharia – CLME’2003 Engenharia e Inovação para o Desenvolvimento. Maputo, Moçambique, Agosto 2003, pp. 219-231 [10] Alexandre Morais Lopes. “Produção Eólica e Enquadramento Técnico-Económico em Portugal”, Junho 2009 [12] Tiago Braga. “ Monitorização Ambiental em Espaços Florestais com Rede de Sensores Sem Fios”, Novembro 2010 [13] Luís Carlos Teixeira Vaz. “Supervisão e controlo remoto da iluminação pública”, 2010 [14] Vasco Sotomaior. “Rede de Sensores Sem Fios para Veículo Frigorífico e/ou Industria Alimentar”, Março 2013 [15] Ed Callaway. “Low Power Consumption Features of the IEEE 802.15.4/ZigBee LR-WPAN Standard”, 2010. [16] José Batista, Júlio S. Martins, João L. Afonso. “Sistema de Monitorização da Qualidade da Energia Eléctrica Baseado em PC”, 8º Congresso Luso-Espanhol de Engenharia Eletrotécnica [17] Open Energy Monitor, software VISampler 2012 [18] José Baptista, Raul Morais, António M. Moura, Paulo Amaral, Ricardo Costa. “Monitorização digital de parâmetros associados à qualidade da energia eléctrica”, 2008 [19] Nuno M. Campos, “Monitorização em tempo-real de parâmetros de qualidade da rede elétrica a partir de diferentes locais em Portugal Continental”, Março 2013