Norma Iec 61850

Grupo de Trabalho
B5.01
026
Aplicações da Norma IEC 61850 -
Sistemas de Automação Operando
com Redes de Comunicação
Outubro 2020
Brasil
APLICAÇÕES DA NORMA IEC 61850
SISTEMAS DE AUTOMAÇÃO
OPERANDO COM REDES DE
COMUNICAÇÃO
GT B5.01
Membros
Pablo Humeres Flores - Coordenador BR

Silvio César Souza de Oliveira - Secretário BR
Tiago Fernandes Barbosa BR
André Franceschett BR
Renato Weingartner Pernas BR
Paulo Henrique Vieira Soares BR
Carlos Alberto de Miranda Aviz BR
Alexandre Fernandes Onça BR
Fernando Estevam Gazzoni BR
Guilherme Penariol BR
Mário Roberto Bastos BR
Mateus Alexandrino BR
Copyright © 2018
“All rights to this Technical Brochure are retained by CIGRE. It is strictly prohibited to reproduce or provide this publication in
any form or by any means to any third party. Only CIGRE Collective Members companies are allowed to store their copy on
their internal intranet or other company network provided access is restricted to their own employees. No part of this
publication may be reproduced or utilized without permission from CIGRE”.
Disclaimer notice
“CIGRE gives no warranty or assurance about the contents of this publication, nor does it accept any responsibility, as to the
accuracy or exhaustiveness of the information. All implied warranties and conditions are excluded to the maximum extent
permitted by law”.
WG XX.XXpany network provided access is restricted to their own employees. No part of this publication may be
reproduced or utilized without permission from CIGRE”.
ISBN : [to be completed by CIGRE]

Disclaimer notice
“CIGRE gives no warranty or assurance about the contents of this publication, nor does it accept any
APLICAÇÕES DA NORMA IEC 61850 SISTEMAS DE AUTOMAÇÃO OPERANDO COM REDES DE COMUNICAÇÃO
1. RESUMO
Na última década os Sistemas de Automação de Subestação passaram por um significativo

processo de evolução tecnológica Esta evolução envolveu não somente o aumento da
capacidade de processamento dos Dispositivos Eletrônicos Inteligentes (Intelligent
Electronic Devices - IEDs), como também a possibilidade do uso intensivo e seguro de
redes de comunicação de dados entre estes dispositivos, com a finalidade de melhorar o
desempenho das funções implementadas. O resultado da digitalização integrada dos
sistemas de proteção, controle e supervisão de uma subestação é, algumas vezes,
denominado Sistema de Automação de Subestações (Substation Automation System -
SAS), englobando no termo automação as demais funções citadas.
Para viabilizar a interoperabilidade entre IEDs de diferentes fabricantes e permitir uma
utilização mais ampla das possibilidades oferecidas pelas tecnologias de
microprocessadores e de redes de comunicação, foi publicada no início dos anos 2000 a
norma IEC 61850. Esta norma rapidamente se tornou uma solução amplamente aceita para
os SAS em todo o mundo. Milhares de instalações ilustram a história de sucesso. Estas
aplicações realimentaram as revisões da norma para corrigir problemas, deixa-la mais clara
e atender necessidades práticas de sua aplicação.
A norma IEC 61850 padronizou vários elementos de um SAS, organizando em níveis de
implementação: nível de processo (Process Level), de vão (Bay Level) e de estação (Station
Level). Foram definidos modelos de dados orientado a objeto, voltados já para os
equipamentos existentes no ambiente de subestações, como disjuntores, transformadores
etc., e das funcionalidades envolvidas como proteção, medição, controle. Também definiu
protocolos de rede para envio e recepção de diferentes tipos de dados, comandos e
supervisão, Manufacturing Message Specification (MMS), Sampled Value (SV), inclusive
entre IEDs, Generic Object Oriented Substation Event (GOOSE) em tempo real, como o
disparo de funções de proteção, padronização da interface para transformadores de
instrumentação convencionais e não convencionais, entre outros itens.
A edição 1.0 da norma IEC 61850 já descrevia várias possibilidades, contudo, a falta de
conhecimento causou uma série de dificuldades na sua adoção. Com a publicação da
edição 2.0 de algumas partes da norma, esses problemas foram sanados e o rol de
aplicações foi ampliado incluindo usinas geradoras, por exemplo, surgiu também a
possibilidade de comunicação entre subestações, como também aprofundou a questão da
segurança e redundância das redes de comunicação, entre outros aspectos.
A norma IEC 61850 oferece um padrão único em termos de tecnologia, pois permite uma
gestão formal de todas as etapas de vida do SAS, desde o seu projeto, passando pelas
fases de teste, implantação, manutenção e expansão. Além disso, altera a forma como
enxergamos a subestação virtualizando seus elementos e desconectando as funções dos
dispositivos físicos, permitindo aplicações cada vez mais inteligentes.
Assim, todas as áreas relacionadas com a implantação de SAS passaram e ainda passam
por um processo de adaptação, impactadas pela nova tecnologia. Surge, assim, a
necessidade da construção de referências técnicas adequadas que ajudem na abordagem
dessas novas possibilidades.
O objetivo deste Grupo de Trabalho (GT) é avaliar a extensa bibliografia já disponível pelos
diversos trabalhos e brochuras técnicas publicadas pelo CIGRE, além de descrever as
diferentes experiências realizadas no Brasil durante a última década, algumas delas
relatadas em informes técnicos publicados em diversas oportunidades. O GT teve como
objetivo principal criar um documento de referência para a aplicação da norma IEC 61850
em sistemas de automação de subestação – SAS.
2
Com base nessa avaliação e compilação de dados, o GT formulou descrições e

recomendações para a implementação do SAS. Os aspectos a avaliados incluem:
 Introdução, filosofia e justificativas para adoção da norma IEC 61850;
 Especificação de dispositivos e sistemas baseados na norma IEC 61850;
 Integração entre dispositivos e redes de proteção e automação;
 Requisitos de documentação em SAS;
 Aplicações da norma IEC 61850 em esquemas de proteção;
 Requisitos de segurança em sistemas operando com comunicação e a norma IEC
61850;
 Manutenção e processos de validação em sistemas operando com a norma IEC
61850;
 Barramento de Processo – IEC 61850-9-2;
 Sistema Supervisórios e a norma IEC 61850.
Referências:
 TB 326 (2007) WG B5.11 – The Introduction of IEC 61850 and Its Impact on
Protection and automation Within Substations;
 TB 401 (2009) WG B5.32 – Functional Testing of IEC 61850 Based Systems;
 TB 427 (2010) WG B5.38 – The Impact of Implementing Cyber Security
Requirements using IEC 61850;
 TB 464 (2011) WG B5.06 – Maintenance Strategies for Digital Substation Automation
Systems;
 TB 466 (2011) WG B5.12 – Engineering Guidelines for IEC 61850 Based Digital SAS;
 TB 540 (2013) WG B5.36 – Applications of IEC 61850 Standard to Protection
Schemes;
 TB 628 (2013) WG B5.39 – Documentation Requirements Throughout the Lifecycle of
Digital Substation Automation Systems;
 TB 637 (2014) WG B5.45 – Acceptance, Commissioning and Field Testing
Techniques for Protection and Automation Systems;
 TB 760, WB B5.53 – Test strategy for Protection, Automation and Control (PAC)
functions in a fully digital substation based on IEC 61850 applications;
 IEC 61850: 2016 SER – Series Communication networks and systems for power
utility automation - ALL PARTS.
3
Sumário
1. RESUMO .................................................................................................................................................. 2
2. SIGLAS ..................................................................................................................................................... 7
3. INTRODUÇÃO, FILOSOFIA E JUSTIFICATIVAS PARA ADOÇÃO DA NORMA IEC 61850 .... 10

3.1 VISÃO GERAL DA NORMA IEC 61850 ....................................................................................................................... 10
3.2 BENEFÍCIOS NA ADOÇÃO DA NORMA ..................................................................................................................... 15
3.3 DIFICULDADES NA ADOÇÃO DA NORMA................................................................................................................. 17
3.4 TENDÊNCIAS TECNOLÓGICAS FUTURAS E REQUISITOS ADERENTES À NORMA ............................................ 18
3.5 HISTÓRICO DE SUAS APLICAÇÕES NO BRASIL........................................................................................................ 19
4. ESPECIFICAÇÃO DE DISPOSITIVOS E SISTEMAS BASEADOS NA NORMA IEC 61850 ........ 20

4.1 DESCRIÇÃO DE UM SISTEMA BASEADO NA NORMA IEC 61850 ....................................................................... 20
4.2 DESCRIÇÃO DO SISTEMA .............................................................................................................................................. 25
4.3 DEFINIÇÃO DAS FUNCIONALIDADES.......................................................................................................................... 26
4.4 REQUISITOS NUMA SOLUÇÃO IEC 61850 ............................................................................................................... 29
4.4.1 Requisitos de comunicação .................................................................................................................................... 29
4.4.2 Requisitos de rede .................................................................................................................................................. 30
4.4.3 Requisitos de sincronismo de tempo .................................................................................................................... 31
4.5 REQUISITOS DE CERTIFICAÇÃO E HOMOLOGAÇÃO ............................................................................................ 34
4.6 EXPERIÊNCIAS DE ESPECIFICAÇÕES ............................................................................................................................ 35
5. INTEGRAÇÃO ENTRE DISPOSITIVOS E REDES DE PROTEÇÃO E AUTOMAÇÃO.................... 37

5.1 INTRODUÇÃO ................................................................................................................................................................... 37
5.2 MODELAGEM DE DADOS .............................................................................................................................................. 38
5.2.1 Níveis lógicos (Logic level) para as funções ...................................................................................................... 38
5.2.2 Funções de automação no sistema de potência ............................................................................................... 39
5.2.3 Livre alocação de funções ..................................................................................................................................... 41
5.2.4 Orientação a objetos ............................................................................................................................................. 43
5.2.5 Classes de modelamento ....................................................................................................................................... 44
5.2.6 Exemplo de modelamento para Logical Node CSWI .................................................................................... 44
5.2.7 Exemplo de modelamento para Logical Node MMXU................................................................................... 46
5.2.8 Functional Constraint ............................................................................................................................................... 48
5.2.9 DataSets .................................................................................................................................................................... 49
5.3 TRANSFERÊNCIA DE MENSAGENS ............................................................................................................................... 50
5.3.1 Tempo de transmissão ............................................................................................................................................ 50
5.3.2 Categoria de serviços e Classes de desempenho ........................................................................................... 51
5.3.3 Transferência de dados entre pares .................................................................................................................. 52
5.4 INFRAESTRUTURA DE COMUNICAÇÃO ...................................................................................................................... 58
5.4.1 Topologias de rede ................................................................................................................................................ 59
5.4.2 Protocolos de redundância de rede ................................................................................................................... 59
6. REQUISITOS DE DOCUMENTAÇÃO EM SAS ................................................................................. 64

6.1 DOCUMENTAÇÃO ........................................................................................................................................................... 64
6.2 LINGUAGEM PARA DESCRIÇÃO DO PAC SYSTEM ................................................................................................. 65
6.3 PROJETOS .......................................................................................................................................................................... 66
4
6.4 PROJETO FUNCIONAL .................................................................................................................................................... 67

6.5 AUTOMATIZAÇÃO DA DOCUMENTAÇÃO ................................................................................................................ 70
6.6 EXPERIÊNCIA NO BRASIL NA DOCUMENTAÇÃO DE SOLUÇÕES IEC 61850 ................................................... 70
7. APLICAÇÕES DA NORMA IEC 61850 EM ESQUEMAS DE PROTEÇÃO ................................... 72

7.1 INTRODUÇÃO ................................................................................................................................................................... 72
7.2 REQUISITOS DOS ESQUEMAS DE PROTEÇÃO ......................................................................................................... 72
7.3 ESQUEMAS DE PROTEÇÃO ADOTANDO A IEC 61850 .......................................................................................... 73
7.3.1 Funções de Proteção para Barramentos ............................................................................................................ 73
7.3.1.1 Esquema de Bloqueio......................................................................................................................................... 74
7.3.1.2 Esquema de Comparação Direcional ............................................................................................................. 76
7.3.1.3 Função Diferencial .............................................................................................................................................. 77
7.3.2 Falha de Disjuntor ................................................................................................................................................... 78
7.3.2.1 Falha de Disjuntor via Proteção de Barramento ......................................................................................... 79
7.3.2.2 Falha de Disjuntor via Proteções dos Módulos ............................................................................................. 80
7.3.3 SEP – Sistema Especial de Proteção ................................................................................................................... 80
7.4 TELEPROTEÇÃO................................................................................................................................................................. 82
7.4.1 Princípios de Operação ......................................................................................................................................... 82
7.4.2 Esquemas de Proteção para Elementos de Distância ..................................................................................... 83
7.4.3 Nó lógico PSCH para Esquemas de Proteção de Distância .......................................................................... 84
7.4.4 Interfaces de Proteção Mista e Comunicação PDH ......................................................................................... 87
7.4.5 Aplicação de Canal de Backup e Sistema de Comunicação SDH ............................................................... 87
7.4.6 Teleproteção e as Redes IP Network ................................................................................................................. 88
7.5 REGISTRADOR DIGITAL DE PERTURBAÇÃO – RDP ................................................................................................... 90
7.5.1 Esquemas Clássicos ................................................................................................................................................. 90
7.5.2 Uso atual da IEC 61850 no RDP ......................................................................................................................... 91
7.5.3 Uso do RDP em sistemas baseados na IEC 61850 .......................................................................................... 91
7.5.3.1 Utilização por Bay - Nível de Bay ................................................................................................................. 91
7.5.3.2 Utilização em mais de um vão (bay) - Nível de Bay ................................................................................. 92
7.5.3.3 Utilização do RDP no pátio – Nível de Processo ......................................................................................... 93
7.5.4 Novos sistemas de Registros ................................................................................................................................. 94
8. REQUISITOS DE SEGURANÇA CIBERNÉTICA EM SISTEMAS OPERANDO COM

COMUNICAÇÃO E A NORMA IEC 61850 .......................................................................................... 95
8.1 ANÁLISE DE ATAQUES, RISCOS E AMEAÇAS ............................................................................................................ 96
8.2 OBJETIVOS DE PROTEÇÃO, NORMAS E ABORDAGEM DE SEGURANÇA ......................................................... 99
8.3 PRINCÍPIOS DE DESIGN SEGURO ............................................................................................................................. 102
8.4 ESTRATÉGIAS DE MITIGAÇÃO DE RISCOS DE UMA SOLUÇÃO IEC 61850 ................................................... 107
8.5 DESENVOLVIMENTOS E ASPECTOS ESTRATÉGICOS ........................................................................................... 112
9. MANUTENÇÃO E PROCESSOS DE VALIDAÇÃO EM SISTEMAS OPERANDO COM A NORMA

IEC 61850 ............................................................................................................................................... 115
9.1 VISÃO GERAL................................................................................................................................................................. 115
9.2 DEFINIÇÕES DE TESTES ................................................................................................................................................ 115
9.3 CONTROLE DE FLUXO DE DADOS EM SUBESTAÇÕES DIGITAIS....................................................................... 116
9.3.1 VLAN ....................................................................................................................................................................... 118
9.3.2 Testes com RSTP, PRP e HSR .............................................................................................................................. 118
9.4 CARACTERÍSTICAS DOS TESTES EM IEC 61850 ..................................................................................................... 119
9.4.1 Modo Simulation ................................................................................................................................................... 120
9.4.2 Mode e Behavior de Funções ............................................................................................................................. 120
9.4.3 Processando Atributos de Dados de Entrada ................................................................................................ 122
9.4.4 Bloqueio de Informações .................................................................................................................................... 122
9.4.5 InRef ........................................................................................................................................................................ 123
5
9.5 REQUISITOS PARA FERRAMENTAS DE TESTE .......................................................................................................... 123

9.5.1 Características Requeridas para testes Remotos .......................................................................................... 125
9.6 MONITORAMENTO....................................................................................................................................................... 125
9.7 PROCESSO DE TESTES ................................................................................................................................................. 127
9.7.1 Metodologias de Teste ....................................................................................................................................... 128
9.7.2 Configuração do SAS e Sistemas de Teste .................................................................................................... 129
9.7.3 Visualização dos Testes na IHM ........................................................................................................................ 130
9.7.4 Documentação do Teste ...................................................................................................................................... 130
9.7.5 Teste do SAS e seus componentes .................................................................................................................... 131
9.7.6 Impactos nos processos de Teste ....................................................................................................................... 131
9.7.7 Simulação de Perdas e Alteração de Mensagens ........................................................................................ 132
9.8 CASOS DE USO ............................................................................................................................................................. 132
9.9 TIPOS DE TESTE .............................................................................................................................................................. 132
9.9.1 Teste de Tipo e Conformidade ......................................................................................................................... 132
9.9.2 Teste de Distúrbios em Redes de Comunicação ............................................................................................ 133
9.9.3 TAF – Testes de Aceitação em Fábrica ........................................................................................................... 133
9.9.4 TAC – Testes de Aceitação em Campo ........................................................................................................... 134
9.9.5 Manutenção após Comissionamento ................................................................................................................ 134
9.9.6 Requisitos de Testes Após Mudanças Funcionais ........................................................................................... 134
9.10 CENÁRIOS DE TESTES ................................................................................................................................................... 134
9.10.1 Trabalhando com Mensagens GOOSE e SV de um sistema de teste e processo ................................. 134
9.10.2 Teste da cadeia completa de funções com diferentes possibilidades de configurações .................... 135
9.10.3 Testes de Funções distribuídas........................................................................................................................... 136
9.10.4 Isolamento Funcional ............................................................................................................................................ 137
9.10.5 Testes Remotos ...................................................................................................................................................... 137
9.10.6 Testes de Manutenção ......................................................................................................................................... 137
9.11 FERRAMENTAS DE MERCADO .................................................................................................................................... 138
9.12 CONSIDERAÇÕES FINAIS ............................................................................................................................................ 139
10. BARRAMENTO DE PROCESSO – IEC 61850-9-2................................................................. 140

10.1 VISÃO GERAL................................................................................................................................................................. 140
10.2 DESCRIÇÃO FUNCIONAL ............................................................................................................................................ 141
10.3 ASPECTOS DA COMUNICAÇÃO NO BARRAMENTO ........................................................................................... 143
10.4 CONSIDERAÇÕES SOBRE ARQUITETURA DE REDE ............................................................................................... 147
10.5 EXPERIÊNCIAS NA APLICAÇÃO DO BARRAMENTO DE PROCESSO ................................................................. 151
11. SISTEMAS SUPERVISÓRIOS E A NORMA IEC 61850.......................................................... 154

11.1 EVOLUÇÃO DOS SISTEMAS SUPERVISORIOS ....................................................................................................... 155
11.2 VISÃO MODERNA DOS SISTEMAS SUPERVISORIOS ........................................................................................... 158
11.3 SISTEMAS SUPERVISORIOS E A NORMA IEC 61850 ........................................................................................... 161
12. CONCLUSÃO .............................................................................................................................. 164
13. REFERÊNCIAS ............................................................................................................................... 166
6
2. SIGLAS
ANEEL Agência Nacional de Energia Elétrica

ANSI American National Standards Institute
APPID Application ID
BPDU Bridge Protocol Data Unit
BR Baseline Requirement
BRCB Buffered Report Control Block
CCU Central Control Unit
CDC Common Data Class
CID Configured IED Description
CIGRE Conselho Internacional de Grandes Sistemas Elétricos
CIM Common Information Model
CMV Complex Measured Value
COMTRADE Common Format for Transient Data Exchange
DA Data Attributes
DAN Double Attached Node
DANP Double Attached Network PRP
DiD Defense-in-Depth
DIS Data and Information Structure
DNP Distributed Network Protocol
DO Data Objects
DoS Denial of Service
DPC Controllable Double Point
DRP Disaster Recovery Plan
DS Data Sets
ECE Esquemas de Controle de Emergência
ERAC Esquemas Regionais de Alívio de Carga
FC Functional Constraint
FR Foundational Requirements
GNSS Global Navigation Satellite System
GOOSE Generic Object Oriented Substation Event
HCD Human-Centered Design
HSR High-availability Seamless Redundancy
IA Inteligência Artificial
IACS Industrial Automation and Control Systems
ICCP Inter-Control Center Communications Protocol
ICD IED Capability Description
IDS Intrusion Detection System
IEC International Electrotechnical Commission
IED Intelligent Electronic Device
IHM Interface Humano Máquina
IID Instantiated IED Description
IP Internet Protocol
IPS Intrusion Prevention Systems
IRIG Inter-Range Instrumentation Group
ISA International Society of Automation
ISO International Organization for Standardization
KEMA Keuring van Elektrotechnische Materialen te Arnhem
LAN Local Area Network
LD Logical Device
LN Logical Node
7
MAC Media Access Control

MMS Manufacturing Message Specification
MPLS-TP Multiprotocol Label Switching - Transport Profile
MU Merging Unit
NCIT Non Conventional Instrument Transformer
NERC North American Electric Reliability Corporation
NIST National Institute of Standards and Technology
ONS Operador Nacional do Sistema Elétrico
OPLAT Ondas Portadoras em Linhas de Alta Tensão
OSI Open System Interconnection
PAC Protection, Automation and Control
PLC Programmable Logic Controller
Pmc Probability of missing command
PRP Parallel Redundancy Protocol
PTP Precision Time Protocol
Puc Probability of unwanted command
RCB Report Control Block
RCT Redundancy Check Trailer
RDP Registrador Digital de Perturbações
RE Requirement Enhancements
RSTP Rapid Spanning Tree Protocol
SAMU Stand Alone Merging Unit
SAN Single Attached Network
SAS Substation Automation System
SCADA Supervisory Control and Data Acquisition
SCD Substation Configuration Description
SCL System Configuration description Language
SCSM Specific Communication Service Mapping
SCU System Communication Unit
SDH Synchronous Digital Hierarchy
SDO Sub Data Objects
SED System Exchange Description
SEP Sistemas Especiais de Proteção
SIEM Security Information and Event Management
SL System Security Levels
SNTP Simple Network Time Protocol
SO Sistema Operacional
SOC Security Operation Center
SOE Sequence of Events
SONET Synchronous optical networking
SR Security Requirements
SSCL Sistema de Supervisão e Controle Local
SSD System Specification Description
STP Spanning Tree Protocol
SuC System under Consideration
SV Sampled Value
TA Tecnologia de Automação
TAC Testes de Aceitação em Campo
TAF Testes de Aceitação em Fábrica
TASE.2 Telecontrol Application Service Element 2
TC Transformador de Corrente
TCP Transmission Control Protocol
TI Tecnologia da Informação
TP Transformador de Potencial
TRA Threat and Risk Assessment
UAC Unidade de Aquisição e Controle
8
UCA Utility Communication Architecture

URCB Unbuffered Report Control Block
UTC Coordinated Universal Time
UTR Unidade Terminal Remota
VBA Virtual Basic for Applications
VDAN Virtual DAN
VPN Virtual Private Network
XML eXtensible Markup Language
9
3. INTRODUÇÃO, FILOSOFIA E JUSTIFICATIVAS PARA

ADOÇÃO DA NORMA IEC 61850
3.1 VISÃO GERAL DA NORMA IEC 61850
A tecnologia digital vem sendo aplicada nos sistemas de Proteção, Automação e Controle
(Protection, Automation and Control System – PAC) há mais de 25 anos. Neste período,
passou-se de uma realidade eletromecânica e de informação mínima, para uma tecnologia
digital que invadiu o controle e proteção dos equipamentos e as interfaces de operação,
propiciando uma supervisão completa dos processos envolvidos. As novas tecnologias
permitiram aumentar consideravelmente a observabilidade do sistema de potência
melhorando a qualidade da operação em tempo real, principalmente em sistemas altamente
complexos como é o caso brasileiro.
Diversas áreas se beneficiaram deste processo: operação em tempo real, suporte à
operação, manutenção de sistemas de proteção, controle e supervisão, manutenção de
equipamentos, telecomunicação e engenharia de projetos. Assim, passou-se a ter
informações para o sistema de supervisão e fazer de maneira mais eficiente o controle em
tempo real, análise de ocorrências, estatísticas operacionais, estatísticas de desempenho de
equipamentos, avaliação de vida útil, de desempenho econômico, de disponibilidade, de
supervisão dos sistemas de comunicação (em função da teleproteção e do telecontrole de
instalações), de qualidade de energia, etc.
O Sistema de Automação da Subestação – SAS, que também pode ser descrito como o
sistema de Proteção, Automação e Controle (Protection, Automation and Control System –
PAC system), é fundamental para garantir a disponibilidade do sistema de potência com
confiabilidade, disponibilidade e eficiência. A Figura 1 apresenta de forma geral a integração
funcional do PAC system convencional eletromecânico de uma subestação.
Figura 1 – PAC system convencional eletromecânico
Portanto, tem-se um sistema na sala de controle (PAC System) que obedecendo a um

conjunto de regras, faz o controle e proteção dos equipamentos de pátio do sistema de
10
potência. A evolução tecnológica inicial foi a digitalização do sistema substituindo elementos

cablados elétricos de painéis com chaves e relés eletromecânicos por interface
computacional (IHM do SCADA local) e unidades de controle digitais (Unidade Terminal
Remotas – UTRs, Unidades de Aquisição e Controle – UACs) com relés de proteção digitais
baseados numa rede de comunicação com protocolo serial e depois na rede Ethernet. Estes
sistemas evoluíram de protocolos proprietários para padronizados mestre/escravo (DNP 3.0,
IEC 60870-5-104) e finalmente para aplicação da norma IEC 61850 no nível de casa de
controle (Station Level), aplicando MMS e mensagens GOOSE. A Figura 2 mostra esta
evolução.
Figura 2 – PAC system digital – Sala de controle digital
A próxima etapa, já em andamento no Brasil, é a digitalização do nível de pátio, com a

aplicação do Process Level. Neste caso, aplicando-se Merging Units (MUs) ou diretamente
Transformadores de Corrente (TCs) e Transformadores de Potencial (TPs) eletrônicos e
medidas via protocolo de comunicação, SV e estados via mensagens GOOSE. A rede
Ethernet se estende para o pátio, conforme podemos ver na Figura 3.
Figura 3 – PAC system digital – Sala de controle e pátio digitais
11
É interessante observar que o conceito de proteção, supervisão e controle não muda.

Continua-se tendo um sistema, independente da tecnologia que seguindo regras garante o
controle e proteção dos equipamentos de pátio.
Quando se pensa numa subestação completamente digital (full digital), a norma IEC 61850
é atualmente a melhor estratégia para garantir interoperabilidade, flexibilidade, gestão da
vida útil, desempenho e confiabilidade. A Figura 4 mostra as partes da norma, que definem
todos os aspetos de uma subestação digital.
Figura 4 – Partes da Norma IEC 61850 [27]
Portanto, a norma IEC 61850 define os aspectos do sistema, a definição de uma linguagem
para descrição das funcionalidades (System Configuration description Language - SCL), um
modelo de dados e os serviços de comunicação. Ela adota os protocolos de comunicação:
modelo cliente servidor (MMS) para controle e supervisão, GOOSE para comunicações
horizontais substituindo o cabeamento metálico convencional, e SV para grandezas
analógicas. O sistema pode ser representado pela Figura 5.
Figura 5 – Visão do sistema PAC conforme a Norma IEC 61850
12
As principais definições que serão aplicadas são:

 SCL: System Configuration description Language (UML/XML);
 SSD: System Specification Description;
 CID: Configured IED Description;
 SCD: Substation Configuration Description;
 Protocolos de Comunicação: MMS, GOOSE, SV.
As funções de aplicação (application functions) de um SAS são: controle, supervisão,

proteção e monitoramento dos equipamentos primários. Outras funções de sistema (system
functions) estão relacionadas ao próprio sistema como, por exemplo, supervisão das
comunicações. As funções podem ser atribuídas a três níveis: o nível da casa de controle
(Station Level), o nível do vão (Bay Level) e o nível do pátio (Process Level), conforme a
Figura 6.
Figura 6 – Níveis da subestação [26]
O sistema se organiza pela entidade que fornece o serviço (Server), dentro de uma instância
física (Logical Device) onde se tem uma funcionalidade (Logical Node). A funcionalidade tem
uma serie de atributos que definem a forma como se adquirem informações, enviam
controles, sincroniza tempo e transfere arquivos.
Figura 7 – Definição das instâncias [1–Part 7-1]
13
A norma IEC 6850 define os tipos de Logical Nodes, definindo as categorias e a letra inicial
de cada tipo. A parte 7-4 traz essas definições.
Figura 8 – Logical Nodes [1-Part 7-4]
A Figura 9 mostra um exemplo de como definir uma função e suas diferentes instâncias.
Neste caso a sincronização de manobra do disjuntor, a proteção de distância e de
sobrecorrente.
Figura 9 – Exemplo de Logical Nodes [1-Part 1]
O processo de aplicação de uma solução IEC 61850 permite a descrição da subestação

através de uma linguagem padronizada (SCL). O projeto inicia com a configuração de um
arquivo utilizando alguma ferramenta de software na qual se descrevem as características
da subestação: diagrama unifilar, vãos (bays) existentes, funcionalidades de proteção e
controle, arquitetura da rede Ethernet, sincronização de tempo, informações para o sistema
de supervisão. Tem-se então uma descrição de toda a especificação do PAC System (SSD).
Com ele, o fornecedor define os IEDs necessários para atender as funcionalidades e
requisitos solicitados, fazendo a configuração da aplicação em cada IED e as informações
que estes irão disponibilizar na rede (CID).
Durante o processo de implementação, o arquivo SSD seguirá incorporando mais detalhes e
históricos de modificações. Ao final tem-se o arquivo que descreverá a subestação (SCD),
detalhando onde os dados se encontram e para onde devem ir. Este arquivo permitirá a
gestão de todo o sistema, com eventuais modificações funcionais e de arquitetura de
comunicação.
14
Em alguns casos a solução caminha pela definição dos IEDs à medida que são definidas as
funcionalidades necessárias. Em outros casos, podem já estar definidos os IEDs a serem
aplicados. Neste último caso o caminho será diferente porque serão definidos os
dispositivos lógicos (Logical Devices) para o mapeamento. A Figura 10 a seguir mostra o
fluxo de trabalho de um projeto baseado na norma IEC 61850.
Figura 10 – Implementação de uma solução IEC 61850 [26]
A correta aplicação da solução e a qualidade do projeto têm enorme relação com a

disponibilidade adequada de ferramentas de software, aderência dos IEDs à norma IEC
61850 e da qualificação das equipes de projeto, manutenção e operação (tanto da empresa
de energia quanto do fornecedor).
3.2 BENEFÍCIOS NA ADOÇÃO DA NORMA
As vantagens na adoção de uma solução baseada na norma IEC 61850 dependem da

estratégia correta na sua implantação. Os benefícios se estendem às obras civis no pátio,
lançamento de cabos e serviços associados (como medição de resistência de terra -
Megger), testes de comissionamento, tempo de implantação, documentos de projeto e
procedimentos de manutenção. Por isso, a solução deve ser definida no início do projeto e
planejada com uma visão global.
A questão que sempre deve estar presente é o motivo pelo qual está se optando por esta
solução, focando para que os benefícios sejam de fato reais e assimilados por todas as
equipes envolvidas na implantação, manutenção e operação da subestação.
Os principais motivos para adotarmos uma solução IEC 61850 são:
• Interoperabilidade: existem diversas soluções digitais que incluem dispositivos no
pátio para comunicação com os IEDs na sala de controle, mas a comunicação não
acontece em protocolos abertos e padronizados. A norma define muito claramente
os protocolos de comunicação (MMS, GOOSE, SV). Também define os requisitos de
redundância de mensagens (Parallel Redundancy Protocol – PRP e High-availability
Seamless Redundancy – HSR), e as possibilidades de sincronização de tempo
(Simple Network Time Protocol – SNTP, Precision Time Protocol – PTP da norma
IEEE 1588). Isso permite que diferentes dispositivos, de fabricantes e gerações
diferentes, possam funcionar em conjunto. Além disso, as ferramentas de software
15
para configuração, monitoramento do desempenho e testes funcionais, uma vez

padronizadas, podem ser aplicados com facilidade. A interoperabilidade deve ser
garantida pela homologação de todos os IEDs, infraestrutura de comunicação,
ferramentas de software e sistema de supervisão;
• Facilidade de Substituição: a possibilidade de realizar a troca de dispositivos do
sistema, especialmente dos IEDs, fica muito facilitada quando se desacopla o pátio e
os IEDs da sala de controle. A configuração física cablada de entradas elétricas de
sinais, medidas e controles restringe a troca a modelos idênticos para permitir as
funcionalidades implementadas. Mas quando os sinais são via protocolo, não existe
mais esta limitação, já que dependem exclusivamente de configuração. Inclusive
podem-se gerenciar as evoluções tecnológicas, tanto na sala de controle quanto no
pátio. Trocar MUs por equipamentos primários inteligentes, TCs e TPs óticos (ou
combinados), disjuntores, transformadores, chaves, que incorporam eletrônicas e se
comunicam diretamente por rede publicando e recebendo comunicação não obrigam
a alterar a sala de controle. Mudanças na sala de controle adotando, por exemplo,
CCUs (Central Control Units), ou seja, trocar um conjunto de IEDs por um
computador central não obrigam a mudar a solução do pátio. Como as novas
tecnologias tem um ciclo de vida em função da eletrônica envolvida a gestão de cada
ativo fica muito mais fácil;
• Documentação: Considerando que a norma define claramente os arquivos (SSD,
CID, SCD) e a linguagem em que devem ser escritos (SCL), gerar uma
documentação pode ser realizado com grande facilidade. Obviamente que existe um
grande impacto cultural, já que listas de fiação serão substituídas por descrição da
rede Ethernet e tráfego de sinais. A visualização também terá que migrar de uma
lógica relacional para uma orientada a objeto. Além disso, a documentação de
procedimentos e testes pode ser realizada automaticamente, baseando-se no
arquivo SCD e modelos (templates) a serem aplicados. Os resultados e análise
também podem ser gerados e documentados automaticamente. Toda a análise de
desempenho de tempo real do PAC system também pode gerar relatórios
predefinidos;
• Facilidade de alterações: durante a vida útil de qualquer PAC system é necessário
alterações, seja para corrigir conceitos do projeto, padronizar filosofias, implementar
novas funcionalidades ou atender necessidades sistêmicas. Obviamente que poder
realizar estas alterações sem a necessidade de lançamento de cabos e/ou instalação
de relés auxiliares, as tornam muito mais fáceis. A digitalização total permite também
realizar testes com maior facilidade e segurança, tanto em laboratório quanto no
campo. A edição mais recentes da norma inclui mecanismos para realização de
testes;
• Gestão de Ativos: considerando que numa aplicação total da norma IEC 61850,
incluindo nível de casa de controle (Station Level) e nível de pátio (Process Level),
passa a se ter inteligência em quase todos os ativos, a sua gestão fica muito mais
eficiente e eficaz. É possível monitorar em tempo real desempenho, histórico,
disponibilidade e aplicar políticas de manutenção preventiva com maior segurança. A
gestão de ativos tem se tornado cada vez mais importante, empresarialmente para
garantir o retorno dos investimentos e tecnicamente para garantir a disponibilidade
do PAC system, fundamental para a segurança e confiabilidade do sistema de
potência. A integração das informações de tempo real e corporativas potencializa
positivamente toda a gestão da empresa;
• Virtualização Total: quando se compara o desenvolvimento tecnológico em outras
áreas similares, como telecomunicações ou sistemas de Tecnologia da Informação
(TI), percebemos que a digitalização permitirá também se apropriar no futuro de
tecnologias de virtualização para realizar funções PAC, que darão grande facilidade
de implementação com alocação livre das funcionalidades e gestão, especialmente
quanto à disponibilidade. O desenvolvimento computacional possivelmente evoluirá
16
permitindo o desempenho necessário para funções de proteção que exigem tempos

de respostas mais rigorosos em milissegundos;
• Disponibilidade: os sistemas terão maior potencial de disponibilidade, uma vez que
será bem mais fácil ter funcionalidades redundantes (backups) em diferentes
dispositivos. Além disso, a substituição de um equipamento poderá ser efetuada com
maior rapidez, com poucas implicações físicas (praticamente alimentação e conexão
na rede Ethernet);
• Segurança Cibernética: a migração dos PAC systems para o ambiente digital
baseado numa rede Ethernet trouxe um componente novo de preocupação com a
segurança cibernética. Ela já é um aspecto a ser abordado em qualquer sistema
digital, mas a importância cresce quando se aplica a norma IEC 61850, na qual
incorporamos mensagem de pátio, GOOSE e SV, que interferem diretamente no
desempenho e atuação do sistema de controle e proteção. A norma prevê uma série
de mecanismos e ações para garantir a segurança cibernética, que podem ser
incorporadas nas políticas e práticas da empresa. Além disso, a possível
virtualização facilita a recuperação e normalização em eventuais incidentes que
possam criar indisponibilidade de dispositivos. Nesse caso, a recuperação do
sistema é transparente.
Obviamente que as vantagens apontadas serão reais, conforme já apresentado, à medida

