Avaliacao_do_desempenho_da_comunicacao

Prévia do material em texto

Universidade Federal de Pernambuco
Centro de Tecnologia e Geociências
Curso de Especialização em Engenharia de Instrumentação
Avaliação do desempenho da comunicação de dados baseada 
na IEC 61850 aplicada a refinarias de petróleo 
Vinícius Machado Moreira 
Orientador: Edval J. P. Santos, PhD
Monografia apresentada ao Centro de 
Tecnologia e Geociências da Universidade 
Federal de Pernambuco como parte dos 
requisitos para obtenção do Certificado de 
Especialista em Engenharia de Instrumentação
Recife, 2009
1
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ônica
Palavras-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.........................8
Figura 2 – Perfis das camadas de comunicação da IEC 61850 para os diversos 
modelos de informação.....................................................................................11
Figura 3 – Módulos dentro de um modelo de nó de uma estação de trabalho 
Ethernet.............................................................................................................17
Figura 4 – Modelo de processo do módulo TCP de um modelo de nó de uma 
estação de trabalho Ethernet............................................................................18
Figura 5 – Tela da área de trabalho de editor de projeto com uma rede 
topologia estrela................................................................................................19
Figura 6 – Tela de apresentação da documentação em html do OPNET Modeler
..........................................................................................................................20
Figura 7– Tela de apresentação do IT GURU......................................................21
Figura 8 – Tela de apresentação do OPNET Modeler.........................................21
Figura 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......28
Figura 11 – Trechos de código de IP antes e após as adaptações....................29
Figura 12 – Modelo de nó do Breaker IED – topologia estrela............................29
Figura 13 – Modelo de processo da GOOSE source do P&C IED........................30
Figura 14 – Modelo de processo da GOOSE source do Breaker IED...................31
Figura 15 – Header Block do Modelo de processo da GOOSE source do Breaker 
IED.....................................................................................................................32
Figura 16– Rotina de execução da máquina de estado generate do Modelo... .33
Figura 17 – Modelo de nó do MU IED – topologia estrela...................................34
Figura 18– Mapeamento das subnets da planta da RPBC..................................36
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
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
Figura 21– Tempo ETE de pacotes que saem dos breakers IEDs em direção ao 
P&C IED do TIE .................................................................................................40
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)....................................41
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).................44
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
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
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)....................................47
 
3
LISTA DE TABELAS
Tabela 1- Uma comparação adaptada entre as camadas OSI e TCP/IP...............5
Tabela 2 – Divisões da Norma IEC 61850..........................................................10
 
