Upload
hahuong
View
238
Download
0
Embed Size (px)
Citation preview
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
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
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
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
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
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
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
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
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
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
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
12
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
14
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
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
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
(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
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
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
• 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
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
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
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
- 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
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
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
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
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
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
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
É 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
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
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
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
22
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
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
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
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
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
ANTES
DEPOIS
Figura 10 – Trechos de código de IPX/SPX antes e após as adaptações
28
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
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
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
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
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
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
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
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
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
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
É 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
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
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
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
(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
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
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
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
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
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
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
50
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
- 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
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
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
70
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
- 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
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
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
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
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
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
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
- 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
80
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
[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