96
Universidade Federal de Pernambuco Centro de Tecnologia e Geociências Curso de Especialização em Engenharia de Instrumentação Avaliação do desempenho da comunicação de dados baseada na IEC 61850 aplicada a refinarias de petróleo Vinícius Machado Moreira Orientador: Edval J. P. Santos, PhD Monografia apresentada ao Centro de Tecnologia e Geociências da Universidade Federal de Pernambuco como parte dos requisitos para obtenção do Certificado de Especialista em Engenharia de Instrumentação Recife, 2009 1

Vinícius Machado Moreira

  • Upload
    hahuong

  • View
    238

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Vinícius Machado Moreira

Universidade Federal de PernambucoCentro de Tecnologia e Geociências

Curso de Especialização em Engenharia de Instrumentação

Avaliação do desempenho da comunicação de dados baseada na IEC 61850 aplicada a refinarias de petróleo

Vinícius Machado Moreira

Orientador: Edval J. P. Santos, PhD

Monografia apresentada ao Centro de Tecnologia e Geociências da Universidade Federal de Pernambuco como parte dos requisitos para obtenção do Certificado de Especialista em Engenharia de Instrumentação

Recife, 2009

1

Page 2: Vinícius Machado Moreira

Resumo

Avaliação do desempenho da comunicação de dados baseada na IEC 61850 aplicada a refinarias de petróleo

Vinícius Machado Moreira

Fevereiro/2009

Orientador: Edval J. P. Santos, PhDÁrea de concentração: Eletro-EletrônicaPalavras-chave: Subestações, IEDs, IEC 61850, simulações computacionais.

Neste trabalho é proposto o desenvolvimento de uma plataforma computacional de modelagem e simulação de uma rede de comunicação para um sistema de automação da PETROBRAS, utilizando os preceitos da norma IEC 61850, que atualmente está se tornando uma tendência na especificação de SASs – Substation Automation Systems dentro desta empresa. A norma se baseia em sistemas supervisórios de controle e proteção distribuída com utilização de IEDs – Intelligent Electronic Devices, interligados por rede de comunicação com protocolo aberto, inclusive utilizando o TCP/IP e também o menos comum OSI CO, ambos para aplicações não críticas e o grande recurso para aplicações mais críticas, o pacote tipo GOOSE, que será bastante explorado neste trabalho.

A plataforma utiliza uma classificação bastante interessante de IEDs, que são divididos em três tipos : os breakers IEDs, os IEDs tipo MU – Merging Units e os IEDs P&C – Protection and Control, de acordo com suas funcionalidades, e suas camadas de protocolos de comunicação. Vale ressaltar que esta classificação partiu de um trabalho de pesquisa do IEEE, fazendo uso de um software, em versão educacional, o OPNET Modeler. A versão deste software é bastante acessível pela Internet, fácil de baixar e de instalar sem maiores dificuldades, e compatível com o Windows XP. Para o funcionamento das simulações pelo software é necessária a instalação do Visual Studio C++ devido à compilação dos arquivos de modelos de processos baseados nesta linguagem.

O OPNET Modeler é uma ferramenta que possui uma biblioteca bastante rica com as diversas tecnologias de dispositivos de redes de comunicação, além de poder dimensionar redes em diferentes escalas, topologias, cenários, como também permitir a criação de novos protocolos de comunicação, através de editores de modelos de processo, representados por um número finito de máquinas de estado e suas respectivas transições entre estados. As informações relacionadas ao funcionamento de cada modelo de processo são organizadas por blocos, contendo as variáveis de processo, as macros, as funções, as rotinas de execução, voltadas para a programação de redes de computadores.

Após a modelagem dos dispositivos são realizadas simulações computacionais no OPNET Modeler com o modelo da topologia de rede de um SAS, já testado, em simulação com IEDs reais, em laboratório da USP- Universidade de São Paulo. Nesta ocasião, na USP, nascia a nova proposta de um sistema baseado na IEC 61850 para atendimento a uma refinaria do sistema PETROBRAS, a RPBC – Refinaria Presidente Bernardes de Cubatão.

2

Page 3: Vinícius Machado Moreira

LISTA DE FIGURAS

Figura 1 - Diagrama : Exemplos de protocolos de comunicação.........................8Figura 2 – Perfis das camadas de comunicação da IEC 61850 para os diversos modelos de informação.....................................................................................11Figura 3 – Módulos dentro de um modelo de nó de uma estação de trabalho Ethernet.............................................................................................................17Figura 4 – Modelo de processo do módulo TCP de um modelo de nó de uma estação de trabalho Ethernet............................................................................18Figura 5 – Tela da área de trabalho de editor de projeto com uma rede topologia estrela................................................................................................19Figura 6 – Tela de apresentação da documentação em html do OPNET Modeler..........................................................................................................................20Figura 7– Tela de apresentação do IT GURU......................................................21Figura 8 – Tela de apresentação do OPNET Modeler.........................................21Figura 9 – Modelo de nó do P&C IED – topologia estrela...................................26 Figura 10 – Trechos de código de IPX/SPX antes e após as adaptações......28Figura 11 – Trechos de código de IP antes e após as adaptações....................29Figura 12 – Modelo de nó do Breaker IED – topologia estrela............................29Figura 13 – Modelo de processo da GOOSE source do P&C IED........................30Figura 14 – Modelo de processo da GOOSE source do Breaker IED...................31Figura 15 – Header Block do Modelo de processo da GOOSE source do Breaker IED.....................................................................................................................32Figura 16– Rotina de execução da máquina de estado generate do Modelo... .33Figura 17 – Modelo de nó do MU IED – topologia estrela...................................34Figura 18– Mapeamento das subnets da planta da RPBC..................................36Figura 19 – Tempo ETE de um pacote que sai do IED P&C do TIE em direção aos IEDs dos disjuntores A e B (todos os cenários).................................................38Figura 20– Tempo ETE de pacotes que saem dos breakers IEDs em direção ao P&C IED do TIE (cenários 1 a 3 somente tráfego FTP e Database e cenário 1 original).............................................................................................................39Figura 21– Tempo ETE de pacotes que saem dos breakers IEDs em direção ao P&C IED do TIE .................................................................................................40Figura 22– Tempo ETE de pacotes que saem dos breakers IEDs em direção ao P&C IED do TIE (cenários 1 a 4 com micro SINK LOAD)....................................41Figura 23 – Tempo ETE de um pacote que sai do P&C IED do alimentador na SE C-14 em direção aos IEDs localizados à montante (cenários 1 a 3).................44Figura 24 – Tempo ETE de resposta de pacotes que retornam dos breakers IEDs em direção ao P&C IED localizado à jusante (cenários 2 e 3)...........................46Figura 25– Tempo ETE de resposta de pacotes que retornam dos breakers IEDs em direção ao P&C IED localizado à montante (cenários 4 e 5).......................47Figura 26 – Tempo ETE de pacotes que partem do P&C IED em direção aos breakers IEDs localizados na SE C-17 (cenários 4 e 5)....................................47

3

Page 4: Vinícius Machado Moreira

LISTA DE TABELAS

Tabela 1- Uma comparação adaptada entre as camadas OSI e TCP/IP...............5Tabela 2 – Divisões da Norma IEC 61850..........................................................10

4

Page 5: Vinícius Machado Moreira

LISTA DE ABREVIATURAS

ANSI American National Standards InstituteARP Address Resolution ProtocolBRK IED Breaker IEDCAN Controller Area NetworkCIM Computer Integrated ManufacturingCO Connection OrientedCPU Central Process UnitCSMA/CD Carrier Sense Multiple Access / Collision DetectionDARPA Defense Advanced Research Protection AgencyDCS Distributed Control SystemDHCP Dynamic Host Configuration ProtocolDNP Distributed Network ProtocolEIA Electronic Industries AllianceEMI Electromagnetic InterferenceEPRI Electrical Power Research InstituteETE End-to-endFTP File Transfer ProtocolGOOSE Generic Object Oriented Substation EventGPS Global Positioning SystemGSSE Generic Substation Status EventHVAC Heating, Ventilation and Air ConditioningIEDs Intelligent Electronic DevicesIEEE Institute of Electrical and Electronics Engineers IHM Interface Homem MáquinaIRIG-B Inter-Range Instrumentation GroupISO International Organization for Standardization LAN Local Area NetworkLLC Logical Link ControlLN Logical NodeLON Local Operating NetworkingLPROT Laboratório de Pesquisa em Proteção de Sistemas ElétricosMAC Media Access ControlMIT Massachusetts Institute of TechnologyMMS Manufacturing Message SpecificationMU IED Merging Unit IEDMVB Multifunction Vehicle BusOPC Ole for Process ControlOPNET OPtimized Network Engineering ToolsOSI Open Systems InterconnectionP&C IED Protection and Control IEDPLCs Programmable Logic ControllersPN PainelProfibus Process Field BusQoS Quality of ServiceRPBC Refinaria Presidente Bernardes de CubatãoRTU Remote Terminal UnitSAS Substation Automation SystemSCADA Supervisory Control And Data Acquisition

5

Page 6: Vinícius Machado Moreira

SCL Substation Configuration LanguageSDCD Sistema Digital de Controle DistribuídoSE SubestaçãoSEL Schweitzer Engineering LaboratoriesSIMPASE Simpósio de Automação de Sistemas ElétricosSNTP Simple Network Time ProtocolSV Sampled ValuesTC Transformador de CorrenteTCP/IP Transmission Control Protocol/Internet ProtocolTF TrafoTP Transformador de Potencialtpal Transport Protocol Adaptation LayerUCA Utility Communication ArchitectureUDP User Datagram ProtocolUFPE Universidade Federal de PernambucoUML Unified Modeling LanguageUSP Universidade de São PauloUTE Usina TérmicaUTRs Unidades Terminais RemotasVID VLAN IdentifierVLAN Virtual Local Area NetworkXML eXtensible Markup LanguageMVA mega volt-ampérekV kilovolt

6

Page 7: Vinícius Machado Moreira

GLOSSÁRIO

2D Duas dimensões.

3D Três dimensões.

802.1Q padrão de rede criado para a otimização de VLANs, a fim de que larguras de banda de transmissão sejam devidamente otimizadas de acordo com os tipos de serviços.

aloha um dos mais antigos protocolos da subcamada de acesso ao meio, nascido na década de 70. Foi criado em uma universidade havaiana. Ele não é muito confiável e por isso mesmo já quase não é mais usado hoje em dia.

arp Address Resolution Protocol (ARP), é um protocolo que mapeia endereços IP para endereços de rede física.

average média.

broadcast informação que é enviada a toda rede de comunicação.

CAN Controller Area Network. As CANs se baseiam no conceito do uso de mensagens geradas por broadcast contendo um dispositivo central controlador de mensagens.

cliente-servidor é um modelo computacional que separa clientes e servidores, sendo interligados entre si geralmente utilizando-se uma rede de computadores. Cada instância de um cliente pode enviar requisições de dado para algum dos servidores conectados e esperar pela resposta. Por sua vez, algum dos servidores disponíveis pode aceitar tais requisições, processá-las e retornar o resultado para o cliente. Apesar de o conceito ser aplicado em diversos usos e aplicações, a arquitetura é praticamente a mesma.

database termo usado para denominar a aplicação de banco de dados no ambiente OPNET Modeler.

dhcp Dynamic Host Configuration Protocol, é um protocolo de serviço TCP/IP que oferece configuração dinâmica de terminais, com concessão de endereços IP de host e outros parâmetros de configuração para clientes de rede.

DNP Distributed Network Protocol. É um protocolo industrial utilizado por uma estação mestre para se comunicar com RTUs ou IEDs. Foi projetado para permitir comunicações confiáveis em ambientes adversos aos sistemas de automação elétrica de utilidade, sendo especificamente projetado para superar distorção induzida por EMI – Eletromagnetic Interference, componentes de envelhecimento (sua vida útil esperada pode esticar em décadas), dentre outros meios de transmissão de baixa qualidade.

7

Page 8: Vinícius Machado Moreira

Enervista Viewpoint(OPC Server) Sistema OPC Server desenvolvido pela GE, centralizado em um servidor,

responsável por interligar redes baseadas em IEC 61850 a outros sistemas de automação não baseados em IEC 61850.

eth_mac_interface subcamada que divide com a subcamada MAC a camada de interlace, que está compreendida entre a camada de rede e a camada física no modelo OSI.

Ethertype é um campo de pacote Ethernet, que define qual protocolo de camada superior o pacote transporta. O tamanho do campo Ethertype é de dois bytes.

fieldbus termo genérico para redes industriais de comunicação em tempo real.

full duplex comunicação que é realizada em sentido bidirecional e simultâneo em um link de uma rede.

função 43-ANSI classificação da tabela ANSI relacionada a transferência.

função 50 BF-ANSI classificação da tabela ANSI relacionada a função de reconhecimento de falha de disjuntor.

função 68-ANSI classificação da tabela ANSI relacionada a relé de bloqueio.

gateway ou porta de ligação, é uma máquina intermediária geralmente destinada a interligar redes, separar domínios de colisão, ou mesmo traduzir protocolos.

header block bloco do editor de modelos de processo do OPNET Modeler utilizado para centralizar os comandos (funções) de um modelo de processo, tais como funções de criação de pacotes, envio, destruição, erros , dentre outras.

high dest address maior endereço físico (MAC) da rede para envio de pacotes.

host computador.

hub ou Concentrador, é a parte central de conexão de uma rede. Muito usado no começo das redes de computadores, sendo o dispositivo ativo que concentra a ligação entre diversos computadores que estão em uma rede de área local ou LAN. Trabalha na camada física do modelo OSI, ou seja, só consegue encaminhar bits.

hub_rx nome dado ao canal de recepção físico de um modelo de nó no OPNET Modeler.

hub_tx nome dado ao canal de transmissão físico de um modelo de nó no OPNET Modeler.

IEC 60870-5 norma da IEC que trata de protocolos de telecontrole, teleproteção e sistemas de telecomunicação associados a sistemas elétricos de potência.

IEC 61850 norma da IEC que trata de sistemas de comunicação para automação de subestações.

8

Page 9: Vinícius Machado Moreira

IEEE 1588 é uma norma que define um protocolo de sincronismo chamado PTP. O PTP pode ser utilizado em redes de pacotes de telecomunicações e automação. Provê sincronismo com maior exatidão que o protocolo NTP se utilizado adequadamente.

IEEE-TR 1550 ou UCA 2.0 é um antigo relatório técnico do IEEE que se tornou fundamental para a criação da IEC 61850. Incorpora uma família de protocolos básicos de comunicação a fim de atender requisitos de uma ampla gama de sistemas.

interface termo genérico usado no OPNET Modeler, muitas vezes representando uma informação que é utilizada entre dois protocolos ou fisicamente representando uma porta de um dispositivo físico ou virtual.

internet rede mundial de computadores.

IP LOAD software gratuito utilizado para configuração de envio de pacotes a um determinado endereço IP, através de protcolos TCP ou UDP.