que os produtos forem de fato plenamente aderentes à norma IEC 61850, a qualificação das
equipes adequadas para o desafio tecnológico, e as empresas alterarem sua cultura e
estruturas para os novos desafios.
3.3 DIFICULDADES NA ADOÇÃO DA NORMA
Até agora foi abordada a aplicação da norma IEC 61850, considerando sua correta
implementação. Obviamente que nenhuma tecnologia disruptiva se estabelece sem
problemas e desafios. A seguir serão comentadas estas dificuldades.
Nas primeiras aplicações, especialmente baseadas na primeira edição da norma, a
interoperabilidade entre diferentes fabricantes, e muitas vezes entre versões diferentes de
produtos de mesmo fabricante, era bastante difícil. Além disso, em vez de aplicar os Logical
Nodes específicos determinados em norma, era utilizado um número excessivo de pontos
genéricos, do tipo Generic Process I/O - GGIO, que são previstos para ser utilizado em
situações de funcionalidades não definidas, o que não era o caso. Possivelmente parte do
problema foi a incorporação das funcionalidades da norma em IEDs existentes, como se
fosse uma casca focada especialmente nos protocolos de comunicação, MMS e GOOSE.
Por não serem produtos projetados conforme a norma, nativos em sua concepção, o arquivo
para descrição da subestação – SCD, não era totalmente aderente à filosofia da IEC 61850.
Esta situação levou a se ter vários arquivos SCD, de acordo com cada ampliação ou
modernização, e não um único arquivo para a subestação.
Esta falta de conformidade à norma dificultou a eficiência dos softwares envolvidos na
configuração dos sistemas, que em ocasiões perdiam configurações ao se fazerem
alterações posteriores à implementação. Apesar disso, o impacto no desempenho no tempo
real não ficou comprometido, mas dificultou muito a manutenção e a integração com novas
ampliações. Outro aspecto importante é que num ambiente de subestação digital
precisamos de novas ferramentas de software. Elas devem ser focadas de acordo com o
objetivo (configuração, diagnostico, registro e teste), e com o nível da equipe (básica,
intermediaria e especializada). A questão está em que ainda têm-se ferramentas de
fornecedores focadas em produto, e nas primeiras implementações com problemas.
17
Também existe uma dificuldade das empresas para entender quais ferramentas são
necessárias e em definir ter um processo de requisitos e de homologação.
A documentação é outro aspecto desafiador. Especialmente porque muitas vezes se insiste
em manter uma forma não adequada. Culturalmente, tanto as empresas quanto
fornecedores, tendem a manter a forma de documentação de soluções convencionais. Isto
faz com que a documentação não seja adequada, e não aproveite as vantagens de uma
solução totalmente digital. Nas primeiras aplicações, em muitos projetos a documentação
ficou incompleta, ou de difícil interpretação, dificultando especialmente as equipes de
manutenção e as futuras ampliações.
A regulação também é um aspecto importante a considerar na aplicação da norma IEC
61850. A solução de uma subestação totalmente digital (full digital) baseada em
comunicação numa rede Ethernet com dispositivos eletrônicos deve atender aos
procedimentos de rede definidos pelo Operador Nacional do Sistema Elétrico – ONS. Os
requisitos definidos pela Agencia Nacional de Energia Elétrica – ANEEL na definição de
autorização dos empreendimentos também devem fazer parte dos requisitos. Implementar
novas tecnologias sem uma definição clara na regulação pode dificultar a segurança da
solução. Por isso é importante que os requisitos regulatórios permitam de maneira clara a
aplicação de uma solução totalmente digital. Cabe ressaltar que o ONS está em processo
de atualização de seus requisitos para os sistemas de proteção e controle constantes em
seus procedimentos de rede, visando adequação às subestações digitais, tomando como
referência as experiências já adquiridas por operadores e empresas internacionais, além
dos projetos pilotos implementados e andamento no Brasil.
A aplicação de uma solução totalmente digital impacta fortemente nas rotinas de como se
executa um projeto e se realiza a manutenção. Nos projetos implementados, normalmente
não houve um foco para que a implementação seguisse um fluxo consistente. Além disso,
nem sempre as empresas prepararam as equipes de manutenção para ter o domínio e
compreensão de uma solução IEC 61850. Os procedimentos devem ser revistos para
atender aos requisitos das novas tecnologias e se apropriar das suas vantagens.
Da mesma forma, a convergência tecnológica implica numa mudança na estrutura das
organizações, já que a segregação de ativos e funcionalidades não está mais limitada
fisicamente. A especialidade de conhecimento também não é mais única, com necessidade
de aproveitar a expertise de cada área: redes, automação, proteção, e controle. Porém, na
maioria dos casos, não ocorreu esta reorganização e o domínio da tecnologia nas empresas
é limitado. A qualificação das equipes nem sempre aconteceu adequadamente, de maneira
sistematizada, com domínio sobre o conhecimento básico (redes, protocolos e norma) e de
produtos (software, configuração e ajustes).
3.4 TENDÊNCIAS TECNOLÓGICAS FUTURAS E REQUISITOS ADERENTES À NORMA
Quando se planeja uma solução digital é importante estar atento às tendências tecnológicas
que podem impactar ao longo da vida útil das instalações, considerando futuras ampliações
e modernizações. Neste sentido existem diversas discussões sobre futuras tecnologias e
procedimentos dentro do CIGRE, que está sempre atento a estas novas potencialidades.
Uma das tendências futuras é a completa virtualização do ambiente do PAC system. A
limitação a dispositivos específicos (IEDs) não existira mais, sendo possível a aplicação de
Central Control Unit - CCU, ou seja, computadores como ambiente onde as funcionalidades
de proteção e controle são instanciados. Esta discussão está em andamento no WG B5.60 -
Protection, Automation and Control Architectures with Functionality Independent of
Hardware.
Outra discussão importante é como podemos melhorar o processo de especificação, numa
linguagem de mais alto nível, de maneira a facilitar que a descrição do PAC system não
18
exija grande domínio da linguagem SCL ou de software específico. O WG B5.64 - Methods

for Specification of Functional Requirements of Protection, Automation and Control está
discutindo esta questão.
Também a questão de gestão de ativos do PAC system precisa ser aprofundada, e agregar
a ela as vantagens tecnológicas de uma solução totalmente digital (full digital). Existem
muitas possibilidades e vantagens neste sentido, e o WG B5.63 - Protection, Automation
and Control System Asset Management está aprofundando estas questões.
A definição e otimização do processo de sincronismo de tempo é fundamental numa solução
IEC 61850. Existem diversas possibilidades e esta questão está sendo discutida no
WGB5/D2.67 - Time in Communication Networks, Protection and Control Applications –
Time Sources and Distribution Methods para apontar as melhores práticas.
O B5.68 - Optimisation of the IEC 61850 Protection, Automation and Control Systems
(PACS) engineering process and tools, está abordando um aspecto importantíssimo que é a
melhoria nas ferramentas de software para projeto, manutenção e documentação dos
sistemas.
Considerando a aplicação da digitalização do pátio nos projetos futuros no Brasil, as
discussões no WG B5.69 Experience feedback and Recommendation for implementation of
Process Level in PACS podem ser muito importantes para incorporar requisitos
aproveitando a experiência e o conhecimento existente. Também o WG B5.70 - Reliability of
PACS (Protection Automation and Control System) – Evaluation Methods and Comparison
of Architectures, pode auxiliar na definição da arquitetura de futuras soluções.
3.5 HISTÓRICO DE SUAS APLICAÇÕES NO BRASIL
As primeiras aplicações de soluções IEC 61850 iniciaram em 2007 no nível de casa de

controle (Station Level). Atualmente, especialmente no sistema de transmissão, o padrão de
solução nas empresas é aplicar soluções de PAC system desta maneira. Possivelmente
hoje pelo menos 50% dos sistemas têm aplicações da norma. A modernização dos sistemas
legados levará a um cenário em que, num horizonte aproximado de 10 anos, todos os
sistemas sejam aplicações IEC 61850. As principais dificuldades foram nas ferramentas de
configuração, no domínio das equipes e na aderência dos produtos à norma.
A evolução da norma IEC 61850 da edição 1.0 para a 2.0 melhorou bastante a definição de
aspectos de implementação, mas também trouxe problemas para integrar sistemas de
versões diferentes. Atualmente a maioria dos fabricantes tem dispositivos projetados
nativamente para a norma, e isso favorece muito sua configuração e desempenho. As
arquiteturas de redes aplicadas variam entre configurações estrela e anel. A sincronização
de tempo aplicam soluções SNTP e Inter-Range Instrumentation Group B (IRIG-B). As
mensagens GOOSE são aplicadas para intercâmbio de diversos tipos de dados, usados, por
exemplo, para intertravamentos e oscilografia (pontos digitais) e também para definição de
trip (condições de transferência de disparo entre vãos).
Naturalmente o próximo passo é a aplicação do nível de pátio (Process Level). Neste
sentido a estratégia de diversas empresas no Brasil foi a de aplicar projetos piloto, para
conhecer a tecnologia, validar a sua aplicação e contribuir para a elaboração de requisitos
técnicos. São projetos que já tem pelo menos cinco anos de implementação, portanto já tem
um bom histórico de desempenho. Atualmente alguns deles estão sendo aprimorados com
novos produtos, funcionalidades e inclusive com equipamentos primários, TCs e TPs óticos.
Mas desde 2019 já temos projetos com a aplicação do nível de pátio (Process Level) em
andamento, alguns inclusive já implementados. A expectativa é ganhar a experiência
operacional e avançar para que o nível de pátio (Process Level) se torne um padrão de
solução nos novos projetos.
19
4. ESPECIFICAÇÃO DE DISPOSITIVOS E SISTEMAS

BASEADOS NA NORMA IEC 61850
4.1 DESCRIÇÃO DE UM SISTEMA BASEADO NA NORMA IEC 61850
A tecnologia digital vem sendo aplicada nos sistemas de supervisão, controle e proteção há
mais de 25 anos. Neste período, passamos de uma realidade eletromecânica e de
informação mínima, para uma tecnologia digital que invadiu o controle e proteção dos
equipamentos, as interfaces de operação além de uma supervisão completa dos processos
envolvidos. As novas tecnologias permitiram aumentar consideravelmente a visibilidade do
sistema de potência melhorando a qualidade da operação em tempo real, principalmente em
sistemas altamente complexos como é o caso brasileiro.
Os requisitos funcionais de um sistema PAC não estão relacionados somente ao tipo de
tecnologia aplicada para seu funcionamento: tem como ponto de partida as funções de
controle, proteção e supervisão. Além disso, os requisitos regulatórios das agências, que
determinam a concessão e as condições operativas do sistema elétrico de potência, devem
ser obrigatoriamente considerados na concepção do SAS.
Uma especificação técnica tem que descrever as funcionalidades, a infraestrutura e a
conexão com os equipamentos primários. Quando se opta por uma solução baseada na
norma IEC 61850, as principais diferenças estão na forma de apresentar estes requisitos,
baseado numa linguagem descritiva, a SCL, numa infraestrutura em que os sinais são
transmitidos através de protocolos de comunicação horizontal e vertical na casa de controle
e/ou com os equipamentos de pátio.
Figura 11 – Sistema baseado numa solução IEC 61850
20
A especificação deve considerar também o processo de implantação e a gestão ao longo da

vida útil do sistema. Isto significa descrever como serão os procedimentos de aceitação,
testes, ferramentas necessárias para projeto e manutenção e operação do sistema. Devem-
se incluir ainda os treinamentos necessários das equipes envolvidas, de acordo com cada
responsabilidade e nível de complexidade que envolve a atividade.
Considerando que a intenção é ter aderência a uma norma, a IEC 61850, deve-se também
contemplar quais os requisitos que serão necessários e a maneira que será verificada a
conformidade. A especificação de uma solução digital deve também abordar a questão da
segurança cibernética, especialmente quando a comunicação de sinais envolvem o controle
e a atuação da proteção. A infraestrutura e funcionalidades digitalizadas permitem o
monitoramento continuo do desempenho, de falhas, da confiabilidade e da disponibilidade.
Figura 12 – Etapas na implementação de um sistema IEC 61850 [6]
As três primeiras etapas (Figura 12) estão relacionadas à especificação do sistema:

 Especificação do SAS:
 Definição do sistema secundário;
 Geração do arquivo SSD onde está a descrição da subestação.
 Planejamento da Implementação: Especificação dos Dispositivos:

 Planejamento e seleção dos dispositivos.
 Planejamento da Implementação: Especificação do Sistema:

 Definição da rede de comunicação;
 Seleção dos dispositivos de comunicação;
 Definição dos protocolos de comunicação.
O ponto de partida de um projeto é a necessidade da própria subestação, definida por quem

é responsável pela expansão do sistema elétrico de potência. Com a definição das
características para o sistema, é possível definir as funções necessárias do sistema PAC. O
projeto irá definir com mais detalhes toda a forma de documentação, sinais e
21
funcionalidades. Com essas informações será possível gerar o arquivo previsto pela norma
IEC 61850 (SSD) que descreve a subestação.
Figura 13 – Etapas do processo na especificação: Subestação
A partir destas informações é possível fazer toda a descrição da infraestrutura de

comunicação, parte fundamental nos requisitos de disponibilidade e desempenho do
sistema. Isto inclui os objetos e serviços a serem aplicados e, se for prática da empresa, os
padrões a serem adotados.
Figura 14 – Etapas do processo de engenharia: Especificação do sistema
22
Os elementos a seguir devem fazer parte básica de uma especificação:

• Diagrama unifilar da subestação;
• Diagrama unifilar CA e CC dos serviços auxiliares;
• Nomenclatura dos dispositivos de alta tensão;
• Estrutura de endereços da subestação;
• Lista de endereços;
• Lista de parametrização;
• Listas de sinais e requisitos de fluxo de dados;
• Informações para registro e armazenamento local;
• Agrupamento de sinais e alarmes;
• Informações aos centros de operação;
• Informações de comunicação entre os IEDs (incluindo serviços de comunicação);
• Informações operacionais, como estados dos equipamentos de comutação,
valores analógicos, estado do transformador (TAP, ventilação, temperaturas etc.);
• Controle e seleções de condições operacionais: seleção de religamento
(monopolar, tripolar), habilitação de controle (local/remoto), condição de
manutenção;
• Informações para suporte da manutenção;
• Informações para estatísticas e planejamento;
• Informações para análise de falhas;
• Detalhes sobre requisitos funcionais;
• Diagrama de blocos de funções;
• Detalhes sobre requisitos funcionais;
• Especificação das funcionalidades a serem executadas (incluindo dados de
desempenho e requisitos de disponibilidade) e sua alocação no diagrama unifilar;
• Requisitos de IHM local: operações, interfaces com o processo e outros centros
de controle;
• Requisitos de redundância e topologia;
• Interface com sistemas existentes;
• Layout físico (planta baixa, canaletas, cabos elétricos);
• Requisitos de segurança para os sistemas digitais;
• Esquemas de automação e monitoramento necessários;
• Requisitos de hardware (normas);
• Requisitos de teste e ferramentas associadas;
• Lista de verificação de teste padrão;
• Requisitos de documentação;
• Treinamentos para operação, engenharia e manutenção.
Na etapa de projeto os seguintes aspectos serão necessários:

• Estudo de curto-circuito;
• Desenhos elétricos de todos os equipamentos eletromecânicos;
• Desenhos esquemáticos que incluem pelo menos o seguinte:
o Desenhos construtivos de painéis;
o Fiação (interligação) entre todos os equipamentos;
o Intertravamento e outras lógicas;
o Lista de equipamentos;
o Esquemáticos (relés auxiliares, disjuntores);
o Identificações dos equipamentos e dispositivos.
• Quantidade de IED: modelos, versões de firmware e hardware;
• Desenhos de interconexão;
• Desenho de posição dos equipamentos;
• Desenhos de layout dos painéis;
• Listas de cabos elétricos;
• Lista de materiais;
23
• Diagramas de interconexão de rede e layout da rede de comunicação;

• Definições de VLANs;
• Regras de firewalls;
• Sistema de sincronismo de tempo;
• Lista de cabos de comunicação;
• Arquivos de configuração;
• Definição de desenhos de telas da IHM;
• Procedimentos de Testes de Aceitação em Fábrica (TAF) e cenários de teste;
• Procedimentos de Testes de Aceitação em Campo (TAC) e cenários de teste.
Para sistemas de automação de subestações baseados em barramentos de comunicação,

os seguintes elementos adicionais podem ser incluídos:
• Diagramas que mostrem todos os dispositivos (para proteção e controle) se existem
redundâncias, rede de aquisição de dados, sincronização de horário e rede de
acesso remoto;
• Parâmetros de rede como IP e endereço MAC para cada dispositivo e o número de
porta no switch;
• Sinais de comunicação com o Registrador Digital de Perturbações (RDP).
A especificação técnica também deverá definir as ferramentas necessárias para as

diferentes etapas de implantação e gestão da vida útil da subestação de acordo com os
dispositivos e sua inter-relação na subestação. As ferramentas de software podem ser
divididas de acordo com o tipo de dispositivo para a parametrização.
 Nível de casa de controle;
 Nível de vão (bay);
 Nível de pátio.
As ferramentas podem também ser definidas de acordo com a fase do ciclo de vida na
subestação:
 Ferramenta de especificação do sistema;
 Ferramenta de configuração do sistema;
 Ferramenta de configuração do IED;
 Ferramentas de simulação;
 Ferramentas de engenharia de proteção;
 Ferramentas para teste de dispositivos;
 Ferramenta para testes de sistema;
 Ferramentas de diagnóstico;
 Ferramentas de documentação;
 Ferramentas de manutenção.
Desta maneira foram descritos todos os requisitos de uma especificação técnica e do projeto
básico necessário do sistema PAC. A seguir serão aprofundados os aspectos mais
específicos de uma solução aderente à norma IEC 61850.
24
4.2 DESCRIÇÃO DO SISTEMA
O ponto de partida de um projeto aderente à norma IEC 61850 é a configuração do arquivo

SSD que descreve todas as características da subestação, o diagrama unifilar, as funções
do sistema primário e do sistema de proteção, automação e controle.
Devem ser utilizadas ferramentas de software para esta etapa, independente de um
fornecedor ou de uma determinada linha de produtos, já que seguem uma linguagem
definida SCL. A partir deste arquivo é possível dar andamento ao projeto executivo.
Figura 15 – Modelo de referência do fluxo de informações no processo de configuração [28]
Como se pode ver na Figura 15, a primeira etapa é a especificação do sistema utilizando
uma ferramenta de especificação (specification tool) que será utilizada para gerar o arquivo
SSD. Usando uma ferramenta de configuração do sistema (system configurator) pode-se
configurar uma solução, um sistema, utilizando as funcionalidades dos dispositivos descritas
nos arquivos ICD e IID em conjunto com o arquivo SSD gerando um arquivo SCD. Com uma
ferramenta de configuração de IED (IED configurator) é possível descarregar em cada
dispositivo uma configuração dos IEDs, os arquivos CID.
Gerado por uma ferramenta de software, o arquivo SSD contém as informações da
subestação, incluindo o diagrama unifilar e uma biblioteca de funções, Logical Nodes.
O nome dos Logical Nodes pode ser editado:
• Prefixos e instâncias dos Logical Nodes podem ser editados;
• Instancias de Logical Nodes podem ser inseridos a partir de uma biblioteca existente;
• Data Objects podem ser criados ou remanejados através da função drag and drop;
• Verificações de consistência são feitos automaticamente para garantir que as regras
e números de caracteres dos objetos não sejam violados.
Uma ferramenta de configuração deverá lidar com as informações apresentadas na Figura
16.
25
Figura 16 – Entrada e saída de ferramenta independente de configuração do sistema [6]
O produto final é uma descrição completa da subestação no arquivo SCD. Ele servirá não
apenas para realizar a configuração dos equipamentos, mas também para gerar toda a
documentação do sistema.
4.3 DEFINIÇÃO DAS FUNCIONALIDADES
A norma IEC 61850 define o sistema lógico como a união de todas as aplicações e funções
de comunicação, executando alguma tarefa completa como o gerenciamento da subestação
e empregando nós lógicos. O sistema físico é composto por todos os dispositivos que
hospedam essas funções e a rede de interconexão física da comunicação. Dentro do
escopo da norma, sistema sempre se refere ao SAS (Sistema de Automação da
Subestação).
Figura 17 - Representação da função com dados de comunicação [26]
26
A definição das funções está relacionada aos grupos de funções lógicas do sistema de
proteção, automação e controle, classificados conforme a Figura 18. Pode-se definir cada
um deles na especificação, incluindo a comunicação horizontal de mensagens GOOSE.
Figura 18 – Estrutura hierárquica do modelo de dados da norma IEC 61850 / Logical Nodes
A definição das funções pode seguir padrões de projeto da empresa. Além das funções
características para cada tipo de vão (bay), transformador, linha de transmissão, barra,
reator, banco de capacitores, gerador e serviço auxiliar. As funções não definidas na norma
podem ser organizadas como genéricas GGIO, e padronizadas dentro dos projetos de
acordo com as definições da empresa.
A Figura 19 apresenta como é a estrutura de dados de um IED para um cliente.
Figura 19 - Estrutura de dado vista por um client IEC 61850 para o IED P1L2PR1 [28]
Outro aspecto importante é definir a relação das nomenclaturas das funções IEC 61850,
incluindo as genéricas GGIO, com as nomenclaturas operacionais. Uma boa estratégia é a
utilização de modelos (templates) que relacionam estas informações. Ela é necessária para
estabelecer como as informações do sistema serão apresentadas aos diversos usuários do
27
sistema SCADA. A operação de tempo real, definindo descrições em visores de alarme,

unifilares e históricos. A pós-operação para análise de ocorrências do sistema de proteção e
de controle do sistema de potência. Também a manutenção com as informações
necessárias para análise e ações preditivas, programadas e corretivas.
Figura 20 – Relação do projeto IEC 61850 e o Sistema SCADA
Para fazer esta relação, podemos incluí-la na descrição do ponto dentro do arquivo SCL ou
incluí-la externamente com outras formas de documentação. É mais comum utilizar planilhas
para fazer esta relação aplicando dicionários que determinam tratamento de cada
informação. Isto ocorre também por causa de dispositivos que não estão incluídos na
solução IEC 61850, porque aplicam tecnologias mais antigas com protocolos como ModBus,
DNP ou IEC-104.
A Figura 21 mostra um exemplo da relação entre as funções tradicionais ANSI, Logical
Nodes IEC 61850 e sistema SCADA.
Figura 21 – Tabela com exemplo de relações das funcionalidades de um projeto IEC 61850
Portanto, a definição das funcionalidades deve atender a todos os aspectos do projeto:

proteção, automação, controle, supervisão, manutenção, operação, gestão de ativos,
comunicação, monitoramento.
28
4.4 REQUISITOS NUMA SOLUÇÃO IEC 61850
A norma IEC 61850 tem diversos requisitos obrigatórios e outros opcionais. Por isso é
fundamental que uma especificação técnica inclua as funcionalidades desejadas.
A descrição destes requisitos está apresentada nas seguintes partes da norma:
 Part 3: General requirements;
 Part 4: System and project management;
 Part 5: Communication requirements for functions and device models;
 Part 6: Configuration description language for communication in power utility
automation systems related to IEDs;
 Part 10: Conformance testing
Quando se aplica uma especificação padronizada com um arquivo SSD, garante-se o

atendimento aos requisitos que se desejam ver aplicados na solução projetada, envolvendo
as funções de proteção, automação, controle, comunicação e supervisão. Também é
possível fazer isto numa especificação descritiva, de modo tradicional. Porém, ela será mais
frágil e mais passível de não atender a todas as funcionalidades desejadas.
Outro aspecto importante é a definição dos requisitos de desempenho do sistema. Vários
deles são definidos em norma, mas é importante ressaltá-los numa especificação e definir
como serão realizados testes que verificarão o seu atendimento.
Os principais indicadores de desempenho de um sistema IEC 61850 são o tempo da
comunicação vertical para o sistema SCADA, na comunicação horizontal e do pátio para os
IEDs, da rede de comunicação e do sistema de sincronização de tempo. Os requisitos
dependem da aplicação a que a função se destina, sendo consistente com os tempos
envolvidos e garantindo o desempenho de todo o sistema de proteção, automação e
controle.
4.4.1 Requisitos de comunicação
Na especificação técnica estão definidos todos os protocolos de comunicação envolvidos na

solução do sistema PAC. Dependendo do nível de implantação que está sendo aplicada da
norma IEC 61850, pode envolver somente a comunicação vertical MMS, ou de mensagens
GOOSE em funções na casa de controle de intertravamento ou posição. Se envolver a
digitalização do pátio (Process Level) vai envolver mensagens GOOSE para desligamento
de equipamentos devido a atuação de funções de proteção ou controle, assim como dados
de medições trafegando em SV.
Garantir o desempenho adequado da comunicação é fundamental já que estamos
substituindo sinais cablados de estados e medidas, que envolvem funcionalidades
fundamentais para um controle confiável e seguro do sistema de potência. Testes ao longo
do processo de implantação, em fábrica, no comissionamento e nos procedimentos de
manutenção devem verificar o atendimento aos critérios definidos no projeto.
Os requisitos de comunicação, MMS, GOOSE e SV estão apresentados a seguir. As
mensagens GOOSE foram aplicadas em funções de proteção definidas na norma IEC
61850, e a supervisão de acordo com os procedimentos de rede definidos pelo operador
nacional do sistema elétrico - ONS e critérios típicos das empresas.
29
Figura 22 – Desempenho das mensagens de comunicação
4.4.2 Requisitos de rede
Uma especificação técnica pode ou não definir uma arquitetura para a rede. Depende de
optar somente por requisitos de desempenho ou aplicar padrões da empresa que facilitem o
projeto e a manutenção, por ser uma solução conhecida. Pode se aplicar uma topologia
estrela, simples ou dupla, ou ainda, em anel. Neste caso é preciso definir o mecanismo de
recomposição: Rapid Spanning Tree Protocol (RSTP). As mensagens podem ser replicadas
por dois caminhos, e neste caso, as mensagens GOOSE não tem perda de tempo quando
da falha de um dos caminhos. Para se utilizar esta solução e garantir que as mensagens
tenham atraso zero pode-se aplicar os protocolos PRP numa rede em dupla estrela ou HSR
numa rede em anel. A solução de redundância com tempo de recomposição zero exige a
aplicação de dispositivos capazes de processar esta duplicidade e, portanto que possuam
suporte a PRP/HSR. No caso de conexão com outro dispositivo que não possua esse
suporte há necessidade de uso de redbox para fazer a interface. Os requisitos serão os
apresentados na Figura23 a seguir.
Figura 23 – Desempenho da rede de comunicação
A documentação da arquitetura de comunicação é também um requisito importante da

especificação, incluindo conexões físicas e virtuais. Ao mesmo tempo é uma área em
constante evolução, por isso é importante planejar uma solução olhando para o futuro, e não
apenas para o projeto em implementação.
O monitoramento da rede, o seu desempenho, disponibilidade e segurança cibernética
exigirão equipamentos e softwares dedicados a este fim, observando todos os segmentos
da rede e gerenciados numa visão global.
30
4.4.3 Requisitos de sincronismo de tempo
O sincronismo de tempo é outra funcionalidade fundamental num sistema digital. A norma

IEC 61850 permite mais de uma tecnologia, tendo vantagens e desvantagens em cada uma.
Cada serviço envolvido tem diferentes requisitos. A especificação deve ter a definição dos
serviços que utilizarão sincronismo de tempo, a solução desejada e seus requisitos. Dessa
forma, podemos destacar as principais definições:
• Servidores de tempo, seus requisitos físicos e funcionais, bem como os critérios de
redundância em caso de falhas;
• Integração de servidores de tempo (arquitetura) e suas conexões;
• Número de constelações de satélites;
• Posicionamento de antenas e conexões com os servidores de tempo;
• Infraestrutura dedicada (com fiação específica) ou via rede Ethernet e, nesse caso, a
aplicação de LANs virtuais;
• Protocolos a serem aplicados e sua adequação aos requisitos de equipamentos
(computadores, IEDs, etc.) e serviços;
• Adesão do sistema às normas internacionais relativas aos protocolos de
sincronização de tempo e conformidade com as normas dos diferentes
equipamentos e serviços;
• Monitoramento que será realizado para garantir o serviço de sincronização de
horário e como ele será informado à equipe de operação e manutenção;
• Testes de aceitação de fábrica e de campo;
• Rotinas para manutenção preditiva e corretiva do sistema.
Os principais serviços para os quais deverão ser definidos os requisitos de sincronismo de

tempo estão apresentados na Figura 24 a seguir.
Figura 24 – Serviços com sincronismo de tempo numa planta de energia [44]
A definição adequada depende da opção de ter uma rede física dedicada ou não para o
serviço de tempo, a segurança da informação, a disponibilidade e a precisão desejada. Com
estas informações podem-se definir os requisitos de precisão conforme as características de
desempenho apresentado na Figura 25 a seguir.
31
Figura 25 – Desempenho do sistema de sincronismo de tempo [44]
Em geral, a sincronização de tempo cumpre duas missões:

 Permitir eventos ocorrerem no momento apropriado (ou seja, evento sincronizado);
 Permitir a identificação temporal em que os eventos ocorreram ou não (isto é,
computação forense).
A primeira missão ocorre durante o fato; a segunda missão ocorre após o fato.
Figura 26 – Objetivo da sincronização de tempo [47]
Para o sistema elétrico de potência o sincronismo de tempo é importante para:

 Determinar as condições do sistema, estados e medidas em tempo real para realizar
o controle da rede de energia;
 Sincronizar fasores e estados do sistema para funções de supervisão, proteção e de
controle;
 Viabilizar a análise pós-operação para determinar sequência de eventos e
oscilografias;
 Permitir o controle automático do sistema de potência.
O Operador Nacional do Sistema Elétrico (ONS) no submódulo 2.7 (Requisitos Mínimos de

Supervisão e Controle para a Operação) especifica atualmente que o Sistema de
Supervisão e Controle Local (SSCL) e Unidades Terminais Remotas - UTRs devem ter seus
relógios internos ajustados com exatidão melhor ou igual a um milissegundo.
 Exatidão: (Accuracy): É quanto o relógio está próximo à referência;

 Precisão (Precision): O valor do menor incremento possível do contador do relógio.
32
Figura 27 – Precisão e exatidão do sincronismo de tempo
Existem diversos métodos de sincronização do tempo. Os mais comuns aplicados no

sistema de potência são Simple Network Time Protocol - SNTP, Inter-Range Instrumentation
Group - IRIG-B, e Precision Time Protocol – PTP (IEEE1588 edição 2).
O tempo de sincronismo do SNTP é acrescido de instabilidade (jitter) e latência por ser
distribuído via rede Ethernet, tornando-o não determinístico. O relógio GPS é assumido
como Stratum 0 (o mais preciso), acrescendo-se de 0,5 a 100 milissegundos a cada servidor
de tempo posicionado hierarquicamente após (Stratum n).
Figura 28 – Sincronização de tempo SNTP
O sincronismo realizado via IRIG-B é determinístico e com melhor precisão dependendo do

formato, porém às vezes se torna inviável considerando-se a necessidade de cabeamento
coaxial ou óptico adicional. A conversão do meio físico de elétrico para óptico pode
introduzir latência ao tempo de sincronismo.
BCD - Binary Coded Decimal,

coding of time (HH,MM,SS,DDD)
SBS - Straight Binary Second of day
(0....86400)
CF - Control Functions depending
on the user application
Figura 29 – Sincronização de tempo IRIG-B [46]
33
No padrão de sincronismo proposto pela norma IEEE1588 edição 2 (Precision Time Protocol
- PTP), os telegramas trocados para calcular o offset e o atraso relativo ao tráfego de rede
entre os relógios do cliente em relação ao servidor são processados em camadas mais
baixas (MAC) do padrão Ethernet. Sendo assim, alcançam precisão na faixa de décimos de
nano-segundos e garantem os requisitos da classe de sincronismo de tempo para SV (T5).
Entretanto, os dispositivos devem possuir tal funcionalidade já disponível no hardware,
sendo impossível sua implementação via software.
Figura 30 – Classes de sincronização de tempo [45]
4.5 REQUISITOS DE CERTIFICAÇÃO E HOMOLOGAÇÃO
A implantação de uma solução aderente à norma IEC 61850 envolve um processo de

engenharia que começa anteriormente à especificação técnica da empresa de energia.
Começam no desenvolvimento dos produtos, dispositivos, sistemas e softwares aplicados
na solução. A Figura 31 representa as etapas envolvidas.
Figura 31 – Engenharia do Processo [9]
Durante o desenvolvimento do produto as empresas aplicam os testes necessários para

garantir a adequação às diferentes normas internacionais. Para aprovação do produto é
necessária uma certificação de conformidade, ou seja, que o produto e/ou sistema atenda o
estabelecido na norma IEC 61850. O mais comum é este processo ser realizado por uma
entidade independente com reconhecimento internacional, como o KEMA. O teste de
34
certificação indica que o produto atende a todos os itens obrigatórios descrevendo quais dos
opcionais estão aplicados. Nesta etapa também são realizados testes de interoperabilidade
considerando as definições do produto.
Num segundo momento acontecem os testes de rotina do produto, que seria a homologação
do produto para as soluções aplicadas pela empresa. Cada empresa tem uma abordagem
para esta etapa. Pode ser uma etapa de homologação genérica, para ser aplicada em
futuras aplicações, ou parte dos testes de aceitação de um projeto. A homologação pode ser
realizada pela equipe própria da empresa, integradores ou o próprio fabricante
apresentando relatórios técnicos.
Os critérios de teste devem estar definidos na especificação técnica. São aplicados testes
de desempenho estáticos e dinâmicos, incluindo a infraestrutura de comunicação local e o
sistema de supervisão: alarmes, sinalizações e comandos. A execução destes testes
considera versão de firmware, modelo do IED, arquitetura e protocolos, configuração
aplicada nos IEDs e a inabilitação de funções não aplicadas. Os testes incluem também o
sistema de supervisão e controle, a IHM e toda a infraestrutura associada de plataforma
computacional e de comunicação da rede.
Nestas atividades as empresas utilizam frequentemente centros de pesquisa e empresas de
consultoria dedicadas a homologar produtos e sistemas, que possuem ambiente dedicado e
preparado para isto. Nos testes que envolvem a solução completa são utilizadas plataformas
no próprio fornecedor onde será aplicado que precisa aplicar roteiro de testes específico
definido pelo cliente.
A grande dificuldade da validação destes testes são as alterações posteriores,
principalmente com relação a novas versões de firmware gerando risco de efeitos colaterais.
Embora não seja o recomendado as empresas acabam aceitando novas versões de
firmware para atender a problemas detectados após a implantação dos sistemas, sem
conseguir aplicar a mesma quantidade de testes inicialmente realizados. A rigor, quando se
altera o firmware de um IED deve ser realizado novamente um conjunto de testes funcionais
pré-estabelecidos, para garantir o seu funcionamento no sistema em questão.
4.6 EXPERIÊNCIAS DE ESPECIFICAÇÕES
A implantação de soluções IEC 61850 aconteceu no mundo, e também no Brasil,

primeiramente pela validação dos protocolos de comunicação. As etapas aconteceram ao
contrário do que orienta a norma.
Por isso, as empresas não se focaram nas suas especificações iniciais com o arquivo SSD
ou a descrição das funcionalidades, Logical Nodes, e aderência à filosofia da norma. Houve
maior foco na descrição e homologação de protocolos, especialmente MMS. Mesmo o
desempenho das mensagens GOOSE não foi muito focado, já que as aplicações não
envolviam desempenhos rápidos, mas apenas intertravamentos de controle e posição de
vãos (bays) e condições (religamento, teleproteção).
Pesou também a pouca experiência e compreensão das equipes de projeto, que
continuaram com especificações descritivas em texto, tentando manter a forma tradicional
de desenvolver e aplicar um projeto, mas com novas tecnologias. A falta de domínio da
operação e manutenção também foi ponto negativo porque não realimentaram os
verdadeiros problemas, mostraram a falta de domínio e geraram atitudes reativas negativas
à aplicação da norma. Uma boa especificação técnica é fruto do domínio tecnológico do
projetista e da realimentação da experiência vinda da manutenção e operação dos sistemas.
Atualmente as especificações evoluíram na aplicação da norma, mas ainda não estão sendo
aplicados os arquivos SSD. Poucas vezes é exigida a aderência às funcionalidades da
norma, e por isso ainda se aplicam grande quantidade de funções genéricas GGIO. É
35
necessário que as empresas invistam mais em softwares que permitam gerar os projetos,
descrevendo de forma mais correta os requisitos.
Também se deve melhorar o conhecimento das equipes sobre a comunicação em rede
Ethernet. A migração da infraestrutura cablada para redes de comunicação exige aplicação
de uma engenharia de projeto da mesma forma. Assim como é preciso definir capacidade
de cabos, conexões, relés auxiliares, conectividade, para uma rede similarmente deve-se
definir capacidade, desempenho, conexões, conectividade, para poder garantir a
confiabilidade e disponibilidade do sistema de proteção, automação e controle.
Nesse sentido, o esforço das empresas nos últimos anos tem sido:
 Qualificação das equipes;
 Definição de padrões de projeto;
 Especificação técnica mais descritiva, formalizada, utilizando arquivos e linguagens;
padronizados, com relação às funcionalidades, requisitos e arquitetura de rede;
 Melhoria no processo de testes de aceitação.
Considerando que nos próximos anos a implementação do nível de pátio (Process Level)
será uma realidade nas empresas no Brasil, será muito importante melhorar todo o processo
de implementação, iniciando pela especificação técnica.
36
5. INTEGRAÇÃO ENTRE DISPOSITIVOS E REDES DE

PROTEÇÃO E AUTOMAÇÃO
5.1 INTRODUÇÃO
Desde o princípio, interoperabilidade entre IEDs (Intelligent Eletronic Devices) de diferentes

fabricantes sempre foi a principal motivação do surgimento da norma IEC 61850. Trata-se
de uma resposta à diversidade de padrões proprietários ou importados da automação
industrial que, tornaram os projetos demasiadamente complexos para as equipes de
trabalho e causaram dependência dos respectivos fabricantes. A comunicação eficiente
entre os novos dispositivos microprocessados tornou-se essencial para a execução das
funções de proteção e supervisão do Sistema de Automação de Subestações - SAS.
“The industry’s experiences have demonstrated the need and the opportunity for developing standard
communication protocols, which would support interoperability of IEDs from different
manufacturers. Interoperability in this case is the ability to operate on the same network or
communication path sharing information and command.” (IEC 61850-1 p. 9).
A interoperabilidade, consequência de um modelo de dados dos serviços de comunicação

deveria ser garantida por uma rede de comunicação cuja tecnologia fosse “a prova do
futuro”, ou seja, que os aprimoramentos futuros dessa rede fossem incorporados mantendo-
se certos níveis de compatibilidade.
“The objective of SAS standardization is to develop a communication standard that will meet
functional and performance requirements, while supporting future technological developments” (IEC
61850-1 p. 10).
A norma viria garantir a troca de informações entre IEDs através de objetos e serviços
comuns em ambientes de instalações de energia elétrica, independentes do protocolo de
comunicação utilizado:
“This standard specifies a set of abstract services and objects which may allow applications to be
written in a manner which is independent from a specific protocol” (IEC 61850-8-1 p. 14).
Em outras palavras, a modelagem do sistema digital de automação deveria ser

independente da maneira como os dados seriam transmitidos fisicamente, contrariamente à
filosofia de alguns protocolos legados nos quais os tipos de dados e os mecanismos de
transmissão eram desenvolvidos em conjunto.
Figura 32 – Comunicação de Sistemas Legados
37
Sendo assim, os esforços de padronização seriam direcionados à modelagem do sistema

PAC. Demais serviços como a transmissão das informações, acesso ao meio, sincronismo
de tempo entre outros, ficariam a cargo de padrões existentes e aceitos no mercado como o
IEC/IEEE/ISO/OSI.
“The communication protocol standard, to the maximum possible extent, should make use of
existing standards and commonly accepted communication principle.” (IEC 61850-1 p. 18).
Seguem abaixo algumas normas referenciadas na parte 8 da norma IEC 61850:
 IEC 62351-6, Power systems management and associated information exchange – Data
and Communication Security – Part 6: Security for IEC 61850;
 IEC 62439-3:2010, Industrial communication networks – High availability automation
networks – Part 3: Parallel Redundancy Protocol (PRP) and High availability Seamless
Redundancy (HSR);
 IEEE C37.111:1999, IEEE Standard Common Format for Transient Data Exchange
(COMTRADE) for Power Systems;
 IEEE 754:1985, IEEE Standard for Binary Floating-Point Arithmetic;
 IEEE 802.1Q:1998, IEEE Standards for Local and Metropolitan Networks: Virtual Bridged
Local Area Networks (VLAN);
 RFC 4330, Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, IETF,
available at http://www.ietf.org.
5.2 MODELAGEM DE DADOS
5.2.1 Níveis lógicos (Logic level) para as funções
A parte 5 da norma IEC 61850 define que as funções do sistema de automação são
logicamente alocadas em três níveis diferentes: Station, Bay/Unit e Process. O capítulo visa
criar funções existentes num sistema de automação de subestações e aplicá-las em
basicamente três níveis que são:
 Process level  Funções relacionadas aos equipamentos primários, sensores etc.,
ou seja, ligadas ao processo. Utilizam as interfaces (IFs) 4 e 5 do Bay/Unit level,
apresentadas na Figura 33;
 Bay/Unit level  Funções que utilizam dados do vão (bay) e interagem tanto
