Documento de Valmir Quelles

Prévia do material em texto

UNIVERSIDADE ESTADUAL DE CAMPINAS 
Faculdade de Engenharia Elétrica e Computação 
 
HÉLDER SALDANHA FERREIRA 
DESENVOLVIMENTO DE UM CO-SIMULADOR PARA REDES INTELIGENTES DE 
DISTRIBUIÇÃO DE ENERGIA ELÉTRICA 
CAMPINAS 
2018 
 
 
 
 
 
UNIVERSIDADE ESTADUAL DE CAMPINAS 
Faculdade de Engenharia Elétrica e Computação 
HÉLDER SALDANHA FERREIRA 
DESENVOLVIMENTO DE UM CO-SIMULADOR PARA REDES INTELIGENTES DE 
DISTRIBUIÇÃO DE ENERGIA ELÉTRICA 
Dissertação apresentada à Faculdade 
de Engenharia Elétrica e de 
Computação da Universidade Estadual 
de Campinas como parte dos requisitos 
exigidos para a obtenção do título de 
Mestre em Engenharia Elétrica, na 
Área de Energia Elétrica 
 
Orientadora: Fernanda Caseño Trindade Arioli 
ESTE EXEMPLAR CORRESPONDE À VERSÃO FINAL 
DA DISSERTAÇÃO DEFENDIDA PELO ALUNO 
HÉLDER SALDANHA FERREIRA, E ORIENTADA PELA 
PROFESSORA DRA. FERNANDA CASEÑO TRINDADE 
ARIOLI 
 
CAMPINAS 
2018 
 
Agência(s) de fomento e nº(s) de processo(s): Não se aplica. 
Ficha catalográfica
Universidade Estadual de Campinas
Biblioteca da Área de Engenharia e Arquitetura
Luciana Pietrosanto Milla - CRB 8/8129
 
 Ferreira, Hélder Saldanha, 1988- 
 F413d FerDesenvolvimento de um co-simulador para redes inteligentes de
distribuição de energia elétrica / Hélder Saldanha Ferreira. – Campinas, SP :
[s.n.], 2018.
 
 
 FerOrientador: Fernanda Caseño Trindade Arioli.
 FerDissertação (mestrado) – Universidade Estadual de Campinas, Faculdade
de Engenharia Elétrica e de Computação.
 
 
 Fer1. Energia elétrica - Distribuição. 2. Redes inteligentes de energia. I. Arioli,
Fernanda Caseño Trindade, 1984-. II. Universidade Estadual de Campinas.
Faculdade de Engenharia Elétrica e de Computação. III. Título.
 
Informações para Biblioteca Digital
Título em outro idioma: Development of a co-simulator for smart power distribution
networks
Palavras-chave em inglês:
Electricity - Distribution
Intelligent power networks
Área de concentração: Energia Elétrica
Titulação: Mestre em Engenharia Elétrica
Banca examinadora:
Fernanda Caseño Trindade Arioli [Orientador]
Mauricio de Barbosa de Camargo Salles
José Antônio Donizete Rossi
Data de defesa: 11-07-2018
Programa de Pós-Graduação: Engenharia Elétrica
Powered by TCPDF (www.tcpdf.org)
http://www.tcpdf.org
 
 
 
 
COMISSÃO JULGADORA – DISSERTAÇÃO DE MESTRADO 
 
 
Candidato: Hélder Saldanha Ferreira RA: 061383 
Data da Defesa: 11/07/2018 
Título da Dissertação: “Desenvolvimento de um Co-Simulador Para Redes Inteligentes de 
Distribuição de Energia Elétrica” 
Prof.ª Dr.ª Fernanda Caseño Trindade Arioli (Presidente, FEEC/UNICAMP) 
Prof. Dr. Maurício Barbosa de Camargo Salles (USP-São Paulo) 
Dr. José Antônio Donizete Rossi (FACTI) 
 
 
A ata de defesa, com as respectivas assinaturas dos membros da Comissão Julgadora, encontra-
se no processo de vida acadêmica do aluno. 
 
 
 
 
AGRADECIMENTOS 
À professora Fernanda Trindade e ao professor Walmir Freitas pela oportunidade 
concedida. 
A orientação, dedicação e apoio da professora Fernanda Trindade durante a realização 
deste trabalho. 
Ao Gustavo Troiano e ao Paulo Meira pelo apoio e contribuições que tornaram esse 
trabalho possível. 
Aos meus pais, José Ferreira e Maria Ferreira, por todo carinho, dedicação e apoio sem 
os quais esse trabalho não seria possível. 
À minha namorada Camila Leal pelo apoio, carinho e paciência. 
Ao meu tio Antônio Augusto por todo apoio recebido dentro e fora da Unicamp. 
Ao meu avô Quintino que gostaria que estivesse presente nesse momento. 
 
 
 
 
 
RESUMO 
Os sistemas de distribuição de energia elétrica têm sido submetidos a importantes 
mudanças como a conexão de veículos elétricos e de geradores fotovoltaicos tanto na 
média quanto na baixa tensão. Devido aos impactos técnicos associados a essas 
mudanças, este cenário potencialmente exigirá uma maior capacidade de controle e 
gerenciamento destes sistemas, o que pode ser viabilizado, entre outros fatores, pela 
integração de uma infraestrutura avançada de medição e comunicação de dados aos 
sistemas de distribuição. Visando balizar a escolha da tecnologia de comunicação mais 
adequada e do uso da rede de comunicação integrada aos sistemas de distribuição, 
ferramentas especializadas para a análise conjunta dos sistemas de distribuição e das redes 
de comunicação tornam-se fundamentais. O desenvolvimento de tais ferramentas, 
contudo, não é uma tarefa fácil, mas que pode ser simplificado ao utilizar uma técnica 
chamada de co-simulação e que envolve utilizar dois ou mais simuladores executando 
paralelamente para obter um resultado em comum. Utilizar a co-simulação reduz o tempo 
de desenvolvimento e testes necessário para simular uma rede de distribuição inteligente. 
Neste contexto, este trabalho de mestrado apresenta detalhes sobre o desenvolvimento de 
um co-simulador de redes de comunicação e sistemas de distribuição de energia elétrica 
objetivando permitir que outras pessoas possam desenvolver ferramentas similares ou 
utilizar a ferramenta desenvolvida, que será disponibilizada gratuitamente à comunidade. 
 
Palavras-Chave: Co-simulação, OMNeT++, OpenDSS, Redes de Comunicação, Redes 
Inteligentes, Sistemas de Distribuição de Energia Elétrica. 
 
 
 
 
ABSTRACT 
The electric power distribution systems have undergone important changes such as the 
connection of electric vehicles and photovoltaic generators in both medium and low 
voltage. Due to the technical impacts associated with these changes, this scenario will 
potentially require a greater capacity to control and manage these systems, which can be 
achieved, among other factors, by the integration of an advanced measurement and data 
communication infrastructure to the distribution systems. In order to determine the most 
appropriate communication technology and the use of the integrated communication 
network to distribution systems, specialized tools for the joint analysis of distribution 
systems and communication networks are fundamental. The development of such tools, 
however, is not an easy task, however it can be simplified by using a technique called co-
simulation and involves using two or more simulators running in parallel to obtain a 
common result. Using co-simulation reduces the development and testing time required 
to simulate an intelligent distribution network. In this context, this work presents details 
on the development of a co-simulator of communication networks and electric power 
distribution systems aiming to allow other people to develop similar tools or to use the 
developed tool, which will be made available to the community free of charge. 
 
Keywords: Co-simulation, Communication Networks, OMNeT++, OpenDSS, Power 
Distribution Systems, Smart grids. 
 
 
 
 
LISTA DE ILUSTRAÇÕES 
Figura 1 - Processo de Co-Simulação. ......................................................................... 20 
Figura 2 - Método de sincronismo Passo Temporal [24]. ............................................. 23 
Figura 3 - Método de sincronismo por lista de eventos. ............................................... 24 
Figura 4 - Método de sincronismo Mestre-Escravo [23]. ............................................. 26 
Figura 5 - Método de sincronismo Mestre-Escravo-Ativo (MAS)................................ 27 
Figura 6 - Arquitetura do co-simulador. ...................................................................... 39 
Figura 7 - Estrutura da mensagem de dados trocada entre os simuladores. ................... 41 
Figura 8 - Mensagens de requisição e resposta do protocolo mDLMS. ........................ 43 
Figura 9 - Rede IEEE de 123 barras. ........................................................................... 47 
Figura 10 - Rede de comunicação utilizada. ................................................................ 48 
Figura 11 - Modelo de dados para a simulação do co-simulador.................................. 52 
Figura 12 - Máximos de tensão por medidor para Fase 1 no Cenário Base................... 54 
Figura 13 - Máximos de tensão por medidor para Fase 2 no Cenário Base................... 54 
Figura 14 - Máximos de tensão por medidor para Fase 3 no Cenário Base................... 54 
Figura 15 - Variação de tensão por medidor da Fase 3 no Cenário Base. ..................... 55 
Figura 16 - Variação de tensão por medidor da Fase 3 no Cenário A. .......................... 57 
Figura 17 - Máximos de tensão por medidor para a Fase 1 no Cenário A..................... 58 
Figura 18 - Máximos de tensão por medidor para Fase 2 no Cenário A. ...................... 58 
Figura 19 -Máximos de tensão por medidor para Fase 3 no Cenário A. ....................... 58 
Figura 20 - Variação de tensão por medidor da Fase 3 no Cenário B. .......................... 60 
Figura 21 - Mapeamento dos barramentos do sistema. ................................................ 62 
Figura 22 - Anomalias de tensão antes do momento da falta. ....................................... 63 
Figura 23 - Variação de tensão por medidor da Fase 1 no Cenário de Falta A. ............. 64 
Figura 24 - Variação de tensão por medidor da Fase 2 no Cenário de Falta A. ............. 64 
Figura 25 - Variação de tensão por medidor da Fase 3 no Cenário de Falta A. ............. 65 
Figura 26 - Anomalias de tensão para o Cenário de Falta A. ....................................... 66 
Figura 27 - Variação de tensão por medidor da Fase 1 no Cenário de Falta B. ............. 67 
Figura 28 - Variação de tensão por medidor da Fase 2 no Cenário de Falta B. ............. 68 
Figura 29 - Variação de tensão por medidor da Fase 3 no Cenário de Falta B. ............. 68 
 
 
 
 
Figura 30 - Anomalias de tensão para o Cenário de Falta B. ........................................ 69 
 
 
 
 
 