ip_encap módulo de processo do modelo de nó de estação ethernet que encapsula pacotes provenientes da camada superior em pacotes IP. Também desencapsula pacotes que chegam da camada inferior, a fim de transmitir os dados do usuário à camada de transporte. Este modelo serve como uma interface entre as camadas superiores e o módulo IP.

ISO 9506 é também chamado de protocolo MMS, e foi o primeiro protocolo do nível de aplicação criado para o chão de fábrica. Pela EIA- Electronic Industries Alliance é designado como RS-511. O MMS é um serviço do nível de aplicação que padroniza as mensagens de comunicação de e para dispositivos programáveis em um ambiente CIM – Computer Integrated Manufacturing.

ISO/IEC 8802-3 Padrão Ethernet.

kernel de um sistema operacional é entendido como o núcleo deste ou, numa tradução literal, cerne. Ele representa a camada de software mais próxima do hardware, sendo responsável por gerenciar os recursos do sistema computacional como um todo.

LON Local Operating Networking, ou também chamado de Lonworks é um protocolo muito popular para automação de várias funções prediais como a iluminação, ar condicionado e climatização (HVAC- Heating, Ventilation and Air Conditioning).

low dest address menor endereço físico (MAC) da rede para envio de pacotes.

Mbps Megabits per second.

Modbus protocolo industrial do tipo mestre escravo desenvolvido pela Modicon (uma empresa do grupo Schneider Electric) em 1970.

9

Page 10: Vinícius Machado Moreira

Multnet Conversor (gateway) de protocolo Modbus RTU/Modbus TCP, FAB. GE.MVB Multifunction Vehicle Bus. Protocolo usado para sistema de controle e

monitoramento de trens.

off-shore aquilo que está fora das extensões territoriais (fronteiras) de um país.

OPNET nome de um projeto de graduação para conclusão de curso na área de redes realizado por um aluno do MIT - Massachusetts Institute of Technology. Posteriormente lançado em versão comercial, o software OPNET Modeler, primeiro produto da empresa, fundada em 1986, se tornou um dos mais conhecidos softwares para modelagem e simulação de redes.

OSI CO Protocolo OSI de características funcionais semelhantes ao TCP/IP, orientado à conexão, daí o termo em inglês Connection Oriented – CO.

packet interarrival intervalo de tempo entre criação de pacotes.

packet streams feixe de pacotes.

perfil A Perfil de aplicação, contemplando as camadas de aplicação, sessão e apresentação do modelo OSI.

perfil T Perfil de transporte, contemplando as camadas que não fazem parte do perfil A no modelo OSI (transporte, rede, dados e física).

priority queueing processo de queueing com prioridade de pacotes.

publicador-assinante diferentemente da arquitetura cliente-servidor, as mensagens são publicadas em um domínio multicast ou broadcast e somente as estações interessadas, ou seja, assinantes do serviço, recebem as mensagens.

queueing termo usado em informática para o processo de espera em fila de pacotes de informação que poderão ser enviados ou recebidos em um canal de comunicação através do processo responsável pelo queueing. Na matemática chama-se teoria das filas.

Relé B30 Relé IED, FAB. GE, para proteção diferencial de barras.

Relé C60 Relé IED, FAB. GE, para proteção de disjuntores.

Relé D60 Relé IED, FAB. GE, para proteção de linhas de transmissão.

Relé F60 Relé IED, FAB. GE, para proteção de alimentadores.

Relé G60 Relé IED, FAB. GE, para proteção de geradores.

Relé L90 Relé IED, FAB. GE, para proteção diferencial de linhas de transmissão.

Relé M60 Relé IED, FAB. GE, para proteção de motores.

Relé T60 Relé IED, FAB. GE, para proteção de transformadores.

10

Page 11: Vinícius Machado Moreira

roteador do inglês router, ou encaminhador é um equipamento usado para fazer a comutação de protocolos, a comunicação entre diferentes redes de computadores provendo a comunicação entre computadores distantes entre si. Roteadores são dispositivos que operam na camada 3 do modelo OSI de referência. A principal característica desses equipamentos é selecionar a rota mais apropriada para encaminhar os pacotes recebidos. Ou seja, escolher o melhor caminho disponível na rede para um determinado destino.

service pack pacote de atualização de serviços.

sink termo usado para módulo de recebimento e destruição de pacotes no ambiente OPNET Modeler.

Sm_int_profile tipo de perfil de aplicação pré-configurado no OPNET Modeler.

source termo usado para fonte de pacotes no ambiente OPNET Modeler.

statistic wires ligação para estatísticas.

subnet sub-rede.

switch ML-1600 switch de fabricação GE, linha Multilin.

switch ML-2400 switch de fabricação GE, linha Multilin.

switch é um dispositivo utilizado em redes de computadores para reencaminhar frames entre os diversos nós. Possuem portas, assim como os concentradores (hubs) e a principal diferença entre o comutador e o concentrador é que o comutador segmenta a rede internamente, sendo que a cada porta corresponde um dominio de colisão diferente, o que significa que não haverá colisões entre pacotes de segmentos diferentes — ao contrário dos concentradores, cujas portas partilham o mesmo domínio de colisão. Outra importante diferença está relacionada ao gerenciamento da rede, pois com um switch gerenciável pode-se criar VLANS, onde deste modo a rede gerenciada fica dividida em menores segmentos.

tie interligação.

transfer time pela norma IEC 61850 é o tempo total de transferência que um pacote leva para ser transmitido de um dispositivo a outro, incluindo o tempo de processamento interno de cada dispositivo.

trip ponto em que o relé de proteção fecha os contatos de saída. Isso ocorre quando o valor da corrente ou tensão de pickup permanecem no sistema por um período de tempo especificado pelo usuário ou por um tempo definido por uma curva, também predeterminada pelo usuário.

trunks configuração que permite que uma porta de um switch possa reconhecer várias VLANs, utilizando para isto um tagueamento de pacotes.

workstation estação de trabalho.

11

Page 12: Vinícius Machado Moreira

12

Page 13: Vinícius Machado Moreira

Sumário

Capítulo 1............................................................................................................1Introdução...........................................................................................................1

1.1- Motivação..................................................................................................11.2- Cenário......................................................................................................1 ........................................................................................................................11.3- A importância de uma subestação em uma refinaria de petróleo...........21.4- Comunicação em redes ...........................................................................31.5- Protocolo de comunicação TCP/IP.............................................................41.6- Sistemas distribuídos................................................................................61.7- IEDs – Intelligent Electronic Devices.........................................................61.8- Proposta da Norma IEC 61850..................................................................71.9- Apresentação da Norma IEC 61850 .........................................................81.10 - Considerações Finais............................................................................14

Capítulo 2..........................................................................................................15Tecnologias disponíveis.....................................................................................15

2.1 - Requisitos iniciais para a instalação do OPNET Modeler........................162.2 - Apresentação do Software OPNET Modeler ...........................................162.3 - Considerações finais..............................................................................21

Capítulo 3..........................................................................................................23Simulações e Resultados Obtidos......................................................................23

3.1 - Modelagem da plataforma de simulação ..............................................233.2 – Formulação dos casos............................................................................343.2.1 – Ensaio de paralelismo momentâneo de alimentadores - Função 43 – ANSI................................................................................................................363.2.2 – Ensaio de seletividade lógica – Função 68 - ANSI...............................433.3 Considerações finais.................................................................................48

Capítulo 4..........................................................................................................49Conclusões, melhorias possíveis e trabalhos futuros........................................49

4.1 Conclusões...............................................................................................494.2 Melhorias possíveis e trabalhos futuros...................................................50

Apêndice A........................................................................................................51Apêndice B........................................................................................................55Apêndice C........................................................................................................57Apêndice D........................................................................................................68Apêndice E.........................................................................................................70Referências Bibliográficas.................................................................................78

13

Page 14: Vinícius Machado Moreira

14

Page 15: Vinícius Machado Moreira

Capítulo 1Introdução

1.1- Motivação

A motivação deste trabalho se deu pela necessidade de agregar mais conhecimentos na

área de automação de subestações. Aliado a este aspecto verifica-se uma moderna tecnologia que

vem sendo aplicada no cenário atual, o que nos leva ao encontro da IEC 61850, que trata de um

conjunto de tecnologias que juntas mudam a forma de especificar sistemas de automação de

subestações. O mercado já está se direcionando para esta tendência, e muitos usuários, como a

PETROBRAS, já comprovam seu desempenho através de testes em laboratórios consagrados. Este

assunto referente ao desempenho da comunicação de dados entre dispositivos, inserido na norma

IEC 61850 é a tônica deste trabalho, onde serão apresentados dois casos de funções executadas

atendendo aos requisitos da referida norma.

1.2- Cenário

A PETROBRAS se baseava em sistemas desenvolvidos por fabricantes de sistemas de

automação elétrica, com UTRs (Unidades Terminais Remotas) e protocolos proprietários1. No

momento atual existem investimentos em sistemas de proteção e automação baseados em IEDs -

Intelligent Electronic Devices, e não mais em UTRs, já que os IEDs possuem atualmente

capacidade para executar estas funções.

1 Protocolo proprietário é também conhecido como protocolo fechado ou privado, onde sua utilização é de exclusividade da empresa desenvolvedora.

1

Page 16: Vinícius Machado Moreira

Segundo consulta, através de e-mail, a Bulgarelli [8], verifica-se que as mais recentes

especificações em sistemas supervisórios se baseiam em protocolo da Norma IEC 61850, e não

mais em protocolos proprietários, contudo a PETROBRAS é muito grande e ainda não existe um

padrão definido dentro da empresa. Por exemplo, muitas unidades off-shore (fora da extensão

territorial) ainda se baseiam em sistemas de automação elétrica com utilização de PLCs adaptados

para as especifidades de um sistema elétrico, tal como tempo de resolução de 50 ms e descarte

seletivo de cargas em 200 ms.

Bulgarelli ainda conclui que há uma tendência para que os sistemas de automação elétrica

da PETROBRAS sejam baseados nos próprios relés digitais de proteção, pois há bastante

investimento na tecnologia de IED utilizando a norma IEC 61850 e os fabricantes têm

acompanhando este mesmo ritmo de evolução. Mas, com base nos resultados a serem obtidos com a

entrada em operação dos novos sistemas que estão sendo projetados, é que a PETROBRAS poderá

fazer ajustes finos nas especificações para os próximos empreendimentos.

1.3- A importância de uma subestação em uma refinaria de petróleo

Uma refinaria de petróleo é algo de um planejamento estratégico de vários anos para que

se inicie sua construção. Envolvem questões de naturezas diversas ao governo de uma nação,

inclusive sociais. Mas, para a operação de uma refinaria é necessária uma grande quantidade de

recursos, o principal e básico seria a matéria prima, o petróleo, podendo vir acompanhado de vários

outros, como o gás, por exemplo. Ainda assim, similarmente a um veículo, que precisa de uma

fonte química para iniciar o processo, ou seja, uma bateria para fornecer energia para o motor de

partida do mesmo, também em uma refinaria, similarmente precisa-se de energia para poder

processar o refino.

As subestações de energia elétrica são as portas de entrada dos recursos de energia elétrica

que podem ser tidos como primordiais para se manter os sistemas de processamento de refino

operando. Sendo ainda passivo de falhas, o sistema elétrico é um recurso crítico que precisa ser

tratado com cautela e prevenção, cujo estudo na Engenharia Elétrica é tema de Proteção de Sistemas

Elétricos. Assim, muito se tem melhorado em termos tecnológicos ao longo dos anos, como por

exemplo, os relés de proteção têm passado por diversas fases de evolução em sua concepção.

O relé sozinho não faz nada, ou seja, precisa enxergar as grandezas supervisionadas em

um sistema elétrico, sendo feito na sua grande maioria através de transformadores de instrumentos

(TCs e TPs), que se utilizam do princípio da conversão eletromagnética. Há também outros

equipamentos que empregam o uso de sensores de temperatura, transformam em meio óptico

2

Page 17: Vinícius Machado Moreira

enviando o sinal por meio de cabeamento óptico até finalmente converter em sinal elétrico para o

equipamento de controle, proteção e monitoramento. O relé, além dos sinais supervisionados,

também precisa de alguém atuando em resposta aos seus comandos, sendo por exemplo, o caso dos

disjuntores.

Inicialmente, a função do relé era somente de proteção, mas com a participação cada vez

maior da eletrônica digital, hoje estes dispositivos podem agregar também funções de controle,

supervisão, alarme, dentre outras, e atualmente já existem modelos chamados IEDs, Intelligent

Electronic Devices, que agregam tecnologias de comunicação em rede, com protocolos de

comunicação que os tornam implementáveis em uma rede de comunicação para sistemas de

automação de subestações – SAS [10] .

Durante anos diversas soluções proprietárias foram sendo impostas ao mercado, criando-

se barreiras aos consumidores que se viam escravos de poucas tecnologias e não tinham poder de

escolha. Como será visto a seguir, com o aparecimento do protocolo TCP/IP – Transmission

Control Protocol/Internet Protocol, um protocolo público e genérico, foi possível que todas estas

barreiras fossem desaparecendo. Muito se faz para conseguir criar uma liberdade de escolha para o

usuário, mas com a proposta da IEC 61850 um grande passo para a padronização destes

protocolos será o caminho da interoperabilidade e da intercambialidade entre IEDs de mesmo

fabricante e de fabricantes diferentes.

1.4- Comunicação em redes

Pode-se dizer que a troca de informações por um canal de comunicação é uma forma de

comunicação em rede. Dentro da engenharia, uma informação pode ser analógica, assumindo

qualquer valor ao longo do tempo dentro de um determinado intervalo, ou digital, “simbolicamente”

assumindo valores lógicos 0 (zero) ou 1 (um).

A informação analógica, mesmo podendo representar qualquer valor, possui uma grande

desvantagem devido a ruídos, ou seja, dependendo do nível de ruído entre um transmissor e um

receptor analógico, este último pode não identificar se o sinal recebido está correto ou não, e pode

aceitar a informação recebida como sendo correta, acarretando aí um grave problema.

O princípio das redes de computadores são os sistemas de informações digitais que vieram

com o aparecimento dos computadores digitais no final dos anos 60. É importante se destacar a

influência da antiga ARPA-Advanced Research Projects Agency criada pelos Estados Unidos, em

resposta ao lançamento do satélite Sputnik pela antiga União Soviética em 1959, que era

considerado uma ameaça. Uma das missões da ARPA, que em 1969 passa a se chamar DARPA

3

Page 18: Vinícius Machado Moreira

(Defense ARPA), foi a criação da ARPANET–Advanced Research Projects Agency Network, ou

seja, uma rede interna de computadores criada para interligar departamentos de pesquisa da

DARPA, de forma a agilizar uma ampla estratégia militar de defesa no território americano em caso

de ataques nucleares inimigos.

A criação da ARPANET é vista como o marco inicial que originou a Internet. Foi

necessária a criação de uma nova “linguagem” para a transmissão de dados, pois havia a

necessidade de unificação de redes de tecnologias distintas, surgindo então o protocolo TCP/IP. Ou