verticalmente com o processo (interfaces 4 e 5), quanto horizontalmente (interface 3).
De acordo com a norma, estariam fora do escopo caso as interfaces 4 e 5 cabeadas;
 Station Level  São definidos dois tipos:

Process related station level  Funções que utilizam dados de mais de um vão
(bay) ou de uma subestação completa para interagir nos equipamentos primários
de mais outro(s) vão(s) ou dados de toda a subestação. Utilizam principalmente a
interface lógica 8;
Interface related station level  Funções de interface do sistema digital com o
operador local (IFinterfaces 1 e 6) ou remoto (IFinterfaces 7 e 10).
38
IF1: Dados de proteção trocados entre o bay e station level;

IF2: Dados de proteção trocados entre o bay level e a unidade de proteção remota;
IF3: Dados trocados entre unidades do bay level;
IF4: Dados analógicos trocados entre o process e bay level;
IF5: Dados de controle trocados entre o process e bay level;
IF6: Dados de controle trocados entre o bay e station level;
IF7: Dados trocados entre subestação e a estação de engenharia remota;
IF8: Dados trocados entre bays, especialmente por funções rápidas como intertravamentos;
IF9: Dados trocados entre station level;
IF10: Dados de controle trocados entre a subestação e centros de controle remotos;
IF11: Dados de controle trocados entre subestações (dados binários como intertravamentos;
ou funções de automação).
Figura 33 – Funções de do sistema de automação e suas interfaces [1-Part 5]
5.2.2 Funções de automação no sistema de potência
Funções de um SAS são tarefas comumente executadas em uma subestação. Devem ser
baseadas em tarefas que visam operar, supervisionar, proteger e monitorar o sistema da
melhor maneira possível. Essas funções incluem também tarefas secundarias que visam
manter a saúde do sistema, como sincronização de tempo, supervisão de mensagens
GOOSE, etc.
“The power utility functions refer to tasks which have to be performed by the utility power
automation system. These are functions to operate, supervise, protect and monitor the
system to keep it running in the best way as possible and to guarantee the reliable and
economic power supply” (IEC 61850-5 p. 17).
“The functions of a substation automation system (SAS) refer to tasks which have to be
performed in the substation. These are functions to control, monitor and protect the
equipment of the substation and its feeders. In addition, there exist functions, which are
needed to maintain the SAS, i.e. for system configuration, communication management or
software management and, very important, for time synchronization” (IEC 61850-5 p. 18).
As funções atualmente mapeadas estão definidas no capítulo 5 da norma IEC 61850, com
descrição, sugestão de uso e categorizadas. Segue abaixo, como exemplo, a função
“XCBR” utilizada para disjuntores (IEC 61850-5 p. 49):
39
Figura 34 – Exemplo de função na norma IEC 61850 [1-Part 5]
Cada agrupamento de funções é representado por uma letra, indicador (IEC 61850-7 p. 18):
Figura 35 – Agrupamento de função [1-Part 7-4]
O intuito da norma não é limitar o uso das funções nem definir suas alocações dentro do
sistema:
“The communication standard must support the operation functions of the substation.
Therefore, the standard has to consider the operational requirements, but the purpose of the
standard is neither to standardize (nor limit in any way) the functions involved in substation
operation nor their allocation within the SAS” (IEC 61850-1 pg. 18).
A ideia é sugerir ao usuário utilizar as funções existentes e caso não encontre aquela que
melhor atenda (ou atenda parcialmente) aos fins desejados, estarão disponíveis as
instruções para criação de novas.
40
Figura 36 – Criação de novas funções [1-Part 7-1]
5.2.3 Livre alocação de funções
A alocação das funções é livre e deve ser realizada conforme a filosofia do projeto, os níveis
lógicos, a disponibilidade e capacidade dos dispositivos, assim como os requerimentos de
desempenho, custos e estado da arte em tecnologia.
“Despite of the similarity of logical and physical levels there is no unique way for mapping the
logical function structure to the physical device structure. The mapping is depending on
availability and performance requirements, cost constraints, the state of the art in technology,
etc. It is influenced also by the operation philosophy and the acceptance of the users i.e. of
the power utilities” (IEC 61850-7-4 p. 161).
Na Figura 37 abaixo temos as funções de proteção de sobrecorrente (PTOC) e distância
(PDIS) gerando uma condição de Trip (PTRC) do disjuntor (XCBR). Note que, no esquema à
esquerda, todas as funções estão concentradas no mesmo IED, mas no esquema à direita
as funções estão distribuídas em mais de um. Note também que, existe a possibilidade de
utilização tanto de redes de comunicação quanto de cabeamento metálico.
41
Figura 37 – Exemplo de funções sobrecorrente e distância [1-Part 7-4]
O próximo exemplo mostra as funções distribuídas de acordo com os níveis lógicos.

Podemos ver a relação entre funções do nível de pátio (Process Level) como
transformadores de tensão (TVTR) e de corrente (TCTR) provendo informações para
atuação das proteções (grupo Pxyz) no nível de vão (Bay Level). As funções de proteção,
por sua vez, terão influência sobre os disjuntores (XCBR) no nível de pátio (Process Level).
Observe-se também a relação entre a função CSWI e a função IHMI para comando remoto
dos disjuntores, sendo influenciada pela função CILO de intertravamento.
Figura 38 – Relação entre funções [1-Part 5]
Em nenhum momento a norma indica em quantos e em quais IEDs as funções devem ser
alocadas. Algumas funções sugeridas pela norma, como no caso da figura abaixo (IEC
61850-5 p. 20), dependem da implementação e demanda para que sejam padronizadas
definitivamente pela norma.
42
Figura 39 – Alocação de funções [1-Part 7-4]
5.2.4 Orientação a objetos
A norma IEC 61850 é baseada no conceito de orientação a objetos, que por sua vez tem
conceitos fundamentais e elementos relacionados:
 Conceitos fundamentais
o Abstração: abstrair um item do mundo real e transformá-lo em uma classe

que o represente;
o Polimorfismo: os mesmos atributos e objetos podem ser utilizados em
objetos distintos, porém, com implementações lógicas diferentes;
o Encapsulamento: separar o programa em partes, o mais isolado possível. O
encapsulamento protege o acesso aos atributos e métodos do objeto,
expondo apenas uma interface para seu uso.
 Elementos
o Classe: tipo de dado que representa o que um objeto pode ter ou fazer;
o Objeto: instância de uma classe;
o Atributos: representam o estado do objeto;
o Métodos: representam os comportamentos e operações que o objeto pode
executar.
43
5.2.5 Classes de modelamento
Baseados nos elementos e conceitos fundamentais da orientação a objetos, a modelagem

do sistema segundo a norma é baseada nos seguintes elementos hierárquicos
apresentados na Figura 40.
Server: nome do IED e nível raiz para o endereçamento.

Logical Device (LD): conjunto de informações consumidas
por grupo de dispositivos.
Logical Node (LN): conjunto de informações (data objects)
consumidas por um único dispositivo ou equipamento do
sistema de automação, como um disjuntor, um
transformador, etc.
Data objects: as ações como abrir/fechar um equipamento;
estado como posição de disjuntores, alarmes, etc.;
descrições, configurações, etc. No geral, são os detalhes
que compõem o SAS.
Obs.: Server e Logical Devices são criados livremente pelo
usuário para que possa agrupar as funções conforme o
SAS.
Figura 40 – Classes de modelamento [1-Part 7-2]
5.2.6 Exemplo de modelamento para Logical Node CSWI
Enquanto o capítulo 5 da norma IEC 61850 lista e descreve os grupos de funções, a parte 7-
4 detalha as funções mandatórias (M), opcionais (O) ou condicionais (C). No caso deste
Logical Node, o data object “Pos” é o único obrigatório e indica em seguida o seu tipo
através de uma classe de dados comum (Common Data Class).
Figura 41 – Classes de dados comuns [1-Part 7-4]
44
Esta classe de objetos é detalhada no capítulo 7-3. No caso deste exemplo, o grupo “DPC”
refere-se a classe de pontos do tipo “Duplos Controláveis”. Nele, encontramos funções para
fins como estados, substituição, configuração, descrição e comando.
Figura 42 – Classe de dados de controle de ponto duplo [1-Part 7-3]
A sequência alfanumérica para a formação do endereçamento será a concatenação de:

SERVER e LOGICAL DEVICE + “/” + LOGICAL NODE + DATA OBJECT + DATA
ATTRIBUTE1 + DATA ATTRIBUTE N
Observações:
 Server e Logical Device são combinados sem espaços (ex: IED001 e CTRL =
IED001CTRL)
 Logical Node deve ser acrescido de prefixo e sufixo (index number) (ex: Q0CSWI1)
Como produto, teríamos:

 IED001CTRL/Q0CSWI1.Pos.stVal, para o valor de supervisão;
 IED001CTRL/Q0CSWI1.Pos.ctlVal, para telecomando;
 IED001CTRL/Q0CSWI1.Pos.q, para indicação da qualidade do ponto;
 IED001CTRL/Q0CSWI1.Pos.t, estampa de tempo do ponto;
45
5.2.7 Exemplo de modelamento para Logical Node MMXU
MMXU é um Logical Node muito utilizado para representar as funções de medição de

corrente, tensão e potência em sistemas trifásicos. Segue o mesmo raciocínio do exemplo
anterior, porém as classes envolvidas possuem mais subclasses linearmente ordenadas.
O Data Object utilizado para expressar a corrente elétrica é “A”, com o Common Data Class
“WYE”, como pode ser visto na Figura 43.
Figura 43 – Modelo para Logical Node MMXU [1-Part 7-4]
A classe WYE tem “Sub data Objects”, ou seja, sub objetos, pois é necessário informar a
corrente de qual fase será representada. Esta subclasse, por sua vez, possui como atributo
a classe CMV, como pode ser visto na Figura 44.
Figura 44 – Classe de dados Medidas [1-Part 7-3]
46
A classe CMV (Complex Measured Value) permite a escolha de valores instantâneos

(instCVal) ou acrescidos de banda morta (cVal), como pode ser visto na Figura 45.
Figura 45 – Classe de dados Valores de Medidas Complexas [1-Part 7-3]
O atributo “cVal” do tipo “Vector” fornece valores absolutos ou angulares, como pode ser
visto na Figura 46.
Figura 46 – Atributo vetor de valores [1-Part 7-3]
E finalmente o atributo tipo “Analogue value” com valores em inteiro ou floating, como pode
ser visto na Figura 47.
Figura 47 – Atributo de tipo de valores [1-Part 7-3]
 IED001MEAS/Q1MMXU1.A.phsB.cVal.mag.f, para corrente fase B

 IED001MEAS/Q1MMXU1.PhV.phsA.cVal.mag.f, para tensão fase A-terra.
 IED001MEAS/Q1MMXU1.W.phsC.cVal.mag.f, para Potência ativa da fase C
47
Entretanto, temos subclasses diferentes para outras medições. No caso da potência total,
sua subclasse common data classe correspondente é “MV” (Measured Value).
 IED001MEAS/Q1MMXU1.TotW.mag.f
E por último, tensão fase-fase com sua subclasse correspondente “DEL” (Phase to phase
related measured values of a three-phase system)
 IED001MEAS/Q1MMXU1.PPV.phsAB.cVal.mag.f
Podemos concluir que os Logical Nodes criados para representar o SAS real reforçam a
ideia de “abstração”, e ao compartilhar suas classes, subclasses e atributos entre os
demais, reforçam também o conceito de “polimorfismo”.
5.2.8 Functional Constraint
Do ponto de vista da aplicação, os data atributes dos data objects são organizados de
acordo com seus usos específicos (ex. pontos digitais, analógicos, comandos, descrições,
etc.). Este tipo de agrupamento é chamado de “Functional Constraint”. A Figura 48
apresenta os valores de Funciontal Constraints definidos na parte 2 da norma IEC 61850.
“From an application point of view, the data attributes are classified according to their specific
use; for example, some attributes are used for controlling purposes, other attributes are used
for reporting and logging, configuration, others indicate measurements or setting groups, or
some identify the description of a specific data attribute.” IEC 61850-7-2 ed2 pg. 53.
Figura 48 – Valores de Funtional Constraint [1-Part 7-2]
48
Este tipo de organização facilita a localização das informações para o Client, tanto para
exibição dos dados de maneira hierárquica quanto para mapeamento de datasets. A Figura
49 mostra a visão dos Functional Constraints em um software de configuração.
Figura 49 – Visão software de configuração
5.2.9 DataSets
DataSets são listas ordenadas de referências a Data Objects e/ou Data Attributes contidos
em um modelo de dados IEC 61850, ordenados de acordo com os requisitos e
conveniências da aplicação. Os elementos do dataset são chamados de “membros”, e a
ordem na qual são indexados é conhecida tanto pelo cliente quanto pelo servidor. Isto vem a
facilitar o reporte de dados do servidor para o cliente, uma vez que apenas os índices e
valores são transmitidos.
“A data-set is an ordered group of ObjectReferences of functional constraint DataObjects,
functional constraint SubDataObjects, functional constraint DataAttributes, and functional
constraint SubDataAttributes, in short of FCDs or FCDAs (see 12.3.3.2), organized as a
single collection for the convenience of the client.” IEC 61850-7-2 Ed2 pg. 61.
Os datasets podem ser do tipo:
 Persistente: visível a todos os clientes e permanece sempre disponível. Pode ser
eliminado pelos clientes;
 Não-Persistente: criado com fins temporários, sendo eliminado assim que o cliente
que o gerou é desconectado.
São gerados pelos seguintes métodos:

 Estático: ferramentas de engenharia do IED, ou seja, estão disponíveis assim que o
servidor está disponível para receber conexões. Clientes não podem apagá-los;
 Dinâmico: gerados sob demanda pelo cliente após a conexão com o servidor. Este
método, se disponível pelo servidor, é extremamente conveniente para a geração de
mensagens espontâneas pois permite ao cliente gerenciar os datasets de maneira
independente à ferramenta de engenharia do IED.
Datasets podem ser criados a partir de qualquer Logical Node, desde que sigam as sintaxes
apresentadas na Figura 50.
Figura 50 – Sintaxe Datasets (IEC 61850-7-2 pg. 63)
49
A Figura 51 abaixo mostra dois datasets persistentes disponíveis em um servidor. Note que,
o primeiro (SIP7SJ85RApplication/LLN0$Data_demo) tem membros que fazem referência a
diferentes caminhos e não somente aos Data Objects contidos dentro do caminho
“SIP7SJ85RApplication/LLN0” (SIP7SJ85RCB1 e SIP7SJ85RDc1). Já o segundo
(SIP7SJ85RApplication/LLN0$DataSet) selecionou como membros somente Data Attributes
como “q” e “stVal”.
Figura 51 – Datasets num Servidor
O significado de cada bit do Data Attribute “q” pode ser encontrada na tabela 33 do capítulo
8 da norma IEC 61850.
5.3 TRANSFERÊNCIA DE MENSAGENS
5.3.1 Tempo de transmissão
Segundo a norma IEC 61850, o “tempo de transferência” inicia-se no momento em que o

transmissor codifica a mensagem contendo os dados da aplicação e termina no momento
em que o receptor decodifica a mensagem. A Figura 52 ilustra esses tempos.
“The complete transfer time t is specified as complete transmission time of a message
including the handling at both ends (sender, receiver). The time counts from the moment the
sender puts the application data content on top of its transmission stack (coding and
sending) up to the moment the receiver extracts the data from its transmission stack
(receiving and decoding).” IEC 61850-5 Ed2 pg. 62.
Figura 52 – Tempos de transmissão [1-Part 5]
50
Na figura acima, são considerados os tempos “ta” e “tc” para empilhar os dados nas filas de
comunicação mais o tempo “tb” referente à transferência da rede, o que inclui tempos de
espera, atrasos e retransmissões (derivadas de possíveis colisões e perdas) de dispositivos
de rede (descrito em IEC 61850-5 – edição 2.0 página 63).
Os deltas de tempo necessários para a execução das funções do SAS podem variar e
requererem diferentes tempos de transmissão. Isto dependerá da análise de desempenho
dos IEDs de acordo com o tamanho e complexidade do sistema. Neste caso, certas
implementações podem não ser adequadas a determinadas aplicações.
5.3.2 Categoria de serviços e Classes de desempenho
Enquanto as classes como Logical Nodes, Logical Devices, Data objects e Data attributes
fornecem as funções para o SAS baseado nas funções reais do sistema, a troca de
informações é definida através de categorias de serviços no capítulo 7-2 para execuções de
tarefas como:
 Obter a autodescrição de um device;
 Troca de informação rápida e confiável entre IEDs (trip ou bloqueio de funções);
 Reporte de qualquer conjunto de informações (data atributes), sequência de eventos
(SOE do Inglês: Sequence of Events) cíclica ou disparada;
 Registrar ou recuperar qualquer conjunto de dados (data atributes) cíclicos ou
eventos;
 Substituição de valores;
 Ajuste ou manuseio de grupos de ajustes;
 Transmissão de valores amostrados (SV) por sensores;
 Sincronizar o tempo;
 Transferir arquivos;
 Operar (controlar) dispositivos;
 Configurar online.
Estas tarefas devem respeitar um determinado tempo de transmissão para não

comprometer o tempo de operação de uma função.
Os tempos de transmissão não devem depender do nível de tensão em questão. As classes
de tempos de transferência (apresentadas na Figura 53) foram então criadas com o intuito
de atender a diferentes requisitos sistêmicos.
Figura 53 – Classes de tempos de transferência [1-Part 5]
51
5.3.3 Transferência de dados entre pares
Existem diversas formas de transferência de dados entre pares, conforme apresentado a

seguir.
 Pooling (GetDataValues)
O pooling é um dos métodos mais simples para transferência de dados verticalmente
(servidor-cliente). O cliente envia ao servidor uma solicitação de leitura de um objeto. Este
método é eficiente para aplicações cujos dados obtidos não necessitam de ação imediata da
operação (ex. leitura de ajustes de proteção), mas ele não é recomendado para envio de
dados para o SCADA devido ao tempo de varredura ser superior ao tempo de
atuação/normalização de eventos (ex. disparos).
Na Figura 54 abaixo temos como exemplo uma requisição para os status ($ST$) do objeto:
“BCP1700CTRL/ACTBCGGIO1.SPCO1”
A resposta enviada pelo servidor contém o valor (false), a sequência de bits referentes aos
qualificadores do ponto e sua estampa de tempo baseada no fuso horário central (UTC do
Inglês: Coordinated Universal Time).
Figura 54 – Exemplo de requisição
 Buffered e Unbuffered Report Control Block

O Report Control Block (RCB) é um serviço de entrega automática de mensagens
disponibilizada pelo servidor. Ele é gerado a partir da alteração de alguma condição de
algum membro do Data set vinculado ao serviço, diminuindo o consumo de banda da rede
(bandwidth) ao evitar repetitivas varreduras do cliente no IED (pooling). A quantidade de
serviços “bufferizados (BRCB)” e “não bufferizados (URCB)” disponíveis em cada IED não
faz parte do escopo da norma IEC 61850, sendo peculiar a implementação de cada
fabricante.
Eles estão agrupados pelos Functional Constraints “BR” (bufferizado) e “RP” (não
bufferizado). No caso de “bufferizado”, os eventos ocorridos durante a desconexão do
cliente são armazenados temporariamente e enfileirados para a posterior entrega,
imediatamente após sua reconexão. O tempo e a quantidade de eventos dependerão
exclusivamente da capacidade do IED.
O cliente pode solicitar ao servidor a ativação de múltiplos RCBs simultâneos. Por exemplo:
um cliente SCADA solicita um BRCB para pontos digitais (para garantir a entrega de
eventos de ocorrências críticas como trips e bloqueios) e um URCB para pontos analógicos
(quando a eventual perda de eventos não é crítica). Considerando-se que RCBs são
exclusivos a cada cliente, será necessário o dobro deles caso o sistema seja redundante.
52
A Figura 55 a seguir traz como exemplo o RCB de nome “A_BRCB01”, seguido do

respectivo caminho em “Path”; em “DatSet” é informada a lista de supervisão. As
condições de disparo das mensagens são definidas pelas opções de “Trg Opt” (trigger
options) e podem ser: a mudança de valores, qualidade e integridade periódica/automática
(“IntgPd”) e/ou solicitada pelo cliente (“GI”). O conteúdo opcional “OptFlds” (optional
fields) pode prover informações adicionais a mensagem como o número da revisão, o nome
do DataSet vinculado, etc. As informações extras facilitam as depurações com as
ferramentas de análise de protocolos.
Figura 55 – Exemplo de Report Control Block - RCB
A designação dos RCB para cada cliente é informada nos arquivos SCL (Substation
Configuration Language). Entretanto, o cliente pode buscar dinamicamente o próximo RCB
fazendo-se a leitura do campo “RptEna” (onde 1 significa “ocupado”) e do campo
“ResvTms” para identificar se, apesar de disponível, é reservado para algum outro cliente.
Uma vez associado a um RCB, o campo “SqNum” indicará quantos telegramas já foram
enviados e se houver alguma mudança (adição/remoção/ordenamento) do DataSet, será
acrescida ao campo “ConfRev”. O campo buffer time (“BufTm”) pode reduzir a quantidade
de envio de mensagens a enviar por agregar múltiplos eventos durante um certo delta
temporal (em ms).
A tabela 4 da parte IEC 61850-7-1 edição 2.0 (apresentada na Figura 56) compara os
métodos mais típicos para referência, mas esclarece que não é possível para um único
método endereçar todos os casos (diferentes requisitos).
Figura 56 – Comparação dos métodos de acesso [1-Part 7-1]
53
 Goose Control Block

Existe um tipo de serviço que não faz uso do perfil de comunicação previsto na ISO 9506
como protocolo de aplicação. As mensagens GOOSE usam poucas camadas do modelo
International Organization for Standardization - Open System Interconnection (ISO-OSI),
como pode ser visto na Figura 57, para que o tempo de transferência da informação possa
atender as funções associadas.
Figura 57 – Camada de comunicação ISO-OSI para mensagens GOOSE [48]
Devido a aplicar a camada TCP/IP, as mensagens GOOSE são transmitidas pelo IED
“Publisher” através de telegramas multicast (camada 2) constantemente na frequência
“Tmax”. Na primeira ocorrência de algum evento gerado por um dos membros de sua lista
(Dataset), a frequência é alterada imediatamente para “Tmin” sendo duplicada a cada envio
consecutivo até alcançar Tmax novamente e assim permanecer até a ocorrência do próximo
evento.
Apesar do telegrama multicast ser recebido por todos os IEDs dentro do mesmo domínio de
broadcast, apenas aquele que tem interesse, o “Subscriber”, processará o telegrama. Ele
manterá a informação como válida para as funções internas desde que o tempo de
recebimento não ultrapasse a marca do “time allowed to live” (tempo máximo de vida,
geralmente configurado como 1,5 x Tmax). A Figura 58 ilustra esse mecanismo.
54
Figura 58 – Mecanismo das mensagens GOOSE [1-Part 8-1]
Na Figura 59 temos um exemplo de mensagem GOOSE. Em vermelho temos os parâmetros

de filtragem; em azul os parâmetros para validação da mensagem; em verde os dados de
interesse.
Figura 59 – Exemplo de mensagem GOOSE
O manuseio e processamento do recebimento da mensagem GOOSE é uma tarefa

exclusiva do subscriber. A primeira filtragem do telegrama multicast é realizada na camada 2
do modelo ISO-OSI, através de faixas de “MAC address” de destino conforme
recomendação do anexo B d parte 8-1 da norma IEC 61850.
55
Figura 60 – Exemplo de endereçamento multicast [1-Part 8-1]
Boas práticas recomendam o isolamento das mensagens GOOSE através da segmentação

da rede conforme a norma IEEE 802.1Q IEEE Standard for Local and Metropolitan Area
Networks — Bridges and Bridged Networks para VLAN (Virtual Bridged Local Area Network):
“VID” (número da VLAN) e “PRIORITY” (para que o switch possa passar o telegrama à
frente dos demais). A Figura 61 apresenta os parâmetros citados.
Figura 61 – Aplicação de VLAN [49]
A próxima entidade a ser filtrada é o application ID (APPID). De acordo com o Anexo C da

parte 8-1 da norma IEC 61850, para mensagens do tipo 1 é recomendado valores entre 1
(0x0001) e 16383 (0x3FFF) e para mensagens do tipo 1A (Trip), valores de 32768 (0x8000)
a 49151 (0xBFFF). O valor 0 deve ser reservado para representar a falta de configuração.
Os parâmetros “GOOSE ID” (GoID), “control block reference” (GoCBRef) e o Dataset
(DatSet), também são empregados para a identificação do telegrama na camada de
aplicação.
O primeiro mecanismo de validação da mensagem GOOSE é a expiração do tempo “time
allowed to live” (timeAllowedtoLive). Em seguida, a aplicação pode conferir se a revisão da
mensagem coincide entre as partes em “config revision” (ConfRev) ou se o publisher não o
configurou corretamente em “needs commisioning” (NdsCom).
Os valores de “sequence number” (SqNum) e “state number” (StNum) são incrementados: a
cada telegrama enviado e a cada mudança de estado de algum membro do Dataset. A faixa
numérica de SqNum é de 1 a 4.294.967.295 e retorna a 0 assim que StNum é
incrementado.
56
 Sampled Values Control Block

As mensagens SV são comumente utilizadas por conversores analógico-digitais como
Merging Units - MUs que operam enviando telegramas multicast sincronizados no tempo
contendo amostras dos valores reais de transformadores de tensão e de corrente. A
frequência de envio dos telegramas estabelece um padrão definido na norma IEC 61850 de
80 amostras por segundo, consumindo entre 5 a 6 Mbit/s cada (MU). A Figura 62 ilustra uma
MU, com um TC e um TP.
Figura 62 – Mensagens Sampled Values
O método de filtragem pelo subscriber é similar ao GOOSE Control Block, iniciando-se pelo
MAC address e application ID. Como o objetivo é a recomposição das medições pela(s)
unidade(s) remota(s), a frequência constante de recebimento é mais importante do que a
validação do telegrama em si.
Figura 63 – Exemplo de mensagem Sampled Values
57
5.4 INFRAESTRUTURA DE COMUNICAÇÃO
Gerenciar o acesso ao meio é o principal desafio para se conectar dispositivos em rede. Os

métodos mais conhecidos basicamente utilizam como princípio de funcionamento:
 Arbitrariedade: o acesso de um dispositivo ao meio é controlado por uma entidade;
 Disponibilidade: a estação verifica se o meio está “livre” antes de iniciar o envio.
Figura 64 – Métodos de gerenciamento numa rede Ethernet
O padrão Ethernet (IEEE 802.3 IEEE Standard for Ethernet) utiliza o protocolo Carrier Sense
Multiple Access with Collision Detection (CSMA/CD) para a gerência de acesso ao meio e
divide os dados em pequenos pacotes para envio através de camadas com funções
específicas, baseadas no modelo ISO-OSI de comunicação. Estas camadas incluem o tipo
de meio físico e conectores, o enquadramento dos dados, transporte, endereçamento e
aplicação. Desde o surgimento em meados da década de 1980, ele acompanhou a evolução
tecnológica e é o padrão comercial mais utilizado desde a década de 1990 até a atualidade.
A norma IEC 61850 precisava confiar em algum padrão sólido e amplamente aceito no
mercado para que os esforços fossem concentrados no aprimoramento dos objetos e
serviços do sistema:
“This standard specifies a set of abstract services and objects which may allow applications
to be written in a manner which is independent from a specific protocol.”
58
5.4.1 Topologias de rede
Topologia é o layout lógico adotado pela rede para o fluxo de dados. Os mais comuns
adotados em ambientes de subestação são barramento, estrela e anel. A escolha
dependerá de fatores como velocidade, custo, confiabilidade e principalmente
disponibilidade em se tratando de sistemas de infraestruturas críticas.
Figura 65 – Topologias de rede
A rede deve ser gerenciada e monitorada para evitar problemas de Broadcast Storm ou
looping de pacotes que são retransmitidos infinitamente até consumir todo o processamento
dos switches e, consequentemente, indisponibilizar todos os recursos da rede.
5.4.2 Protocolos de redundância de rede
A seguir são apresentados os protocolos de redundância de rede no contexto da norma IEC

61850.
 RSTP (Rapid Spanning Tree Protocol)

O RSTP, que é uma evolução do Spanning Tree Protocol (STP), é um dos protocolos de
redundância mais utilizados em sistemas de automação de subestações. Ele opera na
camada 2 do modelo ISO-OSI visando determinar um único caminho mais eficiente (menor
custo) entre cada segmento separado por bridges ou switches.
O ponto inicial para o cálculo dos custos dos segmentos é chamado de “Root”, que na
Figura 66 abaixo é representado pelo ponto A. Partindo-se dele, há somente um único
caminho para se chegar a qualquer um dos nós (pontos em vermelho e verde) do sistema.
Figura 66 – Spanning Tree Protocol
59
Os IEDs trocam telegramas chamados “BPDUs” (Bridge Protocol Data Unit) para a eleição
do “Root” da rede. O dispositivo eleito será o de menor valor de “Bridge Priority” e, em caso
de empate, o menor valor de “MAC address” deve ser considerado. A partir do momento que
o elemento “Root” é eleito, iniciam-se os cálculos para eliminação dos caminhos menos
eficientes, ou seja, os caminhos de maior custo.
Observa-se na Figura 67 que o segmento em vermelho é diferente dos demais por ser um
segmento de 100 Mbit/s, sendo os demais de 1 Gbit/s. Saindo do primeiro elemento “Root”
até o último elemento da rede, temos do lado direito um custo de 40.000 (20.000 + 20.000) e
do lado esquerdo um custo de 220.000 (20.000 + 200.000). Logo, o segmento mais custoso
será interrompido virtualmente para que não haja fluxo de telegramas por este caminho e
consequentemente pacotes não circulem duplicadamente.
Figura 67 – Exemplo de Spanning Tree Protocol
As primeiras versões do STP tinham tempo de recomposição na faixa de 30 a 60 segundos,

evoluindo para valores de 4 a 5 milissegundos com o novo RSTP (IEEE 802.1D). Estes
valores atendem à maior parte dos tempos de transmissão propostos pela norma IEC
61850, exceto aplicações como SV ou trips via GOOSE.
 PRP (Parallel Redundancy Protocol)

O PRP tem diferente abordagem de funcionamento por não se reconfigurar (seamless)
perante falhas, ou seja, não alterar a topologia de rede. O dispositivo Double Attached
Network PRP (DANP) é conectado simultaneamente a duas redes locais (LAN_A e LAN_B),
de arquitetura similar. Ele enviará o mesmo frame Ethernet nas duas redes ao mesmo
tempo; receberá o mesmo frame das duas LANs, consumirá o primeiro frame e descartará o
duplicado.
60
As duas LANs são independentes e não devem ser conectadas em hipótese alguma. Elas
podem inclusive ter topologias distintas (exemplo: estrela e anel RSTP). A Figura 68 ilustra o
funcionamento do PRP.
Figura 68 – Parallel Redundancy Protocol – PRP [50]
É possível que dispositivos Single Attached Network (SAN), sem suporte a PRP como
laptops ou impressoras, sejam ligados somente a uma das LANs. Entretanto, dispositivos
SAN pertencentes a LAN_A não podem se comunicar com dispositivos SAN pertencentes a
LAN_B e vice-versa. Switches também são considerados dispositivos SAN. Esta
compatibilidade existe porque os switches podem ignorar (truncar) os bits de controle do
PRP, chamado Redundancy Check Trailer (RCT), localizado no final do telegrama. A Figura
69 apresenta o frame com os bits de controle do PRP.
Figura 69 – Bits de controle PRP – RCT [50]
É possível conectar dispositivos SAN nas duas LANs através de um dispositivo intermediário
denominado “RedBox”. Esse dispositivo gerenciará as idas e vindas de frames Ethernet e
transformará o SAN em um Virtual DAN - Double Attached Node (VDAN).
O PRP traz uma desvantagem financeira já que tanto os nós da rede como a infraestrutura
de interligação (cabos elétricos ou fibras ópticas) devem ser duplicados.
61
 HSR (High-Availability Seamless Redundancy)

O protocolo HSR utiliza o mesmo princípio da dualidade de LANs e sem reconfiguração de
topologia, porém aplicado a topologias de rede em anel. A Figura 70 apresenta um esquema
HSR.
Figura 70 – High-Availability Seamless Redundancy – HSR [50]
Dispositivos SAN sem compatibilidade com HSR não podem participar do anel de
comunicação sem dispositivos Redbox, pois a etiqueta do HSR é utilizada antes da camada
de aplicação.
Figura 71 – Bits de Controle HSR [50]
A quantidade máxima de dispositivos no anel é extremamente importante. Operando-se a

100Mbit/s, cada nó pode acrescentar 125 microssegundos de atraso na entrega dos pacotes
(por exemplo: 50 elementos resultam em 6 milissegundos de atraso). Outro fator relevante é
a quantidade da banda Ethernet consumida por cada elemento. Considerando-se um anel
de MUs operando em 100 Mbit/s e gerando-se 6 Mbit cada uma, a quantidade máxima
aconselhável de elementos seria 12, considerando-se uma folga de 30% da largura de
banda.
62
Dispositivos do tipo “QuadBox” conectam dois anéis HSR. Eles gerenciam os pacotes de um
anel para outro, evitando a circulação desnecessária de cópias. Geralmente utilizam-se dois
dispositivos do tipo QuadBox adjacentes para evitar que um único ponto de falha torne a
redundância indisponível, como ilustrado na Figura 72.
Figura 72 – Dispositivos QuadBox [50]
A combinação das soluções PRP e HSR é possível com a utilização de RedBox. Para evitar
a re-injeção de pacotes, cada mensagem HSR carrega a informação de Lan ID (A=0, B=1) e
Net ID (1 a 7), formando a etiqueta de 4-bits do PathID. Sendo assim, até 7 redes PRP
podem ser conectadas ao anel HSR. A Figura 73 apresenta um exemplo de uso do PRP
combinado com o HSR.
Figura 73 – Dispositivos RedBox [50]
63
6. REQUISITOS DE DOCUMENTAÇÃO EM SAS
A documentação do Sistema de Automação de Subestações (Substation Automation Sytem

- SAS) é criada por ferramentas de engenharia divididas em gerenciamento, parametrização
e documentação. A norma IEC61850-4 relaciona essas ferramentas conforme Figura 74 a
seguir.
Figura 74 - Escopo das ferramentas de engenharia [1-Part 4]
As informações constantes na documentação gerada pelas ferramentas de engenharia

dependerão da etapa que o projeto se encontrar, que podem ser divididas em:
 Especificação;
 Projeto;
 Construção/Implementação;
 Testes de Aceitação em Fábrica (TAF);
 Testes de Aceitação em Campo (TAC);
 Operação;
 Manutenção.
6.1 DOCUMENTAÇÃO
A parte IEC 61850-6 especifica a linguagem a ser utilizada em subestações para descrever
as configurações do IED e os sistemas de comunicação. Essa linguagem é chamada de
System Configuration description Language (SCL) e tem as seguintes características:
 Utilizar esquema XML (versão 1.0 na edição 1.0 e versão 2.3 na edição 2.0 da parte
IEC 61850-6);
 Possuir mais de um tipo de arquivo;
 Necessitar de ferramentas para criar/editar/extrair dados dos arquivos SCL que vão
depender da etapa e/ou usuário do projeto.
64
O intuito do SCL é que as configurações possam ser exportadas da ferramenta de

configuração dos IEDs para outras ferramentas de configuração do sistema e importadas de
volta para a ferramenta de configuração dos IEDs, mantendo a interoperabilidade entre os
diversos fabricantes.
6.2 LINGUAGEM PARA DESCRIÇÃO DO PAC SYSTEM
Faz parte do SCL um conjunto de arquivos divididos de acordo com suas funcionalidades e
as ferramentas de engenharia são desenvolvidas para ler e/ou editá-los. Como vimos no
capítulo 3 os arquivos são:
 IED Capability Description (ICD): descreve as capacidades de um único IED, ou
seja, aquilo que está disponível nele. É obrigatório que possua o data type template
com as definições dos tipos de nós lógicos do IED;
 Configured IED Description (CID): descreve as partes relacionadas a comunicação
de um IED instanciado em projeto. Esse arquivo contém as informações que o IED
irá disponibilizar na rede;
 System Specification Description (SSD): descreve o sistema incluindo o diagrama
unifilar e as funções relacionadas a cada IED;
 Substation Configuration Description (SCD): descreve a configuração de toda a
subestação. Contém os IEDs com as configurações do fluxo de dados, seção de
subestação e seção de comunicação, ou seja, contém as fontes dos dados e seus
destinos, seja na comunicação entre IEDs ou entre IED e sistema de supervisão e
controle;
 Instantiated IED Description (IID): arquivo incluído a partir da edição 2.0 da norma
IEC 61850. Ele e utilizado para troca de dados de apenas um IED pré-configurado
entre o configurador do IED e o configurador do sistema. Por exemplo, para incluir
um arquivo com instância pré-configurada ou alterações de parâmetros ou modelo
de dados de um IED previamente instanciado. Não substitui todo o IED do projeto
como no caso de utilizar o CID;
 System Exchange Description (SED): arquivo incluído a partir da edição 2.0 da
norma IEC 61850. Ele descreve as interfaces de um projeto que será utilizado em
outro projeto. É um subconjunto de um arquivo SCD utilizado para troca de dados
entre configuradores de sistema diferentes.
As interligações das ferramentas de engenharia prevista em norma para abrir/editar esses

arquivos são mostradas na Figura 75 a seguir.
65
Figura 75 - Fluxo de informações no processo de configuração do PAC System
6.3 PROJETOS
Os projetos da subestação consistem em vários documentos que mantém relação direta

entre si. Como vimos no capítulo 4 alguns documentos necessários são:
 Diagramas unifilares de proteção e controle;
 Arquitetura de redes com a lista de IPs, MAC addresses, portas, VLANs,
equipamentos e tipos de mensagens trafegadas (GOOSE, MMS, SV, SNTP, etc.);
 Lista de pontos “de - para” elétrico e por mensagens de rede;
 Lógicas: documentos e arquivos de configuração dos IEDs;
 Sistema SCADA: Base de dados para supervisão e controle, utilizando os dados dos
IEDs, telas de IHM, lista de pontos com descritivo operacional.
As informações contidas nesses documentos devem ser recebidas ou transmitidas por

arquivos SCL pelas ferramentas de engenharia. São necessárias ferramentas que
interpretem os arquivos SCL para cada etapa do projeto.
Por exemplo, na fase de desenvolvimento, o projetista deve ser capaz de utilizar o ICD para
gerar a lista de interconexões (elétricas e/ou lógicas para configurar o IED, gerando os
arquivos CID e IID).
Na fase de Teste de Aceitação em Fábrica o diagrama funcional e o arquivo SCD estarão
consistidos por ferramentas próprias e, caso necessário, as alterações serão realizadas de
forma que, alterando o SCD, o diagrama funcional e os IEDs sejam atualizados e/ou
consistidos.
66
6.4 PROJETO FUNCIONAL
O projeto funcional reflete as conexões existentes na instalação e por isso as subestações