LISTA DE TABELAS 
Tabela 1 - Requisitos de Software para utilização do co-simulador. ............................ 37 
Tabela 2 - Requisitos de hardware para simular a rede elétrica. ................................... 37 
Tabela 3 - Requisitos de hardware para simular a rede de comunicação. ..................... 38 
Tabela 4 - Frequência de medições para o Cenário Base. ............................................ 55 
Tabela 5 - Dados da rede de comunicação Cenário Base. ............................................ 56 
Tabela 6 - Frequência de medições para o Cenário A. ................................................. 59 
Tabela 7 - Dados da rede de comunicação para o Cenário A. ...................................... 59 
Tabela 8 - Frequência de medições para o Cenário B. ................................................. 61 
Tabela 9 - Dados da rede de comunicação Cenário B. ................................................. 61 
Tabela 10 - Frequência de medições para o Cenário de Falta A. .................................. 66 
Tabela 11 - Dados da rede de comunicação Cenário de Falta A. .................................. 66 
Tabela 12- Frequência de medições para o Cenário de Falta B. ................................... 69 
Tabela 13 - Dados da rede de comunicação Cenário de Falta B. .................................. 70 
Tabela 14 - Comparativo do número total de medições de todos cenários. ................... 71 
Tabela 15 - Comparativo de latência e jitter de todos cenários. .................................... 71 
Tabela 16 - Comparativo de retransmissões e RTO de todos cenários. ........................ 71 
 
 
 
 
 
LISTA DE ABREVIATURAS E SIGLAS 
ADMS Advanced Distribution Management System 
API Application Programming Interface 
DLMS Device Language Message Specification 
EDS Event Domain Simulation 
GbE Gigabit Ethernet (Padrão IEEE 802.3-2005) 
ID Código de identificação de um elemento 
IP Internet Protocol 
LTE Long Term Evolution 
MAS Método de sincronismo Mestre-Escravo-Ativo 
mDLMS mock DLMS 
POSIX Portable Operating System Interface 
PV Painel fotovoltaico 
RAM Random Access Memory 
RTO Retransmission timeout 
SCADA Supervisory Control and Data Acquisition 
TCP Transmission Control Protocol 
TDS Time Domain Simulation 
UDP User Datagram Protocol 
 
 
 
 
 
GLOSSÁRIO 
API Interface de programação de aplicações, um conjunto de funções ou 
métodos disponibilizados por um programa para que possa ser controlado 
externamente por um programa ou script. 
 
Latência Tempo necessário para que um pacote trafegue da origem até o destino em 
uma rede de comunicação. 
 
Jitter Variação estatística da latência em uma rede de comunicação. 
 
RTO Tempo mínimo de espera para reiniciar as retransmissões quando muitos 
pacotes são perdidos em sequência em uma rede de comunicação. 
 
 
 
 
 
 
SUMÁRIO 
AGRADECIMENTOS ................................................................................................. 5 
RESUMO ..................................................................................................................... 6 
ABSTRACT ................................................................................................................. 7 
LISTA DE ILUSTRAÇÕES ......................................................................................... 8 
LISTA DE TABELAS ................................................................................................ 10 
LISTA DE ABREVIATURAS E SIGLAS .................................................................. 11 
GLOSSÁRIO.............................................................................................................. 12 
SUMÁRIO ................................................................................................................. 13 
1 INTRODUÇÃO ....................................................................................................... 16 
1.1 Motivação e Objetivos .................................................................... 17 
1.2 Escopo desse Trabalho .................................................................... 19 
1.3 Organização .................................................................................... 19 
2 CO-SIMULAÇÃO ................................................................................................... 20 
2.1 Métodos de Sincronismo ................................................................. 21 
2.1.1 Método do Passo Temporal ...................................................... 22 
2.1.2 Método de Sincronismo por Eventos ........................................ 23 
2.1.3 Método Mestre-Escravo ........................................................... 25 
2.1.4 Método Mestre-Escravo-Ativo (MAS) ..................................... 26 
2.2 Comunicação Entre os Simuladores ................................................ 28 
2.2.1 Arquivos .................................................................................. 28 
2.2.2 Pipes ........................................................................................ 30 
2.2.3 Filas de Mensagens .................................................................. 31 
2.2.4 Interface COM ......................................................................... 32 
2.2.5 Memória Compartilhada ........................................................... 32 
2.2.6 Sockets ..................................................................................... 33 
3 DESENVOLVIMENTO DO CO-SIMULADOR ..................................................... 35 
 
 
 
 
3.1 Simulador da Rede Elétrica ............................................................. 35 
3.2 Simulador da Rede de Comunicação ............................................... 36 
3.3 Requisitos Mínimos ........................................................................ 36 
3.4 Arquitetura e Estrutura do Co-simulador ......................................... 38 
3.5 Protocolo de Comunicação Entre Os Simuladores ...........................40 
3.5.1 Mensagens de Requisição de Medição e Informação ................ 42 
3.5.1.1 Mensagem de Requisição de Medição ............................... 42 
3.5.1.2 Mensagem de Informação de Medição ............................... 43 
3.5.2 Mensagens de Alarme e de Ação de Controle ........................... 44 
3.6 Processo de Co-Simulação .............................................................. 44 
4 ESTUDOS DE CASO E RESULTADOS ................................................................ 46 
4.1 Estrutura da Rede de Distribuição e de Comunicação ...................... 46 
4.2 Cenários de Teste ............................................................................ 48 
4.2.1 Cenários de Controle de Tensão ............................................... 49 
4.2.2 Cenários de Falta ...................................................................... 50 
4.3 Resultados ...................................................................................... 50 
4.3.1 Arquivos de Dados das Simulações .......................................... 51 
4.3.2 Cenário Base ............................................................................ 52 
4.3.3 Cenários de Controle de Tensão ............................................... 56 
4.3.3.1 Cenário de Controle de Tensão A ...................................... 57 
4.3.3.2 Cenário de Controle de Tensão B ...................................... 60 
4.3.4 Cenários de Falta ...................................................................... 61 
4.3.4.1 Cenário de Falta A ............................................................. 63 
4.3.4.2 Cenário de Falta B ............................................................. 67 
4.3.5 Comparativo ............................................................................ 70 
5 CONCLUSÕES ....................................................................................................... 72 
 
 
 
 
5.1 Limitações do Co-Simulador ........................................................... 73 
5.2 Sugestões Para Trabalhos Futuros ................................................... 73 
5.3 Desafios da Co-Simulação .............................................................. 74 
5.3.1 Dificuldades Encontradas Durante o Desenvolvimento ............. 75 
REFERÊNCIAS ......................................................................................................... 77 
16 
 
 
 
1 INTRODUÇÃO 
Tradicionalmente, com exceção da subestação, os sistemas de distribuição de 
energia operam com pouca ou nenhuma medição em tempo real, sendo muitas vezes 
restrita a medições de consumo realizadas mensalmente por um funcionário da empresa 
de distribuição de energia elétrica [1]. Em vários países, ainda é comum encontrar 
medidores eletromecânicos instalados no consumidor de baixa tensão. Porém, nos últimos 
anos começaram a ser instalados medidores digitais que utilizam microcontroladores, 
sensores eletrônicos e uma memória digital para armazenar os dados de consumo. Esses 
medidores ainda necessitam que um funcionário da empresa de distribuição de energia 
realize as medições manualmente, porém a leitura é facilitada com os dados sendo 
exibidos em um painel digital. 
Recentemente, com o advento de novas tecnologias que estão permitindo 
reduzir os custos e o tempo necessário para obter, transmitir, armazenar e analisar grande 
quantidade de dados observa-se uma maior integração entre as redes de distribuição de 
energia elétrica e de telecomunicação criando as chamadas redes inteligentes de 
distribuição de energia, em inglês smart grids. Nessas redes estão presentes equipamentos 
com capacidade de comunicação bidirecional e que permitem medição, controle e 
detecção de problemas remotamente, proporcionando uma maior agilidade na operação 
do sistema. Um desses equipamentos é chamado de medidor inteligente de energia, em 
inglês smart meter [2], é um dos componentes fundamentais na criação e operação das 
redes inteligentes de distribuição de energia. Esse tipo de medidor é uma evolução dos 
medidores digitais e utilizam processadores ou microcontroladores com maior capacidade 
de processamento, possuem maior quantidade de memória de armazenamento e memória 
RAM e, principalmente, trazem a capacidade de comunicação bidirecional. 
A adoção dos medidores inteligentes permite, para a concessionária de 
distribuição de energia, um monitoramento em tempo real (ou quase real) do estado da 
rede e até a utilização de ferramentas de estimação de estado [3]. A possibilidade de criar 
perfis de demanda detalhados por tipo de rede e região, e a capacidade de operar 
remotamente elementos de controle da rede também permitem reduzir o impacto causado 
por novos elementos como a geração distribuída na baixa tensão utilizando geradores 
17 
 
 
 