seja, um conjunto de protocolos que possibilitou que redes de pacotes distintos fossem

interconectadas, de forma que os computadores não mais precisassem ter o conhecimento sobre as

redes intermediárias utilizadas pelos mesmos.

1.5- Protocolo de comunicação TCP/IP

Protocolos de comunicação são as “linguagens” usadas pelos dispositivos de uma rede

para que haja um entendimento entre os mesmos durante a troca de informações. Ou seja, sem

protocolos não haveria uma forma simplificada de se transmitir qualquer informação em uma rede.

A informação precisa ser empacotada (envelopada), enviada de uma fonte e encaminhada para um

sistema de destino [2].

Quando se fala em TCP/IP, fala-se em dois importantes protocolos dentro de um conjunto

de protocolos que tornam possível o envio de uma informação desde a criação da mesma até o seu

destino. O uso do protocolo TCP/IP se torna uma vantagem em relação a outros protocolos

existentes pelo fato de ser roteável, isto é, ser criado pensando em grandes redes e longas distâncias,

onde podem haver vários caminhos para que os dados possam atingir o computador receptor.

Informações nem sempre são pequenas para serem transmitidas numa rede. Por isso, são

quebradas em partes compostas por dados binários (digitais), onde cada parte é identificada e

processada em vários estágios (camadas), tornando-se menor ou maior, a depender se é origem ou

destino, à medida que vai passando por estas camadas. Por exemplo, quando se inicia a quebra de

uma informação na origem, ou seja, a partir da camada de aplicação, tem-se uma divisão em

pequenas partes que vão sendo agregadas com uma identificação ou cabeçalho. Estas várias partes

com os seus respectivos cabeçalhos formam um quadro. Cada parte deste quadro identifica uma

camada percorrida durante o processo de quebra da informação.

Existem várias formas de se quebrar a informação, ou seja, existem modelos padronizados

pela ANSI, como também pela ISO, dependendo da complexidade com a qual a rede deseja ser

criada. O modelo TCP/IP (da ANSI-American National Standards Institute) veio antes do modelo

4

Page 19: Vinícius Machado Moreira

OSI (da ISO-International Organization for Standardization), sendo este último uma tentativa de

estabelecer uma generalização de classificação em sete camadas para todos os protocolos existentes

no mundo.

No caso da Internet, era um desejo a utilização de um protocolo que fosse independente da

evolução das tecnologias de transmissão, aberto ao público, e que fosse independente da topologia

de rede. Sendo assim, público e genérico conforme já citado, o TCP/IP permite sua implementação

por diversos fabricantes. Sua arquitetura é composta por quatro camadas, conforme mostra a

comparação entre os dois modelos na Tab. 1 [22].

Tabela 1- Uma comparação adaptada entre as camadas OSI e TCP/IP

Camadas OSI

Protocolos comuns ao OSI e ao TCP/IP

Camadas TCP/IP Observações

7 AplicaçãoSNMP, TFTP, NFS, DNS,

BOOTP

FTP, Telnet, Finger,

SMTP,POP

Aplicação

A camada de aplicação do TCP/IP corresponde às camadas de aplicação, apresentação e sessão do OSI

6Apresentaçã

o

5 Sessão

4 Transporte

utilizam UDP(não

orientado à

conexão)

utilizam TCP

(orientado à

conexão)

Transporte de Máquina

para Máquina

A camada de transporte de máquina para máquina do TCP/IP corresponde à camada de transporte do OSI

3Rede

IP Internet

A camada Internet do TCP/IP corresponde à camada de rede do OSI

2 DadosCartões de

Interface de Rede Interface de Rede

A camada de interface de rede do TCP/IP corresponde às camadas de dados e física do OSI

1 FísicaMeio de

Transmissão

O Modelo OSI é dividido em sete camadas num arranjo top-down, ou seja, o nível mais

acima (7) representa a interface humana, ou o próprio aplicativo, já o menor nível (1), não menos

importante, é o meio de transmissão (meio físico), onde efetivamente são transmitidos e recebidos

os bits devidamente codificados através de protocolos. A codificação das séries de bits

recebidos/transmitidos permite a divisão destas séries em quadros, conforme já citado

anteriormente. O modelo TCP/IP é mais simples devido à sua concepção original mais antiga ao

5

Page 20: Vinícius Machado Moreira

modelo OSI, e por isso se verifica a existência de uma camada de aplicação que engloba as três

camadas mais acima do modelo OSI, e uma camada de interface de rede que engloba as duas

camadas mais inferiores.

Quanto aos protocolos mostrados na parte central da Tab. 1 verifica-se que aonde ocorre

uma subdivisão é porque existe uma preocupação em se mostrar que há uma classificação

importante dentro da tabela, ou seja, quanto à conexão podem existir dois tipos de protocolos de

transporte: o TCP, orientado à conexão e o UDP, não orientado à conexão. Ou seja, para

aplicações que necessitam de uma confirmação de entrega de uma mensagem transmitida a um

destinatário utiliza-se o TCP, e aonde não há, utiliza-se o UDP.

1.6- Sistemas distribuídos

Os sistemas distribuídos são comumente chamados de DCS – Distributed Control System,

e surgiram da necessidade de descentralizar a função de controle que antes era feita integralmente

em um computador remoto. Ou seja, antes o sistema era totalmente dependente do correto

funcionamento do computador (host) remoto, e havia uma quantidade de cabos proporcional à

quantidade de malhas controladas. Com a invenção dos PLCs – Programmable Logic Controllers,

inicialmente criados para substituir o uso de relés auxiliares, foi possível transferir para o campo

este poder de controle, ainda mais quando estes passaram também a integrar interfaces analógicas.

Finalmente com a criação das redes de comunicação digitais houve uma verdadeira revolução na

qual cada vez mais o controle vai chegando perto do processo, ficando a supervisão remota mais

ligada à aplicação de engenharia e interface de controle humana.

Uma concepção muito comum nos antigos sistemas supervisórios são os chamados

sistemas do tipo SCADA – Supervisory Control and Data Aquisition System, onde basicamente os

hosts se localizam hierarquicamente no topo do sistema e se interligam por uma rede de

comunicação com os PLCs ou RTUs – Remote Terminal Units , e estes finalmente se interligam por

fios com o processo (no campo).

1.7- IEDs – Intelligent Electronic Devices

Os principais elementos de supervisão e controle de subestações com automação integrada

passam a ser os relés inteligentes, ou seja, relés multifunção digitais, que além da proteção, também

desempenham as funções antes executadas pelas RTUs.

Dentre os vários benefícios provenientes da substituição dos relés eletromecânicos pelos

relés multifunção microprocessados estão:

6

Page 21: Vinícius Machado Moreira

• padronização de equipamentos;

• novas funções de proteção;

• maior flexibilidade na aplicação;

• facilidades de comunicação e integração de dados;

• simplificação da manutenção; e

• novas possibilidades de aquisição de dados operacionais.

Para esses benefícios serem extraídos do sistema de proteção implantado, é preciso

analisar, e especificar uma gama muito maior de itens e um número maior de ajustes de

parametrização durante a concepção do projeto.

Do ponto de vista da manutenção, os relés digitais possuem recursos como ajuste e

aferição local, isto é, diretamente em interfaces nos painéis locais ou traseiros, programas especiais

e recursos de auto-monitoramento, que reduzem, drasticamente, o tempo gasto nestas operações;

além disto, é eliminada a necessidade de calibração como nos relés eletromecânicos. [21]

1.8- Proposta da Norma IEC 61850

Um dos principais objetivos da nova norma IEC 61850 é o de garantir a interoperabilidade

entre IEDs de diferentes fabricantes, permitindo o uso e a troca irrestrita de dados a fim de que

sejam realizadas suas funcionalidades dedicadas individuais. Assim, por interoperabilidade entende-

se a habilidade de dois ou mais IEDs de um mesmo fabricante, ou de fabricantes diferentes, de

trocar informações e usar estas informações para correta cooperação [3].

A Norma IEC61850 torna-se realidade para atender aos requisitos de mercado, e é baseada

em fortes argumentos de funcionalidades comprovadas, evolução tecnológica, especificações de

clientes e em métodos de engenharia disponibilizados pelos fabricantes.

O mercado global precisa de uma norma também global e de um padrão que suporte

todas as filosofias de operação e concepção de subestações, com uma combinação de dispositivos

sendo feita sem a necessidade de elementos que convertam a todo instante os seus protocolos. Desta

forma é possível evitar o emprego de conversores de protocolos, os gateways, os altos custos de

engenharia de integração, treinamento de pessoal, excessos de documentação e dispositivos físicos

para administração da manutenção .

7

Page 22: Vinícius Machado Moreira

Na Fig. 1 [3] tem-se o retrato de como foram utilizados alguns dos principais protocolos

de comunicação no setor elétrico antes da IEC 61850, evidenciando a presença de uma estação

gateway para compatibilização entre os diversos protocolos utilizados. A presença de variados

protocolos recai muitas vezes nas próprias características dos equipamentos de proteção e controle

utilizados, que ao longo de uma ou duas décadas vêm sofrendo rápidos avanços tecnológicos, ou

seja, no setor elétrico seria o próprio caso do relé de proteção e controle.

Figura 1 - Diagrama : Exemplos de protocolos de comunicação

1.9- Apresentação da Norma IEC 61850

Os sistemas de automação industrial modernos atingiram um certo nível de complexidade

que a intuição e experiência humana não são mais suficientes ou eficientes para consolidar

rapidamente uma modelagem bem definida dos mesmos. Um ambiente de modelagem torna-se

necessário para que se alcance esse objetivo. Nestas circunstâncias, o planejamento da arquitetura

do sistema é um dos aspectos mais importantes.

A IEC 61850 estabelece muito além de requisitos de comunicação entre IEDs, trazendo

uma visão moderna que não se prende à rápida mudança da tecnologia da comunicação, mas sim

num modelo de dados de objetos, ou seja, em partes de funções que são comuns em subestações tais

como disjuntores, controladores e proteção que podem trocar dados entre si. Estes dados possuem

determinados atributos, tais como estampas de tempo ou validade, que devem ser conhecidos ou

ajustados para que haja o correto funcionamento do sistema de automação [3]. O acesso ou troca de

8

Page 23: Vinícius Machado Moreira

dados é determinado pela padronização de serviços, garantindo a estabilidade a longo prazo,

preparada para a evolução das tecnologias de comunicação e das próprias exigências do sistema.

Os modelos de dados de objetos podem ser chamados de nós lógicos, ou LNs, do inglês,

Logical Nodes. Estes LNs trocam dados entre si e possuem as informações a serem transmitidas. A

localização destes nós não se prende a um único dispositivo físico, quando se considera que uma

função está composta em vários nós, ou seja, existe uma livre alocação de funções, que admitem

sua centralização ou descentralização.

A norma IEC 61850 estabelece uma padronização para a linguagem que mapeia os

modelos de dados de objetos, consistindo no que se chama de SCL- Substation Configuration

Language, que independe dos fabricantes de dispositivos IEDs, descrevendo o modelo de dados

com todas as suas opções, a alocação dos LNs aos diferentes dispositivos, todos os canais de

comunicação, e a alocação de funções aos equipamentos de manobras de acordo com o diagrama

unifilar. Mesmo com o uso de ferramentas de diferentes fabricantes esta linguagem deve ser capaz

de garantir a troca de dados durante o processo de engenharia, daí a origem do termo chamado

interoperabilidade, conforme citado anteriormente.

Sendo assim, com a sua publicação oficial em 2004, a IEC 61850 se tornou referência nos

novos projetos de automação de subestações, propondo-se a introduzir novos conhecimentos, entre

os quais:

- Modelagem de uma subestação de energia elétrica, com automação baseada nos

conceitos de redes e orientação a objetos, através da UML-Unified Modeling Language

e estrutura da informação proposta com Dispositivo Lógico, Nó Lógico e Objeto de

Dados;

- Emprego da Substation Configuration Language (SCL), baseada na XML – Extensible

Markup Language ;

- Emprego do mecanismo de comunicação de mensagens prioritárias, GOOSE - Generic

Object Oriented Substation Event, e dos modelos de rede Cliente/Servidor e

Publicador/Assinante ;

9

Page 24: Vinícius Machado Moreira

A norma se divide em dez partes, como apresentado na Tab.2 [3]:

Tabela 2 – Divisões da Norma IEC 61850

PARTE 1: INTRODUÇÃO E VISÃO GERAL

INFORMAÇÕES E COMPREENSÃO

PARTE 2: GLOSSÁRIO

PARTE 3: REQUISITOS GERAIS

PARTE 4:ADMINISTRAÇÃO DO PROJETO E SISTEMAS

IMPACTO EM OFERTAS E CONDUÇÃO DE PROJETO

PARTE 5: REQUISITOS DE COMUNICAÇÃOREQUISITOS BÁSICOS PARA

O PADRÃO

PARTE 6:LINGUAGEM DE CONFIGURAÇÃO DE SUBESTAÇÕES (SCL) IMPACTO NA ENGENHARIA

PARTE 7:

MODELO DE COMUNICAÇÃO (FORMATO DE DADOS E SERVIÇOS) A PARTE PRINCIPAL

PARTE 8-1:

MAPEAMENTO PARA MMS-TCP/IP – ETHERNET

MAPEAMENTO DO BARRAMENTO DA

SUBESTAÇÃO

PARTE 8-x: PARA MAPEAMENTOS FUTUROS RESERVADO PARA FUTURO

PARTE 9-1:

MAPEAMENTO PARA CONEXÕES PONTO A PONTO

EXECUÇÃO DOS MODELOS PARA ETHERNET

PARTE 9-2:

MAPEAMENTO PARA CONEXÕES DO BARRAMENTO

MAPEAMENTO DO BARRAMENTO DO

PROCESSO

A norma é bastante extensa, com mais de 1000 páginas, e neste aspecto, será comentado

apenas o que interessa para o escopo deste trabalho. Claramente, pode-se verificar que o interesse

para o desenvolvimento de uma plataforma de modelagem e simulação requer o estudo dos modelos

de dados a serem transmitidos na rede do SAS. Portanto, na Parte 5 e na Parte 8 podem ser

encontradas estas informações que basicamente são:

- Requisitos para as funções, modelos de dispositivos, tipos de mensagens – Parte 5: que

estabelece os requisitos de desempenho dos diversos tipos de mensagens, tais como taxas

de transferência de informações, em diversos tipos de arranjos de subestações,

independentemente da tecnologia de comunicação utilizada;

10

Page 25: Vinícius Machado Moreira

- Mapeamento de serviços e objetos para o protocolo MMS e ISO/IEC 8802-3 – Parte 8:

que estabelece a estrutura de perfis A – Aplication e T – Transport para os tipos de

mensagens prioritárias e não prioritárias.

Outras partes da norma podem ser consultadas para entendimento acerca de um roteiro

para a integração em sistemas reais, vislumbrando um maior aprofundamento acerca da tecnologia.

Por exemplo, a Parte 7 descreve a forma como é feita a abstração do modelo real para o modelo