tradicionais utilizam desenhos com as conexões elétricas dos equipamentos. A
nomenclatura padrão das instalações tradicionais é baseada na norma ANSI. A Figura 76
apresenta um exemplo da representação funcional de proteção e controle.
Figura 76 – Representação de projeto por conexões elétricas e nomenclatura ANSI
Para uma subestação aderente à norma IEC 61850 esse mesmo projeto teria as
nomenclaturas alteradas, por exemplo, 52 para XCBR, 89 para XSWI, 21 para PDIS ou a
utilização das duas nomenclaturas.
O projeto funcional que contempla as entradas e saídas dos IEDs em instalações
convencionais que são exclusivamente físicos e por isso suas representações seguem o
padrão mostrado na Figura 77 a seguir.
67
Figura 77 - Representação de projeto por conexões elétricas e nomenclatura ANSI
Em um projeto IEC6 1850 essa representação passa a não ser a melhor para as conexões
por mensagens de rede. Por exemplo, o ponto físico representando a chave 789P1,
apresentada no desenho como o contado normalmente fechado conectado nos pontos 30 e
31 da régua de borne X1, passaria a ser uma conexão realizada por mensagem de rede,
representado, por exemplo:
IED_LT$CFG$LLN0$GPub01$PRO$X89AXSWI5$Pos$stVal.
A criação de variáveis com nome simplificado, como realizado no projeto lógico, pode ser
uma solução para a visualização das variáveis de comunicação dentro do projeto funcional.
Nesse caso seria necessário um dicionário para correlacionar as nomenclaturas.
A Figura 78 ilustra um exemplo simples e hipotético de documentação contendo o nome do
IED (IED name), endereço IP, MAC address da porta física, número de portas e o tipo de
conector. Para o switch é apresentado o tag do equipamento, a porta de conexão do
respectivo IED e as VLAN’s a serem atribuídas para permitir a segregação das mensagens
GOOSE.
68
Figura 78 - Lista de IEDs e Switch
A Figura 79 apresenta um exemplo de documentação para os parâmetros presentes no

report GOOSE. Os campos de MAC address e APPID devem ser configurados dentro de
uma faixa definida na norma IEC 61850 e os demais campos precisam ser documentados
no projeto para facilitar a solução de eventuais problemas (troubleshooting).
Figura 79 - Lista de parâmetros das mensagens GOOSE
Por fim, a lista de IEDs da Figura 80 exibe outro exemplo de documentação contendo a lista
de dispositivos que publicam e assinam as mensagens GOOSE na rede de comunicação
das subestações.
Figura 80 - Lista de publicador e assinante
69
6.5 AUTOMATIZAÇÃO DA DOCUMENTAÇÃO
Durante as etapas do projeto, como TAF, podem ser encontradas inconsistências que
geram alterações no projeto emitido. Como vários documentos do projeto são inter-
relacionados, essas alterações são realizadas em mais de uma ferramenta de engenharia,
necessitando de alterações manuais que podem inserir erro de execução.
Para minimizar as falhas e atrasos causados pela alteração manual em documentos do SAS
deve-se utilizar software que permitam a automatização da documentação.
Um processo automatizado eficiente exige que haja garantia de consistência das
informações contidas em todos os sistemas envolvidos no projeto. Para isso é necessário
que:
a) A documentação necessária para o SAS seja bem conhecida;
b) Os itens necessários para consistir diferentes projetos sejam definidos claramente.
Dúvidas sobre quais informações serão enviadas de uma ferramenta para outra não
podem existir;
c) Sejam bem definidas as regras e critérios para trocas de informações entre
ferramentas de engenharia. Exemplos de informações que exigem conhecimento
prévio são: o número máximo de caracteres para nomear ou povoar uma variável, se
são permitidas variáveis iniciadas com número e quais caracteres especiais são
permitidos utilizar;
d) A permissão de quem pode editar, criar ou visualizar cada projeto sejam bem
definidas;
e) Projetos não fiquem com situação “em revisão” por muito tempo. Através de um fluxo
automático os responsáveis devem receber avisos das necessidades de interação
com o sistema e os prazos estabelecidos para o término das tarefas.
O projeto automatizado diminui o tempo de planejamento, execução e validação do mesmo,

e aumenta a confiabilidade dos documentos ao final do processo.
6.6 EXPERIÊNCIA NO BRASIL NA DOCUMENTAÇÃO DE SOLUÇÕES IEC 61850
Apesar das soluções IEC 61850 estarem estabelecidas no Brasil como padrão na maioria
das empresas de energia elétrica, a documentação ainda não se adaptou aos novos
requisitos e recursos da norma. Ainda é comum representar as funcionalidades com
desenhos elaborados manualmente, sem explorar as facilidades da norma o que torna
menos eficiente o processo de implantação e de atualização de documentos.
A mudança não passa apenas por utilizar ferramentas de software e documentar de maneira
mais adequada, mas alterar processos, organização interna e perfil profissional. Significa
compreender o impacto da aplicação da norma IEC 61850 no processo de implantação do
sistema de proteção, automação e controle incluindo a casa de controle e os equipamentos
primários no pátio da subestação.
A consequência em muitas empresas é que a aplicação destes sistemas tornou mais
complexa o acesso e a compreensão das equipes de projeto, manutenção e operação para
avaliar o desempenho, realizar intervenções e planejar ampliações no sistema. Se não se
utilizar as vantagens tecnológicas da solução, perde-se o motivo de sua aplicação.
Naturalmente, no início (primeiros projetos) o esforço será maior e as vantagens virão com a
experiência e serão mais evidentes no ciclo de vida do SAS.
Esta mudança ainda está em andamento nas empresas no Brasil. Avançou-se em alguns
aspectos com uma melhor documentação de mensagens GOOSE, VLANs, lista de sinais.
70
Entretanto, seria importante poder gerar a documentação e mantê-la atualizada a partir do

arquivo SCD da subestação. Assim como as lógicas de proteção e controle contidas em
cada relé poder gerar automaticamente a documentação.
O esforço das empresas para melhoria da documentação está nas seguintes iniciativas:
 Qualificação das equipes com as novas tecnologias de redes de comunicação,
orientação a objeto e, claro, da norma IEC 61850;
 Melhoria nas especificações técnicas incluindo a geração do arquivo SSD, descrição
detalhada das funções, arquitetura, requisitos e documentação;
 Investimento em softwares comerciais e próprios para gestão dos sistemas
envolvidos na configuração de equipamentos de proteção, automação e controle e
da infraestrutura de comunicação;
 Padronização de soluções para facilidade de gestão do ciclo de vida e futuras
ampliações, facilitando a documentação e domínio das aplicações.
71
7. APLICAÇÕES DA NORMA IEC 61850 EM

ESQUEMAS DE PROTEÇÃO
7.1 INTRODUÇÃO
Os esquemas de proteção do sistema elétrico de potência baseados em relés

eletromecânicos foram desenvolvidos no século XIX, inicialmente com a utilização de
funções de sobrecorrente. Durante o início do século XX foram desenvolvidos os princípios
das funções de proteção que utilizamos hoje em dia como sobrecorrente, direcional,
distância e diferencial.
Com o avanço tecnológico, tanto na área de materiais quanto no desenvolvimento das
tecnologias eletrônica e computacional, houve uma grande transformação nos relés de
proteção, migrando do eletromecânico para o estático e posteriormente para a utilização de
circuitos integrados e microprocessados. Hoje em dia os relés digitais dominam
completamente o mercado e as atuais aplicações dos esquemas de proteção.
A incorporação de equipamentos de comunicação no PAC System, bem como a massiva
aplicação dos relés digitais, agora chamados de IEDs, foi ambiente propício para o
nascimento e consolidação das aplicações baseadas em IEC 61850. Essas aplicações
agora permitem diferentes formas de alocação de funções de proteção, facilidade na troca
de informações entre essas funções e abrem um campo vasto para o desenvolvimento de
novas técnicas de proteção. Houve também uma evolução da teleproteção, migrando de
sistemas de Ondas Portadoras em Linhas de Alta Tensão - OPLAT para redes de
telecomunicações de alto desempenho.
Esta transformação também trouxe impactos bastante positivos na supervisão dos sistemas
de proteção, tanto na parte de oscilografia, com a utilização de dispositivo dedicado a esse
fim, o Registrador Digital de Perturbação - RDP, como na parte de aquisição dos dados no
sistema SCADA. A aplicação da norma IEC 61850 permitiu, principalmente para esse
primeiro, um aumento significativo no grau de supervisão.
7.2 REQUISITOS DOS ESQUEMAS DE PROTEÇÃO
O sistema elétrico de potência precisa, dada a sua natureza, manter elevadíssimos padrões
de continuidade de serviço, bem como ter a sua indisponibilidade minimizada quando
condições inadmissíveis de operação ocorrem. Essas condições são geradas por fatores
como eventos naturais, acidentes, falhas em equipamentos, erros humanos e na prática são
impossíveis de serem evitadas por completo. O PAC System, em especial o esquemas de
proteção, carregam uma grande parcela de responsabilidade na manutenção desses
padrões de continuidade do sistema elétrico de potência, ao identificar e tomar as ações
necessárias, com o menor impacto sistêmico possível, durante as condições inadmissíveis
de operação.
Dada a importância do esquema de proteção para o sistema elétrico de potência, esse
necessita ser projetado considerando os seguintes aspectos:
 Confiabilidade – atuação de forma correta sempre que solicitada e não atuação

acidental quando não solicitada;
 Seletividade – desconexão da menor porção do sistema de potência para a
eliminação do distúrbio;
72
 Velocidade de operação – minimização do tempo de exposição do sistema de

potência ao distúrbio;
 Simplicidade – minimização do número de equipamentos e circuitos para
atendimentos dos requisitos da proteção;
 Econômico – máximo desempenho da proteção com o menor custo.
Ao se avaliar o emprego de novas tecnologias, métodos, filosofias etc. é essencial que seja
verificado se esses aspectos são atendidos em patamares aceitáveis pelos critérios da
empresa de energia, bem como pelos órgãos de regulação e controle do sistema elétrico de
potência. Além disso, deve-se determinar se existe ganho ou prejuízo em cada um desses
aspectos com relação à situação anterior, avaliando então se a mudança é positiva ao não.
7.3 ESQUEMAS DE PROTEÇÃO ADOTANDO A IEC 61850
O benefício mais evidente da aplicação da IEC 61850 para as funções de proteção é a

substituição do modo como essas informações são trocadas, passando da tradicional fiação
para a aplicação via comunicação, utilizando as mensagens GOOSE e Sampled Values.
Outro possível benefício é a livre alocação das funções (logical nodes), permitindo maior
flexibilidade, principalmente, no que diz respeito construção de soluções para a redundância
dos esquemas de proteção.
Nesta seção serão apresentados exemplos de funções de proteção, que são atualmente
aplicadas nos esquemas tradicionais de proteção, e como essas podem ser implementadas
utilizando a IEC 61850. O objetivo não é detalhar todas as funções de proteção, nem
explorar todas as possibilidades de aplicações dessas funções, mas sim fornecer uma visão
de como essas aplicações pode ser realizadas. Outras aplicações podem ser derivadas a
partir dos exemplos apresentados.
Diferentes formas de abordagem serão apresentadas. Algumas funções serão descritas de
maneira mais detalhada e outras com menos detalhes. Em alguns casos serão
apresentados detalhes das lógicas, de configuração das mensagens GOOSE e da própria
aplicação.
7.3.1 Funções de Proteção para Barramentos
Normalmente para a proteção de barramentos são aplicadas funções diferenciais,

esquemas de comparação direcional ou esquemas de bloqueio. Em todos os casos é
necessário o monitoramento dos módulos conectados ao barramento, sendo esse
monitoramento realizado pela corrente ou atuação de alguma outra função de proteção, e,
em muito dos casos, dependendo do arranjo, para se permitir flexibilidade de operação e a
possibilidade de uma proteção mais seletiva, também é necessária a informação do estado
das chaves seccionadoras e disjuntores.
Os esquemas de comparação direcional e de bloqueio encontram utilização principalmente
em sistema de distribuição, sendo que este último para sistemas radiais. Não é possível a
aplicação desses esquemas na Rede Básica, devido aos critérios estabelecidos nos
Procedimentos de Rede do ONS (Revisão 2016.12), que obriga a utilização de proteção
com princípio diferencial para barramentos. Além disso, em função da necessidade da
inclusão de temporização nesses esquemas, esses não são adequados para a utilização em
sistemas de transmissão.
73
7.3.1.1 Esquema de Bloqueio
O esquema de bloqueio, conforme mencionado anteriormente, pode ser utilizado para

sistemas radiais, ou seja, onde existe um alimentador conectado ao sistema (fonte) e os
demais conectados às cargas. A Figura 81 mostra um arranjo típico, bem como a troca de
informação entre as proteções dos alimentadores para a realização do esquema de
bloqueio.
IED 1
F1
IED 2 IED 3 IED 4

F2
Figura 81 – Troca de informações em um esquema de bloqueio
Funções de sobrecorrente (PTOC) de fase e de neutro normalmente já são utilizadas nas

proteções dos alimentadores. O esquema de bloqueio pode se utilizar da partida dessas
funções de proteção para a composição do esquema, sendo que o objetivo é permitir um
disparo rápido do alimentador fonte para um defeito em F1 enquanto permanece estável
para um defeito para faltas em algum outro alimentador (F2). A falta em F2 deve ser
eliminada somente pela aberturado do disjuntor associado ao IED2.
Para ser atingido o objetivo do esquema é necessário aplicar uma lógica no IED1, para
processar as mensagens GOOSE (PTOC.Str) vinda dos outros alimentadores juntamente
com o estado própria unidade de sobrecorrente. Adicionalmente, porém, não é necessário
para a eliminação do defeito, é possível que o sinal de disparo seja retransmitido para os
demais IEDs para que esses comandem a abertura dos respectivos disjuntores. A Figura 82
apresenta essas lógicas.
74
IED Alimentador (fonte)
IED1 Partida
Temp.
GOOSE IN – IED2 Partida
E SAÍDA DIGITAL – Disparo
GOOSE IN – IED3 Partida OU
GOOSE IN – IED4 Partida GOOSE OUT – Disparo
IEDs Alimentadores (carga)
GOOSE IN – Disparo SAÍDA DIGITAL – Disparo
Figura 82 – Lógica dos IEDs para o esquema de bloqueio
Em caso de ausência de alguma mensagem GOOSE o esquema pode não operar de

maneira satisfatória. A presença da mensagem GOOSE pode ser monitorada e considerada
na lógica para contornar esse problema. Dependendo da criticidade da aplicação se pode
optar pelo bloqueio do esquema, com emissão de alarme para indicar à operação a
indisponibilidade e essa solicitar manutenção, ou pela atuação preventiva do esquema,
habilitando, por exemplo, uma unidade de sobrecorrente instantânea (PIOC) no IED1.
As Figuras 83, 84 e 85, mostram um exemplo de arquivo SCD para a aplicação descrita
acima onde constam as configurações do GOOSE Control Block e a lista de informações do
dataset do IED1 e a associação na recepção dessas informações no IED2, respectivamente.
Figura 83 – Configurações do GOOSE Control Block do IED1
Figura 84 – Dataset do IED1
Figura 85 – Recepção da informação no IED2
75
7.3.1.2 Esquema de Comparação Direcional
O esquema de comparação direcional para proteção de barramentos pode ser realizado

pela interconexão de funções direcionais de sobrecorrente ou de distância, implementadas
para este fim específico ou se aproveitando das funções já aplicadas nos módulos. É um
esquema que encontra utilização principalmente em sistemas de distribuição.
A Figura 86 mostra a troca de informação entre IEDs do esquema de comparação
direcional. O IED de proteção do barramento é aquele que executará as lógicas associadas
ao esquema de comparação direcional e enviará aos demais IEDs os sinais de disparo.
Estes últimos devem fornecer os sinais de detecção de falta e direcionalidade direta, bem
como receber e processar o sinal de disparo vindo do IED de proteção de barramento.
Reversa
IED 1 IED 2
Direta
IED
Proteção
Barramento
F1
IED 3 IED 4 IED 5

F2
Figura 86 – Troca de informações em um esquema de comparação direcional
A Figura 87 mostra as lógicas que devem ser implementadas no IED de proteção do

barramento e nos IEDs dos módulos para compor o esquema de comparação direcional.
IED Proteção Barramento

GOOSE IN – IED3 Partida OU
Temp.
E GOOSE OUT – Disparo
GOOSE IN – IED1 Direta
GOOSE IN – IED3 Direta OU
IEDs Módulos
GOOSE IN – Disparo SAÍDA DIGITAL – Disparo
Figura 87 – Lógica para o esquema de comparação direcional
76
A lógica se baseia no fato de quando existe uma falta interna ao barramento, as correntes
fluem em direção à barra. Porém, quando ocorre uma falta externa o fluxo vai em direção a
barra em todos os circuitos, exceto onde ocorre a falta.
Os sinais de partida e de direcionalidade direta dos IEDs dos módulos podem ser obtidos de
um mesmo Logical Node, por exemplo, PDIS ou PTOC, utilizando o Data Object adequado
para cada sinal ou, dependendo da necessidade da aplicação, podem ser utilizados dois
Logical Nodes distintos. A temporização apresentada é fundamental para se manter a
coordenação e seletividade desse esquema e deve ser ajustada considerando o
desempenho do sistema bem como uma margem de segurança.
O exemplo de aplicação mostrada acima pode ser adaptado para outros arranjos de
barramento, inclusive naqueles que possuem mais de um barramento e módulo de
transferência, mantendo seletividade no disparo.
A ausência de alguma mensagem GOOSE pode levar o esquema de comparação direcional
a não operar de maneira satisfatória. As possibilidades de solução são as mesmas
apontadas para o esquema de bloqueio, com exceção que no caso de se optar pela
habilitação de alguma unidade instantânea, seja uma distância ou sobrecorrente com
direcionalidade reversa, essa habilitação deve ser realizada nos IEDs de todos os módulos.
7.3.1.3 Função Diferencial
A função diferencial de barramento é baseada na comparação entre as correntes de todos

os módulos conectados àquele barramento. Existem dois tipos de soluções para essa
função de proteção, a que adota IEDs de forma concentra ou distribuída. Para a solução
concentrada, normalmente é utilizado um único IED para realizar toda a função, onde as
correntes e estados das chaves seccionadoras e disjuntores são conectados diretamente a
esse IED. Em determinadas situações, por limitações de hardware, são utilizados três IEDs
também na solução concentrada, porém, o princípio permanece o mesmo. Já para a solução
distribuída é aplicado um IED como Unidade Central - UC e os IEDs, um para cada módulo,
como Unidade Periférica - UP. A Unidade Periférica também é denominada de Unidade de
Bay. Nessa solução temos então as informações de corrente e estado dos equipamentos,
conectadas à UP e repassadas à UC para o processamento e definição das ações, estas
repassadas à UP para execução de fato das ações.
A aplicação da norma IEC 61850 na função diferencial para barramento pode ser feita tanto
no nível de pátio (Process Level) e de casa de controle (Station Level) ou somente no
Station Level. Neste último caso a troca de informação fica restrita ao estado dos
equipamentos, que seriam informados ao IED que executa a função diferencial pelos demais
IEDs de proteção e controle da subestação. Trataremos com mais detalhes a aplicação
utilizando os dois níveis.
A Figura 88 mostra uma configuração bastante simples de uma aplicação da função
diferencial de barramento utilizando o Process Level. É importante destacar que essa
aplicação não conta com um nível de confiabilidade, dado a ausência de redundância,
exigida para uma aplicação na Rede Básica. Também nessa Figura não é detalhado o
módulo de conexão, em especial as chaves seccionadoras. O objetivo é demonstrar a
aplicação em si.
77
IED SW
Proteção Barramento
Barramento de Processo
Merging Merging Merging

Unit 1 Unit 2 Unit 3
Figura 88 – Aplicação do Process Level na função diferencial de barramento
As Merging Units (MUs), que são as UPs nesse caso, recebem a informação do estado dos
componentes, normalmente chaves seccionadoras, utilizada para determinar o arranjo atual
dos barramentos, ou seja, quais módulos estão conectados em cada barramento ou
segmento de barramento. Elas também fazem a medição de corrente do respectivo módulo,
que será convertida em Sampled Values. Além disso, as Merging Units recebem os
eventuais comandos de disparo da função diferencial de barramento para proceder com a
abertura do respectivo disjuntor. Todo esse tráfego de informação ocorre no Process Level.
Todos os requisitos de comunicação, rede e sincronismo de tempo, apresentados no
Capítulo 4 devem ser observados, sob pena de mau funcionamento da função diferencial.
A Unidade Central executa todos os algoritmos de proteção (diferencial, zona de supervisão,
TC aberto, detecção de falta externa, detecção de saturação etc.) e toma a decisão pelo
disparo e gera a mensagem GOOSE de intertrip para as Unidades Periféricas, que no caso
são as próprias Merging Units que comandarão a abertura dos respectivos disjuntores.
7.3.2 Falha de Disjuntor
A função falha de disjuntor (breaker failure – BF) fornece retaguarda local aos sistemas de
proteção no caso em que um disjuntor seja chamado a operar, ou seja, receba um sinal de
disparo de alguma função de proteção, e por algum motivo não consiga executar a abertura
dos seus polos. A atuação da função falha de disjuntor normalmente promove inicialmente
um redisparo no disjuntor monitorado (Retrip) e posteriormente, caso as condições se
mantenham, o comando de disparo em todos os disjuntores adjacentes a esse, inclusive
com a transmissão de transferência de disparo para o terminal remoto em caso de linhas de
transmissão.
A função de falha de disjuntor (RBRF) pode ser alocada nos IEDs da proteção dos
componentes, no IED da proteção de barramento, em IED exclusivo para este fim ou na
própria Merging Unit. A escolha do local onde será alocada essa função deve levar em conta
também como os sinais de disparo serão enviados aos disjuntores adjacentes, bem como o
processo de evolução da subestação. Como nessa função existe uma interação entre vários
módulos, algumas soluções podem levar à necessidade de reconfiguração e
recomissionamento quando da alteração da subestação, notadamente nos casos de
inclusão de novos módulos.
78
Serão apresentadas as soluções onde a função falha de disjuntor é executada em IED

exclusivo e utiliza a proteção de barramento para executar o disparo nos IEDs adjacentes e
a solução onde a atuação ocorre diretamente sob os IEDs dos outros módulos.
7.3.2.1 Falha de Disjuntor via Proteção de Barramento
É comum nas aplicações clássicas dos sistemas de proteção a utilização da proteção de

barramento, que já monitora conexão dos módulos no barramento, para o direcionamento
do disparo da função de falha de disjuntor.
A Figura 89 mostra como seria a modelagem feita diretamente em IEC 61850 dessa
solução. Foram realçados os sinais ativos no caso da atuação de falha de disjuntor do
M1Q1.
S1PDIF1
.Op
S1PTRC1
.Tr
.Op .Op .Op
.OpEx
.Tr .Tr .Tr
M1PTRC1 F1Q1RBRF1 M2PTRC1 F2Q1RBRF1 M3PTRC1 F3Q1RBRF1
.OpIn .OpIn .OpIn
M1Q1PTRC1 M2Q1PTRC1 M3Q1PTRC1
Figura 89 – Modelagem IEC 61850 falha de disjuntor via proteção de barramento
No caso de ser necessário um novo módulo na subestação, somente o IED de barramento,

onde está alocado o Logical Node associado ao disparo (S1PTRC1), necessitará ser
reconfigurado para subscrever a nova mensagem GOOSE (F4Q1RBRF1.OpEx).
Naturalmente já haveria uma intervenção no IED de barramento de qualquer maneira uma
vez que se trata da inclusão de um novo módulo na subestação e normalmente são
realizados testes de comissionamento nessa situação.
Entretanto, é possível evitar a necessidade da intervenção no IED do barramento para a
inclusão da subscrição das mensagens GOOSE, ao se prever na etapa de implementação
da subestação todos os possíveis módulos futuros. Isso é interessante tanto pela questão
da intervenção, mas também para se manter uma padronização na aplicação, uma vez que
diferentes integradores, com diferentes soluções, podem trabalhar nas ampliações no
decorrer do tempo.
Nesse caso se faz necessário incluir formas de ligar e desligar o módulo na aplicação, para
que essa reflita a atual situação da subestação. Isso pode ser útil também durante
intervenções da manutenção onde se faz necessário retirar um módulo de operação.
79
7.3.2.2 Falha de Disjuntor via Proteções dos Módulos
O método descrito anteriormente é bastante aplicado nas soluções tradicionais (cabladas),

uma vez que evita a necessidade de várias ligações entre painéis dos módulos da
subestação, aproveitando o caminho de disparo da proteção de barramento. Tanto
considerando a solução tradicional quanto a aplicação com IEC 61850 o esquema de falha
de disjuntor fica dependente do IED da proteção do barramento.
Entretanto, dado que a Local Area Network - LAN utilizada na IEC 61850 interliga todos os
IEDs da subestação é possível eliminar o ponto de falha comum da função de falha de
disjuntor, que seria o IED da proteção de barramento.
Para se migrar da solução apresentada anteriormente para uma que não envolva a
distribuição dos disparos pelo IED da proteção de barramento basta que os IEDs de
proteção ou Merging Units de cada módulo subscrevam as mensagens GOOSE de atuação
de falha de disjuntor de todos os outros módulos.
A Figura 90 mostra essa forma de aplicação.
.Op .Op .Op
.OpEx .OpEx .OpEx

.Tr .Tr .Tr
M1PTRC1 F1Q1RBRF1 M2PTRC1 F2Q1RBRF1 M3PTRC1 F3Q1RBRF1
.OpIn .OpIn .OpIn
M1Q1XCBR1 M2Q1XCBR1 M2Q1XCBR1
Figura 90 – Modelagem IEC 61850 – falha de disjuntor via IEDs
Fazendo a mesma consideração sobre a adição de um novo módulo, neste caso todos os
IEDs devem ser reconfigurados e testados. Também nesse caso aqui é possível contornar o
problema pré-configurando os IEDs com todos os possíveis módulos futuros da subestação.
7.3.3 SEP – Sistema Especial de Proteção
Os Sistemas Especiais de Proteção – SEP são aplicados com o objetivo de evitar violações,
acima dos limites de suportabilidade de curta duração dos equipamentos, ou instabilidades
no sistema. Suas ações são planejadas previamente e implementadas de forma que as
contingências previstas não provoquem um aumento na área de abrangência da
perturbação.
Existem ainda no Sistema Interligado Nacional os Esquemas de Controle de Emergência –
ECE, que são esquemas especiais que visam automatizar as ações dos operadores. Estes
esquemas podem ter ações semelhantes as dos SEP, porém os objetivos e níveis de
ajustes são diferentes. Enquanto o SEP tem ação de proteção, o ECE tem ação de controle.
80
No Brasil, dentro da Rede de Operação, o ONS é o responsável por identificar essas

contingências, bem como de propor lógicas e ajustes que os SEPs e ECEs devem possuir.
Além disso, o agente ou proprietário do sistema, dentro ou fora da Rede de Operação, pode
identificar outras necessidades e também adotar esquemas especiais de proteção, fora das
funções tradicionais, para melhorar o desempenho do seu sistema de proteção/controle.
Como a identificação da necessidade dos SEPs, e ECEs principalmente aquelas em função
de alterações no sistema de potência, ocorre muitas vezes em etapa posterior as de projeto
e comissionamento, ou seja, durante a operação, a implementação desses muitas vezes
traz os mesmos desafios de uma ampliação. Porém, ao se utilizar a IEC 61850 essa
implementação, notadamente nas situações em que os requisitos do SEP e ECE permitem o
compartilhamento de infraestrutura entre esse e os sistemas de proteções já existentes,
pode ser bastante facilitada, com grande redução de tempo e custos.
A Figura 91 mostra um diagrama lógico de um exemplo de aplicação de um SEP para
desinserção automática de um reator de barramento, em arranjo de disjuntor e meio, onde
as medições de tensão são realizadas através dos TPs dos barramentos.
Figura 91 – Exemplo de diagrama lógico de SEP
No exemplo as informações de tensão e o estado do grupo central do vão onde está

conectado o reator, necessárias para a lógica do SEP, já estavam disponíveis nos IEDs de
controle (5R2CP1 e 5R2CD1). Essas informações foram repassadas via GOOSE aos IEDs
de proteção (5R2PP1 e 5R2PA1), onde o restante da lógica foi executado. Desta forma não
houve a necessidade de inclusão e/ou alteração em fiação.
É importante fazer uma avaliação de como o SEP deve se comportar na eventualidade de
uma falha das mensagens GOOSE, portanto, e dependendo do resultado dessa avaliação
devem ser previstas nas lógicas soluções para melhor atender à aplicação. Essa informação
de falha da mensagem GOOSE deve ser monitorada no sistema supervisório, para
acionamento e correção por parte da manutenção.
81
7.4 TELEPROTEÇÃO
Esta seção descreve os principais aspectos relacionados aos princípios de operação de um

sistema típico de teleproteção. Apresenta algumas características da evolução dos sistemas
de comunicação, desde os sistemas de Ondas Portadoras OPLAT, em que o meio de
comunicação é a própria linha de transmissão, passando pelos sistemas de comunicação ou
redes de chaveamento de circuitos SDH/SONET, até a chegada das tecnologias baseadas
em MPLS-TP. Explica também seus principais mecanismos de configuração, considerando
a utilização de Nós Lógicos conforme a Norma IEC 61850, específicos para a comunicação
entre terminais remotos e finalmente, apresenta duas formas bastante empregada para
realizar o sincronismo de tempo destes sistemas.
7.4.1 Princípios de Operação
O princípio de operação de um sistema de teleproteção baseia-se, por um lado, na

comunicação com um terminal de proteção dentro da mesma subestação e, por outro lado,
na comunicação com seu terminal correspondente, ou seja, o terminal do outro lado do link,
para poder transmitir um sinal de comando.
A teleproteção é um método de proteção de linha, através de IEDs de proteção e meios de
comunicação, no qual um defeito interno é detectado e determinado comparando-se as
condições do sistema nos terminais do circuito protegido, utilizando-se canal ou canais de
comunicação.
A comunicação com os terminais de proteção pode ser analógica ou digital e de acordo com
a norma IEC 61850. Um terminal de teleproteção, que recebe um comando do terminal na
outra extremidade do link, deve ativar o relé de saída de comando correspondente (ou relés)
e/ou a mensagem GOOSE (ou mensagens) para o terminal de proteção (ou terminais).
Dentre os meios de comunicação para esquemas de teleproteção, no Brasil, a utilização de
Ondas Portadoras sobre linhas de alta tensão como meio físico de propagação do sinal, que
interliga subestações e usinas para a transmissão de dados, voz e sinais de teleproteção, é
ainda o meio de comunicação mais utilizado em vista do seu baixo custo de investimento.
Figura 92 - Aplicação de equipamentos OPLAT em linhas de transmissão para envio de

dados, voz e sinais de Teleproteção entre três subestações.
82
Um sistema de teleproteção pode ser configurado para funcionar sobre canais analógicos
tipicamente sendo capaz de transmitir e receber até quatro comandos combinados (tom
único) ou independente (dual tone) de teleproteção, ou até trinta e dois comandos
codificados (duplo tom).
Um sistema de teleproteção configurado para funcionar em canais digitais tipicamente
permite a transmissão bidirecional de até oito comandos de teleproteção usando linhas
digitais com interface elétrica ou óptica. A interface elétrica pode ser de 2 Mbit/s ou 64 kbit/s
de acordo com a Recomendação G.703 do ITU-T, bem como 64 kbit/s, 56 kbit/s ou 32 kbit/s
de acordo com as recomendações V.11 / X.21 e V.35 do ITU-T. A interface óptica dos
terminais de teleproteção em geral funciona a uma velocidade de 64 kbit/s ou de acordo
com o padrão C37.94 (2 Mbit/s frame).
Os sistemas de teleproteção devem atender às normas IEC 60834-1 e IEC 6100-6-5 e às
normas ANSI C37.90.1 e ANSI C37.90.2.
A Norma IEC 60834-1 define os seguintes parâmetros básicos de desempenho:
 Confiabilidade: a capacidade de fornecer informações de teleproteção no final do
recebimento, apesar da presença de degradações do canal de comunicação;
 Segurança: a capacidade do receptor de rejeitar uma falsa informação de
teleproteção que foi provocada pelas degradações do canal de comunicação.
Um parâmetro adicional é o tempo máximo de transmissão: as informações de teleproteção

devem ser entregues na extremidade remota antes de um tempo máximo de transmissão. A
confiabilidade é geralmente medida em termos de Probabilidade de Comando Ausente Pmc
(Probability of Missing Command) e a segurança é medida em termos de Probabilidade de
Comando Indesejado Puc (Probability of Unwanted Command).
7.4.2 Esquemas de Proteção para Elementos de Distância
Os IEDs de proteção de distância incluem diferentes esquemas de proteção como

complemento aos elementos escalonados de distância. Esses esquemas visam acelerar o
disparo por falhas que ocorrem fora da Zona 1. Esses sistemas são conhecidos como
Esquemas de Proteção de Distância e são baseados no uso de sinais transmitidos através
de canais de comunicação entre terminais de ambos extremos da linha, de modo que uma
lógica de decisão opera tanto com informações locais quanto remotas.
Os esquemas de teleproteção podem ser classificados em 5 (cinco) grandes grupos:
 Esquemas de comparação de fase;
 Esquemas diferenciais;
 Esquemas de transferência de sinal de "trip";
 Esquemas de comparação direcional;
 Esquemas de aceleração ou prolongamento de zona.
Tipos de esquemas:
 Transferência Direta de Trip por Subalcance (Direct Underreaching Transferred
Tripping) – DUTT;
 Transferência de Trip Permissivo por Subalcance (Permissive Underreaching
Transferred Tripping) – PUTT;
 Transferência de Trip Permissivo por Sobrealcance (Permissive Overreaching
Transferred Tripping) – POTT;
 Transferência de Trip Direto (Direct Transferred Tripping) – TDD.
83
Figura 93 – Transferência de Trip Direto (Direct Transferred Tripping) de um sistema de

Proteção Diferencial de Linhas
Figura 94 - Comunicação entre um IED de proteção e um equipamento de teleproteção por

meio do padrão IEC 61850 (GOOSE)
7.4.3 Nó lógico PSCH para Esquemas de Proteção de Distância
A Norma IEC 61850 apresenta a proposta de Nós Lógicos para todas as funções de
proteção. Para o Esquema de teleproteção o nome do Nó Lógico é: PSCH.
Este Nó Lógico deve ser usado para modelar o esquema lógico para coordenação da função
de proteção de linha. O esquema de proteção permite a troca das saídas “Operate" de
diferentes funções e condições de proteção para esquemas de proteção de linha.
A Norma IEC 61850 apresenta a proposta de Nós Lógicos para todas as funções de
proteção. Para o Esquema de teleproteção o nome do Nó Lógico é: PSCH.
84
Figura 95 - Nós Lógicos para as funções de proteção [1-Part 7-4]
Conforme a Norma IEC 61850 estabelece, os Nós Lógicos PSCH e PTRC são utilizados em
aplicações em Esquemas de teleproteção. O Nó Lógico PSCH é usado para modelar
esquemas típicos em IEDs multifuncionais para proteção de linha. Os dados fornecidos
permitem seu uso para modelagem de diferentes comunicações baseadas em esquemas de
aceleração para proteção de linhas de transmissão.
O PSCH pode trocar dados com muitos Nós Lógicos (PDIS, PTOC,..., ou até mesmo outros
PSCH). Todos esses Nós Lógicos podem estar localizados em diferentes Dispositivos
Lógicos e Dispositivos Físicos (IEDs). O Nó Lógico PTRC é usado para agrupar vários sinais
de disparo e aplicá-los em uma única condição de disparo. O exemplo na Figura 95,
diagrama extraído da Norma IEC 61850, ilustra um esquema de proteção de linha que
consiste em funções para Proteção de distância (três instâncias para três zonas) com
teleproteção (PDIS + PSCH), para Proteção por comparação direcional de faltas à terra
(PTOC2) e para proteção sobrecorrente (PTOC1) em ambas as extremidades da linha.
Figura 96 – Uso de PSCH e PTRC [1-Part 7-4]
85
As funções de teleproteção (permissive overreach, permissive under reach, blocking,

unblocking, etc.) para proteção de distância e para o esquema de comparação direcional de
faltas a terra estão concentrados nas instâncias PSCH1 e PSCH2 do LN PSCH.
Esses nós lógicos controlam a comunicação entre as duas extremidades da linha. Todos os
sinais de operação provenientes dos nós PSCH e dos demais nós de proteção são
agrupados a um único comando de disparo em um PTRC. PTRC cuida do condicionamento
do sinal de disparo (duração mínima do comando de disparo, decisão de disparo
monopolar/tripolar, etc.).
Dependendo dos módulos que compõem o sistema de teleproteção, o sistema pode ser
configurado para trabalhar com um ou dois canais de transmissão que podem ser
analógicos ou digitais. Além disso, ao trabalhar com dois canais, o terminal pode ser
programado para funcionar como dois terminais independentes de teleproteção.
Como no caso das interfaces de proteção analógica, um módulo de interface de proteção
IEC 61850, permite que os sistemas de teleproteção gerenciem as mensagens GOOSE e
estas sejam associadas a qualquer um dos comandos possíveis a serem transmitidos do
sistema de teleproteção. Caso mais de uma mensagem seja atribuída ao mesmo comando,
deve ser programada uma lógica que deve ser cumprida para que o sistema de teleproteção
transmita o comando para o terminal do outro lado do link.
Um sistema de teleproteção equipado com um módulo de comunicação Ethernet pode
transmitir as informações de teleproteção sobre redes de pacotes IP. As tags específicas do
pacote, que são adicionadas às informações de teleproteção, permitem que a qualidade do
serviço da rede IP seja monitorada e, as saídas de comando do sistema de teleproteção
sejam bloqueadas quando a carga da rede IP afetar o desempenho do sistema de
teleproteção.
Dependendo do fabricante, um sistema de teleproteção pode ser configurado para funcionar
em redes de pacotes IP e permitir a transmissão de comandos de teleproteção em um
pacote IP usando uma interface de comunicação IP. Esta interface de comunicação IP pode
consistir em um número de portas elétricas tipo 10/100Base-Tx com conectores RJ-45 ou
portas ópticas 100Base-Fx multimode (1300 nm) com conector ST. Estas portas podem
possuir o mesmo endereço IP.
O sistema de teleproteção pode ser compatível com a norma IEC 61850 e, portanto, permitir
que a comunicação dos IEDs de proteção com os equipamentos de teleproteção em uma
subestação seja realizada através da troca de mensagens GOOSE. O sistema de
teleproteção também pode ser equipado com interfaces de proteção analógica, que
permitem que ele se comunique com IEDs de proteção que ainda não estão adaptadas ao
padrão IEC 61850.
Os terminais de teleproteção podem incluir um agente SNMP capaz de enviar notificações
(informações não solicitadas transmitidas espontaneamente) sobre alarmes e eventos do
terminal para os dispositivos especificados pelo usuário, e isso permite monitorar o sistema
de teleproteção a partir de um aplicativo de gerenciamento SNMP, como, o HP Openview ou
equivalente.
De um modo geral, os sistemas de teleproteção registram cronologicamente todos os
alarmes e eventos produzidos em um link. Este registro cronológico de alarmes e eventos
dos terminais de teleproteção é realizado com base em seu relógio interno em tempo real,
podendo ser sincronizado com o sistema GPS ou por meio do SNTP.
86
7.4.4 Interfaces de Proteção Mista e Comunicação PDH
O exemplo da Figura 97 mostra como um sistema de teleproteção equipado com interfaces