fotovoltaicos [2] e a introdução de veículos elétricos [4] e [5]. Para o consumidor, é 
possível acompanhar de uma maneira mais detalhada o consumo de energia através de 
gráficos diários, instantâneos e até mesmo contendo o consumo de cada equipamento 
conectado. Além da introdução de novos equipamentos também é possível atualizar e 
aumentar as funcionalidades dos sistemas avançados de gerenciamento da distribuição 
(em inglês, Advanced Distribution Management Systems, ADMS). 
O sistema avançado gerenciamento de distribuição é a plataforma de software 
que contempla o gerenciamento e a otimização dos sistemas de distribuição de energia 
elétrica. Um ADMS inclui funções que automatizam a restauração do sistema e otimizam 
o desempenho da rede de distribuição. Funções do ADMS incluem localização de faltas, 
isolamento e restauração do sistema; controle Volt/Var; gestão do pico de demanda; e 
suporte para microrredes e veículos elétricos. Esses sistemas foram desenvolvidos como 
extensões do sistema SCADA (em inglês, Supervisory Control and Data Acquisition) 
presente na transmissão ou como melhoria dos sistemas de proteção [6] e normalmente 
utilizavam apenas informações dos equipamentos presentes na subestação e alguns 
sistemas de proteção e reguladores. Com a presença de equipamentos com comunicação 
e capacidade de medição remota é possível melhorar esses sistemas com uma maior 
quantidade de informação. 
1.1 MOTIVAÇÃO E OBJETIVOS 
Investimentos em redes inteligentes vêm crescendo consideravelmente pelo 
mundo nos últimos anos [7] e [8]. No Brasil, alguns projetos e estudos em busca das 
melhores soluções estão sendo realizados [9], [10] e [11]. Como resultado, tem-se 
constatado que redes mais inteligentes apresentam o potencial de trazer mudanças que 
facilitam a operação e aumentam a confiabilidade das redes de distribuição de energia. 
Uma das principais mudanças está na quantidade de dados disponíveis, pois atualmente 
existe pouca ou nenhuma medição após a subestação e quando existe está frequentemente 
limitada a unidades consumidoras conectadas diretamente à média ou alta tensão [12]. 
Porém antes que essas mudanças possam ser incorporadas e todo seu potencial seja 
aproveitado é importante que a empresa de distribuição de energia saiba quais dados são 
18 
 
 
 
relevantes para a operação do sistema, qual a frequência de leitura dos medidores é a mais 
adequada e qual a melhor tecnologia que pode ser utilizada para a transmissão de dados 
e se o ideal é construir uma rede dedicada [13] ou é possível operar utilizando a 
infraestrutura de telecomunicação já presente na localidade [12] e [13]. 
A escolha da tecnologia utilizada e dos algoritmos de controle para a operação 
dos sistemas de distribuição necessita de vários estudos utilizando a infraestrutura das 
redes inteligentes, porém devido aos custos elevados de construir e operar essas redes a 
maioria dos estudos necessários devem ser realizados através de simulação 
computacional. Contudo simular uma rede inteligente não é uma tarefa fácil [13], é 
necessário simular a rede dedistribuição de energia elétrica e a rede de telecomunicação 
simultaneamente, e para realizar essa tarefa há três opções: a primeira consiste em criar 
um simulador capaz de simular o sistema completo. A segunda é o desenvolvimento de 
extensões para softwares já existentes; cria-se um módulo de simulação da rede de 
telecomunicação para um software de simulação de sistemas de potência ou um módulo 
de simulação do sistema de potência para um simulador do sistema de telecomunicação; 
a terceira opção é a co-simulação, onde dois ou mais simuladores existentes e dedicados 
são executados paralelamente e de maneira conjunta através da troca de informações para 
simular uma rede inteligente completa [15], [16] e [17]. 
A co-simulação oferece diversas vantagens em relação a desenvolver um 
simulador completo para redes inteligentes. São adotados simuladores já disponíveis e 
testados e que possuem modelos validados para os mais diferentes cenários. A co-
simulação também oferece vantagens em relação a criar extensões para um simulador 
específico, pois são utilizados simuladores completos que podem simular cenários 
complexos sem um grande esforço de desenvolvimento. É uma técnica que já foi utilizada 
para vários estudos [5], [17] e [18], porém a maioria deles desenvolveu uma solução 
específica para o cenário desejado [5] e sem descrever com detalhes como foi 
implementado e as dificuldades encontradas durante o desenvolvimento da solução de co-
simulação. Também existem alguns frameworks mais flexíveis como o Mosaik [19], mas 
que não podem ser facilmente utilizados com alguns simuladores, como por exemplo o 
OMNeT++ [20] sem que seja necessário alterar funções que compões o núcleo do 
simulador [21]. 
19 
 
 
 
O objetivo deste trabalho é desenvolver um co-simulador flexível de código 
aberto que utiliza os simuladores OpenDSS [22] e OMNeT++ para realizar a co-
simulação de redes inteligentes com uma configuração simples e que possa ser utilizado 
para cenários distintos sem grande esforço de configuração. Também é objetivo desse 
trabalho expor os principais pontos que devem ser considerados na criação de um co-
simulador e as dificuldades que podem ser encontradas durante o desenvolvimento. 
1.2 ESCOPO DESSE TRABALHO 
O desenvolvimento de uma ferramenta de co-simulação, também chamada de 
co-simulador, pode ser uma tarefa com grau de dificuldade elevado. Contudo, ao definir 
os objetivos desejados e estudar as características e particularidades dos simuladores que 
serão utilizados o esforço necessário e a complexidade do desenvolvimento são 
reduzidos. Um co-simulador flexível, ou seja, que pode ser utilizado para diferentes 
cenários, topologias e tecnologias com pouco ou nenhum ajuste da ferramenta pode 
demandar um maior esforço de desenvolvimento, mas que será recompensado por não ser 
necessário desenvolver ou mesmo alterar significativamente a ferramenta. Neste trabalho 
são cobertas as principais etapas no desenvolvimento de um co-simulador. Também são 
apresentados cenários de teste que envolvem o controle de geradores fotovoltaicos 
instalados nas unidades consumidoras e a detecção de faltas (curtos-circuitos). 
1.3 ORGANIZAÇÃO 
O restante deste trabalho é organizado da seguinte forma: No Capítulo 2, é 
abordado mais profundamente o tema da co-simulação, as vantagens e desvantagens, e as 
principais formas de realizar a integração entre os simuladores utilizados. No Capítulo 3, 
é abordada a implementação do co-simulador desenvolvido neste trabalho, são expostos 
detalhes como arquitetura, método de sincronismo e comunicação utilizados. No Capítulo 
4, são apresentados os cenários de teste utilizando o co-simulador desenvolvido. Por fim, 
no Capítulo 5, são apresentadas as conclusões e sugestões para trabalhos futuros. 
20 
 
 
 
2 CO-SIMULAÇÃO 
A técnica que utiliza dois ou mais simuladores em paralelo para obter um resultado 
combinado recebe o nome de co-simulação. Como cada simulador é responsável por uma 
parte do sistema, é possível modelar com precisão partes individuais do sistema sem 
aumentar desnecessariamente a complexidade dos modelos e do simulador, reduzindo 
consideravelmente o tempo de desenvolvimento e simulação de cada parte. O processo 
de co-simulação é ilustrado na Figura 1 e uma de suas grandes vantagens é o 
aproveitamento de simuladores disponíveis e testados reduzindo drasticamente o tempo 
gasto modelando, desenvolvendo, testando e corrigindo problemas. O objetivo da co-
simulação é obter um resultado em comum e, portanto, elementos modelados em um 
simulador têm influência direta ou indireta nos elementos dos outros simuladores e essas 
interações dependem da integração entre os simuladores. 
 
 
Figura 1 - Processo de Co-Simulação. 
 
A integração entre os simuladores é um dos pontos mais críticos de uma co-
simulação e determina os tipos de cenários em que o co-simulador pode ser utilizado além 
de ser responsável por uma parcela considerável do desempenho da simulação. Para 
simplificar o entendimento, as próximas seções consideram que são utilizados apenas dois 
Simulador
da Rede
Elétrica
Simulador
da Rede de
Comunicação
Tempo
+ Coordenadas
+ Informações
Tempo
+ Perfil das
Cargas
Modelos da
Rede de
Comunicação
Modelos da
Rede de
Elétrica
Perfil das
Cargas
Topologia da
Rede Elétrica
Topologia da
Rede de Comunicação
Mensagem de
informação recebidaPerfil das cargasajustado
para o momento do
evento
21 
 
 
 
simuladores genéricos chamados de Simulador A e Simulador B. A integração dos 
simuladores deve garantir que a sequência de simulação executada corresponda à 
sequência esperada e que o estado da simulação seja coerente e coeso entre os 
simuladores. Essa tarefa é feita através do sincronismo de tempo entre os simuladores, 
por exemplo, uma falta que ocorre no tempo t1 modelada no Simulador A deve refletir 
uma resposta enviada pelo Simulador B sinalizando para que um disjuntor seja aberto. 
Em uma co-simulação com problemas de sincronismo, o Simulador B pode enviar o 
comando para a abertura do disjuntor quando o Simulador A já avançou horas ou dias em 
relação ao tempo em que a falta ocorreu. 
2.1 MÉTODOS DE SINCRONISMO 
Devido à importância do sincronismo entre os simuladores foram 
desenvolvidos diversos métodos e algoritmos para tornar possível realizar uma co-
simulação. Esses métodos variam em dificuldade de implementação, desempenho e 
filosofia. A escolha de um método de sincronismo deve considerar o princípio de 
funcionamento dos simuladores (por exemplo, se são baseados em tempo ou em eventos), 
como é realizada a comunicação entre eles, e a quantidade e a frequência de dados. 
Escolher um método de sincronismo inadequado pode gerar um grande impacto na co-
simulação, reduzindo consideravelmente o desempenho e em casos mais extremos 
impossibilitando sua execução. 
Uma dificuldade adicional está relaciona à maneira como a simulação avança 
em cada um dos simuladores utilizados, sendo possível dividir os simuladores em duas 
categorias que se diferenciam pelo domínio em que a simulação é executada. A primeira 
dessas categorias é chamada de simulação no domínio do tempo, em inglês time domain 
simulation (TDS), em que passos temporais são utilizados para avançar a simulação. É 
possível visualizar esse tipo de simulador da seguinte maneira: A simulação inicia em um 
instante t0 em que são realizados os cálculos necessários na execução do modelo utilizado, 
e a cada intervalo de tempo Δt os cálculos são refeitos. O resultado obtido em um instante 
tn depende dos resultados de passos anteriores. Um exemplo é um simulador da rede 
elétrica que realiza uma série de cálculos de fluxo de carga sequenciais para realizar o 
22 
 
 
 