abstrato, ou seja, a virtualização da subestação em nós lógicos.

O protocolo MMS – Manufacturing Message Specification é tido como um protocolo da

camada de aplicação, específico para mensagens do tipo cliente-servidor. O perfil T, ou seja, das

quatro camadas a partir da camada de transporte até a camada física pode utilizar tanto o protocolo

TCP/IP como o ISO CO, ou seja, ambos de característica orientada à conexão. Na Fig. 2 [19] pode-

se verificar de forma clara o perfil dos tipos básicos de modelos de informação da norma.

Figura 2 – Perfis das camadas de comunicação da IEC 61850 para os diversos modelos de informação

A norma define um serviço de geração de mensagens no que seria a camada de aplicação,

uma camada de transporte, uma de rede e uma de enlace. A única camada comum a todas as

11

Page 26: Vinícius Machado Moreira

mensagens, com exceção da GSSE, é a camada de enlace do padrão Ethernet usando um esquema

de prioridade de mensagens.

Algumas mensagens “saltam” camadas porque são mensagens com restrições de tempo

quanto a atrasos, sendo, portanto mapeadas direto na camada de enlace.

Uma interessante característica da norma IEC 61850 é que ao invés de determinar um

protocolo específico a ser usado em cada camada, ela define um Abstract Communication Service

Interface, ACSI, que funciona como uma interface virtual do IED. Essa interface contém os

modelos de funções dos dispositivos lógicos, os dados com seus atributos, as funções de

comunicação para acesso a variáveis, transferência de arquivos, dentre outros. Isso permite que

qualquer IED se comporte de maneira idêntica do ponto de vista da rede, pois o ACSI é

independente dos protocolos utilizados [4].

Embora a norma defina o ACSI, é necessário um conjunto real de protocolos de

comunicação para que o esquema realmente funcione, e por esse motivo são utilizados protocolos

práticos que possam operar em equipamentos normalmente encontrados na indústria.

A camada de transporte usa os protocolos TCP/UDP¸ e a camada de rede usa o IP, todos

extremamente consolidados no mercado. Os objetos do modelo de dados e suas respectivas funções

são mapeadas de acordo com o protocolo MMS, da ISO9506. Essa escolha aconteceu porque esse é

o único protocolo público que suporta a complexidade dos modelos de dados e funções da IEC

61850 [4].

As mensagens, definidas na Parte 5 da norma, são classificadas pelo desempenho em sete

classes:

- Tipo 1 – Mensagens rápidas;

- Tipo 1A – Trip;

- Tipo 2 – Velocidade média;

- Tipo 3 – Baixa velocidade;

- Tipo 4 – Dados em rajada (raw data) ou SV – sampled values;

- Tipo 5 – Transferência de arquivos;

- Tipo 6 – Sincronização de tempo.

Além desta classificação, as mensagens podem ainda se dividir em dois grupos, ou seja,

mensagens cliente-servidor que são mensagens com o formato similar a outros protocolos do tipo

12

Page 27: Vinícius Machado Moreira

mestre-escravo e as mensagens GOOSE/SV. O mapeamento dessas mensagens na pilha de

protocolos de comunicação pode ser vista na Fig. 2.

Dentro das mensagens GOOSE/SV podem ser citadas duas características que justificam

sua transmissão direta à camada de enlace:

- A mensagem tipo GOOSE, pela sua especificação, é utilizada para troca em tempo real

de lógicas de intertravamento e para envio de trip;

- As mensagens de dados em rajada (raw) ou também chamadas de SV – Sampled Values

realizam o papel de amostragem dos sinais de tensão e corrente dos TCs e TPs que fazem parte da

barra de processo, ou seja estes sinais de amostragem precisam ser reconstituídos de maneira rápida

e correta para que se obtenham as formas de onda originais.

As mensagens do tipo cliente-servidor são: Sincronização de tempo do tipo 6, Serviços

ACSI dos tipos 2, 3 e 5 e Eventos genéricos do status da subestação, GSSE, do inglês Generic

Substation Status Event, do tipo 1 e 1A.

As mensagens do tipo 6 servem para garantir a sincronização entre IEDs. O protocolo

padronizado pela norma para sincronização é o Simple Network Time Protocol, SNTP, mas existe

uma polêmica com relação à adoção desse protocolo, pois alguns fabricantes, como por exemplo, a

Schweitzer Engineering Laboratories, SEL, diz que o SNTP não é adequado para as aplicações com

precisões de até 1μs previstas na IEC 61850. A SEL adota como alternativa o IRIG-B, Inter-range

instrumentation group [5]. Oficialmente o SNTP é o padrão adotado pela IEC 61850, mas em breve

será lançado um novo padrão para sincronização, o IEEE 1588, que deve resolver a polêmica.

Como já foi dito, todas as mensagens do tipo cliente-servidor são enviadas através de

todas as camadas de rede definidas na IEC 61850. Como existe um tempo de processamento

associado a cada uma dessas camadas, as mensagens desse tipo têm um tempo de transmissão maior

que as mensagens GOOSE e SV.

As mensagens GOOSE são da classe de mensagens Generic Substation Event, GSE, assim

como as mensagens GSSE, ambas são dos mesmos tipos (1 e 1A), mas enquanto as mensagens

GSSE suportam apenas estruturas fixas de dados, as mensagens GOOSE transportam estruturas

configuráveis [4].

O termo GOOSE não é novo, ou seja, já era usado pelo protocolo UCA-Utility

Communications Architecture, o qual serviu de base para a criação do novo GOOSE da IEC 61850.

UCA era um título de um projeto, que ocorreu entre 1987 e 1999, da EPRI– Electric Power

Research Institute, e que posteriormente virou título de um relatório técnico do IEEE – Institute of

Electrical and Electronics Engineers , o IEEE TR- Technical Repo rt Nr. 1550, comumente chamado

de UCA 2.0.

13

Page 28: Vinícius Machado Moreira

Historicamente em 1998 é que a IEC e o IEEE concordam em vir com um acordo para um

padrão internacional simplificado. Sendo assim, o IEEE TR 1550 deixa de ser reconhecido como

um padrão IEEE, passando o padrão IEC 61850 a ser internacionalmente reconhecido e aceito para

a especificação de sistemas de comunicação para automação de subestações. Uma das mudanças

implementadas pela IEC foi a nomenclatura do antigo GOOSE da UCA que passa a se chamar de

GSSE.

Muitos padrões baseados em IEC 61850 estão em desenvolvimento, entre eles:

- uma extensão da IEC 61850 para monitoramento de qualidade de energia (PQM);

- uma extensão da IEC 61850 para monitoramento (estatísticas e históricos de

informação);

- IEC 61400-25 (comunicação para monitoramento e controle de plantas eólicas);

- IEC 62344 (plantas hidroelétricas – comunicação para monitoramento e controle);

- IEC 62350 (sistemas de comunicação para fontes de energia distribuída - DER).

1.10 - Considerações Finais

Nos tópicos vistos neste capítulo destacam-se alguns pré-requisitos necessários para a

implantação de uma nova forma de especificação de sistemas supervisórios:

- classificação por tipos de mensagens da IEC 61850 e respectivos mapeamentos em

termos de protocolos de comunicação;

- uso do IED, ou seja, de um dispositivo bastante aceito e empregado na área de proteção,

controle e supervisão de sistemas elétricos;

- conceito de modelo abstrato de informações com foco em nós lógicos;

- conhecimento da forma estrutural dos capítulos (partes) da IEC 61850.

No capítulo 2 são fundamentadas as tecnologias utilizadas para análise de desempenho da

comunicação de dados entre IEDs, como também os aspectos que favorecem a adoção das mesmas.

14

Page 29: Vinícius Machado Moreira

Capítulo 2Tecnologias disponíveis

Do ponto de vista tecnológico dentro do ambiente de construção de uma plataforma de

testes de simulação abstraem-se os elementos sensores, atuadores, e os controladores (IEDs) dentro

do ambiente computacional chamado OPNET Modeler. Ou seja, Optimized Network Engineering

Tools foi o nome comercial dado ao software lançado em 1986 após um bem sucedido projeto de

conclusão de curso elaborado por um aluno do MIT- Massachusetts Institute of Technology.

A escolha por esta tecnologia, ou seja, o software OPNET Modeler, se baseia na

possibilidade de analisar as estatísticas diante de vários tipos de arquiteturas, escalas, cenários,

tecnologias, dentre outras vantagens, sem uma necessidade inicial de um laboratório real com

equipamentos reais, reduzindo assim o custo para a obtenção de uma solução para a especificação

de SAS quanto ao seu conteúdo em termos de tecnologias de rede, tais como: tipo de link,

velocidade de transmissão de dados, definição de protocolos, prioridade de tráfego, dentre outros.

2.1 - Requisitos iniciais para a instalação do OPNET Modeler

É necessária uma máquina com Windows XP com no mínimo alguns recursos que

suportem também a instalação do Visual Studio 6.0. O hardware escolhido tem as seguintes

características:

- Laptop TOSHIBA – Modelo Satellite A60 – S1591, Processador Intel Celeron(R) CPU

2.80 GHz, 704 Mb RAM.

15

Page 30: Vinícius Machado Moreira

O sistema operacional, em sua versão original, é o Microsoft Windows XP (Home

Edition), versão 2002, service pack 3 .

2.2 - Apresentação do Software OPNET Modeler

O software trata-se de um simulador de redes de computadores em ambiente virtual,

utilizado também para analisar e predizer o desempenho destas redes, incluindo aplicações, usuários

e tecnologias de redes e protocolos. É usado por milhares de organizações comerciais,

universidades e órgãos do governo ao redor do mundo [6].

Uma grande vantagem deste software, que nos leva à sua escolha, como uma ferramenta

bastante promissora no nosso estudo de modelagem, é a de poder interagir no funcionamento dos

modelos de processo que estão dentro dos módulos de quaisquer modelos de nós que possam ser

utilizados na simulação. Na Fig. 3 tem-se a tela de edição de um modelo de nó da própria biblioteca

do OPNET Modeler, versão 14.0 – Educational version, que será a versão utilizada neste trabalho.

Figura 3 – Módulos dentro de um modelo de nó de uma estação de trabalho Ethernet

16

Page 31: Vinícius Machado Moreira

Os modelos de nós mais utilizados já se encontram disponíveis na biblioteca do OPNET.

Tais modelos, como é o caso dos dispositivos de rede, representados por estações de trabalho,

roteadores, switches, servidores, e vários outros diferem do caso dos IEDs, que foram

desenvolvidos especificamente para uma aplicação.

Uma vez que cada módulo pode representar um protocolo, tem-se a possibilidade de

interagir no funcionamento destes protocolos através de um editor do OPNET para alcançar o

comportamento desejado como será visto adiante.

Os modelos de processos são criados pelo seu respectivo editor, cujo objetivo é permitir

que o usuário possa editar máquinas de estado finito. Neste aspecto, as máquinas de estado finito

são interligadas por transições que ocorrem quando do acontecimento de um determinado evento, e

podem provocar uma mudança para um outro ou até para o mesmo estado, dependendo do percurso

da transição. Como exemplo, tem-se a Fig. 4 que mostra a tela de edição de um modelo de processo

TCP, que faz parte da biblioteca do software OPNET Modeler, aplicado ao uso deste trabalho.

Figura 4 – Modelo de processo do módulo TCP de um modelo de nó de uma estação de trabalho Ethernet

17

Page 32: Vinícius Machado Moreira

É possível notar na Fig. 4 que uma transição entre dois estados ocorre,

por exemplo entre as máquinas periféricas e a máquina central. Já uma

transição para o próprio estado ocorre na máquina init e na máquina active.

Outro editor muito importante, o editor de modelos de projetos,

disponibiliza uma área de trabalho para a elaboração de um modelo de rede,

no qual podem ser alocados os dispositivos de rede já citados: switches,

roteadores, estações de trabalho, dentre outros. Torna-se possível a criação de

vários cenários para a simulação do modelo de rede desejado, a escolha de

estatísticas que devem ser analisadas sobre a rede, a execução da simulação,

a apresentação dos resultados, a criação de recursos para simulação de uma

rede específica, a utilização de editores auxiliares, inclusos os editores já

citados anteriormente.

Figura 5 – Tela da área de trabalho de editor de projeto com uma rede topologia estrela

18

Page 33: Vinícius Machado Moreira

Na Fig. 5 pode-se visualizar a área de trabalho do editor de projetos do

OPNET Modeler com uma rede topologia estrela modelada apenas para

ilustração deste trabalho. Foi utilizado o recurso de configuração rápida para

10 estações de trabalho com uma distância radial de aproximadamente 25

metros de um switch 16 portas ethernet na posição cartesiana x=50 e y=50,

com escala da área de trabalho em metros.

Ao se abrir um novo projeto no editor de projetos é necessário o ajuste

de alguns parâmetros que serão solicitados inicialmente, tais como: nome do

projeto, nome do cenário, topologia inicial, escala da rede, especificação das

dimensões (x,y) da área, a unidade, especificação das tecnologias a serem

utilizadas, e ainda a revisão de parâmetros e finalização.

É possível através da documentação em formato html do OPNET

Modeler acessar os diversos tutoriais, bibliotecas, conceitos básicos, dentre

outros, conforme se verifica na tela de conteúdo capturada da documentação

do OPNET mostrada na Fig. 6.

Figura 6 – Tela de apresentação da documentação em html do OPNET Modeler

19

Page 34: Vinícius Machado Moreira

Para iniciar recomenda-se a leitura de Basic Tutorials, onde se tem

uma introdução ampla de todos os editores e suas funcionalidades. Ainda, num

subtópico deste, Small Internetworkings, pode-se perceber de onde vêm os

recursos que foram utilizados para o exemplo da rede mostrado na Fig. 5,

muito embora a montagem do tutorial seja a de dois cenários, um mostrando o

desempenho da rede antes, e o outro depois da expansão, dentro do edifício

de uma companhia que possui uma pequena rede intranet.

Este tutorial é muito interessante, e pode ser explorado em muitos

manuais traduzidos do OPNET Modeler, que estão expostos no próprio site,

através do endereço:

http://www.opnet.com/university_program/teaching_with_opnet/textbooks_and_materi

als/index.html .

Existe ainda uma versão acadêmica fornecida pelo site do OPNET

através do endereço:

http://www.opnet.com/university_program/itguru_academic_edition. Porém,

esta versão não fornece acesso a edição de modelos dos nós, e por

conseguinte aos modelos de processo, o que não possibilita o desenvolvimento

de outros protocolos, que é o caso do presente trabalho desenvolvido. Talvez

possam ser adaptáveis modelos da versão OPNET Modeler para a versão IT

GURU Academic Edition, mas neste trabalho não foi utilizada esta

possibilidade, já que a versão Modeler engloba a Academic. São mostradas as

telas iniciais de abertura de cada uma das versões respectivamente nas Figs. 7

e 8.

Figura 8 – Tela de apresentação do OPNET ModelerFigura 7– Tela de apresentação do IT GURU