4
LISTA DE ABREVIATURAS
ANSI American National Standards Institute
ARP Address Resolution Protocol
BRK IED Breaker IED
CAN Controller Area Network
CIM Computer Integrated Manufacturing
CO Connection Oriented
CPU Central Process Unit
CSMA/CD Carrier Sense Multiple Access / Collision Detection
DARPA Defense Advanced Research Protection Agency
DCS Distributed Control System
DHCP Dynamic Host Configuration Protocol
DNP Distributed Network Protocol
EIA Electronic Industries Alliance
EMI Electromagnetic Interference
EPRI Electrical Power Research Institute
ETE End-to-end
FTP File Transfer Protocol
GOOSE Generic Object Oriented Substation Event
GPSGlobal Positioning System
GSSE Generic Substation Status Event
HVAC Heating, Ventilation and Air Conditioning
IEDs Intelligent Electronic Devices
IEEE Institute of Electrical and Electronics Engineers 
IHM Interface Homem Máquina
IRIG-B Inter-Range Instrumentation Group
ISO International Organization for Standardization 
LAN Local Area Network
LLC Logical Link Control
LN Logical Node
LON Local Operating Networking
LPROT Laboratório de Pesquisa em Proteção de Sistemas Elétricos
MAC Media Access Control
MIT Massachusetts Institute of Technology
MMS Manufacturing Message Specification
MU IED Merging Unit IED
MVB Multifunction Vehicle Bus
OPC Ole for Process Control
OPNET OPtimized Network Engineering Tools
OSI Open Systems Interconnection
P&C IED Protection and Control IED
PLCs Programmable Logic Controllers
PN Painel
Profibus Process Field Bus
QoS Quality of Service
RPBC Refinaria Presidente Bernardes de Cubatão
RTU Remote Terminal Unit
SAS Substation Automation System
SCADA Supervisory Control And Data Acquisition
5
http://en.wikipedia.org/wiki/Institute_of_Electrical_and_Electronics_Engineers
SCL Substation Configuration Language
SDCD Sistema Digital de Controle Distribuído
SE Subestação
SEL Schweitzer Engineering Laboratories
SIMPASE Simpósio de Automação de Sistemas Elétricos
SNTP Simple Network Time Protocol
SV Sampled Values
TC Transformador de Corrente
TCP/IP Transmission Control Protocol/Internet Protocol
TF Trafo
TP Transformador de Potencial
tpal Transport Protocol Adaptation Layer
UCA Utility Communication Architecture
UDP User Datagram Protocol
UFPE Universidade Federal de Pernambuco
UML Unified Modeling Language
USP Universidade de São Paulo
UTE Usina Térmica
UTRs Unidades Terminais Remotas
VID VLAN Identifier
VLAN Virtual Local Area Network
XML eXtensible Markup Language
MVA mega volt-ampére
kV 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
http://pt.wikipedia.org/wiki/Rede_de_computadores
http://pt.wikipedia.org/wiki/Endere%C3%A7o_IP
http://pt.wikipedia.org/wiki/IP
http://pt.wikipedia.org/wiki/TCP
http://pt.wikipedia.org/wiki/Protocolo
http://pt.wikipedia.org/wiki/Rede_de_computadores
http://pt.wikipedia.org/wiki/Servidor
http://pt.wikipedia.org/w/index.php?title=Cliente_(computa%C3%A7%C3%A3o)&action=edit&redlink=1
http://pt.wikipedia.org/wiki/Broadcast
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
http://pt.wikipedia.org/wiki/Bit
http://pt.wikipedia.org/wiki/Modelo_OSI
http://pt.wikipedia.org/wiki/Rede_de_%C3%A1rea_local
http://pt.wikipedia.org/wiki/Computador
http://pt.wikipedia.org/wiki/Rede_de_computador
http://pt.wikipedia.org/wiki/Protocolo
http://pt.wikipedia.org/wiki/Dom%C3%ADnio_de_colis%C3%A3o
http://pt.wikipedia.org/wiki/Rede_de_computadores
http://pt.wikipedia.org/wiki/Computador
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 protcolosTCP 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
http://pt.wikipedia.org/wiki/Sistema_de_controle_HVAC
http://pt.wikipedia.org/wiki/Climatiza%C3%A7%C3%A3o
http://pt.wikipedia.org/wiki/Ar_condicionado
http://pt.wikipedia.org/wiki/Ilumina%C3%A7%C3%A3o
http://pt.wikipedia.org/wiki/Pr%C3%A9dio
http://pt.wikipedia.org/wiki/Sistema_computacional
http://pt.wikipedia.org/wiki/Sistema_computacional
http://pt.wikipedia.org/wiki/Hardware
http://pt.wikipedia.org/wiki/Software
http://pt.wikipedia.org/wiki/Sistema_operacional
http://pt.wikipedia.org/wiki/NTP
http://pt.wikipedia.org/wiki/Automa%C3%A7%C3%A3o
http://pt.wikipedia.org/wiki/Telecomunica%C3%A7%C3%B5es
http://pt.wikipedia.org/wiki/Protocolo
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
http://pt.wikipedia.org/wiki/Dom%C3%ADnio_de_colis%C3%A3o
http://pt.wikipedia.org/wiki/Concentrador
http://pt.wikipedia.org/wiki/Concentrador
http://pt.wikipedia.org/wiki/Rede_de_computadores
http://pt.wikipedia.org/wiki/Pacote
http://pt.wikipedia.org/wiki/OSI
http://pt.wikipedia.org/wiki/Rede_de_computadores
http://pt.wikipedia.org/wiki/Rede_de_computadores
http://pt.wikipedia.org/wiki/Protocolo
12
Sumário
Capítulo 1............................................................................................................1
Introdução...........................................................................................................1
1.1- Motivação..................................................................................................1
1.2- Cenário......................................................................................................1
 ........................................................................................................................1