cálculo do fluxo de potência ao longo do período de um dia. A segunda categoria é 
chamada de simulação no domínio de eventos, em inglês event domain simulation (EDS), 
em que determinadoseventos fazem com que o tempo da simulação avance e 
diferentemente das simulações no domínio do tempo o avanço não tem um intervalo de 
tempo fixo, ou seja, cada tipo de evento que causa o avanço diferente no tempo. No 
simulador da rede de comunicação, por exemplo, eventos na rede, como envio de 
mensagens ou estabelecimento de conexões, não possuem um intervalo determinado de 
tempo ou duração específica, mas fazem a simulação avançar no tempo. 
Normalmente os simuladores da rede de distribuição e da rede de 
telecomunicação executam em domínios diferentes. Portanto, ao desenvolver um co-
simulador é necessário considerar essa particularidade na escolha do método de 
sincronismo adotado. Nas próximas seções são descritos os principais métodos de 
sincronismo encontrados na literatura e um novo método proposto neste trabalho e 
chamado de Mestre-Escravo-Ativo. 
2.1.1 Método do Passo Temporal 
Um dos primeiros métodos de sincronismos encontrados na literatura é 
chamado de Método do Passo Temporal [14], [23] e [24]. Nesse método é definido um 
intervalo de tempo fixo Δt, no tempo de simulação, em que os simuladores realizam a 
troca de dados. Um dos problemas de se utilizar esse método está relacionado ao intervalo 
de tempo fixo. Como nenhuma comunicação pode acontecer antes que um período Δt 
tenha passado, eventos que ocorrerem nesse intervalo são atrasados, pequenas diferenças 
de tempo entre os simuladores também se acumulam durante toda a simulação gerando o 
que é chamado de erro de acumulação temporal, em inglês time accumulation error. A 
Figura 2 ilustra o funcionamento desse método. 
23 
 
 
 
 
Figura 2 - Método de sincronismo Passo Temporal [24]. 
 
É possível reduzir os erros de acumulação temporal utilizando uma variação 
desse método que permite que o intervalo de tempo Δt possa ser variado de uma maneira 
adaptativa [18]. Esse método de sincronismo é mais facilmente utilizado quando os dois 
simuladores executam a simulação no domínio do tempo (TDS). Quando existirem 
simuladores executando no domínio de eventos (EDS) é necessário adaptar esses 
simuladores para que possam efetuar a comunicação no instante de tempo correto. A 
complexidade de realizar esse ajuste pode ser elevada dependendo do simulador que está 
sendo utilizado. Simuladores que não são de código aberto podem tornar esse ajuste 
extremamente trabalhoso ou até mesmo impossível. 
2.1.2 Método de Sincronismo por Eventos 
Um outro método presente na literatura utiliza o domínio de eventos para 
sincronizar os simuladores. Ao iniciar uma simulação é criada uma lista de eventos que é 
compartilhada, cada um dos simuladores pode consultar e atualizar a lista conforme 
necessidade. Os outros simuladores conseguem identificar modificações na lista e se 
necessário realizar ajustes na simulação, garantindo assim o sincronismo entre os 
Simulador A
Simulador B
t 2t 3t 4t
t 2t 3t 4t
tempo
tempo
24 
 
 
 
simuladores. Esse método é mais facilmente implementado quando os simuladores 
executam no domínio de eventos (EDS). Simuladores que executam no domínio do tempo 
(TDS) necessitam que seja criada uma camada de adaptação que permita que o domínio 
de eventos controle o avanço da simulação, uma tarefa que pode gerar alguns problemas 
de desempenho. 
Na Figura 3 é apresentado o funcionamento do método de sincronismo, no 
início da simulação é criada uma lista de eventos compartilhada entre os simuladores. A 
criação da lista adiciona eventos responsáveis pela inicialização de cada um dos 
simuladores utilizados e a serem tratados os simuladores irão preencher a lista com os 
eventos iniciais de cada simulação. O evento de início da co-simulação também é gravado 
durante a criação da lista e será executado após todo os simuladores terminarem a 
inicialização e de gravarem os eventos inicias e é o evento que inicia a simulação em cada 
um dos simuladores utilizados. 
 
 
Figura 3 - Método de sincronismo por lista de eventos. 
 
Esse método de sincronismo tem algumas desvantagens, a maioria delas está 
relacionada ao desempenho da co-simulação que pode ser reduzido [24]. Também é 
Simulador A
Simulador B
tempo
tempo
tempo
t
t
t
t
Lista de Eventos
25 
 
 
 
necessário considerar onde cada um dos simuladores é executado, ou seja, quando os 
simuladores estiverem executando em computadores diferentes e, principalmente, 
utilizando sistemas operacionais diferentes a dificuldade de implementação desse método 
aumenta consideravelmente pois torna-se necessário adicionar mecanismos que garantam 
a integridade da lista de eventos. A garantia da integridade é necessária, por exemplo, em 
um momento em que o fornecimento de energia oscilar pois é possível que um dos 
simuladores não consiga atualizar ou perca o evento. Portanto, existe um risco maior de 
corromper os dados. 
A complexidade de implementação desse método é alta quando um dos 
simuladores não utiliza o domínio de eventos ou são utilizados computadores com 
sistemas operacionais diferentes. 
2.1.3 Método Mestre-Escravo 
Um outro método de sincronismo presente na literatura é chamado de Método 
de Sincronismo Mestre-Escravo [16], [24] e [25]. Nesse método um dos simuladores é 
chamado de Mestre e é responsável por controlar toda a simulação e o avanço temporal. 
O outro simulador é denominado de Escravo e deve apenas responder requisições 
enviadas pelo Mestre. O avanço do tempo da simulação do Escravo depende de comandos 
enviados pelo Mestre, isso significa que a simulação do escravo avança até o momento 
que o Mestre requisitar. Assim como o Método do Passo Temporal, o Método Mestre-
Escravo está sujeito a acumulação de erros temporais. Por exemplo, se uma falta ocorrer 
entre a primeira mensagem do Mestre no tempo t1 e a segunda mensagem do Mestre no 
tempo t2, só será entregue ao Mestre no tempo t2, podendo ser tarde demais para que uma 
ação seja tomada. Na Figura 4 é apresentada uma ilustração do funcionamento do Método 
Mestre-Escravo. A complexidade de implementação do Método Mestre-Escravo é baixa 
e permite que seja utilizado com softwares que executam em domínios diferentes. 
26 
 
 
 
 
Figura 4 - Método de sincronismo Mestre-Escravo [23]. 
2.1.4 Método Mestre-Escravo-Ativo (MAS) 
Uma das contribuições desse trabalho é o desenvolvimento de um método de 
sincronismo chamado de Método Mestre-Escravo-Ativo, em inglês Master-Active-Slave 
(MAS), e foi concebido para resolver os problemas do Método Mestre-Escravo na 
aplicação da simulação de redes inteligentes. Nesse método é permitido que o Escravo 
inicie a comunicação com o Mestre, porém essa comunicação iniciada pelo Escravo pode 
acontecer apenas quando violações pré-definidas e chamadas de alarmes ocorrerem. A 
Figura 5 apresenta o funcionamento desse método de sincronismo. 
A simulação se inicia da mesma maneira que o Método Mestre-Escravo, o 
Mestre inicia a simulação e executa até o primeiro ponto de troca de mensagens onde o 
Escravo recebe a requisição e executa até o instante atual enviando a resposta ao Mestre. 
A partir desse ponto a simulação passa a executar no modo Mestre-Escravo-Ativo, com 
o Escravo executando à frente do Mestre até o próximo instante de comunicação. Durante 
a execução da simulação, é possível que ocorram violações no Escravo. Nesse caso, o 
Escravo para a execução e envia uma mensagem de alarme para o Mestre e espera que 
um comando seja recebido. Quando a simulação do Mestre chega no instante de 
ocorrência do Alarme, ele é devidamente processado e ações podem ser geradas. Após o 
Simulador A (Escravo)
Simulador B (Mestre)
t tempo
t tempo
1
2
3
4
5 6
7
8
9
10
11
12
13
27 
 
 
 
Mestre processar o alarme, o Escravo pode receber um comando para efetuar uma ação 
de controle para corrigir o problema ou continuar a simulação sem efetuar nenhuma ação. 
Uma das vantagens desse método de sincronismo é poder utilizar um 
intervalode comunicação grande sem a perda de eventos que ocorrerem entre os instantes 
de comunicação e sem atraso no tratamento e reduzindo drasticamente ou eliminando 
completamente a acumulação de erros temporais. É possível, por exemplo, utilizar esse 
método de sincronismo para simular o controle de geradores fotovoltaicos quando limites 
de tensão forem violados ou para detecção de faltas sem a necessidade de reduzir 
drasticamente o intervalo a amostragem dos medidores. 
A complexidade de implementação desse método é média. É necessário 
implementar o Método Mestre-Escravo e adicionar elementos adicionais que permitam 
que o Mestre receba as mensagens de alarme do Escravo e possa efetuar o tratamento 
correto para cada uma delas, seja enviando ações de controle ou o comando para continuar 
a execução. Assim como o Método Mestre-Escravo, esse método pode ser facilmente 
utilizado mesmo que os simuladores executem a simulação em domínios diferentes. 
 
 
Figura 5 - Método de sincronismo Mestre-Escravo-Ativo (MAS). 
Simulador A (Escravo)
Simulador B (Mestre)
t
tempo
tempo
t
Requisição Inicial
Resposta
Requisição/Resposta
Requisição/Resposta
Requisição/Resposta
Alarm
e
Ação de Controle
28 
 
 
 