20

Page 35: Vinícius Machado Moreira

2.3 - Considerações finais

O objetivo deste capítulo foi expor uma introdução ao ambiente

computacional OPNET Modeler, como também a sua importância como

ferramenta para a escolha do modelo a ser implementado nas simulações de

um SAS.

A partir deste ambiente computacional é possível a construção de

modelos de dispositivos, os relés do tipo IEDs, no tocante à comunicação de

dados. É válido ressaltar que não estão sendo modelados TCs, TPs, disjuntores,

ou outros equipamentos ou instrumentos de uma subestação, com exceção

destes relés que neste ambiente podem no máximo disparar pacotes de trip

(GOOSE) a partir do recebimento de dados de medição para função de

abertura de disjuntores, no entanto tudo se limitando no meio da transmissão

de dados entre IEDs.

Considera-se que os sinais de tensão e corrente de TCs e TPs são

processados por IEDs de amostragem de sinais e estes se comunicam com os

IEDs de proteção e controle. Já os comandos de abertura são enviados por

estes aos IEDs de abertura específicos para tal função.

Os modelos são melhorados continuamente a cada nova simulação ou

interpretação do caso, haja vista a inúmera variedade de dados que podem ser

coletados em uma simulação, sejam estes dados de natureza global, sobre

determinado nó ou até mesmo sobre determinado link.

No Capítulo 3, os resultados das simulações obtidos permitirão

determinar se os modelos desenvolvidos estão compatíveis com a norma IEC

61850 quando da abordagem do estudo de casos reais.

21

Page 36: Vinícius Machado Moreira

22

Page 37: Vinícius Machado Moreira

Capítulo 3Simulações e Resultados Obtidos

O objetivo principal deste capítulo é mostrar de uma maneira mais

profunda a ferramenta OPNET Modeler com a possibilidade de que esta venha

a se consagrar no ramo da Engenharia Elétrica e Eletrônica como um recurso

bastante útil no planejamento de sistemas supervisórios no que se refere ao

requisito dinâmico da rede de comunicação.

A ampliação da proposta de simulação aqui presente poderá ser

realizada em trabalhos futuros. A plataforma é uma entidade virtual e são

inúmeros os caminhos e arquiteturas que podem ser criados. Outra

característica importante é que podem ser montados cenários comparativos

com parâmetros estatísticos os mais diversos possíveis, incluindo animações

2D e 3D em alguns casos.

Este capítulo mostra uma modelagem de IEDs, em termos de

requisitos dinâmicos de rede de comunicação de dados, a serem utilizados em

simulações para avaliação do desempenho dos tempos end-to-end de envio de

pacotes GOOSE durante eventos que ocorrem no sistema elétrico concebido da

RPBC [7] através de dois casos de funções de proteção clássicos.

23

Page 38: Vinícius Machado Moreira

3.1 - Modelagem da plataforma de simulação

Com base no trabalho dos professores Sidhu e Yin [7] foi possível a

construção de modelos de dispositivos IEDs em ambiente virtual. No entanto,

para a análise do desempenho da comunicação de dados de um SAS, houve a

necessidade de se implantar tais modelos sobre uma arquitetura de um

sistema de comunicação já testado.

A leitura da documentação em html do OPNET Modeler foi abordada

através dos conceitos trazidos em Basic Tutorials e Modeler Tutorials. Saber o

conceito de queueing, módulo mac, módulo source, módulo sink, CSMA/CD,

Aloha, tudo isto ainda não basta para que se possa formular um modelo que

funcione o mais próximo do real. O fato é que após um tempo relativamente

longo para assimilar estes conceitos, somado à adequação de algumas linhas

dos códigos de máquinas de estado finito de alguns modelos de processo, e

após várias simulações mais simples, foi possível acreditar nos avanços que

estão expostos neste trabalho.

Uma grande vantagem do OPNET Modeler é a de poder dispor de um

simulador com dois modos de funcionamento, ou seja, um modo debug e um

modo otimizado (mais rápido), ambos de grande valor, a depender da evolução

do desempenho das simulações.

De acordo com o que foi visto na IEC 61850–5, parte da norma que

especifica os requisitos de transfer time dos diversos tipos de mensagens

trocadas entre IEDs, é possivel seguir uma linha de simulação que obtenha

estatísticas de tempo fim-a-fim (ETE- end-to-end) de um pacote GOOSE,

enviado de um IED tipo P&C para um IED tipo breaker, responsável pelo

acionamento de disjuntores. É possível se prender somente a esta análise ou a

uma complexidade bem maior desta análise, dependendo do tamanho do

sistema.

24

Page 39: Vinícius Machado Moreira

Conforme exposto no trabalho [7], os IEDs podem ser divididos em três

tipos :

1) Merging Units - MU IED ;

São basicamente medidores multigrandezas acoplados aos TCs e TPs

do sistema elétrico, obtendo amostras dos sinais de tensão e corrente

a uma determinada taxa em samples/s ou Hz, disponibilizando estas

amostras, que se denominam SV - Sampled Values ou Raw Data que

são encapsuladas em pacotes ethernet no barramento de processo

ethernet para serem lidas pelos outros IEDs interessados nestas

informações, os P&Cs IEDs. Conforme modelo apresentado na Fig. 17.

2) Protection & Control – P&C IED ;

Na ocorrência de um evento previamente programado, por exemplo,

uma falta no sistema, haverá pacotes GOOSE de função de trip sendo

enviados dos P&Cs IEDS para os BRKs IEDs. Portanto, os P&C IEDs são

dispositivos com características de reconhecimento de eventos

indesejáveis no sistema elétrico, e podem dispor de muitas funções de

proteção, a depender do objetivo deste dispositivo no sistema.

Conforme modelo apresentado na Fig. 9.

3) Breakers - BRK IED .

São responsáveis pelo acionamento dos disjuntores do sistema, como

também o envio de status destes disjuntores através de pacotes de

confirmação GOOSE ou GSSE para os P&Cs IEDs. Conforme modelo

apresentado na Fig. 12.

Para o desempenho inicial proposto pela norma, o tempo ETE que uma

mensagem GOOSE deveria levar de um IED a outro seria de 4 ms, e de acordo

com os resultados obtidos a serem expostos adiante poderá ser necessário um

ajuste mais fino nos modelos ou na tecnologia de rede utilizada. Em testes

comparativos com proteções convencionais o GOOSE ainda consegue ser mais

rápido, conforme Seminário Técnico de Proteção e Controle [23].

25

Page 40: Vinícius Machado Moreira

O trabalho pôde ser iniciado a partir da modelagem dos P&Cs IEDs, em

seguida com a modelagem dos BRKs IEDs, e finalmente com a modelagem

dos MUs IEDs. Neste aspecto, foi observado no trabalho [7] que um P&C IED

podia ser modelado a partir de uma estação de trabalho workstation,

tecnologia ethernet, já disponível na biblioteca do OPNET. No entanto, a

adaptação inicial de colocação de um módulo simple source, um módulo

eth_mac_interface, e um módulo sink, todos próximos ao módulo mac, com

seus devidos packet streams (fluxo de pacotes) e statistic wires (ligações para

estatísticas) não foi suficiente para se iniciarem de imediato as simulações.

A maioria dos módulos da estação de trabalho workstation não tiveram

a necessidade de uma adaptação em seu código e configuração, exceto os que

foram inseridos na vizinhança do módulo MAC, inclusive o próprio módulo MAC.

Vale ressaltar, que o arquivo padrão foi preservado usando-se o recurso save

as para se criar um segundo módulo MAC caracterizado para o uso específico

do trabalho, chamado ethernet_macv2_iec61850.

3.1.1 - Modelagem do Nó – Protection & Control IED – topologia estrela

Figura 9 – Modelo de nó do P&C IED – topologia estrela

26

Page 41: Vinícius Machado Moreira

Na área circulada da Fig. 9 se observam os módulos que foram

implantados na vizinhança do módulo MAC, onde fica claro também observar

que entre a fonte de pacotes GOOSE (aplicação) e o módulo MAC (ligado à

camada física) existe um módulo de interface MAC que seria um dos módulos

de ligação entre a camada de aplicação e a camada física. Sendo assim, o

módulo MAC e sua interface MAC fazem o papel da camada de enlace ethernet,

consolidando a forma hierárquica das camadas no tipo de mensagem GOOSE

da Fig. 2, retirada da norma IEC 61850-8. O módulo sink tem a função de

receber, para processamento interno no P&C IED, os pacotes que chegam de

outros IEDs, simulando assim o processo de recebimento de pacotes pelos

dispositivos IEDs reais, na etapa em que estes iniciam a lógica interna do trip.

Um problema típico ocorreu no reconhecimento de quais fluxos de

pacotes o módulo MAC deveria reconhecer para enviar pacotes GOOSE para

que os mesmos pudessem fluir para a camada superior de interface. Foi

verificado que nas execuções de entrada da máquina de estado start, do

modelo de processo do módulo MAC, existia uma possibilidade de adaptação

para realizar a implantação de outro módulo vizinho, particularmente num

trecho de código que fazia a sistemática de reconhecimento de protocolos

IPX/SPX, que não se aplica ao caso. Logo, uma vez adaptado, pôde-se observar

o efeito através de simulações com estatísticas configuradas para animações

2D, o que possibilitou observar o comportamento dos pacotes dentro do nó .

A adaptação consistiu basicamente em fazer com que o módulo MAC

reconhecesse o módulo ARP e seus fluxos de pacotes, como também de forma

análoga, reconhecesse o módulo de interface MAC. Verifica-se nas Figs. 10 e

11, respectivamente o trecho de código de IPX/SPX antes e após a adaptação,

usado para reconhecer o módulo ARP, e o trecho de código IP antes e após

adaptação, usado para reconhecer o módulo de interface MAC.

27

Page 42: Vinícius Machado Moreira

ANTES

DEPOIS

Figura 10 – Trechos de código de IPX/SPX antes e após as adaptações

28

Page 43: Vinícius Machado Moreira

ANTES

DEPOIS

Figura 11 – Trechos de código de IP antes e após as adaptações

Os códigos mostrados acima são em linguagem C++, na verdade

chamada de proto-C dentro do ambiente OPNET Modeler, provavelmente

devido ao direcionamento dado aos diversos protocolos que são

disponibilizados para a área de programação de redes. O processo de

modelagem abordado neste trabalho trouxe aos poucos várias adaptações em

trechos de códigos nos modelos de processos.

29

Page 44: Vinícius Machado Moreira

Ao contrário do que possa se pensar, para os modelos aqui mostrados,

não foi necessário nenhum domínio sobre linguagem C++, mas sim boas horas

de leitura da documentação do OPNET Modeler, principalmente os tutoriais,

algumas simulações, facilidade com o idioma inglês, paciência, saber

interpretar o modo debug do Kernel, dentre outras qualidades.

3.1.2 - Modelagem do Nó – Breaker IED – topologia estrela

Figura 12 – Modelo de nó do Breaker IED – topologia estrela

Conforme se observa na Fig.12, há uma diferença na implantação

deste modelo de nó para o do item anterior. O módulo GOOSE source passa de

um processo simple source padrão do OPNET Modeler para um processo

adaptado a fim de poder realizar tanto a criação de pacotes, como também o

recebimento de pacotes e envio destes para o módulo sink.

Nas figs. 13 e 14 se verificam respectivamente a simple source, usada

no P&C IED, e a sua nova adaptação para o BRK IED. Nota-se ainda na Fig. 16 a

30

Page 45: Vinícius Machado Moreira

introdução de mais uma máquina de estado finito, a RCV, ao modelo de

processo a fim de que o início da criação de pacotes dependa da chegada de

um pacote proveniente de outro IED tipo P&C. Por último, ainda na Fig. 16,

observa-se um pequeno ajuste na máquina de estado generate, ou seja, um

pequeno ajuste inicial que vai naturalmente surgindo após o resultado das

primeiras simulações.

Figura 13 – Modelo de processo da GOOSE source do P&C IED

Figura 14 – Modelo de processo da GOOSE source do Breaker IED

31

Page 46: Vinícius Machado Moreira

Com a introdução da máquina de estado RCV, e com a chegada de um

pacote, ocorre a ativação da macro RCV_ARRVL e paralelamente da função rcv(

) – responsável pelo envio de cada pacote recebido para o módulo sink. Ao

mudar então para o estado init, ocorrerá uma leitura dos valores atribuídos ao

módulo GOOSE source, algumas validações, acionamento da macro START

para transição ao estado generate e registro de algumas variáveis para coleta

de estatísticas. Os parâmetros de atributos do módulo GOOSE source são

facilmente acessíveis no ambiente do editor de modelos de processos, clicando

com o botão direito do mouse sobre o módulo.

A macro RCV_ARRVL não existia no Header Block original da simple

source. Com a inserção da mesma, conforme se observa na Fig. 15, foi possível

reconhecer durante as simulações que sua ativação representava a ocorrência

de um evento no fluxo de pacotes de índice 0 do módulo GOOSE source .

Figura 15 – Header Block do Modelo de processo da GOOSE source do Breaker IED

Os índices de um módulo são números inteiros, e são atribuídos para

cada ponto de um módulo de onde possa se originar ou se finalizar um fluxo de

32

Page 47: Vinícius Machado Moreira

pacotes. Eles garantem a identificação do local onde estará ocorrendo um

evento no módulo. Daí a sua grande importância, já que identificando-se este

local, sabe-se de onde vem ou para onde se envia um pacote de dados.

A numeração dos índices é dada pela ordem de criação dos fluxos de

pacotes durante a edição do modelo do processo. Para acessar o valor da

numeração dos índices pode-se clicar com o botão direito do mouse sobre o

módulo GOOSE source, e no menu clicar em Show Connectivity,

consequentemente todos os fluxos e os respectivos índices em cada ponto dos

módulos que se interligam ao módulo em análise irão aparecer.

Esta característica diferenciada no modelo deste tipo de IED é devido

ao tipo de lógica que o mesmo é destinado a executar, ou seja, conforme o

trabalho [7], define-se que este tipo de IED é capaz de receber pacotes GOOSE

de trip, calcular o tempo ETE e em seguida enviar um comando de abertura ou

fechamento para o equipamento de campo, sendo assim o módulo sink é posto

em posição acima do módulo GOOSE, o que não ocorre no P&C IED, já que este

não precisa enviar comando diretamente a nenhum equipamento atuador de

campo.

Um outro detalhe que se observa, na Fig. 14, é a transição para a

máquina loop, onde a cada pacote recebido inicia-se um processo que leva à

criação de um novo pacote e assim sucessivamente, a um intervalo de criação

pré-estabelecido nos atributos iniciais do módulo GOOSE source. Tal

modificação substitui a permanência da antiga transição feita pela macro

PACKET_GENERATE que verificava quando um pacote acabava de ser gerado e

enviado para a camada inferior (interface_MAC). Esta geração dependia de

uma rotina de execução que havia no estado generate, substituída então

apenas pela chamada à função ss_packet_generate( ), conforme se observa na

Fig. 16.

33