1.3- A importância de uma subestação em uma refinaria de petróleo...........2
1.4- Comunicação em redes ...........................................................................3
1.5- Protocolo de comunicaçãoTCP/IP.............................................................4
1.6- Sistemas distribuídos................................................................................6
1.7- IEDs – Intelligent Electronic Devices.........................................................6
1.8- Proposta da Norma IEC 61850..................................................................7
1.9- Apresentação da Norma IEC 61850 .........................................................8
1.10 - Considerações Finais............................................................................14
Capítulo 2..........................................................................................................15
Tecnologias disponíveis.....................................................................................15
2.1 - Requisitos iniciais para a instalação do OPNET Modeler........................16
2.2 - Apresentação do Software OPNET Modeler ...........................................16
2.3 - Considerações finais..............................................................................21
Capítulo 3..........................................................................................................23
Simulações e Resultados Obtidos......................................................................23
3.1 - Modelagem da plataforma de simulação ..............................................23
3.2 – Formulação dos casos............................................................................34
3.2.1 – Ensaio de paralelismo momentâneo de alimentadores - Função 43 – 
ANSI................................................................................................................36
3.2.2 – Ensaio de seletividade lógica – Função 68 - ANSI...............................43
3.3 Considerações finais.................................................................................48
Capítulo 4..........................................................................................................49
Conclusões, melhorias possíveis e trabalhos futuros........................................49
4.1 Conclusões...............................................................................................49
4.2 Melhorias possíveis e trabalhos futuros...................................................50
Apêndice A........................................................................................................51
Apêndice B........................................................................................................55
Apêndice C........................................................................................................57
Apêndice D........................................................................................................68
Apêndice E.........................................................................................................70
Referências Bibliográficas.................................................................................78
13
14
Capítulo 1
Introduçã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, queagregam 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ção
SNMP, 
TFTP, 
NFS, 
DNS, 
BOOTP
FTP, 
Telnet, 
Finger, 
SMTP,PO
P
Aplicação
A camada de 
aplicação do TCP/IP 
corresponde às 
camadas de 
aplicação, 
apresentação e 
sessão do OSI
6
Apresentaçã
o
5 Sessão
4 Transporte
utilizam 
UDP
(não 
orientad
o à 
conexão
)
utilizam 
TCP
(orientad
o à 
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
3
Rede
IP Internet
A camada Internet do 
TCP/IP corresponde à 
camada de rede do 
OSI
2 Dados
Cartõ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ísica
Meio 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 decontrole 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ÇÃO
REQUISITOS 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
http://en.wikipedia.org/wiki/Institute_of_Electrical_and_Electronics_Engineers
http://en.wikipedia.org/wiki/Institute_of_Electrical_and_Electronics_Engineers
http://en.wikipedia.org/wiki/Institute_of_Electrical_and_Electronics_Engineers
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çasimplementadas 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 2
Tecnologias 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
http://www.opnet.com/university_program/itguru_academic_edition
http://www.opnet.com/university_program/teaching_with_opnet/textbooks_and_materials/index.html
http://www.opnet.com/university_program/teaching_with_opnet/textbooks_and_materials/index.html
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 3
Simulaçõ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 simplesource, 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