TCC_CelsoRocha

Prévia do material em texto

Universidade de São Paulo–USP
Escola Politécnica
Celso Henrique Santos Rocha
Análise e Mitigação de Impactos da
Conexão de Geração Distribuída,
Microgeração Distribuída e
Armazenadores em Alimentadores de
Distribuição Utilizando o Software
OpenDSS
São Paulo
2016
Celso Henrique Santos Rocha
Análise e Mitigação de Impactos da
Conexão de Geração Distribuída,
Microgeração Distribuída e
Armazenadores em Alimentadores de
Distribuição Utilizando o Software
OpenDSS
Trabalho de Formatura apresentado à Escola Politéc-
nica da Universidade de São Paulo para obtenção do
título de Bacharel em Engenharia
São Paulo
2016
Celso Henrique Santos Rocha
Análise e Mitigação de Impactos da
Conexão de Geração Distribuída,
Microgeração Distribuída e
Armazenadores em Alimentadores de
Distribuição Utilizando o Software
OpenDSS
Trabalho de Formatura apresentado à Escola Politéc-
nica da Universidade de São Paulo para obtenção do
título de Bacharel em Engenharia
Área de concentração: Energia e Automação Elétricas
Orientador: Nelson Kagan
São Paulo
2016
Catalogação-na-publicação
Rocha, Celso Henrique Santos Rocha
 Análise e Mitigação de Impactos da Conexão de Geração Distribuída,
Microgeração Distribuída e Armazenadores em Alimentadores de Distribuição
Utilizando o Software OpenDSS / C. H. S. R. Rocha -- São Paulo, 2016.
 170 p. 
 Trabalho de Formatura - Escola Politécnica da Universidade de São
Paulo. Departamento de Engenharia de Energia e Automação Elétricas.
 1.Engenharia Elétrica 2.Sistemas Elétricos de Potência 3.Recursos
Distribuídos I.Universidade de São Paulo. Escola Politécnica. Departamento
de Engenharia de Energia e Automação Elétricas II.t.
Agradecimentos
Primeiramente, gostaria de agradecer à Deus por ter me dado o dom da vida e por
ter me dado forças para vencer uns dos momentos mais difíceis que eu passei em minha
vida, durante os primeiros anos da minha graduação. Viver afastado da minha família
realmente não foi fácil. Mas Ele foi responsável por me fazer transformar o sentimento de
saudade em vontade e determinação, lembrando-me sempre o motivo real do porquê de
eu ter saído de casa cedo: a busca por uma educação de excelência.
Em segundo lugar, agradeço à minha amada família pelo apoio incondicional recebido
durante toda a minha caminhada. Mãe, muito obrigado pelo seu amor infinito, pela sua
dedicação à nossa família, pelo incentivo dado aos meus estudos e por sempre ter me
mostrado a sua importância. Muito obrigado pelos “nãos” que a senhora e o papai deram
a mim e a Mana. Eles foram essenciais à nossa formação. Pai, muito obrigado por sempre
ter me apoiado e por sempre ter me dado palavras sábias em momentos importantes dessa
caminhada. Mana, tu és a principal culpada disso. Tu foste a minha maior incentivadora
quando eu decidi prestar vestibular para a USP. Na época, eu não sabia o que viria pela
frente. Muito obrigado, a experiência que eu obtive nesses últimos 6 anos é imensurável.
Mãe, Pai e Mana, amo vocês de coração, e não importa aonde eu vá parar, eu sempre
levarei vocês comigo, seja no meu pensamento, seja nas minhas ações. A minha verdadeira
casa é e sempre vai ser aonde vocês três estiverem!
Eu não poderia deixar de agradecer aos mestres que eu tive contato durante esses
anos de Poli. Obrigado por todos os ensinamentos. As poucas experiência que tive
fora da Poli já me mostraram que a formação que aqui nos é oferecida é de grande
qualidade. Em especial, gostaria de agradecer ao professor e grande amigo Nelson Kagan,
por ter me recebido tão bem no seu laboratório, passando-me grande confiança em tão
pouco tempo. Ao professor Hernán Schmidt, por sempre ter me dado conselhos sinceros,
ter sido extremamente atencioso sempre que tive dúvidas e por ser um grande amigo.
Agradeço também à professora Eliane Fadigas, por ter me oferecido a oportunidade única
de trabalhar em um grande projeto de campo ainda no meu segundo ano de graduação.
Junto à esses, agradeço os professores Ivan Chabu e Eduardo Senger pelo nível das aulas
oferecidas e comprometimento com os alunos. Tenho todos vocês como exemplos de
educadores a serem seguidos.
I would like to give a special thanks to Mark McGranaghan and Geraldine Porter for
receiving me so well in their home during this last semester. I will never forget everything
you two did for me. I would also like to say thank you to all the people in the Power
Systems Studies Group at EPRI, Knoxville. I would never imagine that I would have the
chance to work with such smart and friendly people in my first professional experience
within a company. Thanks for sharing with me a little bit of your knowledge with so
much attention. I hope to have the chance to work with you all again. You are awesome!
Por fim, obrigado à Poli por ter me dado dois irmãos, Paulo e Bahia. Foram com vocês
que eu tive as conversas mais sérias e as brincadeiras mais idiotas nesses seis anos. A Poli
teria sido muito mais difícil e sem graça sem vocês dois. Paulo, essa vai especialmente pra
ti. Muito obrigado por toda a ajuda que tu me deste na Poli. Eu admiro muito a pessoa
que tu te tornaste e a dedicação que tu colocas em todas as tuas tarefas. Tamo junto!
“Se você quer transformar o mundo, experimente primeiro promover o seu
aperfeiçoamento pessoal e realizar inovações no seu próprio interior. Estas atitudes se
refletirão em mudanças positivas no seu ambiente familiar. Deste ponto em diante, as
mudanças se expandirão em proporções cada vez maiores. Tudo o que fazemos produz
efeito, causa algum impacto.”
Dalai Lama
Resumo
Nos últimos anos, as redes elétricas de distribuição têm passado por uma transforma-
ção significativa, com um crescimento da infraestrutura de medição, controle e a inserção
de uma quantidade considerável de geração, principalmente a partir de fontes renováveis,
e elementos armazenadores de energia. Esse cenário criou desafios no planejamento des-
ses sistemas, com a introdução de certos impactos na rede que requerem a utilização de
ferramentas computacionais com modelos fiéis e a flexibilidade necessária para realizar
novos tipos de estudos. O objetivo desse trabalho é analisar e mitigar um dos impac-
tos da conexão de recursos distribuídos em uma rede de distribuição utilizando o software
OpenDSS. Inicialmente focou-se no estudo do algoritmo interno e na modelagem dos prin-
cipais componentes e controles implementados nessa ferramenta. Em seguida, verificou-se
como pode-se interferir no processo de simulação do software e implementar algoritmos e
elementos de controle personalizados. Utilizou-se a rede IEEE 123 Barras modificada e
analisou-se como a conexão de painéis fotovoltaicos impacta na operação dos reguladores
de tensão dessa rede. Por fim, os impactos verificados foram mitigados através da utili-
zação de baterias e de um algoritmo de controle baseado em uma média móvel. Por fim,
uma modificação nesse algoritmo foi proposta visando a redução do dimensionamento das
baterias.
Palavras-chave: Redes Elétricas Inteligentes. Simulação de Sistemas de Potência.
OpenDSS. Fluxo de Potência. Geração Distribuída. Redes de Distribuição.
Abstract
In the last years, the electric distribution grids have been passing through a significant
transformation, with a growth in metering and control infrastructure and the introduction
of great amounts of generation, mainly by employing renewable resources, and energy
storage. This scenario imposed challenges in the planning of those systems, including the
introduction of certain impacts in the grid which require the use of computacional tools
able of modelling them with the reliability and the flexibility required to perform new
types of studies. The aim of this project is to analyze and to mitigate one of the impacts
caused by the connection of distributed resources in a distribution system by using the
software OpenDSS. Initially, the focus has been put in the study of the internal algorithm
and in the modelling of the main components and controls currentlyimplement in the
software. Then, it has been verified how one can interfere in the simulation process and
implement custom algorithms and control elements. The IEEE 123 Buses Test Case with
modifications has been used and it has been analyzed how the connection of a photovoltaic
system impacts the behavior of the system’s voltage regulators. The verified impact has
been mitigated by using batteries along with a dispatch control method based on a moving
average. Finally, a modification in the algorithm has been proposed in order to reduce
the size of the battery required for this application.
Keywords: Smart Grid. Power Systems Simulation. OpenDSS. Power Flow. Distributed
Generation. Distribution Grids.
Lista de ilustrações
Figura 1 Escalas de Tempo relevantes em Sistemas de Potência . . . . . . . . . . 26
Figura 2 Diagrama do modelo do Sistema Fotovoltaico no Open Distribution
System Simulator (OpenDSS) . . . . . . . . . . . . . . . . . . . . . . . 30
Figura 3 Corrente de curto-circuito, 𝐼𝑠𝑐, tensão em vazio, 𝑉𝑜𝑐 e potência máxima,
𝑃𝑚𝑎𝑥, normalizados em função da temperatura da célula fotovoltaica, a
uma dada irradiância, de um painel fotovoltaico de aplicação residencial
típico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 4 Corrente de curto-circuito, 𝐼𝑠𝑐, tensão em vazio, 𝑉𝑜𝑐 e potência máxima,
𝑃𝑚𝑎𝑥, normalizados de uma célula, em função da irradiância, para uma
dada temperatura, de um painel fotovoltaico de aplicação residencial
típico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figura 5 Diagrama do modelo do Armazenador de Energia no OpenDSS . . . . 33
Figura 6 Ilustração do comportamento do Armazenador de Energia no modo
padrão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figura 7 Ilustração do comportamento do Armazenador de Energia no modo
seguidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 8 Diagrama do modelo do Armazenador de Energia no OpenDSS, quando
no estado de descarga . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figura 9 Diagrama do modelo do Armazenador de Energia no OpenDSS, quando
no estado de carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 10 Diagrama de Blocos do Processo de Simulação do OpenDSS . . . . . . 42
Figura 11 Funcionamento da Lista de Controle . . . . . . . . . . . . . . . . . . . 43
Figura 12 Verificação no elemento de controle antes da execução da ação . . . . . 45
Figura 13 Arquitetura do OpenDSS . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 14 Taps do enrolamento controlado na configuração default. . . . . . . . . 48
Figura 15 Representação esquemática do Regulador de Tensão e parâmetros do
OpenDSS associados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figura 16 Regulador de Tensão com Compensação por Queda de Tensão de Linha 50
Figura 17 Definição da banda na qual o regulador não atua, com os valores default. 52
Figura 18 Banco de capacitores genérico no OpenDSS . . . . . . . . . . . . . . . 56
Figura 19 Evolução do estado de um religador para uma falta permanente de
acordo com as configurações default. . . . . . . . . . . . . . . . . . . . 58
Figura 20 Diagrama de blocos do processo de simulação com pontos onde o usuá-
rio pode interagir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 21 Interação entre o Control Proxy e a lista de controle do OpenDSS . . . 68
Figura 22 Rede IEEE 8500 Barras . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Figura 23 Rede IEEE 8500 Barras com consumidores escolhidos em destaque . . 70
Figura 24 Curvas de carga adicionadas às cargas prioritárias e não prioritárias
dos três consumidores em questão . . . . . . . . . . . . . . . . . . . . . 71
Figura 25 Demanda Total dos consumidores e demanda por tipo de carga ao longo
do dia simulado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figura 26 Saída do código desenvolvido em Python . . . . . . . . . . . . . . . . . 73
Figura 27 Trecho da lista de ações evidenciando a presença de uma ação inserida
através da CtrlQueue Interface . . . . . . . . . . . . . . . . . . . . . . 74
Figura 28 Diagrama Unifilar da rede IEEE123 Barras . . . . . . . . . . . . . . . . 79
Figura 29 Diagrama Unifilar da rede IEEE123 Barras com a adição de um sistema
fotovoltaico e um transformador de conexão na barra 300 e com as
linhas trifásicas em evidência (linha cheia) . . . . . . . . . . . . . . . . 80
Figura 30 Curva de irradiação normalizada, com zoom em um intervalo de tempo
de aproximadamente 5 minutos . . . . . . . . . . . . . . . . . . . . . . 81
Figura 31 Curva de carga diária . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Figura 32 Tensão no ponto de conexão da geração solar para diferentes níveis de
penetração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figura 33 Número acumulado de operações dos reguladores de tensão ao longo
de um dia para diferentes níveis de carga e de penetração . . . . . . . . 83
Figura 34 Conexão do sistema fotovoltaico em paralelo com baterias na barra 300
da rede IEEE 123 barras através de um transformador de interconexão 86
Figura 35 Representação da janela móvel . . . . . . . . . . . . . . . . . . . . . . 87
Figura 36 Diagrama de blocos do algoritmo para suavização da flutuação da po-
tência injetada na rede pelos painéis fotovoltaicos . . . . . . . . . . . . 87
Figura 37 Representação da inicialização do registrador de deslocamento utilizado
no cálculo da média móvel. . . . . . . . . . . . . . . . . . . . . . . . . 89
Figura 38 Representação do registrador de deslocamento utilizado no cálculo da
média móvel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Figura 39 Potência injetada na rede no caso base e para diferentes tamanhos de
janela da média móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figura 40 Potência injetada na rede no caso base e para diferentes tamanhos de
janela da média móvel, versão com zoom em um intervalo de aproxi-
madamente 90 minutos . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figura 41 Potência injetada nas baterias para diferentes tamanhos de janela da
média móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Figura 42 Potência injetada nas baterias para diferentes tamanhos de janela da
média móvel, ampliada . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figura 43 Número acumulado de operações dos reguladores de tensão no caso
base e para 3 diferentes tamanhos de janela móvel . . . . . . . . . . . . 94
Figura 44 Energia armazenada na bateria das 5:00hr - 19:00hr para diferentes
tamanhos da janela móvel . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figura 45 Diagrama de blocos do algoritmo para suavização da flutuação da po-
tência gerada pelos painéis fotovoltaicos, com controle de estado de
carga da bateria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figura 46 Energia armazenada na bateria com controle de estado de carga para
uma janela móvel de 10 minutos e diferentes ganhos K . . . . . . . . . 97
Figura 47 Número de operações dos reguladores de tensão para uma média móvel
de 10 minutos e controle de estado de carga da bateria para diferentes
ganhos K . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figura 48 Influência do ganho K nas especificações mínimas da bateria, na energia
necessária para preparar a bateria para a operação no dia seguinte e
na quantidade de operações acumulada dos reguladores de tensão . . . 100
Figura 49 Diagrama de blocos do processo de simulação do OpenDSS evidenci-
ando as funções utilizadas em cada etapa e os pontos de medição da
lista de controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Figura 50 Registro de Eventos do OpenDSS no modo de controle estático . . . . 120
Figura 51 Saída da simulação através da interfaceCOM . . . . . . . . . . . . . . 121
Figura 52 Registro de Eventos do OpenDSS no modo de controle temporal . . . . 123
Figura 53 Registro de Eventos do OpenDSS gerado pelo código em Python no
modo de controle temporal . . . . . . . . . . . . . . . . . . . . . . . . . 123
Lista de tabelas
Tabela 1 Parâmetros do elemento de controle RegControl . . . . . . . . . . . . . 47
Tabela 2 Parâmetros do elemento de controle CapControl . . . . . . . . . . . . . 54
Tabela 3 Parâmetros do elemento de controle Recloser . . . . . . . . . . . . . . 57
Tabela 4 Parâmetros do elemento de controle Relay . . . . . . . . . . . . . . . . 62
Tabela 5 Parâmetros do elemento de controle StorageController . . . . . . . . . 63
Tabela 6 Parâmetros do elemento de controle SwtControl . . . . . . . . . . . . . 64
Tabela 7 Parâmetros do elemento de controle Fuse . . . . . . . . . . . . . . . . . 64
Tabela 8 Dados dos reguladores de tensão . . . . . . . . . . . . . . . . . . . . . 78
Tabela 9 Cenários simulados para verificação da atuação dos reguladores de tensão 82
Tabela 10 Impacto de diferentes níveis de carga e penetração na quantidade total
de operações dos reguladores de tensão . . . . . . . . . . . . . . . . . . 84
Tabela 11 Número de operações individuais dos reguladores da rede IEEE 123
Barras para todos os casos simulados . . . . . . . . . . . . . . . . . . . 84
Tabela 12 Comparação entre a operação da bateria para os três tamanhos de
janela móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Tabela 13 Comparação entre a operação da bateria para uma janela móvel de 10
minutos com diferentes valores de ganho K . . . . . . . . . . . . . . . . 99
Lista de siglas
ANEEL Agência Nacional de Energia Elétrica
ANSI American National Standards Institute
MT Média Tensão
BT Baixa Tensão
COM Component Object Model
CVR Conservation Voltage Reduction
DLL Dynamic-link Library
DMS Distribution Management System
EPRI Electric Power Research Institute
GD Geração Distribuída
IEEE Instituto de Engenheiros Eletricistas e Eletrônicos
IMA Infraestrutura de Medição Automatizada
LTC Load Tap Changer
LDC Line Drop Compensation
OpenDSS Open Distribution System Simulator
PCE Power Conversion Element
QSTS Quasi-Static Times-Series
RPS Regime Permanente Senoidal
TP Transformador de Potencial
TC Transformador de Corrente
TCC Time-Current Curve
UPFC Unified Power Flow Controller
Sumário
1 Introdução 23
1.1 Sistemas Elétricos de Distribuição . . . . . . . . . . . . . . . . . . . . . . 23
1.2 O Open Distribution System Simulator (OpenDSS) . . . . . . . . . . . . . 24
1.3 Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2 Modelos de Recursos Distribuídos implementados no OpenDSS 29
2.1 Sistema Fotovoltaico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2 Armazenador de Energia . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.1 Cálculo de perdas e atualização da energia armazenada . . . . . . 37
3 Implementação de controles no OpenDSS 41
3.1 Lógica interna de execução do controle . . . . . . . . . . . . . . . . . . . . 41
3.1.1 Modos de controle . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Controles Implementados no OpenDSS . . . . . . . . . . . . . . . . . . . 46
3.2.1 Regulador de Tensão . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.2 Controle de Capacitores . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.3 Religadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.4 Relé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.5 Controle de Armazenadores de Energia . . . . . . . . . . . . . . . 59
3.2.6 Controle de Chaves . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2.7 Controle de Fusíveis . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4 Inserção de elementos de controle externos e Controle do OpenDSS
via interface COM utilizando a linguagem Python 65
4.1 A interface COM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2 Inserindo funções próprias na algoritmo de controle interno do OpenDSS . 66
4.2.1 A interface de controle CtrlQueue Interface . . . . . . . . . . . . . 67
4.3 Exemplo de aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 Aplicação de algoritmo de controle personalizado em recursos distri-
buídos adicionados à rede IEEE123 Barras 75
5.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2 A rede IEEE 123 Barras . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.1 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.2 Modificações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.3 Dados de entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.3.1 Sistema Fotovoltaico . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.3.2 Curvas de carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.4 Constatação do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.5 Solução proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.5.1 Média Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.5.2 Média Móvel com controle de carga da bateria . . . . . . . . . . . 96
5.5.3 Comentários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Conclusão 103
Referências 107
Apêndices 111
APÊNDICE A Verificação do processo de simulação do OpenDSS 113
A.1 Controle no modo estático . . . . . . . . . . . . . . . . . . . . . . . . . . 113
A.2 Controle no modo temporal . . . . . . . . . . . . . . . . . . . . . . . . . . 120
A.3 Comentários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
APÊNDICE B Códigos do Exemplo de Aplicação do Capítulo 5 125
B.1 Scripts no OpenDSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
B.2 Scripts em Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
APÊNDICE C Códigos da Aplicação do Capítulo 6 135
C.1 Scripts no OpenDSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
C.2 Scripts em Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
23
Capítulo 1
Introdução
1.1 Sistemas Elétricos de Distribuição
O planejamento e o design dos sistemas elétricos de distribuição têm sofrido uma
grande mudança no mundo todo. Por um lado, há uma crescente restrição ambiental que
inviabiliza empreendimentos de grande porte e a utilização de fontes de energia poluen-
tes. Por outro, há um grande avanço em comunicação que permite uma ampliação do
conhecimento do estado da rede e que pode proporcionar um maior controle da mesma,
com uma maior integração entre seus componentes. Nas redes de distribuição, essa reali-
dade gira em torno do conceito de Smart Grids. Segundo (DUGAN; MCDERMOTT, 2011),
embora não haja um consenso quanto a definição de Smart Grids, alguns aspectos são
comuns à várias arquiteturas propostas como a utilização de Geração Distribuída (GD)
baseada em fontes renováveis, a utilização de sistemas de armazenamento de energia, uma
Infraestrutura de Medição Automatizada (IMA), uma maior confiabilidade baseada em
localização automática de faltas, restauração automática do sistema, comunicação de alta
velocidade para medição e controle e um melhor uso dos ativos do sistema.
Um dos principais aspectos refere-se à geração distribuída, tanto de unidades gera-
doras independentes quanto de tradicionais consumidores. No passado, o planejamento
dos sistemas de distribuição era focado na manutenção de condições elétricas aceitáveis
durante a demanda de pico. Com o aumento da penetração de fontes de energia distribuí-
das, incluindo as fontes intermitentes como a solar fotovoltaica e a eólica, a rede precisa
ser analisada e planejada para condições de operação dinâmicas que podem ocorrer em
qualquer momento do ano. Além disso, a maioria dos sistemas de distribuição não foram
projetadospara uma penetração significativa de (GD). Os padrões utilizados pelas empre-
sas de distribuição de energia elétrica que visam a interconexão de (GD) assumem baixos
níveis de penetração. Nesse contexto, há um reconhecimento da alteração dos requisitos
do sistema pela indústria.
Desse modo, há necessidade de se realizarem estudos através de simulações que envol-
vem a operação conjunta do sistema de potência em si, juntamente com os sistemas de
24 Capítulo 1. Introdução
controle, sensoriamento e comunicação. Essa nova realidade, muito mais complexa que
a rede de distribuição tradicional, exige que sejam utilizados softwares com os melhores
modelos dos elementos da rede disponíveis.
1.2 O Open Distribution System Simulator (OpenDSS)
De acordo com (SMITH; DUGAN; SUNDERMAN, 2011), a indústria dos sistemas elétricos
de distribuição tem investigado os problemas a cerca da integração de recursos distribuídos
na rede de distribuição. Muito desse esforço tem limitado-se a usar modelos simplificados
de alimentadores, com dados típicos e simulações para um único instante de tempo, ao
invés de considerar a natureza intermitente e não coincidente com os instantes críticos
do sistema de alguns recursos como as fontes renováveis e como elas interagem com o
sistema.
As simulações computacionais de sistemas de potência classificam-se basicamente em
quatro categorias quanto ao intervalo de tempo em análise, (MILLER et al., 2013). Essas
categorias são brevemente descritas abaixo:
1. Simulação Estática: A simulação estática corresponde a solução do problema de
fluxo de potência clássico, no qual as tensões e as correntes injetadas em todos os
nós do sistema são calculadas a partir de um processo iterativo, em um instante
específico do sistema. Esse tipo de solução assume que o sistema encontra-se em
equilíbrio, isto é, no Regime Permanente Senoidal (RPS). Em sistemas de distri-
buição, tradicionalmente utilizava-se a simulação estática em instantes considerados
críticos para a rede, tal qual nas condições de máxima e mínima demanda. O ob-
jetivo principal era determinar o carregamento máximo dos equipamentos da rede
bem como avaliar se a tensão em todos os pontos do sistema permaneciam dentro
de limites aceitáveis.
2. Simulação Quase-Estática: Nas simulações quase estáticas (do inglês, quasi-static)
são realizados vários fluxos de potência em pequenos intervalos de simulação. A
solução de um fluxo de potência determina o estado inicial do sistema para o pró-
ximo, e assim sucessivamente. A velocidade desse tipo de simulação é rápida o
suficiente para que análises anuais em intervalos de tempo da ordem de segundos
sejam praticáveis em microcomputadores. Esse tipo de simulação é o mais utili-
zado para a avaliação do impacto da conexão de recursos distribuídos em reded de
distribuição. Problemas como regulação de tensão, análise de curto-curto circuito,
localização de faltas, harmônicas, fluxo de potência reverso, impacto em capacitores
chaveados e reguladores de tensão são comumente realizados por meio da simulação
quase estática.
3. Simulação Dinâmica:
1.3. Organização do Documento 25
Esse tipo de simulação é utilizado quando o sistema não pode ser tratado como se
estivesse no RPS no intervalo de tempo em questão. Normalmente ele é utilizado
para analisar problemas de estabilidade após alguma perturbação no sistema, como
uma falta ou a abertura de uma chave, e problemas de ressonância. O passo de
simulação é da ordem de centésimos a décimos de segundos.
4. Simulação Transitória: Do mesmo modo que na simulação dinâmica, a análise em
transitórios é empregada quando há algum distúrbio no sistema, porém da ordem
de até milésimos de segundos como, por exemplo, nos casos de descargas elétricas,
transitórios de chaveamento e operação de sistemas de proteção.
Tanto na simulação transitória quanto na dinâmica, modelos mais elaborados dos com-
ponentes do sistema devem ser utilizados e o processo de simulação exige uma capacidade
computacional elevada, levando cerca de minutos e até horas para a análise de um pe-
queno intervalo de tempo. A Figura 1 descreve a escala de tempo de algumas dinâmicas
presentes em sistemas de potência. O fato de haver diferentes fenômenos ocorrendo com
diferentes constantes de tempo, da ordem de microssegundos a horas, torna a análise
simultânea de todos eles inviável através de um modelo único. Na prática, a partir do
fenômeno que se deseja analisar, define-se o passo de simulação de tal modo que as dinâ-
micas relevantes sejam capturadas, utilizando-se modelos e ferramentas computacionais
capazes de representar as mesmas. O software OpenDSS foi escolhido como ferramenta de
simulação para este trabalho. Ele é capaz de realizar simulações do tipo quase-estáticas
nas quais, além do que já foi citado acima, têm sido utilizadas para avaliar a intermitência
de fontes renováveis como a solar fotovoltaica e a eólica, nas quais a variação da irradiação
devido ao sombreamento e a variação da velocidade do vento, respectivamente, exigem
que um passo de simulação da ordem de poucos segundos seja utilizado de tal modo que
os efeitos da intermitência dessas fontes sejam corretamente quantificados, principalmente
quanto a flutuações de tensão, como apresentado em (SMITH; DUGAN; SUNDERMAN, 2011)
e (CHIRAPONGSANANURAK et al., 2012).
1.3 Organização do Documento
A seguir, apresenta-se um breve resumo dos capítulos do presente trabalho:
O Capítulo 1 apresenta uma rápida descrição das mudanças que vêm ocorrendo nas
redes de distribuição de energia e a motivação para as mesmas. Além disso, apresenta-se
os tipos de simulação comumente utilizados em sistemas elétricos de potência definidos
pelo tamanho do passo de simulação e também a consequente complexidade dos modelos.
As diferentes constantes de tempo de fenômenos elétricos relevantes são comparadas com
as constantes de tempo das ações de controle típicas. Alguns dos impactos da conexão
de recursos distribuídos na rede de distribuição são citados e comentários sobre como eles
26 Capítulo 1. Introdução
Figura 1: Escalas de Tempo relevantes em Sistemas de Potência
Controle de FACTS
Controle de Geradores 
Proteções
Controle de Turbinas
 Controle de Tap
 Controle de Carga x Frequência
Ações do Operador
Surtos Atmosféricos
Surtos de Manobra
Ressonância sub-síncrona
Estabilidade Transitória
Dinâmica de Longa duração
Regulação de Linha de interconexão
Curva de Carga Diária
Escala de Tempo [s]
A
çõ
e
s 
d
e
 c
o
n
tr
o
le
F
e
n
ô
m
e
n
o
s
1 dia1 hora1 minuto1 segundo1 grau a 50Hz 1 ciclo
10-7 10-6 10
-5 10-4 10-310
-2
10-1 100 101 102 103 104 105
Fonte: tradução própria, adaptado de (MILANO, 2010)
têm sido analisados no OpenDSS são tecidos. Assim, o escopo do projeto é reduzido às
análises passíveis de serem implementadas no software escolhido.
O Capítulo 2 apresenta os modelos dos recursos distribuídos implementados no OpenDSS
e que são utilizados ao longo do projeto, procurando-se frisar as hipóteses assumidas, a
validade das mesmas e referenciando projetos com protótipos reais que validaram esses
modelos.
O Capítulo 3 apresenta em detalhes os principais tipos de controle atualmente im-
plementados no OpenDSS como, por exemplo, o funcionamento de Load Tap Chan-
ger (LTC), reguladores de tensão, banco de capacitores chaveados e Unified Power Flow
Controller (UPFC). Analisa-se o funcionamento do algoritmo interno do software, es-
pecificamente da Control Queue, responsável por gerenciar as ações de controle durante
o processo de simulação. Além disso, uma simulação da rede IEEE 13 Barras é reali-
zada com o objetivo de verificar a operação do processo de simulação software em dois
modos de controle distintos e, também, na versão standalone a na versão Dynamic-link
Library (DLL). Os códigos utilizados e comentários são fornecidos no apêndice A.
O Capítulo 4 explica o funcionamento da CtrlQueue Interface, disponível através
da versão DLL do software, e como ela pode ser utilizada para inserção dealgoritmos
1.3. Organização do Documento 27
e/ou elementos de controle personalizados. Inicialmente, uma breve introdução à in-
terface Component Object Model (COM) é fornecida e, ao fim do capítulo, um exem-
plo de aplicação é desenvolvido na rede de testes Instituto de Engenheiros Eletricistas e
Eletrônicos (IEEE) 8500 Barras.
O Capítulo 5 apresenta a aplicação final desse trabalho, que consiste, primeiramente,
na análise do aumento do número de operações dos reguladores de tensão da rede de testes
IEEE 123 Barras quando adiciona-se painéis fotovoltaicos com uma curva de irradiação
com alta variabilidade e em diferentes níveis de penetração. Em seguida, um método
para a mitigação do problema verificado que utilizada baterias é implementado, os resul-
tados são apresentados e, por fim, uma modificação desse método é proposta visando-se
a redução do dimensionamento das baterias.
28 Capítulo 1. Introdução
29
Capítulo 2
Modelos de Recursos Distribuídos
implementados no OpenDSS
Esse capítulo apresenta a descrição e a modelagem dos modelos de recursos distribuídos
atualmente presentes no OpenDSS e que serão utilizados na aplicação final desse trabalho.
2.1 Sistema Fotovoltaico
O diagrama do modelo de Sistema Fotovoltaicos no OpenDSS é apresentado na Figura
2. Como se pode notar, o modelo já possui um inversor agregado. Assim como cargas e
geradores, o sistema fotovoltaico é tratado como um elemento de conversão de energia,
no qual há geração de potência de acordo com uma determinada função.
A potência de saída do sistema é descrita pela seguinte expressão:
𝑃𝐷𝐶(𝑡) = 𝑃𝑝𝑚𝑝(1𝑘𝑊/𝑚2) × 𝑖𝑟𝑟𝑎𝑑(𝑡) × 𝑖𝑟𝑟𝑎𝑑𝐵𝑎𝑠𝑒 × 𝑃𝑝𝑚𝑝(𝑇 (𝑡)) (1)
𝑃𝐴𝐶(𝑡) = 𝑃𝐷𝐶(𝑡) × 𝜂(𝑃𝐷𝐶(𝑡)) (2)
o 𝑃𝐷𝐶(𝑡):Potência de saída do sistema fotovoltaico em um dado instante, 𝑡.
o 𝑃𝑝𝑚𝑝(1𝑘𝑊/𝑚2): Potência nominal do arranjo fotovoltaico no ponto de máxima
potência a uma irradiância de 1𝑘𝑊/𝑚2 e uma dada temperatura.
o 𝑖𝑟𝑟𝑎𝑑(𝑡): Irradiância em pu em um dado instante, 𝑡, utilizada como multiplicador
para modificar a irradiância de base.
o 𝑖𝑟𝑟𝑎𝑑𝐵𝑎𝑠𝑒: Irradiância de base.
o 𝑃𝑝𝑚𝑝(𝑇 (𝑡)): 𝑃𝑝𝑚𝑝 Fator de correção da potência gerada em função da temperatura
em um dado instante, 𝑡.
o 𝜂(𝑃𝐷𝐶(𝑡)): Eficiência do inversor em função da potência do arranjo fotovoltaico
𝑃𝐷𝐶(𝑡).
30 Capítulo 2. Modelos de Recursos Distribuídos implementados no OpenDSS
Figura 2: Diagrama do modelo do Sistema Fotovoltaico no OpenDSS
dc
ac
V
I
.
.
PFkvarkV Conexão
Temperatura
Irradiação de Base
Temperatura(t)
Irradiação(t)
Diário
Anual
Duty
(T)
T
P
Pdcx 
@ 1 kW/m²
Ppmp
Ppmp
Pdc ᶯ
ᶯ
Curvas
Fonte: tradução própria, adaptado de (SMITH; DUGAN; SUNDERMAN, 2011)
Esse modelo é adequado para simulações com um passo de tempo de no mínimo um
segundo, pois o modelo assume que o inversor é capaz de rastrear o ponto de máxima
potência rapidamente. Isso simplifica consideravelmente a modelagem do sistema e é uma
consideração adequada para a maioria dos estudos de impacto da conexão de recursos
distribuídos. Na definição do modelo no software quatro curvas devem ser definidas:
1. Fator de correção da potência gerada em função da temperatura 𝑃𝑝𝑚𝑝 × 𝑇 (𝑡): A
potência gerada no ponto de máxima potência varia com a temperatura em relação à
temperatura escolhida para a potência máxima nominal. 𝑃𝑝𝑚𝑝(𝑇 (𝑡)) é um fator em
pu e igual a 1 para a temperatura na qual a potência nominal no ponto de máxima
potência foi definida. A relação entre essas duas grandezas é praticamente linear.
Deve ser definida como um objeto da classe XYCurve, que consiste basicamente em
dois arrays com a quantidade de pontos definida pelo usuário. Pontos da curva não
definidos são interpolados. A Figura 3 foi extraída das especificações técnicas de
um painel fotovoltaico padrão em aplicações residenciais e mostra a relação linear
da curva 𝑃𝑝𝑚𝑝 × 𝑇 (𝑡). Exemplo:� �� �
New Loadshape . MyIrrad npts=24 i n t e r v a l=1 mult=[0 0 0 0 0 0 . 1 . 2 . 3
. 5 . 8 . 9 1 . 0 1 . 0 . 99 . 9 . 7 . 4 . 1 0 0 0 0 0 ]
 	� �
2.1. Sistema Fotovoltaico 31
Figura 3: Corrente de curto-circuito, 𝐼𝑠𝑐, tensão em vazio, 𝑉𝑜𝑐 e potência máxima, 𝑃𝑚𝑎𝑥,
normalizados em função da temperatura da célula fotovoltaica, a uma dada irradiância,
de um painel fotovoltaico de aplicação residencial típico
Fonte: extraído de (SOLAR, 2016)
2. Temperatura x Tempo, T(t): Essa curva descreve a variação da temperatura ao
longo de um determinado período. É utilizada em simulações temporais. Deve ser
definida como um objeto da classe Tshape. Exemplo:� �� �
New XYCurve .MyPvsT npts=4 xarray =[0 25 75 100 ] yarray =[1.0 1 .0
1 .0 1 . 0 ]
 	� �
3. Curva de eficiência do inversor, 𝜂 * 𝑃𝐷𝐶(𝑡): Essa curva representa a variação da
eficiência do inversor em função da potência de entrada, 𝑃𝐷𝐶(𝑡). Sabe-se que, na
prática, a curva de eficiência do inversor corresponde a uma família de curvas,
dependendo da tensão do barramento DC, porém, o atual modelo utiliza apenas
uma curva, que deve ser próxima da tensão DC de operação típica. Também deve
ser definida como uma curva XY. Exemplo:� �� �
New XYCurve . MyEff npts=4 xarray =[ .1 . 2 . 4 1 . 0 ] yarray =[1 1 1
1 ]
 	� �
4. Curva de irradiância em função do tempo, irrad(t): Essa curva é utilizada em
simulações temporais e corresponde a um multiplicador responsável por modificar
a irradiância de base, irradBase. No software, é uma curva pertencente à classe
32 Capítulo 2. Modelos de Recursos Distribuídos implementados no OpenDSS
Loadshape. A relação entre a potência no ponto de máxima potência e a irradiação, à
uma dada temperatura, varia muito pouco na prática. Por esse motivo, essa relação é
considerada constante. Assim como a última figura, a Figura 4 também foi extraída
das especificações técnicas de um painel fotovoltaico de aplicação residencial típico.
Os parâmetros do modelo são especificados para uma irradiância de 1000 𝑊/𝑚2,
com o objetivo de tornar o modelo mais preciso quando a potência gerada é elevada,
situação na qual os impactos na rede são maiores. Exemplo:� �� �
New Loadshape . MyIrrad npts=24 i n t e r v a l=1 mult=[0 0 0 0 0 0 . 1 . 2 . 3
. 5 . 8 . 9 1 . 0 1 . 0 . 99 . 9 . 7 . 4 . 1 0 0 0 0 0 ]
 	� �
Figura 4: Corrente de curto-circuito, 𝐼𝑠𝑐, tensão em vazio, 𝑉𝑜𝑐 e potência máxima, 𝑃𝑚𝑎𝑥,
normalizados de uma célula, em função da irradiância, para uma dada temperatura, de
um painel fotovoltaico de aplicação residencial típico
Fonte: extraído de (SOLAR, 2016)
2.2 Armazenador de Energia
O diagrama do modelo de armazenadores de energia no OpenDSS é apresentado na
Figura 5. Assim como o modelo de Painéis Fotovoltaicos, os armazenadores de energia
também são tratados como elementos de conversão de energia. Eles essencialmente são
geradores que podem ser despachados para consumir energia do sistema, durante a carga,
ou gerar energia para o sistema, durante a descarga e, obviamente, quando dentro de suas
2.2. Armazenador de Energia 33
especificações de limite de taxa de carga e descarga, e com disponibilidade de energia,
tanto para consumo quanto para geração. O modelo de armazenador de energia pode
operar isoladamente ou ser controlado por um StorageController, cujo funcionamento
será descrito no 3.
Figura 5: Diagrama do modelo do Armazenador de Energia no OpenDSS
Energia 
Armazenada
Eficiência de Carga
 e Descarga