Page 48: Vinícius Machado Moreira

Figura 16– Rotina de execução da máquina de estado generate do Modelo

Com todas estas modificações foi possível se aproximar de um modelo

que permitisse iniciar um estudo estatístico do tempo ETE, importantíssimo

para a validação dos modelos perante a norma IEC 61850. O modelo a seguir

mostrado na Fig. 17, último a ser apresentado antes dos resultados das

simulações, será utilizado mais adiante como uma fonte geradora de tráfego

de pacotes GOOSE em direção ao P&C IED da lógica de funções, embora não

seja muito diferente de sua função principal que seria alimentar o P&C IED com

amostras de informações bem parecidas, ou seja, pacotes raw data de alta

prioridade.

3.1.3 - Modelagem do Nó – MU IED – topologia estrela

Este modelo de nó da Fig.17 se assemelha em parte ao modelo de nó do P&C IED,

sendo a principal diferença a retirada das camadas que fazem a função do protocolo MMS,

ficando então somente a parte referente à aplicação de dados raw. Portanto, tem-se então a

fonte de dados raw, a camada de interface, um módulo sink, a camada MAC, e a camada

física.

34

Page 49: Vinícius Machado Moreira

Figura 17 – Modelo de nó do MU IED – topologia estrela

3.2 – Formulação dos casos

Os casos a serem mostrados neste capítulo são baseados no trabalho

[8] realizado em 2005 no laboratório da USP, o LPROT, pela PETROBRAS. Neste

trabalho foram obtidos os resultados acerca da viabilidade da utilização de um

SAS, baseado na IEC 61850, para atender o que viria a ser a nova configuração

do sistema elétrico de potência da refinaria RPBC. Sendo assim, baseado nas

configurações dos diagramas unifilares, pode-se verificar o posicionamento dos

diversos dispositivos de proteção inteligentes (IEDs) e seus respectivos

disjuntores que deverão estar devidamente interconectados. Estes disjuntores

serão acionados ao receberem os sinais de trip de abertura/fechamento a

depender do tipo de evento que esteja sendo processado pelos IEDs.

Devido à falta de um layout mais preciso da planta da RPBC foi

adotado de uma forma geral o layout da Fig. 18, cujas distâncias em metros

vistas no topo da figura concedem uma noção de espaço ocupado pela rede de

comunicação entre as diversas subestações e sala de controle. Nesta

arquitetura de rede estão representados os pontos principais da rede de

comunicação de dados, as subnets, e suas interligações físicas via

cabeamento lógico. Cada subnet contém um switch, e cada um destes

35

Page 50: Vinícius Machado Moreira

switches poderá ao seu redor ter um grupo de modelos de dispositivos IEDs,

estações clientes e até um servidor, dependendo da sua função, a exemplo da

subnet da sala de controle da planta. A constituição interna de cada subnet

presente na Fig. 18 poderá diferir um pouco nos casos estudados, conforme se

verifica nos apêndices C e D.

Figura 18– Mapeamento das subnets da planta da RPBC

Um dos recursos utilizados nas diversas simulações é o modelo

adaptado de nó do MU IED que neste trabalho é chamado de SINK LOAD. A

função do SINK LOAD é criar um tráfego de fundo nos diversos links de dados

que se interligam aos P&C IEDs. Além deste recurso, haverá o tráfego de fundo

das aplicações de FTP e de Database que pode ser configurado a qualquer

36

Page 51: Vinícius Machado Moreira

tempo através dos objetos de aplicação e de perfil de aplicação presentes na

área de trabalho do projeto.

Geralmente os modelos do tipo P&C IED são os responsáveis pelo

envio dos pacotes GOOSE para os demais IEDs. Porém, na prática, é possível

que um mesmo dispositivo IED abrigue as funções de cada um dos modelos

que neste trabalho se classificam, o que não impede a análise qualitativa da

proposta.

3.2.1 – Ensaio de paralelismo momentâneo de alimentadores - Função 43 – ANSI

O caso aborda a ininterruptibilidade de alimentação elétrica em duas

barras interligadas por um disjuntor (TIE) C da SE C-14 durante

indisponibilidade programada nos alimentadores das barras. Ou seja, cada

barra é alimentada por uma linha, respectivamente protegida por disjuntores,

A e B. Todos os disjuntores possuem um IED associado, mas uma lógica de

check de sincronismo é implantada no IED do TIE. A comunicação entre os IEDs

após o check de sincronismo permite envio e confirmação de comandos para

abrir e/ou fechar disjuntores de forma que se retire ou se coloque em operação

alimentadores, ocorrendo neste intervalo o paralelismo momentâneo de

alimentadores.

Neste ensaio procura-se focar no tráfego existente entre os IEDs

responsáveis pela abertura/fechamento dos disjuntores alimentadores das

duas barras da SE C-14 e o IED do disjuntor de interligação (TIE) destas duas

barras, onde serão analisados 4 cenários a seguir discriminados :

- 1º. Cenário : Análise de tempo ETE para envio de comando GOOSE do

P&C IED aos breakers IEDs dos disjuntores A e B, com todos os três

IEDs isolados em uma VLAN 3 como padrão de porta de switch, mas

sob influência de uma estação SINK LOAD interligada ao switch 4 da

SE C-14 da planta que estará enviando pacotes de tamanho de 200

bytes ao P&C IED, totalizando um tráfego interferente de 6,4 Mbps;

- 2º. Cenário : Análise de tempo ETE para envio de comando GOOSE do

P&C IED aos breakers IEDs dos disjuntores A e B, com somente os

breakers IEDs isolados em uma VLAN 3 como padrão de porta de

37

Page 52: Vinícius Machado Moreira

switch, sob influência da mesma estação SINK LOAD do cenário 1,

como também sob influência do tráfego de pacotes FTP e Database

que simulam a aplicação MMS, baseada em TCP/IP, para atualizações

dos IEDs quanto a dados não prioritários, tais como dados de

configuração dos IEDs, dentre outros;

- 3º. Cenário : remonta o cenário 2, mas com a implantação de serviço

de QoS – Quality of Service, baseado em priority queueing ;

- 4º. Cenário : remonta o cenário 2, mas com a implantação de

velocidade de 100 Mbps no link que interliga o P&C IED ao switch 4,

inclusive com canais de 100 Mbps no dispositivo P&C IED.

Figura 19 – Tempo ETE de um pacote que sai do IED P&C do TIE em direção aos IEDs dos disjuntores A e B (todos os cenários)

38

Page 53: Vinícius Machado Moreira

É válido ressaltar que embora esta manobra de paralelismo momentâneo

não seja crítica em termos de requisito de tempo, foi utilizado neste exemplo

comandos de trip baseados em mensagens rápidas GOOSE para a sua

realização seguindo o tratamento dos ensaios dado pela PETROBRAS no LPROT

da USP.

A análise do gráfico da Fig.19 fornece uma interpretação inicial positiva com relação aos

requisitos de tempo de transfer time da norma IEC 61850. No entanto, uma análise

do tempo de confirmação de comandos nas lógicas entre relés IEDs demonstra uma preocupação

com relação ao correto dimensionamento da capacidade da rede, conforme visto adiante.

Neste aspecto, há uma consideração muito importante a ser feita

quanto à análise do tempo ETE apresentado na Fig. 20, ou seja, com relação ao

tempo ETE de confirmação de envio de pacotes que chegam aos breakers IEDs

disparados pelo P&C IED.

Figura 20– Tempo ETE de pacotes que saem dos breakers IEDs em direção ao P&C IED do TIE (cenários 1 a 3 somente tráfego FTP e Database e cenário 1 original)

39

Page 54: Vinícius Machado Moreira

Somente analisando o tempo de resposta dos breakers IEDs (tempo de

confirmação através do retorno de pacotes GOOSE de confirmação) dos

comandos que foram enviados pelos P&Cs IEDs é possível se obter conclusões

perante a IEC 61850.

Foram estudados os cenários de 1 a 3 sem micros de SINK LOAD para

se mostrar a real influência dos tráfegos de FTP e Database e apenas o cenário

1 com o micro SINK LOAD ligado.

Pode-se observar na Fig. 20 uma variação bem acentuada nos tempos

de ETE no cenário 2, e logo em seguida no cenário 3 com a implantação do

QoS. Na comparação entre os ETEs do cenário 1 com e sem SINK LOAD

verifica-se uma degradação de tempo ETE na faixa de 0,16 ms

aproximadamente.

Na literatura do ensaio realizado pelo LPROT da USP pela PETROBRAS

[8] tem-se um tráfego de fundo que é gerado pelo programa IP LOAD, ou seja,

um programa para saturação de tráfego da rede que se utiliza para envio de

pacotes em direção ao número de IP do relé P&C IED do TIE. Nesta ocasião, nos

ensaios da USP, não é feita uma análise da confirmação da recepção de

pacotes no destino via pacotes de confirmação GOOSE. Caso viesse a ser

realizada esta análise pelo laboratório da USP é bem provável que os

resultados seriam bem parecidos com os que foram obtidos nos ensaios que se

seguem.

40

Page 55: Vinícius Machado Moreira

Figura 21– Tempo ETE de pacotes que saem dos breakers IEDs em direção ao P&C IED do TIE

(cenários 2 e 3 com micro SINK LOAD)

Observa-se no gráfico da Fig. 21 que no cenário 3 o tempo ETE se

aproxima bastante de zero, o que pode ser explicado pelos curtos instantes em

que o tráfego de fundo não está tão intenso, melhorando nesses instantes o

tempo ETE dos pacotes de confirmação.

Neste trabalho o tráfego não foi direcionado ao número IP do TIE, pois

esse tráfego de pacotes não está formatado para chegar na camada de

aplicação MMS do IED, e sim ao módulo SINK deste IED, que originalmente é

responsável pelos pacotes de confirmação de comandos GOOSE recebidos

pelos breakers IEDs. Enfim, devido a este ponto, SINK, ser o destino deste

tráfego de fundo, neste trabalho o micro gerador de tráfego é chamado de

SINK LOAD.

A configuração do SINK LOAD, assim como do IP LOAD original, prevê o

envio de pacotes no tamanho de 200 bytes a uma taxa de 4000 pacotes/seg, o

que representa 200 bytes x 8 bits x 4000 pacotes/seg = 6,4 Mbps, suficiente

para saturar em 100 % uma rede full duplex de 10 Mbps. Sendo assim, na Fig.

21, com os cenários 2 e 3, observam-se os efeitos devastadores somados dos

dois tráfegos de fundo em um link de 10 Mbps.

41

Page 56: Vinícius Machado Moreira

Figura 22– Tempo ETE de pacotes que saem dos breakers IEDs em direção ao P&C IED do TIE (cenários 1 a 4 com micro SINK LOAD)

Observa-se na Fig. 22 que somente com uma capacidade de link de

100 Mbps é que se consegue estabilizar em um perfil mais uniforme e de valor

bem mais satisfatório, na casa dos 0,2 ms, ou seja, encontra-se um tempo total

de envio mais recebimento de aproximadamente 0,46 ms durante todo o

intervalo de tempo de 20 s na simulação do OPNET Modeler para este caso, o

que representa uma convergência para uma solução de escolha da capacidade

daquele link que estaria mais crítico naquela ocasião.

Outro aspecto muito importante a se considerar na análise dos

cenários é a limitação do domínio de broadcast para alguns agrupamentos de

IEDs, pois foi observado que uma vez que se configura a porta do switch que se

interliga ao IED analisado para suporte à outra(s) VLAN(s), poderá existir

influência naquele ETE analisado.

No cenário 2 utiliza-se a VLAN 1 como padrão na configuração da

porta do switch 4 que se interliga ao P&C IED, mas deixa-se o suporte à VLAN 3

42

Page 57: Vinícius Machado Moreira

(pacotes GOOSE). Definida a VLAN 1 então como padrão, na qual se localiza o

servidor de dados da sala de controle, tem-se influência de tráfego FTP e

Database, e com isso ocorre uma oscilação no tempo ETE de pacotes que

chegam dos breakers IEDs dos disjuntores A e B.

No cenário 3 é utilizado um recurso de prioridade de tráfego, o QoS,

Quality of Service, que se baseia em critérios de prioridade de quais serviços

ou pacotes devem ter prioridade durante um processo de queueing, ou seja,

em espera numa fila de envio para a rede ou para uma camada de enlace.

Assim, na tentativa de buscar uma melhoria no tempo ETE, influenciado pelo

tempo de queueing, procura-se mostrar se haverá algum ganho neste aspecto,

uma vez que há uma mudança na oscilação do perfil do ETE neste cenário.

Já no cenário 4, como pode-se perceber, há uma grande mudança no

perfil do tempo ETE, havendo uma redução bastante significativa em virtude

da alta capacidade de transmissão do link de 100 Mbps em comparação com o

link anterior de 10 Mbps.

Mais adiante, nos apêndices, estarão detalhadas as configurações

utilizadas nas seguintes tecnologias : switches 16 portas – ethernet, estações

de trabalho ethernet, servidor ethernet, P&Cs IEDs, breakers IEDs, MU IEDs,

links de dados full duplex para velocidades de 10/100 Mbps, tecnologia de

VLANs, trunks, formato de pacotes GOOSE da IEC 61850, dentre outros

recursos de configuração de tipo de aplicação, perfil de aplicação, tempo de

intervalo de criação de pacotes, tempo de início de criação e finalização de

pacotes em alguns IEDs, dentre outras ferramentas de auxílio de manuseio do

próprio OPNET, tais como para exibição de dados estatísticos gráficos ou

paramétricos.

Uma das tarefas mais difíceis da simulação seria encontrar o

verdadeiro perfil a ser utilizado na prática, que poderia levar a inúmeras

simulações de desempenho. Na dúvida deve-se, como em todo projeto,

considerar uma margem de segurança.

É válido ressaltar que, no ensaio real de bancada com IEDs reais, são

considerados também os tempos de processamento das lógicas internas aos

dispositivos, ou seja, na simulação em ambiente virtual essas lógicas internas

podem ser diferentes em termos de tempo de processamento, não sendo

43

Page 58: Vinícius Machado Moreira

porém o objetivo aqui considerado. Procura-se adotar uma pior situação de

tráfego que compreenda todos os fluxos que na prática podem interferir ou não

no mesmo instante de amostragem do ETE.

3.2.2 – Ensaio de seletividade lógica – Função 68 - ANSI

O ensaio com o emprego da função 68, na tabela ANSI relacionada a

bloqueio, consiste em atribuir à uma determinada cadeia de proteção, formada

por relés, uma lógica operacional de forma que haja uma ordem para atuação

de cada relé diante de um evento. Quando da ocorrência de um evento, todos

os relés da cadeia são sensibilizados, porém somente um determinado relé

estará liberado para atuar, permanecendo bloqueados os demais até que uma

ordem de desbloqueio, acionada pela função de falha de disjuntor (50BF), seja

enviada pelo relé que se encontra desbloqueado naquele instante dentro da

cadeia de proteção.

Neste ensaio, procura-se focar no tráfego existente entre IEDs