de proteção compatíveis com o padrão IEC 61850 pode ser equipado, simultaneamente,
com interfaces de proteção analógica que facilitam a migração das proteções para o padrão
IEC 61850 em uma subestação.
Figura 97 – Interfaces de proteção mista
Os dois terminais de teleproteção se comunicam através de uma rede PDH que eles
acessam por meio de um canal de 64 kbit/s. O sistema de teleproteção da subestação A
está conectado à rede corporativa da concessionária de energia elétrica, para que os
usuários autorizados possam acessá-lo a partir de qualquer ponto da rede.
O equipamento de teleproteção da subestação A possui módulos de interface para IEDs de
proteção compatíveis com o padrão IEC 61850 e, relés não compatíveis. A proteção da
subestação B não é compatível com a norma IEC 61850. Considera-se que quatro
comandos são transmitidos entre os terminais de teleproteção, embora o número de
comandos possa ser de até oito.
7.4.5 Aplicação de Canal de Backup e Sistema de Comunicação SDH
O exemplo da Figura 98 mostra como um sistema de teleproteção pode ser equipado com
duas interfaces de comunicação, de modo que ele tenha um canal de backup que possa
evitar qualquer possível falha do canal principal.
87
Figura 98 – Interfaces duplicadas
Como pode ser visto, a subestação A não está preparada para funcionar de acordo com o
padrão IEC 61850, enquanto a subestação B está capacitada.
A Teleproteção em um ambiente onde o canal de comunicação seja baseado em um
sistema de comutação de circuito SDH funciona através de um quadro E1. Quando a
mensagem de teleproteção é otimizada para obter tempos de transmissão adequados para
o canal de comunicação e para os requisitos da norma IEC 60834-1. Essa otimização
permite que os comandos da proteção de distância cheguem ao lado remoto com tempo
suficiente para o sistema de proteção atuar nos tempos necessários.
7.4.6 Teleproteção e as Redes IP Network
O vasto crescimento da Internet fez com que o Protocolo de Internet (IP) se tornasse a base
das redes de telecomunicações atuais. Dessa forma, as empresas de energia tendem a
substituir as interfaces analógicas e digitais tradicionais por interfaces padrão tipo Ethernet
ou IP, com o objetivo de usar uma única rede para transportar todos os tipos de
informações, incluindo, entre outros serviços, teleproteção, um dos serviços mais
importantes em redes de transmissão de energia.
Um dos desafios na adaptação da teleproteção aos novos canais de comunicação é manter
a confiabilidade dos equipamentos de proteção no novo sistema de comunicação. Ao mudar
de um sistema de comutação de circuito SDH para um sistema de comutação de pacotes
MPLS-TP, é necessário adaptar os quadros de comunicação do equipamento ao novo
ambiente, a fim de manter os tempos de transmissão necessários para as proteções e
continuar cumprindo a norma IEC 60834-1 no que diz respeito à segurança e confiabilidade.
Muitos fabricantes vêm adequando os seus equipamentos de teleproteção a esta nova
realidade adicionando um novo módulo de comunicação que permite acesso ao nó de
88
comunicações MPLS-TP através de uma interface Ethernet. O objetivo é adaptar a

teleproteção aos novos canais de comunicação, o que permitirá reduzir os tempos de
transmissão, mantendo os valores de segurança e confiabilidade dentro dos padrões
exigidos pela norma IEC60834-1.
A adequação da estrutura dos frames inclui todas as proteções da mensagem de
teleproteção digital, como o CRC, a estrutura fixa e endereços das teleproteções. Esta
estrutura está encapsulada dentro do frame Ethernet. Considerando a preocupação mundial
com os assuntos de segurança cibernética, os fabricantes vêm implementando o IPSEC
para melhorar a segurança da rede Ethernet.
A solução baseada na comutação de pacotes permite melhorar a confiabilidade do sistema
de teleproteção, reduzindo o tempo de transmissão devido ao menor tempo de
processamento necessário para cada pacote em comparação com o usado nos sistemas
SDH.
No exemplo da Figura 99 a seguir, cada dispositivo de teleproteção é equipado com uma
interface IP, a fim de realizar transmissão de sinal de teleproteção e recepção no modo
pacote através de uma rede IP. Tags específicas do pacote, que são adicionadas às
informações de teleproteção, permitem monitorar a qualidade do serviço da rede IP e,
dependendo da configuração adotada no sistema, as saídas de comando do terminal de
teleproteção podem ser bloqueadas quando a qualidade do serviço da rede IP não for
satisfatória.
Figura 99 – Aplicação em rede IP e GOOSE
89
As empresas de energia precisam de comunicações confiáveis e sistemáticas em sua grade

de operação. Por outro lado, também precisam que muitos aplicativos, infraestruturas ou
serviços funcionem ao mesmo tempo em momentos críticos. Portanto, certas aplicações
possuem requisitos rigorosos no desenvolvimento de seu canal de comunicação e,
logicamente, as soluções aplicadas devem ser otimizadas para a tecnologia da rede de
comunicação da concessionária.
A tecnologia da rede de comunicações, como está acontecendo no resto das operadoras ou
em todo mundo, está evoluindo para soluções de comutação de pacotes, o que traz novos
desafios para manter os requisitos iniciais.
O desempenho do sistema de proteção só é garantido se todos os subsistemas contribuírem
com a parte necessária. Os equipamentos de teleproteção estão dentro desses serviços que
exigem requisitos mais rigorosos. O cumprimento da norma IEC60834 garante o correto
funcionamento do sistema de teleproteção e a aplicação da Norma IEC 61850 nos sistemas
de teleproteção permite que as empresas de energia se beneficiem de todas as vantagens
da evolução da tecnologia.
7.5 REGISTRADOR DIGITAL DE PERTURBAÇÃO – RDP
O Registrador Digital de Perturbação - RDP é utilizado como um agente externo e

independente aos IED de proteção. O RDP tem a funcionalidade de registrar as grandezas
analógicas (corrente e tensão) e as grandezas digitais (status e disparos de proteção)
durante as perturbações que ocorrem no sistema elétrico. Essas perturbações geram
arquivos, normalmente em formato COMTRADE, que devem ser encaminhados
automaticamente para a equipe de análise dos agentes e para o Operador Nacional do
Sistema Elétrico - ONS.
A oscilografia é uma ferramenta de alta importância na análise das perturbações do sistema
elétrico, que juntamente com as informações de sequencial de eventos (supervisório e IEDs
de proteção), relatórios da operação, dados de monitoração de descargas atmosféricas e
queimadas, permitem a análise completa de uma perturbação.
De acordo com os procedimentos definidos pelo Operador do Sistema Elétrico, os
registradores devem ter filtragem anti-aliasing, taxa de amostragem que permita o registro
de componentes harmônicas de até a 15º ordem (60 Hz), requisitos de sincronismo com
erro máximo de 1ms, além de outros requisitos quanto a precisão das medidas analógicas,
autodiagnostico e armazenamento interno.
Devido ao alto valor das parcelas variáveis, linhas de transmissão mais importantes
possuem RDP que contam com uma tecnologia de localização por ondas viajantes. Essa
tecnologia permite que a localização da falta dentro da linha de transmissão seja calculada
de maneira simples e com alta precisão. Entretanto, essa tecnologia tem como base
componentes em alta frequência (tipicamente de 10kHz a 600kHz), necessitando de
conversores Analógicos/Digitais (AD) de alta velocidade e filtros especiais.
7.5.1 Esquemas Clássicos
Os esquemas clássicos de implementação do RDP possuem ligações físicas das

grandezas analógicas (corrente e tensão) provindas dos equipamentos de pátio,
interligações físicas entre os IEDs de proteção (principal e alternado) e o RDP para o
registro da atuação das funções de proteção (TRIP) e status de equipamentos ligados
fisicamente. Podem-se citar as seguintes características dos sistemas clássicos existentes:
90
 Necessidade de diversas entradas digitais no Registrador;

 Necessidade de diversas saídas digitais no IED de Proteção;
 Conversão A/D (corrente e/ou tensão) realizada pelo RDP;
 Projeto de interligação complexo;
 Limitação das entradas físicas digitais;
 Maior complexidade de expansão e adequação;
 Agrupamento de funções de proteção visando a economia dos canais digitais físicos.
7.5.2 Uso atual da IEC 61850 no RDP
Como explicitado nos capítulos anteriores, atualmente os agentes no Brasil estão utilizando
muito mais os protocolos descritos na norma do que as filosofias e fundamentos baseados
nela. Com isto, muitos RDP em funcionamento já registram canais digitais através do
protocolo GOOSE, provenientes de pontos de atuação (TRIP) publicados pelos IEDs de
proteção, entretanto ainda utilizam canais analógicos cablados. Podem-se citar as seguintes
características dos sistemas atuais:
 Projeto de interligação mais simples;
 Conversão A/D (corrente e/ou tensão) realizada pelo RDP;
 Limitação devido a capacidade de processamento do RDP;
 Facilidade de expansão e adequação de novos pontos digitais (GOOSE);
 Equipamentos mais compactos, porém mantendo canais analógicos físicos e alguns
canais digitais físicos.
7.5.3 Uso do RDP em sistemas baseados na IEC 61850
Como exemplificado anteriormente o uso do RDP nos sistemas atuais tem como base sua
independência em relação ao IED de proteção, ou seja, os registros oscilográficos são
formados a partir do conversor A/D do próprio RDP. Entretanto, em uma arquitetura
utilizando Merging Unit (MU) a conversão A/D deixa de ser interna aos IED de proteção e ao
RDP e passa exclusivamente a ser realizada pelo conversor A/D da Merging Unit.
A seguir vai se detalhar algumas arquiteturas possíveis de implementação do RDP em
sistemas baseados na IEC 61850 com Merging Unit.
7.5.3.1 Utilização por Bay - Nível de Bay
Conforme se pode verificar na Figura 100 a seguir, cada Bay possui um RDP específico.
Essa arquitetura pode ser utilizada quando se possui anéis HSR individuais para cada bay.
Nesta arquitetura o RDP recebe as informações analógicas via Sampled Values (SV) e
digitais via GOOSE. Entretanto, como a conversão A/D é realizada pela Merging Unit, as
informações analógicas via SV que chegam no RDP são as mesmas do IED de proteção.
91
Nível de Estação IHM Coletor
Barramento de Estação
Bay 1 Bay 2
Nível de Bay Proteção UAC RDP Proteção UAC RDP
Nível de Processo MU MU
MU Pátio MU
Figura 100 – Aplicação de RDP por bay no nível de bay
Podem-se citar como características dessa arquitetura:

 Canais analógicos via protocolo (SV);
 Canais digitais via protocolo (GOOSE);
 Possibilidade de incorporação da função “Registrador” em um IED existente;
 Conversão A/D realizada pela Merging Unit;
 Menor requisito de velocidade da placa de comunicação;
 Equipamentos compactos;
 Maior quantidade de pontos digitais monitorados;
 Maior quantidade de RDP na subestação;
 Comunicação direta do IED de proteção com o Registrador de perturbação via
protocolo GOOSE;
 Registros de oscilografias sendo adquiridos em tempo real, através de comandos
MMS pelo COLETOR em nível de estação;
 Taxa de amostragem definida pela MU;
 Não é possível a localização de faltas por Ondas Viajantes.
7.5.3.2 Utilização em mais de um vão (bay) - Nível de Bay
Conforme se pode verificar na Figura 101 abaixo, um RDP pode ser utilizado por mais de
um vão (bay). Nesta arquitetura o RDP recebe as informações analógicas via Sampled
Values (SV) e digitais via GOOSE de todos os bays envolvidos. Assim como a arquitetura
anterior a conversão A/D é realizada pela Merging Unit, as informações analógicas via SV
que chegam no RDP são as mesmas do IED de proteção.
Bay 1 Bay 2
Nível de Bay Proteção UAC RDP Proteção UAC
MU Pátio MU
Figura 101 – Aplicação de RDP no nível de bay
92

 Canais analógicos via protocolo (SV);
 Canais digitais via protocolo (GOOSE);
 Possibilidade de incorporação da função “Registrador” em um IED existente;
 Conversão A/D realizada pela Merging Unit;
 Maior requisito de velocidade da placa de comunicação;
 Maior quantidade de pontos digitais monitorados;
 Menor quantidade de RDP na subestação;
 Limitação devido à capacidade de processamento do RDP;
 Limitação devido à capacidade da rede de comunicação;
protocolo GOOSE;
 Taxa de amostragem definida pela MU;
 Não é possível a localização de faltas por Ondas Viajantes.
7.5.3.3 Utilização do RDP no pátio – Nível de Processo
Conforme se pode verificar na Figura 102 a seguir, o RDP está instalado no pátio. Nesta
arquitetura o RDP recebe as informações analógicas físicas e informações digitais via
GOOSE e/ou físicas. A conversão A/D é realizada pelo próprio RDP garantindo a
individualidade em relação aos sistemas de proteção. Outra característica importante dessa
arquitetura é que ela permite a localização de faltas por ondas viajantes e as taxas de
amostragem das oscilografias não estão associadas às MUs. Essa arquitetura não poderá
ser utilizada quando na existência de TP e TC óptico na subestação.
O RDP além de desempenhar o papel de “auditor” da proteção pode também realizar o
papel de “auditor” da própria Merging Unit nos momentos de perturbação do sistema.
Possuindo a capacidade de monitoração ativa dos “watchdogs” das MUs (binária de saída
por falha interna) reportando diretamente para o sistema supervisório via MMS.
Bay 1 Bay 2
Nível de Bay Proteção UAC Proteção UAC
Pátio
MU RDP MU
Figura 102 – Aplicação do RDP no nível de processo
93

 Canais analógicos físicos;
 Canais digitais via protocolo (GOOSE) e físicos;
 Conversão A/D realizada pelo próprio RDP;
 Menor requisito de velocidade da placa de comunicação;
 Limitação devido a quantidade de canais físicos analógicos e digitais;
 Necessidade de cabos de cobre de interligação entre MU e RDP;
 Necessidade de projetos elétricos de interligação;
protocolo GOOSE;
 Taxa de amostragem definida pelo próprio RDP;
 Possível localização de faltas por Ondas Viajantes.
7.5.4 Novos sistemas de Registros
Com a digitalização total das subestações é provável que novas tecnologias e novos
conceitos surjam para colaborar nas análises de perturbações e na confecção de registros
oscilográficos. Devido a todos os dados das grandezas analógicas e digitais estarem
circulando pelas redes de comunicação, uma monitoração ativa nessa rede de comunicação
durante as perturbações se tornará cada vez mais importante. O papel do registrador não
ficará mais restrito ao sistema elétrico, pois terá de registrar os acontecimentos da própria
rede de comunicação durante a perturbação.
Com o avanço dos sistemas de armazenamento, o registrador poderá guardar ao longo do
dia todas as informações que estão circulando pela rede de comunicação de uma
subestação. Estas informações poderão ser armazenadas e consultadas com a finalidade
de entendimento de perturbações na própria subestação ou até em subestações próximas,
trazendo para a engenharia elétrica conceitos como Big Data e mineração de dados. Essa
extraordinária quantidade de dados pode auxiliar nos estudos de curto-circuito, estabilidade
sistêmica, arquitetura de equipamentos entre outros.
94
8. REQUISITOS DE SEGURANÇA CIBERNÉTICA EM

SISTEMAS OPERANDO COM COMUNICAÇÃO E A
NORMA IEC 61850
Com a evolução das subestações aplicando tecnologia digital, com dispositivos eletrônicos
inteligentes na sala de controle e no pátio da subestação, conectados numa rede ethernet e
utilizando sistemas de comunicação para aquisição de dados e aplicação de funções, um
aspecto novo e fundamental é garantir a segurança cibernética.
Numa solução IEC 61850 ela é muito importante porque toda a infraestrutura de
comunicação adota uma solução padronizada, portanto conhecida e que deve ser protegida
para garantir a confidencialidade, integridade e, principalmente a disponibilidade dos dados
e dos fluxos de informações, de acordo com as metas de proteção definidas em ISO/IEC
27000 (CIA Triangle).
Apesar dos requisitos e mecanismos de segurança na rede industrial ser similar a uma rede
aplicada tradicionalmente pela Tecnologia da Informação – TI, existem diferenças
importantes, porque a premissa dos IACS - Industrial Automation and Control Systems é que
foram concebidos para atender requisitos de escalabilidade, desempenho, eficiência,
interoperabilidade, redundância e, principalmente, disponibilidade, e normalmente sem
preocupação inicial com segurança cibernética, mas com foco em ciclos de vida longos sem
interrupção. Estes requisitos, portanto, não podem ser impactados pelos mecanismos de
proteção.
Figura 103 – Subestações digitais de 3ª Geração
Nas subestações modernas de 3ª geração o projeto da rede e seus dispositivos devem

contemplar as ações, requisitos, procedimentos e sistemas que irão garantir a segurança
cibernética da instalação. A visão deve englobar uma rede local segura, e considerar todas
as interfaces externas existentes, sejam elas conexões remotas operacionais e conexões
com a rede corporativa, de maneira controlada e somente quando for estritamente
necessário à operação.
Além da evolução tecnológica, aspectos regulatórios nacionais e internacionais pressionam
as empresas a garantirem a disponibilidade e a segurança de redes críticas, como é o caso
daquelas associadas ao sistema elétrico.
95
8.1 ANÁLISE DE ATAQUES, RISCOS E AMEAÇAS
A aplicação intensa de uma solução digital, baseada em dispositivos eletrônicos numa rede
ethernet, com serviços, funcionalidades e protocolos padronizados permite agregar grandes
vantagens de flexibilidade, interoperabilidade, monitoramento e acesso.
Por outro lado, o sistema de proteção, automação e controle fica mais vulnerável, o que
pode levar a sérias consequências para o sistema de potência. Isto acontece porque a
infraestrutura está mais exposta e uma configuração incorreta ou uma fragilidade no sistema
permite que incidentes cibernéticos ou ataques direcionados sejam efetuados,
comprometendo a confidencialidade, a integridade ou a disponibilidade do sistema.
Um grande desafio é que normalmente em dispositivos utilizados nos sistemas de
automação e proteção são aplicadas poucas atualizações. Os motivos disso são
principalmente:
 Garantir a disponibilidade sem interrupção dos serviços;
 Complexidade em testes de validação, já que atualizações de firmware são tratadas
como um novo produto tendo que passar por todos os níveis de testes, laboratório e
campo gerando custos, riscos e indisponibilidade;
 Limitações de hardware e versões de produto que não suportam atualizações
tecnológicas mais recentes.
Por isso é comum termos sistemas legados, que atingiram o limite de sua atualização
tecnológica. Isto aumenta a vulnerabilidade e facilita as ações de quem quer invadir
sistemas. O grupo de trabalho WG B5.38 do CIGRE definiu o adversário como muitas
pessoas (não um único hacker) com um conhecimento abrangente das funções críticas de
proteção e automação de missão crítica, que são o objeto do ataque. O conhecimento
técnico necessário para realizar um ataque e atingir um sistema crítico de energia está
ficando cada vez menor. Por isso, sabe-se que com um patrocinador que financie o ataque e
com a paciência suficiente para treinar e ensaiar adequadamente todos os elementos do
ataque durante o tempo necessário é cada vez mais difícil proteger toda esta infraestrutura
crítica e seus dispositivos.
A Figura 104 mostra a evolução de algumas ferramentas, utilizadas por profissionais de
segurança e também por atacantes, que reduzem significativamente o nível de
conhecimento necessário para elaborar e efetuar um ataque cibernético.
Figura 104 – Evolução de ferramentas e nível de conhecimento
96
Como um sistema IEC 61850 é baseado nos protocolos TCP/IP Ethernet aplicada em
grande escala, está sujeito às mesmas ameaças que qualquer outro sistema de controle
distribuído do setor com base nesses protocolos. Alguns exemplos são:
• Ataques de negação de serviço (DoS), por exemplo, pelo uso de pacotes
fragmentados disparados em larga escala em direção ao alvo;
• Ataques de verificação geralmente consistindo em um host que testa a
acessibilidade de todos os endereços IP em uma LAN procurando oportunidades de
acesso backdoor;
• Sessões incompletas, como ataques TCP SYN Flooding, que tentam saturar os
hosts atacados (recusa de serviço);
• Sobrecargas de interface;
• Falsificação de IP, em que um pacote usa um endereço IP de origem incorreto para
ocultar sua verdadeira fonte;
• Exploração de pilha de protocolos (falhas de implementação da IEC 61850) -
necessário patch para correção.
Figura 105 – Requisitos de segurança, ameaças e possíveis ataques [52]
As ameaças podem ser consideradas com relação a duas origens: riscos internos e
externos.
As ameaças internas são muito preocupantes, pois significa ter alguém que conhece com
detalhe, não apenas como o sistema de proteção e automação funciona, mas também os
pontos de acesso mais vulneráveis que permitem vetores de ataque. Por isso a proteção
deve começar internamente, olhando para incidentes que podem ser causados, por
exemplo, por funcionários (ou ex-funcionários) insatisfeitos, chamados insiders, que tem
acesso à rede da empresa, ou por falhas humanas e erros de configuração e operação,
causados principalmente por excesso de privilégios e/ou acessos inadequados (bastante
frequente). Incidentes cibernéticos nem sempre são causados por ataques direcionados e
97
consegue-se contornar essa situação e incidentes internos através de boas práticas,

políticas adequadas de segurança e medidas técnicas adequadas.
Deve-se considerar não apenas os funcionários das concessionárias, mas as empresas de
dispositivos e sistemas IEC 61850, integradores de sistemas e consultores que suportam
todos os aspectos do projeto de proteção e automação, teste e avaliação e
comissionamento que normalmente podem ter necessidade legítima de acessar qualquer
parte do sistema.
Os riscos externos significam um patamar mais elevado de segurança, quando a intenção é
proteger-se contra ameaças iminentes e ataques direcionados, exigindo medidas de
proteção mais rigorosas, uso de equipamentos e tecnologias apropriadas e aplicação de
controles de acesso restritos. Além disso, é extremamente importante a capacitação do
corpo técnico que opera e mantém o sistema, pois na maioria das vezes as pessoas são o
elo mais fraco da cadeia e podem ser utilizadas como primeiro vetor de ataque para
manipulação e infiltração nas empresas, através de um mecanismo conhecido como
engenharia social.
As maiores preocupações das empresas de energia elétrica que operam o sistema de
potência são:
• Riscos e Vulnerabilidades das redes de comunicação baseadas em TCP/IP;
• Garantir a Disponibilidade;
• Acesso Remoto Seguro / Confidencialidade.
Figura 106 – Metas e objetivos de proteção
As preocupações são similares aos sistemas corporativos, mas a mudança está na

prioridade dos requisitos. A disponibilidade é fundamental especialmente quando estamos
considerando um sistema IEC 61850, em que o sistema de proteção e automação precisa
de informações instantâneas de sinais de estados e medidas. A indisponibilidade da
informação forçará a consequente parada do sistema de controle e colocará em risco os
equipamentos primários e as pessoas envolvidas em sua operação e manutenção.
Comprometimento da integridade também é um problema grave, podendo levar a
comportamentos incorretos. Mas num sistema de proteção e controle existem diferentes
IEDs e funções (proteção primária e alternada, controle principal e dual) que podem cobrir
problemas e ajudar a detectar incorreções, preservando funcionalidades e continuidade das
funções.
A confidencialidade tem menor importância, a não ser para ajudar a ter compreensão do
sistema para um ataque dirigido.
98
8.2 OBJETIVOS DE PROTEÇÃO, NORMAS E ABORDAGEM DE SEGURANÇA
Para definirmos os requisitos de uma solução de segurança cibernética adequada a uma

solução IEC 61850, precisamos determinar as normas internacionais que deverão ser
aplicadas garantindo sua disponibilidade.
Este é um problema bastante complexo, porque existem diversas normas, com diferentes
focos, e todas com aspectos importantes a serem abordados. Elas não chegam a ser
complementares, o que torna mais difícil a definição de quais devem ser aplicadas.
Na Figura 107 temos uma visão geral de algumas normas IEC/ISO, mostrando o foco de
cada uma:
 Sistemas de Energia;
 Sistemas de Informação;
 Automação Industrial.
Figura 107 – Visão geral das normas IEC/ISSO [51]
Mas existem outras referências importantes que devem ser consideradas que dependem do
papel no sistema: vendedor, integrador, operador e das etapas do processo: orientação,
requisitos e implementação. A Figura 108 apresenta uma visão geral neste sentido.
Figura 108 – Visão geral - Padrões de segurança cibernética
99
Uma das principais normas a considerar é a IEC 62443, padrão internacional criada pela
ISA - International Society of Automation que consiste em uma série de normas, relatórios
técnicos e informações relacionadas que definem procedimentos para aplicar os IACS -
Industrial Automation and Control Systems que devem ser eletronicamente seguros.
Figura 109 – IEC 62443 padrão líder em automação industrial
Ela cobre de forma abrangente todos os aspectos de segurança industrial, conforme vemos
na próxima figura.
Figura 110 – Aspectos cobertos pela norma IEC 62443
O objetivo da norma é melhorar o sistema de automação e controle industrial garantindo sua

segurança, integridade, disponibilidade e confidencialidade abordando políticas,
procedimentos, sistemas e componentes.
O seu escopo são os sistemas de automação e controle industrial das indústrias críticas de
infraestrutura:
 Transmissão e distribuição de eletricidade;
 Redes de distribuição de gás e água;
 Operações de produção de petróleo e gás;
 Tubulações de transmissão de gás e líquido.
100
A estrutura da norma aborda os diferentes envolvidos nos processos de implantação e

gestão:
 Fornecedor de produtos;
 Integradores de sistemas;
 Provedor de serviço;
 Operador;
 Proprietário do ativo.
Para que seja possível identificar a exposição ao risco de um sistema e consequentemente

definir as medidas que deverão ser adotadas, é importante realizar uma avaliação preliminar
de ameaças e riscos, conhecida como TRA - Threat and Risk Assessment. Com uma
abordagem baseada em risco é possível identificar possíveis ameaças e ataques que violem
os objetivos de proteção. As mais significativas devem ser mapeadas e organizadas em
uma tabela de referência que considera o impacto do ataque versus a probabilidade de
ocorrência.
O objetivo principal é criar um plano de ação para cada ameaça identificada (posicionada
em um quadrado dentro da matriz de classificação de risco) e aplicar algum tratamento com
medidas de mitigação ou contramedidas até que desapareçam do mapeamento ou sejam
reduzidas para uma posição menos significativa após as medidas aplicadas.
Figura 111 – TRA - Threat and Risk Assessment [15]
Um dos conceitos importantes nestas estratégias e apresentada na norma é o de defesa em

profundidade, do termo em inglês DiD - Defense-in-depth.
Figura 112 – TRA - DiD - Defense-in-depth
101
O princípio básico é não confiar numa única medida de segurança para evitar invasões.
Desta maneira deve se construir várias camadas de proteção, sendo que cada uma suporta
as demais camadas. Desta maneira aumentamos a segurança do sistema, e se ocorrer a
invasão numa camada dificultamos o avanço e ganhamos tempo para detectar a ameaça e
tomar ações de proteção para reagir a tempo.
8.3 PRINCÍPIOS DE DESIGN SEGURO
A aplicação de uma solução digital IEC 61850 segura depende de incorporar ao projeto os
conceitos necessários e as estratégias para aplicar uma arquitetura segura e princípios para
um design seguro. Estes aspectos são abordados na norma IEC 62443 parte 3-3: Requisitos
de Segurança do Sistema e Níveis de Segurança.
Ela considera aspectos de outras normas, com as principais entradas da ISO / IEC 27002 e
NIST SP800-53, rev. 3. A IEC 62443-3-3 é utilizada no NIST Cybersecurity Framework.
A norma IEC 62443 aborda as medidas de segurança de um sistema:
 Controle de acesso e gerenciamento de contas;
 Log e monitoramento de segurança;
 Endurecimento do sistema (hardening);
 Patch de segurança, backup e restauração;
 Proteção contra malware;
 Proteção e integridade de dados e arquitetura do sistema;
 Acesso remoto seguro.
Figura 113 – Visão geral de um design seguro [15]
102
O escopo da norma IEC 62443-3-3 não é um produto único, mas um sistema para fazer uma
abordagem completa. Ele prescreve os requisitos de segurança para sistemas de controle
relacionados aos sete requisitos fundamentais (FRs - foundational requirements) definidos
na IEC 62443-1-1 e atribui níveis de segurança do sistema (SLs - system security levels) ao
próprio sistema em questão (SuC - system under consideration).
As medidas de segurança do IACS - Industrial Automation and Control Systems não devem
ter o potencial de causar perda de serviços e funções essenciais, incluindo procedimentos
de emergência. As metas de segurança do IACS concentram-se na disponibilidade do
sistema de controle, proteção da planta, operações da planta (mesmo em modo degradado)
e resposta do sistema com tempo crítico.
Uma etapa fundamental na avaliação de risco, conforme exigido pela IEC 62443-2-1, deve
ser a identificação de quais serviços e funções são realmente essenciais para as operações.
Figura 114 – FRs Requisitos Fundamentais
A IEC 62443-3-3 prescreve os requisitos de segurança para sistemas de controle

relacionados aos sete FRs. Os requisitos fundamentais são expandidos numa série de
requisitos de segurança SRs - Security Requirements. Cada SRs tem requisitos básicos
BRs – Baseline Requirement e requisitos de aprimoramento REs - Requirement
Enhancements.
Requisitos básicos BRs e REs são mapeados para um nível de segurança SL – Security
Level.
Os níveis definidos são:
 SL 0 - Não são necessários requisitos específicos ou proteção de segurança;
 SL 1 - Proteção contra violação casual ou coincidente;
 SL 2 - Proteção contra violação intencional usando meios simples, com
poucos
recursos, habilidades genéricas e baixa motivação;
 SL 3 - Proteção contra violação intencional usando meios sofisticados com
recursos
moderados, habilidades específicas do IACS e motivação moderada;
 SL 4 - Proteção contra violação intencional usando meios sofisticados com
recursos
estendidos, habilidades específicas do IACS e alta motivação.
103
Desta maneira podemos avaliar a força de segurança das soluções indicadas por níveis de
segurança padronizados.
Toda esta metodologia permite visualizar o nível de segurança de maneira gráfica com uma
representação vetorial dos diversos critérios, conforme apresentado na Figura 117.
Figura 115 – Avaliação níveis de segurança dos requisitos fundamentais: Vetor SL [15]
Outro conceito importante é da IEC 62443-3-2 é zona e condute:

 Zona - Agrupamento de ativos lógicos ou físicos que compartilham requisitos de
segurança comuns;
 Condute - Agrupamento lógico de canais de comunicação, conectando duas ou mais
zonas, que compartilham requisitos de segurança comuns.
As zonas e conduites são estabelecidas de forma a agrupar ativos com base na

funcionalidade local, organização responsável e o resultado de uma avaliação de risco de
alto nível. Os resultados da avaliação de riscos são usados para atribuir níveis de segurança
SL específico para cada zona e condute. A Figura 118 mostra um exemplo de zonas e
conduites.
Figura 116 – Exemplo de zonas e conduítes [15]
104
Ao projetar um sistema de controle para atender a um nível de segurança específico, não é

necessário que todos os componentes do sistema de controle proposto suportem todos os
requisitos do sistema até o nível exigido na IEC 62443-3-3. Contramedidas de compensação
podem ser empregadas para fornecer a funcionalidade necessária a outros subsistemas, de
modo que os requisitos gerais de SL-T (nível almejado) sejam atendidos no nível do sistema
de controle.
Um exemplo prático de contramedida empregada seria, por exemplo, quando o PLC de um
fornecedor não pode atender aos recursos de controle de acesso de um usuário final;
portanto, o fornecedor colocaria um firewall na frente do PLC (contramedida) e o venderia
como um sistema seguro que atende aos requisitos necessários.
Figura 117 – Inter-relação entre SRs, SLs, zonas e conduites.
A Figura 117 apresenta a relação entre os conceitos apresentados de requisitos de

segurança SR, níveis de segurança SL, zonas e conduítes. Percebe-se que existe um ciclo
contínuo de otimização e melhoria do ponto de vista de segurança, ou seja, as medidas de
segurança devem ser aplicadas até que se atinja o patamar desejado estabelecido no SL-T
Além dos cuidados diretos com o sistema de automação da subestação - SAS, será
necessário aplicar produtos e sistemas específicos de segurança cibernética. Os principais
são:
 Acesso Remoto (VPN): O acesso remoto é um recurso fundamental na gestão dos
sistemas de uma subestação digital. Mas é importante aplicar uma rede virtual
privada (VPN) que garante acesso seguro e criptografado, especialmente se o
acesso for advindo de uma infraestrutura de rede pública. Para acessos remotos
externos é importante considerar mecanismos com múltiplo fator de autenticação
(two-factor-authentication);
 Firewalls: É uma solução de segurança baseada em hardware ou software (mais

comum) que, a partir de um conjunto de regras ou instruções, analisa o tráfego de
rede para determinar quais operações de transmissão ou recepção de dados podem
ser executadas, bloqueando as não autorizadas;
105
 Controle de Acesso e Gerenciamento de Contas: Significa um sistema de gestão

centralizado, para autenticar contas de usuário, fazer mapeamento de funções de
usuário, a ter gestão e regras no momento de execução;
 Registro e Monitoramento: Realizar a coleta de log de equipamentos e

monitoramento das informações. Significa ter um SysLog Server, um SysLog Agent e
uma gestão centralizada dos eventos de segurança com um SIEM – Security
Information and Event Management., normalmente localizado no SOC (Security
Operation Center);
 Proteção contra malware: A proteção contra malware exige software que atua de
forma que pode ser categorizada de duas maneiras:
- Blacklisting (antivírus clássico);
- Whitelisting (lista de permissões de aplicativos).
 Hardening: O “endurecimento” garante produtos e soluções seguros, através de

configuração segura, reduzindo sua superfície de ataque. Por exemplo, isto é
alcançado por remoção de software desnecessário, nomes de usuário ou logins
desnecessários, desativação de portas e protocolos não utilizados ou fortalecimento
do HW / OS;
 Backup e restauração: O processo de backup e restauração garante que todo o

sistema possa ser restaurado após a exclusão ou corrupção acidental de dados,
falhas de hardware e danos às instalações devido a desastres naturais, incêndio ou
inundação. Significa a capacidade de recuperar-se de incidentes de segurança,
negação de serviço, surto de malware. O backup e a restauração são a base de um
plano de recuperação de desastre (DRP) que inclui:
- Aplicação: por exemplo, firmware e sistema operacional;
- Configuração: Telas de IHM, Lógica e configurações de controle e proteção,
configurações do switch / roteador;
- Tempo real: por exemplo, lista de eventos, medição, registros de falhas.
 Sistemas de Detecção: Existem basicamente dois tipos de sistemas para fazer a

detecção de invasões, fazendo o monitoramento em tempo real de todo o tráfego da
rede ethernet:
- Sistema de Detecção de Intrusões (IDS - Intrusion Detection System);
- Sistemas de Prevenção de Intrusões (IPS - Intrusion Prevention Systems).
Para sistemas de automação de subestações, recomenda-se um IDS baseado em rede para

fornecer proteção adicional, por exemplo contra malware, para a zona de automação da
subestação. Isso porque no caso de um “falso positivo” não existe o risco de interrupção de
serviços.
106
8.4 ESTRATÉGIAS DE MITIGAÇÃO DE RISCOS DE UMA SOLUÇÃO IEC 61850
Todos os aspectos abordados até aqui se referem a requisitos e estratégias necessárias

numa solução que utilize intensamente comunicação de dados numa rede ethernet. Elas
serão importantes especialmente para garantir a disponibilidade das mensagens envolvidas
na comunicação entre dispositivos.
Todos os requisitos não são necessários em todas as situações e os aplicáveis devem ser
qualificados (ou adaptados) para minimizar a degradação do desempenho funcional. Por
exemplo, a confidencialidade das mensagens de disparo de proteção na subestação
geralmente não é necessária, mas a integridade é fundamental.
Como já foi apresentado a norma IEC 61850 não detalha aspectos relacionados a
segurança cibernética. Mas estes aspectos são abordados na norma IEC 62351-6 - Power
systems management and associated information exchange – Data and Communication
Security – Part 6: Security for IEC 61850. Nela o foco é a prevenção da reprodução,
exigindo extensões de segurança de autenticação de mensagens para evitar violações e
assim garantir a integridade das mensagens.
O motivo de usar mecanismos de extensão é a necessidade de desempenho das
mensagens do nível de processo, GOOSE e Sampled Values que precisam ter sua
integridade assegurada, mas também o tempo garantido de tráfego na rede entre a origem e
destino.
O processamento da mensagem Sampled Values pelo cliente melhora a segurança
descartando as mensagens cujo carimbo de data/hora excede uma inclinação de dois
minutos. O cliente deve registrar e acompanhar a contagem de amostras recebidas
(smpCnt) para o IED de publicação. Se um valor menor para o número de sequência
(sqNum) for recebido e não houver rollover, a mensagem deverá ser descartada.
Com relação a extensões de segurança podemos por exemplo considerar um mecanismo
de autenticação em um sistema de automação de uma subestação em que se quer garantir
que a mensagem de mudança de status GOOSE emitida pelo nó lógico PDIS que é
recebido pelo nó lógico XCBR não tenha sido alterada. Assim, do ponto de vista da
cibersegurança, a integridade é necessária.
A mensagem GOOSE, juntamente com o hash e a assinatura digital (denominada resumo
da mensagem) é enviada do IED que contém o PDIS para o IED que contém o XCBR. O
IED de recebimento recalcula o hash sobre a mensagem recebida. Usando a chave pública
para descriptografia do RSA, o hash original é calculado. Se os dois corresponderem, a
mensagem GOOSE será autenticada. Se os dois não corresponderem, a mensagem
GOOSE não será validada.
107
Figura 118 – Proteção da integridade por autenticação
Com relação à confidencialidade a norma IEC 62351-6 recomenda que para aplicativos que
usam GOOSE e Sampled Values e exigem tempos de resposta de 4 ms, configurações de
multicast e baixa sobrecarga da CPU, a criptografia não é recomendada. Em vez disso, o
processo de seleção do caminho de comunicação deve estar restrito a uma VLAN especifica
da subestação, especialmente no barramento de processo, o que fornece confidencialidade
às trocas de informações em termos de segurança das informações em trânsito. Estes
aspectos devem estar definidos no projeto da rede de comunicação, envolvendo o nível de
Station Level e Process Level.
Numa solução IEC 61850 a aplicação de ferramentas em todos os processos envolvidos é
fundamental. Eles ajudam a melhorar a segurança do sistema porque consolida a correta
aplicação do projeto, a possibilidade de monitoramento e certificação da solução. As
ferramentas necessárias são:
 Ferramentas de configuração: Executam a configuração do sistema, seja de todo o
sistema, de um IED individual ou de certos componentes do sistema. As ferramentas
de configuração típicas são o System Configurator e o IED Configurator;
 Ferramentas de teste: Fornecem facilidades para realizar testes, como simulação
de condições e injeção de sinais. Em um sistema IEC 61850, os tipos de ferramentas
nesta categoria são o Station Bus Simulator e o Process Bus Simulator;
 Ferramentas de coleta de dados: Realizam operações de coleta de dados na rede.
