Desenvolvimento de um co-simulador para redes inteligentes de distribuição de energia elétrica

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

Ficha catalográfica

Universidade Estadual de Campinas Biblioteca da Área de Engenharia e Arquitetura

Luciana Pietrosanto Milla - CRB 8/8129

Ferreira, Hélder Saldanha,

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

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

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

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

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

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.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

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

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

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 de distribuiçã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].

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.

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 recebida Perfil das cargas

ajustado para o momento do

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

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 determinados eventos 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.

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

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

t

t

t

t

Lista de Eventos

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.

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

t

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 intervalo de 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

t

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

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.

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 mecanismo de comunicação pode ser utilizado para facilmente implementar os métodos

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.

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

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

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 definida e 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.

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.

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”.

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

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.

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 para garantir 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étrica Simulação da Rede de Comunicação

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.

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

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.

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

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údo vá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