responsáveis pela proteção seletiva de um alimentador localizado na SE C-14.

Neste caso, o IED responsável pela lógica de bloqueio e seletividade será o

P&C IED do próprio alimentador supervisionado. Foram avaliados 5 cenários a

seguir discriminados :

- 1º. Cenário : Análise de tempo ETE para envio de comando GOOSE do

P&C IED aos breakers IEDs dos disjuntores localizados à montante.

Todos os quatro IEDs encontram-se isolados na VLAN 3 (adotada

como padrão de porta de switch), sob influência de uma estação SINK

LOAD interligada ao switcth 4 da SE C-14 da planta. O SINK LOAD

estará enviando pacotes de tamanho de 200 bytes ao P&C IED,

totalizando uma tráfego interferente de 6,4 Mbps;

- 2º. Cenário : Análise de tempo ETE para envio de comando GOOSE do

P&C IED aos breakers IEDs dos disjuntores localizados à montante.

Somente os breakers IEDs encontram-se isolados na VLAN 3 (adotada

como padrão de porta de switch), sob influência da mesma estação

SINK LOAD do cenário 1. Haverá influência do tráfego de pacotes FTP

e Database que simulam a aplicação MMS, baseada em TCP/IP, para

44

Page 59: Vinícius Machado Moreira

atualizações dos IEDs quanto a dados não prioritários, tais como

dados de configuração dos IEDs, dentre outros;

- 3º. Cenário : remonta o cenário 2, mas com a implantação de serviço

de QoS – Quality of Service, baseado em priority queueing ;

- 4º. Cenário : remonta o cenário 2, mas com a implantação de

velocidade de 100 Mbps no link que interliga o P&C IED ao switch 4,

inclusive com canais de 100 Mbps no dispositivo P&C IED;

- 5º. Cenário : remonta o cenário 4, mas com simulação de falha no

link que interliga a SE C-14 a SE C-17.

Figura 23 – Tempo ETE de um pacote que sai do P&C IED do alimentador na SE C-14 em direção aos IEDs localizados à montante (cenários 1 a 3)

45

Page 60: Vinícius Machado Moreira

Ao contrário do caso do item anterior, neste esquema de proteção seletiva,

existe um ponto crítico em termos de requisito de tempo e obrigatoriamente

foram utilizados comandos de trip baseados em mensagens rápidas GOOSE. Na

análise de desempenho supõe-se que toda a lógica se localiza no P&C IED do

alimentador da SE C-14, que inicialmente envia comandos de bloqueio, função

68, aos IEDs à montante, e estes apenas estariam responsáveis pelos

comandos de abertura de seus respectivos disjuntores quando do desbloqueio

remoto pela função 50BF – Falha de disjuntor. A análise dos cenários se finaliza

quando se estabelecem os requisitos necessários para que os pacotes dos IEDs

mais afastados estejam dentro da faixa permitida dos 4 ms da IEC 61850.

Na Fig. 23 observam-se tempos de ETE para o trajeto de pacotes que

saem do IED (L90-1) de um alimentador na SE C-14 para os IEDs à montante

que estão submetidos à seletividade lógica. Os tempos são compatíveis com as

respectivas localizações dos breakers IEDs, nos quais os IEDs localizados na SE

C-17 apresentando tempos ETE maiores que 0,35 ms e menores que 0,45 ms.

Já o breaker IED na SE C-14 apresentando tempo ETE entre 0,25 e 0,30 ms.

Figura 24 – Tempo ETE de resposta de pacotes que retornam dos breakers IEDs em direção ao P&C IED localizado à jusante (cenários 2 e 3)

46

Page 61: Vinícius Machado Moreira

Como no caso anterior, é também primordial a análise dos tempos de

resposta dos breakers IEDs em relação ao P&C IED da lógica (L90-1), ou seja, o

tempo desde a detecção da falta até o recebimento da informação que o

disjuntor abriu, pois como se observa na Fig. 24 mais uma vez o efeito é

extremamente devastador, principalmente quando se requer neste caso uma

resposta rápida dos mesmos para o caso de falha de disjuntor, sendo muito

provável que haja até a perda de seletividade, já que há um certo limite de

tempo programado pelo relé da lógica para a verificação de falha de disjuntor,

em torno de 100 ms.

Observa-se pela Fig. 24 que não há condições de resposta aceitável

perante os requisitos da norma IEC 61850 em caso de aumento de tráfego

interferente à medida que se incrementa o tempo na simulação, e que não há

melhorias em termos do uso do serviço de QoS.

Seguindo a recomendação do caso anterior de aumento da capacidade

do link do P&C IED, são mostrados na Fig. 25 os tempos de ETE para os

cenários 4 e 5.

Figura 25– Tempo ETE de resposta de pacotes que retornam dos breakers IEDs em direção ao P&C IED localizado à montante (cenários 4 e 5)

47

Page 62: Vinícius Machado Moreira

Observa-se na Fig. 25 que mesmo durante a situação do cenário 5, em que ocorre a perda

de um link entre a SE C-14 e a SE C-17, é garantida a comunicação com os IEDs da SE C-17.

Ocorre um aumento de tempo ETE do cenário 4 para o cenário 5, indicando que provavelmente um

caminho mais longo foi necessário para o recebimento de pacotes de confirmação oriundos destes

IEDs da SE C-17.

Figura 26 – Tempo ETE de pacotes que partem do P&C IED em direção aos breakers IEDs localizados na SE C-17 (cenários 4 e 5)

Verifica-se na Fig. 26 um aumento no tempo ETE de pacotes que partem do P&C IED

em direção aos seus breakers IEDs.

3.3 Considerações finais

Foram apresentados dois casos de simulação de funções, um de paralelismo momentâneo

de alimentadores e outro de seletividade lógica, ambos operando através de comandos GOOSE da

IEC 61850. Sendo assim, foram criados alguns cenários com respectivas condições de tráfego de

fundo para que intencionalmente houvesse o efeito de uma saturação de rede. Consequentemente, as

soluções para cada caso recaem em um aumento na capacidade de transmissão do link, ressalvando

48

Page 63: Vinícius Machado Moreira

que o objetivo neste caso é manter o padrão de tempo da IEC 61850 para o ETE de confirmação de

abertura de disjuntor.

A validação do ensaio se observa na comparação com os resultados obtidos nos ensaios

que foram realizados conforme o trabalho em referência [8], onde procura-se testar a eficiência dos

comandos GOOSE em termos de requisitos de tempo da IEC 61850. É válido ressaltar que nos

ensaios da USP o tempo de confirmação de abertura foi medido pela abertura do contato físico do

relé IED que estava conectado a uma máquina de aferição real (Fab. OMICRON). Neste aspecto, o

tempo ETE do trajeto do pacote se soma ao tempo de abertura do contato.

Outros requisitos da norma não tratam de requisitos de tempo ou requisitos dinâmicos,

portanto não poderiam ser testados no OPNET Modeler devido a sua área de aplicação específica.

Um exemplo de outro requisito a ser testado poderia ser o da segurança da rede, que caberia a um

outro tipo de estudo.

49

Page 64: Vinícius Machado Moreira

50

Page 65: Vinícius Machado Moreira

Capítulo 4Conclusões, melhorias possíveis e trabalhos futuros

4.1 Conclusões

No âmbito de avaliação do desempenho da comunicação de dados baseados na IEC

61850 aplicada a refinarias de petróleo, são necessários recursos muitas vezes parecidos como os

que se têm nos laboratórios de testes reais, a exemplo da USP, mas é importante salientar que

simulações computacionais baseadas em modelos de processos estão cada vez mais acessíveis aos

usuários que desejam planejar um estudo sem um laboratório de testes reais.

É indiscutível que empresas de porte como a PETROBRAS possam utilizar melhores

recursos, mas muitas vezes é necessária a diversificação de métodos para a chegada de uma

solução, pois recursos reais muitas vezes são dependentes de inúmeros fatores.

Uma vasta gama de recursos existentes encontrados no OPNET Modeler permite chegar

a algumas soluções, mas não ao domínio completo de soluções. Através do trabalho publicado no

IEEE [7] encontrado no site de periódicos da UFPE foi possível unir a possibilidade de construção

de uma plataforma de análise virtual ao caso de implantação de IEDs na refinaria RPBC.

O passo inicial sem dúvida muito anterior ao de construção desta plataforma foi o de

tentar analisar o tráfego cliente-servidor entre dois micros reais. Mas, esta possibilidade logo se

frustrou pela impossibilidade de existir um software livre capaz de simular comandos GOOSE entre

IEDs virtuais. Na ocasião, os softwares utilizados foram cópias de demonstração obtidas no site da

51

Page 66: Vinícius Machado Moreira

Netted Automation [9], que por sinal foi um ótimo site para pesquisa de conhecimentos acerca da

norma IEC 61850.

Quanto à norma IEC 61850, no início sua grandiosidade parece torná-la um tanto quanto

repulsiva, no entanto tal fato é superado ao se focalizar naquilo que realmente é de interesse do

estudo: os modelos, os requisitos e os principais conceitos da norma. Fica claro entender que a

implantação da norma é algo baseado no interesse de liberdade de escolha para o usuário, com o

objetivo de reduzir custos por uma solução global, diferentemente da solução proprietária.

Os modelos de IEDs consolidados neste trabalho são bem acadêmicos do ponto de vista

lógico, e obedecem ao processamento interno kernel do OPNET Modeler, mas pelo fato deste

software ser bem difundido na área de simulação computacional de redes, apresentar uma vasta

biblioteca de modelos de processos já consagrados, por estar apoiado em trabalhos internacionais

por empresas já consagradas, acredita-se estar na direção certa de um novo tipo de tecnologia capaz

de auxiliar o planejamento de sistemas de comunicação de SASs, principalmente porque se pode

evoluir nesta tecnologia. Ou seja, simulações computacionais servem para planejar testes reais.

4.2 Melhorias possíveis e trabalhos futuros

O projeto da plataforma computacional deste estudo poderia ficar ainda melhor com o

uso de tag de prioridade dado ao pacote GOOSE, que apesar de ser previsto na norma IEC 61850,

não foi usado neste trabalho. Seria necessária uma atenção maior para os estudos dos modelos de

processo MAC e switch.

Outro fato que se tornaria interessante seria o aperfeiçoamento da configuração de

endereços IP e endereços de MAC com utilização de domínios de broadcast corretamente

configurados, pois assim pode-se integrar o funcionamento de vários casos em um só cenário, o que

nos daria uma visão mais completa de desempenho durante várias situações de contingência no

sistema elétrico estudado.

52

Page 67: Vinícius Machado Moreira

Apêndice A

Este apêndice fornece os diagramas unifilares representados nas telas do sistema supervisório aplicado nos testes da plataforma de IEDs montados no laboratório LPROT [8] da Escola Politécnica da USP com relação à arquitetura de automação das subestações da Refinaria Presidente Bernardes de Cubatão - RPBC quando da proposta de atualização baseada na IEC 61850 pela PETROBRAS em 2005 :

- SE C-17 – Subestação de entrada com recebimento em 230 kV e distribuição em 13,8 kV ;

- SE C-14 – Subestação de distribuição em 13,8 kV ;

- SE C-03 – Subestação de distribuição em 13,8 kV.

Juntas estas três subestações abastecem inúmeras subestações unitárias espalhadas pela refinaria para atendimento aos vários processos da planta. A subestação de entrada recebe energia da UTE Cubatão em 230 kV, transforma para 13,8 kV e distribui através de sua barra de 13,8 kV para alimentadores e para outras subestações, tais como a SE C-14 e a SE C-03. A linha de IEDs utilizada nos ensaios foi de fabricação GE com suporte à IEC 61850.

Figura A. 1 – Tela para proteção e controle da SE C-17 – Diagrama Unifilar do Painel PN-17010A – 13,8kV

53

Page 68: Vinícius Machado Moreira

Figura A. 2– Tela para proteção e controle da SE C-17 – Diagrama Unifilar do Painel PN-17010B – 13,8kV

Figura A. 3– Tela para proteção e controle da SE C-17 – Diagrama Unifilar do Painel PN-17010C – 13,8kV

54

Page 69: Vinícius Machado Moreira

Figura A. 4– Tela para proteção e controle da SE C-14 – Diagrama Unifilar do Painel PN-14010 – 13,8kV

Figura A. 5– Tela para proteção e controle da SE C-03 – Diagrama Unifilar do Painel PN-03010 – 13,8kV

55

Page 70: Vinícius Machado Moreira

Figura A. 6– Tela para proteção e controle da SE C-17 – Diagrama Unifilar de Interligação entre os Painéis PN-17010 A/B/C - 13,8kV

56

Page 71: Vinícius Machado Moreira

Apêndice B

Este apêndice fornece os diagramas de interligação de switches ópticos, IEDs e computadores aplicados nos testes da plataforma de IEDs montados no laboratório LPROT da Escola Politécnica da USP com relação à arquitetura de automação das subestações da Refinaria Presidente Bernardes de Cubatão - RPBC quando da proposta de atualização baseada na IEC 61850 pela PETROBRAS em 2005.

Figura B. 1– Configuração de IEDs e switch utilizados para a configuração da SE C-17

Figura B. 2– Configuração de IEDs e switches utilizados para a configuração da SE C-14

57

Page 72: Vinícius Machado Moreira

Figura B. 3– Configuração de IEDs e switch utilizados para a configuração da SE C-03

Figura B. 4– Rede geral de IEDs e switches ópticos construída no Laboratório de Proteção de Sistemas, para simulação da arquitetura do novo sistema de proteção e automação elétrica da RPBC/PETROBRAS

58

Page 73: Vinícius Machado Moreira

Apêndice C

Este apêndice fornece as configurações e os diagramas de interligação de switches, IEDs e computadores para o caso de paralelismo momentâneo de alimentadores montado no software OPNET Modeler da simulação computacional deste trabalho.

- Configuração da subnet da SE C-14 durante simulação do caso de paralelismo momentâneo de alimentadores ;

Figura C. 1- IEDs, switch, micro de engenharia de campo, micro SINK LOAD utilizados para a simulação da comunicação de dados no paralelismo momentâneo de alimentadores da barra da SE C-14

Na Fig. C.1 o switch 4 faria o papel do switch ML-2400 da SE C-14 da Fig. B.2, e aparecem também os IEDs D60, L90-2 e o C60, respectivamente trocando dados lógicos de formato GOOSE para a operação de paralelismo. A seguir tem-se algumas configurações realizadas especificamente para este caso.

59

Page 74: Vinícius Machado Moreira

Figura C. 2 – Tela das configurações de atributos da fonte GOOSE do modelo de nó P&C IED TIE C60

Figura C. 3 – Tela das configurações de atributos da interface de ethernet do modelo de nó P&C IED TIE C60

60

Page 75: Vinícius Machado Moreira

Figura C. 4– Tela das configurações de atributos do módulo MAC do modelo de nó P&C IED TIE C60

Figura C. 5– Tela das configurações de atributos do canal de recepção RX do modelo de nó P&C IED TIE C60