Além disso, eles fornecem coleta permanente ou temporária, local ou remota, para
recuperação automática de registros de falhas internas, status e medições, relatórios
e outros dados disponíveis dos IEDs, bem como coleta de dados brutos para análise
de pacotes;
 Ferramentas de segurança: Usadas para configurar e testar os recursos de
segurança cibernética implementados no sistema. Embora importantes, eles não
estão afetando especificamente ou são afetados pela IEC 61850;
 Ferramentas de comissionamento: Geralmente são combinações de recursos de
outras ferramentas, como ferramentas de configuração e teste, e, como tal, qualquer
impacto nos sistemas IEC 61850 já é considerado.
108
Figura 119 – Ferramentas de um sistema IEC 61850
Deve se avaliar o impacto que as medidas de segurança cibernética têm sobre as

ferramentas aplicadas, considerando se continuam a executar suas funções ou se exigem
novos recursos para lidar com os requisitos adicionais dos mecanismos de segurança. Os
principais aspectos a considerar são:
 Impacto funcional: O comportamento, configuração, usabilidade, aplicação e
eficácia da ferramenta estão comprometidos;
 Impacto no gerenciamento: Licenciamento, patches, atualizações, distribuição, IP,
documentação e outras áreas que não fazem parte da funcionalidade real da
ferramenta são afetados;
 Impacto de aprimoramento: A ferramenta precisa de novos recursos para
configurar, gerenciar, controlar, testar, codificar, decodificar e fazer interface com os
sistemas.
Uma ferramenta será categorizada com impacto de gerenciamento se algum aspecto da

ferramenta que não é funcional for impactado. Um bom exemplo seria o gerenciamento de
chaves de criptografia que uma ferramenta pode precisar ter para se comunicar com os
outros componentes da IEC 61850 no sistema. O gerenciamento das chaves de criptografia
da ferramenta seria um novo fator em seu ciclo de vida. Pode também ser necessária uma
funcionalidade adicional para permitir a configuração da criptografia. Essa será uma
categoria de Impacto de aprimoramento.
109
Figura 120 – Ferramentas de Segurança Requisitos Fundamentais e Efeitos (FRs x Effect)
É importante considerar que as próprias ferramentas são vulneráveis a ataques. Uma

ferramenta nada mais é do que outra aplicação seja para configuração, monitoramento ou
teste. Como tal, deve ser resiliente a ataques cibernéticos, para que não seja comprometido
ou usado para fornecer um mecanismo para que os invasores cibernéticos obtenham
acesso à rede.
A exploração de vulnerabilidades em um recurso contido em um aplicativo é um método
comum. Isso implica que qualquer ferramenta deve atender aos mesmos critérios que
qualquer outro aplicativo com reconhecimento de segurança, como:
 Uma ferramenta deve ser projetada e implementada usando diretrizes de segurança
cibernética que ajudam a evitar a criação acidental de vulnerabilidades na própria
ferramenta;
 As ferramentas devem poder ser atualizadas com as práticas de segurança mais
recentes;
 As ferramentas precisam ser resilientes às funções passivas, como as verificações
de portas, que geralmente são uma abertura a um ataque real, mas não elas
mesmas um ataque (ser robusto contra testes difusos);
 O teste de ferramentas deve incluir testes de segurança cibernética, bem como
quaisquer testes funcionais e outros realizados pelo fornecedor ou desenvolvedor
(Pentest).
Portanto, o desenvolvimento de software requer qualidade e confiabilidade, ou seja, adotar a

premissa de segurança no design durante o desenvolvimento da solução, considerando
também a segurança física do ambiente critico em questão como uma necessidade
essencial adicional.
Outro aspecto importante é a gestão da segurança cibernética. Gerenciamento de
segurança é o conjunto de processos para identificação dos ativos de informações de uma
organização e a implementação de políticas, padrões e procedimentos para garantir seu uso
de maneira segura.
As arquiteturas IEC 61850 apresentam alguns desafios exclusivos de gerenciamento de
segurança para gerenciamento de políticas, gerenciamento de riscos, monitoramento e
auditoria e resposta a incidentes.
110
As redes e sistemas IEC 61850 devem abordar os seguintes problemas de gerenciamento:

 Proteção contra acesso não autorizado por pessoas, atos ou influências; criar, excluir
e controlar serviços e mecanismos de segurança; distribuir informações relevantes à
segurança ou material de codificação criptográfica; e autorizar o acesso, direitos e
privilégios do assinante;
 Estabelecer um conjunto de processos usados para garantir relatórios oportunos de
eventos relevantes à segurança, avaliando a exposição ao risco da subestação e
identificando quais ativos essenciais devem ser protegidos; definição de métodos e
ferramentas para reduzir o risco e um nível aceitável; e projetar planos para mitigar
os riscos de segurança para garantir uma operação confiável do sistema de energia,
fornecendo uma resposta rápida, estruturada e determinística aos incidentes de
segurança. O maior desafio, neste caso, é diferenciar entre um evento induzido por
segurança cibernética e um evento operacional normal;
 Estabelecer, manter e medir a eficácia da conscientização sobre segurança,
incluindo responsabilidade pessoal. Essas métricas quantitativas devem identificar as
medidas necessárias para monitorar e gerenciar a eficácia da segurança implantada
nos sistemas IEC 61850.
Um plano de gestão de incidentes inicia-se na identificação de riscos e ameaças, seguido de

um plano de ação com medidas de contorno e mitigação. O próximo nível seria um processo
e uso de tecnologias adequadas para ter visibilidade e conseguir identificar ameaças,
reagindo a tempo através de um SOC (Security Operation Center).
Esse tema já é bem evoluído no mundo de TI, mas ainda há muito que se discutir para
adaptar e criar políticas que façam sentido no mundo de operação de TA, que tem muitas
particularidades e uma operação com requisitos extremamente rigorosos.
Apesar de ainda não existir regulamentação vigente no Brasil que dite os requisitos mínimos
de segurança cibernética no setor elétrico, as empresas entendem a criticidade do tema e
os possíveis danos e impactos (muitas vezes irreparáveis) que podem ser ocasionados por
um incidente cibernético.
A situação atual é preocupante, pois o nível de maturidade das instalações críticas de
energia com relação à segurança cibernética ainda é muito baixo.
A boa notícia é que existe um movimento no Brasil de conscientização sobre o tema através
de alguns grupos de trabalho e disseminação do assunto em congressos do setor e
iniciativas para que sejam incluídos requisitos mínimos de segurança cibernética nos sub-
módulos de rede do ONS.
Os controles necessários para gerir a segurança cibernética são classificados como
administrativos, físicos ou técnicos, aplicáveis às instalações e operações da IEC 61850.
Alguns exemplos são:
 Gerenciamento de configuração e gerenciamento de patches para minimizar riscos
administrativos;
 Supervisão por vídeo, portas trancadas e locais restritos para minimizar riscos
físicos;
 Firewalls, software de verificação de vírus, controle de senha para minimizar riscos
técnicos.
Porém, deve se estar atento a um equilíbrio nos mecanismos utilizados. Pesquisas

mostraram que controles excessivos de segurança de gerenciamento podem ser
contraproducentes, resultando em menos segurança e não mais.
111
8.5 DESENVOLVIMENTOS E ASPECTOS ESTRATÉGICOS
Os sistemas de automação de subestação têm um desenvolvimento tecnológico constante.

As ameaças cibernéticas também evoluem constantemente, exigindo que haja um
desenvolvimento continuo dos sistemas de segurança cibernética.
 Ferramentas e métodos de avaliação de riscos e vulnerabilidades: A avaliação
deve apoiar o gerenciamento de riscos, considerando desde uma pessoa apenas
bem como a governança de toda a infraestrutura, incluindo todos os aspectos
interdivisões da empresa;
 Arquiteturas e tecnologias de controle: Devido à sua complexidade, a mudança

completa de arquiteturas existentes de controle para sistemas de energia não é
adequada, de modo que a pesquisa e o desenvolvimento devem se concentrar em
sua atualização;
 Consciência e governança de risco na sociedade: Uma cultura geral de

conscientização de risco terá que permear a dimensão humana, organizacional e
social da infraestrutura de energia, abrangendo todos os aspectos dos sistemas.
O desenvolvimento futuro também deve se concentrar na criação de ferramentas e métodos

educacionais que não apenas conscientizem os engenheiros de energia dos riscos e
vulnerabilidades de segurança das tecnologias da informação e comunicação, mas também
de como essas vulnerabilidades interagem com a rede elétrica e o que pode ser feito para
prevenir e mitigar riscos.
O desenvolvimento de sistemas de segurança cibernética deve também evoluir para atingir
o melhor custo-benefício. Neste sentido:
 Orientação clara para os fornecedores de sistemas IEC 61850 para
implementação de métricas de segurança: Definições práticas de métricas de
segurança com base nos dados que a maioria dos engenheiros de proteção e
automação já estão coletando. Isso tornará mais fácil, rápido e barato implementar
um programa de métricas de segurança que ofereça suporte à tomada de decisões
eficaz. Além disso, essas métricas fornecem um meio de comunicar o desempenho
da segurança e podem ser usadas para orientar a alocação de recursos, identificar
práticas recomendadas, melhorar a eficácia do gerenciamento de riscos e
demonstrar conformidade;
 Definir uma estrutura de métrica de segurança para produtos e serviços IEC

61850: Um conjunto claro de requisitos de dados e definições de métricas baseadas
em consenso permitirá que os fornecedores da IEC 61850 incorporem e aprimorem
com eficiência seus produtos de segurança com métricas;
 Padrões comuns para compartilhamento de dados e benchmarking

significativos: As medidas de métricas de segurança serão usadas para calcular
uma referência uniformemente significativa entre parceiros de negócios e agências
reguladoras. Uma estrutura de métrica de segurança compartilhada e a capacidade
de rastrear e comparar resultados padronizarão os relatórios de incidentes, levando
à identificação de melhores práticas e melhorias nas práticas gerais de segurança
cibernética.
112
Um aspecto importante a avaliar é se o custo e os testes de segurança a serem aplicados

são acessíveis. O lado positivo neste sentido é que os sistemas IEC 61850 aplicam uma
segurança em profundidade, portanto, a defesa pode ser alcançada passo a passo em
camadas sobrepostas (proteção do SO, detecção de negação de serviço, gerenciamento de
patches, antivírus, autenticação de aplicativos, controle de acesso baseado em funções,
etc.).
Por outro lado o retorno do investimento é muito difícil de estimar. O custo para implementar
a segurança em um projeto específico é relativamente fácil de identificar. No entanto, além
desses custos, existem custos operacionais e significativos em andamento, principalmente
os necessários para uma comunicação segura fora da subestação. Por exemplo, o
gerenciamento de patches é um esforço de custo de manutenção particularmente alto e os
benefícios são duvidosos. Como a frequência e a gravidade dos ataques cibernéticos são
desconhecidas ou não estão bem definidos, os benefícios são difíceis de quantificar.
Mas por outro lado a segurança traz alguns benefícios que são mensuráveis. Um benefício
mensurável indireto é o resultado da implementação de mecanismos de segurança de
qualidade. Por exemplo, a implantação de um controle de acesso verdadeiramente seguro
com fortes mecanismos de controle de uso reduzirá o risco de definir incorretamente
parâmetros de proteção de missão crítica nos IEDs. Os usos tradicionais de senhas (às
vezes três níveis de senhas) gerenciados pelo IED dificilmente o protegem. Uma empresa
de energia precisa gerenciar vários milhares de IEDs, o que resulta na maioria das senhas
sendo as mesmas ou similares e conhecidas por todos e sem rastreamento das alterações
no IED.
A segurança cibernética deve ser encarada como um seguro. Um ataque bem sucedido
pode causar prejuízos imensos. Portanto, deve ser mandatória, regulamentada e, sobretudo,
fiscalizada.
Na Figura 121 é apresentado o uso atual e planejado das medidas de segurança da
subestação nas empresas de energia da América do Norte.
Figura 121 – Uso atual e planejado das medidas de segurança da subestação
113
Por último, é importante definir o papel de responsabilidades na segurança cibernética

envolvidas numa implementação IEC 61850. Claramente, a empresa de energia deve
projetar e declarar os requisitos de segurança como parte de suas especificações técnicas.
E é de responsabilidade do fornecedor (fabricante do sistema ou integrador) implementar as
funcionalidades de segurança que podem ser ativadas quando o sistema IEC 61850 é
testado e comissionado.
A segurança de um sistema de proteção e automação de subestação IEC 61850 é
principalmente de responsabilidade da concessionária, com o possível suporte dos
fabricantes e integradores de sistemas para fornecer informações sobre a arquitetura e a
capacidade do sistema e dos produtos que o compõe.
114
9. MANUTENÇÃO E PROCESSOS DE VALIDAÇÃO EM

SISTEMAS OPERANDO COM A NORMA IEC 61850
9.1 VISÃO GERAL
O crescente desenvolvimento das soluções de proteção de subestações, automação e

sistemas de controle baseadas na norma IEC 61850 vem demonstrado os benefícios desta
comunicação na indústria. Cada vez mais, equipamentos vêm sendo desenvolvidos e
registrados no UCA International User Group, como Merging Units. A grande maioria dos
fabricantes de IEDs possui em seu portfólio de produtos soluções baseado na IEC 61850,
inclusive com a interface de barramento de processo IEC 61850-9-2 LE, explorada no
próximo capítulo.
Dessa forma, com esta maturidade tecnológica, aumento de confiabilidade na IEC 61850,
tem-se uma transição natural para o próximo estágio de aceitação da norma: subestações
totalmente digitais. Tendo em vista este cenário, três questões básicas podem ser
levantadas:
 O que estamos fazendo?
 Porque estamos fazendo?
 Como estamos fazendo?
A primeira pergunta pode ser respondida pela apresentação deste capítulo do trabalho,
baseado nas diretrizes da IEC 61850, seus requisitos, pesquisas de mercado, e no
entendimento dos membros deste grupo de trabalho.
Para a segunda pergunta pode-se considerar que também está no foco deste capítulo, que
é o teste funcional, ou seja, pode-se auxiliar a indústria da energia elétrica descrevendo em
detalhes os métodos e ferramentas necessárias para a realização dos testes funcionais de
uma subestação completamente digitalizada, em qualquer nível de seu ciclo de vida.
Para responder a terceira pergunta aqui proposta, este capítulo apresentará inicialmente a
descrição dos testes relacionados com a IEC 61850 edição 2.0, assim como métodos de
teste e ferramentas para diferentes tipos de teste.
Por fim, os testes descritos neste capítulo compreendem um importante papel na
confiabilidade e segurança do sistema elétrico.
9.2 DEFINIÇÕES DE TESTES
Algumas definições de testes importantes:
 Testes de Aceitação em Fábrica (TAF): Testes funcionais do sistema

especialmente fabricado, ou suas partes, utilizando os parâmetros especificados e
acordados pelo cliente para a aplicação planejada, realizado em fábrica;
 Testes de Aceitação em Campo (TAC): Os testes de aceitação em campo

consistem na verificação de cada ponto e controle de dados, e sua correta
funcionalidade, dentro do sistema de proteção de automação de subestações e seu
ambiente operacional em geral, em toda a instalação;
115
 Testes de Comissionamento: O teste de comissionamento é executado em campo,

quando a instalação estiver completa. São executados para garantir a segurança e
confiabilidade da operação do sistema com a interface da subestação associada. O
comissionamento é uma operação global desde a instalação até a energização, que
inclui, também, o teste de novas partes e peças (extensões) do SPACs existente;
 Teste de Conformidade: De acordo com a IEC 61850, o teste de conformidade é a

verificação se os fluxos de dados nos canais de comunicação estão de acordo com
as condições determinadas na referida norma sobre organização de acesso,
formatos e sequencia de bits, sincronização de tempos, temporização, formato do
sinal e nível, reação aos erros;
 Testes de Certificação: Este tipo de teste é designado para verificar se um IED ou

um esquema está de acordo com os requisitos do cliente. Pode incluir um TAF
específico se for solicitado pelo cliente;
 Teste Ponta a Ponta: Teste executado nas fronteiras entre os processos e os

SPACs. Normalmente, o estágio final de um TAF e TAC são testes Ponta a Ponta;
 Testes de Interoperabilidade: Estes tipos de testes são aplicados a um conjunto de

IEDs do mesmo fabricante ou de diferentes fabricantes. Devem demonstrar que os
IEDs sob teste, quando interconectados por um sistema de comunicação adequado,
podem operar juntos, compartilhando informações e desempenhando suas funções
individuais de maneira segura, com nível de desempenho especificado. Os testes de
Interoperabilidade devem ser realizados com a aceitação do cliente durante os testes
de conformidade, homologação e TAF.
9.3 CONTROLE DE FLUXO DE DADOS EM SUBESTAÇÕES DIGITAIS
A norma IEC 61850-5 define três protocolos de comunicação de dados exclusivos. São eles:
 IEC 61850-9-2 Sampled Values sobre Ethernet-based network;
 IEC 61850-8-1 GOOSE;
 IEC 61850-8-1 MMS baseado Cliente Servidor.
O entendimento desta arquitetura de comunicação é essencial para o correto teste do SAS.

Por se tratar de um sistema complexo e versátil, é necessário considerar a metodologia de
fluxo de dados e definir a estratégia de teste.
Como definido na IEC 61850-7-1, um exemplo da arquitetura do fluxo de dados de uma
subestação pode ser:
116
Figura 122 – Exemplo de uma arquitetura de SAS [1-Part 7-1]
Onde:
(1): Troca de dados baseado na IEC 61850-9-2 Sampled Value;
(2): Troca de dados rápida de I/O para proteção e controle;
(3): IEC 61850-8-1 GOOSE;
(4): Configuração e Engenharia;
(5): IEC 61850-8-1 MMS baseado em cliente / servidor – Monitoramento e Supervisão;
(6): IEC 61850-8-1 MMS baseado em cliente / servidor – Comunicação Centro de Controle;
(7): IEC 61850-9-3 (IEEE 1588) Sincronização de tempo.
Nos capítulos anteriores, já foi bastante discutido a confiabilidade (mensagem chega onde
deve chegar) e desempenho (com o tempo adequado).
É importante destacar que confiabilidade e desempenho, em redes de comunicação de
subestações, devem ser balanceados entre eles.
O uso de protocolos como o RSTP, PRP, HSR, também já discutidos e demostrados,
garante a confiabilidade das redes de comunicação.
Métodos de controle de fluxo, também já discutidos, que podem ser destacados são a
utilização de VLAN e filtros MAC.
Considerando todos os protocolos, filtros, controles de fluxos de dados aqui listados, é
importante salientar que um teste de uma subestação totalmente digital deve prever os
protocolos e filtros para a execução do teste.
Por exemplo, em seu modo mais básico, o teste deverá criar entradas simuladas a uma
função ou dispositivo para verificar sua operação e expectativa de desempenho
considerando os resultados do teste e redes de comunicação. Em uma subestação digital,
isso é feito considerando nós lógicos e dispositivos lógicos, passando pela simulação pela
rede de comunicação. Para isto, é necessário que o sistema de teste publique mensagens
baseadas nas definições do arquivo SCD descritivo da subestação.
117
9.3.1 VLAN
Os protocolos de comunicação GOOSE e SV devem ser configurados em VLANs

específicas, e assim limitados a partes de uma rede de comunicação. Um Dispositivo 1 e um
Dispositivo 2 comunicam-se entre si através de uma VLAN. Um equipamento de teste
designado para esses Dispositivos 1 e 2 deve criar mensagens de dados para a mesma
VLAN dos Dispositivos 1 e 2, assim, deve ser conectado na mesma VLAN de 1 e 2.
Essa configuração deve ser prevista na execução dos testes, conforme a figura abaixo.
Ainda, a norma IEEE 802.1Q define o uso do GVRP (GARP VLAN Registration Protocol) ou
MVRP (Multiple VLAN Registration Procotol) através do IEEE 802.1ak podendo expandir
dinamicamente através de portas trunk, também demonstradas na imagem abaixo.
Figura 123 – VLAN e equipamentos de teste
9.3.2 Testes com RSTP, PRP e HSR
O protocolo RSTP determina automaticamente a melhor rota da mensagem. Em caso de

falha, uma nova rota é desenvolvida. Para o teste utilizando-se RSTP, deve ser previsto
uma conexão simples para o equipamento de teste na topologia de teste.
Já com a utilização do protocolo PRP, o equipamento de teste pode ser conectado como um
SAN – mais simples - ou como um DANP (Capítulo 5 deste documento), de acordo com o
esquemático a seguir:
118
Figura 124 – PRP e Equipamento de Teste
Já considerando o protocolo de HSR, como definido no Capítulo 5, somente pode ser

testado considerando o DANH (Dual Attached Node HSR), ou um RedBox, de acordo com o
esquemático abaixo:
Figura 125 – HSR e Equipamento de Teste
9.4 CARACTERÍSTICAS DOS TESTES EM IEC 61850
Funções do SAS não são executadas isoladamente em cada Nó Lógico, e sim

implementadas de acordo a uma interação de múltiplos Nós Lógicos, cada um contribuindo
com sua funcionalidade específica.
Tendo em vista uma operação normal, o fluxo de dados é definido pelo esquema de
comunicação, e isto exige uma interface de usuário para execução do teste antes
previamente definido, evitando assim reações inadequadas.
Desconectar um equipamento sob teste não é a maneira correta de se executar o teste em
uma subestação digital, especialmente quando este dispositivo pode ser requisitado para
outras funções. Assim, outras formas de isolamento devem ser utilizadas para execução do
teste, que serão descritas a seguir.
119
Todas as relações de comunicação são descritas nos arquivos SCD, porém, nem todas são
mandatórias. Assim, nem todos os IEDs possuem tais funcionalidades.
9.4.1 Modo Simulation
No nível do IED, há a opção do dado Sim.stVal do Nó Lógico LPHD ser ajustado como
TRUE ou FALSE. Esse ajuste permite ao IED selecionar que os sinais multicast sejam
processados, assim:
 Se LPHD.Sim.stVal = TRUE e existe um sinal GOOSE e/ou SV com o bit de
simulação = TRUE na rede = Esse sinal será processado. O mesmo sinal GOOSE
e/ou SV com bit de simulação = FALSE não será processado;
 Se LPHD.Sim.stVal = FALSE e existe um sinal GOOSE e/ou SV com bit de
simulação= TRUE na rede = Esse sinal não será processado.
Assim, para se processar um sinal de simulação, é obrigatório:
 Ajustar LPHD.Sim.stVal = TRUE;
 Ajustar bit de simulação do GOOSE / SV = TRUE.
Figura 126 – Dado usado para Simulation – IEC 61850-7-1
9.4.2 Mode e Behavior de Funções
Na IEC 61850, cada função pode adotar um de cinco diferentes modos funcionais - Mod:
 on: Função está operativa, toda comunicação está em serviço;
 blocked: Somente pode ser usada por funções que possui interação direta com o
processo, por exemplo, saídas através de contatos que podem ser bloqueadas de
alteração por um período de tempo. Toda comunicação permanece em serviço;
 Test: Não deve ter impacto na comunicação, no entanto, uma função em “test” deve
ser operativa mas indicar uma condição de teste, reagindo somente a um comando
com uma indicação de teste (de uma IHM, telecomando, por exemplo);
 Test/bloqued: Similar ao “blocked”, adicionado à indicação de teste;
 off: Essa opção desabilita a função.
120
O behavior de uma função, ou comportamento, é controlado juntando o seu superior

hierárquico com o seu modo controlável. Assim, devem-se seguir os níveis hierárquicos de
Mod, onde off tem prioridade sobre test que tem prioridade sobre on.
Figura 127 – Tabela de prioridades de Mod [1-Part 7-4]
Ainda, para o propósito de teste, Mod pode ser ajustado para test, permitindo assim o
“processamento como válido” considerando um indicador de teste = TRUE e q.test = TRUE.
Figura 128 – Modes de Nós Lógicos – IEC 61850-7-1
121
9.4.3 Processando Atributos de Dados de Entrada
As mensagens de entrada podem ser processadas de acordo com as classificações:

 As valid: Todas as mensagens com indicação de teste TRUE (quando em mod =
test) ou FALSE (quando em mod = on), com assumido com q.quality = GOOD;
 As invalid: Mensagens quando em Mod = on e Test = TRUE, e com indicação de
medição errada, por exemplo;
 As questionable: Quando o processamento de valores mostra uma inconsistência
nos resultados;
 Not processed: Dados não processados por conta da função ajustada em off.
Figura 129 – Dispositivo Lógico recebendo atributos de qualidade heterogêneos
9.4.4 Bloqueio de Informações
As saídas e/ou as entradas físicas das funções podem ser bloqueadas, dado a necessidade,
utilizando-se para isso a função “blocked” ou “test/blocked” diretamente no bloco de controle
“CmdBlk”. Assim, desabilitam-se as saídas/entradas da função em referência, diretamente
no nó logico.
Figura 130 – Dado usado para bloqueio do nó logico de entrada/saída - IEC 61850-7-1
122
9.4.5 InRef
O método de entrada de sinais de cada nó lógico pode ser alterado entre sinais de processo
para outras funções e, também, sinais de testes de funções dedicadas, definido através do
objeto InRef demonstrado na figura abaixo. Ele não depende do Behavior ou Mode, e os
dados são publicados de acordo com o Behavior.
Figura 131 – Exemplo de entrada de dado usado para teste com InRef - IEC 61850-7-1
9.5 REQUISITOS PARA FERRAMENTAS DE TESTE
As ferramentas de teste devem incluir todos os requisitos para execução dos testes TAF e
TAC, promovendo condições de verificação de todas as entradas e saídas de equipamentos
primários, comunicação com o centro de controle e funções individuais de IEDs. Deve,
portanto, executar os testes nas três categorias:
 Simulação convencional de processo;
 Simulação de processo transitório e de faltas;
 Verificação de comunicação e simulações.
Equipamentos mais complexos devem ser capazes de simular reações de disjuntores em

tempo real. Deve também ser capaz de gerar grande quantidade de tráfego de dados em
um curto período de tempo ou dado intermitente, além de aplicar tensões e correntes
transitórias em um sistema trifásico, simulando várias faltas, saturação automática de
transformadores de corrente, entre outros.
Os equipamentos de testes ainda devem ser utilizados para realizar testes em links internos
de sistemas de automação e telecomunicação, considerando:
 Simulação de um servidor, simulação de um cliente, monitoramento do tráfego de
dados;
 Análise de qualidade de tráfego de dados (por exemplo, qualidade do sinal elétrico,
tempo de transporte de mensagem, jitter, latência, etc.).
123
Especificamente para subestações digitais baseadas na IEC 61850, os requisitos para os

equipamentos de teste são:
 Deve ser compatível com a IEC 61850 edição 2.0;
 Deve possibilitar ser utilizada como IEC 61850 cliente;
 Deve ser configurável de acordo com os arquivos SCL da IEC 61850;
 Deve ser capaz de operar em Mod.Sim = FALSE e Mod.Sim=TRUE;
 Deve permitir configuração individual dos atributos de qualidade;
 Deve ser capaz de verificar o Test bit nos atributos de qualidade;
 Deve ser capaz de sincronizar por PTP (IEEE 1588), incluindo a possibilidade o
usuário de escolha entre GLOBAL, LOCAL, NOT SYNCHRONIZED;
 Deve ser capaz de simular ou causar perdas/alteração de SV / GOOSE;
 Deve ser capaz de analisar a desempenho do sistema e gerar um relatório dos
resultados;
 Deve ser capaz de testar as funcionalidades de cliente/servidor;
 Deve ser capaz de gerar testes automáticos baseados no sistema, podendo incluir as
funcionalidades de troca de ajustes, habilitar/desabilitar elementos funcionais quando
necessário.
O sistema de teste pode ser dividido em hardware e software.

O hardware pode ser alocado unicamente no sistema, com também pode ser alocado de
forma distribuída em diversos hardwares necessários para o teste, como as imagens abaixo.
Figura 132 – Equipamento de teste único na arquitetura de teste
Figura 133 – Equipamento de teste distribuído na arquitetura de teste
124
O hardware de teste compreende:

 Computadores;
 Equipamento de teste, com interfaces de comunicação, entradas binárias, interfaces
analógicas de baixo nível, interfaces secundárias (1 ou 5 A, 100 V ou correspondente
MU), valores primários ou pseudo valores primários (testes de NCIT);
 Amplificadores de valores analógicos;
 Equipamentos de comunicação – Roteadores e Switches;
 Antenas GPS e receptores;
 Relógios.
Já os softwares são responsáveis por desempenharem as funções:

 Simulação de condição normal e anormal como definido;
 Controle e monitoramento dos modos de teste;
 Monitoramento do desempenho dos Dispositivos sob Teste;
 Documentação.
Os softwares podem ser:

 Embarcados nos equipamentos em teste;
 Aplicações em computadores;
 Aplicações em nuvem.
Durante o teste, o status dos IEDs deve ser monitorado. Normalmente, existem 3 maneiras
de se executar este monitoramento: blocos de reports, GOOSE e MMS. Assim, a ferramenta
de teste deve ser capaz de executar este monitoramento em tempo real, através de um
MMS Browser, ou da criação de um dataset para teste, escrita de um report control block ou
GOOSE control block.
9.5.1 Características Requeridas para testes Remotos
Considerando testes remotos de subestações, é recomendável a utilização de um script de

teste previamente determinado. Geralmente, esta solução é utilizada após alguma
manutenção pontual ou atuação pontual na subestação.
Esta possibilidade deve estar prevista no plano de manutenção, arquivos de teste e ter
operadores qualificados para executar.
9.6 MONITORAMENTO
Subestações digitais podem e devem ser continuamente monitoradas para determinar a

validade dos dados, a saúde de sua instrumentação e sua telemetria. A utilização de
estimadores de estado, inclusive, é de grande valia para determinar e implementar
processos de manutenção baseada na condição.
Para exercer a função de monitoramento, o sistema SCADA deve estar preparado para as
novas funções descritas na Seção 9.4, como qualidade de mensagem, SIM e BEH, entre
outros.
É necessário implementar o monitoramento de operação de todos os IEDs da subestação.
Mensagens transmitidas na rede devem ser monitoradas online a fim de detectar perda de
sinais e intrusões. Este monitoramento fornece o estado de diferentes IEDs e sistemas de
125
controle. Existem ferramentas comerciais para o monitoramento online de todos os tipos de

mensagens, como ACSI, MMS, GOOS, SV, SNMP, etc.
Em qualquer tempo, o operador da subestação deve ser capaz de ter os indicadores de:
 Quais partes do sistema primário estão disponíveis e em serviço;
 Quais os estados dos componentes do sistema primário;
 Quais as partes do sistema primário são estão disponíveis e:
o Estão em teste;
o Estão afetados por testes de outros componentes do SAS.
 Quais os estados dos diferentes elementos do SAS (IEDs, switches, Merging Units,
etc.).
A visualização do resultado do monitoramento pode ser:

 Menus
 Lista de alarmes
 Logs
 Vistas de IHMs dedicadas
Abaixo, um exemplo de um software de monitoramento de protocolo de comunicação

dedicado a IEC 61850.
Figura 134 – Software de Monitoramento IEC 61850
126
9.7 PROCESSO DE TESTES
Uma subestação totalmente digital é um SPACS complexo onde o IED interage com
sistemas primários e processa aplicações locais e distribuídas e suas funções. Essas
funções são baseadas nas trocas de informações entre o barramento de processo e
barramento de estação.
Por sistemas, entende-se:
 Sistema lógico de dados;
 Sistema físico de dados.
Por funções, entende-se uma atividade básica do sistema de proteção e automação,

incluindo a comunicação.
Assim, os testes que podem ser feitos são:
 Teste de sistemas de comunicação;
 Teste de interface de comunicação;
 Testes funcionais;
 Teste da interface lógica de cada função (LN);
 Teste do IED;
 Teste do subsistema;
 Teste do sistema completo.
Dessa forma, deve-se ter uma definição muito clara e consistente dos cenários de teste,
tendo em vista condições realísticas no plano de teste. Teste de um sistema, ou subsistema,
a fim de avaliar sua conformidade com seus requisitos. Isto pode incluir testar parte do SAS
em operação.
Essa definição deve incluir:
 Contexto da aplicação;
 Função ou sistema sob teste;
 Componentes do sistema e seus ajustes;
 Passos do teste (procedimento de teste) incluindo isolação, se aplicável;
 Resultados esperados.
É possível indicar um procedimento genérico de teste, da seguinte forma:

1. Carregar o devido cenário de teste no sistema de teste;
2. Conectar o equipamento de teste e equipamentos de gravação (se necessário);
3. Se requisitado: Troca de funções ou bloqueio, entradas e saídas do SPACS;
4. Ajustar a função a ser testada no modo correto;
5. Ajustar LPHD.Sim do equipamento de teste;
6. Executar o teste;
7. Retornar o LPHD.Sim para o valor antes do teste;
8. Retornar os ajustes da função / bloqueio para o pré-teste;
9. Retirar os bloqueios;
10. Desconectar o equipamento de teste e gravação;
11. Analisar os resultados de teste.
127
9.7.1 Metodologias de Teste
Métodos de testes funcionais podem ser divididos em diversas categorias, onde devem ser
levados em consideração os diferentes níveis de complexidade, funções de monitoramento,
utilização de sistemas de redundância, propósito do teste: Aceitação, comissionamento de
componente ou sistema, manutenção, entre outros.
Essas informações ajudarão a definir o melhor método de teste a ser utilizado.
Podem-se destacar, aqui, quatro metodologias:
 Caixa Preta: Esta metodologia é utilizada quando não se tem o interesse em saber o
comportamento interno do dispositivo sob teste, e sim somente suas entradas e
saídas. É bastante utilizado no conceito de testes sistêmicos, onde não há interesse
nas funções específicas, e sim no comportamento de todo o seu sistema de proteção
e automação de subestações e suas interações.
Figura 135 – Caixa Preta
 Caixa Branca: Já nesta metodologia de teste, há o interesse em saber exatamente o

comportamento de uma determinada ou de todas as funções internas do dispositivo
sob teste. Trata-se de um teste mais detalhado, e por consequência, mais demorado.
Figura 136 – Caixa Branca
128
 Top-Down: Modelo amplamente utilizado em SPACS, especialmente durante o TAC,

pois se assume que todos os componentes individuais já foram testados e validados.
Assim, o método de teste Top-Down avalia o sistema como um todo, iniciando da
função mais generalista. Se falhar, reduz-se o nível dos testes até encontrar a
origem da falha.
Figura 137 – Metodologia de Teste Top-Down
 Bottow-Up: Esta metodologia é mais utilizada por fabricante de IEDs e durante os

testes de aceitação, pois se inicia em um determinado elemento ou função do IED,
passando-se por vários níveis até chegar ao sistema completo. Exige-se, com isso,
um maior número de testes.
 Positivo e Negativo: Testes positivos são obtidos quando o testador confronta o

resultado do teste dado uma entrada esperada, ou seja, uma condição normal. Já o
teste negativo deve ser obtido quando o testador confronta o resultado do teste dado
uma entrada inesperada no sistema, ou seja uma condição anormal.
9.7.2 Configuração do SAS e Sistemas de Teste
Com este novo cenário de subestação totalmente digital, é importante ratificar que o sistema
de teste deve ser previsto no projeto, principalmente no projeto de comunicação de
subestações (SCL), com IP FIXO e tratamento de segurança cibernética.
A configuração dos switches também deve permitir o roteamento de mensagens para o
equipamento de teste, com portas temporariamente disponíveis para tal finalidade (testes).
Caso o conceito de “lista branca” seja aplicado, deve ser previsto o equipamento de teste
evitando, assim, alarmes falsos devido à utilização deste instrumento. Ainda, operações nos
nós lógicos LN e LD em Modo de Teste e Modo de Simulação do IED devem ser previstas,
evitando assim o bloqueio destes comandos.
129
9.7.3 Visualização dos Testes na IHM
Enquanto os testes são executados, é essencial que o operador seja informado do status do
sistema primário. Assim, deve ser previsto na IHM o recebimento dos dados em modo SIM
e/ou modo TEST, e devidamente tratados.
O operador deve ter a correta informação, se dados simulados ou reais, de fácil
entendimento. Ainda, os alarmes devem ser removidos do SCADA, em uma situação de
recebimento de mensagens modo SIM e/ou TEST. É indicado que se utilize alterações de
cor em ocasiões de falhas de comunicação, e uma cor diferente em situações de modo SIM.
9.7.4 Documentação do Teste
A documentação associada aos testes de validação deve apresentar:

 Objeto de teste;
 Propósito do teste;
 Escopo do teste.
Em caso de teste de manutenção, deve-se também apresentar o diagrama unifilar da

subestação.
O primeiro documento criado deve descrever o plano de teste, contendo os tipos de teste e
os casos de teste para os objetos específicos de teste da subestação. Após a sua execução,
o documento deve incluir todos os resultados de todos os testes selecionados pelo usuário.
Esta documentação pode ser dividida em duas áreas:
1. Documento do Teste de Interface de Processo
Neste, todas as entradas e saídas, assim como os pontos de interligação de software

da instalação, são listados. Deve incluir:
 Entradas analógicas de medições / sincronização / proteção, etc.;

 Equipamentos de alarmes (SF6 de disjuntor, por exemplo);
 Comportamento dos elementos da rede de comunicação;
 Sincronização de tempo.
Este conteúdo pode ser gerado de um SCD.
2. Documento da Função
Neste, deve ser desenvolvido o documento baseado na função requisitada pelo

usuário, descrevendo todas as funções e pontos que são disponíveis, assim como
suas interfaces. Deve incluir, para cada função:
 Configuração (Modo, Pontos do software de engenharia);

 Ajustes;
 Tolerâncias;
 Casos de testes (por exemplo para função de distância: característica, zona
de carga, oscilação de potência);
 Desempenho durante o teste para todas as funções testadas.
130
9.7.5 Teste do SAS e seus componentes
O primeiro passo para o teste do SAS durante o TAF ou até mesmo em pré-TAF é verificar
se todas as suas interfaces de comunicação correspondem às definições do arquivo SCD
definido. Isto inclui data set e control block para os serviços implementados.
Já o teste do SAS no estado nominal deve ser entendido como um teste ponta a ponta em
TAF ou TAC convencional, com fronteira no SAS, e pode ser feito com a injeção de
Sampled Values. Porém, também se recomenda a injeção analógica primária no
transformador de instrumentos não convencional – NCIT, para a verificação de cabeamento.
Este tipo de teste deve ser feito em Testes de Certificação, TAF e TAC.
Outro processo de teste que pode ser discutido é o teste da cadeia completa de função.
Neste caso, adiciona-se ao teste acima descrito a injeção analógica na MU, tendo a
possibilidade de visualização dos sinais também no centro de controle. Pode-se inclusive
argumentar sobre a real necessidade deste teste, fato este que cabe ao cliente a decisão de
sua necessidade.
Também se pode ter o teste do sistema completo de proteção associado ao NCIT, onde se
devem aplicar correntes e tensões nominais primárias, e de falta com valores primários.
Este tipo de teste é um problema para ser executado por limitações técnicas, porém em TAF
é possível que seja executado. Pode ser considerado que se trata de testes sobrepostos,
onde também cabe ao cliente a decisão final.
O teste de funções isoladas é de grande valia, pois se pode testar realizando a injeção de
valores SV e a leitura de valores GOOSE. Nesta metodologia, a ideia é testar somente uma
função específica do SAS, por exemplo, função de distância, não interferindo em outras
funcionalidades do sistema. No entanto, deve-se ter atenção quando se aplica este conceito
em IEDs com funções distribuídas. Para isso, o procedimento correto a ser adotado é:
 Verificar se a função está isolada;
 Verificar se a injeção de SV não irá impactar nas operações do IED;
 Verificar se colocar a função em Test Mode, o IED continuará em modo ON.
