Para a correta interconexão e operação da plataforma de D-PMU com os dispo- sitivos de hardwares empregados, são necessárias algumas considerações sobre a maneira com que os blocos de software/hardware da plataforma operam e se intercomunicam. Desta forma esta sessão do documento objetiva orientar sobre as adequações que foram realizadas na plataforma apresentada.
3.4.1
Comunicação ADC - Beaglebone Black
A leitura do barramento de dados de forma sequencial propicia a redução no uso de GPIOs do hardware. Entretanto este tipo de comunicação implica em um tempo maior para leitura de todos os bits referentes a todas entradas do ADC. Fator que é capaz de impossibilitar a leitura de todas as amostras convertidas sob a taxa máxima de amostragem do AD7609 de 200 kSPS (kilo Samples Per Second). A leitura paralela dos dados possibilita altas velocidades na comunicação, uma vez que todos os bits oriundos da conversão de uma amostra são lidos em um único ciclo de processamento. Mas acaba por exigir um esforço maior no projeto e roteamento das trilhas da PCB. No caso da plataforma D-PMU, tendo em vista a FS de 3840 Hz e a simplicidade do circuito de interface entre os blocos, emprega-se a comunicação do tipo serial.
3.4.2
Operação AD7609
O range de tensão de ±10 V é adotado visando maior flexibilidade e robustez à possíveis falhas no circuito de condicionamento além oferecer maior imunidade a surtos de tensão. Já para a resolução adotada neste trabalho, visando a aplicabilidade deste algoritmo em hardwares de arquiteturas em 16 bits, elimina-se dois dos 18 bits de dados produzidos pelo ADC através da truncagem dos dados. Nesta configuração, seguindo a Equação 3.2, obtém-se 30 milivolts de resolução do ADC.
Sobre FS, é necessário salientar de que, dadas as características intrínsecas ao hardware, há um desvio da FS configurada e a real gerada pelo PWM. Isto ocorre por conta
Capítulo 3. Plataforma D-PMU desenvolvida 63
de variações no valores nominais do clock do cristal de oscilação do sistema da Beaglebone Black, geralmente ocasionadas por variações de temperatura, tensão de alimentação ou por picos de corrente. Este erro acaba por refletir-se no algoritmo da D-PMU sob a forma de descontinuidade no ângulo do fasor a cada pulso de 1PPS de sincronismo e, por sua vez, gerando spykes na frequência (ZHANG; VENKATASUBRAMANIAN, 2014), (ZHAO et al., 2017).
A Figura 3.13 elucida melhor um exemplo do efeito prático deste fenômeno onde, simulando uma fonte de clock ideal, gera-se uma FS teórica de 1920 Hz e simulando uma arquitetura real onde, há um erro na frequência do cristal de operação, obtém-se uma FS real de 1920.8 Hz, por exemplo.
Figura 3.13 – Erros de FS por conta de erros no clock.
Na figura acima, ocorrem duas amostragens do sinal sinusoidal que, durante a troca o sincronismo do GPS (tempo 0) há, no instante anterior ao sincronismo, um erro no instante de amostragem para a frequência de 1920.8 Hz. No instante posterior ao sincronismo, ocorre a correção nos instantes de amostragem do sinal, causando uma descontinuidade no ângulo do último fasor estimado quer precede o sinal de sincronismo e o fasor calculado logo após. Este erro é acumulativo ao longo de cada segundo e seu efeito é melhor observado, durante o pulso de sincronismo.
A forma de onda do ângulo estimado com FS não teórica fica com o efeito de dente de serra de frequência de 1 Hz como apresentado na Figura 3.14-(a).
Outro erro que afeta o sincrofasor estimado é a defasagem ocasionada pelo atraso de fase inserido pelas arquiteturas de filtragem da arquitetura, pois como mostrado na Figura 3.7, além de atenuar as magnitudes dos sinais que estão fora da banda passante,
Capítulo 3. Plataforma D-PMU desenvolvida 64
acabam por afetar também a fase das componentes de frequências próximas da região de corte. O efeito prático deste desvio angular é o Δ𝜃 presente na Figura 3.14-(b)
(a) Erro por desvio de FS. (b) Erro por atraso de fase na filtragem.
Figura 3.14 – Erros provenientes da arquitetura de hardware (YAO et al., 2016).
Ambos os erros da Figura 3.14 são passíveis de correção por software ou por métodos de forma que, durante o fluxo de dados da D-PMU, o offset referente ao erro de fase da Figura 3.14-(b) é subtraído do ângulo estimado pelo algoritmo fasor a fasor. Esta parcela é obtida por meio da somatória dos atrasos de fase dos filtros no fluxo de dados, bem como ajustada durante a calibração do dispositivo.
A correção do desvio de ângulo da Figura 3.14-(a), provenientes da Figura 3.13, pode ser feito através da atuação dinâmica sob a FS do hardware, a cada amostra. Um exemplo de algoritmo proposto na literatura para este fim é apresentado em (YAO et al., 2016) onde é realizada a alteração da FS para o valores reais superiores e inferiores próximos ao valor teórico de forma a obter na média, amostras mais alinhadas com os instantes teóricos desejados. Entretanto, tal metodologia implica em operações extras de cálculo matemático, em malha fechada, para avaliação do desvio de erro em relação ao sinal de sincronismo de 1PPS sob a relação atual de compensação de FS.
Na versão atual da plataforma, simplificando e agilizando a implementação, emprega-se um número limitado de atrasos propositais entre cada requisição de amostra do ADC que é previamente configurado para operar na maior FS próxima a teórica. Ou seja, se configura a unidade de processamento para operar em uma frequência ligeiramente maior do que a desejada e, no decorrer de cada pulso de sincronismo, se adicionam atrasos de compensação (ajustando os registradores do PWM) entre as requisições de maneira uniformemente distribuída no tempo.
Obviamente, tal compensação é obtida de maneira empírica pois cada hard- ware possui precisão relativa a cada componente, ou seja, para placas diferentes de Bea- glebone Black, é esperado que os número de compensações sejam diferentes devendo serem ajustados durante a calibração do dispositivo.
Capítulo 3. Plataforma D-PMU desenvolvida 65
3.4.3
Habilitação das PRUs
Por padrão do SO Linux embarcado não habilita as PRUs presentes na Bea- glebone Black necessitando da configuração do sistema operacional para utilização destas unidades. O emprego de uma estrutura (framework) com um driver é necessário para o gerenciamento e gravação das firmwares nestas unidades e, nas imagens mais recentes do Linux (Debian 8.7 ou superiores) a estrutura padrão utilizada é a Remote PROC. Entretanto este driver padrão da Texas instruments, até a presente data, apresenta limi- tações para comunicação entre PRU e o processador ARM de grandes pacotes de dados a altas taxas. Entretanto a estrutura que utiliza o Driver UIO (Debian 8.6) permite o compartilhamento direto de memória e, por conta disso, foi adotada para a plataforma D-PMU como método utilizado para gravação das PRUs. Com este método, é possível a transferência de todos os dados coletados pelas PRUS através de uma memória dedicada que também é acessivel pelo micrprocessador ARM que roda os programas apresentados na Figura 3.12.
As configurações GPIOs conectados à placa de ADC é feita de maneira mista entre a microprocessador ARM e as unidades PRUs pois, dado o número limitado de pinos dedicados às PRUs, usa-se GPIOs que são controlados e acessíveis somente pelo microprocessador ARM principal. Desta forma, as PRUs ficam responsáveis pelos controle das requisições e de interpretação das amostras do ADC e o microprocessador ARM, responsável pela configuração e habilitação do ADC por meio de GPIOs ligados a sinais como Enable, Reset, Oversampling do ADC.
3.4.4
Interferência nos Barramentos
Sob a perspectiva do design das placas PCB que compõem a D-PMU, é re- comendável que haja atenção no roteamento dos sinais de interface entre a Beaglebone Black e ADC de forma a evitar os problemas de interferência entre os barramentos ou seja, caso um sinal de dados esteja muito próximo ao sinal de Reset do ADC, pode ocorrer, a indução do nível lógico entre os sinais podendo causar, neste caso, o Reset inesperado do ADC.