As mesmas configurações do canal de Recepção RX acima servem para o canal de transmissão TX do mesmo P&C IED. Observa-se a mudança necessária no ajuste de data rate para suprir a demanda de tráfego intenso na pior situação estudada para o referido caso.

61

Page 76: Vinícius Machado Moreira

Figura C. 6 – Tela das configurações de atributos da fonte GOOSE do modelo de nó breaker IED L90-2

Figura C. 7 – Tela das configurações de atributos da interface de ethernet do modelo de nó breaker IED L90-2

62

Page 77: Vinícius Machado Moreira

Figura C. 8 - Tela das configurações de atributos do módulo MAC do modelo de nó breaker IED L90-2

Figura C. 9– Tela das configurações de atributos do canal de recepção RX do modelo de nó breaker IED L90-2

As mesmas configurações do canal de Recepção RX acima servem para o canal de transmissão TX do mesmo breaker IED.

63

Page 78: Vinícius Machado Moreira

Figura C. 10– Tela das configurações de atributos da fonte GOOSE do modelo de nó breaker IED D60

Figura C. 11 – Tela das configurações de atributos da interface de ethernet do modelo de nó breaker IED D60

64

Page 79: Vinícius Machado Moreira

Figura C. 12– Tela das configurações de atributos do módulo MAC do modelo de nó breaker IED D60

Figura C. 13– Tela das configurações de atributos do canal de recepção RX do modelo de nó breaker IED D60

As mesmas configurações do canal de Recepção RX acima servem para o canal de transmissão TX do mesmo breaker IED.

65

Page 80: Vinícius Machado Moreira

Figura C. 14– Modelo de nó do micro SINK LOAD

Clicando-se com o botão esquerdo no micro SINK LOAD verifica-se que este modelo de nó é baseado no IED tipo Merging Unit – MU IED configurado para envio de pacotes numa taxa de 6,4 Mbps, conforme atributos da Fig. C.15. A idéia do micro SINK LOAD foi inspirada na idéia do software IP LOAD [8], utilizando saturação da rede através de pacotes raw data.

Figura C. 15– Configuração dos atributos do módulo raw data do modelo de nó SINK LOAD

66

Page 81: Vinícius Machado Moreira

- Configuração da subnet da sala de controle da planta durante simulação do caso de paralelismo momentâneo de alimentadores .

Figura C. 16– Estações de trabalho cliente e servidor na subnet da sala de controle da planta

Figura C. 17– Configuração FTP (Heavy) ajustada no item de aplicação da simulação

67

Page 82: Vinícius Machado Moreira

Figura C. 18 – Configuração Database (Light) ajustada no item de aplicação da simulação

Uma vez configurados estes dois itens de aplicação e de perfil de aplicação a estação servidor deve ser configurada para o perfil de serviços, que no caso foi adaptado do perfil padrão Sm_Int_profile que já vem disponível na biblioteca do OPNET Modeler. O micro servidor então faz o papel da aplicação FTP e Database que foi especificado e as estações clientes utilizam estes serviços. Sendo assim, posteriormente ao passo das configurações acima, as estações clientes devem conter o perfil Sm_Int_profile para geração de um pequeno tráfego que passe pelo switch 1. O mesmo papel também que o micro de engenharia de campo faz no switch 4 da subnet da SE C-14 na Fig. C.1

Figura C. 19– Configuração do item Supported Services das configurações de atributos do modelo de nó da estação servidor

68

Page 83: Vinícius Machado Moreira

Figura C. 20 – Configuração do item Supported Profile das configurações de atributos do modelo de nó de uma estação cliente

Essas configurações de Supported Profile acima de uma estação cliente localizada na subnet da sala de controle servem também para as demais estações clientes existentes na simulação. As demais configurações de IP ou MAC devem ser distintas para cada uma das estações. Caso não seja IP fixo deverá se optar pela opção auto assign, o mesmo ocorrendo para o endereço MAC. Para os IEDs, que precisam de endereço certo, foi necessário fixar endereços MAC, que é o que ocorre na prática, pois cada placa de rede de um dispositivo é única no mundo. Na prática esse endereço é um número hexadecimal, mas note-se que neste trabalho foram usados apenas números inteiros distintos especialmente para diferenciar os únicos modelos que foram utilizados na simulação em tela.

69

Page 84: Vinícius Machado Moreira

70

Page 85: Vinícius Machado Moreira

Apêndice D

Este apêndice fornece os diagramas de interligação de switches, IEDs e computadores para o caso da seletividade lógica entre IEDs montada no software OPNET Modeler da simulação computacional deste trabalho.

- Configuração da subnet da SE C-14 durante simulação do caso de seletividade lógica entre IEDs ;

Figura D. 1– IEDs, switch, micro de engenharia de campo, micro SINK LOAD utilizados para a simulação da comunicação de dados na seletividade lógica entre IEDs na SE C-14

Em termos significativos não existiram quase mudanças nas configurações de atributos dos modelos, mas sim na distribuição dos mesmos, na nomenclatura e no acréscimo de mais um IED, que no total foram 4(quatro), ou seja, 2(dois) IEDs na subnet da SE C-14 e dois IEDs na subnet da SE C-17, conforme se verifica na Fig. D.2.

71

Page 86: Vinícius Machado Moreira

- Configuração da subnet da SE C-17 durante simulação do caso de seletividade lógica entre IEDs .

Figura D.2– IEDs e switch, utilizados para a simulação da comunicação de dados na seletividade lógica entre IEDs na SE C-17

72

Page 87: Vinícius Machado Moreira

Apêndice E

Este apêndice fornece as demais configurações que também seriam importantes para as simulações em ambos os casos, tais como as configurações dos switches, as configurações para a coleta de estatísticas e o formato do pacote GOOSE.

- Switches ;

Uma opção para configuração rápida de VLAN para um determinado switch ou link é feita pelo menu da área de trabalho na opção protocols \VLAN.

Figura E. 1 – Opção no menu para configuração rápida de um switch ou um link

73

Page 88: Vinícius Machado Moreira

Outra opção é clicar no próprio switch ou no próprio link com o botão direito e acessar a opção Edit attributes.

Figura E. 2– Tela de atributos de um switch 16 portas ethernet

Figura E. 3– Tela de atributos de um link

74

Page 89: Vinícius Machado Moreira

Para se determinar em qual porta do switch estaria ligado um determinado link deve-se com o botão direito sobre o link desejado escolher a opção Edit ports.

Figura E. 4– Tela de seleção de portas de um link

Uma outra opção de configuração de um switch seria manualmente fazer as configurações por porta .

Figura E. 5– Tela de configuração manual das portas de um switch

75

Page 90: Vinícius Machado Moreira

Na tela da Fig. E.5 se observa que a porta 10 do switch 4 no cenário 1 do caso paralelismo momentâneo de alimentadores está configurada para suportar as VLANs 1 e 3, mas a VLAN padrão neste caso é a VLAN 3, adotada como a VLAN para pacotes GOOSE, a qual foi configurada somente para os IEDs do paralelismo. Já nos demais cenários a VLAN 3 deixa de ser padrão, a fim de que o dispositivo detentor da lógica de envio de pacotes de comando GOOSE passe a ser influenciado pelo tráfego de fundo proveniente da VLAN 1.

Um importante recurso para a visualização das VLANs que estão ativas pode ser acessado pela opção View\Visualize Protocol Configuration\VLAN Configuration da área de trabalho.

Figura E. 6– Tela de recurso para visualização das VLANs configuradas, mostrando a VLAN 3

Figura E. 7– Tela de recurso para visualização das VLANs configuradas, mostrando a VLAN 1

76

Page 91: Vinícius Machado Moreira

Observa-se que alguns links estão com configuração trunk, ou seja, para suportar mais de uma VLAN no mesmo link. Vale ressaltar que este recurso só se torna viável em dispositivos que aceitam a configuração de tagueamento de porta, ou seja padrão 802.1Q. Sendo uma das dificuldades do trabalho e que foram citadas no capítulo 4, subitem de trabalhos futuros.

- Configurações de coleta de estatísticas ;

Um dos recursos principais deste trabalho foram as configurações para a coleta de estatísticas. O OPNET Modeler apresenta inúmeras possibilidades e isto é o que mostra a Fig. E.8 a respeito de uma coleta individual de estatística, como por exemplo, no modelo de nó P&C IED .

Figura E. 8– Tela de configuração das estatísticas individuais de um modelo

Acima uma das opções escolhidas é o tempo End-to-End Delay (ETE) do tráfego em direção ao módulo sink do IED. Podem ser feitas várias outras escolhas, inclusive animações 2D e até 3D dependendo do tipo de plataforma de simulação. Vale ressaltar que no desenvolvimento dos modelos várias

77

Page 92: Vinícius Machado Moreira

animações 2D foram necessárias. Na opção DES do menu tem-se essas opções de gravação das animações, Record, e também da escolha das estatísticas, se individual ou global.

Quanto aos resultados, estes podem ser exibidos de diversas formas ou estilos, por exemplo, abaixo pode-se obter o formato gráfico do ETE em valor médio, average. Para acessar os resultados existe um pequeno botão no menu chamado View Results.

Figura E. 9 – Tela de recurso para visualização dos resultados

No botão Show mostrado na parte inferior direita da Fig. E.9 tem-se a opção de exibir em uma tela individual somente o gráfico do resultado, e por conseguinte pode-se escolher o estilo da linha do gráfico, como por exemplo, estilo discreto, barras, dentre outros, e até exportar os resultados para uma planilha.

Figura E. 10– Tela de recurso para visualização individual de um resultado gráfico e a opção de exportação para uma planilha

78

Page 93: Vinícius Machado Moreira

- Formato do pacote GOOSE .

O formato do pacote GOOSE é baseado no formato da Norma IEC-61850 -8-1 – Anexo C, Overview of ISO/IEC 8802-3 frame structure for GSE management and GOOSE. Portanto, abaixo tem-se o formato do pacote ainda na fonte GOOSE e o formato do pacote ethernet_v2 que é usado no encapsulamento quando da passagem pelo módulo MAC do IED.

Figura E. 11– Formato dos pacotes GOOSE e ethernet_v2 pelo editor de formato de pacotes

Vale ressaltar que o formato dos pacotes é um importante recurso para interpretação quando da passagem pelos módulos de processo do OPNET Modeler.

79

Page 94: Vinícius Machado Moreira

80

Page 95: Vinícius Machado Moreira

Referências Bibliográficas

[1] Torres, Gabriel. Redes de Computadores – Curso Completo. Rio de Janeiro, Axcel Books, 2001;

[2] Cyclades Brasil, Guia Internet de Conectividade. São Paulo, SENAC São Paulo, 2001;

[3] Dos Santos, Luís Fabiano & Pereira, Lima. São Paulo, VII SIMPASE;

[4] GURJÃO, E. C.; CARMO, U. A.; SOUZA, B. A. Aspectos de comunicação danorma IEC 61850. In: Simpósio Brasileiro de Sistemas Elétricos - SBSE 2006, Campina Grande. Anais do Simpósio Brasileiro de Sistemas Elétricos - SBSE 2006, 2006. v. 1. p. 1-5;

[5] ALMEIDA, Clóvis. Notas de aula. CENEL 2008. Rio de Janeiro, 2008;

[6] ALECRIM, Paulo Dias de. Simulação Computacional para Redes de computadores. Rio de Janeiro, Editora Ciência Moderna Ltda, 2009;

[7] T. S. Sidhu, Y. Yin, “Modelling and Simulation for Performance Evaluation of IEC 61850 based Substation Communication Systems,” IEEE Trans. On Power Delivery, vol. 22, no. 3, pp. 1482-1489, Jul.2007;

[8] Bulgarelli, R.; Senger, E.C.; Santos, A.; Zerbinatti, P.E.; Viceconti, P.E.; Reis Filho, E.A.. O Modelamento e Ensaios de Sistema de Proteção e Automação para o Sistema de Distribuição de Energia Elétrica da Refinaria Presidente Bernardes (RPBC), baseado em IEDs e no Protocolo IEC 61850. São Paulo, LPROT-USP, 2005;

[9] http://www.nettedautomation.com/index.html;

[10] INTERNATIONAL ELETROTECHNICAL COMMISSION. IEC 61850-1: Communication networks and systems in substations – Part 1 Introduction and overview. Geneva, 2003;

[11] INTERNATIONAL ELETROTECHNICAL COMMISSION. IEC 61850-2: Communication networks and systems in substations – Part 2: Glossary. Geneva, 2003;

[12] INTERNATIONAL ELETROTECHNICAL COMMISSION. IEC 61850-3: Communication networks and systems in substations – Part 3: General requirements. Geneva, 2002;

[13] INTERNATIONAL ELETROTECHNICAL COMMISSION. IEC 61850-5: Communication networks and systems in substations – Part 5 Communication requirements for functions and device models. Geneva, 2003;

81

Page 96: Vinícius Machado Moreira

[14] INTERNATIONAL ELETROTECHNICAL COMMISSION. IEC 61850-6: Communication networks and systems in substations – Part 6 Configuration description language for communication in electrical substations related to IEDs Introduction and overview. Geneva, 2004;

[15] INTERNATIONAL ELETROTECHNICAL COMMISSION. IEC 61850-7-1: Communication networks and systems in substations – Part 7-1: Basic communication structure for substation and feeder equipment – Principles and models. Geneva, 2003;

[16] INTERNATIONAL ELETROTECHNICAL COMMISSION. IEC 61850-7-2: Communication networks and systems in substations – Part 7-2: Basic communication structure for substation and feeder equipment – Abstract communication service interface (ACSI). Geneva, 2003;

[17] INTERNATIONAL ELETROTECHNICAL COMMISSION. IEC 61850-7-3: Communication networks and systems in substations – Part 7-3: Basic communication structure for substation and feeder equipment – Common data classes. Geneva, 2003;

[18] INTERNATIONAL ELETROTECHNICAL COMMISSION. IEC 61850-7-4:Communication networks and systems in substations – Part 7-4: Basic communication structure for substation and feeder equipment – Compatible logical node classes and data classes. Geneva, 2003;

[19] INTERNATIONAL ELETROTECHNICAL COMMISSION. IEC 61850-8-1: Communication networks and systems in substations – Part 8-1: Specific Communication Service Mapping (SCSM) – Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3. Geneva, 2004;

[20] INTERNATIONAL ELETROTECHNICAL COMMISSION. IEC 61850-9-1: Communication networks and systems in substations – Part 9-1: Specific Communication Service Mapping (SCSM) – Sampled values;

[21] Tecnologia em Metalurgia e Materiais, São Paulo, v.3, n.3, p. 41-45, jan.-mar. 2007;

[22] Gallo, Michael A.; Hancock, William M. Comunicação entre computadores e tecnologias de rede. São Paulo, Pioneira Thomson Learning, 2003;

[23] P. Júnior, Paulo S. Testes de performance de IEDs através de ensaios utilizando mensagens GOOSE (IEC61850). IX STPC – Seminário Técnico de Proteção e Controle. Belo Horizonte, 2008.

82