2.2 COMUNICAÇÃO ENTRE OS SIMULADORES 
Apenas escolher o método de sincronismo não é suficiente para realizar a co-
simulação, também é necessário escolher o mecanismo de comunicação entre os 
simuladores. Esse mecanismo é responsável por permitir que os simuladores troquem 
dados e possam executar as simulações e implementar os métodos de sincronismo 
disponíveis. A escolha do mecanismo de comunicação adequado depende: 
• dos simuladores utilizados; 
• da quantidade e frequência da troca de dados entre eles; 
• do tipo de método de sincronismo desejado; 
• da quantidade de computadores e dos sistemas operacionais utilizados. 
Nas próximas seções são apresentados os principais mecanismos de 
comunicação, suas vantagens e desvantagens, e os métodos de sincronismo mais 
adequados para cada um dos mecanismos apresentados. No Capítulo 3, o tipo de 
comunicação entre os simuladores que compõem o co-simulador é apresentado. 
2.2.1 Arquivos 
A comunicação através de arquivos é um dos mecanismos mais simples que 
pode ser utilizado para a comunicação entre os simuladores. É uma forma de comunicação 
bem versátil, suportada por praticamente todos sistemas operacionais, e pode ser utilizada 
para comunicação de simuladores executando em um único computador ou simuladores 
executando em computadores distintos na rede local ou até mesmo pela internet [5], [25]. 
Utilizar comunicação por arquivos requer que cada simulador seja responsável por 
monitorar modificações no(s) arquivo(s) ou diretório(s) de interesse, na maioria dos 
sistemas operacionais e linguagens de programação disponíveis existem bibliotecas que 
facilitam essa tarefa [26] e [27]. A utilização de arquivos para realizar a comunicação 
entre os simuladores é simples e basta garantir que todos os simuladores tenham 
permissão de leitura e escrita para os arquivos utilizados. Outro ponto positivo desse 
mecanismo é a flexibilidade do formato de arquivo utilizado para o compartilhamento de 
29 
 
 
 
dados, é possível utilizar arquivos em texto, arquivos binários ou arquivos que podem ser 
facilmente lidos por humanos e computadores como csv, xml e json. 
Assumindo que o arquivo utilizado para o compartilhamento de informações 
está localizado em uma pasta acessível para os dois simuladores e com permissão de 
escrita, pode-se descrever o funcionamento desse mecanismo da seguinte maneira: O 
Simulador A precisa enviar dados para que o Simulador B possa continuar a simulação, 
para isso o Simulador A escreve os dados no formato escolhido, por exemplo através do 
formato ‘csv’ em um arquivo chamado ‘dados_sim_a.csv’. O Simulador B é então 
notificado que o arquivo ‘dados_sim_a.csv’ foi modificado e procede, então, para extrair 
os dados presentes no arquivo que são necessários para continuar a simulação. O caso 
acima representa uma comunicação unidirecional onde o fluxo de dados é do Simulador 
A para o Simulador B. É um cenário que não ocorre em um ambiente de co-simulação 
pois o Simulador B não tem influência sobre o Simulador A. A comunicação 
unidirecional do exemplo acima pode ser utilizada para uma simulação serial, onde 
primeiramente o Simulador A é executado e os resultados obtidos são gravados no 
arquivo ‘dados_sim_a.csv’ e utilizados como parâmetros de entrada para o Simulador B, 
que é executado assim que o Simulador A finalizar. 
Uma co-simulação necessita de comunicação bidirecional entre os 
simuladores utilizados. Essa necessidade expõe uma das desvantagens de utilizar 
arquivos para o compartilhamento de dados. O controle de acesso do sistema de arquivos 
permite que apenas um processo tenha permissão de escrita a cada instante de tempo [28], 
[29] e [30]. A comunicação entre os simuladores é half-duplex, ou seja, se o Simulador A 
estiver escrevendo dados no arquivo, o Simulador B pode apenas efetuar a leitura; e se o 
Simulador B precisar escrever no arquivo, deve esperar o Simulador A libera-lo (o que 
pode nunca ocorrer). Para obter uma comunicação full-duplex, é necessário utilizar dois 
arquivos distintos. O primeiro arquivo é responsável por enviar dados do Simulador A 
para o Simulador B, o segundo arquivo é responsável por enviar dados no sentido oposto, 
ou seja, do Simulador B para o Simulador A. Outra desvantagem de utilizar a 
comunicação através de arquivo é a grande latência envolvida na leitura e escrita de 
arquivos em disco. A utilização de unidades de estado sólido (SSD) reduz 
consideravelmente os tempos de acesso. 
30 
 
 
 
Uma das maneiras mais simples de implementar os métodos de sincronismo 
do Passo Temporal e Mestre-Escravo é utilizar a troca de dados através de arquivos. É 
importante ressaltar que os altos tempos de acesso envolvidos nas operações de leitura e 
escrita em disco tornam a co-simulação muito lenta quando leituras e, principalmente, 
escritas frequentes são necessárias. 
2.2.2 Pipes 
O mecanismo de canalização da entrada e saída de processos, em inglês pipe, 
consiste em direcionar a saída de um processo para a entrada do seguinte encadeando a 
execução e gerando o que é chamado, em inglês, de pipeline. É um conceito muito 
utilizado em sistemas operacionais compatíveis com POSIX (Portable Operating System 
Interface) [31], [32] e [33]. O conceito de canalização também existe em sistemas 
operacionais Windows, porém a maneira que são criados e operados é bem diferente [24]. 
A utilização de pipes implica que a saída de um processo é utilizada como entrada de 
outro – uma situação parecida com a abordada no mecanismo de comunicação por 
arquivos e que não é uma solução viável para co-simulação. Porém existe um mecanismo 
levemente diferente para a comunicação entre os processos e que recebe o nome de pipes 
nomeados, em inglês named pipes e que também pode ser chamado de FIFO (First in 
First Out), sendo suportado pela maioria dos sistemas operacionais atuais [34] e [35]. O 
funcionamento dos pipes nomeados depende do sistema de arquivos, sendo que não são 
realizadas leituras e escritas em arquivos no disco. Com isso, os tempos de acesso são 
reduzidos em relação ao mecanismo que utiliza arquivos. 
A utilização de pipes nomeados varia conforme o sistema operacional, porém 
o funcionamento é o mesmo. É criado um canal de dados unidirecional entre dois 
processos do sistema, nesse caso entre o Simulador A e o Simulador B. Sempre que o 
Simulador A precisar enviar dados para o Simulador B basta efetuar uma escrita no pipe 
correspondente que o Simulador B é notificado. O mesmo acontece quando o Simulador 
B precisar enviar dados para o Simulador A, porém será necessário utilizar um pipe 
diferente e que permita o tráfego de dados do Simulador B para o Simulador A. Esse 
mecanismode comunicação pode ser utilizado para facilmente implementar os métodos 
31 
 
 
 
de sincronismo do Passo Temporal e Mestre-Escravo. Não é aconselhável utilizar esse 
mecanismo para métodos que utilizam lista de eventos pois além de problemas de 
desempenho, a comunicação unidirecional dificulta a criação de uma lista única que pode 
ser lida e atualizada por todos simuladores [36]. 
2.2.3 Filas de Mensagens 
Um outro mecanismo de comunicação que pode ser utilizado para realizar a 
comunicação dos simuladores durante a co-simulação é chamado de fila de mensagens 
[37], [38] e [39]. É um recurso que utiliza o sistema operacional para entregar mensagens 
entre os processos e garante-se que as mensagens sejam entregues na ordem de envio. A 
implementação de fila de mensagens é dependente do sistema operacional utilizado, 
tornando difícil sua utilização mediante a utilização de mais de um sistema operacional. 
A utilização de mais de computador também pode aumentar a complexidade dependendo 
do sistema operacional que for utilizado. Na maioria dos sistemas operacionais modernos, 
a fila de mensagens é um mecanismo de comunicação unidirecional em que apenas um 
processo pode obter permissão de escrita em um instante de tempo. Portanto, para obter 
uma comunicação bidirecional full-duplex é necessário utilizar mais de uma fila de 
mensagens entre os simuladores. Existem protocolos que utilizam fila de mensagem para 
comunicação como AMQP [40] ou MQTT [41] e que podem facilitar a comunicação 
entre computadores e/ou sistema operacionais distintos. A dificuldade de implementação 
desse método é moderada. São necessário conhecimentos do sistema operacional que está 
sendo utilizado ou de protocolos que implementam fila de mensagens. É necessário 
também observar se o protocolo ou biblioteca utilizado para a comunicação por fila de 
mensagens é síncrono ou assíncrono para garantir que as mensagens sejam entregues na 
ordem e no tempo corretos. 
É possível utilizar a fila de mensagens para implementar os métodos de 
sincronismo do tipo Passo Temporal e Mestre-Escravo. A utilização desse mecanismo 
com métodos que utilizam Fila de Eventos não é aconselhável quando não for possível 
utilizar uma única fila de mensagens para a comunicação dos simuladores. 
32 
 
 
 