Esta possibilidade de teste deve fazer parte do TAF.
9.7.6 Impactos nos processos de Teste
Em subestações digitais, os termos de topologia lógica “barramento de processo” e

“barramento de estação” são utilizados. Dependendo da aplicação, podem ser combinados
na mesma rede. Se separados, a largura de banda de 100 Mbps pode ser suficiente para o
barramento de estação. No entanto, para o barramento de processo a largura de banda
recomendável é 1 Gbps, pois há a necessidade de maior disponibilidade de rede na
presença de Sampled Values.
Desta forma, o carregamento de rede deve ser verificado, inclusive com injeção de fluxos de
SV durante o TAF e TAC confirmando o correto funcionamento da rede de comunicação.
Também, os protocolos de redundância de rede têm impactos nos processos de rede, e
devem ser verificados. O PRP e HSR devem apresentar tempo de reconfiguração próximo
de zero, já o RSTP pode ter um tempo de reconfiguração de rede significativo (centenas de
milissegundos).
Para este teste, um fluxo de SV pode ser interrompido propositalmente, medindo-se assim o
tempo de reconfiguração de rede através de ferramentas específicas para tal finalidade. É
possível que se efetue a medição do tempo com dois computadores, com precisão mínima
de 4 ms.
131
9.7.7 Simulação de Perdas e Alteração de Mensagens
Por fim, para o processo de teste de subestações digitais, deve ser possível simular perdas
e alterações de mensagens, de acordo com:
 Atraso de mensagens durante um sobrecarregamento de rede;
 Mensagem fora de sequência;
 Perda de mensagem;
 Perda de um IED;
 Perda de um link ou switch;
 Chegada de mensagens duplicadas.
Esses casos requerem o uso de diferentes métodos de simulação de condições associadas.
9.8 CASOS DE USO
O trabalho apresentado pelo TB 760, WB B5.53, apresenta uma grande variedade de casos
de uso de como testar um sistema IEC 61850 e seus componentes, detalhadamente, que
podem ser consultados..
9.9 TIPOS DE TESTE
Neste tópico, serão descritos os diferentes tipos de teste executados em um SAS, quais as
topologias e tecnologia a serem aplicadas.
9.9.1 Teste de Tipo e Conformidade
Os testes de Tipo e Conformidade são, em geral, realizados pelos fabricantes dos

elementos, mas também podem ser requisitados pelo usuário quando sua funcionalidade for
estendida, ou até mesmo pelo integrador do sistema quando parte de uma solução
apresentada.
Deve ser utilizada uma topologia Bottom-Up, com a inclusão de testes positivos e testes
negativos para:
 Perda de dados;
 Jitter;
 Recebimento de dados com atributos de qualidade não nominal.
Devem ser realizados testes de distúrbios em redes de comunicação. Esses testes devem
incluir testes funcionais ajustadas ao IED, controle do Disjuntor e Merging Unit.
132
Figura 138 – Sistema de teste de carregamento de rede do controlador de disjuntor e

Merging Unit
9.9.2 Teste de Distúrbios em Redes de Comunicação
Existem dois tipos testes de distúrbios de redes para carregamento:

 Packet Storm: Quando o HSR é utilizado, dados errados injetados em outra rede
podem causar a perda de comunicação. Se existe uma falha no hardware de
comunicação, o IED pode enviar mensagens com falhas. Este tipo de teste é
importante para lidar com ataques.
 Avalanche Messages: Aumento da repetição de mensagens causando a sobrecarga
da rede.
De acordo com o IEC TC 57 WG10, o tempo de reconfiguração de rede é de 400 ms para o

barramento de estação e de 0 ms para o barramento de processo.
O teste pode ser realizado considerando um hardware inserido na rede de comunicação,
tendo a capacidade de interromper a comunicação através de uma chave eletrônica, como
demonstrado na imagem abaixo.
Figura 139 – Equipamento de teste habilitando a interrupção do link de comunicação
9.9.3 TAF – Testes de Aceitação em Fábrica
Para o TAF, deve-se usar a topologia Top-down baseado no plano de teste incluindo os
cenários de teste definidos no projeto do sistema, podendo ser utilizada a metodologia caixa
preta até que nenhuma falha específica ocorra.
Caso tenha alguma falha e deseja-se investigar, utiliza-se a metodologia caixa branca.
Como neste tipo de teste nem todos os componentes estão disponíveis, muitas vezes deve
ser necessário simular alguns componentes do SAS para sua efetivação.
133
Para o carregamento de rede durante o TAF, devem ser considerados os testes:

 Tráfego em condições de comunicação normal;
 Tráfego em condições de máxima carga.
9.9.4 TAC – Testes de Aceitação em Campo
Já o TAC deve ser preferencialmente executado baseado no sistema, e não nos

componentes funcionais do IED, incluindo a capacidade de comunicação dos elementos do
SAS. São recomendados testes ponta a ponta nesta etapa, considerando assim uma
topologia Top-Down, podendo ser utilizada a metodologia caixa preta até que nenhuma
falha específica ocorra.
Caso tenha alguma falha e deseja-se investigar, utiliza-se a metodologia caixa branca.
É importante destacar que, diferentemente do TAF, no TAC todos os equipamentos estão
disponíveis, tendo a possibilidade de verificação da real interação entre todos os elementos
do SAS.
Este teste deve ser baseado no SCD da subestação.
9.9.5 Manutenção após Comissionamento
Este tipo de teste é requisitado quando o IED não é totalmente monitorado, tanto suas
entradas e saídas quanto suas funções de comunicação.
Bastante utilizado para ensaios periódicos, podem ser executados em funções isoladas do
SAS.
Não há requisitos de periodicidade definido na norma IEC 61850 para este tipo de teste.
9.9.6 Requisitos de Testes Após Mudanças Funcionais
Após mudanças funcionais, sejam em nível de hardware (manutenção ou atualização) ou

firmware (atualização), é necessário que sejam executados os testes funcionais nas
unidades afetadas, e suas respectivas unidades de comunicação.
A metodologia a ser utilizada pode ser tanto Top-Down quanto Bottom-Up, dependendo da
fronteira do SAS que se deseja alcançar.
9.10 CENÁRIOS DE TESTES
Alguns cenários de testes possíveis são propostos a seguir.
9.10.1 Trabalhando com Mensagens GOOSE e SV de um sistema de teste e processo
Como indicado anteriormente, os testes podem ser executados na cadeia funcional

completa do SAS em operação. Isso significa que o fluxo de SV e outras informações,
usados como entradas das funções podem ser publicados pelo sistema de teste enquanto a
MU publica o mesmo dado do processo ao sistema de proteção e automação, tendo sua
134
operação garantida adequadamente. Isto implica na necessidade da publicação de fluxo de

SV, para o teste, considerando o bit de simulação ajustado para TRUE.
Esta sistemática, atualmente (IEC 61850 edições 2.0 e 2.1), possui as seguintes limitações:
 Somente o IEC completo pode ser colocado em modo de simulação. Assim, não é
possível testar funções isoladas desta forma;
 Não é permitida a publicação de 2 fluxos de SV ou GOOSE com cabeçalhos
idênticos que possuem diferentes valores, por exemplo, q.test.
9.10.2 Teste da cadeia completa de funções com diferentes possibilidades de configurações
É possível a utilização de diferentes configurações de teste para realizar a completa

avaliação de toda a cadeia de funções. Assim:
 Testes convencionais: Utilização de Simuladores de tempo real, amplificadores e
injeção de sinais analógicos no SAS;
 SAMU + IEC 61850-9-2: Utilização de simuladores de tempo real, amplificadores,
conformador SAMU para IEC 61850-9-2 SV e injeção de sinais do SAS, com retorno
por IEC 61850-8-1 GOOSE;
 Somente IEC 61850: Utilização de simuladores de tempo real com geração de sinais
IEC 61850-9-2 SV e IEC 61850-8-1 GOOSE, injeção de sinais do SAS, com retorno
por IEC 61850-8-1 GOOSE;
 NCIT/MU: Utilização de simuladores de tempo real, amplificadores com injeção de
valores analógicos no NCIT e conformação na MU, geração de sinais IEC 61850-9-2
SV no SAS e retorno por IEC 61850-8-1 GOOSE.
Figura 140 – Possíveis configurações de testes para hardware em loop fechado baseado em
interface analógica e barramento de processo
135
9.10.3 Testes de Funções distribuídas
Funções são desempenhadas por IEDs (dispositivos físicos). No entanto, todas as funções
consideradas consistem em trocas de dados entre nós lógicos. Esses nós lógicos podem ser
alocados em diferentes dispositivos físicos.
Figura 141 – Livre alocação de funções [1-Part 5]
Da mesma forma, os testes podem ser realizados considerando a livre alocação de

equipamentos em testes, ou equipamentos em testes distribuídos. Por exemplo, quando se
deseja executar o teste de diferencial de barras em uma subestação com SAMU alocados
em cada disjuntor, cada equipamento de teste deve ser alocado individualmente a uma
distância um do outro, sendo necessária a correta sincronização entre eles.
Figura 142 – Teste distribuído da função diferencial de barras
Esta abordagem pode ser utilizada para diferentes propósitos de teste, quando aplicável,
sendo eles aceitação, TAF, TAC, comissionamento e manutenção.
136
9.10.4 Isolamento Funcional
O isolamento funcional é requerido quando se deseja testar qualquer elemento de proteção

e controle em uma subestação energizada onde se pode injetar tensão e corrente, assim
como sinais binários e monitorar as saídas dos equipamentos.
Em subestações convencionais, o isolamento é realizado utilizando-se chaves de teste.
Porém nos casos de subestações digitais, este isolamento deve ser feito usando as
funcionalidades de simulação e teste de acordo com a IEC 61850-5, já descritos neste
capítulo.
O nível de isolamento depende da filosofia do teste. Podem ser considerados:
 Isolamento de um elemento funcional para teste;
 Isolamento de uma sub-função ou função para teste;
 Isolamento de um completo IED para teste;
 Isolamento de um grupo de elementos, funções ou IEDs para testes ou funções
distribuídas.
9.10.5 Testes Remotos
Caso o teste seja executado remotamente, existe um impacto nas ferramentas de teste e na
infraestrutura necessária. As ferramentas devem ser instaladas em campo e possuírem
acesso remoto, além da empresa estar preparada para tal atividade. Por razões práticas,
este tipo de teste deve ser limitado a testes simples em fase de manutenção ou
comissionamento.
9.10.6 Testes de Manutenção
Em geral, testes de manutenção são executados em subestações energizadas para realizar

o diagnóstico, identificar problemas ou confirmar que alguma ação que foi realizada, como
alteração de ajuste, atualização ou reparo de um equipamento do SAS. Uma condição
mestre para definir quais os requisitos deste tipo de teste é saber qual o motivo do teste.
Assim, os testes incluídos aqui dependem do seu elemento motivador.
Alguns motivadores para os testes de manutenção:
 Falha em operação: Ocorre quando um IED falha em operar quando deveria;
 Operação indesejada: Ocorre quando um IED opera em uma condição não desejada;
 Alteração de ajuste: Qualquer modificação de ajuste de IED, seja em sua proteção
ou comunicação, deve ser verificado e testado;
 Substituição: Quando um elemento físico for substituído, devem ser executados
testes de modo a verificar sua eficácia operacional no SAS;
 Gestão de Atualização: Qualquer modificação ou atualização nos elementos
funcionais do SAS devem ser testados após esta atividade, mitigando os riscos
operacionais.
137
9.11 FERRAMENTAS DE MERCADO
Existem diversas ferramentas no mercado capazes de realizar os testes de validação e

manutenção de sistemas operando com IEC 61850, apresentados neste capítulo. Cada
ferramenta possui suas particularidades, especificidades e características únicas, e cabe ao
usuário definir qual será de sua escolha.
Dessa forma, destaca-se que são necessárias ferramentas para:
 Injeção primária analógica em NCITs e leitura em SV;
 Injeção secundária analógica em MU;
 Simulação de SV;
 Simulação e Subscrição de GOOSE;
 Sincronização de tempo IEEE 1588;
 Monitoramento de redes de comunicação MMS, cliente servidor;
 Monitoramento de GOOSE e SV;
 Simulação de IEDs para manutenção;
 Funcionalidades Mod.Test e Mod.Sim;
 Injeção de fluxos de mensagem com perda de mensagem / fora de sequência;
 Medição de tempos de transporte de mensagem;
 Duplicação de mensagens;
 Medição de carregamento de rede;
 Elaboração de planos de teste;
 Elaboração de relatórios para documentação.
Seguem uma arquitetura de exemplo de testes, descritas neste capítulo.
Figura 143 – Exemplo de Ferramentas de Mercado
138
Figura 144 – Exemplo de Ferramentas de Mercado
Ratifica-se que não se trata de uma recomendação de ferramentas, mas somente uma nota
de que essas ferramentas existem, são comerciais e estão disponíveis no mercado.
9.12 CONSIDERAÇÕES FINAIS
Em um SAS, são de vital importância os testes de redes de comunicação, protocolos de

comunicação e protocolos de reconfiguração, além dos switches integrados às redes.
O monitoramento das redes de comunicação e de todo o sistema de automação de
subestações é parte integrante que pode ser utilizado para redução da manutenção,
utilizando-se de processos inteligentes de manutenção centrada na confiabilidade.
Ainda, os arquivos de configuração de subestações SCD baseados na IEC 61850 devem
ser utilizados para configuração dos procedimentos de testes e documentação. O
conhecimento do IED, suas funções, mapeamento e hierarquia de comunicação são de
fundamental importância para o sucesso nos procedimentos de teste, que devem ser
condizentes com o sistema.
A utilização dos recursos trazidos pela norma IEC 61850, em sua versão 2.0 e 2.1, auxilia
na tarefa de execução e preparação do teste, porém deve-se atentar para todo o
procedimento envolvido, seguindo-o estritamente evitando assim erros.
Por fim, o treinamento do profissional envolvido para esta nova tecnologia de subestação
totalmente digital é a chave para o sucesso de implementação, manutenção e validação do
processo IEC 61850.
139
10. BARRAMENTO DE PROCESSO – IEC 61850-9-2
10.1 VISÃO GERAL
A norma IEC 61850-9-2, como um padrão internacional de automação de subestação,

propõe uma rede de comunicação de barramento de processo entre equipamentos no nível
do pátio e os dispositivos eletrônicos inteligentes (IEDs), no nível do bay, usados para
proteção e controle de sistemas de energia. É um padrão de comunicação que define a
base para instalações de barramento de processo, descrevendo a troca de representação
digital de valores analógicos em um formato digital padronizado, conhecido como Sampled
Measure Values, SMV ou SV. Ele especifica o uso do link digital entre os relés de proteção,
controladores e medidores que estão ao nível de bay com os transformadores de corrente
(TC) e Transformadores de tensão (TP) que estão no nível de processo.
O barramento de processo, que por definição constitui um segmento de rede isolado (físico
ou lógico), também é utilizado para transportar mensagens GOOSE entre os equipamentos
de aquisição e os que implementam a funcionalidade de monitoramento, proteção e controle
em uma subestação digital.
Figura 145 - Subestação Digital
As mensagens GOOSE constituem uma classe de mensagens rápidas utilizadas para a

troca de sinais de comando entre IEDs que, anteriormente, eram transmitidos por conexões
a fio e sinais elétricos analógicos (por exemplo, sinal de contato de alarme de um relé).
Estes comandos são utilizados na implementação das diversas lógicas de controle e
proteção, tais como: função de proteção de falha de disjuntor, esquema de transferência de
barramentos, lógica de religamento de disjuntores, intertravamentos, dentre outras. Os
diversos dispositivos compartilham as informações digitais, para executarem as funções de
proteção e controle distribuídas, através da rede Ethernet.
O barramento de processo constitui, então, uma arquitetura de entradas e saídas (E/S) para
proteção, controle, monitoramento e medição, a qual permite a substituição da fiação de
cobre no pátio da subestação por comunicações padronizadas baseadas em fibra óptica,
substituindo os sinais analógicos e binários por mensagens Ethernet, habilitando desta
forma o uso de comunicação digital entre dispositivos.
140
10.2 DESCRIÇÃO FUNCIONAL
No nível do processo, é feita a aquisição de dados analógicos utilizando-se transformadores

de instrumentação, cujas saídas são amostradas, convertidas em uma representação digital
e formatadas para transmissão através da rede local (Process Bus Local Area Network).
Observa-se que o barramento de processo também é usado como meio de comunicação
para o controle dos equipamentos de manobra de alta tensão, como disjuntores, unidades
de controle de disjuntores, chaves seccionadoras, etc.
Figura 146 - Sistemas de automação e controle de subestações [1]
Na implementação do barramento de processo, todos os módulos de E/S binários e os de

conversão análogo-digital são instalados no pátio da subestação, próximos às fontes
primárias de sinal.
Essa conversão local tem muitas vantagens, sendo uma delas o aumento da confiabilidade
dos sistemas de proteção e automação em termos de transmissão de dados,
disponibilizando-os para todo o sistema. Assim como, também, a redução do custo total do
SAS em termos de limitação da utilização dos fios de cobre, substituindo a conexão por fios
metálicos por interfaces lógicas.
Os sinais analógicos dos transformadores de instrumentação convencionais, corrente (TC) e
tensão (TP), são digitalizados pelas Merging Units (MUs). MU refere-se a dispositivos
eletrônicos habilitados para rede que se conectam a transformadores de instrumentação no
pátio da subestação, realiza localmente a conversão analógica para digital (ADC), o
processamento digital de sinais (DSP) e transmitem, no barramento de processo, os pacotes
de valores amostrados, conforme definido pela IEC 61850-9-2, Figura 147.
141
Figura 147 – Diagrama funcional da MU
A MU compreende os nós lógicos TVTR (transformador de tensão) e TCTR (transformador

de corrente) constituindo uma interface que concentra as várias informações analógicas,
como tensões e correntes de fase.
Figura 148 – Barramento de Processo
Transformadores convencionais de corrente (TC) e tensão (TP) com fios de cobre estão em
uso há muito tempo, mas atualmente, estão sendo substituídos por NCIT -Non Conventional
Instrument Transformers (Transformadores de Instrumentação Não Convencionais), com
várias opções disponíveis para se medir correntes e tensões CA. NCITs, como os
transformadores ópticos de corrente (OCT), os TCs da Rogowski Coil, os TPs eletrônicos de
potência, começaram a ganhar popularidade.
Os OCTs funcionam com o princípio do efeito de Faraday - a corrente que flui através de um
condutor induz um campo magnético que afeta a propagação da luz que viaja através de
uma fibra óptica que circunda este condutor. A OCT é colocada em torno do condutor com
corrente primária e um sinal de saída correspondente à corrente primária é produzido
conforme IEC 61850 9-2LE.
Os desafios mais importantes para os OCTs são, por um lado, a publicação direta dos
valores amostrados, sem a necessidade de elementos intermediários (MU) entre a medição
e seus usuários (proteções e medidores) e, por outro lado, o uso de sensores ópticos para
realizar as medições. As implicações e melhorias desses dois fatos são numerosas, além
das do uso do barramento de processo. Eles são vantajosos em relação aos TCs
convencionais por várias razões, incluindo uma melhor resposta na faixa de frequência
(ampla faixa linear), menor peso etc.
142
Com a tecnologia óptica, a necessidade de distinguir entre enrolamentos com classe de

precisão de medição ou proteção desaparece, uma vez que a classe de exatidão de
medição permanece (ou melhora) em toda a faixa dinâmica do sensor. Os valores
amostrados publicados pelo sensor podem ser usados por muitos "clientes",
independentemente da faixa dinâmica da aplicação. As necessidades futuras não serão
limitadas pela disponibilidade de enrolamentos de medição adicionais, uma vez que um
sensor é capaz de satisfazer todas as necessidades atuais e futuras de medição.
10.3 ASPECTOS DA COMUNICAÇÃO NO BARRAMENTO
Sejam quais forem as origens, os sinais analógicos convertidos em pacotes Ethernet (SV)
são disponibilizados, via multicast e modo publisher-subscriber, aos IEDs de proteção e
controle, localizados no nível de bay, através da rede Ethernet de comunicação local. Esta
troca de dados com os equipamentos no barramento de processo é proporcionada por meio
das interfaces lógicas indicadas com os números 4 e 5, na Figura 149.
Figura 149 - Modelo de Sistema de Proteção Distribuído [1-Part 5]
Da Figura 149, pode-se observar que, considerando as suas funcionalidades, a arquitetura

de uma subestação, apesar de ser dividida em três níveis: estação, bay e processo, são
altamente interconectados, com base em várias interfaces lógicas.
Embora a IEC 61850-9-2 descreva mapeamentos de protocolo específicos, ela não inclui
modelos de dados, conjuntos de dados, taxas de amostragem ou taxas de transmissão.
Informações, estas, necessárias para uma implementação de barramento de processo
realmente interoperável.
Buscando um entendimento comum para esses parâmetros, uma especificação de
implementação interoperável, a “Diretriz de Implementação para a Interface Digital para
Transformadores de Instrumentação Utilizando IEC 61850 9-2” foi publicada pelo UCA
International Users Group. Esse perfil da IEC 61850-9-2 é conhecido como IEC 61850-9-
2LE (Light Edition). Duas das principais exigências integradas pela IEC 61850-9-2LE foram
o formato de telegrama das SV e a sua taxa de amostragem.
143
Os telegramas SV compatíveis com IEC 61850-9-2LE incluem tensões e correntes de todas

as fases de um sistema trifásico e suas componentes de sequência zero, Figura 6. A
combinação de tensões e correntes em um único fluxo de dados SMV é vantajosa,
especialmente para funções de proteção.
Figura 150 – Barramento de processo conforme IEC 61850-9-2LE
A taxa de amostragem das MUs IEC 61850-9-2LE é especificada, para aplicações de

proteção, como 80 amostras por ciclo, resultando que, nos sistemas 50/60 Hz, são gerados
4000/4800 telegramas por segundo, por cada MU instalada. E, para aplicações de medição
e qualidade de energia, a taxa de amostragem é de 256 amostras por ciclo, 12800/15360
telegramas por segundo.
Desta forma, o uso de valores amostrados cria um tráfego de natureza contínua, com
elevada carga de informações, o que torna a largura de banda e velocidade da rede local
parâmetros fundamentais a serem considerados ao se projetar uma rede de barramento de
processo.
A confiabilidade e a funcionalidade adequada das MUs também devem ser objetos de
atenção, pois as mesmas passam a desempenhar um papel fundamental no SAS, uma vez
que medições incorretas, atrasos e falhas podem levar à atuação incorreta de IEDs de
proteção e controle, o que pode acarretar sérios danos à equipamentos e à integridade do
sistema elétrico de potência.
No contexto de rede de comunicação, as partes 8 (IEC 61850-8) e 9 (IEC 61850-9) da
norma especificam a tecnologia de comunicação Ethernet, com base no modelo OSI (Open
System Interconnection), para o barramento de estação e de processo no SAS. A tecnologia
Ethernet foi adotada como uma solução de comunicação apropriada, para uso na
automação de subestações de energia, com base em sua alta flexibilidade, largura de banda
e velocidade.
Nesta abordagem, a principal ideia por trás da norma IEC 61850 foi que o modelo de dados
e os serviços correlacionados fossem separados da pilha de camadas OSI de comunicação,
oferecendo, desta forma, a oportunidade de se implementar o estado da arte das
tecnologias de comunicação. As principais tecnologias são os esquemas de comunicação
que foram usados para o modelo de referência OSI.
O modelo de referência OSI (ISO/IEC 7498-1) define um modelo baseado no conceito de
camadas de funções de comunicação. São definidas 7 camadas e os seus requisitos
funcionais, de modo a se obter um sistema de comunicação extremamente robusto.
144
A pilha OSI é baseada no conceito de funcionalidade de comunicação por camadas,

consistindo em sete camadas. As camadas um e dois são as camadas física e de link
Ethernet, as camadas três e quatro compreendem a camada de rede IP e de transporte
TCP/UDP e as camadas cinco a sete compreendem as camadas seção, apresentação e
aplicação. Os modelos de objetos IEC 61850 são mapeados em diferentes camadas em
termos de serviços e requisitos. O modelo de objeto MMS baseado nos serviços de
cliente/servidor é mapeado para as camadas cinco a sete, enquanto as mensagens de alta
velocidade críticas de tempo, como SV e GOOSE, são mapeadas diretamente na camada
de link Ethernet, conforme IEC 61850-8-1, Figura 151.
Figura 151 – Mapeamento de Mensagens IEC 61850 nas camadas OSI
Uma vez que, pela IEC 61850, todos os IEDs são descritos de um modo padronizado, torna-
se possível que todos compartilhem dados por meio de uma estrutura idêntica relacionada
às suas funções, além de permitir que estes IEDs apresentem comportamentos idênticos.
Dentro desta abordagem e também pela perspectiva do comportamento da rede, o ACSI -
Abstract Communication Service Interface fornece a especificação para o modelo básico, o
qual define os modelos de informação específicos da subestação. A especificação do
conjunto de modelos de serviço de troca de informações e as respostas a esses serviços
também faz parte do seu escopo. O uso desta técnica de abstração permite separar o
aplicativo SAS, dos protocolos de comunicação e dos sistemas operacionais adotados,
Figura 152.
Figura 152 – Conceito do ACSI
145
Dentro do conceito ACSI, com base no modelo de serviço de troca de informações, a

abstração pode ser definida a partir da maneira como os dispositivos podem compartilhar as
informações em termos de definição, concentrando-se em aspectos da finalidade dos
serviços, em vez de se descrever como os serviços são construídos. (IEC 61850-7-2 2003).
Em uma implementação real, o modelo básico de informações e o modelo de serviços são
mapeados em uma pilha de comunicação existente, através dos esquemas de mapeamento
fornecidos pelo SCSM – Specific Communication Service Mapping. Na IEC 61850, são
especificados dois esquemas de mapeamento: (IEC 61850-9-1 2003) para a transmissão do
SV e (IEC 61850-8-1 2003) para a transmissão de eventos de estação e demais serviços de
comunicação.
Através do ACSI, também são fornecidas as interfaces abstratas que descrevem
comunicações entre cliente e servidor, para uso por aplicativos em tempo real, assim como
as comunicações entre aplicativos em um dispositivo como editor e em muitos aplicativos
em vários dispositivos como assinantes, para distribuições rápidas e confiáveis de eventos
em todo o SAS, como GOOSE, (GSEs) e SV, Figura 153.
Figura 153 - Esquema de Publisher e Subscriber em barramento de processo
Observa-se que as interfaces nos diversos níveis da subestação são criadas pelo sistema
de comunicação, com um papel fundamental na troca de informações e nas funções,
podendo ser considerado como elo de união entre os vários níveis da subestação. Desta
forma, o desempenho, a confiabilidade, a velocidade e as funções suportadas dos sistemas
podem ser determinados e definidos por suas redes de comunicação.
Dentre os vários tipos de mensagens em um SAS, as mensagens GOOSE com difusão
seletiva são mensagens críticas de alta velocidade e alta prioridade que devem ser
transferidas para o destino final com uma latência (transfer time) de menos de 4 ms, Figura
154.
Figura 154 - Tempo Total de Transferência [1-Part-5]
146
O tempo de transferência de uma mensagem, deve ser contabilizado como o somatório do

tempo necessário para encapsular os dados na pilha de protocolos antes de serem enviados
pela interface de rede (intervalo ta), do tempo de processamento de todo e qualquer
dispositivo que se encontra no barramento de rede, como switches, (intervalo tb), e do
tempo requerido pelo receptor para desencapsular, extrair e tratar os dados da pilha de
protocolos da mensagem recebida (intervalo tc).
Os requisitos de latência crítica das mensagens de alta velocidade, a quantidade de
informações transitadas assim como a disponibilidade e a confiabilidade do SAS, implicam
em maiores considerações quanto à topologia da rede local a ser adotada. O barramento de
processo e o barramento de estação transportam tipos diferentes de tráfego e apresentam
diferentes requisitos de desempenho.
10.4 CONSIDERAÇÕES SOBRE ARQUITETURA DE REDE
A confiabilidade do SAS está diretamente relacionada à confiabilidade de seus IEDs e suas

funções de proteção e automação. A norma IEC 61850, ao definir o conceito de função
distribuída de forma a permitir a alocação livre de funções por vários IEDs (IEC 61850-1),
faz com que as funções possam ser divididas em várias partes que serão executadas em
IEDs diversos. A implementação com êxito, da função atribuída, exige a comunicação
adequada entre estas partes funcionais distribuídas.
Adicionalmente, a IEC 61850 define uma restrição de confiabilidade: não deve existir
nenhum ponto único de falha que possa fazer com que todo o sistema entre em um estado
de falha. Este critério de confiabilidade pode ser abordado com redundância, de modo que
para se alcançar um alto grau de tolerância a falhas, deve-se garantir redundância nos
dispositivos e caminhos de comunicação em cada nível da subestação.
Esquemas de redundância são uma maneira de se aumentar a confiabilidade do SAS às
custas de maior complexidade do sistema em hardware e software, e também com maiores
custos. Na Figura 155 tem-se o exemplo de um esquema de redundância.
Figura 155 – Exemplo de arquitetura de uma subestação digital

Dentro do conceito de subestação digital com o IEC 61850, uma separação física entre os
barramentos de processo e de estação pode nem sempre ser possível devido a vários
fatores, sendo que nestes casos deve-se tomar cuidado ao se configurar o SAS de modo
147
que sempre haja uma separação lógica entre os dois barramentos e os diferentes tipos de
tráfegos. A segregação do tráfego é uma etapa importante para manter o desempenho
necessário e não sobrecarregar os dispositivos de rede. Os valores amostrados
provenientes da MU não devem inundar todas as portas de um switch Ethernet e devem
apenas ir para a porta em que o respectivo IED assinante desta informação está conectado.
Da mesma forma, os sinais GOOSE para o comando de trip do relé de proteção devem ser
encaminhados apenas para a porta em que a SCU assinante está conectada. Esta
separação lógica entre barramentos pode ser realizada definindo-se domínios (filtros)
multicast nas portas dos switches das LANs, ou implantando-se VLANs - Rede Local Virtual,
os quais dividem logicamente a rede conectada fisicamente e controlam o fluxo de dados
nos barramentos.
A Figura 156 mostra a aplicação de VLAN e da filtragem de endereços multicast para um
exemplo de subestação. Uma VLAN é alocada para o tráfego PTPv2 – sincronismo de
tempo, sem nenhuma filtragem de endereço multicast, pois os endereços são fixados pelo
próprio padrão. Duas VLANs GOOSE são atribuídas: uma para mensagens de trip de alta
prioridade (tipo 1A) e um para mensagens de mais baixa prioridade (tipo 1B), os quais são
definidos na seção 13.7 da IEC 61850-5. Nesta aplicação foi usada filtragem de endereço
multicast, pois geralmente é improvável que o número de mensagens exceda a capacidade
de processamento de um IED. No caso de se exceder a capacidade do IED, os filtros de
endereço multicast poderiam ser utilizados. Na última VLAN configurou-se o tráfego de
todas as mensagens SV, sendo a filtragem de endereços multicast utilizada para separar
bays e setores. Cada MU em um setor é colocada no mesmo grupo multicast, pois os IEDs
de proteção de alimentador ou de transformador requerem as medições de vários conjuntos
de TCs. Os alimentadores e os transformadores conectados, por disjuntores únicos, em um
arranjo de bay possuem um mesmo grupo multicast.
Figura 156 - Exemplo de uma configuração de VLANs e Multicast – Segregação de trafego
148
Em relação a disponibilidade do sistema de comunicação da subestação, a IEC 61850

especifica um esquema de redundância de rede baseado em dois protocolos
complementares, definidos na norma IEC 62439-3 e aplicáveis a subestações de qualquer
tamanho e topologia para o barramento da estação e também para o barramento do
processo:
 Protocolo de redundância paralela (PRP)
 Redundância contínua de alta disponibilidade (HSR)
Nos dois protocolos, cada nó possui duas portas Ethernet idêntico para uma conexão de
rede. Eles contam com a duplicação de todas as informações transmitidas e fornecem
tempo de chaveamento zero se os links ou switches falharem, atendendo a todos os
requisitos em tempo real da automação da subestação.
O PRP (IEC 62439-3, seção 4) especifica que cada dispositivo seja conectado em paralelo a
duas redes locais de topologia semelhante.
O HSR (IEC 62439-3, Cláusula 5) aplica o princípio do PRP a anéis e anéis de anéis para
obter redundância. Para esse efeito, cada dispositivo incorpora um elemento de switch que
encaminha quadros de porta a porta.
A IEC 62439 é aplicável a todas as redes Ethernet industriais, uma vez que considera
apenas métodos independentes de protocolo. Ele contempla dois métodos básicos para
aumentar a disponibilidade de redes de automação por meio de redundância:
 Redundância na rede: a rede oferece links e switches redundantes, mas os nós são
anexados individualmente aos switches por meio de links não redundantes. O ganho
na disponibilidade é pequeno, pois apenas parte da rede é redundante. A
redundância normalmente não está ativa e sua inserção custa um atraso de
recuperação. Um exemplo típico desse método é o protocolo de árvore de expansão
rápida (RSTP IEEE 802.1D). No entanto, o RSTP pode garantir apenas um tempo de
recuperação inferior a um segundo em uma topologia restrita. No entanto, o RSTP é
uma boa opção para o barramento da estação em sistemas não redundantes;
 Redundância nos nós: cada nó é conectado a duas redes redundantes diferentes,

de topologia arbitrária, por duas portas. Cada nó escolhe independentemente a rede
a ser usada. Este esquema suporta qualquer topologia de rede; as redes
redundantes podem até exibir uma estrutura diferente. A única parte não redundante
são os próprios nós.
Com relação ao PRP, a Cláusula 4 da IEC 62439-3 especifica redundância em dispositivos

nos quais os nós usam as duas redes simultaneamente. Isso oferece tempo de recuperação
zero, tornando o PRP adequado para todos os aplicativos em tempo real.
A Cláusula 5 da IEC 62439-3 define outra solução de redundância nos nós com HSR, na
qual um switch é integrado em cada dispositivo. O modo de operação é o mesmo que para o
PRP.
No PRP, cada nó é conectado a duas redes independentes operadas em paralelo. As redes
são completamente separadas para garantir a independência das falhas e podem ter
topologias diferentes. Ambas as redes operam em paralelo, proporcionando recuperação em
tempo zero e verificação contínua de redundância para se evitar falhas, Figura 157.
149
Figura 157 – PRP
O HSR aplica o princípio PRP de operação paralela a um único anel. Para cada mensagem
enviada, o nó (que possui um switch incorporado) envia dois quadros um para cada porta,
tratando as duas direções como duas LANs virtuais. Ambos os quadros circulam em
direções opostas sobre o anel e cada nó encaminha os quadros que recebe de uma porta
para a outra. Quando o nó de origem recebe um quadro enviado, ele o descarta para evitar
loops, Figura 158.
Figura 158 – HSR
Além da redundância de rede, outro recurso de rede indispensável para um sistema em

tempo real é a sincronização de tempo, a qual é resolvida pelo SNTP, com requisitos mais
rigorosos atendidos pela norma IEEE 1588.
A sincronização de tempo é crítica na arquitetura da Subestação Digital, especialmente
quando os valores das amostras a serem processadas por um determinado IED são
publicados por diferentes MUs. A sincronização de horário também é importante para a
marcação correta do horário dos eventos. Para isso, um servidor de horário baseado em
GPS é alocado para cada sistema primário e de backup. Todos os dispositivos em cada
sistema são sincronizados com o seu respectivo relógio de tempo. No caso de falha no
recebimento das amostras sincronizadas no tempo, o IED de proteção dispara um alarme e
bloqueia a sua função proteção. Outros dispositivos, como MUs e SCU, também têm os
meios para gerar um alarme quando a sincronização do tempo é perdida.
O tempo de transferência de mensagens entre o aplicativo de envio (por exemplo, função de
proteção que emite o disparo) e o aplicativo de recebimento (função do disjuntor que
executa a operação do disjuntor) é determinado pelos requisitos das funções que dependem
dessa transferência de mensagens.
Como o disparo de proteção é crítico em termos de tempo, o mesmo é alocado para a
classe de requisito de transferência mais exigente, 3 ms.
150
A transferência de amostras usando SVs também é atribuída a essa classe de requisito para
evitar, por exemplo, atrasos na detecção de falhas pela proteção. Os requisitos devem ser
cumpridos não apenas pelos IEDs, mas também pelo design do sistema de SAS.
Para analisar adequadamente a sequência de eventos no sistema de automação e para a
análise de falhas pós-evento, os eventos precisam de um registro de data e hora com
precisão de tempo de 1 ms. No entanto, a sincronização de tempo para amostras de
corrente e tensão, necessárias para proteção diferencial ou à distância, requer uma precisão
da ordem de 1 μs.
O nível de precisão de 1 ms pode ser alcançado usando o SNTP diretamente através de um
link de comunicação serial e a sincronização de tempo de 1 μs através do uso do padrão
IEEE 1588, sincronização de tempo de alta precisão, sobre Ethernet.
Os requisitos de tempo para o barramento de estação e do processo são distintos; eles
ditam como a redundância será usada. O tempo de recuperação da rede deve ser menor
que o tempo que a subestação tolera uma interrupção do sistema de automação.
Os tempos de recuperação compilados pelo Grupo de Trabalho 10 (GT10), do Comitê
Técnico da IEC 57 (TC57), estão mostrados na Figura 159.
Figura 159 – Tempos de recuperação
10.5 EXPERIÊNCIAS NA APLICAÇÃO DO BARRAMENTO DE PROCESSO
Na última década a aplicação do barramento de estação da norma IEC 61850 se tornou

uma realidade tecnológica nas novas instalações e modernizações do sistema elétrico de
potência no Brasil. Com maior ou menor sucesso, o cenário de uma supervisão de sinais
cablada, baseada em fios elétricos, foi sendo substituído pela aquisição de sinais virtuais
numa infraestrutura de rede.
Simultaneamente o barramento de processo foi evoluindo em aplicações no mundo e no
Brasil. Inicialmente o desenvolvimento de produtos capazes de alcançar os requisitos de
publicação, desempenho e disponibilidade num ambiente de pátio de subestação. Isto
significou principalmente soluções de dispositivos Merging Units que no pátio recebem
sinais analógicos e digitais publicando Sampled Values e GOOSE. Além disso, os
mecanismos de rede Ethernet para garantir redundância com PRP e HSR, e a adequação
de Switches e IEDs.
O processo iniciou por uma série de projetos pilotos com parcerias entre empresas de
energia e fornecedores de sistemas de proteção, automação e controle. Estas experiências
151
contribuíram significativamente para o desenvolvimento de soluções e a compreensão do

funcionamento e requisitos necessários para ter uma solução segura.
Neste sentido não apenas a eletrônica foi aprimorada, mas toda a infraestrutura e processo
de implantação, operação e manutenção foram amadurecidos. Alguns aspectos abordados
foram:
 Definição de requisitos para os armários de pátio que garantissem condições