kW, kvar
Estado
Perdas por 
Inatividade
Fonte: adaptado de (EPRI, 2011)
Como pode ser notado na Figura 5, esse elemento possui 3 estados:
o Carga: O elemento só pode entrar nesse estado quando a quantidade de energia
armazenada(kWhStored ou %Stored) é menor que a quantidade de energia nominal
(kWhRated). A taxa de carga é definida pelo usuário através do parâmetro %Charge.
o Descarga: O elemento só pode entrar nesse estado se a quantidade de energia ar-
mazenada é tal que a capacidade máxima de descarga (%Reserve) não seja violada.
A taxa de descarga é definida pelo usuário através do parâmetro %Discharge.o Isolado: Nesse estado, não há transferência de potência ativa entre o sistema e o
elemento. Pode-se especificar perdas enquanto o elemento se encontra nesse estado,
chamadas de idling losses, ou, perdas por inatividade. Essas perdas representam
a energia necessária para manter controles internos, aquecedores e ventiladores em
funcionamento, com o intuito de manter a temperatura de baterias em um nível
adequado. As perdas por inatividade são modeladas como uma impedância shunt
conectada ao sistema e podem ser definidas pelo parâmetro %IdlingkW e %Idlingk-
var.
Quando nos estados de carga e descarga, esse elemento normalmente é modelado como
uma carga, positiva ou negativa, com uma potência constante, porém, também é possível
34 Capítulo 2. Modelos de Recursos Distribuídos implementados no OpenDSS
modelar esse elemento como uma impedância constante. Ao todo, os armazenadores
de energia apresentam cinco modos de despacho, que são acionados por dois gatilhos,
um de carga(ChargeTrigger) e um de descarga(DischargeTrigger). O funcionamento dos
gatilhos é diferente dependendo do modo de despacho escolhido. Cada modo de despacho
é explicado em detalhes abaixo:
1. Modo Padrão (Standard):
Nesse modo, os gatilhos de carga e descarga seguem uma curva de carga (loadshape)
especificada pelo usuário. A regra é que sempre que sempre que o valor da curva de
carga é maior que o valor especificado pelo gatilho de descarga, o armazenador de
energia descarrega à uma potência fixa, definida pela taxa de descarga %Discharge.
A descarga continua até que a capacidade máxima de descarga seja atingida ou
a curva de carga assuma um valor menor que o gatilho de descarga. De modo
análogo, sempre que o valor da curva de carga é menor que o valor especificado
pelo gatilho de carga, o elemento carrega à uma potência constante, até que a
curva de carga assuma um valor maior que o gatilho de carga ou o elemento se
encontre completamente carregado. Sobreposto à regra acima, há um critério que é
prioritário em relação gatilho de carga quando especificado. Esse critério é temporal
e é definido pelo parâmetro TimeChargeTrigger. Corresponde basicamente à uma
hora do dia na qual o carregamento do armazenador de energia é ativado, mesmo
que a carga da curva de carga não seja inferior que o valor especificado pelo gatilho
de carga. Esse mecanismo é normalmente utilizado para carregar um armazenador
de energia durante a madrugada, quando a demanda é baixa, para garantir que o
armazenador de energia esteja completamente carregado para a demanda de pico do
dia seguinte. A figura abaixo representa o funcionamento desse elemento no modo
padrão para um ChargeTrigger igual a 0.3, um DischargeTrigger igual a 0.8 e um
TimeChargeTrigger igual a 2 (02:00hr).
2. Modo Seguidor (Follow):
Como o próprio nome sugere, nesse modo, o carregamento e o descarregamento
do armazenador de energia obedecem uma curva de carga (loadshape) até que o
armazenador esteja completamente carregado ou descarregado até a sua capacidade
máxima, sendo que o elemento é descarregado quando a curva de carga apresenta
valores positivos e carregado quando a curva de carga apresenta valores negativos.
As taxas de carga e descarga são proporcionais à potência nominal do armazenador,
definida pelo parâmetro kWrated. A Figura 7 apresenta a taxa de descarga, a curva
de carga e a energia armazenada em um armazenador de 1000kWh, com capacidade
de descarga máxima de 80%, ou seja, com reserva de 20% ou 200kWh, em um período
de 48 horas. Além disso, considera-se ainda um inversor de potência nominal de
250kVA. No primeiro ciclo de carga, não há carregamento, pois considera-se que o
2.2. Armazenador de Energia 35
Figura 6: Ilustração do comportamento do Armazenador de Energia no modo padrão
Curva de Carga
Tempo(horas)
0.5
1.0
0.3
6 12 18 24 30 36 42 48 54 60
Zona de carregamento
Zona de descarregamento
Carregamento por 
tempo (02:00)
Fonte: adaptado de (EPRI, 2011)
armazenador inicia-se carregado. Além disso, nota-se que a capacidade de descarga
máxima é atingida um pouco antes do fim do ciclo de descarga. O mesmo é válido
para o clico de carga do segundo dia.
Um fato importante a se notar, é que não há somente despacho de potência ativa.
Assume-se que o elemento se encontra conectado à um inversor cuja potência no-
minal é definida pelo parâmetro kVA. A potência reativa despachada pode ser no
máximo aquela cuja combinação com a potência ativa produz a potência nominal do
inversor. Essa potência reativa máxima é comumente chamada de potência reativa
disponível, e é calculada de acordo com a expressão abaixo:
𝑄𝐷𝑖𝑠𝑝(𝑡) =
√︁
𝑘𝑉 𝐴2 − 𝑘𝑊 (𝑡)2
Onde 𝑘𝑊 (𝑡) é a potência ativa gerada ou consumida em um dado instante. A
potência reativa que é realmente despachada é definida a partir do parâmetro kvar
ou da combinação de kW(t) e o fator de potência especificado em pf. Por fim, uma
curva de carga específica para a potência reativa é aplicada, definida pelo parâmetro
Qmul no objeto loadshape. Quando essa curva não é definida, por default, considera-
se a curva de carga definida para a potência ativa.
3. Modo por Preço ou por Nível de Carga (Price or Loadlevel):
Nesses dois modos, os gatilhos de carga e descarga também são utilizados, porém
eles são aplicados a variáveis globais, isto é, aplicadas a todo o sistema, o que pode
simular o efeito de uma central de controle responsável por uma grande quantidade
de armazenadores de energia, por exemplo.
No caso do modo por preço, ao invés de se utilizar um objeto loadshape, utiliza-se
uma curva definida como um objeto do tipo Priceshape, não normalizada. Esse curva
36 Capítulo 2. Modelos de Recursos Distribuídos implementados no OpenDSS
Figura 7: Ilustração do comportamento do Armazenador de Energia no modo seguidor
Fonte: extraído de (EPRI, 2011)
é um constituída por um vetor de preços, normalmente $/MWh. Nessa situação,
os gatilhos devem ser definidos como preços e a regra é que sempre que o preço da
energia definido no gatilho de carga é maior que o preço no instante considerado,
o armazenador é carregado. Em outras palavras, o gatilho de carga representa o
máximo preço da energia no qual o elemento ainda pode ser carregado (caso já não
tenha sido completamente carregado). O gatilho de descarga funciona do modo
inverso. Ele representa o mínimo preço da energia no qual o elemento pode ser
descarregado (caso já não tenha sido descarregado até o limite).
A mesma lógica se aplica no modo por nível de carga. Nesse modo, a curva de carga
global é definida como um objeto do tipo loadshape. Os comandos utilizados para
definir essas curvas se encontram no quadro abaixo:� �� �
// De f in i cao da curva de preco
Set PriceCurve = Curva_de_preco_x
Set P r i c e S i g n a l = Preco_x // U t i l i z a d o quando se d e s e j a r a t r i b u i r o
preco manualmente
// De f in i cao da curva de carga g l o b a l
Set De fau l tDa i ly = Curva_de_carga_diaria_x // deve s e r u t i l i z a d a
2.2. Armazenador de Energia 37
quando a s imulacao r e a l i z a d a f o r uma simulacao d i a r i a
Set Defau l tYear ly = Curva_de_carga_anual_x // deve s e r u t i l i z a d a quando
a s imulacao r e a l i z a d a f o r uma simulacao anual
// Opcional
Set LoadMult = mult ip l icador_de_carga // va l o r em pu u t i l i z a d o como
f a t o r m u l t i p l i c a t i v o para as curvas de carga
 	� �
4. Modo Externo (External):
Nesse modo, o armazenador não determina o seu estado por conta própria. O
responsável por isso passa a ser um controlador, chamado de StorageController.
Esse modo é ativado automaticamente quando se associa um StorageController a
um armazenador de energia. Esse elemento é explicado em detalhes no capítulo 3.
É importante salientar que o estado desse elemento pode ser alterado diretamente a
partir de um script na linguagem de programação do OpenDSS ou através da interface
COM, a partir de um programa externo.
2.2.1 Cálculo de perdas e atualização da energia armazenada
Independentemente do método decarga e descarga do armazenador de energia, o
cálculo das perdas e a atualização da energia armazenada ocorre do mesmo modo, como
segue abaixo:
2.2.1.1 Armazenador Descarregando
A figura 8 apresenta as potências internas ao elemento armazenador de energia durante
o descarregamento, em uma dado instante de tempo, após a potência de saída 𝑃𝑜𝑢𝑡 ter
sido calculada ou diretamente especificada a partir de algum dos métodos descritos acima.
A eficiência do processo de descarga é dado por 𝜂𝑑𝑖𝑠𝑐ℎ.
Figura 8: Diagrama do modelo do Armazenador de Energia no OpenDSS, quando no
estado de descarga
Pout+ Pout+Perdascte
Energia 
Armazenada
Pout
Perdascte
Perdascte
ᶯdisch ᶯdisch
Fonte: adaptado de (EPRI, 2011)
38 Capítulo 2. Modelos de Recursos Distribuídos implementados no OpenDSS
As perdas totais podem ser calculada a partir da diferença entre a potência de saída
calculada e a potência de saída do armazenador de energia ideal, representado na figura
8 por um reservatório, conforme equações 3 e 4.
𝑃𝑒𝑟𝑑𝑎𝑠𝑇𝑜𝑡𝑎𝑖𝑠[𝑡] = 𝑃𝑜𝑢𝑡[𝑡] + 𝑃𝑒𝑟𝑑𝑎𝑠𝑐𝑡𝑒[𝑡]
𝜂𝑑𝑖𝑠𝑐ℎ
− 𝑃𝑜𝑢𝑡[𝑡] (3)
𝑃𝑒𝑟𝑑𝑎𝑠𝑇𝑜𝑡𝑎𝑖𝑠[𝑡] = 𝑃𝑜𝑢𝑡[𝑡] ×
(︃
1
𝜂𝑑𝑖𝑠𝑐ℎ
− 1
)︃
+ 𝑃𝑒𝑟𝑑𝑎𝑠𝑐𝑡𝑒[𝑡]
𝜂𝑑𝑖𝑠𝑐ℎ
(4)
Assim, a energia armazenada na bateria é atualizada considerando-se que a potência
extraída do armazenador de energia ideal se mantém constante no intervalo de tempo
entre a solução do instante anterior, 𝑡 − 1 e do instante atual 𝑡, que corresponde ao passo
de tempo, Δ𝑡, utilizado na simulação, conforme equação.
𝐸𝑛𝑒𝑟𝑔𝑖𝑎𝐴𝑟𝑚𝑎𝑧𝑒𝑛𝑎𝑑𝑎[𝑡] = 𝐸𝑛𝑒𝑟𝑔𝑖𝑎𝐴𝑟𝑚𝑎𝑧𝑒𝑛𝑎𝑑𝑎[𝑡 − 1] − 𝑃𝑜𝑢𝑡[𝑡] + 𝑃𝑒𝑟𝑑𝑎𝑠𝑐𝑡𝑒[𝑡]
𝜂𝑑𝑖𝑠𝑐ℎ
× Δ𝑡 (5)
2.2.1.2 Armazenador Carregando
De modo semelhante à figura 8, a figura 9 apresenta o modelo quando o armazenador é
carregado, onde 𝜂𝑐ℎ representa a eficiência do processo de carga e 𝑃𝑖𝑛 representa a potência
injetada no elemento armazenador de energia.
Figura 9: Diagrama do modelo do Armazenador de Energia no OpenDSS, quando no
estado de carga
Pin- (Pin-
Perdascte)xᶯch
Energia 
Armazenada
ᶯch
Pin
Perdascte
Perdascte
Fonte: adaptado de (EPRI, 2011)
Nessa situação, as perdas totais pode ser calculada a partir da diferença entre a po-
tência de injetada no elemento, 𝑃𝑖𝑛 e a potência injetada no elemento armazenador de
energia ideal, conforme equações 6 e 7.
𝑃𝑒𝑟𝑑𝑎𝑠𝑇𝑜𝑡𝑎𝑖𝑠[𝑡] = 𝑃𝑖𝑛[𝑡] − (𝑃𝑖𝑛[𝑡] − 𝑃𝑒𝑟𝑑𝑎𝑠𝑐𝑡𝑒[𝑡]) × 𝜂𝑐ℎ (6)
𝑃𝑒𝑟𝑑𝑎𝑠𝑇𝑜𝑡𝑎𝑖𝑠[𝑡] = 𝑃𝑖𝑛 × (1 − 𝜂𝑐ℎ) + 𝑃𝑒𝑟𝑑𝑎𝑠𝑐𝑡𝑒[𝑡] × 𝜂𝑐ℎ (7)
2.2. Armazenador de Energia 39
E, portanto, a energia armazenada no instante 𝑡 é dada por,
𝐸𝑛𝑒𝑟𝑔𝑖𝑎𝐴𝑟𝑚𝑎𝑧𝑒𝑛𝑎𝑑𝑎[𝑡] = 𝐸𝑛𝑒𝑟𝑔𝑖𝑎𝐴𝑟𝑚𝑎𝑧𝑒𝑛𝑎𝑑𝑎[𝑡−1]+(𝑃𝑖𝑛[𝑡] − 𝑃𝑒𝑟𝑑𝑎𝑠𝑐𝑡𝑒[𝑡])×𝜂𝑐ℎ ×Δ𝑡
(8)
É importante frisar que, no estado isolado, a única perda existente é a perda por
inatividade, que é suprida pela rede na qual o elemento armazenador de energia está
conectado. Ou seja, nesse estado, o armazenador de energia funciona como uma carga,
e não há alteração na quantidade de energia armazenada no mesmo. Por fim, a perda
por inatividade, chamada de “perdas constantes” no equacionamento acima, na realidade,
não é constante. Essa perda é modelada como uma impedância constante, de tal modo
que a potência absorvida varia com a tensão no ponto de conexão do elemento.
40 Capítulo 2. Modelos de Recursos Distribuídos implementados no OpenDSS
41
Capítulo 3
Implementação de controles no
OpenDSS
Nesse capítulo será apresentada a lógica interna de execução de controles no OpenDSS
e os principais elementos de controle já implementados no software serão descritos sucin-
tamente.
3.1 Lógica interna de execução do controle
O OpenDSS possui uma lógica interna para a execução de comandos de controle
discretos como, por exemplo, abertura e fechamento de chaves e mudança de tap de
transformadores. A lógica baseia-se no preenchimento de uma Lista de Controle (do
inglês, Control Queue), em que cada elemento dessa lista representa uma ação específica
a ser executada por um elemento de controle específico. A figura 10 mostra o diagrama
de blocos do processo de simulação do OpenDSS. Cada passo do processo de simulação é
dividido em três partes:
o Execução de uma solução com controles, representada pelo bloco "Loop de Con-
trole"na figura 10.
o Amostragem de dados pelos monitores, medidores de energia e outras ações de rotina
como a atualização do estado de carga de baterias.
o O passo de tempo é incrementado e o ciclo começa novamente.
A diferença entre uma simulação no modo Snapshot e uma simulação de uma série
temporal (timeseries) é que , na primeira, não ocorre o incremento de um passo de tempo,
ou seja, somente as duas primeiras partes do processo de simulação são executadas, e
apenas uma única vez. Já na simulação de uma série temporal, esse processo se repete
até que não haja mais um passo de tempo a ser simulado. Quando isso ocorre, os dados
42 Capítulo 3. Implementação de controles no OpenDSS
Figura 10: Diagrama de Blocos do Processo de Simulação do OpenDSS
Inicia
a solução
de uma 
série 
temporal
Inicializa a solução
no modo Snapshot
Resolve o Fluxo de 
Potência sem 
Controles
Lista
de Controles
Limpa?
Amostra os dispositivos
de controle internos e
adiciona ações à lista de 
controle
Executa ações 
pendentes da 
lista de controle
Amostra monitores 
e outras ações
de rotina
Salva monitores
e conclui simulação
Último 
passo de
tempo?
Incrementa um
passo de tempo
Loop de 
Controle
Não
Sim
Sim
Não
Fonte: adaptado de (BIRCHFIELD, 2015)
dos monitores são salvos e a simulação é concluída. A lógica interna de execução do
controle é realizada na primeira parte do processo de simulação. No primeiro passo de
tempo da simulação, todos os componentes do sistema que possuem um elemento de
controle associado possuem um estado inicial que, juntamente com outros componentes
elétricos da rede como linhas, transformadores, cargas, entre outros, definem o circuito e
sua respectiva matriz de admitâncias nodais na primeira iteração de controle, isto é, dentro
do loop de controle. Nesse loop, bloco cinza da figura 10, a primeira etapa realizada é a
inicialização da solução no modo snapshot, que consiste basicamente na inicialização dos
contadores de iteração. Em seguida, o fluxo de potência é resolvido iterativamente. Em
especial, antes da solução do fluxo de potência no primeiro instante de tempo, é resolvido
um fluxo de potência em vazio, isto é, com todas as cargas desprezadas. O objetivo é
encontrar uma condição inicial mais próxima da solução final quando a carga na condição
inicial for considerada. Além disso, no fluxo de potência em vazio, o OpenDSS consegue
calcular todas as "regiões"de tensão da rede, necessário para apresentar alguns resultados
3.1. Lógica interna de execução do controle 43
em pu. Por default, o método utilizado para a solução do fluxo de potência é o método
por injeção de correntes, chamado de "Normal"no software, descrito em (RADATZ, 2015).
Um outro método possível de ser utilizado é o método de Newton, que é mais lento,
porém mais robusto. Após a solução do fluxo de potência, todos os elementos de controle
amostram as variáveis do componente elétrico que monitoram. Por exemplo, a tensão
em determinado nó para conexão de banco de capacitores visando o controle de nível
de tensão. Desse modo, cada elemento de controle verifica se a variável controlada se
encontra dentro ou fora de sua banda de referência e determina se alguma ação precisa
ser realizada. Assim, todos os elementos de controle que se encontram fora da banda
enviam uma ação para a lista de controle do OpenDSS, através da função PushAction. A
lista de controle é populada e cada ação é ordenada de acordo com o seu delay, figura 11.
Figura 11: Funcionamento da Lista de Controle
Objeto 
de 
Controle
Objeto 
de 
Controle
Despachante
de
ações
DoPendingAction
DoPendingAction
DoPendingAction
PushAction
PushAction
PushAction
Objeto 
deControle
Lista de Controle
Ação 2
Ação 3{ {HandleHour, SecCódigo da AçãoPuxador do ProxyEndereço do Controle
Ação 1
Ação n
Fonte: adaptado de (EPRI, 2015)
Depois que a lista de controle é populada e ordenada, a solução passa por um bloco
condicional, que checa se a lista de controle se encontra vazia. Se esse é o caso, o processo
sai do loop de controle. Caso contrário, o processo continua no loop de controle e o
despacho das ações pendentes ocorre dependendo do modo de controle selecionado.
3.1.1 Modos de controle
No OpenDSS há 3 modos de controle que ditam o despacho das ações da lista de
controle. Cada um dos modos é descrito abaixo:
44 Capítulo 3. Implementação de controles no OpenDSS
1. Modo de controle estático ("Static"): Nesse modo de controle não há avanço no
tempo de simulação, isto é, o loop de controle primeiramente encontra um estado
final para os componentes controlados e somente após a estabilização desses elemen-
tos, ou seja, após a lista de controle estar completamente limpa é que ocorre um
incremento de um passo de tempo no tempo de simulação. As ações de controle são
executadas a partir do elemento de controle com menor atraso. Em outras palavras,
o atraso dos elementos de controle é utilizado para definir a ordem em que os ele-
mentos de controle atuam, sendo que um elemento atua por vez, a não ser que mais
de um elemento possua o mesmo atraso. Esse modo de controle é o padrão para a
solução no modo "snapshot"e no modo diário e anual, quando o passo de tempo é
maior que o atraso dos elementos de controle.
2. Modo de controle temporal ("Time"): Nesse modo, a sequência das ações dos ele-
mentos de controle é guiada pelo tempo. As ações de controle são executadas quando
o atraso da ação pendente é alcançado ou ultrapassado pelo tempo de simulação.
Sempre que uma ação é despachada da lista de controle ocorre uma nova iteração
do loop de controle. Esse modo de controle deve ser utilizado quando o passo de
simulação é da mesma ordem de grandeza do delay dos elementos de controle. Por
esse motivo, mesmo que a lista de controle não se encontre limpa, ocorrem incre-
mentos no passo de simulação. Isso acontece quando um elemento de controle está
armado, porém ainda aguarda o tempo de simulação "alcançar"o seu delay para que
a ação seja executada.
3. Modo de controle baseado em eventos ("Event"): Nesse modo, a sequência das ações
dos elementos é guiada por eventos, ou seja, é semelhante ao modo temporal, porém
o passo de tempo não é fixo. Alguns passos de simulação são executados apenas
próximo de alguma ação da lista de controle. O tempo avança automaticamente
para o instante do próximo evento da lista de controle. Esse modo de controle não
é muito utilizado. Por esse motivo, não será abordado no presente trabalho.
Quando o delay da primeira ação pendente da lista de controle é atingido, essa ação
é despachada de volta ao elemento de controle, através da função DoPendingAction, que
decide se ela deve ser realizada ou não. Quando a ação é executada, a rede simulada
é efetivamente alterada. Por esse motivo, a matriz de admitâncias nodais da rede é
recalculada e um novo fluxo de potência para a "nova"rede é executado, ainda dentro
do mesmo passo de tempo. Esse ponto é importante, pois em uma rede com diversos
elementos de controle, esses elementos começam a interagir entre si, de tal modo que,
a atuação de um deles pode colocar a variável controlada por outro dentro da banda
desejada, não havendo mais necessidade da execução de uma nova ação. Essa verificação
pode ser resumida em um bloco "E"("AND"), figura 12.
3.1. Lógica interna de execução do controle 45
Figura 12: Verificação no elemento de controle antes da execução da ação
Delay atingido
Executa ação
Variável de controle 
fora da banda
Fonte: autor
Como pode ser observado na figura 11, quando um elemento de controle envia uma
ação à lista de controle, essa ação é representada por cinco parâmetros. Eles são:
o Hour e Sec: Hour e sec são parâmetros distintos e representam o instante de tempo
em que a ação enviada à lista de controle deve ser despachada de volta ao elemento de
controle. Esse tempo corresponde ao instante em que a amostragem dos elementos
de controle detectou que uma ação deveria ser tomada mais o delay da respectiva
ação.
o ActionCode: É um número inteiro que corresponde à uma ação específica a ser
executada pelo elemento de controle. Esse parâmetro é extremamente importante.
Em um elemento CapControl, por exemplo, é através desse parâmetro que o controle
identifica se a ação a ser realizada é de adicionar ou retirar um capacitor do banco.
o ProxyDevRef: Esse parâmetro é importante quando deseja-se inserir novos elemen-
tos de controle programados via interface COM. Esse parâmetro é descrito no
Capítulo 4, onde é estudado em detalhes como controlar o OpenDSS pela interface
COM e inserir dentro do processo de simulação do software um elemento de controle
criado pelo usuário.
o Device: Esse parâmetro é responsável por identificar à qual elemento de controle
pertence uma determinada ação. Assim, a lista de controle consegue saber para
qual elemento ela deve despachar a ação quando chegar o instante adequado.
Quando uma ação é inserida na lista de controle, um outro parâmetro é adicionado
a ela, que se chama Handle. Esse parâmetro é um número inteiro que corresponde à
ordem em que a ação entrou na lista de controle a partir do início da simulação, ou
seja, a primeira ação a entrar na lista recebe um parâmetro Handle igual a 1, a segunda
recebe um Handle igual a 2, e assim sucessivamente. Esse parâmetro também é a saída
da função PushAction, executada internamente nos elementos de controle. Como o nome
sugere, o objetivo desse parâmetro é criar uma associação entre o elemento de controle e
a ação que ele acabou de enviar à lista de controle, de tal modo que ele possa acessar essa
46 Capítulo 3. Implementação de controles no OpenDSS
ação mesmo antes dela ser despachada. Isso ocorre em alguns elementos de controle. Por
exemplo, no elemento CapControl, sempre que o elemento se arma e envia uma ação de
controle à lista de controle, a cada iteração de controle ele checa se a variável controlada
ainda se encontra fora da banda de referência. Caso a variável controlada tenha entrado
na banda novamente, o CapControl consegue deletar a ação da lista de controle antes que
o seu delay seja alcançado, resetando o seu estado de armado para desarmado. Isso já não
ocorre no elemento RegControl, por exemplo. Esse elemento faz essa verificação somente
na iteração em que a lista de controle despacha a ação de volta, isto é, após o delay, como
foi apresentado na figura 12
Nos Apêndice A, são apresentados dois exemplos utilizando a rede de testes IEEE 13
Barras. O objetivo é demonstrar o funcionamento do processo de simulação do OpenDSS
com elementos de controle no modo estático e temporal, verificando algumas variáveis
internas ao processo de simulação a partir da interface COM.
3.2 Controles Implementados no OpenDSS
Uma importante característica do software é o fato dos elementos de controle serem
modelados separadamente dos elementos de potência, Figura 13. Isso garante flexibilidade
na criação de novos modelos. De acordo com (DUGAN; MCDERMOTT, 2011), inicialmente,
os elementos de controle foram projetados para operar somente de modo similar aos
dispositivos de controle utilizados em sistemas de distribuição, porém o software tem
sido constantemente aprimorado e, mais recentemente, novos modelos passíveis de serem
implementados no cenários das Redes Elétricas Inteligentes têm sido acrescentados ao
software. Atualmente, há 9 elementos de controle implementados no OpenDSS, sendo os
principais descritos a seguir:
Figura 13: Arquitetura do OpenDSS
Fonte: extraído de (DUGAN; MCDERMOTT, 2011)
3.2. Controles Implementados no OpenDSS 47
Tabela 1: Parâmetros do elemento de controle RegControl
Parâmetro Descrição
band Largura de banda em volts para a barra controlada. Default = 3.
basefreq Frequência base paraclassificações.
bus Nome da barra controlada (nomedabarra.nomedonó) do sistema para ser utilizada ao invés
da barra na qual está conectado o enrolamento do transformador ou a queda de tensão na
resistência e na reatância, R e X, do compensador.
CTprim Corrente nominal, em amperes, da primário do TC para conversão de corrente de linha
para corrente de controle. O valor típico da corrente nominal do secundário é 0,2A.
debugtrace Armazena o progresso do regulador para cada iteração de controle. Cria um arquivo .CSV
separado para cada regulador. Default = No.
delay Atraso temporal, em segundos, de quando a tensão está fora da banda para quando a
mudança de tap começa. Esse parâmetro é utilizado para definir qual regulador vai agir
primeiro. Default = 15.
enabled Indica se o elemento deve ser ativado ou não.
EventLog Registra as ações de controle. Default = Yes.
inversetime O delay é ajustado de modo inversamente proporcional ao valor da tensão fora da banda
até 10% do valor especificado no parâmetro delay.
maxtapchange Máxima mudança de tap permitida por iteração de controle no modo estático. Default =
16.
PTphase Para transformadores polifásicos, o número de fases a serem monitoradas ou uma opção
entre {Máximo|Mínimo} dentre todas as fases. Parâmetro ignorado quando uma barra é
controlada. Default = 1.
ptratio Relação de transformação do TP que converte a tensão no enrolamento controlado para o
nível de tensão de controle do regulador. Se a conexão é estrela, a tensão de fase é utilizada.
Senão, a tensão de linha é utilizada. Default = 60.
R Resistência de linha para compensação por queda de tensão de linha, expresso em volts.
RemotePTRatio Quando a regulação de barra é utilizada, representa a razão do TP necessário para con-
verter a tensão atual na barra remota para tensão de controle. É inicializada a partir da
propriedade ptratio.
revband Largura de banda para operação no modo reverso.
revDelay Atraso em segundo para execução da ação no modo reverso uma vez que o limiar para
operação no modo reverso é excedido. Default = 60.
reversible Indica se o regulador pode ser alternado para fazer regulação na direção reversa. Tipica-
mente se aplica para reguladores de linha. Default = No.
revNeutral O regulador vai para o neutro na direção reversa. Default = No.
revR Resistência de linha para compensação por queda de tensão de linha no modo reverso,
expressa em volts.
revThreshold Potência reversa em kW para reversão da direção do regulador. Default = 100.
revvreg Referência de tensão em volts para regulação no modo reverso.
revX Reatância de linha para compensação por queda de tensão de linha no modo reverso,
expressa em volts.
tapdelay Atraso em segundos entre mudanças de tap, após a primeira mudança. Default= 2.
TapNum Número inteiro indicando a posição do tap na qual o transformador controlado está atual-
mente ou está sendo configurado para.
tapwinding Enrolamento que contém o tap atual, se diferente do parâmetro winding. Por default, é o
mesmo enrolamento especificado na propriedade winding.
transformer Nome do transformador ao qual o regulador é conectado.
vlimit Limite de tensão para a barra na qual o enrolamento regulado está conectado. Declarar
com um valor acima de 0 para ativar essa função. Default = 0.
vreg Referência de tensão em volts para o enrolamento sendo monitorado. Default = 120.
winding Número do enrolamento do transformador que o regulador controla.
X Reatância de linha para compensação por queda de tensão de linha, expressa em volts.
3.2.1 Regulador de Tensão
O regulador de tensão é um dos principais elementos de controle implementados no
OpenDSS. A tabela 1 apresenta a lista dos principais parâmetros que descrevem esse
elemento e a respectiva descrição.
A quantidade de taps do enrolamento do transformador controlado é um parâmetro
do transformador em si. Os parâmetros do transformador relevantes para o regulador são:
48 Capítulo 3. Implementação de controles no OpenDSS
o MaxTap: Máximo tap em pu do enrolamento controlado. Por default, é igual 1.1.
o MinTap: Mínimo tap em pu do enrolamento controlado. Por default, é igual a 0.9.
o NumTaps: Número total de taps entre a quantidade mínima e máxima de taps do
enrolamento controlado. Por default, é igual a 32, isto é, 16 taps acima e 16 taps
abaixo da posição neutra. A posição neutra não é considerada em NumTaps.
Figura 14: Taps do enrolamento controlado na configuração default.
Max Tap = +16
Tap = +15
Tap = +14
Min Tap = -16
Tap = -15
Tap = -14
Tap = -3
Tap = -2
Tap = -1
Tap = +1
Tap = +2
Tap = +3
Tap = 0
1.1pu
1.09375pu
1.0pu
1.00625pu
1.0125pu
1.01875pu
1.0875pu
0.99375pu
0.9875pu
0.98125pu
0.9pu
0.9625pu
0.96875pu
0.00625pu
Fonte: autor
A figura 14 mostra a definição dos taps do regulador de tensão na configuração default.
Esse elemento pode regular o nível de tensão da rede em 4 diferentes modos:
1. Controle do nível de tensão do enrolamento de um transformador: A fi-
gura 15 apresenta o circuito de controle do regulador de tensão controlando o nível
de tensão no enrolamento secundário de um transformador, modelando efetivamente
um LTC ou um regulador de linha, quando o transformador monitorado é um auto-
transformador. A figura também inclui alguns dos parâmetros definidos no modelo
do elemento RegControl, descritos na tabela 1. Vale notar que o enrolamento mo-
nitorado não necessariamente precisa ser aquele onde se encontram os taps.
2. Controle do nível de tensão de uma barra qualquer: Funciona de modo
semelhante ao controle do nível de tensão do enrolamento de um transformador,
com a diferença de que o Transformador de Potencial (TP) é conectado a uma
3.2. Controles Implementados no OpenDSS 49
Figura 15: Representação esquemática do Regulador de Tensão e parâmetros do
OpenDSS associados.
ptratio
Sinal de controle
transformer
winding
vlimit
vreg
band
tapdelay
delay
tensão 
controlada
Fonte: autor
barra qualquer da rede. Esse modo pode emular dispositivos em uma Smart Grid,
por exemplo.
3. Controle do nível de tensão com Compensação por Queda de Tensão de
Linha:
No modo Compensação por Queda de Tensão de Linha, do inglês, Line Drop Com-
pensation (LDC), deseja-se monitorar a tensão em um centro de carga ou em uma
carga, por exemplo. Nesse caso, os parâmetros R e X da linha devem ser forne-
cidos, em volts, bem como a corrente nominal do primário do Transformador de
Corrente (TC) utilizado para calcular a queda de tensão na linha. O objetivo é
garantir que o tap do regulador se altere dependendo da queda de tensão na linha.
Isso é feito a partir de um circuito analógico, apresentado na figura 16, cuja queda
de tensão Δ𝑉𝑐𝑜𝑚𝑝 deve emular a queda de tensão na impedância de linha, Δ𝑉𝑙𝑖𝑛ℎ𝑎,
refletida para o circuito do regulador, ou seja, reduzida de ptratio. A queda de
tensão na linha é apresentada na equação 9, enquanto que a queda de tensão no
circuito analógico do compensador é dada pela equação 10.
Δ�̇�𝑙𝑖𝑛ℎ𝑎 = (𝑅𝑙𝑖𝑛ℎ𝑎 + 𝑗𝑋𝑙𝑖𝑛ℎ𝑎) × 𝐼𝑙𝑖𝑛ℎ𝑎 (9)
Δ�̇�𝑐𝑜𝑚𝑝 = (𝑅 + 𝑗𝑋) × 𝐼𝑐𝑜𝑚𝑝 (10)
Para Δ𝑉𝑐𝑜𝑚𝑝 emular a queda de tensão na linha no secundário do TP, Δ𝑉𝑐𝑜𝑚𝑝 ×
ptratio deve ser igual a Δ𝑉𝑙𝑖𝑛ℎ𝑎. Assim, tem-se que
50 Capítulo 3. Implementação de controles no OpenDSS
Figura 16: Regulador de Tensão com Compensação por Queda de Tensão de Linha
ptratio
transformer
winding
CTprim:CTsec Rlinha Xlinha
R X
1
:1
Ilinha
ΔVcomp
ΔVlinha
vmedida
tensão 
controlada
Carga
Icomp
Relé de 
Tensão
Fonte: autor
(𝑅 + 𝑗𝑋) = (𝑅𝑙𝑖𝑛ℎ𝑎 + 𝑗𝑋𝑙𝑖𝑛ℎ𝑎) ×
𝐼𝑙𝑖𝑛ℎ𝑎
𝐼𝑐𝑜𝑚𝑝
× 1
𝑝𝑡𝑟𝑎𝑡𝑖𝑜
[Ω] (11)
Porém, pode-se substituir a razão das correntes pela relação de transformação do
TC. Além disso, é prática comum em reguladores com LDC, inserir os dados das
impedâncias R e X em volts, bastando, para isso, multiplicá-las pela corrente nomi-
nal do secundário do TC, 𝐶𝑇𝑠𝑒𝑐. Por esse motivo, os valores de R e X no OpenDSS
foram implementados de tal modo que basta o usuário acessar o painel do reguladorreal, e copiar os valores de R e X apresentados, em volts. Portanto, tem-se que:
(𝑅 + 𝑗𝑋) = (𝑅𝑙𝑖𝑛ℎ𝑎 + 𝑗𝑋𝑙𝑖𝑛ℎ𝑎) ×
𝐶𝑇𝑝𝑟𝑖𝑚
𝐶𝑇𝑠𝑒𝑐
× 𝐶𝑇𝑠𝑒𝑐 ×
1
𝑝𝑡𝑟𝑎𝑡𝑖𝑜
[𝑉 ] (12)
(𝑅 + 𝑗𝑋) = (𝑅𝑙𝑖𝑛ℎ𝑎 + 𝑗𝑋𝑙𝑖𝑛ℎ𝑎) ×
𝐶𝑇𝑝𝑟𝑖𝑚
𝑝𝑡𝑟𝑎𝑡𝑖𝑜
[𝑉 ] (13)
A equação 13 apresenta a conversão da impedância de linha para o valor de R e
X do regulador, em volts. De fato, o valor de R + jX representa o valor da queda
de tensão na linha refletida ao secundário do TP quando a corrente de linha é
igual a 𝐶𝑇𝑝𝑟𝑖𝑚 que, por sua vez, é próximo da corrente nominal de linha. Nessa
configuração, como o objetivo é controlar a tensão na carga, a variável controlada
passa a ser a tensão sobre o relé de tensão, figura 16, que representa justamente a
tensão no centro de carga. Desse modo, o tap do regulador varia de modo que a
tensão sobre o relé de tensão mantenha-se próxima do parâmetro vreg, dentro de
3.2. Controles Implementados no OpenDSS 51
uma certa banda. Porém, quando esse tipo de regulador é utilizado, a tensão no
enrolamento controlado fica muito dependente do nível de carga da linha, o que pode
levar a níveis de tensão elevados quando o carregamento da linha é elevado. Por esse
motivo, utiliza-se a variável vlimit para limitar o nível de tensão no enrolamento do
transformador.
52 Capítulo 3. Implementação de controles no OpenDSS
4. Regulador operando no modo reverso:
Também é possível operar o regulador de tensão no modo reverso. Esse modo é
tipicamente aplicado em reguladores de linha. É habilitado através do parâmetro
reversible. Ele é ativado quando o fluxo de potência encontra-se invertido e é maior
que um limiar, definido pelo parâmetro revThreshold. Nesse modo, é possível definir
parâmetros similares aos definidos nos modos anteriores, porém com a apresenta o
prefixo rev. Por exemplo, revband, revreg, revR e revX. Há dois parâmetros impor-
tantes para se especificar nesse modo. Um deles é o revDelay, que corresponde ao
tempo necessário para que a ação de início de controle no modo reverso se inicie,
uma vez que o fluxo de potência no sentido reverso acima do limiar for detectado. O
outro parâmetro corresponde ao revNeutral. Quando definido como "Yes", sempre
que o regulador entra no modo reverso, a posição do tap fica fixa na posição neutra.
O cálculo da mudança de taps necessária é feita sempre que a tensão controlada
encontra-se fora da banda especificada, figura 17.
Figura 17: Definição da banda na qual o regulador não atua, com os valores default.
vreg
{
band
vreg + band/2
vreg + band/2
Tensão no 
secundário do TP
120
121.5
118.5
Fonte: autor
Primeiramente, o "erro", que corresponde ao aumento do nível de tensão desejado, por
isso chamado de 𝑣𝑏𝑜𝑜𝑠𝑡 no código fonte do software, é calculado pela equação 14.
𝑣𝑏𝑜𝑜𝑠𝑡 = 𝑣𝑟𝑒𝑔 − 𝑣𝑎𝑐𝑡𝑢𝑎𝑙 [𝑉 ] (14)
Onde 𝑣𝑟𝑒𝑔 é a tensão desejada, e 𝑣𝑎𝑐𝑡𝑢𝑎𝑙 é a tensão medida. Depois que o aumento de
tensão desejado no secundário do TP é calculado, ele é convertido para pu e chamado de
BoostNeeded de acordo com a equação 15.
𝐵𝑜𝑜𝑠𝑡𝑁𝑒𝑒𝑑𝑒𝑑 = 𝑣𝑏𝑜𝑜𝑠𝑡 ×
𝑝𝑡𝑟𝑎𝑡𝑖𝑜
𝐵𝑎𝑠𝑒𝑉 𝑜𝑙𝑡𝑎𝑔𝑒
(15)
O aumento desejado em pu é, então, convertido para o múltiplo inteiro mais próximo
do incremento de tensão em pu por tap. Esse valor é chamado de PendingTapChange,
3.2. Controles Implementados no OpenDSS 53
calculado pela equação 16, mediante o uso do método Round(), da linguagem de progra-
mação Delphi.
𝑃𝑒𝑛𝑑𝑖𝑛𝑔𝑇𝑎𝑝𝐶ℎ𝑎𝑛𝑔𝑒 = 𝑅𝑜𝑢𝑛𝑑(𝐵𝑜𝑜𝑠𝑡𝑁𝑒𝑒𝑑𝑒𝑑
𝐼𝑛𝑐𝑟𝑒𝑚𝑒𝑛𝑡
) × 𝐼𝑛𝑐𝑟𝑒𝑚𝑒𝑛𝑡 (16)
Onde Increment é o incremento em pu, apresentado na figura 14. Após o cálculo
da mudança de tap pendente, verifica-se se o regulador se encontra armado e se o tap
atual está dentro do valores de tap máximo e mínimo do enrolamento do transformador,
especificados respectivamente por, MaxTap e MinTap. Se o regulador já se encontra
armado, nenhuma ação de controle nova é adicionada à lista de controle. Porém, se ele
não se encontra armado e a mudança de tap é possível, isto é, o tap atual é menor que o
tap máximo e maior que o tap mínimo, a ação é enviada para a lista de controle, com o
devido delay.
Quando o regulador de tensão recebe uma ação da lista de controle, a mudança de tap
real dependendo do modo de controle utilizado.
3.2.1.1 No modo de controle estático
Nesse modo de controle, é permitido que o tap do regulador altere mais de uma posição
por iteração do controle. Primeiro, o número de taps que devem ser alterados é limitado
a 70% do número pendente, de acordo com a equação 17. A função Trunc() é utilizada
para garantir que a mudança de taps real seja um número inteiro.
𝑁𝑢𝑚𝑇𝑎𝑝𝑠 = 𝑇𝑟𝑢𝑛𝑐(0.7 × 𝐴𝑏𝑠(𝑃𝑒𝑛𝑑𝑖𝑛𝑔𝑇𝑎𝑝𝐶ℎ𝑎𝑛𝑔𝑒)
𝐼𝑛𝑐𝑟𝑒𝑚𝑒𝑛𝑡
) (17)
Por fim, verifica-se se a mudança de taps NumTaps está dentro do limite imposto pela
variável TapLimitPerChange que, como o nome sugere, limita a mudança de taps por
ação.
3.2.1.2 No modo de controle time
No modo de controle time, a alteração dos taps é mais realista, e só uma mudança de
tap é permitida por ação.
3.2.2 Controle de Capacitores
O elemento CapControl é responsável pelo controle de capacitores. A tabela 2 apre-
senta os parâmetros desse elemento e sua respectiva descrição.
No OpenDSS, um capacitor ou um banco de capacitores possui 5 modos de controle
distintos:
1. Controle por corrente, current:
54 Capítulo 3. Implementação de controles no OpenDSS
Tabela 2: Parâmetros do elemento de controle CapControl
Parâmetro Descrição
basefreq Frequência base na qual os demais parâmetros são definidos.
capacitor Nome do capacitor a ser controlado.
CTPhase Número da fase sendo monitorada para controle por corrente ou uma das opções
{AVG(média)|MAX(máxima)|MIN(mínima)} para todas as fases. Default =1 (fase A).
Para capacitor conectado entre fases, entrar com a primeira fase ou as duas fases sendo
monitoradas (1-2,2-3,3-1). Essa propriedade não se aplica para controle por potência rea-
tiva (kvar),pois a potência total é utilizada nesse modo de controle.
CTratio Relação de transformação do TC para conversão de corrente de linha para corrente de
controle para uso nos modos de controle de corrente e de potência reativa.
DeadTime Tempo morto após o capacitor ter sido desconectado da rede, antes que ele possa ser
conectado novamente. Caso o controle detecte que o capacitor precisa ser reconectado após
um intervalo de tempo menor que o DeadTime, o capacitor é armado, porém o seu delay
será igual à soma entre o tempo restante para que o DeadTime tenha transcorrido, a partir
da abertura, e o valor definido no parâmetro Delay. Default = 300 segundos.
Delay Delay, em segundos, a partir do momento em que o capacitor é armado até haja o envio
do comando para conexão. O controle pode ser reinicializado antes que a ação ocorra.
Esse parâmetro é utilizado para determinar qual controle vai agir primeiro. Default = 15
segundos.
DelayOFF Delay em segundos, para o controle desligar, quando o estado presente é ligado. Default =
15 segundos.
element Nome completo do elemento ao qual o TP e o TC do elemento de controle estão conectados.
enabled Indica se o elemento está ativado ou não.
EventLog Registra as ações de controle. Default = Yes.
OFFsetting Valor no qual o controle arma para desconectar o capacitor. Depende do tipo de controle.
ONsetting Valor no qual o controle se arma para conectar o capacitor ou engrenar o passo. Depende
do tipo de controle.
pctMinkvar Para opção de controle por fator de potência. Porcentagem mínima da potência reativa
total do banco (kvar) na qual o controle pode conectar o capacitor. Default = 50.
PTphase Número da fase sendo monitorada para controle por tensão ou uma das opções
{AVG(média)|MAX(máxima)|MIN(mínima)} para todas as fases. Default = 1 (fase A).
Para capacitor conectado entre fases, entrar com a primeira fase ou as duas fases sendo
monitoradas (1-2,2-3,3-1). Essa propriedade não se aplica para controle por potência rea-
tiva (kvar), pois a potênciatotal é utilizada nesse modo de controle.
PTratio Relação de transformação do TP que converte a tensão monitorada para uma tensão de
controle. Se a conexão é estrela, a tensão da fase A é monitorada. Senão, a tensão de linha
Vab é monitorada. Default = 60.
terminal Número do terminal do componente da rede ao qual o elemento CapControl está conectado.
Default = 1.
type Tipo de controle. Um entre Current, voltage, kvar, pf ou time.
UserData String que passa ao modelo do elemento CapControl escrito pelo usuário os dados requisi-
tados para definição do modelo.
UserModel Nome da DLL contendo o modelo do elemento CapControl escrito pelo usuário. Sobrescreve
o modelo default.
VBus Nome da barra a ser utilizada para a função voltage override. Default = Barra do terminal
monitorado. As vezes é útil monitorar uma barra em uma outra localidade para emular
algoritmos de controle de um Sistema de Gerenciamento de Distribuição (do inglês, DMS,
Distribution Management System.
Vmax Máxima tensão, em volts. Se a tensão sobre o capacitor refletida ao secundário do TP é
maior que essa tensão, o capacitor é desconectado independentemente das demais configu-
rações de controle. Default = 126 (usado para um PT com relação de transformação de
60, em um sistema de 12.47kV).
Vmin Mínima tensão, em volts. Se a tensão sobre o capacitor refletida ao secundário do TP é me-
nor que essa tensão, o capacitor é conectado independentemente das demais configurações
de controle. Default = 115.
VoltOverride Yes ou No. Ativa a função voltage override.
No modo de controle por corrente, a corrente no terminal escolhido do elemento
controlado é monitorada e, quando possui um valor maior que o definido pelo parâ-
metro ONsetting, o capacitor é armado e envia uma ação de fechamento para a lista
de controle. Quando a corrente monitorada é menor que o valor de definido pelo
parâmetro OFFsetting, o capacitor é armado e envia uma ação de abertura para a
3.2. Controles Implementados no OpenDSS 55
lista de controle. A corrente monitorada pode ser ajustada a partir do parâmetro
CTPhase. Por default, ela é a corrente na fase A do elemento controlado. Porém,
pode ser ajustada como sendo a média da corrente de todas as fases, a máxima ou
a mínima.
2. Controle por tensão, voltage:
O controle por tensão ocorre de modo similar ao controle por corrente, com a di-
ferença de que a variável controlada é a tensão no terminal escolhido do elemento
controlado. Se a tensão controlada é menor que o valor definido em ONsetting, o
capacitor é armado para fechar. Caso a tensão controlada seja maior que o valor
definido em OFFsetting, o capacitor é armado para abrir.
3. Controle por potência reativa, kvar:
Quando a potência reativa total é maior que o valor definido em ONsetting, o capa-
citor é armado para fechar. Quando é menor que o valor definido em OFFsetting,
o capacitor é armado para abrir. Esse elemento é direcional, onde a referência é a
potência que "entra"no terminal definido.
4. Controle por fator de potência, pf :
Quando o fator de potência definido pela potência total do terminal monitorado é
menor que o valor definido em ONsetting e o valor da potência reativa no terminal do
elemento controlado é no mínimo a porcentagem da potência reativa total do banco
de capacitores definida pelo parâmetro pctMinkvar, o controle arma o capacitor para
fechamento. Essa verificação é necessária para garantir que o fator de potência não
fique muito capacitivo. Quando o fator de potência é maior que o valor definido
pela variável OFFsetting, o capacitor é armado para abertura.
5. Controle por tempo, time:
Nesse modo, os parâmetros ONsetting e OFFsetting representam horas do dia a
partir da meia noite. Esses dois parâmetros aceitam apenas uma hora. Ou seja,
caso haja necessidade de várias ações de abertura e fechamento em um mesmo dia,
esses dois parâmetros precisam ser alterados ao longo da simulação.
Vale salientar que o elemento capacitor é definido como um banco de filtros LC série
com vários passos, conforme figura 18. Por default, a reatância X é nula e só há um
ramo paralelo. Quando o capacitor é definido com mais de um ramo, as ações de controle
que representam o fechamento e a abertura do banco de capacitores ocorrem ramo por
ramo. Por exemplo, se em um banco de capacitores com 5 ramos, para um dado modo de
controle, uma ação de fechamento de capacitor foi enviada para a lista de controle. No
momento do fechamento, mais um ramo irá fechar, e somente um. O mesmo ocorre para
uma ação de abertura.
56 Capítulo 3. Implementação de controles no OpenDSS
Figura 18: Banco de capacitores genérico no OpenDSS
X
C
step1 step2 stepN
Fonte: autor
Diferentemente do elemento de controle RegControl, o CapControl age do mesmo modo
qualquer que seja o modo de controle definido no OpenDSS, isto é, ele sempre atua
alterando o estado de um passo por vez. Além dos modos de controle já descritos, o
elemento CapControl ainda possui uma função chamada de "sobreposição de tensão"(do
inglês, voltage override). Ela basicamente monitora o nível de tensão em uma dada barra,
que deve ser especificada no parâmetro VBus. Quando essa tensão é maior que Vmax ou
menor que Vmin, ela altera um passo do banco de capacitores no sentido de manter o
nível de tensão dentro do intervalo determinado por esses dois parâmetros. Quando essa
função é ativada, ela funciona como uma função mestre, possuindo prioridade em relação
aos controles por corrente, fator de potência, potência reativa e por tempo.
3.2.3 Religadores
O religador é um elemento de controle que deve ser associado a algum outro compo-
nente elétrico da rede a ser monitorado, tipicamente uma linha ou um transformador, no
qual o TP e o TC do religador são conectados. A tabela 3 apresenta os parâmetros desse
elemento e sua respectiva descrição.
É importante notar que o OpenDSS permite que o elemento controlado seja diferente
do elemento monitorado. A figura 19 apresenta a evolução do estado de um religador
para uma condição de falta permanente. As variáveis são descritas abaixo:
o 𝑡𝑐𝑢𝑟𝑡𝑜: instante em que ocorre o curto e a sobrecorrente é detectada pela função de
sobrecorrente de terra ou de fase;
o 𝑡1: tempo de atuação do religador no primeiro trip. Caso algum valor de sobre-
corrente instantânea seja declarado e a corrente medida seja maior que esse valor,
o tempo de atuação 𝑡1 é igual a 10ms. Caso a corrente medida seja menor que a
corrente mínima para proteção instantânea, o valor de 𝑡1 passa a ser definido pela
curva tempo x corrente rápida. Essa curva só é utilizada em apenas um trip de
abertura na condição default, pois NumFast é igual a 1;
3.2. Controles Implementados no OpenDSS 57
Tabela 3: Parâmetros do elemento de controle Recloser
Parâmetro Descrição
Action Open ou Close. Ação com prioridade em relação ao controle do religador. Simula o controle
manual do equipamento. Open faz com que o elemento controlado abra e permaneça
bloqueado, enquanto que Close fecha e reseta o religador para a sua primeira operação.
basefreq Frequência de base para classificações.
Delay Tempo de atraso fixo adicionado ao tempo de trip do religador. Default = 0. Esse atraso
pode ser utilizado para representar o tempo da abertura do disjuntor.
enabled Yes ou No. Indica se o elemento está habilitado.
GroundDelayed Nome da curva tempo x corrente, Time-Current Curve (TCC), que determina a proteção de
terra com atraso. Deve ser definida previamente como "TCC_Curve object". Multiplicando
os valores da curva pelo parâmetro groundtrip obtém-se o valor atual da corrente.
GroundFast Nome da curva TCC que determina a curva rápida de proteção de terra. Deve ser definida
previamente como "TCC_Curve object". Multiplicando os valores da curva pelo valor do
parâmetro groundtrip fornece o valor atual da corrente.
GroundInst Corrente, em amperes, para trip instantâneo. Assume-se ocorrer em 10ms mais o tempo
definido no parâmetro Delay. Default = 0, que significa que não há trip instantâneo.
GroundTrip Multiplicador oucorrente de proteção de terra nominal para a curva TCC. Default = 1.
MonitoredObj Nome do elemento do circuito ao qual o TP e o TC do religador são conectados. Corres-
ponde ao elemento monitorado.
MonitoredTerm Número do terminal do elemento monitorado. Default = 1.
NumFast Número de operações rápidas. Deve ser definido em acordo com o parâmetro Shots. Default
= 1.
PhaseDelayed Nome da curva TCC que determina a curva de proteção de fase com atraso. Deve ser
definida previamente como "TCC_Curve object". Curva default = "D". Multiplicando os
valores da curva pelo valor do parâmetro phasetrip obtém-se o valor atual da corrente.
PhaseFast Nome do curva TCC que determina a curva rápida de proteção de fase. Deve ser definida
previamente como "TCC_Curve object". Curva default = "A". Multiplicando os valores
das corrente na curva pelo valor do parâmetro phasetrip obtém-se o valor atual da corrente.
PhaseInst Corrente em amperes para trip instantâneo de fase. Assume-se ocorrer em 10ms mais o
tempo definido no parâmetro Delay. Default = 0, que significa que não há tripinstantâneo.
PhaseTrip Multiplicador ou valor atual da corrente de fase em amperes para a curva TCC. Default =
1.
RecloseIntervals Vetor de intervalos de religamento. Default = (0.5, 2.0, 2.0).
Reset Tempo para resetar o religador. Default = 15 segundos.
Shots Número total de operações de abertura rápidas e com atraso para que o religador seja
bloqueado. Esse valor é um a mais que a quantidade de religamentos. Default = 4. OBS:
Um religador travado precisa ser fechado manualmente, com o parâmetro action.
SwitchedObj Nome do elemento de circuito que o religador controla. Por default, é o elemento monito-
rado, definido em MonitoredObj. Corresponde ao elemento controlado.
SwitchedTerm Número do terminal do elemento controlado. Default = 1.
TDGrDelayed Dial de tempo para a curva tempo x corrente de proteção de terra com atraso. Multiplicador
no eixo do tempo da curva especificada. Default = 1.
TDGrFast Dial de tempo para a curva tempo x corrente rápida de proteção de terra. Multiplicador
no eixo do tempo da curva especificada. Default = 1.
TDPhDelayed Dial de tempo para a curva tempo x corrente de proteção de fase com atraso. Multiplicador
no eixo do tempo da curva especificada. Default = 1.
TDPhFast Dial de tempo para a curva tempo x corrente rápida de proteção de fase. Multiplicador no
eixo do tempo da curva especificada. Default = 1.
o D: corresponde ao parâmetro Delay;
o Reclose[i]: Corresponde ao valor do intervalo de religamento definido pelo vetor
RecloseIntervals. Por default, o primeiro intervalo de religamento é menor que os
outros dois;
o 𝑡2: tempo de atuação do religador de acordo com a curva tempo x corrente com
atraso;
A figura se encontra fora de escala para melhor visualização dos parâmetros envolvidos.
Além disso, ao todo, há somente 4 operações de abertura devido ao parâmetro Shot.
58 Capítulo 3. Implementação de controles no OpenDSS
Figura 19: Evolução do estado de um religador para uma falta permanente de acordo
com as configurações default.
Estado do Religador
Aberto
Fechado
tcurto
t1 D Reclose
 Interval[1] 
D t2 D DReclose
 Interval[2] 
t2 D t2 DDReclose
 Interval[3] 
Fonte: autor
3.2.4 Relé
O relé é um elemento que se conecta ao terminal de um componente do circuito de
potência e controla chaves em qualquer um dos terminais do elemento monitorado ou de
qualquer outro elemento do circuito. Normalmente esse elemento de controle é conectado
aos terminais de transformadores ou linhas, mas nada impede que o seja conectado a qual-
quer outro elemento. Os principais parâmetros desse elemento de controle são descritos
na tabela 4.
Como pode ser observado pela descrição do parâmetro Type, o relé pode executar uma
dentre seis funções diferentes. Além disso, nas funções de sobrecorrente e sobretensão, a
operação do relé quanto a quantidade de religamentos e operações ocorre do mesmo modo
que nos religadores. Ressalta-se ainda que, é somado ao valor do atraso calculado pelas
curvas de atuação, ou definido pelo parâmetro Delay, o tempo de atuação do mecanismo
de abertura, definido em Breakertime. Por padrão, esse parâmetro é nulo.
1. Função de sobrecorrente de sequência negativa, ANSI 46 : Quando o mó-
dulo da corrente de sequência de negativa no terminal monitorado é maior que o
valor definido por %46𝑃𝑖𝑐𝑘𝑢𝑝×46𝐵𝑎𝑠𝑒𝐴𝑚𝑝𝑠×0.01, o relé é armado para abrir após
um delay dado pelo parâmetro Delay, caso tenha sido especificado. Caso contrário,
𝐷𝑒𝑙𝑎𝑦 = 46𝑖𝑠𝑞𝑡
( |𝐼012|46𝐵𝑎𝑠𝑒𝐴𝑚𝑝𝑠)2
(18)
Caso o relé continue armado após o tempo de delay calculado. O relé abre e é
travado. Caso a magnitude da corrente de sequência negativa fique abaixo do valor
de pickup antes do atraso de abertura, o relé é desarmado.
2. Função de sobretensão de sequência negativa, ANSI 47 :
Quando o módulo da tensão de sequência negativa no terminal monitorado é maior
que o valor definido por %47𝑃𝑖𝑐𝑘𝑢𝑝 × 𝑉 𝑏𝑎𝑠𝑒, o relé é armado para abrir após o
3.2. Controles Implementados no OpenDSS 59
delay especificado pelo parâmetro Delay. De modo semelhante à função ANSI46, o
relé é travado após a primeira abertura.
3. Função de sobrecorrente:
A função de sobrecorrente do relé opera de modo semelhante a dos religadores, isto é,
pode-se definir o número de religamentos, a curva tempo×corrente para trip de fase
ou de terra ou o parâmetro Delay, quando se deseja utilizar um tempo de abertura
fixo. Além disso, pode-se definir um valor de corrente para trip instantâneo e aplicar
um dial de tempo para as curvas tempo×corrente de fase e de terra.
4. Função de sobretensão e subtensão:
A função de sobretensão também opera de modo semelhante a dos religadores. Pode-
se definir uma curva tempo x tensão para atuação da proteção por sobretensão e
outra curva para atuação da proteção por subtensão. Assume-se que as curvas são
dadas em valores pu. Por isso, deve-se especificar uma tensão de base em kvbase,
dependendo do tipo de conexão do elemento monitorado, isto é, tensão de linha
para elementos trifásicos e tensão de fase para elementos monofásicos.
5. Detecção de fluxo de potência reverso:
Nesse modo, o relé monitora o sentido do fluxo de potência ativa. Caso a potência
ativa injetada no terminal monitorado seja negativa e maior que o valor especificado
em PhaseInst, em kW, o relé é armado para abrir com um delay de 0.1 segundos.
O relé é travado após a primeira abertura.
6. Modo genérico:
Esse modo, como o próprio nome sugere, é genérico, no sentido de que o usuário é
capaz de escolher qual variável (parâmetro Variable) será monitorada e os limites
superior(parâmetro overtrip) e inferior(parâmetro undertrip) para o valor dessa va-
riável. O trip é realizado em tempo definido, especificado em Delay. Por fim, esse
modo de operação só funciona em PCEs.
3.2.5 Controle de Armazenadores de Energia
O elemento StorageController é responsável pelo controle de armazenadores de energia.
A tabela 5 apresenta os principais parâmetros desse elemento e sua respectiva descrição.
Como visto no capítulo 2, seção 2.2, os armazenadores de energia possuem métodos
de controle próprios capazes de definir o seu modo de despacho. Porém, quando se olha
para um sistema de distribuição como um todo, é difícil garantir que o objetivo global da
utilização de armazenadores será alcançado a partir da utilização de controles locais. Por
exemplo, quando se deseja desafogar a demanda em uma subestação durante horários de
pico, a demanda no ponto de conexão de um armazenador pode não refletir a realidade do
60 Capítulo 3. Implementação de controles no OpenDSS
sistema como um todo. Por esse motivo, foi-se criado o elemento de controle StorageCon-
troller. Esse elemento é capaz de controlar simultaneamente tantos armazenadores quanto
se queira. Do mesmo modo como a maioria dos elementos de controle no OpenDSS, esse
elemento monitora um terminal de um elemento físico do circuito de potência, por exem-
plo, uma linha ou um transformador.A lista de armazenadores de energia controlados
pelo mesmo StorageController poder ser especificada pelo parâmetro ElementList. Se esse
parâmetro não for especificado, subentende-se que o todos os armazenadores de energia
do circuito são controlados pelo mesmo StorageController, nesse caso, único, pois cada
armazenador pode ser controlado por apenas um StorageController. A Figura XX ilustra
o funcionamento desse controlador. Ao todo, há seis modos de controle para descarga e
dois modos de controle para carga. Cada um desses modos é explicado abaixo:
3.2.5.1 Modos de Controle de Descarga
1. Peakshave: Esse é o modo de descarga padrão. O controle tenta despachar os
armazenadores para manter a potência monitorada em kWTarget dentro de um
intervalo (especificado por % kWBand) ou abaixo. Assim como ocorre no modo
de controle local, os armazenadores de energia são desconectados automaticamente
quando descarregados até o limite.
2. Follow: Nesse modo, o despacho é ativado por tempo, especificado em TimeDis-
charge Trigger e passa a operar de modo semelhante ao modo Peakshave, com a
diferença de que a potência alvo (kWTarget) é redefinida como sendo igual àquela
no terminal monitorado no instante do despacho.
3. Support: Esse modo é sugerido quando se deseja utilizar armazenadores de energia
para dar suporte à geração distribuída, em especial, quando se tem oscilações na
potência gerada por por painéis fotovoltaicos e geradores eólicos em casos de som-
breamento e alta variabilidade dos regimes de vento, respectivamente. Os elementos
controlados são despachados para procurar manter a potência no elemento moni-
torado igual ou superior ao valor especificado em kWTarget, em oposição ao modo
Peakshave.
4. Loadshape: Esse modo se aplica não só ao despacho, mas também ao carregamento
dos elementos, que seguem uma curva de carga (loadshape) em pu. Quando o valor
da curva é positivo, todos os armazenadores controlados são descarregados à taxa
definida pelo valor da curva. Quando o valor da curva é nulo, todos os armazenadores
entram no estado "isolado"e, por fim, quando o valor da curva é negativo, todos os
armazenadores são carregados à taxa definida pelo valor da curva.
5. Time: Nesse modo, todos os elementos armazenadores são descarregados quando a
simulação alcança uma certa hora do dia, especificada em TimeDischarge Trigger e
3.2. Controles Implementados no OpenDSS 61
são desconectados, estado "isolado", quando atingem a sua capacidade máxima de
descarga. A taxa de descarga é especificada por %RateDischarge.
6. Schedule:
3.2.5.2 Modos de Controle de Carga
1. Loadshape: Mesmo princípio do modo Loadshape durante a descarga.
2. Time: Esse é o modo de carga padrão. O princípio de funcionamento é o mesmo do
modo de descarga, todos os elementos são carregados quando a simulação alcança
uma certa hora do dia, especificada em TimeCharge Trigger. Quando os elementos
estão completamente carregados, eles são alterados para o estado "isolado". A taxa
de descarga é especificada por %RateCharge.
3.2.6 Controle de Chaves
O elemento SwtControl é responsável pelo controle de chaves. A tabela 6 apresenta
os parâmetros desse elemento e sua respectiva descrição.
O elemento de controle SwtControl controla um elemento de circuito Switch que, por
sua vez, consiste em uma linha, cujo parâmetro switch foi definido como yes. Como o
próprio modo de definição sugere, no OpenDSS, uma chave é um elemento de circuito com
as mesmas características de uma linha, ou seja, corresponde a uma impedância, porém
muito baixa. É importante notar que o OpenDSS não possui nenhum modo de controle
automático das chaves, como apresentado no elemento CapControl, por exemplo. Porém,
a interface COM pode ser utilizada para este fim.
3.2.7 Controle de Fusíveis
O elemento Fuse é responsável pelo controle dos terminais de um elemento através das
características de um fusível. A tabela 7 apresenta os parâmetros desse elemento e sua
respectiva descrição.
O elemento Fuse basicamente monitora a corrente no terminal desejado do elemento
monitorado especificado. Quando ele é aberto, a partir das características da curva TCC,
ele basicamente abre o terminal especificado do elemento controlado. Não é necessário
adicionar um elemento de circuito específico para ser controlado, como no caso do elemento
Switch e do seu respectivo controle, SwtControl.
62 Capítulo 3. Implementação de controles no OpenDSS
Tabela 4: Parâmetros do elemento de controle Relay
Parâmetro Descrição
Delay Tempo de atuação para relé de tempo fixo. Default = 0 para relés de tensão e corrente.
Quando esse parâmetro é maior que zero, ele passa a ser utilizado ao invés das curvas.
Usado pelo relé nos modos Generic, RevPower, 46 e 47. Por default, é igual a 0,1 segundo
para esses relés.
Breakertime Tempo de atraso fixo adicionado ao tempo de atuação do relé. Default = 0.
GroundCurve Nome da curva TCC que determina o tempo de atuação da proteção de terra. Default =
None, isto é, a curva é ignorada. Para relé de sobrecorrente, multiplicando o valor das
corrente na curva pelo valor do parâmetro groundtrip obtêm-se o valor atual da corrente.
GroundInst Corrente, em amperes, para trip instantâneo. Assume-se ocorrer em 10ms mais o tempo
definido no parâmetro Delay. Default = 0, que significa que não há trip instantâneo.
GroundTrip Multiplicador ou corrente de proteção de terra nominal para a curva TCC. Default = 1.
basekv Tensão de base para o relé. Especificar tensão de linha para dispositivos trifásicos e tensão
de fase para dispositivos monofásicos. O relé assume a quantidade de fases do elemento
monitorado. Default = 0, o que significa assumir que os valores de tensão da curva tempo
x corrente são especificados em tensão de fase atual, em volts.
Overtrip Condição (valor superior) de abertura para a variável do relé no modo genérico. O relé
atua com tempo de atuação fixo se a variável exceder esse valor.
Overvoltcurve Curva tempo x corrente que determina a curva de proteção por sobretensão. Se uma
tensão de base for especificada, a curva é subentendida como sendo declarada em pu. Caso
contrário, entende-se que os seus valores correspondem a tensões de fase atuais. Default =
None, ou seja, é ignorada.
PhaseCurve Nome do curva TCC que determina a de proteção de fase. Default = None, ou seja, é
ignorada. Multiplicando os valores da curva pelo valor do parâmetro phasetrip obtém-se o
valor atual da corrente.
PhaseInst Corrente em amperes(para relé de corrente) ou kW (para relé de potência) para trip ins-
tantâneo de fase. Assume-se ocorrer em 10ms mais o tempo definido no parâmetro Delay.
Default = 0, que significa que não há trip instantâneo. Usar esse parâmetro para especificar
o limiar de potência reversa, em kW, para relés de potência reversa .
PhaseTrip Multiplicador ou valor atual da corrente de fase em amperes para a curva TCC. Default =
1 .
RecloseIntervals Vetor de intervalos de religamento. Caso não se deseje religamento, deve ser especificado
como "None". Para relé no modo de sobrecorrente, o default é (0.5, 2.0, 2.0) segundos.
Possui um valor default para cada modo de operação.
Shots Número total de operações de abertura para que o relé seja bloqueado. Esse valor é um a
mais que a quantidade de religamentos. Default = 4.
TDGround Dial de tempo para a curva tempo x corrente de proteção de terra. Multiplicador no eixo
do tempo da curva especificada. Default = 1.
TDPhase Dial de tempo para a curva tempo x corrente de proteção de fase. Multiplicador no eixo
do tempo da curva especificada. Default = 1.
Type Tipo do relé. Um entre Current, Voltage, Reversepower, 46, 47 e Generic.
Undertrip Condição (valor inferior) de abertura para a variável do relé no modo genérico. O relé atua
com tempo de atuação fixo se a variável for inferior a esse valor.
Undervoltagecurve Curva tempo x corrente que determina a curva de proteção por subtensão. Se uma tensão de
base for especificada, a curva é subentendida como sendo declarada em pu. Caso contrário,
entende-se que os seusvalores correspondem a tensões de fase atuais. Default = None, ou
seja, é ignorada.
Variable Nome da varável no elemento de conversão de potência(Power Conversion Element (PCE))
sendo monitorada. Só se aplica para relé operando no modo genérico.
46%Pickup Corrente de Pickup percentual para relé operando no modo de proteção de corrente de
sequência negativa(Função 46 -American National Standards Institute (ANSI)). Default =
20. Quando a corrente excede esse valor multiplicado pela corrente de base (46BaseAmps),
o cáculo de I-squared-t começa ???.
46BaseAmps Corrente de base, em amperes, para relé operando com a função 46. Utilizada para esta-
belecer a corrente de pickup e o valor de I-squared-t em pu.
46isqt Valor da corrente I-squared-trip de sequência negativa para trip no relé no modo de proteção
de corrente de sequência negativa. Default = 1 (atua em 1 segundo para 1pu de corrente
de sequência negativa). Deve ser um valor entre 1 a 99.
47%Pickup Tensão de Pickup percentual para relé operando no modo de desbalanceamento de tensão
(Função 47 -ANSI). Default = 2. A tensão de base, basekv, e o parâmetro Delay também
devem ser especificados.
3.2. Controles Implementados no OpenDSS 63
Tabela 5: Parâmetros do elemento de controle StorageController
Parâmetro Descrição
%kWBand Largura (em % da potência alvo [𝑘𝑊 ]) da banda morta em torno da potência alvo. Default
= 2% (+/-1%). Não ocorre nenhuma mudança no despacho se a potência no elemento
controlado se encontra dentro dessa banda.
%Participation Fator de participação, %. Default = 100.
%RateCharge Define a potência de carregamento em kW como uma % em relação à capacidade nominal
de cada elemento controlado. Se aplica ao modo de controle por tempo ou em qualquer
momento em que o carregamento é ativado por engatilhamento por tempo.
%Ratekvar Define a potência de descarregamento em kvar como uma % em relação à capacidade
nominal de cada elemento controlado. Se aplica ao modo de controle por tempo ou em
qualquer momento em que o descarregamento é ativado por engatilhamento por tempo.
%RatekW Define a potência de descarregamento em kW como uma % em relação à capacidade nominal
de cada elemento controlado. Se aplica ao modo de controle por tempo, controle por
agendamento ou qualquer momento em que o descarregamento é engatilhado pelo tempo.
%Reserve Usar este parâmetro para alterar a porcentagem de reserva de cada armazenador de energia
sob controle do StorageController em questão. Pode ser utilizado, por exemplo, para per-
mitir uma descarga mais profunda do armazenador ou em caso de operação de emergência,
na qual seja necessário utilizar o restante da energia armazenada.
Daily Curva de carga de despacho, se houver, para o módulo de solução diário.
Duty Curva de carga de despacho, se houver, para o módulo de solução duty.
Element Nome completo do elemento de circuito controlado.
ElementList Vetor de armazenadores a serem controlados. Se não especificado, todos os armazenadores
do circuito serão despachados por este controlador.
InhibitTime Horas (número inteiro) para inibir a descarga após entrar no modo de carga. Default = 5.
kWActual Somente leitura. Potência de saída atual de todos os armazenadores controlados.
kWhActual Somente leitura. Energia atual armazenada em todos os armazenadores controlados.
kWhTotal Somente leitura. Capacidade de carga total de todos os armazenadores controlados.
kWneed Somente leitura. Potência necessária para atingir a potência alvo.
kWTarget Potência alvo para descarga. Os armazenadores controlados são descarregados para tentar
manter a potência na banda até que sejam descarregados.
kWThreshold Limiar, em kW, para modo seguidor. A potência deve estar acima desse valor para que
o armazenador seja despachado. Default = 75% de kWTarget. Essa propriedade deve ser
resetada após a alteração de kWTarget, se um valor diferente é desejado.
kWTotal Somente leitura. Potência total nominal de todos os armazenadores controlados.
ModeCharge Loadshape ou Time. Modo de operação para a função de carregamento dos armazenadores
controlados.
ModeDischarge Um entre {PeakShave|Follow|Support|Loadshape|Time|Schedule}. Modo de operação para
a função de descarga dos armazenadores controlados.
PFBand Largura da banda morta em torno fator de potência alvo do elemento monitorado. Default
= 0.04(+/-0.02). Não há alteração no despacho de potência reativa se o fator de potência
do elemento monitorado permanecer dentro dessa banda.
PFTarget Fator de potência alvo para despacho de potência reativa. Default = 0.96 . A potência
reativa dos armazenadores é despachada de modo a tentar manter o fator de potência na
banda, PFBand. É assumido que o inversor pode produzir reativos até a sua potência
aparente nominal independentemente do estado de carga do armazenador.
Tdn Duração, em horas, da rampa de descida para o modo de operação Schedule. Default =
0.25.
Terminal Número do terminal do elemento ao qual o controlador está conectado. Default = 1.
TFlat Duração, em horas, para a parte horizontal do modo Schedule. Default = 2.
TimeChargeTrigger Hora do dia default para iniciar a carga do armazenador no modo de controle Time. Definir
esse valor como negativo para ignorá-lo. Default = 2. Quando esse parâmetro é positivo, a
frota de armazenadores é carregada nessa hora do dia independentemente de qualquer outro
critério de controle, para que se tenha certeza que o armazenador vai estar completamente
carregado para o próximo ciclo de descarga.
TimeDischargeTrigger Hora do dia default para iniciar a descarga da frota de armazenadores. Nos modos de
operação Follow ou Time, a descarga é ativada em um tempo fixo, cada dia, nessa hora.
No modo de operação Follow, o armazenador é descarregado na tentativa de manter a
carga em uma potência igual ou abaixo da potência no instante do gatilho. No modo
Time, a descarga é baseada na propriedade %RatedkW. Definir esse valor como negativo
para ignorá-lo. Default = 12 para o modo Follow, caso contrário, é -1 (ignorado).
Tup Duração, em horas, da rampa de subida para o modo de operação Schedule. Default =
0.25.
VarDispatch Yes ou No. Default = No. Flag que indica se deve-se despachar potência reativa.
Weights Vetor com o peso proporcional correspondente a cada armazenador em ElementList. A
potência ativa ou reativa necessárias para retornar para banda central é despachada em
cada elemento de acordo com esses pesos. Default = 1, para todos os armazenadores.
Yearly Curva de carga de despacho, se houver, para o módulo de solução anual.
64 Capítulo 3. Implementação de controles no OpenDSS
Tabela 6: Parâmetros do elemento de controle SwtControl
Parâmetro Descrição
Action Open ou Close. Simula a operação manual da chave controlada, após um delay. A operação
automática exige o uso da interface COM, com algum algoritmo de controle externo.
basefreq Frequência de base para classificações.
Delay Tempo de atraso da operação da chave. Default= 120 segundos.
enabled Yes ou No. Indica se o elemento está habilitado.
Lock Yes ou No. A chave controlada é travada no seu estado atual (aberta ou fechada). O
controle não irá responder a ações de controle até que esse parâmetro seja removido.
SwitchedObj Nome do elemento do circuito que é controlado pelo SwtControl. Especificar o nome
completo (classe e nome).
SwitchedTerm Número do terminal do elemento controlado. Default = 1.
Tabela 7: Parâmetros do elemento de controle Fuse
Parâmetro Descrição
Action Open ou Close. Ação com prioridade em relação ao controle do fusível. Simula o controle
manual do equipamento. Open faz com que o elemento controlado abra e permanece
bloqueado, enquanto que Close fecha e reseta o fusível.
basefreq Frequência de base para classificações.
Delay Tempo de atraso fixo adicionado ao tempo de abertura do fusível determinado pela curva
TCC. Default = 0. Esse atraso pode ser utilizado para representar o tempo de extinção
do arco, após a fusão do fusível.
enabled Yes ou No. Indica se o elemento está habilitado.
FuseCurve Nome doobjeto da curva TCC que determina a fusão do fusível. Deve ser definida previ-
amente como "TCC_Curve object". Curva default = "Tlink". Multiplicando os valores da
curva pelo valor do parâmetro RatedCurrent obtém-se o valor atual da corrente.
MonitoredObj Nome completo (classe + nome) do elemento do circuito que é monitorado.
MonitoredTerm Número do terminal do elemento de circuito que é monitorado. Default = 1.
RatedCurrent Multiplicador ou corrente de fase nominal para a curva TCC. Default = 1.
SwitchedObj Nome do elemento do circuito que o fusível controla, ou seja, o elemento no qual o fu-
sível está conectado. O nome completo deve ser especificado. Por default, é o elemento
monitorado, definido em MonitoredObject.
SwitchedTerminal Número do terminal do elemento controlado. Default = 1. É assumido que todas as fases
do elemento possuem um fusível do mesmo tipo .
65
Capítulo 4
Inserção de elementos de controle
externos e Controle do OpenDSS via
interface COM utilizando a linguagem
Python
O objetivo desse capítulo é apresentar como o usuário pode interferir no processo
de simulação do OpenDSS, apresentado no final do capítulo 3, de tal modo a inserir
controles customizados no ambiente de simulação do software para simular diferentes
funções possíveis de serem implementadas em uma rede distribuição com um Distribution
Management System (DMS), dentro do cenário das redes elétricas inteligentes. A inserção
de funções próprias no algoritmo do OpenDSS se dá através da interface COM. Por esse
motivo, uma breve introdução à essa interface é apresentada e um exemplo de aplicação
com a rede IEEE8500 Barras é exposto ao final do capítulo.
4.1 A interface COM
A interface COM foi implementada pela Microsoft em 1993. Ela permite a comuni-
cação entre processos e a criação dinâmica de objetos em qualquer linguagem de pro-
gramação que suporte a tecnologia. Em sua essência, ela é uma forma independente de
linguagem de programação de implementar objetos de forma eles possam ser utilizados em
diferentes ambientes dos quais ele foram criados, (KEDAR, 2011). No caso do OpenDSS,
que é implementado na linguagem de programação Delphi, (DELPHI. . . , ), além da ver-
são Standalone, ele também possui uma versão DLL, a qual permite a utilização de uma
interface COM para o controle do software através de uma variedade de plataformas.
De acordo com o manual do OpenDSS, (DUGAN, 2016), essa interface foi implementada,
pois os autores projetaram o software reconhecendo que jamais seriam capazes de an-
tecipar todos os usos possíveis da ferramenta. Assim, a grande vantagem da utilização
66
Capítulo 4. Inserção de elementos de controle externos e Controle do OpenDSS via interface COM
utilizando a linguagem Python
dessa interface é que, através dela, os usuários mais experientes são capazes de utilizar
os atributos disponíveis no OpenDSS para realizar novos tipos de estudos e implementar
elementos, algoritmos que não foram implementados no software. De fato, um mundo
inteiramente novo de aplicações pode ser alcançado através da interface COM. Algorit-
mos complexos, com a utilização de loops e métodos de otimização, por exemplo, podem
ser implementados em VBA Excel, Matlab, e outras linguagens como C#, R e Python.
Como já citado anteriormente, a plataforma escolhida nesse trabalho foi a linguagem de
programação Python.
Mais recentemente, uma terceira versão do software, baseada na versão DLL foi de-
senvolvida. Ela é referida pelos autores como DirectDLL, pois ela possui a mesma funcio-
nalidade que a versão DLL, porém ela é mais rápida que a primeira. Algumas linguagens
de programação suportam a utilização das chamadas ligações prematuras, do inglês Early
Binding, para acessar o servidor COM, como a VBA Excel e a Python. Nesses casos,
o acréscimo de poucas linhas de código no instante da inicialização da interface COM é
suficiente para reduzir significativamente o tempo necessário para realização da conexão
entre o código externo e o código original. Já outras linguagens, como Matlab e LabView,
não suportam a utilização de ligações prematuras para conexão com servidores COM.
Para esses casos, os desenvolvedores elaboraram uma Direct-connection Shared Library
(DCSL), que é uma DLL capaz de reproduzir as mesmas funcionalidades da interface
COM, e com a mesma performance adquirida com a utilização de ligações prematuras.
Essa nova versão é chamada pelos autores de DirectDLL. Mais informações podem ser
obtidas em (DUGAN; MONTENEGRO, 2015) e em (MONTENEGRO, 2016).
4.2 Inserindo funções próprias na algoritmo de con-
trole interno do OpenDSS
Aplicações em que se deseja implementar controles a partir de um DMS podem ser
simuladas no OpenDSS inserindo-se ações customizadas em diferentes etapas do processo
de simulação do software, apresentado no capítulo 3. A figura 20 apresenta dois locais
comuns onde pode-se inserir ações de controle próprias.
No ponto (1), pode-se alterar as configurações dos elementos de controle já implemen-
tados no software com o objetivo de se analisar o comportamento do sistema frente a essas
alterações. Por exemplo, pode-verificar qual o efeito que a variação da tensão de referên-
cia dos taps dos transformadores causa nas perdas do sistema, entre outros. A vantagem
dessa solução é que a função implementada pelo usuário faz o uso de todo o algoritmo
de controle e dos elementos de controle próprios do OpenDSS. Já no ponto (2), pode-se
criar elementos de controle novos, definidos pelo próprio usuário, inserindo ações na lista
de controle e interagindo com os elementos próprios do software. Por exemplo, pode-se
criar um elemento de controle que monitora o fator de potência de uma dada carga e que
4.2. Inserindo funções próprias na algoritmo de controle interno do OpenDSS 67
Figura 20: Diagrama de blocos do processo de simulação com pontos onde o usuário
pode interagir.
Inicia
a solução
de uma 
série 
temporal
Inicializa a solução
no modo Snapshot
Resolve o Fluxo de 
Potência sem 
Controles
Lista
de Controles
Limpa?
Amostra os dispositivos
de controle internos e
adiciona ações à lista de 
controle
Executa ações 
pendentes da 
lista de controle
Amostra monitores 
e outras ações
de rotina
Salva monitores
e conclui simulação
Último 
passo de
tempo?
Incrementa um
passo de tempo
Loop de 
Controle
Não
Sim
Sim
Não
(1) Gerenciamento de
configurações de controle
(2) Inserção de ações de
 controle verdadeiramente
customizadas
Fonte: adaptado de (BIRCHFIELD, 2015)
corta o fornecimento de energia à essa carga a partir de um dado valor mínimo e após um
determinado tempo de aviso, isto é, um delay. Ao final desse capítulo será apresentado
um exemplo semelhante. A criação de um novo elemento de controle se dá através da
interface de controle, CtrlQueue Interface.
4.2.1 A interface de controle CtrlQueue Interface
A interface de controle contém propriedades e métodos para a interação entre objetos
de controle internos do OpenDSS e algoritmos de controle elaborados pelo usuário através
de programas externos. A interface CtrlQueue basicamente instancia um representante,
chamado de Control Proxy, que fornece uma função DoPendingAction ao OpenDSS, imi-
tando assim um objeto de controle interno do software. O Control Proxy possui uma lista
de ações semelhante à lista de controle do OpenDSS. Essa lista contém todas as ações
que foram despachadas da lista do OpenDSS, ou seja, que foram enviadas de volta aos
objetos que, originalmente, haviam inserido a ação na lista do OpenDSS através da função
PushAction, figura 21.
68
Capítulo 4. Inserção de elementos de controle externos e Controle do OpenDSS via interface COM
utilizando a linguagem Python
Figura 21: Interação entre o Control Proxy e a lista de controle do OpenDSS
Objeto 
de 
Controle
Despachante
de
ações
DoPendingAction
PushAction
COM Control
Proxy
DoPendingAction
Interface COM
Lógica do 
Usuário
PushAction
Lista de Controle
Ação 2
Ação 3{
Ação 1
Ação n
Lista de Ações
Ação 1
Ação n
Fonte: adaptado de (EPRI,2015)
Portanto, a cada iteração de controle o algoritmo do usuário deve checar a lista de ações
e decidir se deve executá-las ou não. De modo semelhante à lista de controle original, a
lista de ações despacha ações usando um parâmetro DeviceHandle, que associa a ação à um
elemento, e um parâmetro ActionCode, que contém a informação da ação a ser executada
em si. No algoritmo do OpenDSS, esses parâmetros são tratados internamente, isto é, o
elemento Relay por exemplo, já possui um valor específico para o parâmetro DeviceHandle
e cada uma das suas ações, como abrir e fechar, já possuem um ActionCode específico.
Porém, em um elemento de controle implementado externamente pela interface COM,
esses parâmetros devem ser definidos também externamente, como será visto mais adiante
em um exemplo prático.
Em suma, após uma solução do fluxo de potência convergido com sucesso, o controle
externo deve executar a amostragem das variáveis de interesse e, então, verificar se deve
empurrar ações para a lista de controle do OpenDSS. Assim, a lista de controle é a
responsável pelo despacho dessas ações de volta. No instante de despacho, o OpenDSS
sabe se uma ação teve como origem a Control Proxy e consegue despachá-la corretamente
para a lista de ações da Control Proxy, que acumula várias ações. Por fim, o código escrito
pelo usuário deve ser responsável por ler a lista de ações e despachar a ActionCode para
o algoritmo de controle apropriado.
É importante notar que todos os elementos de controle externos que possuem ações com
atraso devem utilizar esse processo, pois desse modo é possível garantir a sincronização
4.3. Exemplo de aplicação 69
com os elementos de controle internos presentes no circuito.
4.3 Exemplo de aplicação
Com o objetivo de demonstrar o uso da Control Queue Interface, um exemplo de
aplicação foi desenvolvido, no qual a rede de testes IEEE 8500 Barras foi utilizada, figura
22. A modelagem dessa rede se encontra nos arquivos de instalação do OpenDSS. Todas as
modificações realizadas nos arquivos .dss juntamente com os códigos em Python utilizados
nesse exemplo se encontram no apêndice B.
Figura 22: Rede IEEE 8500 Barras
Subestação
Fonte: autor
Nesse exemplo, imaginou-se um cenário hipotético em que consumidores em 120/240V
(Baixa Tensão (BT)) são capazes de comprar um pacote de energia diário junto às distri-
buidoras. Cada consumidor apresenta dois tipos de cargas, prioritárias e não prioritárias,
que podem representar, por exemplo, refrigeração e parte da iluminação em prédios co-
merciais, respectivamente. Assim, a energia consumida é monitorada em tempo real pela
distribuidora e sempre que o consumidor atinge um determinado nível de consumo ao
longo do dia, ele recebe uma notificação e pode ter o fornecimento de energia das suas
cargas não prioritárias cortado. A lógica é descrita abaixo:
o Se o consumo é inferior a 80% do valor contratado: Nada acontece.
o Se o consumo ultrapassa 80% do valor contratado: O consumidor recebe uma noti-
ficação.
70
Capítulo 4. Inserção de elementos de controle externos e Controle do OpenDSS via interface COM
utilizando a linguagem Python
o Se o consumo ultrapassa o valor contratado: O consumidos recebe uma nova notifi-
cação e tem o fornecimento de enegia de suas cargas não prioritárias interrompido
em 1 hora.
O objetivo de esperar 1 hora até a interrupção do fornecimento de energia é para
que o consumidor possa se preparar para tal ou tomar alguma medida como aumentar
o seu pacote diário ou comprar mais energia para um determinado dia. Além disso, um
certo "atraso"é fundamental para a utilização da Control Queue Interface. Como esse
exemplo é meramente ilustrativo, foram escolhidos arbitrariamente três consumidores,
conforme figura 23, em verdade, amarelo e vermelho, representando consumidores com
uma, baixa(1kW), média(2kW) e alta(3kW) potência instalada, respectivamente. As car-
gas prioritárias e não prioritárias foram definidas de acordo com a fase a qual elas estão
conectadas. As cargas prioritárias foram conectadas à fase A e as cargas não prioritárias
foram conectadas à fase B de seus respectivos cabos Triplex, típicos em redes de distribui-
ção secundária da América do Norte, em que cada fase apresenta uma tensão de 120V em
relação ao neutro. Além disso, às cargas prioritárias foi atribuído dois terços da potência
total instalada e o restante foi atribuído às cargas não prioritárias.
Figura 23: Rede IEEE 8500 Barras com consumidores escolhidos em destaque
Subestação
Baixa Potência
Alta Potência
Média Potência
Fonte: autor
As curvas de carga apresentadas na figura 24 foram adicionadas às cargas prioritárias
e não prioritárias e, um pacote diário de 30kWh foi assumido para cada um dos três
consumidores. A simulação foi realizada no modo diário, com um passo de simulação de
1 hora e o código foi implementado em Python, através da interface COM.
A figura 25 apresenta a evolução da demanda de cada um dos consumidores ao longo
do dia simulado e a figura 26 apresenta um trecho da saída do código desenvolvido em
4.3. Exemplo de aplicação 71
Figura 24: Curvas de carga adicionadas às cargas prioritárias e não prioritárias dos três
consumidores em questão
Fonte: autor
Python, no qual se verifica a energia consumida por cada um dos três consumidores em
três diferentes instantes da simulação. Em cada um desses instantes há uma notificação
da distribuidora enviada à um respectivo consumidor, emulada aqui como um simples
print. Os consumidores de baixa, média e alta potência instalada foram denominados de
consumidores A,B e C.
Nota-se que, o consumidor C, como esperado, foi o primeiro a atingir a receber uma
notificação ao ultrapassar o limite de 80% de consumo, isto é, 24 kWh. Isso ocorreu ao final
da hora 16. Como não o código não apresenta nenhum tipo de alteração no consumo de
cada um dos consumidores devido à notificação recebida, o que provavelmente aconteceria
em uma situação mais realista, a demanda desse consumidor continuou a seguir a curva
de carga descrita anteriormente na figura 24. Assim, no passo de simulação da hora 19, o
consumidor ultrapassa a sua cota contratada de 30kWh, com um consumo energético de
31,8 kWh. Portanto, ele recebe uma notificação de que suas cargas não prioritárias terão
o seu fornecimento interrompido após uma hora daquele instante, isto é, às 20:00hr. O
consumidor B atinge 80% de sua cota diária contratada ao final da hora 22. Porém, a
sua cota não é integralmente ultrapassa antes do término do dia. Por fim, o consumidor
A não chega a atingir nenhum dos limites de energia e, portanto, não recebe nenhuma
notificação.
A interrupção do fornecimento de energia das cargas prioritárias do consumidor C
pode ser observada na figura 25, onde, às 20:00hr, nota-se que a demanda das cargas
prioritárias é nula e consequentemente, a demanda total desse consumidor é integralmente
igual à demanda das cargas não prioritárias.
Um ponto importante a se notar aqui, é que o OpenDSS apresenta uma solução com
72
Capítulo 4. Inserção de elementos de controle externos e Controle do OpenDSS via interface COM
utilizando a linguagem Python
Figura 25: Demanda Total dos consumidores e demanda por tipo de carga ao longo do
dia simulado
Fonte: autor
um passo de tempo de 1 hora. A energia consumida é então calculada considerando-se que
o consumo até o próximo passo de tempo é constante. Em outras palavras, a figura 25 não
é perfeitamente fiel à demanda das cargas considerada no cálculo da energia consumida,
pois ela considera que a demanda dos consumidores é interpolada entre cada passo de
tempo, o que de fato não é, pois o passo de simulação utilizado nesse exemplo foi de 1
hora. Para minimização deste erro, basta realizar uma simulação com um passo de tempo
reduzido, como, por exemplo, 1 segundo. Assim, mesmo que a curva de carga utilizada
possua um passo de 1 hora, ela é interpolada pelo OpenDSS internamente.
O ponto mais importante desse exemplo corresponde ao atraso de 1 hora inserido na
ação de interrupção dofornecimento de energia. Para simulação desse atraso, foi utilizada
a Control Queue Interface, apresentada na seção anterior. A lista de controle dessa
simulação foi armazenada a cada passo de simulação. Na figura 27, encontra-se o conteúdo
da lista no passo de simulação correspondente à hora 20, antes e após a execução das ações
pendentes. Nota-se que, antes da execução das ações pendentes, há uma ação, número
199, que foi inserida pelo "dispositivo"COM_Proxy. Essa ação corresponde justamente ao
interrompimento do fornecimento de energia das cargas prioritárias do consumidor C, que
foi inserida através da Control Queue Interface. Além disso, é importante notar a presença
de outras ações na lista de controle, geridas pelos elementos de controle já implementados
no OpenDSS e presentes na rede IEEE 8500 Barras, os quais são reguladores de tensão e
banco de capacitores chaveados. Por fim, nota-se que todas as ações com um tempo de
4.3. Exemplo de aplicação 73
Figura 26: Saída do código desenvolvido em Python
Fonte: autor
atuação anterior ou igual à hora 20 são realizados nesse passo de simulação.
74
Capítulo 4. Inserção de elementos de controle externos e Controle do OpenDSS via interface COM
utilizando a linguagem Python
Figura 27: Trecho da lista de ações evidenciando a presença de uma ação inserida através
da CtrlQueue Interface
Fonte: autor
75
Capítulo 5
Aplicação de algoritmo de controle
personalizado em recursos distribuídos
adicionados à rede IEEE 123 Barras
Este capítulo apresenta a aplicação de um algoritmo de controle personalizado apli-
cado à rede de testes IEEE 123 Barras, com algumas modificações. A aplicação consiste
na análise do aumento do número de operações em reguladores de tensão quando se é
adicionado um gerador fotovoltaico na rede em estudo, com uma curva de irradiação com
alta variabilidade e em diferentes níveis de penetração. Primeiramente, explica-se as ca-
racterísticas da rede, os motivos da sua escolha e as modificações executadas. Então,
os dados de entrada adotados são apresentados, seguidos da constatação da problema.
Por fim, um método para a mitigação do problema é apresentado, implementado e os
resultados são analisados.
5.1 Introdução
A flutuação de tensão de curta duração causada pela alta intermitência de fontes re-
nováveis como a solar e a eólica tem sido objeto de estudo desde o final da década de
80. Inicialmente, o enfoque foi dado na quantificação da variabilidade da irradiação so-
lar e como isso pode afetar o sistema elétrico quando utiliza-se geração concentrada e
distribuída, (BEYER et al., 1991), (JEWELL; RAMAKUMAR, 1987) e (OTANI; MINOWA; KU-
ROKAWA, 1997). Em geral, observou-se que a dispersão geográfica da geração fotovoltaica
atua naturalmente como um filtro para a flutuação de potência gerada, como apresentado
em (MARCOS et al., 2012) e em (KLIMA; APT, 2015).
Em sistemas de transmissão, principalmente nos de pequeno porte, com poucas inter-
conexões ou com a uma grande concentração de geração eólica e/ou solar em uma única
região, os impactos da variação de curta duração do recurso energético é mais significativo,
pois, nessas circunstâncias, é mais improvável que a rede tenha um estoque considerável
76
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
de recursos geradores, acesso a mercados de balanço de energia ou a diversidade geográ-
fica necessária para gerenciar esses eventos (PORTER; WEISBURGER, 2007). Uma solução
encontrada por alguns operadores de rede de transmissão recai integralmente sobre o
responsável pela geração solar e/ou eólica. Por exemplo, no ano de 2013, a Autoridade
de Energia Elétrica de Porto Rico (PREPA) estabeleceu um limite de taxa de rampa
(MW/min) de 10% em relação à capacidade nominal de geração, tanto para geração solar
quanto para eólica, (K PORTER; WEISBURGER, 2013). Restrições semelhantes foram im-
plementadas na Irlanda, na Escócia, na província de Alberta (Canadá) e na Alemanha,
(PORTER; WEISBURGER, 2007).
Com um aumento expressivo da penetração, principalmente da geração solar, também
em redes de distribuição, tanto na forma de plantas mais centralizadas quanto dispersas,
tem-se analisado como essa rápida variação de potência afeta a operação de elementos
como LTC’s, banco de capacitores chaveados e reguladores de tensão, comuns em redes
de distribuição e responsáveis por corrigir variações de tensão de longa duração, dadas
essencialmente pela variação da demanda ao longo do dia. Algumas soluções apresentadas
propõem a utilização de um controle coordenado entre recursos energéticos distribuídos,
incluindo baterias, e os equipamentos reguladores de tensão, como em (LIU et al., 2012)
e em (BASS et al., 2016). Tais soluções se apresentam bastante adequadas no cenário das
redes elétricas inteligentes. Porém, enquanto não se dispõe de uma infraestrutura capaz
de fornecer a troca de informações necessárias, outras soluções, mais localizadas, como a
utilização de sistema armazenadores de energia com controle de rampa, (CHAMANA et al.,
2014), (LAM; YEH, 2014) e (MARCOS et al., 2014) ou através de um controle da potência
despachada com o uso de uma média móvel, como em (MOUMOUNI; BAGHZOUZ; BOEHM,
2014), e algumas variações desse método, buscando-se otimizar a utilização de sistemas
de armazenadores de energia, como em (CHANHOM; SIRISUKPRASERT; HATTI, 2013) e
(MAMMOLI et al., 2013), têm sido adotadas.
A aplicação final deste trabalho tem como objetivo analisar como as variações de
tensão de curta duração causadas pelo sombreamento em uma planta solar instalada na
rede de testes IEEE 123 Barras afeta a quantidade de operações dos reguladores de tensão
da rede e como esse efeito pode ser mitigado a partir de estratégias de controle baseadas
nos trabalhos acima referidos. Todas as simulações realizadas foram implementadas no
OpenDSS, através da utilização da interface COM, a partir da linguagem de programação
Python. Todos os algoritmos desenvolvidos se encontram no apêndice C.
5.2. A rede IEEE 123 Barras 77
5.2 A rede IEEE 123 Barras
5.2.1 Características
A rede de testes IEEE 123 barras, figura 28, foi desenvolvida em 2009 pelo Subcomitê
de Análise de Sistemas de Distribuição do IEEE PES (Power and Energy Society). Essa
rede foi escolhida pelo fato de, dentre as redes de distribuição desbalanceadas propostas
pelo IEEE, ela ser a que agrega a maior quantidade de diferentes tipos carga, linhas e de
elementos reguladores de tensão. As suas principais características são descritas abaixo:
o Quanto as Cargas:
– Potência Ativa e Reativa Totais: 3490 kW e 1920 kvar
Dos quais:
* Fase A: 1135 kW e 575 kvar
* Fase B: 705 kW e 365 kvar
* Fase C: 910 kW e 455 kvar
* Fase AB: 180 kW e 125 kvar
* Fase BC: 105 kW e 75 kvar
* Fase CA: 140 kW e 100 kvar
* Fase ABC: 315 kW e 225 kvar
– Agregadas, em Média Tensão (MT)
– Conectadas em delta ou estrela
– Modeladas como potência constante, impedância constante e corrente cons-
tante
– Desbalanceadas
o Quanto as Linhas:
– Linhas áreas trifásicas, bifásicas e monofásicas
– Linhas subterrâneas trifásicas
o Quanto ao nível de tensão:
– Tensão de linha de 4,16 kV
o Quanto aos reguladores de tensão:
As especificações dos reguladores de tensão presentes na rede IEEE 123 Barras estão
sumarizadas na tabela 8. Nota-se que, com exceção do regulador mais próximo à
subestação, 1a, todos os outros reguladores são monofásicos. Além disso, todos os
reguladores possuem LDC e um TP com uma relação de transformação de 20:1.
78
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
Tabela 8: Dados dos reguladores de tensão
Regulador de Tensão
1a 2a 3a 3c 4a 4b 4c
Fases 3 1 1 1 1 1 1
Localização (Barra) 150 9 25 25 160 160 160
Referência de Tensão 120 V 120 V 120 V 120 V 124 V 124 V 124 V
Banda 2 V 2 V 1 V 1 V 2 V 2 V 2 V
Delay 2s 2s 2s 2s 2s 2s 2s
R 3 0,4 0,4 0,4 0,6 1,4 0,2
X 7,5 0,4 0,4 0,4 1,3 2,6 1,4
CTprim 700 A50 A 50 A 50 A 300 A 300 A 300 A
Fase Monitorada A A A C A B C
Uma referência de tensão de 120V no secundário do TP corresponde, portanto, a
uma tensão de fase igual à tensão nominal de fase, 2,402 kV. Outro fato a se notar
é que a banda dos reguladores de tensão 3a e 3c é de apenas 1V. Isso significa que
esses reguladores devem atuar para qualquer nível de tensão fora da faixa 2,402
+/- 0,01 kV. A quantidade de taps dos reguladores de tensão é a mesma da figura
14, isto é, a mudança de um tap leva a uma variação de tensão de 0,00625pu,
ou aproximadamente 15V (pois a variação real depende da tensão no primário do
regulador), para mais ou para menos. Em outras palavras, para os reguladores 3a
e 3c, só há apenas 1 tap capaz de manter a tensão dentro da banda especificada, o
que significa que a operação desses dois reguladores é mais sensível que a dos outros
reguladores da rede.
o Capacitores Shunt:
– 1 Trifásico, fixo, de 600 kvar, conectado à barra 83
– 3 Monofásicos, fixos de 50 kvar cada, conectados às barras 88,90 e 92
5.2.2 Modificações
A única alteração realizada na rede IEEE 123 Barras original em relação aos compo-
nentes elétricos foi a adição de um sistema fotovoltaico. Como o objetivo do estudo é
analisar o impacto de uma curva de irradiação com alta variabilidade nos reguladores de
tensão, o sistema fotovoltaico, juntamente com um transformador de conexão foi adicio-
nado na barra de número 300, que é uma das extremidades trifásicas da rede. Esse nó foi
escolhido, pois, mantidos todos os outros parâmetros constantes, espera-se que o impacto
seja maior quanto mais distante estiver o ponto de conexão do sistema fotovoltaico do
equivalente de Thévenin, ou barra Swing, conforme a figura 29, onde os trechos de rede
trifásicos foram colocados em evidência.
5.3. Dados de entrada 79
Figura 28: Diagrama Unifilar da rede IEEE123 Barras
1
3
4
5 6
2
7 8
12
11 14
10
20
19
22
21
18
40
135
33
32
31
27
26
25
28
29
30
250
48
47
49
50
51
44
45
46
42
43
41
36
38 39
66
65
64
63
62
60
160 67
57
58
59
545352
55 56
13
34
15
16
17
96
95
94
93
152
92 90
88
91 89
87 86
80
81
82
83
84
78
8572
73
74
75
77
79
300
111 110
108
109 107
112 113 114
105
106
101
102
103
104
450
100
97
99
68
69
70
71
197
151
150
61
6109
24
23
251
195
451
149
350
35
37
98
76
Fonte: autor
5.3 Dados de entrada
Para o estudo proposto, foram-se realizadas simulações temporais (Quasi-Static Times-
Series (QSTS)) ao longo de um dia, as quais exigiram a utilização de curvas de carga e
de uma curva de irradiação para o sistema fotovoltaico. A descrição completa de todos os
elementos da rede na linguagem de programação do OpenDSS é apresentada no apêndice
C.
5.3.1 Sistema Fotovoltaico
Como pode-se notar na figura 29, a geração solar foi conectada à rede de distribuição
através de um transformador de conexão, como sugere a resolução normativa n∘687, da
Agência Nacional de Energia Elétrica (ANEEL), para minigeração. Nessa aplicação, toda
a potência gerada é injetada na rede de distribuição com um fator de potência unitário.
A curva de irradiação utilizada foi fornecida gratuitamente pelo Electric Power Re-
search Institute (EPRI), disponibilizada juntamente com os arquivos de instalação do
OpenDSS e podendo também ser obtida através da página (EPRI, 2016). A curva de ir-
radiação contém um intervalo de dados de um dia, com resolução de 1 segundo, conforme
figura 30. A curva apresenta alta variabilidade, podendo haver uma redução da irradia-
80
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
Figura 29: Diagrama Unifilar da rede IEEE123 Barras com a adição de um sistema
fotovoltaico e um transformador de conexão na barra 300 e com as linhas trifásicas em
evidência (linha cheia)
1
3
4
5 6
2
7 8
12
11 14
10
20
19
22
21
18
40
135
33
32
31
27
26
25
28
29
30
250
48
47
49
50
51
44
45
46
42
43
41
36
38 39
66
65
64
63
62
60
160 67
57
58
59
545352
55 56
13
34
15
16
17
96
95
94
93
152
92 90
88
91 89
87 86
80
81
82
83
84
78
8572
73
74
75
77
79
300
111 110
108
109 107
112 113 114
105
106
101
102
103
104
450
100
97
99
68
69
70
71
197
151
150
61
6109
24
23
251
195
451
149
350
35
37
98
76
Fonte: autor
ção de ordem de 50% em um intervalo de tempo de aproximadamente 3 minutos, como
pode-se observar na região ampliada da mesma figura, o que é uma variação bem realista,
pois, de acordo com (BOLLEN; HASSAN, 2012), a geração de um único painel fotovoltaico
pode variar em até 50% da potência nominal em um intervalo de 5 a 10 segundos.
5.3.2 Curvas de carga
A curva de carga utilizada para todas as cargas do sistema é apresentada na figura
31. Ela apresenta resolução de 1 hora. As simulações realizadas nessa aplicação possuem
um passo de tempo de 1 segundo. Sendo assim, a curva de carga é automaticamente
interpolada no OpenDSS.
5.4 Constatação do problema
Inicialmente, buscou-se quantificar os impactos da geração fotovoltaica na rede. A
figura 32 mostra a influência dos diferentes níveis de penetração sobre a tensão no ponto
5.4. Constatação do problema 81
Figura 30: Curva de irradiação normalizada, com zoom em um intervalo de tempo de
aproximadamente 5 minutos
Fonte: autor
Figura 31: Curva de carga diária
Fonte: autor
de conexão (MT) com a rede de distribuição na condição de base, isto é, sem nenhuma
penetração, e também para um nível de penetração de 10%, 20% e 30%.
A alteração no nível de tensão do ponto de interconexão é evidente. Além disso, sabe-
se que a injeção de potência ativa na rede tende a elevar o perfil de tensão da mesma.
Como só há potência injetada em uma única barra do sistema, podemos dizer que o local
com a maior probabilidade de haver sobretensão é no ponto de interconexão, haja vista
82
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
Figura 32: Tensão no ponto de conexão da geração solar para diferentes níveis de pene-
tração
Fonte: autor
que a tensão na subestação é controlada em níveis adequados. Sendo assim, a partir da
figura 32, pode-se notar que os limites de tensão estabelecidos pela norma (C84.1, 2006)
são satisfeitos ao longo do dia considerado, isto é, os reguladores de tensão são suficientes
para manter a tensão em níveis de fornecimento adequados.
Com o objetivo de se analisar como o stress dos reguladores de tensão é afetado,
verificou-se a quantidade de operações de todos os reguladores da rede ao longo do tempo,
não só para diferentes níveis de penetração, mas também para diferentes níveis de carga
instalada. Quando se aumenta o nível de carga da rede, as variações de tensão de longa
duração tornam-se, naturalmente, mais acentuadas. Como consequência, os equipamen-
tos responsáveis por regular a tensão tornam-se mais sensíveis às rápidas flutuações de
potência injetada pela geração fotovoltaica. Os cenários utilizados são apresentados na
tabela 9.
Tabela 9: Cenários simulados para verificação da atuação dos reguladores de tensão
Penetração [kW]
Multiplicador de Carga Potência Instalada [kW] 10% 20% 30%
1 3490 349 698 1047
1,15 4013 401,3 802,6 1203,9
1,3 4537 453,7 907,4 1361,1
A figura 33 apresenta o número acumulado das operações do reguladores de tensão ao
5.4. Constatação do problema 83
longo do dia para os 12 cenários considerados. Através dela, é possível verificar que, de
fato, a atuação dos reguladores é mais intensa durante o período do dia em que há uma
grande oscilação na geração fotovoltaica. Um ponto interessante a se notar é que a relação
entre a quantidade de operações acumuladas não possui necessariamente uma relação
monotônica com o aumento da penetração. Em algum nível de penetração intermediário, é
possível que a quantidade total de mudanças de tap do reguladores seja menor ou igual que
no caso base, sem penetração, para o respectivo multiplicador decarga, conforme tabela
10. Isso pode ser explicado pelo fato de que parte da variação de tensão de longa duração,
originada da curva de carga adotada, é atenuada pela geração fotovoltaica. Porém, a
medida em que o nível de penetração aumenta, a variação de tensão de curta duração,
dada pelo sombreamento dos painéis fotovoltaicos, que se sobrepõe à variação de longa
duração, passa a ser mais significativa, impactando na quantidade total de operações dos
reguladores.
Figura 33: Número acumulado de operações dos reguladores de tensão ao longo de um
dia para diferentes níveis de carga e de penetração
Fonte: autor
A figura 33 ilustra bem a coincidência temporal entre a quantidade de operações
dos reguladores de tensão e a geração fotovoltaica, bem como um panorama geral do
comportamento dos reguladores de tensão, porém, para uma análise mais profunda do
problema, é necessário verificar como cada regulador responde, individualmente, à conexão
da geração solar. A tabela 11 sumariza o número de operações individuais de todos os
reguladores da rede para todos os casos simulados. Nela, pode-se destacar alguns pontos:
84
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
Tabela 10: Impacto de diferentes níveis de carga e penetração na quantidade total de
operações dos reguladores de tensão
Penetração
Multiplicador
de Carga
Operações sem
PV (Base) 10% 20% 30%
1 28 0% 0% -21,43%
1,15 36 +5,56% +38,89% +27,78%
1,3 42 0% 0% +114,286%
Tabela 11: Número de operações individuais dos reguladores da rede IEEE 123 Barras
para todos os casos simulados
Número de Operações
Multiplicador de Carga 1,0 1,15 1,30
Penetração 0% 10% 20% 30% 0% 10% 20% 30% 0% 10% 20% 30%
1a 4 4 4 2 6 6 6 6 7 7 7 7
2a 0 0 0 0 2 2 2 2 2 2 2 2
3a 6 6 6 4 6 6 16 10 9 9 9 53
3c 6 6 6 4 8 10 12 10 12 12 12 12
4a 6 6 6 6 8 8 8 12 6 6 6 10
4b 2 2 2 2 2 2 2 2 2 2 2 2
4c 4 4 4 4 4 4 4 4 4 4 4 4
Total 28 28 28 22 36 38 50 46 42 42 42 90
o O número de operações da maioria dos reguladores é pouco ou não é afetado:
Nota-se que, nos casos simulados, a operação dos reguladores 1a e 2a pouco varia e
a operação dos reguladores 4b e 4c não é afetada. Todos esses reguladores possuem
uma variação máxima de 2 operações, enquanto que os reguladores 3a, 3c e 4a
apresentam uma variação máxima de 47, 6 e 6 operações, respectivamente.
o O regulador mais afetado não é aquele mais próximo do ponto de conexão da geração
fotovoltaica:
De fato, inicialmente, poderia-se esperar que os reguladores mais afetados seriam os
reguladores 4a, 4b e 4c, por estarem mais próximos do ponto de conexão da geração
fotovoltaica e mais afastados da barra swing da rede.
o Os reguladores mais afetados estão conectados à fase A da rede:
Os reguladores 3a e 4a, conectados à fase A da rede são os que apresentam maior
sensibilidade ao nível de carga instalada e ao nível de penetração do gerador foto-
voltaico.
Essas constatações podem ser explicadas por fatos já apresentados anteriormente.
Primeiramente, nessa rede, em especial, há dois fatores determinantes no comportamento
dos reguladores de tensão. Um deles é que a rede estudada é desequilibrada, com a fase A
sendo significativamente mais carregada que as outras, como apresentado na seção 5.2.1.
Por esse motivo, os reguladores conectados à fase A são os mais afetados pela variação de
5.5. Solução proposta 85
tensão de longa duração devido à curva de carga. Caso multiplicadores de carga maiores
tivessem sido utilizados, certamente chegaria-se a um ponto em que os reguladores da
fase B e C começariam a reagir mais intensamente à variação da curva de carga, sendo
aqueles conectados à fase C sendo mais afetados haja vista que a fase C é mais carregada
que a fase B. Segundo essa lógica, poderia-se esperar que os reguladores 2a e o regulador
trifásico 1a, cuja tensão monitorada é a tensão da fase A, também apresentassem uma
maior sensibilidade, porém, é importante notar que esses dois reguladores estão muito
próximos da barra swing do sistema, que é uma região forte, isto é, uma região em
que a impedância total até o equivalente de Thévenin da rede de transmissão é baixa,
resultando em uma baixa sensibilidade da tensão com relação ao carregamento do sistema.
O segundo fator é que os reguladores 3a e 3c apresentam uma banda ao redor da referência
de tensão muito estreita, que, como já comentando anteriormente, comporta apenas 1 tap
do regulador, tornando ambos os reguladores mais sensíveis à variações de tensão. São
por esses dois motivos que, mesmo estando relativamente afastado do ponto de conexão
da geração fotovoltaica, o regulador 3a é aquele que, a partir de um certo nível de carga
e penetração, é o primeiro a apresentar um grande aumento no seu número de operações.
Por fim, os métodos de mitigação desse impacto apresentados nas seções seguintes
levam em conta que não se pode alterar os parâmetros dos reguladores da rede.
5.5 Solução proposta
Para reduzir a quantidade de operações dos reguladores é necessário de algum modo
filtrar a flutuação de tensão no sistema. A flutuação de tensão nada mais é do que o reflexo
da flutuação da potência injetada pelo sistema fotovoltaico devido à alta variabilidade do
recurso solar. Do ponto de vista técnico, o uso de baterias conectadas em paralelo com
painéis fotovoltaicos consiste em uma solução bastante adequada para essa compensação
haja vista que as mesmas possuem tempo de resposta da ordem de centésimos de segundo,
(CHAMANA et al., 2014).
As soluções propostas nesse trabalho se baseiam no uso de baterias como elementos
armazenadores de energia e como compensador da potência injetada pelo sistema fotovol-
taico. A conexão da bateria e do sistema fotovoltaico na rede é esquematizada na figura
34. A bateria deve ser, então, responsável por despachar uma potência tal que a potência
injetada na rede resultante seja igual a um dado valor desejado, o qual será chamado de
𝑃𝑑𝑒𝑠. Como o objetivo é filtrar a flutuação da potência gerada pelo sistema fotovoltaico,
𝑃𝑝𝑣, idealmente, 𝑃𝑑𝑒𝑠 deve ser exatamente igual à potência gerada caso os painéis foto-
voltaicos não estivessem sob o efeito do sombreamento. Infelizmente, não é possível ter
ingerência sobre o comportamento da curva de irradiação, dado que ela é definida pelas
condições climáticas do local de instalação dos painéis fotovoltaicos. Porém, pode-se ten-
tar prevê-la. Para isso, há inúmeros métodos na literatura, como o descrito em (MAMMOLI
86
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
Figura 34: Conexão do sistema fotovoltaico em paralelo com baterias na barra 300 da
rede IEEE 123 barras através de um transformador de interconexão
300
P
pv
P
bat
Trafo de
interconexão
P
inj
Fonte: autor
et al., 2013) e em (CHOW et al., 2011). Nesse caso, é possível estimar qual será a respectiva
variação da potência injetada na rede e, portanto, compensá-la adequadamente.
Nesse trabalho são utilizadas duas estratégias de controle de despacho da bateria. A
primeira utiliza uma média móvel da potência gerada pelo sistema fotovoltaico e a outra
corresponde a uma modificação da primeira, visando um melhor aproveitamento da bate-
ria. Ambos são descritos em detalhes nas próximas seções. Além disso, uma das análises
realizadas se refere às especificações mínimas da bateria quando cada uma das estratégias
é utilizada. Essas especificações mínimas são extraídas dos resultados obtidos nas simula-
ções. Sendo assim, no OpenDSS, a bateria foi descrita com uma capacidade em potência
e energia extremamente elevada, de tal modo que ela fosse capaz de fornecer a potência e
a energia total exigida como resultado do algoritmo de controle implementado. No caso,
a potência nominal foi definida em 1000kW e a capacidade de carga em 10000kWh. Esses
e todos os outros parâmetros utilizados são apresentados no apêndice C.
5.5.1 Média Móvel
Quando não se dispõe de nenhum método para previsão da irradiação/sombreamentoem tempo real, um recurso bastante utilizado é a média móvel. Ela consiste na utilização
de dados anteriores da potência gerada pelos módulos fotovoltaicos para realizar uma
estimativa de qual deve ser ou qual seria a potência gerada no instante em questão, caso
não houvesse sombreamento. A estimativa se baseia na média dos dados amostrados em
um certo intervalo de tempo anterior. A figura 35 ilustra o conceito. Nota-se a utilização
de uma janela “móvel” que contém os dados anteriores a serem utilizadas para o cálculo
da média. Nesse caso, a potência desejada é matematicamente descrita pela equação 19.
𝑃𝑑𝑒𝑠(𝑡) =
1
𝜏
∫︁ 𝑡
𝑡−𝜏
𝑃𝑝𝑣(𝑡)𝑑𝑡 (19)
5.5. Solução proposta 87
Figura 35: Representação da janela móvel
τ
τt- t
Fonte: autor
Como a evolução do tempo no OpenDSS é discreta e o passo de simulação utilizado é
de 1 segundo, a equação 19 pode ser reescrita por
𝑃𝑑𝑒𝑠[𝑡] =
1
𝑛
𝑛−1∑︁
𝑖=0
𝑃𝑝𝑣[𝑡 − 𝑖] (20)
onde n corresponde ao tamanho da janela da média móvel, em segundos, ou ainda a
quantidade de amostras consideradas para o cálculo da média móvel. Como o objetivo
é fazer com que a potência injetada total seja igual a 𝑃𝑑𝑒𝑠, a potência despachada pela
bateria é então descrita por
𝑃𝑏𝑎𝑡[𝑡] = 𝑃𝑑𝑒𝑠[𝑡] − 𝑃𝑝𝑣[𝑡] (21)
O diagrama de blocos da figura 36 ilustra o algoritmo utilizado.
Figura 36: Diagrama de blocos do algoritmo para suavização da flutuação da potência
injetada na rede pelos painéis fotovoltaicos
Ppv[t]
Pdes[t]
+
-
Pbat[t]
t
τ
tτt-
Média Móvel
Fonte: autor
88
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
o Implementação:
A implementação do algoritmo de controle segue essencialmente o diagrama de blo-
cos descrito no capítulo 4, figura 20. O ponto de acesso escolhido para a inserção do
controle personalizado foi o ponto de acesso (2). No capítulo anterior, foi visto que
esse deve ser utilizado quando se deseja inserir ações de controle verdadeiramente
customizadas, isto é, quando se utiliza a CtrlQueue Interface para inserir ações de
controle que devem interagir com as ações dos elementos de controle implementados
diretamente no OpenDSS, como os reguladores de tensão, no caso em questão. Po-
rém, nessa aplicação, assumiu-se que a bateria possui um tempo de resposta menor
que o passo de simulação de 1 segundo de tal modo que não houve a necessidade de
se inserir ações na lista de controle, pois não há nenhum atraso envolvido na atuali-
zação do despacho da bateria. De acordo com essa lógica, poderia-se ter utilizado o
ponto de acesso (1). Porém, um fato adicional nessa aplicação faz com que isso não
seja possível. O cálculo da potência despachada pela bateria num dado instante, t,
é dependente da potência gerada pelo gerador fotovoltaico no mesmo instante de
tempo, como visto na equação 21. Então, a atualização do despacho das baterias
só pode ser realizada depois que a potência gerada pelo gerador fotovoltaico tenha
sido devidamente atualizada e o seu novo valor tenha ficado disponível na interface
COM, para utilização pelo algoritmo de controle.
Em um dado passo de simulação, isso só ocorre após a execução do primeiro fluxo
de potência dentro do loop de controle, isto é, no bloco “Resolve o Fluxo de Po-
tência sem Controles”, do diagrama apresentado na figura 20. Nesse bloco, antes
do processo iterativo de cálculo do fluxo de potência, todos os PCEs têm as suas
respectivas variáveis atualizadas. No caso do sistema fotovoltaico, a potência gerada
no passo de tempo em questão é calculada pela equação 2.
Assim, a cada passo de simulação, sempre que o algoritmo se encontra na primeira
iteração do loop de controle e após o cálculo do fluxo de potência, o algoritmo de
controle é invocado, através de um método chamado 𝑎𝑡𝑢𝑎𝑙𝑖𝑧𝑎_𝑃𝑏𝑎𝑡𝑒𝑟𝑖𝑎𝑠() que,
como o nome sugere, é responsável por atualizar o despacho das baterias. Logo
após a execução desse método, uma nova solução do fluxo de potência é realizada e
o processo de simulação segue a sua lógica padrão. Em outras palavras, a primeira
solução do fluxo de potência tem como objetivo simplesmente atualizar a potência
gerada pelos painéis fotovoltaicos. O método 𝑎𝑡𝑢𝑎𝑙𝑖𝑧𝑎_𝑃𝑏𝑎𝑡𝑒𝑟𝑖𝑎𝑠() é explicado
passo-a-passo abaixo:
1. Verificação do instante do dia: Primeiramente, o método 𝑎𝑡𝑢𝑎𝑙𝑖𝑧𝑎_𝑃𝑏𝑎𝑡𝑒𝑟𝑖𝑎𝑠()
só é invocado quando o tempo de simulação se encontra dentro da faixa horária
em que há geração fotovoltaica, com base na curva de irradiação utilizada. O
5.5. Solução proposta 89
objetivo dessa verificação é reduzir o tempo de simulação total. A faixa horária
na qual o algoritmo é ativado é das 5:00 horas até as 19:00 horas.
2. Inicialização do Registrador de Deslocamento: A média móvel descrita pela
equação 20 foi implementada através de um registrador de deslocamento, no
qual a potência gerada nos instantes de tempo anteriores, definidos pelo tama-
nho da janela móvel, são armazenados. Sempre que o método 𝑎𝑡𝑢𝑎𝑙𝑖𝑧𝑎_𝑃𝑏𝑎𝑡𝑒𝑟𝑖𝑎𝑠()
é chamado pela primeira vez no dia simulado, o registrador de deslocamento é
inicializado com todos os seus elementos sendo nulos, conforme figura 37.
Figura 37: Representação da inicialização do registrador de deslocamento utilizado no
cálculo da média móvel.
P[t] P[t-1] P[t-2] P[t-(n-1)]
0 0 0 0 0
Fonte: autor
3. Deslocamento dos elementos armazenados no Registrador de Deslocamento:
Cada vez que o método 𝑎𝑡𝑢𝑎𝑙𝑖𝑧𝑎_𝑃𝑏𝑎𝑡𝑒𝑟𝑖𝑎𝑠() é chamado, os elementos do
registrador são deslocados e a potência gerada no instante de tempo em questão
é inserida no seu primeiro elemento. Do mesmo modo, a potência gerada no
instante t-(n-2) é eliminada do registrador de deslocamento, conforme figura
38.
Figura 38: Representação do registrador de deslocamento utilizado no cálculo da média
móvel.
P[t] P[t-1] P[t-2] P[t-(n-1)]
PPV[t] PPV[t-(n-2)]
Fonte: autor
4. Cálculo de 𝑃𝑑𝑒𝑠 e de 𝑃𝑏𝑎𝑡:
A potência gerada desejada é então calculada a partir da somatória de todos
os elementos presentes no registrador de deslocamento, dividido pelo tamanho
de amostras da janela móvel, conforme equação 20, e a nova potência a ser
despachada pela bateria é calculada através da equação 21.
5. Atualização do despacho e do estado das baterias via interface COM:
Por fim, com o novo valor de potência a ser despachado pela bateria, verifica-se
se o mesmo é positivo, representando uma potência injetada na rede (bateria
90
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
descarregando), negativo, representando uma potência absorvida da rede (ba-
teria carregando), ou nulo, representando a bateria em um estado ilhado. As-
sim, a bateria tem o seu estado e a sua nova potência despachada atualizados
através da interface ActiveCktElement, disponível através da interface COM.
o Resultados:
O algoritmo de controle foi simulado para o caso de um multiplicador de carga igual
1,3 e uma penetração de 30%, pois, nessa situação, de acordo com a figura 33, o
ajuste dos reguladores de tensão se mostrou mais sensível à flutuação de tensão
devido à alta variabilidade da irradiação incidente sobre os painéis fotovoltaicos.
Além disso, buscou-se analisar como a utilização de diferentes tamanhos de janela
da média móvel afeta o algoritmo. Para isso, utilizou-se janelas de 2, 4 e 10 minutos
de duração. As figuras 39 e 40, apresentam a potência injetada na rede para o caso
base, sem utilização de baterias, e para os 3 tamanhos de janela.
Figura 39: Potência injetada na rede no caso base e para diferentes tamanhos de janela
da média móvel
Fonte: autor
Pode-se notar claramente como a média móvel atua como um filtro sobre a potência
injetada na rede, atenuando as flutuações de potência de curta duração. Na figura
40, em especial, nota-se que, quanto maior o tamanho da janela, maior é a suavização
da flutuação da potência injetada. Como consequência da utilização de uma janela
5.5. Soluçãoproposta 91
Figura 40: Potência injetada na rede no caso base e para diferentes tamanhos de janela
da média móvel, versão com zoom em um intervalo de aproximadamente 90 minutos
Fonte: autor
mais larga, nota-se que há um atraso maior na resposta da potência desejada em
relação a potência gerada pelos painéis fotovoltaicos (caso base), o que afeta a
evolução do estado de carga da bateria ao longo do dia, como será visto mais adiante.
As figuras 41 e 42 apresentam a potência despachada pela bateria em cada um dos
casos. Percebe-se que a bateria é carregada e descarregada várias vezes ao longo do
dia, dependendo da diferença entre 𝑃𝑑𝑒𝑠 e 𝑃𝑝𝑣, conforme equação 21. Na figura 41,
também é possível notar que a bateria apresenta uma potência de perdas essenci-
almente constante enquanto ela não se encontra em estado de carga ou descarga.
Essa potência é fornecida pela rede, e é responsável por manter o estado de carga
da bateria constante enquanto ela não carrega ou descarrega. Na figura 42, fica
evidente a diferença entre os ciclos de carga e descarga da bateria para cada um dos
casos analisados.
A seguir, analisa-se os resultados da utilização de diferentes tamanho de janela
quanto à redução na quantidade de operações dos reguladores de tensão e quanto
ao dimensionamento da bateria, isto é, quanto aos seus requisitos mínimos.
– Quanto à redução da quantidade de operações dos reguladores de tensão:
A figura 43 apresenta a evolução da quantidade de operações dos reguladores
92
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
Figura 41: Potência injetada nas baterias para diferentes tamanhos de janela da média
móvel
Perdas Constantes
Fonte: autor
de tensão ao longo do dia para o caso base e para os diferentes tamanhos de
janela móvel.
Percebe-se que todas as janelas reduzem a quantidade de operações dos regula-
dores de tensão. Porém, devido ao fato da janela móvel de 10 minutos possuir
uma filtragem mais acentuada em relação às outras, ela é a que mais reduz o
stress na operação dos reguladores de tensão, especificamente de 90 para 48
mudanças de tap.
– Quanto à especificação das baterias:
A figura 44 apresenta o estado de carga da bateria para cada um dos três casos
simulados. Nota-se que, ao longo da operação do algoritmo de controle, a perda
de energia armazenada na bateria ao fim do dia, dada pela diferença entre a
energia armazenada antes do acionamento do algoritmo e a energia armazenada
após o termino da operação do algoritmo, é maior quanto maior o tamanho
da janela móvel. Esse fato se dá devido as perdas de carga e descarga. Como
já verificado, quanto maior a duração da janela móvel, maior é a filtragem da
flutuação de curta duração da potência injetada na rede. Como consequência, a
potência injetada pela bateria apresenta uma maior variabilidade, quantificada
através do desvio padrão da potência despachada pela bateria ao longo da
5.5. Solução proposta 93
Figura 42: Potência injetada nas baterias para diferentes tamanhos de janela da média
móvel, ampliada
Fonte: autor
operação do algoritmo de controle, tabela 12, o que implica em maiores perdas
de carga e descarga, pois essas são função da potência despachada. Como
será visto mais adiante, as perdas da bateria se refletem diretamente no seu
dimensionamento.
Além disso, nota-se que no início da manhã, para o caso de uma janela móvel
de 10 minutos, a bateria é carregada por uma período de aproximadamente 2
horas. Isso ocorre pois, como no início do dia praticamente não há sombre-
amento, 𝑃𝑑𝑒𝑠 se mantém atrasada em relação a potência gerada pelos painéis
fotovoltaicos, o que implica em um carregamento da bateria. O mesmo efeito
ocorre ao fim do dia, conforme figura 39. Note que esse atraso também ocorre
para as janelas móveis de 2 e 4 minutos, porém, ele é menor, o que leva a
bateria a ser carregada com uma potência menor, em especial, com uma po-
tência menor que as suas perdas. Por esse motivo, a energia armazenada na
bateria para esses dois tamanhos de janela móvel já apresenta uma tendência
decrescente desde o início da operação do algoritmo.
A capacidade mínima necessária para uma bateria, desprezando-se a capaci-
dade máxima de descarga, nas condições simuladas, se dá pela diferença entre
a máxima e a mínima energia armazenada na mesma. A tabela 12 apresenta
a capacidade mínima de energia das baterias, Δ𝐸, para cada um dos casos.
Outros fatores importantes no dimensionamento das baterias são a capacidade má-
94
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
Figura 43: Número acumulado de operações dos reguladores de tensão no caso base e
para 3 diferentes tamanhos de janela móvel
Fonte: autor
xima de carga e descarga (ou potência nominal da bateria) e a taxa de rampa
máxima (ou taxa de varição máxima) da potência despachada pela bateria. Esses e
outros parâmetros comparativos também são apresentados na tabela 12.
Pode-se notar que, para a quantidade de cenários simulados, não há uma correlação
direta entre a potência máxima e o tamanho da janela móvel. O mesmo vale para a
taxa de variação máxima. Isso pode ser explicado pelo fato desses dois parâmetros
serem muito mais dependentes da característica da variação da curva de irradiação
do que do tamanho da janela em si, isto é, os requisitos de potência e de taxa de
rampa são impostos pela flutuação de irradiação mais severa no período simulado.
Uma única oscilação no nível de irradiação é capaz de alterar drasticamente os seus
valores.
Por outro lado, é possível notar uma correlação entre as perdas na bateria e o tama-
nho da janela da média móvel. Isso se deve ao fato de as perdas em energia serem
muito mais dependentes do comportamento médio, ou da distribuição da potência
despachada pela bateria ao longo dia, esse sim, determinado predominantemente
pelo tamanho da média móvel haja vista que, quanto maior o tamanho da janela,
maior é a filtragem da flutuação da geração dos painéis fotovoltaicos.
Do ponto de vista da redução da quantidade de operações dos reguladores de tensão,
a janela móvel de 10 minutos se apresenta como melhor alternativa, porém exige
uma bateria com maior capacidade. Em outras palavras, existe um compromisso
5.5. Solução proposta 95
Figura 44: Energia armazenada na bateria das 5:00hr - 19:00hr para diferentes tamanhos
da janela móvel
ΔE10min.
ΔE4min.
ΔE2min.
Fonte: autor
Tabela 12: Comparação entre a operação da bateria para os três tamanhos de janela
móvel
Duração da Janela da Média Móvel
Características da bateria 2 Min. 4 Min. 10 Min.
|Potência Máxima|(kW) 751,1 810,4 802,8
Taxa de Variação Máxima(kW/s) 91,43 89,94 88,91
Desvio Padrão da Potência Despachada(kW) 133,66 159,14 179,37
Perdas por ilhamento(kWh) 128,49 128,92 129,99
Perdas por carga e descarga(kWh) 77,96 103,42 133,68
Perdas Totais(kWh) 206,45 232,34 263,67
Δ𝐸 (Capacidade Mínima, kWh) 206,45 232,34 295,23
entre a redução da quantidade de operações dos reguladores de tensão e a capacidade
da bateria necessária para tal e a quantidade de energia perdida ao longo do dia
que, obviamente, deve ser reposta para o ciclo do dia seguinte.
Quanto à recarga da bateria para operação no próximo dia, uma das opções é fazê-la
durante a madrugada, uma vez que a demanda do sistema é normalmente reduzida
durante as primeiras horas do dia. Uma outra opção consiste no carregamento da
bateria durante o dia, através da utilização de uma fração da potência gerada pe-
96
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
los painéis fotovoltaicos, enquanto o controle se encontra ativado, o que também
reduziria a especificação da capacidade de carga da bateria. Isso pode ser realizado
através da adição de uma malha de controle do estado de carga da bateria no algo-
ritmo responsável pelo cálculo da nova potência a ser despachada. Essa modificação
é detalhadana subseção seguinte.
5.5.2 Média Móvel com controle de carga da bateria
o Implementação
A implementação da média móvel com controle de carga da bateria é semelhante
ao algoritmo anterior. A diferença é que uma malha de realimentação negativa é
adicionada, com uma referência, 𝐸𝑟𝑒𝑓 , para a energia armazenada na bateria. O
erro é, então, multiplicado por um ganho K, cujo valor é responsável por alterar a
velocidade com que o estado de carga da bateria é regulado. A saída do ganho K
modifica a última amostra da potência gerada pelos painéis fotovoltaicos a ser inse-
rida no cálculo da média móvel. A modificação da última amostra afeta, portanto,
o cálculo da média móvel por toda a duração da mesma. O diagrama de blocos da
figura 45 ilustra o novo algoritmo de controle.
Figura 45: Diagrama de blocos do algoritmo para suavização da flutuação da potência
gerada pelos painéis fotovoltaicos, com controle de estado de carga da bateria
t
τ
tτt-
+
-
Ebat[t]
+
-
Eref
+
-
K
Média Móvel
Ppv[t]
Pdes[t] Pbat[t]
Fonte: autor
É importante notar que o cálculo da potência despachada pelas baterias em um
instante t, começa com o cálculo do erro entre 𝐸𝑟𝑒𝑓 − 𝐸𝑏𝑎𝑡[𝑡]. A energia armazenada
na bateria no instante em questão, é obtida através da interface COM. O trecho
de código responsável pela implementação da malha de realimentação negativa é
acrescentado no método 𝑎𝑡𝑢𝑎𝑙𝑖𝑧𝑎_𝑃𝑏𝑎𝑡𝑒𝑟𝑖𝑎𝑠(). Para realizar a comparação com
o caso em que não há controle do estado de carga da bateria, é necessário que o
algoritmo seja mantido ativo pelo mesmo intervalo de tempo nos dois casos. Como
a média móvel com janela de 10 minutos apresentou o melhor desempenho em
relação à redução da quantidade de taps, porém o pior desempenho com relação às
5.5. Solução proposta 97
especificações da bateria, utilizou-se a mesma janela para avaliação do algoritmo
modificado. Além disso, inicialmente, foram escolhidos arbitrariamente 4 valores
para o ganho K: 0,5, 1, 3 e 5.
o Resultados
A figura 46 apresenta a evolução do estado de carga da bateria para os diferentes
ganhos K. É possível notar que, quanto maior o ganho, mais rápida é a resposta
do sistema quanto à regulação do estado de carga da bateria e, consequentemente,
menor é a diferença entre o estado de carga máximo e mínimo ao longo da operação
do algoritmo, bem como a quantidade de energia necessária para carregar a bateria
para a operação no dia seguinte.
Por outro lado, a medida em que o ganho K é aumentado, maior é a redução na
capacidade de suavização da potência injetada na rede resultante, conforme pode
ser verificado na figura 47. Ou seja, assim como no caso anterior, no algoritmo
de controle com regulação do estado de carga da bateria também há um conflito
entre a redução das especificações mínimas da bateria, agora para diferentes ganhos
K, e a quantidade de operações dos reguladores. Porém, para os casos simulados,
o aumento do stress dos reguladores de tensão em relação ao caso base (K=0) só
ocorre partir de um ganho K igual a 3, enquanto que a melhora das especificações
da bateria em termos de capacidade mínima ocorre para qualquer ganho K.
Figura 46: Energia armazenada na bateria com controle de estado de carga para uma
janela móvel de 10 minutos e diferentes ganhos K
Fonte: autor
98
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
Figura 47: Número de operações dos reguladores de tensão para uma média móvel de 10
minutos e controle de estado de carga da bateria para diferentes ganhos K
Fonte: autor
A tabela 13 resume as características da bateria necessária para cada um dos ganhos
K. Primeiramente, percebe-se que, assim como no caso anterior, não há variação
significativa na taxa de variação máxima do despacho da bateria. Portanto, esse
parâmetro não é utilizado na comparação das características da bateria para cada
um dos casos. Nota-se que, para os ganhos K igual a 3 e 5 há um aumento da
potência máxima injetada pela bateria. A grande vantagem ocorre na redução da
capacidade mínima de energia da bateria e na energia necessária para a preparação
para o próximo ciclo. Ambos são significativamente reduzidos para todos os valores
de ganho K, porém, à medida que o ganho K aumenta, a melhora nesses parâmetros
se reduz. Por exemplo, para um K = 0,5 , há uma redução de aproximadamente 59%
na capacidade mínima da bateria e de 78% na energia necessária para o próximo
ciclo em relação ao caso base (K=0). Já para um ganho K=1, há uma redução de
27% e de 52% para os mesmos parâmetros, respectivamente, em relação ao ganho
K=0,5.
A partir do ganho K=3, nota-se que a redução na capacidade mínima e na energia
necessária para operação no dia seguinte é bastante reduzida, enquanto que há um
aumento cada vez mais significativo na potência máxima da bateria.
Para uma melhor visualização do comportamento das características mínimas da bate-
ria, da energia necessária para a preparação da bateria para a operação no dia seguinte e
da quantidade de operações acumuladas dos reguladores de tensão, a figura 48 apresenta
5.5. Solução proposta 99
Tabela 13: Comparação entre a operação da bateria para uma janela móvel de 10 minutos
com diferentes valores de ganho K
Ganho K
Características da Bateria 0 0,5 1 3 5
Potência Máxima (kW) 802,85 795,37 793,83 838,64 904,22
Taxa de Variação Máxima (kW/s) 88,91 88,91 88,89 88,88 88,80
Δ𝐸 (Capacidade Mínima, kWh) 295,23 120,74 88,11 71,07 69,49
Energia para próximo ciclo (kWh) 263,67 57,87 27,52 6,99 3,62
a evolução desses parâmetros em função do ganho K, para os três tamanhos de janela
móvel. Essas curvas foram levantadas simulando-se o algoritmo de controle para ganhos
K de 0 à 6, em passos de 0,25 até o ganho K igual 2 e em passos de 0,5 até o ganho K
igual a 6. Nota-se que, de fato, a taxa de variação máxima da potência despachada pela
bateria pode ser considerada constante para cada janela e, tanto a capacidade mínima
quanto a energia necessária para recarregar a bateria para a operação no dia seguinte
caem exponencialmente com o ganho K, sendo que a segunda tende a zero, enquanto que
a primeira tende a 20,47 kWh, 35,61 kWh e 68,88 kWh para as janelas de 2,4 e 10 mi-
nutos, respectivamente. Além disso, nota-se que a partir de um ganho aproximadamente
entre 1 e 2, a máxima potência da bateria passa a crescer linearmente para todas as 3
janelas, e com uma maior inclinação para a janela de 10 minutos, atingindo uma potência
de cerca de 950kW para um ganho K igual a 6. Nota-se ainda que, de fato, o número
acumulado de operações dos reguladores de tensão aumenta a partir de um determinado
K, para todos as janelas. Portanto, assumindo que a redução da quantidade de opera-
ções dos reguladores de tensão é o fator dominante, um K igual a 2 e uma janela de 10
minutos se apresenta como a melhor opção, pois a quantidade de operações se mantém
igual a 48 e não há nenhum benefício adicional ao se aumentar o ganho K, uma vez que
a taxa de variação máxima é praticamente constante, a capacidade mínima e a energia
necessária para operação no dia seguinte também são aproximadamente constantes e a
potência máxima começa a crescer a partir desse ganho.
5.5.3 Comentários
Nessa aplicação, pode-se notar que a utilização de baterias em paralelo com geradores
fotovoltaicos apresenta-se como uma boa solução do ponto de vista técnico. Em dias em
que há uma grande variabilidade do recurso solar, os métodos de controle apresentados
podem reduzir significativamente o stress dos reguladores de tensão da rede. Porém, é
importante destacar alguns pontos:
o Preço das baterias:
Baterias de grande porte são equipamentos caros. Antes de se definir a sua uti-
lização, é necessário verificar outras alternativas, como por exemplo, um ajuste
100
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
Figura 48: Influência do ganho K nas especificações mínimas da bateria, na energia
necessáriapara preparar a bateria para a operação no dia seguinte e na quantidade de
operações acumulada dos reguladores de tensão
Fonte: autor
dinâmico das configurações dos reguladores de tensão da rede. Uma opção seria
afrouxar a banda regulada dos reguladores mais afetados pela flutuação da gera-
ção solar. Porém, há situações em que isso não é possível de ser realizado, como
em redes onde há implementação de Conservation Voltage Reduction (CVR) para
redução de demanda. Cada caso deve ser estudado individualmente.
Uma outra opção é utilizar as baterias para suavização da geração solar como um
objetivo secundário. Baterias de grande porte tem sido frequentemente utilizadas
em redes de distribuição para modificação do perfil de carga de transformadores de
subestações durante horários de pico com o objetivo de aumentar a vida útil desses
equipamentos. Essas mesmas baterias podem ser utilizadas com o objetivo proposto
nesse trabalho.
5.5. Solução proposta 101
o Bateria centralizada x Baterias distribuídas:
Na aplicação apresentada nesse trabalho, considerou-se que a bateria é conectada
na mesma barra da geração fotovoltaica. Porém, uma questão que surge é: e se
a bateria estiver conectada em um ponto qualquer da rede que não seja àquele
da geração fotovoltaica? O algoritmo de controle ainda é tecnicamente viável?
Como ele é afetado? O que é mais vantajoso? Manter uma bateria de grande
porte centralizada, com despacho controlado pela distribuidora ou um conjunto de
baterias distribuídas, sob o controle local de cada consumidor/gerador?
o Custo de um número elevado de operações dos reguladores de tensão:
Nesse trabalho, o objetivo primário foi a redução da quantidade de operações dos
reguladores de tensão, porém, quanto custa cada operação de um regulador? Como
o número de operações de um regulador pode ser convertido em aumento de sua
vida útil e, consequentemente, em uma economia financeira com o adiamento da
troca desses equipamentos? Uma análise econômica deve ser feita para verificar o
custo benefício dessa aplicação.
102
Capítulo 5. Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à
rede IEEE123 Barras
103
Conclusão
O desenvolvimento do presente estudo possibilitou o entendimento de parte do pro-
cesso de simulação do OpenDSS e como o usuário pode interferir nesse processo inserindo
elementos e algoritmos de controle personalizados. A flexibilidade apresentada por essa
ferramenta é essencial para a execução de novos tipos de estudos que têm surgido dentro
do ambiente das redes elétricas inteligentes. Além disso, os conceitos verificados foram
aplicados na mitigação de um problema mais realista, causado pela conexão de GD em
uma rede de distribuição. Esse trabalho se apresenta como um importante recurso para
o meio acadêmico, onde o OpenDSS tem adquirido grande espaço, devido a ausência de
materiais que expliquem em detalhes os assuntos abordados, com exemplos e disponibili-
zação completa do código fonte. E em especial, para a comunidade de usuários brasileiros,
hoje a segunda maior, devido ao fato do trabalho ter sido elaborado 100%, ou quase, em
português.
Dentro dos diversos modos de simulação computacional de sistemas de potência, as
simulações QSTS apresentam um excelente compromisso entre acurácia e velocidade em
grande parte dos estudos realizados em sistemas de distribuição como problemas de regula-
ção de tensão, análise de curto-circuito, fluxo de potência reverso, operação de reguladores
de tensão, entre outros. Nesse tipo de simulação, o modo de controle por tempo representa
mais fielmente o comportamento real dos sistemas simulados, porém exige dados com uma
maior resolução. Um exemplo na rede de testes IEEE 13 Barras foi utilizado para verificar
esses fatos. Dentro do processo de simulação do OpenDSS, a lista de controle (Control
Queue) se apresenta como um excelente meio de coordenação da atuação dos diferentes
elementos de controle existentes em um sistema. Além disso, a CtrlQueue Interface per-
mite que o usuário insira ações controle personalizadas, com atraso ou um certo tempo
de atuação, na lista de controle, permitindo o sincronismo entre os elementos de controle
internos ao software e externos, definidos pelo usuário. Um exemplo hipotético em que
consumidores podem comprar pacotes de energia diário foi elaborado e implementado na
rede de testes IEEE 8500 Barras. Como estudo final, foi realizada a análise da influência
de conexão de uma geração solar fotovoltaica considerando a alta variabilidade do recurso
104 Conclusão
solar na rede de testes IEEE 123 Barras quanto ao aumento do número de operações dos
reguladores de tensão presentes nessa rede. Métodos de mitigação desse problema foram
sugeridos, implementados e a sua eficácia foi comprovada.
Ao se penetrar um nível significativo de geração solar (o mesmo sendo válido para ge-
ração eólica) com alta variabilidade do recurso energético, verificou-se que a alta variação
da potência gerada em um curto intervalo de tempo se reflete diretamente em variações
de tensão de pequena duração que se distribui ao longo da rede de distribuição e pode
afetar o comportamento de equipamentos como reguladores de tensão, LTC’s e banco de
capacitores chaveados, levando a um aumento expressivo do número de operações desses
equipamentos e reduzindo a vida útil dos mesmos. Ao se utilizar uma bateria conectada
em paralelo com um gerador fotovoltaico e definindo a potência de despacho dessa bate-
ria através da diferença entre a potência gerada instantânea e uma referência, calculada
através da média móvel da potência gerada, verificou-se que é possível filtrar essa variação
de potência injetada na rede e, consequentemente, a variação de tensão de curta duração
que se propaga pela rede. Como resultado, os equipamentos responsáveis por regular a
tensão no sistema são pouco afetados pela alta variabilidade do recurso energético. As
especificações das baterias necessárias para esse tipo de aplicação depende do tamanho
da janela móvel utilizada para o cálculo da média e das perdas nas baterias. Ao se uti-
lizar uma malha de realimentação negativa tendo como referência o estado de carga da
bateria, é possível modificar o cálculo da média móvel de tal modo a se reduzir as suas
especificações e, consequentemente, os custos da implementação desse método.
O algoritmo de controle proposto se mostrou eficaz do ponto de vista técnico, porém
um projeto real deve envolver toda a engenharia financeira por trás dessa solução. As
baterias utilizadas nesse tipo de aplicação possuem um preço elevado. É preciso quan-
tificar qual o custo de uma operação dos elementos reguladores de tensão em termos de
redução de vida útil desses equipamentos e como isso pode ser convertido em economia
financeira quando se reduz a quantidade de operações desses equipamentos. Devido a
grande quantidade de variáveis envolvidas no problema, qualquer tentativa de definição
de regras gerais para solução do mesmo é extremamente arriscada. Cada rede analisada
corresponde a um caso específico, com problemas e características únicas.
Trabalhos Futuros
Além da inclusão da engenharia financeira por trás da implementação do método
sugerido, outros pontos relevantes devem ser abordados em trabalhos futuros:
o Comparação com outros métodos de mitigação:
É preciso comparar economicamente e tecnicamente o método apresentado com
outras opções, desde a simples realização de um ajuste dinâmico das configurações
105
dos reguladores de tensão, o uso de um controle baseado em taxa de rampa até o uso
de técnicas mais recentes como a função de corrente reativa dinâmica de inversores.
o Análise da variabilidade do recurso solar em um longo período:
As simulações realizadas nesse trabalho foram realizadas em um período de um dia
e foi utilizada apenas uma curva de irradiação e uma curva de carga. Em um estudo
mais completo, necessita-se utilizar dados reais de curva de carga e de irradiação da
região em estudo. Por exemplo, se a curva de irradiaçãoapresentar alta variabilidade
em apenas poucos dias do ano, talvez não seja vantajoso investir em uma solução
desse tipo. Eventualmente deve-se utilizar dados probabilísticos para um estudo
mais realista.
106 Conclusão
107
Referências
BASS, R. B. et al. Determining the power and energy capacities of a battery energy
storage system to accommodate high photovoltaic penetration on a distribution feeder.
IEEE Power and Energy Technology Systems Journal, 2016. v. 3, n. 3, p.
119–127, Sept 2016.
BEYER, H. G. et al. Spatial and temporal characteristics of short term fluctuations
in solar radiation for pv-plant applications. In: . Tenth E.C. Photovoltaic
Solar Energy Conference: Proceedings of the International Conference, held
at Lisbon, Portugal, 8–12 April 1991. Dordrecht: Springer Netherlands, 1991. p.
453–456. ISBN 978-94-011-3622-8. Disponível em: <http://dx.doi.org/10.1007/978-94-
011-3622-8 116>.
BIRCHFIELD, A. Python to OpenDSS Interface for Modeling Control Systems.
[S.l.], July 2015. Disponível em: <https://sourceforge.net/p/electricdss/code/HEAD-
/tree/trunk/Distrib/Doc/Python-to-OpenDSS%20Control%20Interface.pdf>.
BOLLEN, M. H.; HASSAN, F. Integration of Distributed Generation in the
Power System. [S.l.]: Wiley-IEEE Press, 2012. 527 p.
C84.1, A. S. American National Standard for Electric Power Systems and
Equipment - Voltage Ratings (60 Herz). 1300 North 17th Street, Rosslyn, VA
22209: National Electrical Manufacturers Association, 2006.
CHAMANA, M. et al. Dynamic ramp rate control for voltage regulation in distribution
systems with high penetration photovoltaic power generations. In: 2014 IEEE PES
General Meeting | Conference Exposition. [S.l.: s.n.], 2014. p. 1–5. ISSN 1932-5517.
CHANHOM, P.; SIRISUKPRASERT, S.; HATTI, N. A new mitigation strategy
for photovoltaic power fluctuation using the hierarchical simple moving average. In:
Intelligent Energy Systems (IWIES), 2013 IEEE International Workshop on.
[S.l.: s.n.], 2013. p. 28–33.
CHIRAPONGSANANURAK, P. et al. Voltage regulation in distribution circuits with
wind power. In: 2012 IEEE Power and Energy Society General Meeting. [S.l.:
s.n.], 2012. p. 1–8. ISSN 1932-5517.
CHOW, C. W. et al. Intra-hour forecasting with a total sky imager at the {UC} san
diego solar energy testbed. Solar Energy, 2011. v. 85, n. 11, p. 2881 – 2893, 2011.
http://dx.doi.org/10.1007/978-94-011-3622-8_116
http://dx.doi.org/10.1007/978-94-011-3622-8_116
108 Referências
ISSN 0038-092X. Disponível em: <http://www.sciencedirect.com/science/article/pii-
/S0038092X11002982>.
DELPHI - Windows, Mac OS X, iOS, Android | Embarcadero. https://www.
embarcadero.com/products/delphi. (Accessado em 06/12/2016).
DUGAN, R. C. OpenDSS Manual. Março 2016. https://sourceforge.net/p/
electricdss/code/HEAD/tree/trunk/Distrib/Doc/OpenDSSManual.pdf. (Accessado
em 06/12/2016).
DUGAN, R. C.; MCDERMOTT, T. E. An open source platform for collaborating on
smart grid research. In: 2011 IEEE Power and Energy Society General Meeting.
[S.l.: s.n.], 2011. p. 1–7. ISSN 1932-5517.
DUGAN, R. C.; MONTENEGRO, D. How to Speed Up your co-simulation
using OpenDSS COM interface. Outubro 2015. https://sourceforge.net/p/
electricdss/code/HEAD/tree/trunk/Distrib/Doc/COM%20Speed%20Comparison.pdf.
(Accessado em 06/12/2016).
EPRI. OpenDSS Storage Element and Storage Controller Element. [S.l.], March
2011. Disponível em: <https://sourceforge.net/p/electricdss/code/HEAD/tree/trunk-
/Distrib/Doc/OpenDSS%20STORAGE%20Element.pdf>.
. OpenDSS COM Documentation - CtrlQueue Interface. [S.l.], March
2015. Disponível em: <https://sourceforge.net/p/electricdss/code/HEAD/tree/trunk-
/Distrib/Doc/OpenDSS%20CtrlQueue%20%20Interface.pdf>.
. SourceForge @ONLINE. 2016. Disponível em: <https://sourceforge.net/p-
/electricdss/code/HEAD/tree/trunk/Distrib/Examples/Loadshapes/1-day-1-s-Solar-2-
.csv>.
JEWELL, W.; RAMAKUMAR, R. The effects of moving clouds on electric utilities with
dispersed photovoltaic generation. IEEE Power Engineering Review, 1987. PER-7,
n. 12, p. 31–32, Dec 1987. ISSN 0272-1724.
K PORTER, C. M.; WEISBURGER, M. Reglamento para la interconexión de
generadores al sistema de transmisión y subtransmisión eléctrica para el
programa de medición neta. [S.l.], Junho 2013. 31 p.
KEDAR, S. Database Management System. [S.l.]: Technical Publications, 2011.
KLIMA, K.; APT, J. Geographic smoothing of solar pv: results from gujarat.
Environmental Research Letters, 2015. v. 10, n. 10, p. 104001, 2015. Disponível em:
<http://stacks.iop.org/1748-9326/10/i=10/a=104001>.
LAM, R. K.; YEH, H.-G. Pv ramp limiting controls with adaptive smoothing
filter through a battery energy storage system. In: Green Energy and Systems
Conference (IGESC), 2014 IEEE. [S.l.: s.n.], 2014. p. 55–60.
LIU, X. et al. Coordinated control of distributed energy storage system with tap changer
transformers for voltage rise mitigation under high photovoltaic penetration. IEEE
Transactions on Smart Grid, 2012. v. 3, n. 2, p. 897–906, June 2012. ISSN 1949-3053.
http://www.sciencedirect.com/science/article/pii/S0038092X11002982
http://www.sciencedirect.com/science/article/pii/S0038092X11002982
https://www.embarcadero.com/products/delphi
https://www.embarcadero.com/products/delphi
https://sourceforge.net/p/electricdss/code/HEAD/tree/trunk/Distrib/Doc/OpenDSSManual.pdf
https://sourceforge.net/p/electricdss/code/HEAD/tree/trunk/Distrib/Doc/OpenDSSManual.pdf
https://sourceforge.net/p/electricdss/code/HEAD/tree/trunk/Distrib/Doc/COM%20Speed%20Comparison.pdf
https://sourceforge.net/p/electricdss/code/HEAD/tree/trunk/Distrib/Doc/COM%20Speed%20Comparison.pdf
http://stacks.iop.org/1748-9326/10/i=10/a=104001
Referências 109
MAMMOLI, A. et al. Low-cost solar micro-forecasts for pv smoothing. In: Technologies
for Sustainability (SusTech), 2013 1st IEEE Conference on. [S.l.: s.n.], 2013. p.
238–243.
MARCOS, J. et al. Smoothing of pv power fluctuations by geographical dispersion.
Progress in Photovoltaics: Research and Applications, 2012. John Wiley
and Sons, Ltd, v. 20, n. 2, p. 226–237, 2012. ISSN 1099-159X. Disponível em:
<http://dx.doi.org/10.1002/pip.1127>.
. Storage requirements for pv power ramp-rate control. Solar Energy, 2014.
v. 99, p. 28 – 35, 2014. ISSN 0038-092X. Disponível em: <http://www.sciencedirect-
.com/science/article/pii/S0038092X13004672>.
MILANO, F. Power System Modelling and Scripting. London: Springer, 2010.
14 p.
MILLER, L. et al. White paper: Electric Distribution System Simulation and
Analysis Tools Status and Research Gaps for Integration of Renewables and
Electric Vehicles. [S.l.], Abril 2013. 10-14 p. Disponível em: <http://uc-ciee.org-
/downloads/Task%201%201%20White%20Paper.pdf>.
MONTENEGRO, D. Direct Connection Shared Library(DLL) for OpenDSS.
Julho 2016. https://sourceforge.net/p/electricdss/code/HEAD/tree/trunk/
Distrib/Doc/OpenDSS_Direct_DLL.pdf. (Accessado em 06/12/2016).
MOUMOUNI, Y.; BAGHZOUZ, Y.; BOEHM, R. F. Power smoothing of a commercial-
size photovoltaic system by an energy storage system. In: 2014 16th International
Conference on Harmonics and Quality of Power (ICHQP). [S.l.: s.n.], 2014. p.
640–644. ISSN 1540-6008.
OTANI, K.; MINOWA, J.; KUROKAWA, K. Study on areal solar irradiance for
analyzing areally-totalized pv systems. Solar Energy Materials and Solar
Cells, 1997. v. 47, n. 1, p. 281 – 288, 1997. ISSN 0927-0248. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0927024897000500>.
PORTER, C. M. K.; WEISBURGER, M. Review of International Experience
Integrating Variable Renewable Energy Generation. [S.l.], 2007.
RADATZ, P. R. R. d. F. Modelos avançados de análise de redes elétricas
inteligentes utilizando o software OpenDSS. 191 p. Monografia (Trabalho de
Formatura) — Escola Politécnica da Universidade de São Paulo, São Paulo, 2015.
SMITH, J. W.; DUGAN, R.; SUNDERMAN, W. Distribution modeling and analysis of
high penetration pv. In: 2011 IEEE Power and Energy Society General Meeting.
[S.l.: s.n.], 2011. p. 1–7. ISSN 1932-5517.
SOLAR, M. E. Homepage @ONLINE. 2016. Disponívelem: <http://www-
.mitsubishielectricsolar.com/images/uploads/documents/specs/MLE 270HD.pdf>.
http://dx.doi.org/10.1002/pip.1127
http://www.sciencedirect.com/science/article/pii/S0038092X13004672
http://www.sciencedirect.com/science/article/pii/S0038092X13004672
http://uc-ciee.org/downloads/Task%201%201%20White%20Paper.pdf
http://uc-ciee.org/downloads/Task%201%201%20White%20Paper.pdf
https://sourceforge.net/p/electricdss/code/HEAD/tree/trunk/Distrib/Doc/OpenDSS_Direct_DLL.pdf
https://sourceforge.net/p/electricdss/code/HEAD/tree/trunk/Distrib/Doc/OpenDSS_Direct_DLL.pdf
http://www.sciencedirect.com/science/article/pii/S0927024897000500
http://www.mitsubishielectricsolar.com/images/uploads/documents/specs/MLE_270HD.pdf
http://www.mitsubishielectricsolar.com/images/uploads/documents/specs/MLE_270HD.pdf
110 Referências
111
Apêndices
112
113
APÊNDICE A
Verificação do processo de simulação
do OpenDSS
O objetivo desse apêndice é verificar o funcionamento do processo de simulação do
OpenDSS com elementos de controle no modo estático e temporal. Por simplicidade, em
ambos os casos a rede utilizada para simulação foi a IEEE13 Barras. Para executar essa
verificação, em cada modo de controle foram realizadas duas simulações, uma na versão
standalone do OpenDSS e a outra pela interface COM através de um código escrito em
Python. Em ambos os modos de controle, a diferença entre os códigos são pontuais.
Por esse motivo, os códigos serão apresentados por completo apenas na verificação do
modo de controle estático. No modo de controle temporal, serão apresentadas apenas as
modificações em relação ao primeiro.
A.1 Controle no modo estático
O código que descreve a rede IEEE13 Barras modelada no OpenDSS se encontra
abaixo, dividido em categorias:
o Equivalente de Thévenin:� �� �
Clear
new c i r c u i t . IEEE13Nodeckt
~ basekv=115 pu=1.0001 phases=3 bus1=SourceBus
~ Angle=30 MVAsc3=20000 MVASC1=21000
 	� �
114 APÊNDICE A. Verificação do processo de simulação do OpenDSS
o Transformadores e Reguladores de Tensão:� �� �
// Transformador da Subestacao
New Transformer . Sub Phases=3 Windings=2 XHL=(8 1000 /)
~ wdg=1 bus=SourceBus conn=de l t a kv=115 kva=5000 %r=(.5 1000 /)
XHT=4
~ wdg=2 bus=650 conn=wye kv=4.16 kva=5000 %r=(.5 1000 /)
XLT=4
// Reguladores de Tensao a s s o c i ado s a cada f a s e do secundar io do
transformador da subestacao
New Transformer . Reg1 phases=1 XHL=0.01 kVAs=[1666 1666 ]
~ Buses =[650.1 RG60 . 1 ] kVs =[2.4 2 . 4 ] %LoadLoss=0.01
~ new r e g c o n t r o l . Reg1 trans fo rmer=Reg1 winding=2 vreg=122 band=2
p t r a t i o =20 ctprim=700 R=3 X=9 delay = 10
New Transformer . Reg2 phases=1 XHL=0.01 kVAs=[1666 1666 ]
~ Buses =[650.2 RG60 . 2 ] kVs =[2.4 2 . 4 ] %LoadLoss=0.01
new r e g c o n t r o l . Reg2 trans fo rmer=Reg2 winding=2 vreg=122 band=2
p t r a t i o =20 ctprim=700 R=3 X=9 delay =15
New Transformer . Reg3 phases=1 XHL=0.01 kVAs=[1666 1666 ]
~ Buses =[650.3 RG60 . 3 ] kVs =[2.4 2 . 4 ] %LoadLoss=0.01
new r e g c o n t r o l . Reg3 trans fo rmer=Reg3 winding=2 vreg=122 band=2
p t r a t i o =20 ctprim=700 R=3 X=9 delay=20
// Transformador de D i s t r i b u i c a o
New Transformer .XFM1 Phases=3 Windings=2 XHL=2
~ wdg=1 bus=633 conn=Wye kv=4.16 kva=500 %r=.55 XHT=1
~ wdg=2 bus=634 conn=Wye kv=0.480 kva=500 %r=.55 XLT=1
 	� �
o Códigos de Linhas:� �� �
// Codigos de Linhas
r e d i r e c t IEEELineCodes . dss //Compila um outro arquivo . dss que
desc reve mais a lguns cod igos de l i nha
New l i n e c o d e . mtx601 nphases=3 BaseFreq=60
~ rmatr ix = (0 .3465 | 0 .1560 0 .3375 | 0 .1580 0 .1535 0 .3414 )
~ xmatrix = (1 .0179 | 0 .5017 1 .0478 | 0 .4236 0 .3849 1 .0348 )
~ un i t s=mi
New l i n e c o d e . mtx602 nphases=3 BaseFreq=60
~ rmatr ix = (0 .7526 | 0 .1580 0 .7475 | 0 .1560 0 .1535 0 .7436 )
~ xmatrix = (1 .1814 | 0 .4236 1 .1983 | 0 .5017 0 .3849 1 .2112 )
~ un i t s=mi
New l i n e c o d e . mtx603 nphases=2 BaseFreq=60
~ rmatr ix = (1 .3238 | 0 .2066 1 .3294 )
A.1. Controle no modo estático 115
~ xmatrix = (1 .3569 | 0 .4591 1 .3471 )
~ un i t s=mi
New l i n e c o d e . mtx604 nphases=2 BaseFreq=60
~ rmatr ix = (1 .3238 | 0 .2066 1 .3294 )
~ xmatrix = (1 .3569 | 0 .4591 1 .3471 )
~ un i t s=mi
New l i n e c o d e . mtx605 nphases=1 BaseFreq=60
~ rmatr ix = (1 .3292 )
~ xmatrix = (1 .3475 )
~ un i t s=mi
New Linecode . mtx606 nphases=3 Units=mi
~ Rmatrix =[0.791721 | 0 . 318476 0.781649 | 0 . 28345 0.318476 0.791721
]
~ Xmatrix =[0.438352 |0 . 0276838 0.396697 | −0.0184204 0.0276838
0.438352 ]
~ Cmatrix =[383.948 | 0 383 .948 | 0 0 383.948 ]
New l i n e c o d e . mtx607 nphases=1 BaseFreq=60
~ rmatr ix = (1 .3425 )
~ xmatrix = (0 .5124 )
~ cmatrix = [ 2 3 6 ]
~ un i t s=mi
 	� �
o Linhas e Switches:� �� �
// Linhas
New Line .650632 Phases=3 Bus1=RG60 . 1 . 2 . 3 Bus2 =632 .1 .2 .3 LineCode
=mtx601 Length=2000 un i t s=f t
New Line .632670 Phases=3 Bus1 =632 .1 .2 .3 Bus2 =670 .1 .2 .3 LineCode
=mtx601 Length=667 un i t s=f t
New Line .670671 Phases=3 Bus1 =670 .1 .2 .3 Bus2 =671 .1 .2 .3 LineCode
=mtx601 Length=1333 un i t s=f t
New Line .671680 Phases=3 Bus1 =671 .1 .2 .3 Bus2 =680 .1 .2 .3 LineCode
=mtx601 Length=1000 un i t s=f t
New Line .632633 Phases=3 Bus1 =632 .1 .2 .3 Bus2 =633 .1 .2 .3 LineCode
=mtx602 Length=500 un i t s=f t
New Line .632645 Phases=2 Bus1 =632.3.2 Bus2 =645.3.2 LineCode
=mtx603 Length=500 un i t s=f t
New Line .645646 Phases=2 Bus1 =645.3.2 Bus2 =646.3.2 LineCode
=mtx603 Length=300 un i t s=f t
New Line .692675 Phases=3 Bus1 =692 .1 .2 .3 Bus2 =675 .1 .2 .3 LineCode
=mtx606 Length=500 un i t s=f t
New Line .671684 Phases=2 Bus1 =671.1.3 Bus2 =684.1.3 LineCode
=mtx604 Length=300 un i t s=f t
New Line .684611 Phases=1 Bus1=684.3 Bus2=611.3 LineCode
=mtx605 Length=300 un i t s=f t
New Line .684652 Phases=1 Bus1=684.1 Bus2=652.1 LineCode
=mtx607 Length=800 un i t s=f t
116 APÊNDICE A. Verificação do processo de simulação do OpenDSS
// Switches
New Line .671692 Phases=3 Bus1=671 Bus2=692 Switch=y r1=1e−4 r0
=1e−4 x1=0.000 x0=0.000 c1 =0.000 c0 =0.000
 	� �
o Comandos Adicionais e Modo de Simulação:� �� �
// Calculo das bases de tensão
Set Voltagebases =[115 , 4 . 16 , . 4 8 ]
ca l cv
// Modo de c o n t r o l e e de solução
Set controlmode=s t a t i c
Set mode=snapshot
Solve
 	� �
Como pode-se notar, o modo de solução escolhido foi o snapshot, portanto, será re-
solvido apenas um fluxo de potência. O código elaborado em Python para verificar o
funcionamento do modo de controle estático se encontra abaixo:� �� �
### # −*− coding : i so −8859−15 −*−
__author__ = ’ Celso Rocha ’
import os
import win32com . c l i e n t
import csv
#I n i c i a l i z a n d o o OpenDSS
try :
DSSObj = win32com . c l i e n t . Dispatch ( " OpenDSSEngine . DSS" )
except :
p r i n t " Houve algum problema na i n i c i a l i z a ç ã o da i n t e r f a c e COM"
r a i s e SystemExit
#Atribuindo a ta lho s a algumas i n t e r f a c e s
DSSText = DSSObj . Text #I n t e r f a c e de texto
DSSCircuit = DSSObj . Ac t i v eC i r cu i t
DSSSolution = DSSCircuit . So lu t i on
DSSCtrlQueue = DSSCircuit . CtrlQueue
DSSElem = DSSCircuit . ActiveCktElement
DSSBus = DSSCircuit . ActiveBus
DSSText .Command = r " Compile ’C: \ Users \User\Google Drive \ Celso \TCC_Celso\
Simulacoes \Estudo\COM_interface\13 Bus_control_queue_static \IEEE13Nodeckt
. dss ’ "
Or i g ina lS t ep s = 1
my_ControlQueue = open ( " ControlQueue . txt " , "w" )
A.1. Controle no modo estático 117
f o r stepNumber in range ( Or i g ina lS t ep s ) :
hora = DSSSolution . Hour
segundo = DSSSolution . Seconds
#Solução com c o n t r o l e s
i t e r a c a o = 1
DSSSolution . In i tSnap ( )
whi l e not DSSSolution . ControlActionsDone :
DSSSolution . SolveNoControl ( )
DSSSolution . SampleControlDevices ( )
DSSText .Command = "Show contro lqueue "
current_control_queue = csv . reader ( open ( ’ IEEE13Nodeckt_ControlQueue
. csv ’ ) )
my_ControlQueue . wr i t e ( ’ Control Queue na Hora ’ + s t r ( hora ) + ’ ,
Segundo ’ + s t r ( segundo ) + " e i t e r aç ã o de c o n t r o l e " + s t r ( i t e r a c a o ) +
" : \ n " )
i f DSSCtrlQueue . QueueSize == 0 : #pror i edade que re to rna a
quantidade de ações na CtrlQueue
my_ControlQueue . wr i t e ( "Não há ações de c o n t r o l e n e c e s s á r i a s \n\n
" )
break
e l s e :
i=0
f o r row in current_control_queue : #l e i t u r a da L i s t a de
Contro le
i f i == 0 :
my_ControlQueue . wr i t e ( ’ ’ +row [0 ]+ row [1 ]+ row [ 2 ] +
row [ 3 ] + row [ 4 ] + row [ 5 ] + ’ \n ’ )
e l s e :
my_ControlQueue . wr i t e ( " "+row [ 0 ] + " "+ row
[1 ]+ " " + row [ 2 ] + " " + row [3 ]+ " " + row [4 ]+ " "
+ row [ 5 ] + " \n " )
i =i+1
DSSSolution . DoControlActions ( ) #Empurra pra f o r a da Control
Queue a pr ime i ra ação da l i s t a
#Repete depo i s do DoControlActions para ver se as ações foram
executadas
DSSText .Command = "Show contro lqueue "
current_control_queue = csv . reader ( open ( ’ IEEE13Nodeckt_ControlQueue
. csv ’ ) )
118 APÊNDICE A. Verificação do processo de simulação do OpenDSS
my_ControlQueue . wr i t e ( ’ Control Queue após a execuçao das ações
pendentes : \ n ’ )
i f DSSCtrlQueue . QueueSize == 0 :
my_ControlQueue . wr i t e ( " Todas as ações foram executadas na
últ ima execução de ações pendentes \n\n" )
e l s e :
i = 0
f o r row in current_control_queue :
i f i == 0 :
my_ControlQueue . wr i t e ( " "+row [ 0 ] + row [ 1 ] + row [ 2 ]
+ row [ 3 ] + row [ 4 ] + row [ 5 ] + " \n " )
e l s e :
my_ControlQueue . wr i t e ( " "+row [ 0 ] + " " + row
[ 1 ] + " " + row [ 2 ] + " " + row [ 3 ] + " " + row [ 4 ] + "
" + row [ 5 ] + " \n " )
i=i+1
i t e r a c a o +=1
i f i t e r a c a o >= DSSSolution . MaxContro l I terat ions :
p r i n t " número máximo de i t e r a c o e s de c o n t r o l e excedido "
i t e r a c a o = "Maximo excedido "
break
DSSSolution . FinishTimeStep ( )
 	� �
O algoritmo basicamente executa todos os passos do diagrama de blocos do processo
de simulação do OpenDSS, descritos na figura 10 do Capítulo 3, porém, após os blocos
onde se realiza a amostragem dos dispositivos de controle e onde se executa a primeira
ação pendente, a lista de controle é lida, figura 49, e o seu conteúdo é armazenado em um
arquivo *.txt.
Desse modo, é possível mapear quais foram as ações de controle executadas pelo
OpenDSS via interface COM de acordo com o modo de controle utilizado e compará-las
com os resultados obtidos pela simulação na versão standalone.
A figura 50 mostra o registro de eventos após a simulação do fluxo de potência no modo
snapshot com controle no modo estático. Percebe-se que, ao todo, houve 7 mudanças de
tap, sendo 2 no regulador reg1, 3 no regulador reg2 e 2 no regulador reg3 e todas as ações
de controle foram realizadas no mesmo passo de tempo, hora=0, segundo=0. Além disso,
nota-se que a sequência em que as mudanças nos taps foram realizadas estão de acordo
com o valor do parâmetro delay definido para cada elemento regcontrol. No caso, como
os atrasos dos reguladores 1,2 e 3 são 10,15 e 20, respectivamente, e o modo de controle
selecionado é o estático, o loop de controle permanece iterando até que o primeiro elemento
da lista de controle tenha sua variável controlada, no caso, tensão na fase A, dentro da
banda desejada. Quando isso ocorre, o elemento seguinte da lista de controle passa a
A.1. Controle no modo estático 119
Figura 49: Diagrama de blocos do processo de simulação do OpenDSS evidenciando as
funções utilizadas em cada etapa e os pontos de medição da lista de controle
Inicia
a solução
de uma 
série 
temporal
Inicializa a solução
no modo Snapshot
Resolve o Fluxo de 
Potência sem 
Controles
Lista
de Controles
Limpa?
Amostra os dispositivos
de controle internos e
adiciona ações à lista de 
controle
Executa ações 
pendentes da 
lista de controle
Amostra monitores 
e outras ações
de rotina
Salva monitores
e conclui simulação
Último 
passo de
tempo?
Incrementa um
passo de tempo
Loop de 
Controle
Não
Sim
Sim
Não
Leitura e Armazenamento
da Lista de Controle
for stepNumber in range(OriginalSteps):
DSSSolution.InitSnap()
DSSSolution.SolveNoControl()
DSSSolution.SampleControlDevices()
if DSSCtrlQueue.QueueSize ==0:
DSSSolution.DoControlActions()
DSSSolution.FinishTimeStep()
while not DSSSolution.ControlActionsDone: 
Fonte: adaptado de (BIRCHFIELD, 2015)
delegar ações até que sua variável de controle também fique dentro da banda, e assim
sucessivamente.
A figura 51 mostra o arquivo de saída do código em Python, motrando a evolução
da lista de controle ao longo do processo de simulação. Nota-se que, a cada iteração
de controle, a primeira ação da lista é despachada após a execução da função DSSSolu-
tion.DoControlActions(). Na figura 51, o tap final dos reguladores a cada ação de controle
também foram evidenciados de modo a comparar o resultado da simulação através da in-
terface COM com o resultado da versão standalone do software.
120 APÊNDICE A. Verificação do processo de simulação do OpenDSS
Figura 50: Registro de Eventos do OpenDSS no modo de controle estático
Fonte: autor
A.2 Controle no modo temporal
Para realizar a verificação do funcionamento do loop de controle no modo temporal,
algumas alterações foram feitas tanto no código no formato *.dss quanto no código escrito
em Python. Os delays dos reguladores 1,2 e 3 foram alterados para 3, 6 e 9 segundos
respectivamente, para reduzir a quantidade de iterações até a convergência dos elementos
de controle. As outras alterações seguem abaixo:
o No arquivo *.dss:
Quanto ao método de solução, o modo agora utilizado é o diário e, quanto ao
controle, o modo agora é o temporal. Ambas as alterações foram realizadas no
arquivo *.dss. O passo de tempo passou a ser de 1 segundo e o número de passos
escolhidos para a simulação foi de 30, isto é, apenas os primeiros 30 segundos da
simulação diária são simulados.� �� �
// Al t e raçõe s no arquivo . dss
Set mode = d a i l y
Set s t e p s i z e = 1 s
Set number=30
Set controlmode = time
 	� �
o No código em Python:
Houve um alteração em relação à variável OriginalSteps, que determina a quantidade
de iterações do processo de simulação do OpenDSS. No modo snapshot, ela foi
feita igual a 1, porém, no modo diário, ela deve ser igual ao número de passos
de tempo de simulação que se deseja simular. No caso, ela deve ser igual a 30,
valor que pode ser lido pela interface Solution, através do objeto Number. Além
disso, como ao todo serão realizados no mínimo 30 fluxos de potência, os resultados
A.2. Controle no modo temporal 121
Figura 51: Saída da simulação através da interface COM
Control Queue na Hora 0, Segundo 0.0 e iteração de controle 1:
 Handle Hour Sec ActionCode ProxyDevRef Device
 1 0 10 0 0 reg1 
 2 0 15 0 0 reg2 
 3 0 20 0 0 reg3 
 Control Queue após a execuçao das ações pendentes:
 Handle Hour Sec ActionCode ProxyDevRef Device
 2 0 15 0 0 reg2 
 3 0 20 0 0 reg3 
Control Queue na Hora 0, Segundo 0.0 e iteração de controle 2:
 Handle Hour Sec ActionCode ProxyDevRef Device
 4 0 10 0 0 reg1 
 2 0 15 0 0 reg2 
 3 0 20 0 0 reg3 
 Control Queue após a execuçao das ações pendentes:
 Handle Hour Sec ActionCode ProxyDevRef Device
 2 0 15 0 0 reg2 
 3 0 20 0 0 reg3 
Control Queue na Hora 0, Segundo 0.0 e iteração de controle 3:
 Handle Hour Sec ActionCode ProxyDevRef Device
 2 0 15 0 0 reg2 
 3 0 20 0 0 reg3 
 Control Queue após a execuçao das ações pendentes:
 Handle Hour Sec ActionCode ProxyDevRef Device
 3 0 20 0 0 reg3 
Control Queue na Hora 0, Segundo 0.0 e iteração de controle 4:
 Handle Hour Sec ActionCode ProxyDevRef Device
 50 15 0 0 reg2 
 3 0 20 0 0 reg3 
 Control Queue após a execuçao das ações pendentes:
 Handle Hour Sec ActionCode ProxyDevRef Device
 3 0 20 0 0 reg3 
Control Queue na Hora 0, Segundo 0.0 e iteração de controle 5:
 Handle Hour Sec ActionCode ProxyDevRef Device
 6 0 15 0 0 reg2 
 3 0 20 0 0 reg3 
 Control Queue após a execuçao das ações pendentes:
 Handle Hour Sec ActionCode ProxyDevRef Device
 3 0 20 0 0 reg3 
Control Queue na Hora 0, Segundo 0.0 e iteração de controle 6:
 Handle Hour Sec ActionCode ProxyDevRef Device
 3 0 20 0 0 reg3 
 Control Queue após a execuçao das ações pendentes:
 Todas as ações foram executadas na última execução de ações pendentes 
Control Queue na Hora 0, Segundo 0.0 e iteração de controle 7:
 Handle Hour Sec ActionCode ProxyDevRef Device
 7 0 20 0 0 reg3 
 Control Queue após a execuçao das ações pendentes:
 Todas as ações foram executadas na última execução de ações pendentes 
Control Queue na Hora 0, Segundo 0.0 e iteração de controle 8:
Não há ações de controle necessárias
{
Tap do regulador 1 = 1.04375
{
Tap do regulador 1 = 1.05625
Tap do regulador 2 = 1.03125
{
{
Tap do regulador 2 = 1.0375
Tap do regulador 2 = 1.04375
{
{
Tap do regulador 3 = 1.04375
{
Tap do regulador 3 = 1.05625
{
Fim do Loop de Controle
Fonte: autor
dessa simulação a partir do código em Python serão apresentados em um registro de
eventos semelhante ao apresentado na versão standalone do OpenDSS. O registro
de eventos é lido ao final do último passo de tempo da simulação e armazenado em
um .txt.� �� �
# Alte raçõe s no código em Python :
Or i g ina lS t ep s = DSSSolution . Number
DSSSolutionNumber = 1
122 APÊNDICE A. Verificação do processo de simulação do OpenDSS
i f stepNumber == Or ig ina lS t ep s − 1 :
my\_eventLog . wr i t e ( " EventLog a f t e r " + s t r ( Or i g ina lS t ep s ) + "
seconds : \n " )
f o r i in range ( l en ( DSSSolution . EventLog ) ) :
event = DSSSolution . EventLog [ i ]
my\_eventLog . wr i t e ( event + " \n " )
 	� �
De maneira igual à realizada para verificar o modo de controle estático, a figura 52
apresenta o registro dos eventos após a simulação na versão standalone do OpenDSS.
Pode-se notar claramente que, para cada passo de simulação, houve apenas 1 iteração
de controle, pois agora a variável tapdelay, descrita na Tabela 1, Capítulo 3, é levada
em consideração e faz com que a cada mudança de tap seja necessário um intervalo de
2 segundos para que haja uma nova alteração. Como consequência, nota-se que nesse
modo de controle as ações de controle ocorrem intercaladas entre si, e não mais na ordem
especificada unicamente pela variável delay. A variável delay é utilizada somente para
determinar o atraso até que ocorra a primeira mudança de tap de cada regulador. A
figura 53 apresenta o resultado do registro de eventos pelo código elaborado em Python.
Nota-se que as ações realizados foram idênticas às ações realizadas pela versão standalone.
A única diferença diz respeito ao início da simulação e o contador de iterações de controle,
pois, aparentemente, quando o modo de solução diário é simulado a partir da interface
COM, o instante inicial corresponde a 00:00:00. Além disso, o contador de iterações de
controle inicia em 0, ao invés de 1.
A.3 Comentários
Um aspecto importante a se notar é que no modo de controle estático, os taps dos
reguladores convergiram para 1.05625, 1.04375 e 1.05625 para os reguladores reg1, reg2
e reg3, respectivamente, enquanto que na simulação no modo de controle temporal, a
solução final foi 1.05625, 1.0375 e 1.05625, ou seja, o tap do regulador reg2 converge para
um valor diferente dependendo do modo de simulação. Isso mostra a importância de saber
qual tipo de controle utilizar em cada tipo de simulação. Em uma rede mais complexa,
com mais elementos de controle interagindo entre si, os taps finais e os outros elementos
de controle do circuito podem convergir para uma solução consideravelmente diferente
para cada modo de controle.
A.3. Comentários 123
Figura 52: Registro de Eventos do OpenDSS no modo de controle temporal
Fonte: autor
Figura 53: Registro de Eventos do OpenDSS gerado pelo código em Python no modo de
controle temporal
Registro de eventos após 30 segundos: 
Hour=0, Sec=3, ControlIter=0, Element=Regulator.reg1, Action= CHANGED 1 TAP TO 1.00625.
Hour=0, Sec=5, ControlIter=0, Element=Regulator.reg1, Action= CHANGED 1 TAP TO 1.0125.
Hour=0, Sec=6, ControlIter=0, Element=Regulator.reg2, Action= CHANGED 1 TAP TO 1.00625.
Hour=0, Sec=7, ControlIter=0, Element=Regulator.reg1, Action= CHANGED 1 TAP TO 1.01875.
Hour=0, Sec=8, ControlIter=0, Element=Regulator.reg2, Action= CHANGED 1 TAP TO 1.0125.
Hour=0, Sec=9, ControlIter=0, Element=Regulator.reg1, Action= CHANGED 1 TAP TO 1.025.
Hour=0, Sec=9, ControlIter=0, Element=Regulator.reg3, Action= CHANGED 1 TAP TO 1.00625.
Hour=0, Sec=10, ControlIter=0, Element=Regulator.reg2, Action= CHANGED 1 TAP TO 1.01875.
Hour=0, Sec=11, ControlIter=0, Element=Regulator.reg3, Action= CHANGED 1 TAP TO 1.0125.
Hour=0, Sec=11, ControlIter=0, Element=Regulator.reg1, Action= CHANGED 1 TAP TO 1.03125.
Hour=0, Sec=12, ControlIter=0, Element=Regulator.reg2, Action= CHANGED 1 TAP TO 1.025.
Hour=0, Sec=13, ControlIter=0, Element=Regulator.reg1, Action= CHANGED 1 TAP TO 1.0375.
Hour=0, Sec=13, ControlIter=0, Element=Regulator.reg3, Action= CHANGED 1 TAP TO 1.01875.
Hour=0, Sec=14, ControlIter=0, Element=Regulator.reg2, Action= CHANGED 1 TAP TO 1.03125.
Hour=0, Sec=15, ControlIter=0, Element=Regulator.reg3, Action= CHANGED 1 TAP TO 1.025.
Hour=0, Sec=15, ControlIter=0, Element=Regulator.reg1, Action= CHANGED 1 TAP TO 1.04375.
Hour=0, Sec=16, ControlIter=0, Element=Regulator.reg2, Action= CHANGED 1 TAP TO 1.0375.
Hour=0, Sec=17, ControlIter=0, Element=Regulator.reg1, Action= CHANGED 1 TAP TO 1.05.
Hour=0, Sec=17, ControlIter=0, Element=Regulator.reg3, Action= CHANGED 1 TAP TO 1.03125.
Hour=0, Sec=19, ControlIter=0, Element=Regulator.reg3, Action= CHANGED 1 TAP TO 1.0375.
Hour=0, Sec=19, ControlIter=0, Element=Regulator.reg1, Action= CHANGED 1 TAP TO 1.05625.
Hour=0, Sec=21, ControlIter=0, Element=Regulator.reg3, Action= CHANGED 1 TAP TO 1.04375.
Hour=0, Sec=23, ControlIter=0, Element=Regulator.reg3, Action= CHANGED 1 TAP TO 1.05.
Hour=0, Sec=25, ControlIter=0, Element=Regulator.reg3, Action= CHANGED 1 TAP TO 1.05625.
Fonte: autor
124 APÊNDICE A. Verificação do processo de simulação do OpenDSS
125
APÊNDICE B
Códigos do Exemplo de Aplicação do
Capítulo 5
Esse apêndice apresenta os códigos utilizados no exemplo de aplicação do capítulo
4. A descrição completa da rede IEEE 8500 Barras na linguagem de programação do
OpenDSS é fornecida juntamente com a instalação do software. Por esse motivo, aqui será
apresentado somente às modificações e os trechos de códigos adicionados na linguagem
de programação de OpenDSS. Quanto ao código implementado em Python para controle
do OpenDSS via interface COM, esse é integralmente fornecido nesse apêndice.
B.1 Scripts no OpenDSS
o Arquivo Master.dss (completo):� �� �
// Master f i l e f o r 8500−Node IEEE Test Feeder Case
Clear
New C i r c u i t . IEEE8500
! Make the source s t i f f with smal l impedance
~ pu=1.05 r1=0 x1=0.001 r0=0 x0=0.001
Red i rec t LineCodes2 . dss
Red i rec t Trip lex_Linecodes . dss
Red i rec t Lines . dss
Red i rec t Transformers . dss
Red i rec t LoadXfmrs . dss ! Load Transformers
Red i rec t Triplex_Lines . dss
! Red i rec t Loads . dss ! Balanced Loads
Red i rec t UnbalancedLoads . dss ! Unbalanced Loads
Red i rec t Capac i tors . dss
126 APÊNDICE B. Códigos do Exemplo de Aplicação do Capítulo 5
Redi rec t CapControls . dss
Red i rec t Regulators . dss
! Medidor na cabeça do al imentador
New Energymeter .m1 Line . ln5815900−1 1
! Medidores de ene rg i a e monitores nas cargas a serem monitoradas
! Carga baixa :
New Energymeter . cargaBaixa Line . Tpx226192954C0 termina l=1
New monitor . cargaBaixa Line . Tpx226192954C0 termina l=1 mode=1 Ppolar =
no
! Carga média :
New Energymeter . cargaMedia Line . Tpx138753B0 termina l=1
New monitor . cargaMedia Line . Tpx138753B0 termina l=1 mode=1 Ppolar=no
! Carga a l t a :
New Energymeter . cargaAlta Line . Tpx247170B0 termina l=1
New monitor . cargaAlta Line . Tpx247170B0 termina l=1 mode=1 Ppolar = no
New Loadshape . r e s i d e n c i a l npts=24 i n t e r v a l=1 mult =(0.2 0 .2 0 . 2 0 . 3 0 . 6
0 .7 0 .6 0 . 5 0 .45 0 .4 0 .4 0 .3 0 . 3 0 . 4 0 .7 0 .88 0 .9 1 .0 0 .8 0 .6 0 . 6
0 .5 0 .3 0 . 2 )
batched i t load . . * d a i l y=r e s i d e n c i a l ! Seta e s s e loadshape para todos
as cargas
New Loadshape . p r i o r i t a r i o npts=24 i n t e r v a l=1 mult =(0.2 0 .2 0 . 2 0 .3 0 .6
0 .7 0 .6 0 . 5 0 .45 0 .4 0 .4 0 .3 0 . 3 0 . 4 0 .7 0 .88 0 .9 1 .0 0 .8 0 .6 0 . 6
0 .5 0 .3 0 . 2 )
batched i t Load .226192954C0a d a i l y=p r i o r i t a r i o ! Seta loadshape para
carga p r i o r i a t á r i a baixa potenc ia
batched i t Load .138753B0a d a i l y=p r i o r i t a r i o ! Seta loadshape para
carga p r i o r i a t á r i a média baixa potenc ia
batched i t Load .247170B0a d a i l y=p r i o r i t a r i o ! Seta loadshape para
carga p r i o r i a t á r i a a l t a baixa potenc ia
New Loadshape . nao_ pr i o r i t a r i o npts=24 i n t e r v a l=1 mult =(0.3 0 .3 0 .3 0 . 3
0 .6 0 .7 0 . 7 0 . 5 0 . 6 0 .9 0 .8 0 . 7 0 . 6 0 .6 0 .6 0 .85 0 .8 0 .6 0 .7 0 . 9
0 .8 0 .6 0 . 4 0 . 3 )
batched i t Load .226192954C0b d a i l y=nao_p r i o r i t a r i o ! Seta loadshape
para carga não p r i o r i a t á r i a baixa potenc ia
batched i t Load .138753B0b d a i l y=nao_pr i o r i t a r i o ! Seta loadshape
para carga não p r i o r i a t á r i a média potenc ia
batched i t Load .247170B0b d a i l y=nao_pr i o r i t a r i o ! Seta loadshape
para carga não p r i o r i a t á r i a a l t a potenc ia
B.1. Scripts no OpenDSS 127
Set max i t e ra t i ons =100
Set maxcont ro l i t e r=20
Set mode = d a i l y
Set s t e p s i z e = 1h
Set number= 24
Set controlmode =time
! Load in bus c oo r d i n t e s now that bus l i s t i s e s t a b l i s h e d
Buscoords Buscoords . dss
! Let DSS est imate the vo l tage bases
Set vo l t ageba s e s =[115 , 12 .47 , 0 . 48 , 0 . 2 0 8 ]
Ca l cvo l tagebase s ! This a l s o e s t a b l i s h e s the bus l i s t
 	� �
o Modificações no arquivo com descrição das cargas desbalanceadas (UnbalancedLo-
ads.dss):� �� �
! Cargas s e l e c i o n a d a s para a s imulação que foram modi f i cadas
! Carga Baixa ! a p r i o r i t á r i a ! b não p r i o r i t á r i a
New Load .226192954C0a phases=1 Bus1=SX3157708C . 1 kV=.120 Status=
v a r i a b l e Model=1 Conn=wye kW= 0.6666 pf = 0 .97 Vminpu = 0.88
New Load .226192954C0b phases=1 Bus1=SX3157708C . 2 kV=.120 Status=
v a r i a b l e Model=1 Conn=wye kW= 0.3333 pf = 0 .97 Vminpu = 0.88
! Carga Média ! a p r i o r i t á r i a ! b não p r i o r i t á r i a
New Load .138753B0a phases=1 Bus1=SX2748130B . 1 kV=.120 Status=
v a r i a b l e Model=1 Conn=wye kW= 1.3333 pf = 0 .97 Vminpu = 0.88
New Load .138753B0b phases=1 Bus1=SX2748130B .2 kV=.120 Status=
v a r i a b l e Model=1 Conn=wye kW= 0.6666 pf = 0 .97 Vminpu = 0.88
! Carga Alta ! a p r i o r i t á r i a ! b não p r i o r i t á r i a
New Load .247170B0a phases=1 Bus1=SX2897784B . 1 kV=.120 Status=
v a r i a b l e Model=1 Conn=wye kW= 2.000 pf = 0 .97 Vminpu = 0.88
New Load .247170B0b phases=1 Bus1=SX2897784B .2 kV=.120 Status=
v a r i a b l e Model=1 Conn=wye kW= 1.000 pf = 0 .97 Vminpu = 0.88
 	� �
o Modificações no arquivo com descrição da topolgia dos cabox triplex (Triplex_Lines.dss):
As linhas conectadas às cargas selecionadas foram definidas como switches. Isso não
precisava necessariamente ser feito. Só foi realizado para mostrar um modo mais fácil
de abrir uma linha, como pode ser visto mais adiante na função verifica_actionlist(),
quando a carga alta é desconectada.
128 APÊNDICE B. Códigos do Exemplo de Aplicação do Capítulo 5
� �� �
! Linhas de d i s t r i b u i ç ã o secundár ia conectadas às cargas modi f i cadas
foram d e f i n i d a s como swi t che s .
! Linha conectada à carga baixa
New Line . Tpx226192954C0 Bus1=X3157708C . 1 . 2 Bus2=SX3157708C . 1 . 2
l i n e c o d e =4/0 Tr ip l ex l ength=50 un i t s=f t switch=yes
! Linha conectada à carga média
New Line . Tpx138753B0 Bus1=X2748130B . 1 . 2 Bus2=SX2748130B . 1 . 2
l i n e c o d e =4/0 Tr ip l ex l ength=50 un i t s=f t switch=yes
! Linha conectada à carga a l t a
New Line . Tpx247170B0 Bus1=X2897784B . 1 . 2 Bus2=SX2897784B . 1 . 2
l i n e c o d e =4/0 Tr ip l ex l ength=50 un i t s=f t switch=yes
 	� �
B.2 Scripts em Python
o Arquivo 8500Bus_COMInterface.py:� �� �
### # −*− coding : i so −8859−15 −*−
__author__ = ’ Celso Rocha NoUSP:7629911 ’
import os
import win32com . c l i e n t
import csv
#I n i c i a l i z a n d o o OpenDSS
try :
DSSObj = win32com . c l i e n t . Dispatch ( " OpenDSSEngine . DSS" )
except :
p r i n t " Houve algum problema na i n i c i a l i z a ç ã o da i n t e r f a c e COM"
r a i s e SystemExit
#Atribuindo algumas i n t e r f a c e s frequentemente u t i l i z a d a s à v a r i á v e i s
mais cur ta s .
DSSText = DSSObj . Text
DSSCircuit = DSSObj . Ac t i v eC i r cu i t
DSSSolution = DSSCircuit . So lu t i on
DSSElem = DSSCircuit . ActiveCktElement
DSSBus = DSSCircuit . ActiveBus
DSSCtrlQueue = DSSCircuit . CtrlQueue
DSSMeters = DSSCircuit . Meters
#Funções
B.2. Scripts em Python 129
#Função r e sponsáve l por l e r e armazenar a l i s t a de c o n t r o l e em um
arquivo de texto " ControlQueue . txt "
de f sa lva_ctr lqueue ( f l ag , hora , segundo , i t e r a c a o ) :
i f f l a g : #se f o r verdade i ra , armazena após a amostragem
DSSText .Command = "Show contro lqueue "
current_control_queue = csv . reader ( open ( ’ IEEE8500_ControlQueue
. csv ’ ) )
my_ControlQueue . wr i t e (
’ Control Queue na Hora ’ + s t r ( hora ) + ’ , Segundo ’ + s t r (
segundo ) + " e i t e r a ç ã o de c o n t r o l e " + s t r (
i t e r a c a o ) + " : \ n " )
i = 0
f o r row in current_control_queue :
i f i == 0 :
my_ControlQueue . wr i t e ( " " + row [ 0 ] + row [ 1 ] + row
[ 2 ] + row [ 3 ] + row [ 4 ] + row [ 5 ] + " \n " )
e l s e :
my_ControlQueue . wr i t e (
" " + row [ 0 ] + " " + row [ 1 ] + " " + row
[ 2 ] + " " + row [ 3 ] + " " + row [
4 ] + " " + row [ 5 ] + " \n " )
i = i + 1
e l s e :
# Repete depo i s do DoControlActions para ver se as ações foram
executadas
DSSText .Command = "Show contro lqueue "
current_control_queue = csv . reader ( open ( ’ IEEE8500_ControlQueue
. csv ’ ) )
my_ControlQueue . wr i t e ( ’ Control Queue após a execuçao das
ações pendentes : \ n ’ )
i f DSSCircuit . CtrlQueue == 0 :
my_ControlQueue . wr i t e ( " Todas as ações foram
executadas na últ ima execução de ações pendentes \n\n" )
e l s e :
i = 0
f o r row in current_control_queue :
i f i == 0 :
my_ControlQueue . wr i t e ( " " + row [ 0 ] + row [ 1 ] +
130 APÊNDICE B. Códigos do Exemplo de Aplicação do Capítulo 5
row [ 2 ] + row [ 3 ] + row [ 4 ] + row [ 5 ] + " \n " )
e l s e :
my_ControlQueue . wr i t e ( " " + row [ 0 ] + " "
+ row [ 1 ] + " " + row [ 2 ] + " " + row [ 3 ] + " " + row [ 4 ] +
" " + row [ 5 ] + " \n " )
i = i + 1
#Função r e sponsáve l por obter a ene rg i a armazenada nos medidores das
cargas no passo de s imulação stepNumber
de f ve r i f i ca_med idore s ( stepNumber ) :
# Primeira etapa : Amostrar ene rg i a dos 3 medidores .
DSSMeters . F i r s t # Medidor m1 at ivo
DSSMeters . Next # Medidor da carga baixa a t i vo
energia_consumida = range (3 )
energia_consumida [ 0 ] = DSSMeters . Reg i s t e rVa lues [ 0 ]
DSSMeters . Next # Medidor da carga média a t i vo
energia_consumida [ 1 ] = DSSMeters . Reg i s t e rVa lues [ 0 ]
DSSMeters . Next # Medidor da carga a l t aa t i vo
energia_consumida [ 2 ] = DSSMeters . Reg i s t e rVa lues [ 0 ]
i = 0
whi le i <= 2 :
p r i n t " Energia armazenada no medidor " , s t r ( i ) , " ao f i n a l da
hora " , s t r ( stepNumber ) , u " é i g u a l a " , energia_consumida [ i ]
i = i + 1
return energia_consumida
#Função r e sponsáve l por v e r i f i c a r se alguma das cargas s e l e c i o n a d a s
a t i n g i u algum l i m i t e de consumo .
de f meu_controle ( energ ia , stepNumber , h , s ) :
energiamax = 30
delay = 1 #1 hora para a b r i r o consumidor
i f stepNumber == 0 :
g l o b a l estado
estado = [ 1 , 1 , 1 ] #estado fechado no i n i c i o do dia . Os
í n d i c e s 0 ,1 e 2 se re ferem às cargas baixa , média e a l t a
respect ivamente
g l o b a l armado
armado = [ 0 , 0 , 0 ] #a abertura das cargas começa desarmada
g l o b a l av i sado
avisado = [ 0 , 0 , 0 ] #nenhuma das cargas recebeu av i so ainda
i=0
whi le i <=2:
i f av i sado [ i ] == 0 and ene rg i a [ i ] >0.8* energiamax :
i f i ==0:
B.2. Scripts em Python 131
p r in t " Consumidor A a t i n g i u 80% de sua cota contratada
ao f i n a l da hora " , h , " . "
i f i == 1 :
p r i n t " Consumidor B a t i n g i u 80% de sua cota contratada
ao f i n a l da hora " , h , " . "
i f i == 2 :
p r i n t " Consumidor C a t i n g i u 80% de sua cota contratada
ao f i n a l da hora " , h , " . "
av i sado [ i ]=1
i f armado [ i ] == 0 and ene rg i a [ i ]>energiamax and estado [ i ] ==
1 :
h = h + 1
actionCode = 0 #act ionode para ação de abertura da carga
deviceHandle = i
DSSCircuit . CtrlQueue . Push (h , s , actionCode , deviceHandle )
armado [ i ]=1
i f i == 0 :
p r i n t u " Consumidor A u l t rapas sou a cota contratada .
Carga não p r i o r i t á r i a t e rá seu fornec imento de ene rg i a suspenso ao
fim da hora " , h , " . "
i f i == 1 :
p r i n t u " Consumidor B u l t rapas sou a cota contratada .
Carga não p r i o r i t á r i a t e rá seu fornec imento de ene rg i a suspenso ao
fim da hora " , h , " . "
i f i == 2 :
p r i n t u " Consumidor C u l t rapas sou a cota contratada .
Carga não p r i o r i t á r i a t e rá seu fornec imento de ene rg i a suspenso ao
fim da hora " , h , " . "
i += 1
#Função r e sponsáve l por v e r i f i c a r se há alguma ação na Act ionL i s t .
de f v e r i f i c a _ a c t i o n l i s t ( ) :
whi l e DSSCircuit . CtrlQueue . PopAction !=0 : #v e r i f i c a se há alguma
ação na a c t i o n l i s t . Se houver , a pr ime i ra ação da l i s t a se torna a
ação a t i va
deviceHandle = DSSCircuit . CtrlQueue . DeviceHandle #armazena
DeviceHandle da ação a t i va
actionCode = DSSCircuit . CtrlQueue . ActionCode #armazena
ActionCode da ação a t i va
i f deviceHandle == 0 : #carga baixa
switchName = " Line . TPX226192954C0 "
DSSCircuit . L ines .Name = switchName . s p l i t ( " . " ) [ 1 ]
i f actionCode == 0 : #abre
armado [ 0 ] =0 #desarma
estado [ 0 ] = 0 #aberto
132 APÊNDICE B. Códigos do Exemplo de Aplicação do Capítulo 5
oldBusName = DSSCircuit . L ines . Bus2
DSSCircuit . L ines . Bus2 = " _aberto_ " + oldBusName
e l s e : #fecha
oldBusName = DSSCircuit . L ines . Bus2
DSSCircuit . L ines . Bus2 = oldBusName [ oldBusName . index ( "
_aberto_ " ) + 1 4 : ]
i f deviceHandle == 1 : # carga média
switchName = " Line . TPX138753B0"
DSSCircuit . L ines .Name = switchName . s p l i t ( " . " ) [ 1 ]
i f actionCode == 0 : # abre
armado [ 1 ] = 0
estado [ 1 ] = 0
oldBusName = DSSCircuit . L ines . Bus2
DSSCircuit . L ines . Bus2 = " _aberto_ " + oldBusName
e l s e : # fecha
oldBusName = DSSCircuit . L ines . Bus2
DSSCircuit . L ines . Bus2 = oldBusName [ oldBusName . index ( "
_aberto_ " ) + 1 1 : ]
i f deviceHandle == 2 : # carga a l t a
switchName = " Line . TPX247170B0"
DSSCircuit . L ines .Name = switchName . s p l i t ( " . " ) [ 1 ]
i f actionCode == 0 : # abre
armado [ 2 ] = 0
estado [ 2 ] = 0
#oldBusName = DSSCircuit . L ines . Bus2
DSSText .Command = "Open Line . TPX247170B0 2 2 " #outra
opção para a b r i r a l inha , dado que e l a f o i d e f i n i d a como sendo um
switch .
# O pr ime i ro " 2 " corresponde ao terminal , e o segundo
corresponde ao nó . No caso , o nó 2 corresponde à f a s e B, f a s e e s ta
onde as cargas
# p r i o r i t á r i a s foram conectadas .
#DSSCircuit . L ines . Bus2 = " _aberto_ " + oldBusName
e l s e : # fecha
oldBusName = DSSCircuit . L ines . Bus2
DSSCircuit . L ines . Bus2 = oldBusName [ oldBusName . index ( "
_aberto_ " ) + 1 1 : ]
#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
DSSText .Command = r " Compile ’C: \ Users \User\TCC_Celso\ Simulacoes \Estudo
\COM_interface \8500Bus_COM\Master . dss ’ " #Endereço do arquivo master
Or i g ina lS t ep s = DSSSolution . Number
DSSSolution . Number = 1
B.2. Scripts em Python 133
my_ControlQueue = open ( " ControlQueue . txt " , "w" )
my_eventLog = open ( " eventLog . txt " , "w" )
f o r stepNumber in range ( Or i g ina lS t ep s ) :
s imulationTime = DSSSolution . dblHour
hora = DSSSolution . Hour
segundo = DSSSolution . Seconds
#Solução com c o n t r o l e s
i t e r a c a o = 1
DSSSolution . In i tSnap ( )
whi l e not DSSSolution . ControlActionsDone :
DSSSolution . SolveNoControl ( )
DSSSolution . SampleControlDevices ( )
f l a g = 1 #f l a g r e sponsáve l por in formar à função
sa lva_ctr lqueue se a l e i t u r a da c t r l queue s e rá f e i t a após a
amostragem dos
#d i s p o s i t i v o s de c o n t r o l e ou não .
sa lva_ctr lqueue ( f l ag , hora , segundo , i t e r a c a o )
i f DSSCircuit . CtrlQueue == 0 :
my_ControlQueue . wr i t e ( "Não há ações de c o n t r o l e
n e c e s s á r i a s \n\n" )
break #s a i do loop de cont ro l e , não há nece s s idade de
executar DSSSolution . DoControlActions ( ) se a l i s t a se encontra
vaz ia .
DSSSolution . DoControlActions ( )
v e r i f i c a _ a c t i o n l i s t ( )
f l a g = 0
sa lva_ctr lqueue ( f l ag , hora , segundo , i t e r a c a o )
i t e r a c a o +=1
i f i t e r a c a o >= DSSSolution . MaxContro l I terat ions :
p r i n t "Número máximo de i t e r a ç õ e s de c o n t r o l e excedido "
i t e r a c a o = "Máximo excedido "
break
i f stepNumber == Or ig ina lS t ep s − 1 : #armazena o r e g i s t r o de
eventos após o últ imo passo de s imulação
my_eventLog . wr i t e ( " Reg i s t ro de eventos após " + s t r (
Or i g ina lS t ep s ) + " segundos : \n " )
f o r i in range ( l en ( DSSSolution . EventLog ) ) :
event = DSSSolution . EventLog [ i ]
134 APÊNDICE B. Códigos do Exemplo de Aplicação do Capítulo 5
my_eventLog . wr i t e ( event + " \n " )
DSSMeters . SampleAll ( ) #Amostra todos os monitores e medidores
ene rg i a = ver i f i ca_med idore s ( stepNumber )
meu_controle ( energ ia , stepNumber , hora , segundo )
p r i n t u "Fim da i t e r a ç ã o " , hora , segundo
DSSSolution . FinishTimeStep ( )
DSSText .Command = " Export monitors cargabaixa "
DSSText .Command = " Plot monitor ob j e c t= cargabaixa channe l s =(1 3 ) "
DSSText .Command = " Export monitors c a r gaa l t a "
DSSText .Command = " Plot monitor ob j e c t= ca rgaa l t a channe l s =(1 3 ) "
DSSText .Command = " Export monitors cargamedia "
DSSText .Command = " Plot monitor ob j e c t= cargamedia channe l s =(1 3 ) "
 	� �
135
APÊNDICE C
Códigos da Aplicação do Capítulo 6
Esse apêndice apresenta os códigos utilizados no exemplo de aplicação do capítulo 5. A
descrição completa da rede IEEE 123 Barras modificada na linguagem de programação do
OpenDSS é fornecida juntamente com os códigos desenvolvidos em Python para aplicação
do controle personalizado.
C.1 Scripts no OpenDSS
o Arquivo Master.dss:� �� �
Set datapath= "C:\ Users \User\Desktop\TCC\IEEE123Barras " ! Colocar o
endereço dos arqu ivos . dss
Clear
New ob j e c t=c i r c u i t . i e e e123
~ basekv =4.16 Bus1=150 pu=1.00 R1=0 X1=0.0001 R0=0 X0=0.0001
New Transformer . reg1a phases=3 windings=2 buses =[150 150 r ] conns=[wye
wye ] kvs =[4.16 4 . 1 6 ] kvas =[5000 5000 ] XHL=.001 %LoadLoss=0.00001
ppm=0.0
New RegControl . c reg1a t rans fo rmer=reg1awinding=2 vreg=120 band=2
p t r a t i o =20 ctprim=700 R=3 X=7.5
Red i rec t IEEELinecodes . DSS
Redi rec t IEEELines . DSS
Redi rec t IEEESwitches . DSS
Redi rec t IEEECapacitors . DSS
New Transformer .XFM1 Phases=3 Windings=2 Xhl=2.72
~ wdg=1 bus=61s conn=Delta kv=4.16 kva=150 %r=0.635
~ wdg=2 bus=610 conn=Delta kv=0.48 kva=150 %r=0.635
136 APÊNDICE C. Códigos da Aplicação do Capítulo 6
Redi rec t IEEE123Regulators . DSS
Redi rec t PVSystem . DSS
! Red i rec t Storage . DSS
Redi rec t IEEE123Loads . DSS
Redi rec t Meters . DSS
Redi rec t Loadshapes . DSS
Set VoltageBases = [ 4 . 1 6 , 0 . 4 8 ]
CalcVoltageBases
 	� �
o Arquivo Storage.dss:� �� �
New Storage . storage_pv1 bus1=PV_Med_1 phases=3 model=1 pf=1 kv=0.48
s t a t e=i d l i n g kWrated =1000 %reserve=20 kWhrated=10000 kvar=0
%stored=50 debugtrace=yes dispmode=e x t e r n a l
! Monitores na Bater ia
New Monitor . Monitor_Bater ias_states element=s to rage . storage_pv1
termina l=1 mode=3
New Monitor . Monitor_Baterias_P element=s to rage . storage_pv1 termina l=1
mode=1 Ppolar=No
 	� �
o Arquivo IEEECapacitors.dss:� �� �
New Capacitor . C83 Bus1=83 Phases=3 kVAR=600 kV=4.16
New Capacitor . C88a Bus1=88.1 Phases=1 kVAR=50 kV
=2.402
New Capacitor . C90b Bus1=90.2 Phases=1 kVAR=50 kV
=2.402
New Capacitor . C92c Bus1=92.3 Phases=1 kVAR=50 kV
=2.402
 	� �
o Arquivo IEEE123Loads.dss:� �� �
New Load . S1a Bus1=1.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S2b Bus1=2.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S4c Bus1=4.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S5c Bus1=5.3 Phases=1 Conn=Wye Model=5 kV=2.4 kW
=20.0 kvar =10.0
New Load . S6c Bus1=6.3 Phases=1 Conn=Wye Model=2 kV=2.4 kW
=40.0 kvar =20.0
New Load . S7a Bus1=7.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
C.1. Scripts no OpenDSS 137
New Load . S9a Bus1=9.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S10a Bus1=10.1 Phases=1 Conn=Wye Model=5 kV=2.4 kW
=20.0 kvar =10.0
New Load . S11a Bus1=11.1 Phases=1 Conn=Wye Model=2 kV=2.4 kW
=40.0 kvar =20.0
New Load . S12b Bus1=12.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S16c Bus1=16.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S17c Bus1=17.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S19a Bus1=19.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S20a Bus1=20.1 Phases=1 Conn=Wye Model=5 kV=2.4 kW
=40.0 kvar =20.0
New Load . S22b Bus1=22.2 Phases=1 Conn=Wye Model=2 kV=2.4 kW
=40.0 kvar =20.0
New Load . S24c Bus1=24.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S28a Bus1=28.1 Phases=1 Conn=Wye Model=5 kV=2.4 kW
=40.0 kvar =20.0
New Load . S29a Bus1=29.1 Phases=1 Conn=Wye Model=2 kV=2.4 kW
=40.0 kvar =20.0
New Load . S30c Bus1=30.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S31c Bus1=31.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S32c Bus1=32.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S33a Bus1=33.1 Phases=1 Conn=Wye Model=5 kV=2.4 kW
=40.0 kvar =20.0
New Load . S34c Bus1=34.3 Phases=1 Conn=Wye Model=2 kV=2.4 kW
=40.0 kvar =20.0
New Load . S35a Bus1 =35.1.2 Phases=1 Conn=Delta Model=1 kV=4.160 kW
=40.0 kvar =20.0
New Load . S37a Bus1=37.1 Phases=1 Conn=Wye Model=2 kV=2.4 kW
=40.0 kvar =20.0
New Load . S38b Bus1=38.2 Phases=1 Conn=Wye Model=5 kV=2.4 kW
=20.0 kvar =10.0
New Load . S39b Bus1=39.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S41c Bus1=41.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S42a Bus1=42.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S43b Bus1=43.2 Phases=1 Conn=Wye Model=2 kV=2.4 kW
138 APÊNDICE C. Códigos da Aplicação do Capítulo 6
=40.0 kvar =20.0
New Load . S45a Bus1=45.1 Phases=1 Conn=Wye Model=5 kV=2.4 kW
=20.0 kvar =10.0
New Load . S46a Bus1=46.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S47 Bus1=47 Phases=3 Conn=Wye Model=5 kV=4.160 kW
=105.0 kvar =75.0
New Load . S48 Bus1=48 Phases=3 Conn=Wye Model=2 kV=4.160 kW
=210.0 kVAR=150.0
New Load . S49a Bus1=49.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=35.0 kvar =25.0
New Load . S49b Bus1=49.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=70.0 kvar =50.0
New Load . S49c Bus1=49.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=35.0 kvar =20.0
New Load . S50c Bus1=50.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S51a Bus1=51.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S52a Bus1=52.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S53a Bus1=53.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S55a Bus1=55.1 Phases=1 Conn=Wye Model=2 kV=2.4 kW
=20.0 kvar =10.0
New Load . S56b Bus1=56.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S58b Bus1=58.2 Phases=1 Conn=Wye Model=5 kV=2.4 kW
=20.0 kvar =10.0
New Load . S59b Bus1=59.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S60a Bus1=60.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S62c Bus1=62.3 Phases=1 Conn=Wye Model=2 kV=2.4 kW
=40.0 kvar =20.0
New Load . S63a Bus1=63.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S64b Bus1=64.2 Phases=1 Conn=Wye Model=5 kV=2.4 kW
=75.0 kvar =35.0
New Load . S65a Bus1 =65.1.2 Phases=1 Conn=Delta Model=2 kV=4.160 kW
=35.0 kvar =25.0
New Load . S65b Bus1 =65.2.3 Phases=1 Conn=Delta Model=2 kV=4.160 kW
=35.0 kvar =25.0
New Load . S65c Bus1 =65.3.1 Phases=1 Conn=Delta Model=2 kV=4.160 kW
=70.0 kvar =50.0
New Load . S66c Bus1=66.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=75.0 kvar =35.0
C.1. Scripts no OpenDSS 139
New Load . S68a Bus1=68.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S69a Bus1=69.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S70a Bus1=70.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S71a Bus1=71.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S73c Bus1=73.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S74c Bus1=74.3 Phases=1 Conn=Wye Model=2 kV=2.4 kW
=40.0 kvar =20.0
New Load . S75c Bus1=75.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S76a Bus1 =76.1.2 Phases=1 Conn=Delta Model=5 kV=4.160 kW
=105.0 kvar =80.0
New Load . S76b Bus1 =76.2.3 Phases=1 Conn=Delta Model=5 kV=4.160 kW
=70.0 kvar =50.0
New Load . S76c Bus1 =76.3.1 Phases=1 Conn=Delta Model=5 kV=4.160 kW
=70.0 kvar =50.0
New Load . S77b Bus1=77.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S79a Bus1=79.1 Phases=1 Conn=Wye Model=2 kV=2.4 kW
=40.0 kvar =20.0
New Load . S80b Bus1=80.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S82a Bus1=82.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S83c Bus1=83.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S84c Bus1=84.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S85c Bus1=85.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S86b Bus1=86.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S87b Bus1=87.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S88a Bus1=88.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S90b Bus1=90.2 Phases=1 Conn=Wye Model=5 kV=2.4 kW
=40.0 kvar =20.0
New Load . S92c Bus1=92.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S94a Bus1=94.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S95b Bus1=95.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
140 APÊNDICE C. Códigos da Aplicação do Capítulo 6
=20.0 kvar =10.0
New Load . S96b Bus1=96.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S98a Bus1=98.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S99b Bus1=99.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S100c Bus1=100.3 Phases=1 Conn=Wye Model=2 kV=2.4kW
=40.0 kvar =20.0
New Load . S102c Bus1=102.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S103c Bus1=103.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S104c Bus1=104.3 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S106b Bus1=106.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S107b Bus1=107.2 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S109a Bus1=109.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=40.0 kvar =20.0
New Load . S111a Bus1=111.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
New Load . S112a Bus1=112.1 Phases=1 Conn=Wye Model=5 kV=2.4 kW
=20.0 kvar =10.0
New Load . S113a Bus1=113.1 Phases=1 Conn=Wye Model=2 kV=2.4 kW
=40.0 kvar =20.0
New Load . S114a Bus1=114.1 Phases=1 Conn=Wye Model=1 kV=2.4 kW
=20.0 kvar =10.0
BatchEdit Load . . * d a i l y=loadshape_cargas ! a l t e r a a propr iedade " d a i l y "
de todas as
! as cargas dec l a radas para " loadshape_cargas "
 	� �
o Arquivo IEEELineCodes.dss:� �� �
New l i n e c o d e . 1 nphases=3 BaseFreq=60
~ rmatr ix = [0 .086666667 | 0 .029545455 0.088371212 | 0 .02907197
0.029924242 0 .087405303 ]
~ xmatrix = [0 .204166667 | 0 .095018939 0.198522727 | 0 .072897727
0.080227273 0 .201723485 ]
~ cmatrix = [2 .851710072 | −0.920293787 3.004631862 | −0.350755566
−0.585011253 2 .71134756 ]
New l i n e c o d e . 2 nphases=3 BaseFreq=60
C.1. Scripts no OpenDSS 141
~ rmatr ix = [0 .088371212 | 0 .02992424 0.087405303 | 0 .029545455
0.02907197 0 .086666667 ]
~ xmatrix = [0 .198522727 | 0 .080227273 0.201723485 | 0 .095018939
0.072897727 0 .204166667 ]
~ cmatrix = [3 .004631862 | −0.585011253 2.71134756 | −0.920293787
−0.350755566 2 .851710072 ]
New l i n e c o d e . 3 nphases=3 BaseFreq=60
~ rmatr ix = [0 .087405303 | 0 .02907197 0.086666667 | 0 .029924242
0.029545455 0 .088371212 ]
~ xmatrix = [0 .201723485 | 0 .072897727 0.204166667 | 0 .080227273
0.095018939 0 .198522727 ]
~ cmatrix = [2 .71134756 | −0.350755566 2.851710072 | −0.585011253
−0.920293787 3 .004631862 ]
New l i n e c o d e . 4 nphases=3 BaseFreq=60
~ rmatr ix = [0 .087405303 | 0 .029924242 0.088371212 | 0 .02907197
0.029545455 0 .086666667 ]
~ xmatrix = [0 .201723485 | 0 .080227273 0.198522727 | 0 .072897727
0.095018939 0 .204166667 ]
~ cmatrix = [2 .71134756 | 0 .585011253 3.004631862 | −0.350755566
−0.920293787 2 .851710072 ]
New l i n e c o d e . 5 nphases=3 BaseFreq=60
~ rmatr ix = [0 .088371212 | 0 .029545455 0.086666667 | 0 .029924242
0.02907197 0 .087405303 ]
~ xmatrix = [0 .198522727 | 0 .095018939 0.204166667 | 0 .080227273
0.072897727 0 .201723485 ]
~ cmatrix = [3 .004631862 | −0.920293787 2.851710072 | −0.585011253
−0.350755566 2 .71134756 ]
New l i n e c o d e . 6 nphases=3 BaseFreq=60
~ rmatr ix = [0 .086666667 | 0 .02907197 0.087405303 | 0 .029545455
0.029924242 0 .088371212 ]
~ xmatrix = [0 .204166667 | 0 .072897727 0.201723485 | 0 .095018939
0.080227273 0 .198522727 ]
~ cmatrix = [2 .851710072 | −0.350755566 2.71134756 | −0.920293787
−0.585011253 3 .004631862 ]
New l i n e c o d e . 7 nphases=2 BaseFreq=60
~ rmatr ix = [0 .086666667 | 0 .02907197 0 .087405303 ]
~ xmatrix = [0 .204166667 | 0 .072897727 0 .201723485 ]
~ cmatrix = [2 .569829596 | −0.52995137 2 .597460011 ]
New l i n e c o d e . 8 nphases=2 BaseFreq=60
~ rmatr ix = [0 .086666667 | 0 .02907197 0 .087405303 ]
~ xmatrix = [0 .204166667 | 0 .072897727 0 .201723485 ]
142 APÊNDICE C. Códigos da Aplicação do Capítulo 6
~ cmatrix = [2 .569829596 | −0.52995137 2 .597460011 ]
New l i n e c o d e . 9 nphases=1 BaseFreq=60
~ rmatr ix = [0 . 2 51 74 24 24 ]
~ xmatrix = [0 . 2 55 20 833 3 ]
~ cmatrix = [2 . 2 70 36 61 28 ]
New l i n e c o d e .10 nphases=1 BaseFreq=60
~ rmatr ix = [0 . 2 51 74 24 24 ]
~ xmatrix = [0 . 2 55 20 833 3 ]
~ cmatrix = [2 . 2 70 36 61 28 ]
New l i n e c o d e .11 nphases=1 BaseFreq=60
~ rmatr ix = [0 . 2 51 74 24 24 ]
~ xmatrix = [0 . 2 55 20 833 3 ]
~ cmatrix = [2 . 2 70 36 61 28 ]
New l i n e c o d e .12 nphases=3 BaseFreq=60
~ rmatr ix = [0 .288049242 | 0 .09844697 0.29032197 | 0 .093257576
0.09844697 0 .288049242 ]
~ xmatrix = [0 .142443182 | 0 .052556818 0.135643939 | 0 .040852273
0.052556818 0 .142443182 ]
~ cmatrix = [33 .77150149 | 0 33.77150149 | 0 0 33 .77150149 ]
 	� �
o Arquivo IEEELines.dss:� �� �
New Line . L115 Bus1=149 Bus2=1 LineCode=1
Length =0.4
New Line . L1 Phases=1 Bus1=1.2 Bus2=2.2 LineCode=10
Length =0.175
New Line . L2 Phases=1 Bus1=1.3 Bus2=3.3 LineCode=11
Length =0.25
New Line . L3 Phases=3 Bus1 =1 .1 . 2 . 3 Bus2 =7 .1 . 2 . 3 LineCode=1
Length =0.3
New Line . L4 Phases=1 Bus1=3.3 Bus2=4.3 LineCode=11
Length =0.2
New Line . L5 Phases=1 Bus1=3.3 Bus2=5.3 LineCode=11
Length =0.325
New Line . L6 Phases=1 Bus1=5.3 Bus2=6.3 LineCode=11
Length =0.25
New Line . L7 Phases=3 Bus1 =7 .1 . 2 . 3 Bus2 =8 .1 . 2 . 3 LineCode=1
Length =0.2
New Line . L8 Phases=1 Bus1=8.2 Bus2=12.2 LineCode=10
Length =0.225
New Line . L9 Phases=1 Bus1=8.1 Bus2=9.1 LineCode=9
Length =0.225
C.1. Scripts no OpenDSS 143
New Line . L10 Phases=3 Bus1 =8 .1 . 2 . 3 Bus2 =13 .1 .2 . 3 LineCode=1
Length =0.3
New Line . L11 Phases=1 Bus1=9r . 1 Bus2=14.1 LineCode=9
Length =0.425
New Line . L12 Phases=1 Bus1=13.3 Bus2=34.3 LineCode=11
Length =0.15
New Line . L13 Phases=3 Bus1 =13 .1 .2 . 3 Bus2 =18 .1 .2 . 3 LineCode=2
Length =0.825
New Line . L14 Phases=1 Bus1=14.1 Bus2=11.1 LineCode=9
Length =0.25
New Line . L15 Phases=1 Bus1=14.1 Bus2=10.1 LineCode=9
Length =0.25
New Line . L16 Phases=1 Bus1=15.3 Bus2=16.3 LineCode=11
Length =0.375
New Line . L17 Phases=1 Bus1=15.3 Bus2=17.3 LineCode=11
Length =0.35
New Line . L18 Phases=1 Bus1=18.1 Bus2=19.1 LineCode=9
Length =0.25
New Line . L19 Phases=3 Bus1 =18 .1 .2 . 3 Bus2 =21 .1 .2 . 3 LineCode=2
Length =0.3
New Line . L20 Phases=1 Bus1=19.1 Bus2=20.1 LineCode=9
Length =0.325
New Line . L21 Phases=1 Bus1=21.2 Bus2=22.2 LineCode=10
Length =0.525
New Line . L22 Phases=3 Bus1 =21 .1 .2 . 3 Bus2 =23 .1 .2 . 3 LineCode=2
Length =0.25
New Line . L23 Phases=1 Bus1=23.3 Bus2=24.3 LineCode=11
Length =0.55
New Line . L24 Phases=3 Bus1 =23 .1 .2 . 3 Bus2 =25 .1 .2 . 3 LineCode=2
Length =0.275
New Line . L25 Phases=2 Bus1=25r . 1 . 3 Bus2 =26.1.3 LineCode=7
Length =0.35
New Line . L26 Phases=3 Bus1 =25 .1 .2 . 3 Bus2 =28 .1 .2 . 3 LineCode=2
Length =0.2
New Line . L27 Phases=2 Bus1 =26.1.3 Bus2 =27.1.3 LineCode=7
Length =0.275
New Line . L28 Phases=1 Bus1=26.3 Bus2=31.3 LineCode=11
Length =0.225
New Line . L29 Phases=1 Bus1=27.1 Bus2=33.1 LineCode=9
Length =0.5
New Line . L30 Phases=3 Bus1 =28 .1 .2 . 3 Bus2 =29 .1 .2 . 3 LineCode=2
Length =0.3
New Line . L31 Phases=3 Bus1 =29 .1 .2 . 3 Bus2 =30 .1 .2 . 3 LineCode=2
Length =0.35
New Line . L32 Phases=3 Bus1 =30 .1 .2 . 3 Bus2 =250 .1 .2 .3 LineCode=2
Length =0.2
New Line . L33 Phases=1 Bus1=31.3 Bus2=32.3 LineCode=11
144 APÊNDICE C. Códigos da Aplicação do Capítulo 6
Length =0.3
New Line . L34 Phases=1 Bus1=34.3 Bus2=15.3 LineCode=11
Length =0.1
New Line . L35 Phases=2 Bus1 =35.1.2 Bus2 =36.1.2 LineCode=8
Length =0.65
New Line . L36 Phases=3 Bus1 =35 .1 .2 . 3 Bus2 =40 .1 .2 . 3 LineCode=1
Length =0.25
New Line . L37 Phases=1 Bus1=36.1 Bus2=37.1 LineCode=9
Length =0.3
New Line . L38 Phases=1 Bus1=36.2 Bus2=38.2 LineCode=10
Length =0.25
New Line . L39 Phases=1 Bus1=38.2 Bus2=39.2 LineCode=10
Length =0.325
New Line . L40 Phases=1 Bus1=40.3 Bus2=41.3 LineCode=11
Length =0.325
New Line . L41 Phases=3 Bus1 =40 .1 .2 . 3 Bus2 =42 .1 .2 . 3 LineCode=1
Length =0.25
New Line . L42 Phases=1 Bus1=42.2 Bus2=43.2 LineCode=10
Length =0.5
New Line . L43 Phases=3 Bus1 =42 .1 .2 . 3 Bus2 =44 .1 .2 . 3 LineCode=1
Length =0.2
New Line . L44 Phases=1 Bus1=44.1 Bus2=45.1 LineCode=9
Length =0.2
New Line . L45 Phases=3 Bus1 =44 .1 .2 . 3 Bus2 =47 .1 .2 . 3 LineCode=1
Length =0.25
New Line . L46 Phases=1 Bus1=45.1 Bus2=46.1 LineCode=9
Length =0.3
New Line . L47 Phases=3 Bus1 =47 .1 .2 . 3 Bus2 =48 .1 .2 . 3 LineCode=4
Length =0.15
New Line . L48Phases=3 Bus1 =47 .1 .2 . 3 Bus2 =49 .1 .2 . 3 LineCode=4
Length =0.25
New Line . L49 Phases=3 Bus1 =49 .1 .2 . 3 Bus2 =50 .1 .2 . 3 LineCode=4
Length =0.25
New Line . L50 Phases=3 Bus1 =50 .1 .2 . 3 Bus2 =51 .1 .2 . 3 LineCode=4
Length =0.25
New Line . L51 Phases=3 Bus1 =51 .1 .2 . 3 Bus2 =151 .1 .2 .3 LineCode=4
Length =0.5
New Line . L52 Phases=3 Bus1 =52 .1 .2 . 3 Bus2 =53 .1 .2 . 3 LineCode=1
Length =0.2
New Line . L53 Phases=3 Bus1 =53 .1 .2 . 3 Bus2 =54 .1 .2 . 3 LineCode=1
Length =0.125
New Line . L54 Phases=3 Bus1 =54 .1 .2 . 3 Bus2 =55 .1 .2 . 3 LineCode=1
Length =0.275
New Line . L55 Phases=3 Bus1 =54 .1 .2 . 3 Bus2 =57 .1 .2 . 3 LineCode=3
Length =0.35
New Line . L56 Phases=3 Bus1 =55 .1 .2 . 3 Bus2 =56 .1 .2 . 3 LineCode=1
Length =0.275
C.1. Scripts no OpenDSS 145
New Line . L57 Phases=1 Bus1=57.2 Bus2=58.2 LineCode=10
Length =0.25
New Line . L58 Phases=3 Bus1 =57 .1 .2 . 3 Bus2 =60 .1 .2 . 3 LineCode=3
Length =0.75
New Line . L59 Phases=1 Bus1=58.2 Bus2=59.2 LineCode=10
Length =0.25
New Line . L60 Phases=3 Bus1 =60 .1 .2 . 3 Bus2 =61 .1 .2 . 3 LineCode=5
Length =0.55
New Line . L61 Phases=3 Bus1 =60 .1 .2 . 3 Bus2 =62 .1 .2 . 3 LineCode=12
Length =0.25
New Line . L62 Phases=3 Bus1 =62 .1 .2 . 3 Bus2 =63 .1 .2 . 3 LineCode=12
Length =0.175
New Line . L63 Phases=3 Bus1 =63 .1 .2 . 3 Bus2 =64 .1 .2 . 3 LineCode=12
Length =0.35
New Line . L64 Phases=3 Bus1 =64 .1 .2 . 3 Bus2 =65 .1 .2 . 3 LineCode=12
Length =0.425
New Line . L65 Phases=3 Bus1 =65 .1 .2 . 3 Bus2 =66 .1 .2 . 3 LineCode=12
Length =0.325
New Line . L66 Phases=1 Bus1=67.1 Bus2=68.1 LineCode=9
Length =0.2
New Line . L67 Phases=3 Bus1 =67 .1 .2 . 3 Bus2 =72 .1 .2 . 3 LineCode=3
Length =0.275
New Line . L68 Phases=3 Bus1 =67 .1 .2 . 3 Bus2 =97 .1 .2 . 3 LineCode=3
Length =0.25
New Line . L69 Phases=1 Bus1=68.1 Bus2=69.1 LineCode=9
Length =0.275
New Line . L70 Phases=1 Bus1=69.1 Bus2=70.1 LineCode=9
Length =0.325
New Line . L71 Phases=1 Bus1=70.1 Bus2=71.1 LineCode=9
Length =0.275
New Line . L72 Phases=1 Bus1=72.3 Bus2=73.3 LineCode=11
Length =0.275
New Line . L73 Phases=3 Bus1 =72 .1 .2 . 3 Bus2 =76 .1 .2 . 3 LineCode=3
Length =0.2
New Line . L74 Phases=1 Bus1=73.3 Bus2=74.3 LineCode=11
Length =0.35
New Line . L75 Phases=1 Bus1=74.3 Bus2=75.3 LineCode=11
Length =0.4
New Line . L76 Phases=3 Bus1 =76 .1 .2 . 3 Bus2 =77 .1 .2 . 3 LineCode=6
Length =0.4
New Line . L77 Phases=3 Bus1 =76 .1 .2 . 3 Bus2 =86 .1 .2 . 3 LineCode=3
Length =0.7
New Line . L78 Phases=3 Bus1 =77 .1 .2 . 3 Bus2 =78 .1 .2 . 3 LineCode=6
Length =0.1
New Line . L79 Phases=3 Bus1 =78 .1 .2 . 3 Bus2 =79 .1 .2 . 3 LineCode=6
Length =0.225
New Line . L80 Phases=3 Bus1 =78 .1 .2 . 3 Bus2 =80 .1 .2 . 3 LineCode=6
146 APÊNDICE C. Códigos da Aplicação do Capítulo 6
Length =0.475
New Line . L81 Phases=3 Bus1 =80 .1 .2 . 3 Bus2 =81 .1 .2 . 3 LineCode=6
Length =0.175
New Line . L82 Phases=3 Bus1 =81 .1 .2 . 3 Bus2 =82 .1 .2 . 3 LineCode=6
Length =0.25
New Line . L83 Phases=1 Bus1=81.3 Bus2=84.3 LineCode=11
Length =0.675
New Line . L84 Phases=3 Bus1 =82 .1 .2 . 3 Bus2 =83 .1 .2 . 3 LineCode=6
Length =0.25
New Line . L85 Phases=1 Bus1=84.3 Bus2=85.3 LineCode=11
Length =0.475
New Line . L86 Phases=3 Bus1 =86 .1 .2 . 3 Bus2 =87 .1 .2 . 3 LineCode=6
Length =0.45
New Line . L87 Phases=1 Bus1=87.1 Bus2=88.1 LineCode=9
Length =0.175
New Line . L88 Phases=3 Bus1 =87 .1 .2 . 3 Bus2 =89 .1 .2 . 3 LineCode=6
Length =0.275
New Line . L89 Phases=1 Bus1=89.2 Bus2=90.2 LineCode=10
Length =0.25
New Line . L90 Phases=3 Bus1 =89 .1 .2 . 3 Bus2 =91 .1 .2 . 3 LineCode=6
Length =0.225
New Line . L91 Phases=1 Bus1=91.3 Bus2=92.3 LineCode=11
Length =0.3
New Line . L92 Phases=3 Bus1 =91 .1 .2 . 3 Bus2 =93 .1 .2 . 3 LineCode=6
Length =0.225
New Line . L93 Phases=1 Bus1=93.1 Bus2=94.1 LineCode=9
Length =0.275
New Line . L94 Phases=3 Bus1 =93 .1 .2 . 3 Bus2 =95 .1 .2 . 3 LineCode=6
Length =0.3
New Line . L95 Phases=1 Bus1=95.2 Bus2=96.2 LineCode=10
Length =0.2
New Line . L96 Phases=3 Bus1 =97 .1 .2 . 3 Bus2 =98 .1 .2 . 3 LineCode=3
Length =0.275
New Line . L97 Phases=3 Bus1 =98 .1 .2 . 3 Bus2 =99 .1 .2 . 3 LineCode=3
Length =0.55
New Line . L98 Phases=3 Bus1 =99 .1 .2 . 3 Bus2 =100 .1 .2 .3 LineCode=3
Length =0.3
New Line . L99 Phases=3 Bus1 =100 .1 .2 .3 Bus2 =450 .1 .2 .3 LineCode=3
Length =0.8
New Line . L118 Phases=3 Bus1 =197 .1 .2 .3 Bus2 =101 .1 .2 .3 LineCode=3
Length =0.25
New Line . L100 Phases=1 Bus1=101.3 Bus2=102.3 LineCode=11
Length =0.225
New Line . L101 Phases=3 Bus1 =101 .1 .2 .3 Bus2 =105 .1 .2 .3 LineCode=3
Length =0.275
New Line . L102 Phases=1 Bus1=102.3 Bus2=103.3 LineCode=11
Length =0.325
C.1. Scripts no OpenDSS 147
New Line . L103 Phases=1 Bus1=103.3 Bus2=104.3 LineCode=11
Length =0.7
New Line . L104 Phases=1 Bus1=105.2 Bus2=106.2 LineCode=10
Length =0.225
New Line . L105 Phases=3 Bus1 =105 .1 .2 .3 Bus2 =108 .1 .2 .3 LineCode=3
Length =0.325
New Line . L106 Phases=1 Bus1=106.2 Bus2=107.2 LineCode=10
Length =0.575
New Line . L107 Phases=1 Bus1=108.1 Bus2=109.1 LineCode=9
Length =0.45
New Line . L108 Phases=3 Bus1 =108 .1 .2 .3 Bus2 =300 .1 .2 .3 LineCode=3
Length=1
New Line . L109 Phases=1 Bus1=109.1 Bus2=110.1 LineCode=9
Length =0.3
New Line . L110 Phases=1 Bus1=110.1 Bus2=111.1 LineCode=9
Length =0.575
New Line . L111 Phases=1 Bus1=110.1 Bus2=112.1 LineCode=9
Length =0.125
New Line . L112 Phases=1 Bus1=112.1 Bus2=113.1 LineCode=9
Length =0.525
New Line . L113 Phases=1 Bus1=113.1 Bus2=114.1 LineCode=9
Length =0.325
New Line . L114 Phases=3 Bus1 =135 .1 .2 .3 Bus2 =35 .1 .2 . 3 LineCode=4
Length =0.375
New Line . L116 Phases=3 Bus1 =152 .1 .2 .3 Bus2 =52 .1 .2 . 3 LineCode=1
Length =0.4
New Line . L117 Phases=3 Bus1=160r . 1 . 2 . 3 Bus2 =67 .1 .2 . 3 LineCode=6
Length =0.35
 	� �
o Arquivo Loadshapes.dss:� �� �
New LoadShape . loadshape_cargas i n t e r v a l=0 npts=24 c s v f i l e =[
Loadshape_carga . csv ]
! i n t e r v a l=0 para que o OpenDSS r e a l i z e a i n t e r p o l a ç ã o
 	� �
o Arquivo Meters.dss:� �� �
! Note que os monitores da b a t e r i a foram d e s c r i t o s no arquivo Storage .
dss
! Tap p o s i t i o n s
New Monitor . Substat iontap trans fo rmer . reg1a te rmina l=2 mode=2
New Monitor . Reg2a trans fo rmer . reg2a te rmina l=2 mode=2
New Monitor . Reg3a trans fo rmer . reg3a te rmina l=2 mode=2
New Monitor . Reg4a trans fo rmer . reg4a te rmina l=2 mode=2
New Monitor . Reg3c t rans fo rmer . reg3c te rmina l=2 mode=2
New Monitor . Reg4b trans fo rmer . reg4b termina l=2 mode=2
148 APÊNDICE C. Códigos da Aplicação do Capítulo 6
New Monitor . Reg4c t rans fo rmer . reg4c te rmina l=2 mode=2
! Voltages
New Monitor . SubstationtapV trans fo rmer . reg1a te rmina l=2 mode=0
New Monitor . Reg2aV trans fo rmer . reg2a termina l=2 mode=0
New Monitor . Reg3aV trans fo rmer . reg3a termina l=2 mode=0
New Monitor . Reg4aV trans fo rmer . reg4a termina l=2 mode=0
New Monitor . Reg3cV trans fo rmer . reg3c te rmina l=2 mode=0
New Monitor . Reg4bV trans fo rmer . reg4b termina l=2 mode=0
New Monitor . Reg4cV trans fo rmer . reg4c te rmina l=2 mode=0
! Monitores do Trafo de Conexao do PV
New Monitor . medidor_trafo_conexao_tensao Transformer .PV_Med1 termina l
=2 mode=0 ! Ppolar = No
New Monitor . medidor_trafo_conexao_potencia Transformer .PV_Med1
termina l=1 mode=1 Ppolar = No
! Monitor no PV
New Monitor . medidor_PV1 PVSystem .PV_1 termina l=1 mode=1 Ppolar = No
 	� �
o Arquivo PVSystem.dss:� �� �
! Descr i ção dos Pa iné i s Fo tovo l t a i c o s
! Loadshapes 1−seg 24 horas . O arquivo LoadshapePV2 . csv é f o r n e c i d o
jutamente à i n s t a l a ç ã o do OpenDSS .
!A única é d i f e r e n ç a é que foram ad ic ionados z e ro s para completar
86400 amostras .
New LoadShape . PVLoadShape2 npts =86400 s i n t e r v a l=1 mult=( F i l e=
LoadshapePV2 . csv ) Action=Normalize
! Curva PT
! Pmpp e s p e c i f i c a d o a 25 graus C e l s i u s
New XYCurve .MyPvsT npts=4 xarray =[0 25 75 100 ] yarray =[1.2 1 .0
0 .8 0 . 6 ]
! Curva de e f i c i ê n c i a
New XYCurve. MyEff npts=4 xarray =[ .1 . 2 . 4 1 . 0 ] yarray =[ .86 . 9
. 93 . 9 7 ]
! Curva de temperatura
New Tshape .MyTemp npts=24 i n t e r v a l=1 temp=[25 , 25 , 25 , 25 , 25 , 25 , 25 ,
25 , 35 , 40 , 45 , 50 60 60 55 40 35 30 25 25 25 25 25 25 ]
! De f in i ção do PV em s i
New PVSystem .PV_1 phases=3 bus1=PV_Med_1 kV=0.48 debugtrace=yes kVA
=1500 i r r a d =1.0 Pmpp=1500 temperature=25 PF=1 %cutin =0.1 %cutout
C.1. Scripts no OpenDSS 149
=0.1 e f f c u r v e=Myeff P−TCurve=MyPvsT Dai ly=PVLoadShape2 TDaily=
MyTemp
! De f in i ção do trans formador de inte r conexão
New Transformer .PV_Med1 phases=3 xhl =5.750000
~ wdg=1 bus=PV_Med_1 kV=0.48 kVA=750.000000 conn=wye
~ wdg=2 bus=300 kV=4.16 kVA=750.000000 conn=wye
 	� �
o Arquivo IEEE123Regulators.dss:� �� �
! Reguladores modelados como trans formadores
New trans fo rmer . reg2a phases=1 windings=2 buses =[9.1
9 r . 1 ] conns=[wye wye ] kvs =[2.402 2 . 4 0 2 ] kvas =[2000 2000 ]
XHL=.01 %LoadLoss=0.00001 ppm=0.0
New trans fo rmer . reg3a phases=1 windings=2 buses =[25.1
25 r . 1 ] conns=[wye wye ] kvs =[2.402 2 . 4 0 2 ] kvas =[2000 2000 ]
XHL=.01 %LoadLoss=0.00001 ppm=0.0
New trans fo rmer . reg4a phases=1 windings=2 buses =[160.1
160 r . 1 ] conns=[wye wye ] kvs =[2.402 2 . 4 0 2 ] kvas =[2000 2000 ]
XHL=.01 %LoadLoss=0.00001 ppm=0.0
New trans fo rmer . reg3c l i k e=reg3a buses =[25.3
25 r . 3 ] ppm=0.0
New trans fo rmer . reg4b l i k e=reg4a buses =[160.2
160 r . 2 ] ppm=0.0
New trans fo rmer . reg4c l i k e=reg4a buses =[160.3
160 r . 3 ] ppm=0.0
! De f in i ção dos e lementos RegControl
New RegControl . c reg2a t rans fo rmer=reg2a winding=2
vreg=120 band=2 p t r a t i o =20 ctprim=50 R=0.4 X=0.4
New RegControl . c reg3a t rans fo rmer=reg3a winding=2
vreg=120 band=1 p t r a t i o =20 ctprim=50 R=0.4 X=0.4
New RegControl . c r eg3c l i k e=creg3a t rans fo rmer=reg3c
New RegControl . c reg4a t rans fo rmer=reg4a winding=2
vreg=124 band=2 p t r a t i o =20 ctprim=300 R=0.6 X=1.3
New RegControl . creg4b l i k e=creg4a t rans fo rmer=reg4b
R=1.4 X=2.6
New RegControl . c r eg4c l i k e=creg4a t rans fo rmer=reg4c
R=0.2 X=1.4
 	� �
o Arquivo IEEESwitches.dss:� �� �
! Switches normalmente fechados
New Line . Sw1 phases=3 Bus1=150r Bus2=149 r1=1e−3 r0=1e−3 x1
=0.000 x0=0.000 c1 =0.000 c0 =0.000 Length =0.001
New Line . Sw2 phases=3 Bus1=13 Bus2=152 r1=1e−3 r0=1e−3 x1
=0.000 x0=0.000 c1 =0.000 c0 =0.000 Length =0.001
150 APÊNDICE C. Códigos da Aplicação do Capítulo 6
New Line . Sw3 phases=3 Bus1=18 Bus2=135 r1=1e−3 r0=1e−3 x1
=0.000 x0=0.000 c1 =0.000 c0 =0.000 Length =0.001
New Line . Sw4 phases=3 Bus1=60 Bus2=160 r1=1e−3 r0=1e−3 x1
=0.000 x0=0.000 c1 =0.000 c0 =0.000 Length =0.001
New Line . Sw5 phases=3 Bus1=97 Bus2=197 r1=1e−3 r0=1e−3 x1
=0.000 x0=0.000 c1 =0.000 c0 =0.000 Length =0.001
New Line . Sw6 phases=3 Bus1=61 Bus2=61s r1=1e−3 r0=1e−3 x1
=0.000 x0=0.000 c1 =0.000 c0 =0.000 Length =0.001
! Switches normalmente aber to s
New Line . Sw7 phases=3 Bus1=151 Bus2=300_OPEN r1=1e−3 r0=1e−3
x1=0.000 x0=0.000 c1 =0.000 c0 =0.000 Length =0.001
New Line . Sw8 phases=1 Bus1=54.1 Bus2=94_OPEN. 1 r1=1e−3 r0=1e−3
x1=0.000 x0=0.000 c1 =0.000 c0 =0.000 Length =0.001
 	� �
C.2 Scripts em Python
o Arquivo analise_inicial.py:
Esse arquivo simula a rede IEEE123 Barras para os 12 casos iniciais e exporta
os monitores em uma localização conveniente, através do comando Set Case, para
posterior análise.� �� �
### # −*− coding : i so −8859−15 −*−
__author__ = ’ CelsoRocha ’
import win32com . c l i e n t
from win32com . c l i e n t import makepy
from pylab import *
import os
import csv
c l a s s DSS( ob j e c t ) : #Classe DSS
de f __init__( s e l f , dssFileName ) :
# Cria uma nova i n s t â n c i a do OpenDSS u t i l i z a n d o Ligações
Prematuras ( Early Bindings )
sys . argv = [ " makepy " , " OpenDSSEngine . DSS" ]
makepy . main ( )
s e l f . dssObj = win32com . c l i e n t . Dispatch ( " OpenDSSEngine . DSS" )
# I n i c i a l i z a o OpenDSS
i f s e l f . dssObj . S ta r t (0 ) == False :
p r i n t "DSS Fa i l ed to Star t "
e l s e :
C.2. Scripts em Python 151
#Atr ibu i uma v a r i á v e l às i n t e r f a c e s comumentes u t i l i z a d a s
para f á c i l a c e s so
s e l f . dssText = s e l f . dssObj . Text
s e l f . d s s C i r c u i t = s e l f . dssObj . Ac t i v eC i r cu i t
s e l f . d s sSo lu t i on = s e l f . d s s C i r c u i t . So lu t i on
s e l f . dssCktElement = s e l f . d s s C i r c u i t . ActiveCktElement
s e l f . dssBus = s e l f . d s s C i r c u i t . ActiveBus
s e l f . dssTransformer = s e l f . d s s C i r c u i t . Transformers
# Limpa a memória do OpenDSS
s e l f . dssObj . C l earAl l ( )
# Carrega o arquivo master
s e l f . dssText .Command = " compile " + dssFileName
# Salva o d i r e t ó r i o a tua l e ac recenta uma pasta para
r e s u l t a d o s
s e l f . OpenDSS_folder_path = os . path . dirname ( dssFileName )
s e l f . r e su l t s_path = s e l f . OpenDSS_folder_path + " / r e s u l t s "
s e l f . dssText .Command = " s e t DataPath=" + s e l f . r e su l t s_path
# Casos Simulados
loadmult = [ 1 , 1 . 1 5 , 1 . 3 ]
pv_penetracao = [ 0 , 0 . 1 , 0 . 2 , 0 . 3 ]
f o r i in range ( l en ( loadmult ) ) :
f o r j in range ( l en ( pv_penetracao ) ) :
s e l f . dssText .Command = " s e t case=" + "LM_" +s t r (
loadmult [ i ] ) + "_PEN_" + s t r ( pv_penetracao [ j ] )
s e l f . ajuste_param ( loadmult [ i ] , pv_penetracao [ j ] )
#Só para conf i rmar se o LoadMult e o Pmpp do PV
f o i rea lmente a l t e r ado .
s e l f . dssText .Command = " get loadmult "
p r i n t s e l f . dssText . Result
s e l f . dssText .Command = " ? PVSystem .PV_1.Pmpp"
p r in t s e l f . dssText . Result
# Ajusta as c o n f i g u r a ç õ e s da so lução
s e l f . s o l v e _ s e t t i n g s ( )
s e l f . d s sSo lu t i on . So lve ( )
# Exporta Monitores para a n á l i s e p o s t e r i o r
s e l f . dssText .Command = " export monitors
152 APÊNDICE C. Códigos da Aplicação do Capítulo 6
Substat iontap "
s e l f . dssText .Command = " export monitors Reg2a "
s e l f . dssText .Command = " export monitors Reg3a "
s e l f . dssText .Command = " export monitors Reg4a "
s e l f . dssText .Command = " export monitors Reg4b "
s e l f . dssText .Command = " export monitors Reg3c "
s e l f . dssText .Command = " export monitors Reg4c "
s e l f . dssText .Command = " export monitors
medidor_trafo_conexao_tensao "
s e l f . dssText .Command = " export monitors
medidor_trafo_conexao_potencia "
s e l f . dssText .Command = " export monitors
medidor_PV1 "
s e l f . dssText .Command = " export monitors
SubstationtapV "
s e l f . dssText .Command = " export monitors Reg2aV"
s e l f . dssText .Command = " export monitors Reg3aV"
s e l f . dssText .Command = " export monitors Reg4aV"
s e l f . dssText .Command = " export monitors Reg4bV"
s e l f . dssText .Command = " export monitors Reg3cV "
s e l f . dssText .Command = " export monitors Reg4cV "
#Funções
de f s o l v e _ s e t t i n g s ( s e l f ) :
s e l f . dssText .Command = " s e t maxcont ro l i t e r =200 "
s e l f . dssText .Command = " s e t max i t e ra t i ons =100 "
s e l f . dssText .Command = " s e t mode = d a i l y "
s e l f . dssText .Command = " s e t controlmode =time "
s e l f . dssText .Command = " s e t s t e p s i z e =1s "
s e l f . dssText .Command = " s e t number=172800 " # 2 d ia s de
s imulação para que o t r a n s i t ó r i o i n i c i a l dos r egu l ado r e s não s e j a
c o n t a b i l i z a d o
de f ajuste_param ( s e l f ,LM, PV_pen) :
s e l f . d s sSo lu t i on . LoadMult = LM
OrigTotalLoad = 3490
i f PV_pen == 0 :
s e l f . dssText .Command = "PVSystem .PV_1. enabled = False "
s e l f . dssText .Command = " ? PVSystem .PV_1. enabled "
p r i n t s e l f . dssText . Result
e l s e :
s e l f . dssText .Command = "PVSystem .PV_1. enabled = True "
s e l f . dssText .Command = "PVSystem .PV_1.Pmpp=" + s t r (
C.2. Scripts em Python 153
OrigTotalLoad *LM*PV_pen)
i f __name__ == ’__main__’ :
d = DSS( r "C: \ Users \User\Desktop\TCC\IEEE123Barras\IEEE123Master .
dss " ) #Coloque aqui o endereço do arquivo Master
 	� �
o Arquivo analise_comStorage.py:� �� �
### # −*− coding : i so −8859−15 −*−
__author__ = ’ CelsoRocha ’
import win32com . c l i e n t
from win32com . c l i e n t import makepy
import sys
from pylab import *
import os
import csv
c l a s s DSS( ob j e c t ) : #Classe DSS
de f __init__( s e l f , dssFileName ) :
# Cria uma nova i n s t â n c i a do OpenDSS u t i l i z a n d o Ligações
Prematuras ( Early Bindings )
sys . argv = [ " makepy " , " OpenDSSEngine . DSS" ]
makepy . main ( )
s e l f . dssObj = win32com . c l i e n t . Dispatch ( " OpenDSSEngine . DSS" )
# I n i c i a l i z a o OpenDSS
i f s e l f . dssObj . S ta r t (0 ) == False :
p r i n t "DSS Fa i l ed to Star t "
e l s e :
#Atr ibu i uma v a r i á v e l às i n t e r f a c e s comumentes u t i l i z a d a s
para f á c i l a c e s so
s e l f . dssText = s e l f . dssObj . Text
s e l f . d s s C i r c u i t = s e l f . dssObj . Ac t i v eC i r cu i t
s e l f . d s sSo lu t i on = s e l f . d s s C i r c u i t . So lu t i on
s e l f . dssCktElement = s e l f . d s s C i r c u i t . ActiveCktElement
s e l f . dssBus = s e l f . d s s C i r c u i t . ActiveBus
s e l f . dssTransformer = s e l f . d s s C i r c u i t . Transformers
s e l f . dssPV = s e l f . d s s C i r c u i t . PVSystems
#Parâmetros Fixos
loadmult = 1 .3
pv_penetracao = 0 .3
minutos = [ 2 , 4 , 1 0 ]
f o r i in range ( l en ( minutos ) ) :
154 APÊNDICE C. Códigos da Aplicação do Capítulo 6
i f i ==0:
s e l f . min = 2 # duração da j a n e l a da média móvel
e l i f i ==1:
s e l f . min = 4
e l i f i ==2:
s e l f . min = 10
# Limpa a memória do OpenDSS
s e l f . dssObj . C l earAl l ( )
# Carrega o c i r c u i t o Master
s e l f . dssText .Command = " compile " + dssFileName
# Salva o d i r e t ó r i o a tua l e ac recenta uma pasta para
r e s u l t a d o s
s e l f . OpenDSS_folder_path = os . path . dirname ( dssFileName
)
s e l f . r e su l t s_path = s e l f . OpenDSS_folder_path + " /
resultados_teste_perdas_somente_ef f / r e su l t sS to rage_ " + s t r ( s e l f . min
) + "_min"
# Seta um novo caso para f á c i l i d e n t i f i c a ç ã o de
r e s u l t a d o s
s e l f . dssText .Command = " s e t case=" + "LM_" +s t r (
loadmult ) + "_PEN_" + s t r ( pv_penetracao )
s e l f . ajuste_param ( loadmult , pv_penetracao )
# Reso lver o r e s t o passo a passo
# Primeiramente , ad i c i ona r os dados da b a t e r i a
s e l f . dssText .Command = " Red i rec t Storage . DSS"
s e l f . dssText .Command = " s e t DataPath=" + s e l f .
r e su l t s_path
# Ajusta as c o n f i g u r a ç õ e s da so lução
s e l f . s o l v e _ s e t t i n g s ( )
Or i g ina lS t ep s = s e l f . d s sSo lu t i on . Number
s e l f . d s sSo lu t i on . Number = 1
f o r stepNumber in range ( Or i g ina lS t ep s ) :
c o n t r o l _ i t e r = 1
s e l f . d s sSo lu t i on . In i tSnap ( ) # I n i c i a l i z a
Contadores
whi l e not s e l f . d s sSo lu t i on . ControlActionsDone :
s e l f . d s sSo lu t i on . SolveNoControl ( ) # Resolve o
f l uxo de potênc ia sem c o n t r o l e s .
C.2. Scripts em Python 155
# Nesse in s tante , j á tenho ace s so à nova
potênc ia i n j e t a d a pe lo PV. Portanto , posso a t u a l i z a r a potênc ia
i n j e t a d a pe l a s b a t e r i a s .
i f c o n t r o l _ i t e r == 1 and s e l f . d s sSo lu t i on . Hour
>=29 and s e l f . d s sSo lu t i on . Hour<=43: #Cons iderar os PVs só no
segundo dia . Menor tempo de s imulação
s e l f . a tua l i za_Pbate r i a s ( )
s e l f . d s sSo lu t i on . SolveNoControl ( )
s e l f . d s sSo lu t i on . SampleControlDevices ( ) #
Amostra os c o n t r o l e s e popula a Control Queue com ações dos
con t r o l ado r e s do OpenDSS
i f s e l f . d s s C i r c u i t . CtrlQueue == 0 :
break #Sai do While se não há mais ações
de c o n t r o l e para r e a l i z a r
s e l f . d s sSo lu t i on . DoControlActions ( ) # Empurra
pra f o r a da Control Queue a pr ime i ra ação da l i s t a de c o n t r o l e . .
quem dec ide
# se a ação é r e a l i z a d a ou não é o elemento de
c o n t r o l e quem dec ide
c o n t r o l _ i t e r += 1
i f c o n t r o l _ i t e r >= s e l f . d s sSo lu t i on .
MaxContro l I terat ions :
p r i n t "Numero maximo de i t e r a c o e s de
c o n t r o l e excedido "
i t e r a c a o = "Maximo excedido "
break
s e l f . d s sSo lu t i on . FinishTimeStep ( ) #a t u a l i z a
monitores , e lementos que integram e incrementa o passo de tempo
s e l f . r a s t r e i a _s o l u c ao ( ) #só para t e r uma i d e i a de
quanto tempo va i demorar
s e l f . dssText .Command = " export monitors Substat iontap "
s e l f . dssText .Command = " export monitors Reg2a "
s e l f . dssText .Command = " export monitors Reg3a "
s e l f . dssText .Command = " export monitors Reg4a "
s e l f . dssText .Command = " export monitors Reg4b "
s e l f . dssText .Command = " export monitors Reg3c "
s e l f . dssText .Command = " export monitors Reg4c "
s e l f . dssText .Command = " export monitors
medidor_trafo_conexao_tensao "
s e l f . dssText .Command = " export monitors
156 APÊNDICE C. Códigos da Aplicação do Capítulo 6
medidor_trafo_conexao_potencia "
s e l f . dssText .Command = " export monitors
Monitor_Bater ias_states "
s e l f . dssText .Command = " export monitors
Monitor_Baterias_P "
s e l f . dssText .Command = " export monitors medidor_PV1 "
s e l f . dssText .Command = " export monitors SubstationtapV
"
s e l f . dssText .Command = " export monitors Reg2aV"
s e l f . dssText .Command = " export monitors Reg3aV"
s e l f . dssText .Command = " export monitors Reg4aV"
s e l f . dssText .Command = " export monitors Reg4bV"
s e l f . dssText .Command = " export monitors Reg3cV "
s e l f . dssText .Command = " export monitors Reg4cV "
de f s o l v e _ s e t t i n g s ( s e l f ) :
s e l f . dssText .Command = " s e t maxcont ro l i t e r =200 "
s e l f . dssText .Command = " s e t max i t e ra t i ons =100 "
s e l f . dssText .Command = " s e t mode = d a i l y "
s e l f . dssText .Command = " s e t controlmode = time "
s e l f . d s sSo lu t i on . StepS ize = 1
s e l f . dssText .Command = " s e t number=172800 "
de f ajuste_param ( s e l f ,LM, PV_pen) :
s e l f . d s sSo lu t i on . LoadMult = LM
OrigTotalLoad = 3490
i f PV_pen == 0 :
s e l f . dssText .Command = "PVSystem .PV_1. enabled = False "
e l s e :
s e l f . dssText .Command = "PVSystem .PV_1. enabled = True "
s e l f . dssText .Command = "PVSystem .PV_1.Pmpp=" + s t r (
OrigTotalLoad *LM*PV_pen)
de f a tua l i za_Pbate r i a s ( s e l f ) :
# I n i c i a l i z a Reg i s t rador de Deslocamento para média móvel ( Só
no segundo dia )
i f s e l f . d s sSo lu t i on . Hour == 29 and s e l f . d s sSo lu t i on . Seconds
==0:
i f s e l f . min == 10 :
s e l f . s h i f t_r eg = [ 0 ] * 600
e l i f s e l f . min == 4 :
s e l f . s h i f t_r eg = [ 0 ] * 240
e l i f s e l f . min == 2 :
C.2. Scripts em Python 157
s e l f . s h i f t_r eg = [ 0 ] * 120
s e l f . dssPV . idx = 1 #Settando o PV at ivo . ( só tem um)
#l ó g i c a da média móvel
f o r i in range ( l en ( s e l f . s h i f t_r eg ) −1) :
s e l f . s h i f t_r eg [ l en ( s e l f . s h i f t_r eg )−i −1]= s e l f . s h i f t_r eg [
l en ( s e l f . s h i f t_r eg )−i −2]
s e l f . s h i f t_r eg [ 0 ] = s e l f . dssPV .kW #I n s e r e a potênc ia gerada
pe lo PV no i n s t a n t e atual , no pr ime i ro elemento do r e g i s t r a d o r de
deslocamento
P_desejado = sum( s e l f . s h i f t_r eg ) / l en ( s e l f . s h i f t_r eg ) #
Cálculo da Potência dese jada
P_bateria = P_desejado − s e l f . dssPV .kW #Nova potênc ia a
s e r i n j e t a d a pe la b a t e r i a .
s e l f . d s s C i r c u i t . SetActiveElement ( " s t o rage . storage_pv1 " ) #
Seta a b a t e r i a como elemento a t i vo
i f P_bateria >0: #Descarrega
s e l f . dssCktElement . P rope r t i e s ( " s t a t e ") . Val = " d i s cha rg ing "
s e l f . dssCktElement . P rope r t i e s ( "%d i s charge " ) . Val =
P_bateria * 100 / 1000
e l i f P_bateria <0: #Carrega
s e l f . dssCktElement . P rope r t i e s ( " s t a t e " ) . Val = " charg ing "
s e l f . dssCktElement . P rope r t i e s ( "%charge " ) . Val = (−1)*
P_bateria * 100 / 1000
e l s e :
s e l f . dssText .Command = " s to rage . storage_pv1 . s t a t e=i d l i n g "
de f r a s t r e i a_ so lu ca o ( s e l f ) :
i f s e l f . d s sSo lu t i on . Seconds == 0 :
p r i n t " Hora =" + s t r ( s e l f . d s sSo lu t i on . Hour )
i f __name__ == ’__main__ ’ :
d = DSS( r "C: \ Users \User\Desktop\TCC\IEEE123Barras\IEEE123Master .
dss " ) #Coloque aqui o endereço do arquivo Master
 	� �
o Arquivo analise_comStorage_controleSOC.py:� �� �
### # −*− coding : i so −8859−15 −*−
#This i s my main code .
__author__ = ’ CelsoRocha ’
158 APÊNDICE C. Códigos da Aplicação do Capítulo 6
import win32com . c l i e n t
from win32com . c l i e n t import makepy
import sys
from pylab import *
import os
import csv
c l a s s DSS( ob j e c t ) : #Classe DSS
de f __init__( s e l f , dssFileName ) :
# Cria uma nova i n s t â n c i a do OpenDSS u t i l i z a n d o Ligações
Prematuras ( Early Bindings )
sys . argv = [ " makepy " , " OpenDSSEngine . DSS" ]
makepy . main ( )
s e l f . dssObj = win32com . c l i e n t . Dispatch ( " OpenDSSEngine . DSS" )
# I n i c i a l i z a o OpenDSS
i f s e l f . dssObj . S ta r t (0 ) == False :
p r i n t "DSS Fa i l ed to Star t "
e l s e :
#Atr ibu i uma v a r i á v e l às i n t e r f a c e s comumentes u t i l i z a d a s
para f á c i l a c e s so
s e l f . dssText = s e l f . dssObj . Text
s e l f . d s s C i r c u i t = s e l f . dssObj . Ac t i v eC i r cu i t
s e l f . d s sSo lu t i on = s e l f . d s s C i r c u i t . So lu t i on
s e l f . dssCktElement = s e l f . d s s C i r c u i t . ActiveCktElement
s e l f . dssBus = s e l f . d s s C i r c u i t . ActiveBus
s e l f . dssTransformer = s e l f . d s s C i r c u i t . Transformers
s e l f . dssPV = s e l f . d s s C i r c u i t . PVSystems
#Parâmetros Fixos
loadmult = 1 .3
pv_penetracao = 0 .3
minutos = [ 2 , 4 , 1 0 ]
ganhos =
[ 0 . 2 5 , 0 . 5 , 0 . 7 5 , 1 , 1 . 2 5 , 1 . 5 , 1 . 7 5 , 2 , 2 . 5 , 3 , 3 . 5 , 4 , 4 . 5 , 5 , 5 . 5 , 6 ]
s e l f . soc_re f = 5000 #kWh Ref ê r enc i a de estado de carga
f o r j in range ( l en ( ganhos ) ) :
s e l f . k = ganhos [ j ] # ganho do cont ro l ador de SOC
f o r i in range ( l en ( minutos ) ) :
s e l f . min = minutos [ i ] # duração da j a n e l a da média
móvel
# Limpa a memória do OpenDSS
C.2. Scripts em Python 159
s e l f . dssObj . C l earAl l ( )
# Carrega o c i r c u i t o Master
s e l f . dssText .Command = " compile " + dssFileName
# Salva o d i r e t ó r i o a tua l e ac recenta uma pasta
para r e s u l t a d o s
s e l f . OpenDSS_folder_path = os . path . dirname (
dssFileName )
s e l f . r e su l t s_path = s e l f . OpenDSS_folder_path + " /
CorrectedLoadShape / re su l t sS to rage_ " + s t r ( s e l f . min ) + "_min/ " + s t r
( s e l f . k )
# Seta um novo caso para f á c i l i d e n t i f i c a ç ã o de
r e s u l t a d o s
s e l f . dssText .Command = " s e t case=" + "LM_" +s t r (
loadmult ) + "_PEN_" + s t r ( pv_penetracao ) + "ganhoK_" + s t r ( s e l f . k )
s e l f . ajuste_param ( loadmult , pv_penetracao )
# Reso lver o r e s t o passo a passo
# Primeiramente , ad i c i ona r os dados da b a t e r i a
s e l f . dssText .Command = " Red i rec t Storage . DSS"
s e l f . dssText .Command = " s e t DataPath=" + s e l f .
r e su l t s_path
# Ajusta as c o n f i g u r a ç õ e s da so lução
s e l f . s o l v e _ s e t t i n g s ( )
Or i g ina lS t ep s = s e l f . d s sSo lu t i on . Number
s e l f . d s sSo lu t i on . Number = 1
f o r s e l f . stepNumber in range ( Or i g ina lS t ep s ) :
c o n t r o l _ i t e r = 1
s e l f . d s sSo lu t i on . In i tSnap ( ) # I n i c i a l i z a
Contadores
whi l e not s e l f . d s sSo lu t i on . ControlActionsDone :
s e l f . d s sSo lu t i on . SolveNoControl ( ) #
Resolve o f l uxo de potênc ia sem c o n t r o l e s .
# Nesse in s tante , j á tenho ace s so à nova
potênc ia i n j e t a d a pe lo PV. Portanto , posso a t u a l i z a r a potênc ia
i n j e t a d a pe l a s b a t e r i a s .
i f c o n t r o l _ i t e r == 1 and s e l f . d s sSo lu t i on .
Hour >=29 and s e l f . stepNumber <=151803: #Cons iderar os PVs só no
segundo dia . Menor tempo de s imulação
s e l f . a lgor i tmo_ativado = 1
160 APÊNDICE C. Códigos da Aplicação do Capítulo 6
i f s e l f . stepNumber == 151803:
s e l f . a lgor i tmo_ativado = 0
s e l f . a tua l i za_Pbate r i a s ( )
s e l f . d s sSo lu t i on . SolveNoControl ( )
s e l f . d s sSo lu t i on . SampleControlDevices ( ) #
Amostra os c o n t r o l e s e popula a Control Queue com acoes dos
con t r o l ado r e s do OpenDSS
i f s e l f . d s s C i r c u i t . CtrlQueue == 0 :
break #Sai do While se não há mais
ações de c o n t r o l e para r e a l i z a r
s e l f . d s sSo lu t i on . DoControlActions ( ) #
Empurra pra f o r a da Control Queue a pr ime i ra ação da l i s t a . . quem
dec ide
# se a ação é r e a l i z a d a ou não é o
elemento de c o n t r o l e quem dec ide
c o n t r o l _ i t e r += 1
i f c o n t r o l _ i t e r >= s e l f . d s sSo lu t i on .
MaxContro l I terat ions :
p r i n t u "Numero maximo de i t e r a c o e s de
c o n t r o l e excedido "
i t e r a c a o = "Maximo excedido "
break
s e l f . d s sSo lu t i on . FinishTimeStep ( ) #a t u a l i z a
monitores , e lementos que integram e incrementa o passo de tempo
s e l f . r a s t r e i a _s o l u c ao ( ) #só para t e r uma
i d e i a de quanto tempo va i demorar
s e l f . dssText .Command = " export monitors
Substat iontap "
s e l f . dssText .Command = " export monitors Reg2a "
s e l f . dssText .Command = " export monitors Reg3a "
s e l f . dssText .Command = " export monitors Reg4a "
s e l f . dssText .Command = " export monitors Reg4b "
s e l f . dssText .Command = " export monitors Reg3c "
s e l f . dssText .Command = " export monitors Reg4c "
s e l f . dssText .Command = " export monitors
medidor_trafo_conexao_tensao "
s e l f . dssText .Command = " export monitors
medidor_trafo_conexao_potencia "
s e l f . dssText .Command = " export monitors
Monitor_Bater ias_states "
C.2. Scripts em Python 161
s e l f . dssText .Command = " export monitors
Monitor_Baterias_P "
s e l f . dssText .Command = " export monitors
medidor_PV1 "
de f s o l v e _ s e t t i n g s ( s e l f ) :
s e l f . dssText .Command = " s e t maxcont ro l i t e r =200 "
s e l f . dssText .Command = " s e t max i t e ra t i ons =100 "
s e l f . dssText .Command = " s e t mode = d a i l y "
s e l f . dssText .Command = " s e t controlmode = time "
s e l f . d s sSo lu t i on . StepS ize = 1
s e l f . dssText .Command = " s e t number=172800 "
de f ajuste_param ( s e l f ,LM, PV_pen) :
s e l f . d s sSo lu t i on . LoadMult = LM
OrigTotalLoad = 3490
i f PV_pen == 0 :
s e l f . dssText .Command = "PVSystem .PV_1. enabled = False "
e l s e :
s e l f . dssText .Command = "PVSystem .PV_1. enabled = True "
s e l f . dssText .Command = "PVSystem .PV_1.Pmpp=" + s t r (
OrigTotalLoad *LM*PV_pen)
de f a tua l i za_Pbate r i a s ( s e l f ) :
# I n i c i a l i z a Reg i s t rador de Deslocamento para média móvel ( Só
no segundo dia )
i f s e l f . d s sSo lu t i on . Hour == 29 and s e l f . d s sSo lu t i on . Seconds
==0:
i f s e l f . min == 10 :
s e l f . s h i f t_r eg = [ 0 ] * 600
e l i f s e l f . min == 4 :
s e l f . s h i f t_r eg = [ 0 ] * 240
e l i f s e l f . min == 2 :
s e l f . s h i f t_r eg = [ 0 ] * 120
#Seta a b a t e r i a como elemento a t i vo
s e l f . d s s C i r c u i t . SetActiveElement ( " s t o rage . storage_pv1 " )
#SOC atua l
energia_armazenada_pct= f l o a t ( s e l f . dssCktElement . P rope r t i e s ( "%
sto r ed " ) . Val )
energia_nominal = f l o a t ( s e l f . dssCktElement. P rope r t i e s ( "
kWhrated " ) . Val )
162 APÊNDICE C. Códigos da Aplicação do Capítulo 6
s e l f . soc_atual = energia_armazenada_pct * energia_nominal /100
#Erro
s e l f . soc_error = s e l f . soc_re f − s e l f . soc_atual
#l ó g i c a da média móvel
f o r i in range ( l en ( s e l f . s h i f t_r eg ) −1) :
s e l f . s h i f t_r eg [ l en ( s e l f . s h i f t_r eg )−i −1]= s e l f . s h i f t_r eg [
l en ( s e l f . s h i f t_r eg )−i −2]
s e l f . dssPV . idx = 1 # Settando o PV at ivo . ( só tem um)
s e l f . s h i f t_r eg [ 0 ] = s e l f . dssPV .kW − s e l f . soc_error * s e l f . k #O
pr ime i ro elemento do r e g i s t r a d o r de deslocamento é modi f icado pe lo
loop de c o n t r o l e
P_avg = sum( s e l f . s h i f t_r eg ) / l en ( s e l f . s h i f t_r eg )
P_bateria = P_avg − s e l f . dssPV .kW #Nova potênc ia a s e r
i n j e t a d a pe la b a t e r i a .
s e l f . d s s C i r c u i t . SetActiveElement ( " s t o rage . storage_pv1 " )
i f P_bateria >0 and s e l f . a lgor i tmo_ativado == 1 : #Descarrega
s e l f . dssCktElement . P rope r t i e s ( " s t a t e " ) . Val = " d i s cha rg ing "
s e l f . dssCktElement . P rope r t i e s ( "%d i s charge " ) . Val =
P_bateria * 100 / 1000
e l i f P_bateria <0 and s e l f . a lgor i tmo_ativado == 1 : #Carregar
s e l f . dssCktElement . P rope r t i e s ( " s t a t e " ) . Val = " charg ing "
s e l f . dssCktElement . P rope r t i e s ( "%charge " ) . Val = (−1)*
P_bateria * 100 / 1000
e l i f P_bateria == 0 or s e l f . a lgor i tmo_ativado == 0 :
s e l f . dssText .Command = " s to rage . storage_pv1 . s t a t e=i d l i n g "
de f r a s t r e i a_ so lu ca o ( s e l f ) :
i f s e l f . d s sSo lu t i on . Seconds == 0 :
p r i n t " Jane la de " + s t r ( s e l f . min ) + " Minutos , K = " + s t r ( s e l f .
k ) + " Hora =" + s t r ( s e l f . d s sSo lu t i on . Hour )
i f __name__ == ’__main__ ’ :
d = DSS( r "C: \ Users \User\Desktop\TCC\IEEE123Barras\IEEE123Master .
dss " ) #Coloque aqui o endereço do arquivo Master
 	� �
	Folha de rosto
	Agradecimentos
	Epígrafe
	Resumo
	Abstract
	Lista de ilustrações
	Lista de tabelas
	Lista de siglas
	Sumário
	Introdução
	Sistemas Elétricos de Distribuição
	O Open Distribution System Simulator (OpenDSS)
	Organização do Documento
	Modelos de Recursos Distribuídos implementados no OpenDSS
	Sistema Fotovoltaico
	Armazenador de Energia
	Cálculo de perdas e atualização da energia armazenada
	Armazenador Descarregando
	Armazenador Carregando
	Implementação de controles no OpenDSS
	Lógica interna de execução do controle
	Modos de controle
	Controles Implementados no OpenDSS
	Regulador de Tensão
	No modo de controle estático
	No modo de controle time
	Controle de Capacitores
	Religadores
	Relé
	Controle de Armazenadores de Energia
	Modos de Controle de Descarga
	Modos de Controle de Carga
	Controle de Chaves
	Controle de Fusíveis
	Inserção de elementos de controle externos e Controle do OpenDSS via interface COM utilizando a linguagem Python
	A interface COM
	Inserindo funções próprias na algoritmo de controle interno do OpenDSS
	A interface de controle CtrlQueue Interface
	Exemplo de aplicação
	Aplicação de algoritmo de controle personalizado em recursos distribuídos adicionados à rede IEEE123 Barras
	Introdução
	A rede IEEE 123 Barras
	Características
	Modificações
	Dados de entrada
	Sistema Fotovoltaico
	Curvas de carga
	Constatação do problema
	Solução proposta
	Média Móvel
	Média Móvel com controle de carga da bateria
	Comentários
	Conclusão
	Referências
	Apêndices
	Verificação do processo de simulação do OpenDSS
	Controle no modo estático
	Controle no modo temporal
	Comentários
	Códigos do Exemplo de Aplicação do Capítulo 5
	Scripts no OpenDSS
	Scripts em Python
	Códigos da Aplicação do Capítulo 6
	Scripts no OpenDSS
	Scripts em Python