2.2.4 Interface COM 
Um outro mecanismo de comunicação entre os simuladores é através da 
interface COM (Component Object Model), uma interface binária desenvolvida pela 
Microsoft e presente no sistema operacional Windows. Com essa interface é possível 
realizar a comunicação entre processos através da criação de objetos compartilhados. 
Uma das vantagens da interface COM é poder ser utilizada por diversas linguagens de 
programação como C++, Python, C#, Java e, também, por diversos softwares e 
simuladores como OpenDSS, Excel, MATLAB, AIMMS, etc. A interface COM permite 
uma grande flexibilidade de linguagens, por exemplo, permitindo facilmente trocar a 
linguagem utilizada de C++ para Python. Porém a interface COM está limitada ao sistema 
operacional Windows e, portanto, restringindo a sua utilização como mecanismo de 
comunicação entre simuladores apenas para simuladores que utilizem o sistema 
operacional Windows. Outra desvantagem da interface COM são os grandes tempos de 
acesso que podem impactar no desempenho da co-simulação. 
É possível utilizar todos os métodos de sincronismo através da interface 
COM. Contudo, devido aos altos tempos de acesso não é recomendada a utilização para 
métodos que utilizam Lista de Eventos ou quando for necessária a troca frequente de 
dados entre os simuladores. A dificuldade de implementação desse mecanismo varia entre 
simples e mediana, dependendo dos simuladores e linguagens de programação adotados. 
2.2.5 Memória Compartilhada 
Também é possível utilizar a memória RAM do computador para realizar a 
transferência de dados entre os simuladores, esse mecanismo é chamado de memória 
compartilhada. A maioria dos sistemas operacionais modernos tem suporte à criação de 
uma área compartilhada de RAM, onde processos autorizados podem realizar leituras 
e/ou escritas [42], [43] e [44]. Uma das principais vantagens ao utilizar uma área de 
memória compartilhada é tempo de acesso reduzido, uma grande vantagem da memória 
RAM em relação a acessos que dependem de operações em disco ou de componentes de 
33 
 
 
 
rede. A utilização desse mecanismo requer alguns cuidados devido à alta suscetibilidade 
a problemas como inconsistência de dados, condições de corridas e outros problemas 
relacionados à concorrência de acesso. É possível utilizar vários computadores presentes 
na rede local utilizando compartilhamento de memória, porém é necessário criar uma 
estrutura compartilhada para executar processos, por exemplo, a criação de um cluster 
[45]. A utilização de memória compartilhada com sistemas operacionais diferentes pode 
ser bem complexa. 
A complexidade de implementação desse mecanismo é alta devido aos 
cuidados e proteções necessárias para manter a integridade de dados em uma região 
compartilhada de memória, mas que pode ser recompensado devido aos baixos tempos 
de acesso a memória RAM e que podem potencialmente gerar um desempenho melhor 
que os outros mecanismos. Também é recomendado para ser utilizado com métodos de 
sincronismo que utilizam Lista de Eventos. 
2.2.6 Sockets 
É possível utilizar a comunicação ponto a ponto através da rede para a troca 
de dados entre os simuladores, esse mecanismo recebe o nome de socket. Atualmente o 
termo socket está diretamente associado com sockets que utilizam o protocolo de internet, 
o protocolo IP (Internet Protocol), um protocolo que permite entregar o pacote ao destino 
apenas com o endereço presente no cabeçalho. A versatilidade dos sockets para a 
comunicação entre processos no mesmo computador, na rede local ou até mesmo através 
da internet fez com que esse mecanismo se tornasse bastante popular nos últimos anos e 
utilizados para diferentes tipos de aplicação. Os dois tipos mais comuns de sockets são 
chamados de socket UDP (User Datagram Protocol) e socket TCP (Transmission Control 
Protocol). 
Sockets UDP recebem esse nome por utilizar o protocolo UDP para 
transmissão de dados através da rede. Esse protocolo possui baixa latência e um cabeçalho 
pequeno, que não aumenta demasiadamente o tamanho da mensagem enviada. É um 
protocolo considerado não confiável por não garantir que os pacotes enviados sejam 
entregues ou que sejam entregues na ordem de envio. A mensagem enviada pelo nó de 
34 
 
 
 
destino para o nó de origem utilizando o protocolo UDP recebe o nome de datagrama, em 
inglês datagram, e são delimitadas o que significa que uma operação de leitura a um 
socket UDP retornará um datagrama. A utilização do protocolo UDP é recomendada 
quando se deseja uma baixa latência e/ou um cabeçalho pequeno, e a não entrega de 
mensagens ou entrega fora de ordem não causa um grande impacto. Para a co-simulação, 
é necessário que as mensagens sejam entregues e na ordem correta. Portanto o protocolo 
UDP não é recomendado como mecanismo de comunicação entre os simuladores. 
A utilização do protocolo TCP para envio de dados através da rede caracteriza 
um socket TCP, um protocolo considerado confiável e que garante a entrega das 
mensagens e na ordem de envio. Essa confiabilidade é obtida através da utilização de 
conexões e de um cabeçalho maior e que geram latências e mensagens maiores. Outra 
diferença para o UDP é a forma que as mensagens são enviadas, o protocolo TCP utiliza 
um fluxo de dados, em inglês streaming. Primeiramente é necessário que uma conexão 
seja estabelecida entre o nó de origem e o nó de destino, isso é feito através de um 
processo chamado de handshake, após o estabelecimento da conexão é possível enviar 
mensagens de maneira continua. Para o nó de destino não existe uma borda de mensagem 
claramente definidae cada operação de leitura de um socket TCP pode retornar mais de 
uma mensagem. Ao contrário do protocolo UDP é comum que primeiramente seja 
enviada uma mensagem de tamanho conhecido informando a quantidade de bytes que é 
enviada, e na leitura seguinte é feita uma a leitura do socket até que a quantidade 
informada de bytes seja obtida. 
 
35 
 
 
 
3 DESENVOLVIMENTO DO CO-SIMULADOR 
Este capítulo apresenta detalhes do desenvolvimento do co-simulador 
implementado. Desenvolveu-se um motor de co-simulação, em inglês engine, utilizando 
os simuladores de código aberto OpenDSS [22] e OMNeT++ [20] para realizar a 
simulação da rede elétrica e da rede de telecomunicação respectivamente. Em conjunto 
com a engine foi desenvolvido um framework de apoio para o simulador OMNeT++. Esse 
framework tem o objetivo de facilitar a utilização da co-simulação nos projetos criados 
no OMNeT++ bastando adicioná-lo ao projeto e utilizar as classes criadas. Nas próximas 
seções são descritos o papel de cada um dos simuladores, da engine e do framework, o 
método de sincronismo utilizado, e o mecanismo de comunicação entre os simuladores. 
3.1 SIMULADOR DA REDE ELÉTRICA 
A simulação da rede elétrica é realizada pelo software OpenDSS [22], um 
simulador bem versátil que pode realizar fluxo de carga trifásico, fluxo de carga 
harmônico, análise de curto-circuito, etc. O OpenDSS também pode realizar cálculos ao 
longo de um período através de um modo chamado série temporal, em inglês time series. 
Nesse modo é realizada uma série de cálculos de fluxo de carga sequenciais avançando 
no tempo por um intervalo Δt e as cargas irão variar no tempo de acordo com uma curva 
de carga pré-definida. No modo série temporal o OpenDSS executa a simulação no 
domínio do tempo (TDS) e esse é o modo utilizado pelo co-simulador desenvolvido neste 
trabalho permitindo que os elementos do circuito como cargas, geradores fotovoltaicos 
(PVs) e outros elementos sigam uma curva pré-determinada de variação no tempo. 
36 
 
 
 
3.2 SIMULADOR DA REDE DE COMUNICAÇÃO 
A simulação da rede de comunicação é realizada pelo software OMNeT++ 
[20], um simulador de código aberto desenvolvido em C++ com uma arquitetura modular 
e flexível que permite simular diversas tecnologias e topologias de rede. É um projeto 
com desenvolvimento ativo que recebe novas versões frequentemente [46] com diversos 
frameworks desenvolvidos para estender os modelos presentes e adicionar a capacidade 
de simular novos tipos de rede ou elementos, como por exemplo redes LTE [47]. As 
simulações do OMNeT++ são executadas no domínio de eventos (EDS) e uma classe 
chamada Scheduler é responsável por agendar e garantir que os eventos da simulação são 
executados na ordem e tempo corretos. Se for desejado utilizar um método de sincronismo 
que utilize Lista de Eventos, a classe Scheduler deve ser modificada, porém a dificuldade 
desse procedimento é considerável e os resultados podem não ser satisfatórios [21]. 
Então, torna-se necessário buscar uma outra maneira de integrar o OMNeT++ a um 
ambiente de co-simulação. A utilização do método de sincronismo Mestre-Escravo-Ativo 
junto ao framework de apoio à co-simulação permite que o sincronismo com o OpenDSS 
seja realizado de uma maneira mais simples. 
3.3 REQUISITOS MÍNIMOS 
Cada um dos simuladores utilizados neste trabalho e a engine desenvolvida 
possuem uma série de requisitos mínimos de software e hardware para que possam 
funcionar corretamente. Esses requisitos incluem o tipo e a versão do sistema operacional, 
bibliotecas, e softwares que devem estar instalados em cada um dos computadores. A 
Tabela 1 apresenta a lista completa de requisitos de software para utilizar o co-simulador 
desenvolvido neste trabalho. É importante observar que alguns softwares ou frameworks 
devem ser utilizados em versões específicas e que estão identificados através da coluna 
“Permite Versão Mais Recente”. 
 
37 
 
 
 
Tabela 1 - Requisitos de Software para utilização do co-simulador. 
Software/Framework Versão Mínima Versão Utilizada Permite Versão Mais Recente 
Microsoft Windows 7 10 ü 
Linux Ubuntu 16.04/Mint 18.3 Mint 18.3 ü 
Python 3.5 3.6 ü 
.Net Framework 4.5.2 4.6 ü 
SQLite 3 3 ü 
OpenDSS 7.6.5.52 7.6.5.52 ü 
OMNeT++ 4.6 4.6 û 
INET Framework 2.3 2.3 û 
SimuLTE 0.9.1 0.9.1 û 
 