adequadas de proteção mecânica, elétrica e de ventilação;
 Avaliação de desempenho da proteção em comparação com soluções tradicionais
cabladas;
 Considerações sobre a infraestrutura de rede Ethernet em termos construtivos e de
arquiteturas de rede;
 Definição de formas de documentação de sinais numa rede Ethernet e organização e
segmentação da rede física e lógica;
 Avaliação da disponibilidade do sistema, informações de pátio para os IEDs na sala
de controle;
 Definição dos requisitos de sincronismo de tempo, especialmente com aplicação do
PTP - IEEE 1588;
 Familiaridade com ferramentas de configuração e de monitoramento;
 Impacto nos procedimentos de projeto, operação e manutenção.
Estes projetos pilotos instalados em diversos países pelo mundo, inclusive no Brasil, com
maturidade de mais de 5 anos de instalação deu confiança para a implantação dos primeiros
projetos operacionais.
Os projetos de subestações totalmente digitais, chamadas de Full Digital, têm sido aplicados
por diferentes empresas, em diferentes países e em parceria com diferentes fornecedores, o
que mostra a maturidade da solução e a tendência tecnológica de aplicar a norma IEC
61850 de maneira plena nas soluções futuras.
Os desafios nestas implementações, algumas ainda a serem vencidas, têm sido:
 Vantagem econômica da solução considerando o custo inicial de uma tecnologia
emergente, o que ainda impacta nos produtos, na qualificação de equipes e na
modernização de procedimentos;
 Definição adequada de arquiteturas de rede que garantam desempenho,
disponibilidade e confiabilidade, e do projeto da rede Ethernet: VLANs, PRP, HSR;
 Garantia do serviço de sincronismo de tempo em todos os dispositivos no
desempenho necessário;
 Garantia de implementação dos recursos para testes de manutenção conforme
definido em norma, garantido isolamento de disparos indevidos e validação de
funcionalidades;
 Definição das ferramentas adequadas de cada equipe de acordo a sua
responsabilidade no processo de implantação, operação e manutenção.
Possivelmente nos próximos anos as empresas terão a confiança e o domínio para

adotarem soluções com aplicação do barramento de processo como padrão, especialmente
com a adequação da regulação (procedimentos de rede).
Nos últimos anos tem evoluído fortemente a tecnologia de Transformadores de
Instrumentação Não Convencionais (NCIT - Non Conventional Instrument Transformers)
baseados em tecnologia ótica, para leitura de valores de tensão e corrente publicadas
diretamente por TC e TP. Diversos projetos piloto estão em andamento pelo mundo, e a
consolidação desta tecnologia será um grande impulso para a aplicação do barramento de
processo. Apesar de a instrumentação ótica ser explorada há muito tempo, numa solução
convencional era necessária a conversão final em um sinal analógico, já que o sistema de
152
proteção e controle assim exigia o que diminuía as vantagens da tecnologia. Com a

aplicação da norma IEC 61850, que utiliza diretamente um sinal digital em protocolo de
comunicação, inúmeras vantagens serão possíveis.
No futuro outros equipamentos de pátio (transformadores, reatores, disjuntores, chaves
seccionadoras) irão incorporar dispositivos eletrônicos e publicar e receber sinais
diretamente do sistema de proteção, automação e controle levando à plena aplicação do
barramento de processo.
153
11. SISTEMAS SUPERVISÓRIOS E A NORMA IEC 61850
O controle e supervisão numa subestação de energia elétrica eram tradicionalmente feita

através de painéis onde existia o mímico da subestação com luzes de posição, chaves para
realizar comandos e anunciadores para mostrar alarmes. Bandeirolas mecânicas
sinalizavam atuações de proteção.
A digitalização dos sistemas de proteção, automação e controle impactou profundamente
esta interface, já que ela migrou para um ambiente computacional com Visores de Telas,
Alarmes, Sequência de Eventos, numa interface gráfica humano-maquina (IHM).
Os sistemas supervisórios, conhecidos com SCADA da sigla em inglês Supervisory Control
and Data Acquisition foram concebidos para poder realizar o controle do sistema de
potência a partir de Centros de Controle. A função dele era de supervisionar as condições
do sistema (medidas e estado de equipamentos) e realizar controle sobre os equipamentos
primários do sistema. O SCADA faz parte de um conjunto de softwares necessários para o
controle do sistema em tempo real, que numa visão de Energy Management System – EMS
inclui ainda outras funcionalidades:
 Estimador de Estado;
 Controle Automático da Geração – CAG;
 Analise de Contingência;
 Sistemas de Medição Fasorial.
Portanto, o SCADA nasceu para atender Centros de Operação, e inicialmente utilizando

grandes computadores (Mainframe) em ambiente físico controlado (DataCenter). A evolução
tecnológica dos computadores permitiu migrar de Mainframe para Workstation (baseados
em arquitetura RISC) e finalmente para computadores baseados em tecnologia CISC que
ofereciam preço muito mais competitivo e foram melhorando o desempenho até ser uma
alternativa segura.
Podendo ser aplicado em computadores de custo menor, o SCADA passou a ser utilizado
localmente, aproveitando o ambiente de digitalização das subestações e sendo mais
adequado para o novo cenário tecnológico.
As primeiras soluções eram de implementação muito complexa. A configuração de pontos
implicava em linguagem de programação, assim como a elaboração de telas que utilizavam
recursos semi-gráficos. O desempenho era apenas aceitável.
O impacto da adoção do SCADA foi enorme. Operadores acostumados a painéis, chaves e
anunciadores posicionais tiveram que se ambientarem com mouse, telas, lista de alarme. A
manutenção teve que mudar seu perfil de conhecimento para entender de computação,
redes Ethernet e protocolos de comunicação.
154
11.1 EVOLUÇÃO DOS SISTEMAS SUPERVISORIOS
Conforme foi comentado, as salas de controles eram dotadas de inúmeras chaves de

comando de disjuntores, de mostradores analógicos de corrente, tensão e potência. Os
intertravamentos eram realizados por meio de lógicas de contatos entre relés
eletromecânicos e estáticos. Os operadores monitoravam diversos anunciadores
interligados eletricamente com os painéis de proteção controle e oscilografia. Existiam uma
infinidade de cabos de cobre de controle e supervisão vindo de diversos painéis e
equipamentos. A Figura 160 abaixo mostra de maneira simplificada, a topologia de
interligação existente numa subestação eletromecânica.
Figura 160 – Interligação com cabos de cobre
Com o avanço da tecnologia, os cabos de interligação deram lugar para os cabos de

comunicação e as Unidades Terminais Remotas – UTR (Remote Terminal Unit - RTU)
utilizando protocolos abertos (IEC-101 e DNP3) e protocolos proprietários. Aos poucos os
anunciadores, punhos de comando, botoeiras e medidores analógicos foram trocados por
computadores industriais contendo um software SCADA, numa IHM com diagramas e listas
de alarmes.
A UTR foi sendo substituída por Reles de Proteção Digital e Unidades de Controle de Bay
capazes de se comunicar diretamente com o SCADA, numa comunicação que migrou de
uma infraestrutura serial para Ethernet, e consolidou a aplicação de protocolos abertos
(DNP3, IEC 104, Modbus). As primeiras aplicações IEC 61850 incorporaram mensagens
MMS do SCADA com os IEDs e GOOSE entre dispositivos. A Figura 161 abaixo demonstra
simplificadamente a arquitetura utilizada no Brasil, que pode ser definida como uma
arquitetura de transição.
155
Figura 161 – Arquitetura atual dos sistemas supervisórios
Pode-se citar algumas características dos sistemas supervisórios atuais:

 Grandezas analógicas reportadas via MMS através de UAC ou multimedidores
usando protocolos Modbus;
 Pontos digitais reportados por IED via MMS;
 Comandos realizados por remotas de integração ou via MMS para UAC de controle;
 Necessidade de equipamentos de integração entre o SCADA e os equipamentos de
campo;
 Equipamentos grandes, complexos e com várias interfaces;
 Lógicas de intertravamentos realizadas por circuitos elétricos e por softwares;
 Diversos relés auxiliares para duplicação de sinais;
 Diversos equipamentos de comunicação;
 Utilização de Modbus, DNP3, IEC 60870-5-104 e MMS;
 Necessidade de fiação de cobre para os equipamentos de campo.
Com a consolidação da norma e o avanço de novas tecnologias acredita-se que os sistemas

supervisórios estarão totalmente integrados com os IEDs de proteção e controle e esses por
sua vez integrados com os equipamentos de campo ou Merging Units. Não haverá mais a
necessidade de cabos de cobre ou interligações físicas para comandos, medições, pontos
de atuação de proteção, entre outros. A Figura 162 abaixo exemplifica de maneira
simplificada esta nova arquitetura.
156
Figura 162 – Arquitetura IEC 61850 dos sistemas supervisórios
O principal impacto será a substituição da fiação de cobre entre os equipamentos primários

e a sala de controle. Mas em consequência os IEDs serão aderentes à norma e se terá
MMS na comunicação com o SCADA local. Além disso, alguns sinais poderão ser
aquisitados diretamente do pátio (Ex. monitoramento de saúde de MU).
Algumas mudanças então serão:
 Comandos realizados via MMS para UAC de controle que por sua vez comanda os
equipamentos via protocolo;
 Equipamentos compactos;
 Lógicas de intertravamentos realizadas exclusivamente por softwares;
 Utilização protocolos MMS, GOOSE e Sampled Values;
 Grande utilização das redes de comunicação;
 Fácil implementação de novos pontos ou equipamentos.
157
11.2 VISÃO MODERNA DOS SISTEMAS SUPERVISORIOS
Atualmente não existe nenhuma dúvida da eficiência, confiabilidade e desempenho do

sistema supervisório. Em muitas empresas ele também assume o papel de Gateway
concentrador de dados locais para envio de informações a Centros de Operação, de
Suporte e de Manutenção.
Esta é uma evolução natural de entender todo o sistema de aquisição de dados de uma
subestação como um sistema de informações. Com esta visão mais ampla é possível
otimizar recursos e melhorar a disponibilidade.
Figura 163 – Sistemas de Informação de uma subestação [53]
Numa subestação pode-se inicialmente analisar como acontece a aquisição de dados, e

avaliar de que forma é conveniente tratar esta coleta para transformar em informação. Na
maioria das soluções atuais, as subestações tem um conjunto de IEDs (relés de proteção,
unidade de aquisição e controle, multimedidores, unidades de monitoramento de
equipamento, unidade terminal remota), utilizando uma infraestrutura de comunicação local
(switches, conversores, terminal servers, roteadores) e uma infraestrutura computacional
(Unidade Concentradora da Substação, IHM, computadores de monitoramento e de
engenharia).
A IHM pode ser um computador diferente da UCS comunicando em protocolo, ou apenas
um Terminal de Operação – TO que neste caso faz somente um acesso grafico na UCS.
Para fazer um planejamento adequado dos sistemas é preciso utilizar uma estrutura de
dados e informação (Data and Information Structure - DIS). Ela deve atender a todas as
funções de proteção e automação, monitoramento, diagnóstico e suporte. Considerando a
crescente tendência de utilização da IEC 61850 e do CIM (Common Information Model), o
DIS deve reforçar a abordagem sistemática que permita que as aplicações interajam e deve
facilitar a implementação funcional ao longo de todos os níveis da hierarquia operacional. A
Figura 164 mostra a hierarquia e os requisitos relativos de dados e informações em cada
nível.
158
Figura 164 – Requisitos relativos a Dados e Informações [53]
O DIS deve atender os seguintes requisitos:

 Melhor relação custo benefício - transformando dado em informação uma única
vez no nível hierárquico mais baixo possível, e a um custo mínimo;
 Consistência: utilizando dados ou informações somente depois de validados e
atendendo ao nível de qualidade exigido para a aplicação específica;
 Coerência: aplicar os mesmos dados ou informações para todas as funções, para a
exposição ao operador e de difusão corporativa;
 Redundância: utilizando a abundância de dados para validação, de acordo a um
ranking de nível de qualidade;
 Confiabilidade: extensão dos conceitos de proteção de confiabilidade e segurança
para todas as funções;
 Segurança Cibernética: atender aos requisitos básicos especificados para o
Sistema Global de Gestão de Energia dos centros de controle regionais e nacionais;
 Compartilhamento: utilizar os mesmos dados ou informações para o proprietário de
uma única função (por exemplo, a proteção de componentes,) e para funções multi-
proprietário (por exemplo, esquemas de proteção de integridade - SIPS);
 Seletividade: para cada função e em cada nível hierárquico utilizar unicamente os
dados necessários às atribuições daquele sistema dentro de cada nível hierárquico.
No ambiente da subestação sempre teremos variedade de protocolos de comunicação. A

Unidade Concentradora da Subestação – UCS, tem que ter a capacidade de
interoperabilidade com diversos protocolos. Deve também ter capacidade de
processamento e inteligência para converter os dados aquisitados em informação. Investir
aqui significa otimizar tráfego de dados e melhorar a qualidade da informação. Também é
possivel com alguns recursos, capturar arquivos de oscilografia, e arquivos de registros em
relés. A partir da UCS é possivel tambem popular um banco de dados em algum padrão
corporativo, armazenando para disponibilizar aos sistemas de gestão: suporte à operação,
manutenção, monitoramento.
159
Figura 165 – Sistema de Informações de uma Subestação [53]
Para os sistemas corporativos é mais facil gerar serviços a partir de bancos de dados
baseados em Oracle, ou Postgres. Com relativa facilidade é possivel formatar para cada
área as informações do seu interesse, estando disponivel no ambiente corporativo. Isto
favorece inclusive a segurança cibernética, já que os usuários não precisam acessar
diretamente as instalações.
A configuração do SCADA é baseada em sofwares especificos de cada produto. As etapas
para poder realizar este trabalho são:
 Definição da arquitetura de comunicação;
 Definição dos requisitos de redundância;
 Definição das conexões de comunicação (IEDs) e protocolos;
 Definição da Lista de Sinais a serem aquisitados;
 Tratamento dos sinais dentro do SCADA;
 Confecção das Telas Unifilares;
 Confecção de Telas Complementares;
 Definição de historico de dados;
 Definição de configuração de banco de dados;
 Definição de Usuarios e Perfis;
 Definição de informações a repassar a outros níveis.
Os recursos para realizar estas atividades dependem de cada produto, empresa,

ferramentas auxiliares e padrões estabelecidos.
160
11.3 SISTEMAS SUPERVISORIOS E A NORMA IEC 61850
Como foi apresentada anteriormente, uma visão moderna de um sistema supervisório aplica
um conceito de tratamento da informação. Isto significa que queremos otimizar o processo
evitando dados que precisam ser traduzidos numa informação real.
A melhor maneira de fazer isto é aplicar um modelo de dados, de maneira a ter uma
informação estruturada. A norma IEC 61850 é exatamente isto, uma configuração descritiva
baseada em modelo, Logical Nodes, com definição de atributos e descrição da comunicação
e de sua infraestrutura.
Portanto pode-se utilizar o arquivo SCD descritivo da subestação como arquivo base para
configuração de nosso sistema SCADA. Nele temos todas as informações que precisamos
disponíveis dos IEDs para supervisão de estados, condições, medidas dos equipamentos,
além de sua saúde funcional.
Mas, aqui já é preciso aplicar conceitos de estrutura de dados e informação (DIS) conforme
já foi apresentado. Portanto, definir que informação, de que forma, em que tempo e em qual
lugar e para quem deve estar disponivel.
Na aplicação do arquivo SCD alguns aspectos devem ser observados:
 O arquivo SCD tem muito mais informação do que é necessário ao sistema
supervisório;
 Existem pontos genéricos GGIO originados de dados que não estão definidos em
norma, ou foram necessários para customizar funcionalidades;
 A nomenclatura e descrição do SCD não é a desejada pelos usuários do SCADA;
 O SCD não define nível de gravidade de uma informação: crítico, alarme,
sinalização, apenas registro historico;
 O SCD não define o tratamento dentro do sistema supervisório: com que cor, fonte
deve mostrar ou não numa lista de alarmes, que nivel de som deve ser associado;
 O SCD não define quais informações devem ir ou não para o Visor de Telas e de que
forma devem ser apresentados (objetos, textos, permanente ou somente quando
solicitado);
 As nomenclaturas do SCD normalmente seguem descrição de projeto, que não
corresponde à descrição operacional, a qual inclusive pode mudar ao longo do
tempo;
 No arquivo SCD pode não conter outras conexões do SCADA, com sistemas
legados, outros dispositivos não IEC 61850, e troca de dados locais com outros
sistemas/empresas em outros protocolos.
Então apesar do papel central do arquivo descritivo da subestação SCD, ele não é suficiente
para configurar e definir a configuração do SCADA.
Conforme viu-se no Capítulo 4 na especificação do sistema, outras fontes de informação
devem ser consideradas. Podemos organizar incluindo mais duas fontes de informação do
projeto:
 Lista de Pontos: Nela aplicamos um dicionário de tratamento e nomenclatura de
todos os sinais, medidas e comandos que irão definir a base de dados do SCADA.
Normalmente ela contém basicamente:
o Informações fisicas e lógicas da origem dos sinais;
o Protocolo e endereço de cada sinal;
o Nomenclatura operacional;
o Identificador e descrição baseado num dicionário padrão da empresa;
o Definição de tratamento: nivel do alarme, visores onde apresentar a
informação.
161
 Template: Para poder gerar as telas do SCADA se precisa das definições de cores,
fontes, detalhes do unifilar da subestação e de outras telas utilizadas (bandeirolas de
proteção, comunicação, etc). A maneira de poder gerar automaticamente estas telas
depende obviamente do software SCADA aplicado, mas normalmente é possivel
gerar os arquivos automaticamente se eu tiver a definição de vãos tipicos:
o Função: Linha de Transmissão, Transformador, Serviço Auxiliar, Barra, etc;
o Nível de Tensão;
o Arranjo da Subestação;
o Informações Complementares (Caixas de detalhes).
Figura 166 – Processo de configuração
Existem diferentes recursos para realizar este processo. Sistemas SCADA de geração mais
nova são capazes de realizar a integração destas fontes de descrição e gerar a base de
dados e desenhos unifilares.
Atualmente é mais comum utilizar ferramentas de Virtual Basic for Applications – VBA,
programação na planilha Excel, onde se importa o arquivo SCD, se tem a definição de
dicionário, se interpretam as informações do projeto às descrições operacionais e de
tratamento. Dependendo do SCADA é possível inclusive exportar diretamente as telas
utilizando templates típicos da aplicação da empresa.
A forma, entretanto, não é o aspecto mais importante, mas se apropriar das vantagens de
poder automatizar o processo de configuração. As vantagens principais são:
 Menor tempo de implementação para configurar todo o sistema SCADA;
 Maior segurança de qualidade e aderência a padrões definidos;
 Facilidade para realizar alterações seguras no sistema;
 Documentação de todas as informações aplicadas;
 Gestão de mudança de padrões com confiabilidade e possibilidade de fazer em
grande escala sem prejuízo dos sistemas em operação.
162
A maneira de fazer a comunicação do SCADA local com Centros de Operação varia de

acordo com as práticas de cada empresa.
Comunicação em protocolo DNP3 e IEC-104 ainda são muito comuns e bastante
consolidadas. Mas implica em converter uma informação novamente num dado definido por
um endereço sem significado.
Por isso, parece mais aderente a uma solução IEC 61850 aplicar uma comunicação em
modelo de dados.
O protocolo de comunicação que tem este foco é o Inter-Control Center Communications
Protocol – ICCP, padrão da IEC 60870-6 / TASE.2 (Telecontrol Application Service Element
2). Ele faz uso do MMS, da mesma maneira que o IEC 61850.
Desta maneira nos beneficiamos de um protocolo de modelo de dados, cliente servidor, e
trabalhamos com o envio de informação, e não apenas de dados para os níveis superiores.
Alguns sistemas SCADA permitem configurar o servidor ICCP como um servidor genérico
Isto significa que disponibiliza toda a sua base de dados ao cliente que se conecta nele. A
vantagem nesta abordagem é que não precisamos configurar quais pontos serão
disponibilizados a um determinado cliente, mas é o cliente que decide quais pontos são do
seu interesse. Isto diminui a possibilidade de erros na configuração da distribuição, facilita
alteração nas informações desejadas pelo Centro de Operação e a inclusão de novas
conexões com facilidade.
Olhando para o futuro os sistemas SCADA têm um enorme potencial de desenvolvimento na
interação humano-maquina. Seus conceitos nasceram num ambiente tecnológico muito
mais limitado do que temos hoje.
Uma das possibilidades é a aplicação de Inteligência Artificial - IA agilizando tomadas de
decisão e ações no sistema de potência. Atualmente existem sistemas especialistas que
podem ser configurados para auxílio de ações. Mas no futuro poderemos ter tecnologias de
Machine Learnig e automatização do sistema de supervisão e controle.
Outro será o desenvolvimento de soluções SCADA baseadas em Human-Centered Design –
HCD. O conceito é uma estrutura de design para a criação de produtos, serviços, hardware
e software criado para atender às necessidades específicas de clientes e usuários. O
objetivo é melhorar a experiência do usuário, reduzir o estresse e evitar desconforto para os
usuários finais. Também melhorar a produtividade de seus usuários criando produtos e
serviços projetados para serem intuitivos, naturais, e fáceis de usar, o que também pode
ajudar a reduzir os custos associados ao treinamento e suporte.
163
12. CONCLUSÃO
A aplicação de soluções IEC 61850 tem se estabelecido como padrão na maioria das
empresas do sistema de energia elétrica no Brasil. Isto não significa que as implementações
são plenamente aderentes à norma, ou na sua plenitude. A aplicação de tecnologias
disruptivas são normalmente implementadas em etapas e sofrem dificuldade em serem
assimiladas pelo impacto que provocam especialmente no perfil de conhecimento das
equipes responsáveis pelo projeto, operação e manutenção e nos procedimentos e na
organização das empresas.
As vantagens dependem de uma visão abrangente da aplicação de uma solução totalmente
digital e de ter uma estratégia para se beneficiar das potencialidades da norma IEC 61850.
Isto significa avançar não apenas no Sistema de Automação da Subestação – SAS, mas
nas implementações do sistema primário, para incorporar as vantagens econômicas, de
confiabilidade, disponibilidade e gestão.
A aplicação de Station Level está consolidada no Brasil. A utilização de mensagens verticais
aplicando MMS para os sistemas de supervisão e controle é amplamente utilizado, e as
mensagens GOOSE nas mensagens horizontais para intertravamentos e condições
operativas como transferência de proteção ou posição do bay de transferência. Por outro
lado falta avançar na aplicação de disparos de proteção.
A experiência de projetos pilotos de Process Level criou o ambiente para a implementação
dos primeiros projetos reais. Estas aplicações em subestações do sistema de potência
darão a segurança para avançar na aplicação completa da norma. Também apontarão
sobre as melhorias e adequações necessárias.
Um aspecto importante na direção de aplicar soluções completas e seguras é avançar nas
ferramentas de configuração e de manutenção. Isto implica tanto na melhoria dos softwares
quanto na qualificação das equipes responsáveis (empresas de energia, fornecedores,
integradores).
O monitoramento do sistema também deve avançar, para avaliar a desempenho das
aplicações e monitorar os aspectos de segurança cibernética.
Os aspectos regulatórios também avançam para permitir a aplicação segura de soluções
completas IEC 61850 o que cria um ambiente seguro para as empresas aplicar e avaliar
empresarialmente as vantagens destas soluções.
Será muito importante consolidar as tecnologias de instrumentos não convencionais (Non
Conventional Instrument Transformers – NCIT) que podem potencializar as vantagens
econômicas e de confiabilidade quando comparadas às soluções tradicionais.
A crescente virtualização dos sistemas possivelmente irá impactar profundamente as atuais
soluções, fugindo das “caixas” que associam as funcionalidades do sistema. As aplicações
de proteção e controle estarão definidas como partes de um sistema virtualizado, sem
depender de um determinado hardware, e por isso com maior disponibilidade, flexibilidade e
confiabilidade.
Os diversos grupos de trabalho nacionais e internacionais do CIGRE avançam aspectos
muito concretos da aplicação da norma e contribuem significativamente para consolidar
conceitos e soluções. Envolvem os diferentes agentes envolvidos no processo:
fornecedores, integradores, laboratórios de pesquisa, empresas de energia, consultores. Isto
enriquece tremendamente as discussões e as sugestões apontadas nos documentos
produzidos.
164
Este documento procurou abordar todos os aspectos importantes na aplicação de uma

solução IEC 61850 destacando aspectos teóricos e práticos a serem observados pelas
empresas que querem aplicar este tipo de solução. A intenção é de auxiliar a criar um roteiro
considerando a quantidade de normas, documentos, especificações, grupos de discussão
disponíveis, que se por um lado permitem aprofundar muitos aspectos, às vezes dificultam
pelo volume imenso de informações disponíveis.
Investir em novas tecnologias significa uma atitude permanente de investimento em
conhecimento, qualificação e aprendizado. Esta motivação deve estar presente na cultura
das empresas e nos profissionais envolvidos nos processos de implantação, operação e
manutenção.
O futuro aponta para grandes possibilidades tecnológicas em relação à infraestrutura e à
aplicação de modelo de dados. Mas é importante compreender que os conhecimentos
específicos de proteção, automação e controle do sistema de potência permanecem. A
mudança está na forma de realizar e nos benefícios que novas tecnologias poderão oferecer
especialmente nos sistema primários no pátio da subestação.
165
13. REFERÊNCIAS
[1] IEC 61850: 2016 SER Series Communication networks and systems for power utility
automation - ALL PARTS
 IEC 61850-1
 IEC 61850-2
 IEC 61850-3
 IEC 61850-4
 IEC 61850-5
 IEC 61850-6
 IEC 61850-7-1
 IEC 61850-7-2
 IEC 61850-7-4
 IEC 61850-8-1
 IEC 61850-9-1
 IEC 61850-9-2
[2] TB 326 (2007) WG B5.11 – The Introduction of IEC 61850 and Its Impact on Protection
and automation Within Substations.
[3] TB 401 (2009) WG B5.32 Functional Testing of IEC 61850 Based Systems
[4] TB 427 (2010) WG B5.38 The Impact of Implementing Cyber Security Requirements
using IEC 61850
[5] TB 464 (2011) WG B5.06 Maintenance Strategies for Digital Substation Automation
Systems
[6] TB 466 (2011) WG B5.12 Engineering Guidelines for IEC 61850 Based Digital SAS
[7] TB 540 (2013) WG B5.36 Applications of IEC 61850 Standard to Protection Schemes
[8] TB 628 (2013) WG B5.39 Documentation Requirements Throughout the Lifecycle of
Digital Substation Automation Systems
[9] TB 637 (2014) WG B5.45 Acceptance, Commissioning and Field Testing Techniques
for Protection and Automation Systems
[10] TB 760 (2019) WB B5.53 Test strategy for Protection, Automation and Control (PAC)
functions in a fully digital substation based on IEC 61850 applications
[11] IEC 62351-6: 2007 Power systems management and associated information
exchange, Data and Communication Security Part 6: Security for IEC 61850
[12] IEC 62439-3: 2010 Industrial communication networks, High availability automation
networks Part 3: Parallel Redundancy Protocol (PRP) and High availability Seamless
Redundancy (HSR)
[13] IEC 60834-1: 1999 Teleprotection equipment of power systems - Performance and
testing
[14] IEC 61000-6-5: 2015 Electromagnetic compatibility (EMC) - Part 6-5: Generic
standards - Immunity for equipment used in power station and substation environment
[15] IEC 62443: 2018 Security For Industrial Automation And Control Systems
[16] IEEE C37.111: 1999 IEEE Standard Common Format for Transient Data Exchange
(COMTRADE) for Power Systems
166
[17] IEEE 754: 1985 IEEE Standard for Binary Floating-Point Arithmetic
[18] IEEE 802.1Q: 1998 IEEE Standards for Local and Metropolitan Networks: Virtual
Bridged Local Area Networks (VLAN)
[19] RFC 4330: 2006 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and
OSI, IETF
[20] ANSI/IEEE C37.90: 2006 Standard For Relays And Relay Systems Associated With
Electric Power Apparatus
[21] ISO/IEC 27000: 2018 Information Technology Security Techniques Collection
[22] NIST SP 800-53: 2009 Recommended Security Controls For Federal Information
Systems And Organizations
[23] NIST: 2018 Framework for Improving Critical Infrastructure Cybersecurity
[24] https://www.scriptcaseblog.com.br/encapsulamento-programacao-orientada-a-objetos/
[25] https://www.devmedia.com.br/fundamentos-basicos-da-orientacao-a-objetos/26372
[26] Flores,P.H., Paulino,M.E.C.,Lima,J.C.M, Penariol,G.S., Carmo,U.A., Bastos,M.R.,
Ramos,M.A., Paulillo,G., Lellys,D.: “Implementation of Digital Substation Automation
Systems in Brazil - Challenges and Findings”, CIGRE 2018, paper number B5-201,
Paris, 2018.
[27] Paulino,M.E.C.: “IEC 61850 automação de subestações”, Revista O Setor Elétrico,
Julho 2008.
[28] Flores,G.H., Alexandrino,M.,Guglielmi Filho,A.J.,Souza Junior,P.R.A, Harispuru,C.,
Demidov,N.: “Aplicação de ferramentas de engenharia eficiente utilizando arquivos
padronizados da norma IEC 61050”, XIV Seminário Técnico de Proteção e Controle –
STPC, Foz do Iguaçu, 2018.
[29] Instruction manual, ZIV Line Differential Protection model DLF Zamudio (Spain),
reference M0DLFA1905Ev00
[30] Instruction manual, ZIV UNIVERSAL TELEPROTECTION TPU-1 Barcelona (Spain),
reference TPU-1 General Description (MVJ_Sun_Web_version_TPU-1R)_R3.13-I
[31] South East Asia Protection and Automation Conference - SEAPAC, 2019, 19-20
March, 2019, Sidney, Australia Teleprotection in the new WAN world
[32] A.C. Adewole, R. Tzoneva, “Impact of IEC 61850-9-2 Standard-Based Process Bus on
the Operating Performance of Protection IEDS: Comparative Study”, Proceedings of
the 19th World Congress The International Federation of Automatic Control Cape
Town, South Africa. August 24-29, 2014
[33] J. Castellanos, I. Ojanguren, I. Garces, R. Hunt, J. Cardenas, M. Zamalloa, J. Garcia,
A. Gallastegui, M. Yubero, E. Otaola, “IEC61850 9-2 Process Bus - Application in a
real multivendor substation”, CIGRE 2010
[34] K. Narendra, N. Perera, R. Midence, “Micro processor based advanced bus protection
scheme using IEC 61850 process bus -9-2- sampled values”, 70th Annual Conference
for Protective Relay Engineers (CPRE), 2017
[35] H. Vardhan, R. Ramlachan, W. Szela, E. Gdowik, “Deploying digital substations
Experience with a digital substation pilot in North America”, 71st Annual Conference for
Protective Relay Engineers (CPRE), 2018
[36] M. Mekknen, “IEC-61850-for-digital-substation-automation-systems - On Reliability and
Performance Analyses of IEC 61850 for Digital SAS”, Monograph, University of Vaasa,
Faculty of Technology, Department of Computer Science, 2015
167
[37] H. Heine, P. Guenther, F. Becker, “New non-conventional instrument transformer -

NCIT- - a future technology in gas insulated switchgear”, IEEE/PES Transmission and
Distribution Conference and Exposition (T&D), 2016
[38] N. Honeth, Z. Ali Khurram, P. Zhao, L. Nordström, “Development of the IEC 61850-9-2
software merging unit IED test and training platform”, IEEE Grenoble Conference, 2013
[39] J. Starck , W. Wimmer , Karol Majer, “Switchgear optimization using IEC 61850-9-2”,
22nd International Conference and Exhibition on Electricity Distribution (CIRED 2013)
[40] D. Lellys U. A. do Carmo, M. Schmitt, M. Paulino, “Process bus Merging Unit Conceito
arquitetura e impacto na automação de subestações”, SENDI - XIX Seminário
Nacional de Distribuição de Energia Elétrica, 2020, São Paulo
[41] IEC, “IEC61850-9-2ed2.1en”, Communication Networks and Systems for Power Utility
Automation, Part 9-2: Specific Communication Service Mapping (SCSM) Sampled
Values over ISO/IEC 8802-3”, 2020
[42] G. Igarashi, “Contribuições para a implementação de um barramento de processo
segundo a Norma IEC 61850-9”, Tese, Escola Politécnica da Universidade de São
Paulo, Departamento de Engenharia de Energia e Automação Elétricas, 2016
[43] I. Ali, M. S. Thomas, S. Gupta, S. M. S. Hussain, “IEC 61850 Substation
Communication Network Architecture for Efficient Energy System Automation”, Energy
Technology & Policy, 2:1, 82-91, 2015
[44] Flores,P.H., Zimath, S.L., Lima,J.C.M, Puppi, L.V.S., Bastos,M.R., Ramos,M.A.,
Lellys,D., Mendes, M.F., Lisboa, L.A.L.: “Implementations and challenges in time
synchronization of protection, automation and control systems: Experience and
expectations of applications in Brazil”, Study Committee B5 Colloquium, paper number
B5-205, Tromsoe, 2019.
[45] IEEE 1558 Verson 2: Standard for a precision clock synchronization protocol for
networked measurement and control systems, 2008.
[46] https://www.meinbergglobal.com/english/info/irig.htm
[47] https://www.microsemi.com/blog/2018/08/14/the-importance-of-network-time-
synchronization-part-2-of-8/
[48] Brand, K.P., Communication Principles, CIGRE, Paris, 2006.
[49] IEEE 802.1Q Standard for Local and Metropolitan Area Networks — Bridges and
Bridged Networks, 2019.
[50] IEC International Standard "Industrial communication networks – High availability
automation networks – Part 3: Parallel Redundancy Protocol (PRP) and High-
availability Seamless Redundancy (HSR)", IEC Reference number IEC 62439-3:2012,
IEC, Geneva, Switzerland.
[51] IEC 62351-10: 2012 Power systems management and associated information
exchange, Data and Communication Security Part 10: Security architecture guidelines
[52] NESCOR - National Electric Sector Cybersecurity Organization Resource, 2012.
[53] Flores, Pablo H., Gestão da informação nos sistemas de supervisão, controle e
proteção: uma avaliação crítica da geração de dados e de informação, PAC World
2012.
168

Norma Iec 61850

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Norma Iec 61850

Uploaded by

Copyright:

Available Formats

Grupo de Trabalho

Pablo Humeres Flores - Coordenador BR

ISBN : [to be completed by CIGRE]

Na última década os Sistemas de Automação de Subestação passaram por um significativo

Com base nessa avaliação e compilação de dados, o GT formulou descrições e

3. INTRODUÇÃO, FILOSOFIA E JUSTIFICATIVAS PARA ADOÇÃO DA NORMA IEC 61850 .... 10

4. ESPECIFICAÇÃO DE DISPOSITIVOS E SISTEMAS BASEADOS NA NORMA IEC 61850 ........ 20

5. INTEGRAÇÃO ENTRE DISPOSITIVOS E REDES DE PROTEÇÃO E AUTOMAÇÃO.................... 37

6. REQUISITOS DE DOCUMENTAÇÃO EM SAS ................................................................................. 64

6.4 PROJETO FUNCIONAL .................................................................................................................................................... 67

7. APLICAÇÕES DA NORMA IEC 61850 EM ESQUEMAS DE PROTEÇÃO ................................... 72

8. REQUISITOS DE SEGURANÇA CIBERNÉTICA EM SISTEMAS OPERANDO COM

9. MANUTENÇÃO E PROCESSOS DE VALIDAÇÃO EM SISTEMAS OPERANDO COM A NORMA

9.5 REQUISITOS PARA FERRAMENTAS DE TESTE .......................................................................................................... 123

10. BARRAMENTO DE PROCESSO – IEC 61850-9-2................................................................. 140

11. SISTEMAS SUPERVISÓRIOS E A NORMA IEC 61850.......................................................... 154

12. CONCLUSÃO .............................................................................................................................. 164

13. REFERÊNCIAS ............................................................................................................................... 166

ANEEL Agência Nacional de Energia Elétrica

MAC Media Access Control

UCA Utility Communication Architecture

3. INTRODUÇÃO, FILOSOFIA E JUSTIFICATIVAS PARA

3.1 VISÃO GERAL DA NORMA IEC 61850

Figura 1 – PAC system convencional eletromecânico

Portanto, tem-se um sistema na sala de controle (PAC System) que obedecendo a um

potência. A evolução tecnológica inicial foi a digitalização do sistema substituindo elementos

Figura 2 – PAC system digital – Sala de controle digital

A próxima etapa, já em andamento no Brasil, é a digitalização do nível de pátio, com a

Figura 3 – PAC system digital – Sala de controle e pátio digitais

É interessante observar que o conceito de proteção, supervisão e controle não muda.

Figura 4 – Partes da Norma IEC 61850 [27]

Figura 5 – Visão do sistema PAC conforme a Norma IEC 61850

As principais definições que serão aplicadas são:

As funções de aplicação (application functions) de um SAS são: controle, supervisão,

Figura 6 – Níveis da subestação [26]

Figura 7 – Definição das instâncias [1–Part 7-1]

Figura 8 – Logical Nodes [1-Part 7-4]

Figura 9 – Exemplo de Logical Nodes [1-Part 1]

O processo de aplicação de uma solução IEC 61850 permite a descrição da subestação

Figura 10 – Implementação de uma solução IEC 61850 [26]

A correta aplicação da solução e a qualidade do projeto têm enorme relação com a

3.2 BENEFÍCIOS NA ADOÇÃO DA NORMA

As vantagens na adoção de uma solução baseada na norma IEC 61850 dependem da

para configuração, monitoramento do desempenho e testes funcionais, uma vez

permitindo o desempenho necessário para funções de proteção que exigem tempos

Obviamente que as vantagens apontadas serão reais, conforme já apresentado, à medida

3.3 DIFICULDADES NA ADOÇÃO DA NORMA

3.4 TENDÊNCIAS TECNOLÓGICAS FUTURAS E REQUISITOS ADERENTES À NORMA

exija grande domínio da linguagem SCL ou de software específico. O WG B5.64 - Methods

3.5 HISTÓRICO DE SUAS APLICAÇÕES NO BRASIL

As primeiras aplicações de soluções IEC 61850 iniciaram em 2007 no nível de casa de

4. ESPECIFICAÇÃO DE DISPOSITIVOS E SISTEMAS

4.1 DESCRIÇÃO DE UM SISTEMA BASEADO NA NORMA IEC 61850

Figura 11 – Sistema baseado numa solução IEC 61850

A especificação deve considerar também o processo de implantação e a gestão ao longo da

Figura 12 – Etapas na implementação de um sistema IEC 61850 [6]

As três primeiras etapas (Figura 12) estão relacionadas à especificação do sistema:

 Planejamento da Implementação: Especificação dos Dispositivos:

 Planejamento da Implementação: Especificação do Sistema:

O ponto de partida de um projeto é a necessidade da própria subestação, definida por quem

Figura 13 – Etapas do processo na especificação: Subestação

A partir destas informações é possível fazer toda a descrição da infraestrutura de

Figura 14 – Etapas do processo de engenharia: Especificação do sistema