Para o hardware, os requisitos são menos restritivos, sendo apenas necessário 
ter um hardware que possa executar os sistemas operacionais e componentes listados 
acima. Porém, ao aumentar o tamanho da rede simulada são necessários mais recursos de 
hardware como memória RAM e capacidade de processamento. 
A Tabela 2 apresenta os requisitos de hardware para realizar a simulação da 
rede elétrica e executar a engine de co-simulação. A Tabela 3 apresenta os requisitos 
mínimos para executar a simulação da rede de comunicação através do OMNeT++. 
Também são apresentadas as configurações de hardware utilizadas durante esse trabalho 
e que são uma sugestão para a co-simulação de redes maiores como a EPRI M1 [48] 
utilizando mais de uma tecnologia de transmissão de dados. 
 
Tabela 2 - Requisitos de hardware para simular a rede elétrica. 
Componente Configuração Mínima Configuração Utilizada 
Processador x86/x64 - Dual Core AMD FX 8150 
RAM 4 GB 32 GB 
Armazenamento (SSD) û 256 GB 
Armazenamento (HD) 500 GB 4 TB 
Interface de Rede Fast Ethernet 1 GbE 
 
38 
 
 
 
Tabela 3 - Requisitos de hardware para simular a rede de comunicação. 
Componente Configuração Mínima Configuração Utilizada 
Processador x86/x64 - Quad Core AMD Ryzen 7 1800x 
RAM 8 GB 32 GB 
Armazenamento (SSD) û 256 GB 
Armazenamento (HD) 1 TB 4 TB 
Interface de Rede Fast Ethernet 1 GbE 
 
3.4 ARQUITETURA E ESTRUTURA DO CO-SIMULADOR 
Como mencionado anteriormente, o co-simulador desenvolvido neste 
trabalho integra os simuladores OpenDSS e OMNeT++ para realizar a simulação de rede 
inteligentes de distribuição de energia através da co-simulação. A Engine de co-simulação 
desenvolvida em C# e o framework de apoio a co-simulação desenvolvido em C++ são 
parte do co-simulador e ambos são de código aberto e com licença GPLv3. 
O sincronismo entre os simuladores utiliza o Método Mestre-Escravo-Ativo 
(MAS), com o OMNeT++ sendo designado Mestre sendo responsável por controlar o 
tempo da simulação e enviar comando para o OpenDSS que é o Escravo. Toda a 
comunicação entre os simuladores é realizada através de sockets TCP e intermediada pela 
Engine de co-simulação. Devido a utilização de sockets TCP é necessário garantir que os 
computadores utilizados na co-simulação estejam na mesma rede local (LAN) e de 
preferência conectados ao mesmo roteador ou switch para reduzir a latência e com as 
portas utilizadas pelo co-simulador abertas para o protocolo TCP. As portas utilizadas são 
17654 para medições e ações de controle e 17655 para alarmes. 
Neste trabalho, considera-se violação de tensão quando a tensão for superior 
a 1,05 pu ou inferior a 0,95 pu e na ocorrência de alguma violação o Escravo envia 
mensagens de alarme para o Mestre. A arquitetura do co-simulador pode ser dividida em 
três partes funcionais sendo elas: Engine de Co-Simulação, Simulação da Rede Elétrica 
e Simulação da Rede de Comunicação (o framework de apoio a co-simulação é 
considerado parte da simulação da rede de comunicação) e que podem ser visualizadas 
na Figura 6. 
39 
 
 
 
 
Figura 6 - Arquitetura do co-simulador. 
Toda a comunicação entre os simuladores é mediada e gerenciada pelo 
Gerenciador, responsável por garantir a correta comunicação entre os simuladores, 
identificar e corrigir problemas que possam ocorrer com as mensagens ou o sincronismo. 
Outro papel desempenhado pela Engine de Co-Simulação é emular o comportamento da 
Central de Controle ou DMS (Distribution Management System) onde as medições e 
alarmes serão recebidos e armazenados, e de onde ações de controle serão enviadas paragarantir a operação da rede de distribuição. A Engine de Co-Simulação está localizada no 
mesmo computador que a simulação da rede elétrica é realizada. 
A Simulação da Rede Elétrica é executada em um computador com o sistema 
operacional Windows e é composta pelo simulador OpenDSS e uma entidade chamada 
de Controlador, que é responsável por controlar o OpenDSS através da interface COM de 
acordo com as requisições e comandos recebidos do Mestre através da Engine de Co-
Simulação. Também é função do Controlador enviar para a Engine de Co-Simulação os 
alarmes que forem gerados devido a violações de tensão que ocorrerem na rede elétrica e 
garantir que as ações de controle recebidas serão executadas. 
Central de Controle
Gerenciador
OMNeT++
OpenDSS
Controlador
Engine de Co-Simulação
Simulação da Rede ElétricaSimulação da Rede de Comunicação
Socket TCP Socket TCP
40 
 
 
 
A Simulação da Rede de Comunicação é executada em um computador com 
o sistema operacional Linux e composta pelo OMNeT++. Para que as requisições sejam 
enviadas e as medições e alarmes sejam recebidos é necessário utilizar o framework de 
apoio a simulação que deve ser importado dentro do workspace do OMNeT++. Esse 
framework cria classes cliente e servidor TCP que são utilizados para a comunicação entre 
os elementos modelados dentro do OMNeT++ e adicionam suporte a comunicação com 
a Engine de Co-Simulação. 
3.5 PROTOCOLO DE COMUNICAÇÃO ENTRE OS SIMULADORES 
O protocolo TCP é um protocolo da camada de transporte, portanto é 
necessário definir um protocolo na camada de aplicação para garantir a correta 
comunicação entre os simuladores, identificando o tipo de mensagem que está sendo 
enviada ou recebida e os dados que estão presentes. Neste trabalho foi desenvolvido um 
protocolo simples que utiliza um cabeçalho para identificar o tipo da mensagem, um 
campo contendo o tempo da simulação seguido do conteúdo como mostrado na Figura 7. 
Foram definidos quatro tipos de mensagem, que cobrem requisições de medição, 
informações de medição, alarmes, e ações de controle. Para cada tipo de mensagem é 
esperada uma resposta que pode consistir de uma confirmação de recebimento, uma 
indicação de mensagem em formato incorreto, ou dados para que o outro simulador 
continue a execução da simulação. O tratamento dessas mensagens é feito na Engine de 
Co-Simulação que segue com o procedimento correto para cada mensagem e resposta 
recebida. 
41 
 
 
 
 
Figura 7 - Estrutura da mensagem de dados trocada entre os simuladores. 
 
Para obter resultados mais reais é necessário também escolher um protocolo 
a ser utilizado para transmitir as mensagens pela rede de comunicação simulada no 
OMNeT++. Essas mensagens trafegam entre a Central de Controle e os Medidores. Para 
este trabalho foi escolhido o protocolo DLMS para encapsular as mensagens de requisição 
de medição e de informação de medição. Esse protocolo é muito utilizado em medidores 
com leitura automática, inclusive em medidores inteligentes de energia. O procotolo 
DLMS é um protocolo que utiliza dados em formato binário e uma configuração cliente-
servidor, onde os medidores são configurados como servidores e a central de controle ou 
central de medição é configurada como cliente e responsável por requisitar que as 
medições sejam enviadas. A implementação desse protocolo é complexa e é necessário 
se associar à organização de desenvolvimento do DLMS, pagando uma taxa alta, para 
obter a documentação completa. Porém é possível desenvolver um protocolo que emule 
o DLMS através do tamanho e formato das mensagens enviadas [49]. Neste trabalho, esse 
protocolo emulado é chamado de mock DLMS (mDLMS) e é utilizado para o 
encapsulamento das mensagens dentro da rede de comunicação simulada. 
Identificador
Tempo da Simulação
Conteúdo
Requisição de Medição
Informação de Medição
Alarme
Ação de Controle
42 
 
 
 
3.5.1 Mensagens de Requisição de Medição e Informação 
O processo de medição, como em uma rede que utiliza o protocolo DLMS, é 
dividido em duas partes. Primeiramente a Central de Controle envia uma requisição, 
encapsulada utilizando o protocolo mDLMS, para o medidor desejado indicando quais 
grandezas devem ser enviadas – neste trabalho são enviados os valores de tensão, potência 
ativa e potência reativa para cada fase presente no medidor. Ao receber a requisição o 
medidor processa a mensagem, verifica se é realmente o destinatário e então envia a 
requisição para a Engine de Co-Simulação solicitando os dados da rede elétrica 
correspondentes ao nó que o medidor está instalado, no instante de tempo atual. A Engine 
então primeiramente verifica se os dados estão disponíveis em cache e caso não estejam 
envia uma mensagem para o Controlador para que o cache seja atualizado. Ao adquirir 
os dados solicitados, a Engine encapsula-os utilizando o protocolo mDLMS e os envia 
para o medidor presente na simulação da rede de comunicação. O medidor por sua vez 
encaminha essa mensagem para a Central de Controle que ao receber verifica se os dados 
são válidos e registra os valores em um banco de dados SQLite. 
3.5.1.1 Mensagem de Requisição de Medição 
Mensagens de requisição de medição utilizando o protocolo DLMS possuem 
um cabeçalho de 12 bytes seguidos de 11 bytes para cada grandeza solicitada. Portanto 
uma requisição de tensão, potência ativa e reativa para um medidor trifásico tem o 
tamanho de 111 bytes. O protocolo mDLMS segue o mesmo padrão, é composto de um 
cabeçalho de 12 bytes contendo o código de identificação do medidor (ID) seguido por 
uma cadeia de caracteres em formato binário indicando as grandezas e fases a serem lidas 
e de um campo de preenchimento que pode ser utilizado para completar o tamanho 
esperado da mensagem como mostrado na Figura 8. 
43 
 
 
 
 
Figura 8 - Mensagens de requisição e resposta do protocolo mDLMS. 
3.5.1.2 Mensagem de Informação de Medição 
As mensagens de informação de medição utilizando o protocolo DLMS 
possuem um cabeçalho de 12 bytes seguidos de 6 bytes para cada grandeza solicitada. 
Portanto ao utilizar esse protocolo, uma mensagem de informação de medição contendo 
informações de tensão, potência ativa e potência reativa de um medidor trifásico tem o 
tamanho de 66 bytes. Novamente o protocolo mDLMS emula esse tipo de mensagem, 
onde a mensagem de informação possui um cabeçalho de 12 bytes contendo o código de 
identificação do medidor (ID), seguido de campos com a composição chave-valor para 
cada uma das grandezas solicitadas. Esses campos de chave-valor são compostos de uma 
chave de 2 bytes que contém um caractere (1 byte) indicando a grandeza e um caractere 
(1 byte) indicando a fase, seguidos do valor da grandeza representado em ponto flutuante 
(4 bytes). Por exemplo o campo chave-valor correspondente à tensão da fase 1 e com 
valor de 0,9923 pu seria representado como V10.9923. A Figura 8 ilustra a mensagem de 
informação de medição em mDLMS. 
ID do Medidor
Grandezas Requisitadas
Preenchimento
Magnitude de Tensão
Potência Ativa
Potência Reativa
ID do Medidor
V # Valor
P # Valor
Q # Valor
Requisição Resposta
44 
 
 
 
3.5.2 Mensagens de Alarme e de Ação de Controle 
As mensagens de alarme constituem um tipo especial de mensagem que foi 
criado para a utilização do método de sincronismo Mestre-Escravo-Ativo. São as únicas 
mensagens que podem ser enviadas pelo Escravo sem que exista uma mensagem anterior 
recebida do Mestre. Essas mensagens são geradas pela Engine de Co-Simulação a receber 
notificação de violação de tensão do Controlador em nós que possuem medidores 
inteligentes instalados. Após a criação, as mensagens são enviadas para os respectivos 
medidores na simulação da rede de comunicação e que então encaminham a mensagem 
diretamente para Central de Controle. Ao receber uma mensagem de alarme, a Central de 
Controle verifica se a mensagem está no formato correto e com o conteúdoválido, 
processa e registra os dados no banco de dados SQLite e pode ou não emitir ações de 
controle para os medidores presentes no sistema. Caso seja necessário efetuar ações de 
controle, a Central de Controle cria as mensagens de ação de controle necessárias e as 
envia para os medidores que necessitam de ação presente no sistema. Ao contrário das 
mensagens de requisição e de informação de medição, não foi utilizado o protocolo 
mDLMS pois o protocolo DLMS é dedicado exclusivamente para medição, e não para 
controle. Essas mensagens estão encapsuladas diretamente na mensagem de comunicação 
entre os simuladores e podem ser passadas diretamente do framework de apoio a 
simulação para a Engine e vice-versa. 
3.6 PROCESSO DE CO-SIMULAÇÃO 
Para executar a co-simulação é necessário primeiramente inicializar a Engine 
de Co-Simulação no computador com sistema operacional Windows e com o OpenDSS 
instalado e o servidor COM registrado. O processo de inicialização da Engine envolve 
inicializar o OpenDSS através da interface COM, validar o circuito e o mapeamento dos 
medidores inteligentes. Por fim, inicializa-se o servidor TCP responsável por receber 
requisições e ações de controle originadas do OMNeT++. Após o termino da inicialização 
a Engine entra em modo de espera aguardando as requisições. O próximo passo é iniciar 
45 
 
 
 
a rede de comunicação no OMNeT++, que começa a enviar requisições e receber as 
medições da Engine. É possível acompanhar o progresso da simulação através do 
OMNeT++ pela interface gráfica ou pelo console, e acompanhar as mensagens trocadas 
entre os simuladores através do console da Engine. 
Até que a primeira requisição seja recebida pela Engine, a co-simulação opera 
no modo Mestre-Escravo em que o Escravo não pode iniciar a comunicação com o 
Mestre. Após o recebimento da primeira requisição, a Engine começa a operar no modo 
Mestre-Escravo-Ativo. Nesse modo, a Engine faz com que a simulação do OpenDSS 
esteja à frente da simulação do OMNeT++ até o próximo intervalo de medição ou até que 
a primeira violação de tensão ocorra. Caso existam violações de alguma variável de 
controle, como a tensão na barra dos consumidores, a simulação do OpenDSS para e 
alarmes são enviados para o OMNeT++ que pode responder com uma ação de controle 
ou uma mensagem para continuar com a simulação. Caso existam ações de controle, a 
Engine notifica o controlador do OpenDSS para que efetue as ações. Após o término do 
envio das mensagens de ações de controle, o OMNeT++ envia a mensagem para que a 
simulação da rede elétrica continue. Esse processo se repete até que o OMNeT+ finalize 
a execução da simulação. 
 
46 
 
 
 
4 ESTUDOS DE CASO E RESULTADOS 
Para efetuar a validação do funcionamento do co-simulador desenvolvido 
nesse trabalho foi escolhida uma rede de distribuição de energia elétrica e criada uma rede 
de comunicação para operar em conjunto com a rede de distribuição. A partir dessas redes 
foram criados cenários de testes distintos que visam determinar o desempenho do co-
simulador, seu correto funcionamento e a sua versatilidade através de cinco cenários que 
envolvem o controle de geradores fotovoltaicos ou localização de faltas. As redes 
escolhidas e os cenários criados visam testar as capacidades do co-simulador criando 
situações onde a comunicação entre os simuladores utilizados seja elevada e o tempo de 
resposta seja rápido, como por exemplo a presença elevada de geração distribuída 
causando problemas de sobretensão ou a ocorrência de faltas (curtos-circuitos) durante a 
operação da rede. 
4.1 ESTRUTURA DA REDE DE DISTRIBUIÇÃO E DE COMUNICAÇÃO 
A rede IEEE de 123 barras, mostrada na Figura 9 [49], foi escolhida para 
realizar os testes com o co-simulador desenvolvido neste trabalho. É uma rede de testes 
criada pelo IEEE, possui um alimentador com tensão nominal de 4,16 kV e é composta 
por uma subestação localizada no barramento 150, 123 barramentos que contemplam 90 
nós de carga. Também possui reguladores de tensão, capacitores shunt, e diversas chaves. 
É uma rede que foi criada para realçar problemas de queda de tensão que são resolvidos 
com a utilização de reguladores ou banco de capacitores [50]. Com a rede base, foi 
definida uma curva de carga discretizada em 15 s, que também é o passo da simulação 
executada em modo série temporal. Foram instalados medidores inteligentes em todos os 
nós de cargas presentes no circuito, totalizando 90 medidores, e a Central de Controle 
realiza a leitura desses medidores a cada 60 s através do envio de requisições de medição 
para cada um deles. 
47 
 
 
 
 
Figura 9 - Rede IEEE de 123 barras. 
 
A Figura 10 apresenta a rede de comunicação utilizada para esse sistema. Para 
simplificar o processo de validação do co-simulador e avaliação de seu desempenho a 
rede de comunicação utilizada nesse trabalho é dedicada e é composta por medidores 
inteligentes com comunicação bidirecional através da rede LTE. Esses medidores se 
comunicam com a subestação através de uma eNodeB localizada aproximadamente no 
centro do sistema de distribuição. A Central de Controle está localizada na subestação 
que corresponde ao barramento 150 mostrado na Figura 9, a comunicação da Central de 
Controle com a eNodeB é feito através de um backbone de fibra óptica. 
 
 
1
3
4
5 6
2
7 8
12
11 14
10
20
19
22
21
18
35
37
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
575859
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 610
 9
24
23
251
195
451
149
350
76
98
76
48 
 
 
 
 
Figura 10 - Rede de comunicação utilizada. 
4.2 CENÁRIOS DE TESTE 
Os cenários de testes utilizados nesse trabalho são simulados por duas horas, 
entre 11:00 e 13:00, horário de pico de geração dos geradores fotovoltaicos (PVs) e se 
presentes no sistema, espera-se que causem problemas de sobretensão. A leitura dos 
medidores é realizada pela Central de Controle através do envio de requisições de 
medição os primeiros 10 s do início da simulação e repete as requisições a cada 60 s. 
Esses cenários podem ser divididos em Cenário Base, Cenários com PVs, e Cenários de 
Falta. A definição das redes de distribuição e de comunicação e a alocação dos medidores 
em todos os nós de carga compõe o que é chamado de Cenário Base e será utilizado como 
base de comparação para todos outros cenários. Equipamentos como reguladores e chaves 
e banco de capacitores instalados na rede de distribuição possuem apenas controle local 
49 
 
 
 
e não podem se comunicar com a Central de Controle e, portanto, nenhum desses 
equipamentos será monitorado ou controlado remotamente pela Central de Controle. 
4.2.1 Cenários de Controle de Tensão 
Para testar a capacidade do co-simulador de tratar alarmes e enviar ações de 
controle corretamente foram desenvolvidos cenários que contam com geração distribuída. 
Essa geração é composta da PVs que foram instalados em todos os nós de carga do 
sistema, nos mesmos pontos onde existe a instalação de medidores inteligentes. Todos os 
PVs instalados são monofásicos e possuem a potência instalada com 90 kW e inversor de 
98 kVA. Os inversores instalados em conjunto com os PVs possuem a capacidade de 
controlar o fator de potência de operação e assim permitindo a operação com um fator de 
potência indutivo que pode ajudar a reduzir problemas de sobretensão. É possível realizar 
o controle dos inversores de três maneiras: Controle local apenas observando os valores 
de tensão utilizando por exemplo o controle Volt-Var; Controle centralizado através de 
comandos enviados por uma central de controle; Controle hierárquico com um controle 
local e um