Implementação do Projecto-Tipo da EDP para Automação ... · Implementação do Projecto-Tipo da...
101
Implementação do Projecto-Tipo da EDP para Automação de Subestações segundo a norma IEC 61850: Configuração de IED’s de dois fabricantes para painéis de saída em MT Duarte Filipe Reves Martins Dissertação para obtenção do Grau de Mestre em Engenharia Electrotécnica e de Computadores Júri Presidente: Prof. Paulo José da Costa Branco Orientador: Prof. Dr. José Luís Costa Pinto de Sá Vogal: Prof. Maria Helena da Costa Matos Sarmento Novembro 2010
-
Upload
doannguyet -
Category
Documents
-
view
222 -
download
4
Transcript of Implementação do Projecto-Tipo da EDP para Automação ... · Implementação do Projecto-Tipo da...
Implementação do Projecto-Tipo da EDP para Automação de Subestações segundo a norma IEC 61850: Configuração de IED’s de dois fabricantes para painéis de saída em MT
Duarte Filipe Reves Martins
Dissertação para obtenção do Grau de Mestre em
Engenharia Electrotécnica e de Computadores
Júri
Presidente: Prof. Paulo José da Costa Branco
Orientador: Prof. Dr. José Luís Costa Pinto de Sá
Vogal: Prof. Maria Helena da Costa Matos Sarmento
Novembro 2010
i
Implementação do Projecto-Tipo da EDP para Automação de Subestações segundo a norma IEC
61850: Configuração de IED’s de dois fabricantes para painéis de saída em MT
Duarte Filipe Reves Martins
ii
Agradecimentos
A vida é feita de etapas, cada uma com as suas dificuldades, motivações, quedas e sucessos.
No desenrolar de todas as etapas da minha história de vida houve um sempre um elemento
comum, a presença incondicional da minha mãe e do meu pai, que depositaram em mim todos
os seus esforços e dedicação para que o culminar de todas as etapas fosse atingido com
sucesso. A eles eu dedico todo o trabalho desenvolvido, agradecendo-lhes por me terem pro-
porcionado chegar ao fim desta etapa.
Por todo o amor, por toda a amizade, e por todo o apoio incondicional que me deu nos bons e
maus momentos da minha vida, quero agradecer à Teresa. Sem ela, os bons momentos nunca
teriam tido o mesmo sabor, e os maus teriam sido muito mais difíceis de ultrapassar. Um muito
obrigado pela tua paciência e sacrifício nas inúmeras horas da minha ausência.
Agradeço sinceramente ao Prof. Pinto de Sá, pela grande oportunidade que me proporcionou
ao deixar-me trabalhar num projecto desta envergadura, pautado pela inovação tecnológica e
ambição de revolucionar as comunicações nas subestações.
Nunca esquecerei todos amigos que me acompanham na jornada da minha vida, cada um com
o seu feitio especial, com diferentes maneiras de encarar os problemas e de olhar a vida, foram
paralelamente à família um factor preponderante para o meu sucesso, e para o meu desenvol-
vimento enquanto ser humano. Poderia deixar o meu agradecimento desta forma global, mas
penso que os verdadeiros amigos merecem ser devidamente mencionados:
Aos que me acompanharam desde muito novo, que me conheceram desde o secundá-
rio e me acompanharam em toda a minha travessia, um muito obrigado. (Joana Rocha,
Carla Andrade, Rita Fernandes e Jó)
Aos que me chamaram para a rodinha no primeiro dia da faculdade e me proporciona-
ram uma experiência universitária recheada de companheirismo, apoio, compreensão e
muita dedicação, um muito obrigado (Joana Rosa, Waaaize)
A todos os amigos que por motivos tão diversos se cruzaram na minha vida, revelando-
se pessoas merecedoras de entrar num núcleo tão restrito de pessoas a que eu chamo
amigos, um muito obrigado (Ricardo Batista, Sílvio Rodrigues, Rui Figueiredo, Cláudio
Fernandes)
A todas as restantes pessoas que contribuíram directa ou indirectamente para a realização
deste trabalho, o meu muito obrigado.
iii
Resumo
A larga tradição de automatização e protecção das subestações da EDP, deu origem à ideia da
configuração de um Projecto-Tipo, cujas configurações pudessem ser reutilizadas em projectos
futuros, com todas as vantagens monetárias que esta solução garante. Por outro lado, a
recente norma de comunicações para ambientes de energia (IEC 61850) propõe regras de
estruturação das especificações orientadas por objectos, usando uma linguagem específica, a
SCL (Substations Configuration Language). A adaptação das subestações à nova norma visa,
levar para os sistemas informáticos das subestações o ambiente dos PC/Windows: redes
Ethernet, TCP/IP e facilidades plug and play.
Neste sentido, é de extremo interesse o desenvolvimento de especificações reutilizáveis de
Sistemas de Automação e Protecção, para as subestações da EDP, usando as regras de
estruturação por objectos e a linguagem SCL definidas na norma IEC 61850.
O trabalho desenvolvido consistiu em escrever na linguagem SCL, as actuais especificações
da EDP para os sistemas descritos no Projecto-Tipo de subestações, estruturando-as de
acordo com os princípios da norma, e usando as ferramentas de alto nível disponíveis, deno-
minadas de “ferramentas de configuração de sistema”. As especificações de automatização,
que recorrem à comunicação horizontal entre automatismos, não foram abordadas.
Estas ferramentas dispõem de ambientes gráficos, que tornam de fácil uso a SCL, tendo sido
utilizadas as ferramentas, Visual SCL e Helinks STS. Para ambos os softwares foram testados
vários métodos de configuração. Adicionalmente foram também exploradas as interfaces de
comunicação entre as ferramentas de configuração de sistema e as ferramentas de configura-
ção de IEDs, de forma a saber se é possível alcançar interoperabilidade através da troca de
dados entre ferramentas.
Foi ainda desenvolvido um método para automatizar todas as configurações dos serviços rela-
cionados com a IEC 61850, que consistiu na criação de um programa com base na linguagem
de programação C++, com capacidades de leitura e edição de ficheiros SCL.
Palavras-Chave
Ferramenta de Configuração de IED’s
Ferramenta de Configuração de Sistema
IEC 61850
Linguagem SCL - Substations Configuration Language
Sistemas de Automação e Protecção
iv
Abstract
The EDP long tradition of substations automation and protection gave birth to a prototype
project, whose configurations can be reuse in future projects with all the financial benefits that
this solution insures. However, the recent communication norm for energy environment (IEC
61850), recommend rules specifications of organization oriented for objects, applying a specific
language SCL (Substations Configuration Language). Substations adjust to the new norm aims
to carry the PC/Windows: Ethernet net, TCP/IP environments, and “plug and play” services to
substations informatics systems.
Towards it is very important and interesting the development of reusable specifications of Au-
tomation and protection systems for EDP substations, using the organization for objects and
SCL language set in IEC 61850.
The main goal of this work was to write in SCL language the EDP current specifications for
systems described in substations prototype project, making their structure according the norm
principles and using high level tools called “System configuration tools”.
These tools have graphical environments that aid SCL use, like Visual SCL and Helinks STS,
which were used in this work. Many configuration methods were tested for these tools. In addi-
tion communication interfaces were exploited between system configuration tools and IED’s
configuration tools, In order to find if it is possible reach interoperability through data exchange
among tools.
It was also developed an automation method for all configuration services related to IEC 61850,
hat consist in a program based on C++ language, with the ability of reading and editing SCL
files.
Keywords
IED’s Configuration Tools
System Configuration Tools
IEC 61850
SCL Language - Substations Configuration Language
Automation and Protection Systems
v
Lista de Conteúdos
AGRADECIMENTOS ................................................................................................................................................ II
RESUMO ............................................................................................................................................................... III
PALAVRAS-CHAVE ................................................................................................................................................. III
ABSTRACT ............................................................................................................................................................. IV
KEYWORDS ........................................................................................................................................................... IV
LISTA DE CONTEÚDOS ............................................................................................................................................ V
LISTA DE FIGURAS ................................................................................................................................................ VII
LISTA DE TABELAS ................................................................................................................................................. IX
LISTA DE ABREVIAÇÕES .......................................................................................................................................... X
1 INTRODUÇÃO ................................................................................................................................................ 1
1.1 ENQUADRAMENTO ............................................................................................................................ 1 1.2 OBJECTIVOS ...................................................................................................................................... 2 1.3 ORGANIZAÇÃO DA DISSERTAÇÃO .......................................................................................................... 2
2 NORMA IEC 61850 ......................................................................................................................................... 4
2.1 HIERARQUIA FUNCIONAL DOS IED’S ...................................................................................................... 4 2.2 LOGICAL NODE CLASS ......................................................................................................................... 7 2.3 LOGICAL NODE ZERO (LLN0) ............................................................................................................... 9 2.4 ORGANIZAÇÃO FUNCIONAL DE NÓS LÓGICOS ......................................................................................... 10 2.5 LINGUAGEM SCL ............................................................................................................................. 11 2.6 CONTROL BLOCK’S (CB’S) ................................................................................................................. 13
2.6.1 Setting Group Control Block (SGCB) .................................................................................... 13 2.6.2 Report Control Block (RCB) ................................................................................................. 14
2.7 FERRAMENTAS DE ENGENHARIA ......................................................................................................... 16 2.7.1 Ferramentas de Configuração de Sistema .......................................................................... 17 2.7.2 Ferramentas de Configuração de IED’s ............................................................................... 18
3 PROJECTO-TIPO DA EDP ............................................................................................................................... 19
3.1 ARQUITECTURA E ORGANIZAÇÃO FUNCIONAL DO SPCC .......................................................................... 20 3.2 ESQUEMA UNIFILAR DA SUBESTAÇÃO .................................................................................................. 22 3.3 DEFINIÇÃO DAS FUNCIONALIDADES PRESENTES NO SPCC ......................................................................... 23 3.4 COMPATIBILIZAÇÃO COM A NORMA IEC 61850 .................................................................................... 24 3.5 CORRESPONDÊNCIA ENTRE FUNÇÕES DO SPCC E NÓS LÓGICOS ................................................................. 24 3.6 CONFIGURAÇÕES DE UMA SUBESTAÇÃO SEGUNDO A NORMA IEC 61850 ................................................... 25
3.6.1 Desenho do esquema unifilar da subestação ..................................................................... 25 3.6.2 Associação de nós lógicos de protecção genéricos aos painéis (Bays) da subestação ....... 28 3.6.3 Importação dos ICD’s dos fabricantes dos IED’s a instalar na subestação ......................... 29 3.6.4 Associação dos IED’s aos painéis que estes vão proteger na subestação .......................... 30
4 CONFIGURAÇÃO REUTILIZÁVEL DO PROJECTO-TIPO .................................................................................... 32
4.1 ESTRUTURAS DE DADOS DISTINTAS ENTRE IED’S DE DIFERENTES FABRICANTES ............................................ 32 4.1.1 Procedimentos .................................................................................................................... 32 4.1.2 Organização do Logical Device ........................................................................................... 35 4.1.3 Organização dos Logical Node Zero (LLN0) ........................................................................ 36
4.2 INTERACÇÃO ENTRE O DIGSI E O VISUAL SCL ........................................................................................ 37 4.2.1 1ª Fase - Exportação do DIGSI vs Importação DIGSI ........................................................... 37 4.2.2 2ª Fase - Leitura e Salvaguarda do ficheiro SCD no Visual SCL ........................................... 38 4.2.3 3ª Fase - Método de Resolução dos Erros Resultantes ....................................................... 38 4.2.4 4ª Fase – Explicação técnica dos bugs pela ASE ................................................................. 39
4.3 INTERACÇÃO ENTRE O DIGSI E O HELINKS STS ...................................................................................... 40
vi
4.3.1 1ª Fase - Exportação do DIGSI vs Importação DIGSI ........................................................... 40 4.3.2 2ª Fase - Leitura e Salvaguarda do ficheiro SCD no Helinks STS ......................................... 41
4.4 REPORT CONTROL BLOCK .................................................................................................................. 41 4.4.1 Procedimentos .................................................................................................................... 42 4.4.2 Configuração básica do RCB no DIGSI ................................................................................ 42 4.4.3 1º Teste - Exportação do RCB do Helinks STS para o DIGSI ................................................ 45 4.4.4 2º Teste - Exportação RCB do Helinks STS para o DIGSI ..................................................... 48
4.5 SETTING GROUP CONTROL BLOCK ...................................................................................................... 53 4.5.1 Procedimentos .................................................................................................................... 53
4.5.1.1 Configuração do SGCB no DIGSI .................................................................................................... 53 4.5.1.2 1º Teste – Teste do SGCB recorrendo ao Helinks STS .................................................................... 55 4.5.1.3 2º Teste – Teste do SGCB recorrendo a um editor de texto XML .................................................. 57
4.6 FERRAMENTA DE CONVERSÃO DE FICHEIROS SCL ENTRE FABRICANTES ........................................................ 59 4.6.1 Objectivos ........................................................................................................................... 60 4.6.2 Funcionamento Geral ......................................................................................................... 61 4.6.3 Fluxograma ......................................................................................................................... 63 4.6.4 Procedimentos .................................................................................................................... 65
4.6.4.1 1ª Fase - Importação e parametrização de um IED da Siemens no Helinks STS ............................ 66 4.6.4.2 2ª Fase - Associação e parametrização de um IED genérico no Helinks STS .................................. 67 4.6.4.3 3ª Fase - Interacção entre o ficheiro SCD resultante e o Conversor SCL........................................ 69 4.6.4.4 4ª Fase a)- Importação do ficheiro SCD gerado no Conversor SCL para o Helinks STS .................. 70 4.6.4.5 4ª Fase b)- Importação do ficheiro SCD gerado no Conversor SCL para o DIGSI ........................... 72
5 CONCLUSÕES ............................................................................................................................................... 75
5.1 CONCLUSÕES PRINCIPAIS .................................................................................................................. 75 5.2 DIRECÇÕES DE INVESTIGAÇÃO ............................................................................................................ 76
6 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................................... 78
ANEXOS ............................................................................................................................................................... 79
1. CORRESPONDÊNCIA ENTRE FUNÇÕES DO SPCC E NÓS LÓGICOS ................................................................. 79 2. INTERACÇÃO ENTRE DIGSI E VISUAL SCL – PROCEDIMENTOS .................................................................. 81
2.1 1ª Fase - Exportação (DIGSI) vs Importação (DIGSI) ............................................................... 81 2.2 2ª Fase - Leitura e Salvaguarda do ficheiro SCD no Visual SCL ............................................... 83 2.3 3ª Fase – Método de Resolução dos Erros Resultantes .......................................................... 85
3. INTERACÇÃO ENTRE O DIGSI E O HELINKS STS – PROCEDIMENTOS ........................................................... 88 4. ASPECTO DO CÓDIGO FONTE DO CONVERSOR SCL .................................................................................. 90
vii
Lista de Figuras
Figura 1 - Modelo do IED segundo a norma IEC 61850 [8] .......................................................... 5 Figura 2 – Hierarquia Funcional do IED segundo a norma IEC 61850 [9] ................................... 6 Figura 3- Estrutura interna genérica de um nó lógico segundo a norma IEC 61850 [1, Figura 3] 7 Figura 4 - Constituição da classe Common Logical Node segundo a norma IEC 61850 [3, capítulo 5.3.3] ................................................................................................................................ 8 Figura 5- Constituição da classe PTOC segundo a norma IEC 61850 [3, capítulo 5.4.18] .......... 8 Figura 6- Constituição da classe Logical Node segundo a norma IEC 61850 [2, Tabela 15] .... 10 Figura 7- Interface de comunicação de ficheiros SCL entre ferramentas de engenharia .......... 12 Figura 8- Definição de SGCB segundo a norma IEC 61850 [2, Figura 17] ................................ 13 Figura 9 – Constituição da classe SGCB segundo a norma IEC 61850 [2, Tabela 22] ............. 14 Figura 10 - Comunicação vertical e horizontal no SPCC [10] ..................................................... 15 Figura 11 – Diagrama funcional da comunicação de ficheiros SCL entre ferramentas de engenharia ................................................................................................................................... 16 Figura 12- Esquema Unifilar da Subestação 60/30 KV [6] ......................................................... 20 Figura 13- Arquitectura e Organização Funcional do SPCC [7] ................................................. 21 Figura 14 – Estruturas previstas para o desenho do esquema unifilar da subestação no Helinks STS .............................................................................................................................................. 26 Figura 15 – Equipamentos previstos para o desenho do esquema unifilar da subestação no Helinks STS ................................................................................................................................. 26 Figura 16 – Esquema unifilar da subestação no Helinks STS .................................................... 27 Figura 17 – Lista das áreas funcionais de Logical Nodes considerados no Helinks STS .......... 28 Figura 18 - Bay representativa do painel de chegada de AT no Helinks STS ............................ 29 Figura 19 – IED’s associados à descrição de uma subestação no Helinks STS ....................... 30 Figura 20 – Correspondência entre os nós lógicos previstos e os disponibilizados pelos IED’s (Helinks STS) .............................................................................................................................. 31 Figura 21 – Associação de IED’s a uma subestação no Visual SCL .......................................... 33 Figura 22 – Estrutura hierárquica dos Data Type Templates no Visual SCL ............................. 33 Figura 23 – Associação de Lnode Types no Visual SCL ............................................................ 34 Figura 24 – Comparação entre ficheiros no Visual SCL (lado esquerdo: Efacec, lado direito: Siemens) ..................................................................................................................................... 35 Figura 25 – Comparação entre ficheiros no Visual SCL (lado esquerdo: Efacec, lado direito: Siemens) ..................................................................................................................................... 36 Figura 26 – 1ª Diferença de sintaxe entre Visual SCL e DIGSI .................................................. 39 Figura 27 - 2ª Diferença de sintaxe entre Visual SCL e DIGSI ................................................... 40 Figura 28 – IED’s considerados dentro da descrição de uma subestação no DIGSI ................. 42 Figura 29 – Estrutura interna da instância de RCB do IED2_lab no DIGSI ................................ 43 Figura 30 - Estrutura interna da instância de RCB do IED_0010 no DIGSI ............................... 43 Figura 31 - IED’s associados à descrição de uma subestação no Helinks STS ........................ 44 Figura 32 - Estrutura interna do IED2_lab no Helinks STS ........................................................ 44 Figura 33 - Estrutura interna do IED_0010 no Helinks STS ....................................................... 45 Figura 34 - Estrutura interna do IED2_lab no Helinks STS ........................................................ 46 Figura 35 - Estrutura interna do IED_0010 no Helinks STS ....................................................... 47 Figura 36 – Aplicação DIGSI system configurator para a descrição de uma subestação .......... 48 Figura 37 – Associação de atributos a um DataSet no Helinks STS .......................................... 50 Figura 38 – Estrutura interna do IED2_lab no Helinks STS (lado esquerdo: original; lado direito: final) ............................................................................................................................................. 50 Figura 39 - Estrutura interna do IED_0010 no Helinks STS (lado esquerdo: original; lado direito: final) ............................................................................................................................................. 51 Figura 40 – Estrutura interna da instância de RCB do IED2_lab no Helinks STS ...................... 51 Figura 41 - Estrutura interna da instância de RCB do IED_0010 no Helinks STS ..................... 52 Figura 42 - Estrutura interna da instância de RCB do IED2_lab no DIGSI ................................ 52 Figura 43 - Estrutura interna da instância de RCB do IED_0010 no DIGSI ............................... 52 Figura 44 – Menu principal de configuração de um IED específico no DIGSI ............................ 54 Figura 45 – Menu que permite trocar o Change Group de um determinado SGCB no DIGSI ... 54 Figura 46 – IED’s considerados dentro da descrição de uma subestação no DIGSI ................. 54 Figura 47 - Menu de activação das funcionalidades disponíveis num determinado IED através do DIGSI ...................................................................................................................................... 55
viii
Figura 48 - Menu principal de configuração de um IED específico no DIGSI ............................ 55 Figura 49 - Estrutura interna do IED_0010 no Helinks STS ....................................................... 56 Figura 50 – Estrutura interna da instância de SGCB do IED_0010 no Helinks STS .................. 56 Figura 51 - Estrutura interna da instância de SGCB do IED_0010 no Helinks STS ................... 57 Figura 52 – Visualização de um ficheiro SCD no XML Copy Editor ........................................... 58 Figura 53 – Estrutura interna do IED_0010 no XML Copy Editor ............................................... 58 Figura 54 – Diagrama funcional do Conversor SCL ................................................................... 61 Figura 55 – Esquema das ramificações a implementar no modelo de um IED genérico ........... 63 Figura 56 – Fluxograma do Conversor SCL ............................................................................... 64 Figura 57 – IED’s considerados dentro da descrição de uma subestação no Helinks STS ....... 66 Figura 58 – Estrutura interna do IED_0010 no Helinks STS ...................................................... 67 Figura 59 – IED’s considerados dentro da descrição de uma subestação no Helinks STS ....... 68 Figura 60 – Estrutura interna do IED_generico no Helinks STS ................................................. 68 Figura 61 - Estrutura interna da instância de RCB do IED2_lab no Helinks STS ...................... 69 Figura 62 – Interface de comunicação com o utilizador do Conversor SCL ............................... 69 Figura 63 – IED’s considerados dentro da descrição de uma subestação no Helinks STS ....... 70 Figura 64 – Estrutura interna do IED2_lab no Helinks STS ........................................................ 71 Figura 65 - Relatório da importação de um ficheiro SCD para o DIGSI ..................................... 72 Figura 66 - Relatório da importação de um ficheiro SCD do DIGSI ........................................... 72 Figura 67 – IED’s considerados dentro da descrição de uma subestação no DIGSI ................. 73 Figura 68 - Estrutura interna da instância de RCB do IED_0010 no DIGSI ............................... 73 Figura 69 - Estrutura interna da instância de RCB do IED2_lab no DIGSI ................................ 74 Figura 70 – DIGSI manager ........................................................................................................ 81 Figura 71 – IED’s considerados dentro da descrição de uma subestação no DIGSI ................. 81 Figura 72 – Relatório da exportação de um ficheiro SCD do DIGSI ........................................... 82 Figura 73 – Propriedades do ficheiro IEC 61850 station ............................................................ 82 Figura 74 - Relatório da importação de um ficheiro SCD do DIGSI ........................................... 82 Figura 75 – Visualização de um ficheiro SCL no Visual SCL ..................................................... 83 Figura 76 – Propriedades do ficheiro IEC 61850 station ............................................................ 84 Figura 77 – Relatório da importação de um ficheiro SCD para o DIGSI .................................... 84 Figura 78 – Erros do relatório de importação de um ficheiro SCD para o DIGSI ....................... 85 Figura 79 – Visualização de um ficheiro SCD no XML Copy Editor ........................................... 86 Figura 80 – Comparação entre ficheiros no editor de código XML (lado esquerdo: DIGSI; lado direito: Visual SCL) ...................................................................................................................... 86 Figura 81 – Relatório de importação de um ficheiro SCD para o DIGSI .................................... 87 Figura 82 - Visualização da organização dos IED’s considerados num ficheiro SCL no Helinks STS .............................................................................................................................................. 88 Figura 83 - Relatório de importação de um ficheiro SCD para o DIGSI ..................................... 89 Figura 84 – Aspecto do código fonte do Conversor SCL ............................................................ 90
ix
Lista de Tabelas
Tabela 1- Correspondência entre funcionalidades do SPCC (Painel de Linha AT) e classes de
nós lógicos ................................................................................................................................... 25
Tabela 2 – Correspondência entre os nomes dos IED’s e respectivos fabricantes ................... 30
Tabela 3 – Simbologia seguida pelo Helinks STS ...................................................................... 31
Tabela 4 - Correspondência entre os nomes dos IED’s e respectivos fabricantes .................... 42
Tabela 5 – Correspondência entre os nomes do IED’s e os resultados experimentais obtidos 47
Tabela 6 - Correspondência entre funcionalidades do SPCC (Painéis de MT) e classes de nós
lógicos ......................................................................................................................................... 79
Tabela 7 - Correspondência entre funcionalidades do SPCC (Painéis de AT) e classes de nós
lógicos ......................................................................................................................................... 80
x
Lista de Abreviações
ASE – Applied Systems Engineering, Inc
AT/MT – Alta Tensão / Média Tensão
BRCB – Buffered Report Control Blocks
CB – Control Block
CC - Centro de Comando
CER - Centro de Engenharia Remoto
CID – Configured IED Description
DA – Data Attributes
DO – Data Objects
EDP – Energias de Portugal
FC – Functional Constraint
GOOSE – Generic Object Oriented Substation Event
HMI – Human Machine Interface
ICD – IED Configuration Description
IEC – International Electrotechnical Commission
IED – Intelligent Electronic Device
LAN – Local Area Network
LD – Logical Device
Lnode – Logical Node
PCL - Posto de Comando Local
PD – Physical Device
PICOM – Piece of Information for Comunications
RCB – Report Control Block
SCD – Substation Configuration Description
SCL – Substation Configuration Language
SGCB – Setting Group Control Block
SPCC – Sistema de Protecção, Comando e Controlo numérico
SSD – System Specification Description
TPU – Unidade Terminal de Protecção
UC - Unidade Central
URCB – Unbuffered Report Control Blocks
XML – Extensible Markup Language
1
1 Introdução
1.1 Enquadramento
O advento da norma de comunicações IEC 61850 (International Electrotechnical Commission 61850)
estabelece métodos que permitem padronizar a comunicação e propiciar benefícios inovadores na
configuração de subestações de energia eléctrica. Como tal, a última década foi um período de
grande desenvolvimento ao nível da aplicação da tecnologia digital aos relés dos sistemas de protec-
ção, tornando os IED’s (Intelligent Electronic Devices) em sistemas cada vez mais complexos. A
norma IEC 61850 foi especialmente desenvolvida para o meio Ethernet, meio padrão de comunicação
já consolidado e disponível no mercado, que permite aos equipamentos de diferentes fabricantes
comunicar entre si em alta velocidade (100 Mbit/s), trocando informações, decidindo e operando com
mais segurança e eficácia no nível de bay. Este princípio de actuação denominado como interopera-
bilidade, permite evitar que “avalanches” de informação recaiam unicamente sobre as entidades res-
ponsáveis pela gestão do sistema, podendo bloquear e atrasar a actuação de todo o sistema. Por
outro lado, a noção de interoperabilidade também se situa ao nível da comunicação entre ferramentas
de configuração, ou entre IED’s e um configurador, as quais se revestem de especial relevância neste
trabalho.
A padronização na comunicação prevista pela norma permitirá ainda a redução dos custos de enge-
nharia e manutenção. As vantagens da aplicação da norma também se situam ao nível dos proces-
sos de expansão do sistema que terão consequentemente custos de actualização muito inferiores
aos que se praticam actualmente. Acresce ainda que a maior virtude da norma reside na descrição de
toda a subestação – incluindo IED – por objectos comuns (nós lógicos) e uma linguagem para mani-
pular todos estes dados. Desta forma, conclui-se que a eventual aplicação da norma IEC 61850 às
subestações de energia eléctrica nacionais trará benefícios operacionais e financeiros, o que pro-
move hoje discussões da sua aplicação também em outras áreas como saneamento e gás.
Uma grande parte da evolução dos sistemas actuais de modo a que consigam lidar com a norma IEC
61850 decorre no sentido do aumento das funcionalidades previstas para os mesmos, pelo que a
quantidade de parâmetros configuráveis assumiu uma característica de crescimento exponencial, tor-
nando consequentemente a tarefa das parametrizações por parte dos engenheiros envolvidos nos
projectos, num processo exaustivo com elevadas taxas de probabilidade de erros associadas. Para
ajudar no processo de configurações dos relés de protecção começaram assim a surgir ferramentas
com um papel auxiliar nas parametrizações.
É essencialmente na fase de interacção entre ferramentas que será mais provável que residam
grande parte dos problemas de incompatibilidades, tendo sido neste ponto em particular que o pre-
sente documento centrou a sua abordagem.
2
1.2 Objectivos
O presente documento contempla uma breve descrição dos objectivos da norma IEC 61850 e da lin-
guagem SCL (Substation Configuration Language), e de como ambos os conceitos devem ser traba-
lhados de forma a ser possível aplicá-los no contexto de um projecto real de configuração de uma
subestação de energia eléctrica.
Faz-se uma descrição da automação em subestações, introduzindo o conceito de Projecto-Tipo de
subestações AT/MT utilizado pela EDP. Através desta descrição é apresentada a estrutura de uma
subestação tipo, mais especificamente, dos conceitos relacionados com a sua arquitectura e SPCC
(Sistema de Protecção, Comando e Controlo numérico).
No sentido da integração da norma IEC 61850 no Projecto-Tipo foram executados extensos procedi-
mentos de testes em ambiente laboratorial recorrendo a unidades de protecção de dois fabricantes
distintos, Efacec e Siemens. Recorrendo às ferramentas de configuração de IED’s específicas dos
fabricantes foi possível explorar algumas das características internas dos dispositivos, dando especial
atenção às compatibilidades com a norma conferidas aos aparelhos.
Foram ainda testadas duas ferramentas de configuração de sistema, Visual SCL e Helinks STS.
Recorrendo a estas ferramentas, para além da construção gráfica da subestação e da configuração
dos elementos associados à mesma, foi possível criar todos os formatos de ficheiros SCL, proporcio-
nando a elaboração de ensaios experimentais no sentido de testar a comunicação entre as ferra-
mentas de configuração de sistema e as ferramentas de configuração de IED’s.
Tendo em conta a linha orientadora do Projecto-Tipo, onde se procura encontrar uma solução de
configuração única, recorrendo sempre em primeira análise a ferramentas de carácter universal para
desempenhar as funcionalidades previstas, foi-se consolidando a ideia de que seria bastante interes-
sante a construção de um software específico que facilitasse este propósito. Este software só é
necessário porque as ferramentas de engenharia testadas não são interoperáveis, contrariamente ao
que era expectável visto terem sido desenvolvidas com o propósito de se adaptarem às especificida-
des da norma IEC 61850. Foi assim desenvolvido em linguagem de programação C++, um algoritmo
que permite importar ficheiros SCL com IED’s genéricos, exportando posteriormente um ficheiro SCL,
com uma descrição da subestação com base em IED’s reais.
1.3 Organização da Dissertação
O presente documento está organizado em 6 capítulos. De seguida, apresenta-se uma descrição
detalhada do conteúdo de cada capítulo:
No capítulo 1 foi feita a introdução ao documento.
No capítulo 2 introduziram-se os tópicos essenciais da norma IEC 61850, tendo-se destacado todos
os conceitos fundamentais indispensáveis para uma correcta compreensão do resto do documento,
3
mais concretamente, hierarquia e organização funcional dos IED’s, Logical Node class, linguagem
SCL e Control Blocks. A grande maioria destes tópicos remete para a parte 7-2 da norma [2] que tem
um papel essencial, visto que é nesta parte que são descritos os serviços de comunicação com os
nós lógicos, nomeadamente através da comunicação vertical (configuração).
No capítulo 3 apresentou-se uma visão global do Projecto-Tipo da EDP, seguida de uma análise de
todos os pontos do mesmo onde está implícita uma interacção com a norma IEC 61850. Mais especi-
ficamente, a análise do documento recaiu sobre o SPCC. É ainda apresentado um exemplo da confi-
guração da subestação tipo segundo a norma IEC 61850, através da ferramenta de configuração de
sistema, Helinks STS.
No capítulo 4 é explorada a estrutura interna dos IED’s dos dois fabricantes que estão disponíveis, a
fim de identificar eventuais discrepâncias nos modelos SCL que foram seguidos pelos mesmos. Foi
testada a configuração de alguns CB’s e explorado o processo de interacção entre os ficheiros SCL
construídos e as diversas ferramentas de engenharia. Para finalizar, é explicado pormenorizada-
mente um software programado em linguagem C++, cuja construção pretende estabelecer uma
interacção com as ferramentas de engenharia exploradas, com a finalidade de facilitar todo o
processo de configuração de uma subestação com base na norma IEC 61850.
O capítulo 5 é dedicado às conclusões que foram retiradas de todos os procedimentos e investiga-
ções que tiveram lugar ao longo de todos os capítulos.
No capítulo 6, foram mencionadas todas as referências bibliográficas utilizadas no trabalho.
4
2 Norma IEC 61850
A norma IEC 61850 surgiu no sentido de tentar criar um protocolo único relacionado com a automa-
ção, resolvendo um problema antigo relacionado com que a existência de múltiplos protocolos, muitos
deles estabelecidos pelos próprios fabricantes. Esta noção, passa essencialmente por garantir a inte-
roperabilidade de aparelhos de diferentes fabricantes, que começou a ser cada vez mais um desejo
incontornável dos utilizadores de aparelhos de automação nas subestações. Por interoperabilidade
entende-se a capacidade de dois ou mais IED’s de um mesmo fabricante, ou de fabricantes diferen-
tes, trocarem dados com vista a uma cooperação entre aparelhos dentro da subestação.
A norma IEC 61850 apresenta-se ao mercado dos fabricantes de protecções como uma inevitabili-
dade começando a ser encarada cada vez mais como um requisito fundamental para a construção de
subestações das grandes companhias eléctricas.
No entanto, a aplicação prática da norma IEC 61850 ainda não está complemente assegurada, visto
que os equipamentos e softwares “IEC 61850 friendly” ainda passam por extensos processos de
experimentação e evolução. Neste contexto, o presente documento apresenta e comenta alguns dos
resultados obtidos em procedimentos experimentais realizados em laboratório. Sempre que possível
são explicados e solucionados os problemas encontrados, bem como apresentadas soluções que
permitam colmatar situações que se tenham revelado problemáticas.
Grande parte dos procedimentos experimentais teve por base uma nova linguagem trazida pela
norma IEC 61850, a SCL. Esta definição da linguagem de configuração de subestações tem como
funcionalidade principal padronizar as informações relativas aos diferentes IED’s, ou seja, os modelos
de dados. Com base neste novo conceito é possível estabelecer o mapeamento dos diferentes nós
lógicos nos respectivos IED’s que os implementam. Adicionalmente, podem ser acopladas informa-
ções referentes aos canais de comunicação e funcionalidades específicas de cada equipamento de
manobra que se podem associar a determinados painéis da subestação através da sua correcta
representação num esquema unifilar da subestação.
2.1 Hierarquia funcional dos IED’s
Um dos conceitos essenciais apresentados pela norma IEC 61850 é o IED, representativo de uma
unidade multifuncional para a protecção, controlo, medição e monitorização de sistemas eléctricos. A
norma prevê a alocação de funções, em que as funcionalidades necessárias para o correcto funcio-
namento de uma subestação podem estar alocadas num IED específico ou distribuídas pelos diver-
sos IED’s da subestação. Estes dispositivos possibilitam diferentes tipos de interface com o usuário,
sendo de salientar a comunicação remota como a mais interessante no actual contexto das subesta-
ções. Este tipo de interface de comunicação é possível recorrendo às portas de comunicação TCP/IP.
Neste caso, cada porto de comunicação de um IED apresenta um endereço IP que possibilita a troca
5
informações entre este dispositivo e um ambiente de rede Ethernet, onde podem existir muitos outros
dispositivos.
No parágrafo anterior foi realçada a comunicação física de IED’s. Contudo, no âmbito deste trabalho
a comunicação lógica (PICOM - Piece of Information for Comunications) [4] entre nós lógicos reveste-
se de especial importância, dado que é através dela que é possível estabelecer comunicação de
dados entre as diversas entidades virtuais. As três componentes fundamentais da comunicação
PICOM são:
Dados que foram enviados entre nós lógicos
Formato dos tipos de dados transaccionados
Informação da performance da transacção de dados
Na Figura 1 está representado graficamente o modelo teórico de um IED tal como a norma IEC 61850
o define. Como se pode reparar o modelo apresenta uma estrutura hierárquica onde se vão consecu-
tivamente definindo todas as estruturas que o compõem. No topo do modelo (a cinzento) encontra-se
o PD (Physical Device), responsável por guardar todos os dados indispensáveis à conexão do IED à
rede existente. Todas as restantes instâncias como o LD (Logical Device), Lnodes (Logical Nodes) e
os DO (Data Objects), encontram-se ramificadas segundo uma hierarquia que pode ser analisada na
referida figura. Estas instâncias são responsáveis por armazenar toda a informação relativa às fun-
cionalidades possíveis de implementar pelo IED.
Figura 1 - Modelo do IED segundo a norma IEC 61850 [8]
A figura anterior pretende apenas dar uma visão conceptual da estrutura de um IED. Embora con-
ceptualmente seja fácil percepcionar o modelo do IED, a extensa quantidade de funcionalidades pre-
vistas pelos fabricantes para estes dispositivos requer uma estrutura mais cuidada onde sejam devi-
damente acautelados todos os dados indispensáveis para uma correcta aplicação prática da norma
IEC 61850.
6
A hierarquia funcional de um IED deve considerar todos os níveis evidenciados na Figura 2. Porém
esta estrutura apresenta um certo grau de flexibilidade, originando situações em que cada fabricante
segue uma filosofia própria.
Figura 2 – Hierarquia Funcional do IED segundo a norma IEC 61850 [9]
O grande número de nós lógicos que podem ser incluídos dentro de um determinado LD pode rapi-
damente exceder os limites da percepção imediata das suas funcionalidades, pelo que determinados
fabricantes optam por dividi-los segundo as suas funcionalidades criando assim aglomerados de nós
lógicos com as mesmas características funcionais. Contudo, esta temática vai ser aprofundada em
detalhe na secção 2.4.
Na lista que se segue são explicadas de uma forma intuitiva todas as instâncias que podem ser anali-
sadas na Figura 2.
Logical Device: Cada IED tem associado um LD, onde se encontram organizados todos os
dados necessários para cumprir as funcionalidades para as quais o IED foi previsto.
Function: Os nós lógicos permitem realizar vários tipos de funções, que podem ser divididas
em grupos funcionais principais, denominados de Function.
o Por exemplo: Protection e Non-protection
Sub-Function: Este nível hierárquico permite descriminar os diversos subgrupos funcionais
disponibilizados pelo fabricante.
o Por exemplo: Protection Functions, Control Functions, Measurements, etc.
Function Element: Neste nível encontram-se organizados todos os nós lógicos que foram
previstos para um determinado IED, consoante a aplicação prática que este vai ter na
subestação.
7
o Por exemplo: PTOC, PTUV, PTOV, etc.
Settings: Os DO’s são utilizados para modelizar individualmente os settings de um determi-
nado nó lógico.
o Por exemplo para o nó lógico PTOC: StrVal (Start Value), OpDlTmms (Operate Delay
Time), etc.
Setting Attributes: Os DA’s (Data Attributes) são utilizados para modelizar os atributos de
um determinado setting.
o Por exemplo para PTOC.OpDlTmms: setValue, minValue, maxValue, stepSize, etc.
2.2 Logical Node class
Na parte 7-4 do documento que constitui a norma IEC 61850 [3], são especificadas cuidadosamente
quais as classes de nós lógicos disponíveis. Cada um destes nós lógicos é definido segundo uma
estrutura genérica composta por várias secções, tal como está representado na figura que se segue.
Figura 3- Estrutura interna genérica de um nó lógico segundo a norma IEC 61850 [1, Figura 3]
Todas as classes de nós lógicos previstas pela norma IEC 61850 são especializações efectuadas
sobre a classe Common Logical Node, que se encontra descrita na Figura 4.
8
Figura 4 - Constituição da classe Common Logical Node segundo a norma IEC 61850 [3, capítulo 5.3.3]
Na Figura 5 encontra-se representado um exemplo da concretização da estrutura da figura anterior a
um nó lógico específico, este caso concreto diz respeito à classe PTOC (Máxima Intensidade de Cor-
rente). A análise da referida figura evidencia que um nó lógico consiste essencialmente num grupo de
dados.
Figura 5- Constituição da classe PTOC segundo a norma IEC 61850 [3, capítulo 5.4.18]
9
Na figura anterior podem ser analisadas grande parte das secções de dados esquematizadas na
Figura 3, nomeadamente:
Common Logical Node Information
Status Information
Settings
Aos atributos definidos dentro das várias secções listadas, está associada uma variável que define
se a presença desse atributo é mandatória ou opcional, tal como pode ser observado na coluna mais
à direita da Figura 5 (M – Mandatory; O - Optional). Esta possibilidade de poder escolher se algum
dos atributos é ou não adicionado à estrutura de um determinado nó lógico confere aos fabricantes a
liberdade de não incorporar alguns atributos nas suas definições da estrutura de um determinado nó
lógico.
2.3 Logical Node Zero (LLN0)
O LLN0 (Logical Node Zero) é um dos nós lógicos mais importantes dado que é através dele que são
estabelecidos todos os serviços previstos pela norma IEC 61850, como por exemplo, o SGCB (Set-
ting Group Control Block) e os GOOSE (Generic Object Oriented Substation Event). Estes serviços
são responsáveis pela comunicação entre nós lógicos, e como tal assumem um papel central na con-
figuração da subestação.
Na Common Logical Node class (Figura 4) é importante notar que não foram apenas definidos atribu-
tos, estando também presentes na estrutura algumas secções adicionais, tais como Data Sets, Con-
trol Blocks e Services.
Segundo a Parte 7-2 da norma IEC 61850 [2], entende-se por CB’s as seguintes classes:
Buffered Report Control Blocks
Unbuffered Report Control Blocks
Log Control Blocks
Setting Group Control Block
GOOSE Control Blocks
GSSE Control Blocks
Multicast Sample Value Control Blocks
Unicast Sampled Value Control Blocks
10
Recorrendo à definição da classe de um nó lógico genérico descrita na Figura 6, pode observar-se na
secção delineada a vermelho a especialização desta classe para implementar o LLN0. Conclui-se
assim, que o nó lógico em análise vai ser responsável por grande parte dos serviços previstos pela
norma, onde se podem incluir funcionalidades tão importantes como a comunicação vertical e hori-
zontal. No entanto, a aplicação deste nó lógico pode seguir filosofias distintas. Por exemplo na
esquematização da estrutura de um IED da Figura 2, pode ser analisada a existência de apenas um
LLN0 para todo o aglomerado de nós lógicos dentro do IED, porém existem outras metodologias onde
se cria uma instância de LLN0 para cada umas das secções funcionais criadas: Protection Functions,
Control Functions, Measurements, etc. Contudo, este tópico vai ser abordado com maior detalhe no
capítulo que se segue.
Figura 6- Constituição da classe Logical Node segundo a norma IEC 61850 [2, Tabela 15]
2.4 Organização funcional de nós lógicos
Na secção 2.1 foi representada a estrutura hierárquica do modelo de um IED (Figura 2), tendo sido
descrito que a secção Sub-Function era utilizada para discriminar os diversos subgrupos funcionais
disponibilizados pelo fabricante. Cada um destes subgrupos incorpora os nós lógicos presentes num
determinado IED, cujo âmbito de actuação se insere na descrição funcional desse subgrupo. Por
exemplo:
Protection
11
o PTOC
o PTOV
o PTUV
o XCBR
o etc
Control
o CILO
o XSWI
o CSWI
o etc
Measurement
o MMTR
o MMXU
o MSQI
o etc
Disturb Rec
o RDRE
o etc
Esta organização dos nós lógicos com base nas suas áreas funcionais não é uma especificação da
norma IEC 61850, dependendo única e exclusivamente da vontade própria de cada fabricante. Na
secção 4.1 vão ser analisadas as estruturas internas de organização seguidas pelos dois fabricantes
considerados neste trabalho.
2.5 Linguagem SCL
Uma das grandes novidades da norma IEC 61850 foi sem dúvida a introdução de uma linguagem
universal de configuração de subestaçãoes ,a SCL. Esta nova linguagem de alto nível é baseada no
XML (Extensible Markup Language), e a sua utilização permite obter uma uniformização dos métodos
de configuração da subestação e da nomenclatura utilizada através de um modelo único de descrição
de dados , criando um vocabulário comum.
Através do estabelecimento de regras de formatação dos ficheiros, e da criação de estruturas bem
definidas, é possivel garantir com mais fiabilidade o intercâmbio de descrições das funcionalidades
dos IED’s e da descrição do sistema de automação da subestação. Torna-se assim possível executar
uma comunicação bidireccional entre as ferramentas de configuração de IED’s e as ferramentas de
configuração de sistema. Esta comunicação garante a interoperabilidade entre as várias ferramentas
de engenharia de diferentes fabricantes, permitindo uma configuração da subestação com
independência dos IED’s e das suas ferramentas especificas.
12
A norma IEC 61850 define vários tipos de ficheiros SCL com funções distintas, que podem ser
devidamente identificados pela sua extensão.
ICD (IED Capability Description): Descreve as capacidades do IED descrito pelo fabricante
em termos de funções de comunicação e de modelo de dados.
SSD (System Specification Description): Descreve o esquema unifilar da subestação
juntamente com as funções executadas no equipamento primário, em termos de nós lógicos.
SCD (Substation Configuration Description): Descreve a configuração da comunicação e
das funções do sistema de automação da subestação e a sua relação com a subestação.
Contém todos os IED’s, uma secção de descrição da subestação e uma secção da
configuração da subestação.
CID (Configured IED Description): Descreve uma instância de um IED totalmente configu-
rado.
Na Figura 7 encontra-se descrito o método básico de interacção entre os ficheiros SCL e as
ferramentas de engenharia.
Figura 7- Interface de comunicação de ficheiros SCL entre ferramentas de engenharia
Na secção 4 vão ser explorados aprofundadamente alguns métodos de interacção entre as
ferramentas de engenharia que recorrem a ficheiros SCL, e expostos todos os problemas
encontrados durante o decorrer das fases de teste.
Ferramenta de
configuração de
IEDs
Ferramenta de
configuração de
sistema
Ferramenta de
configuração de
IEDs
13
2.6 Control Block’s (CB’s)
A norma IEC 61850 define um grande grupo de blocos funcionais ao qual chama CB’s (Control
Block’s). Englobados neste grupo encontram-se: RCB (Report Control Block), LCB (Log Control
Block), SGCB (Setting Group Control Block), entre outros.
2.6.1 Setting Group Control Block (SGCB)
O SGCB pretende trazer para a realidade da norma IEC 61850, uma funcionalidade utilizada nos
relés digitais que consiste na existência de vários cenários de parametrização para uma mesma
função de protecção.
A estrutura organizativa deste CB e o seu método de funcionamento, encontram-se explicados
graficamente na Figura 8. Na situação representada está em análise o nó lógico PVOC, para o qual
se encontram descritos alguns dos atributos que o constituem. Na referida figura é possível analisar a
associação de valores aos seus atributos (parte esquerda da imagem). O conjunto de todos estes
valores constitui uma parametrização possível entre uma gama de três possíveis parametrizações
que estão disponíveis (parte direita da imagem, com #).
Figura 8- Definição de SGCB segundo a norma IEC 61850 [2, Figura 17]
No caso específico representado na figura anterior, foram previstos três cenários de actuação. Cada
um destes cenários guarda um conjunto de parametrizações para os nós lógicos que o operador de
sistema pode configurar. Desta forma ao fazer variar o cenário em vigor, são comutados os atributos
de todos os nós lógicos previstos.
14
Dada a grande responsabilidade e complexidade do SGCB, a norma definiu um grande número de
atributos e de serviços associados a este CB. A criação de variáveis de controlo permite de certo
modo, a simplificação e maior flexibilidade de todo o processo de configuração e parametrização das
funções de protecção.
Na Figura 9 está representada a estrutura da classe SGCB onde estão definidos quais os atributos e
serviços previstos para este CB específico.
Figura 9 – Constituição da classe SGCB segundo a norma IEC 61850 [2, Tabela 22]
Entre o grande número de atributos definidos dentro da classe SGCB (Figura 9), destacam-se o
“NumOfSG” e o “ActSG”, cujos valores associados representam o número de cenários disponíveis na
subestação e o cenário que está actualmente em vigor.
Entre a lista de serviços que a classe SGCB engloba, encontra-se por exemplo o “SetSGValues” que
permite ao operador de sistema parametrizar um determinado cenário de actuação, ou ainda o
“SelectActiveSG” que permite ao operador comutar o cenário de parametrizações em vigor, tudo
recorrendo a uma ferramenta de configuração de sistema universal.
Tendo em linha de conta a ambição da norma IEC 61850, é esperado que os fabricantes programem
as suas ferramentas de configuração para que consigam lidar com todas as variáveis necessárias
para a correcta implementação deste CB. Contudo, aos fabricantes não é exigido que considerem na
construção dos seus ficheiros SCL estes atributos e serviços. Na secção 4.5 irá ser analisado de
forma pormenorizada quais as funcionalidades previstas na classe SGCB que a Siemens e a Efacec
decidiram considerar nos seus IED’s.
2.6.2 Report Control Block (RCB)
Na norma IEC 61850 é possível distinguir dois níveis de comunicação distintos, a comunicação
vertical e a comunicação horizontal. A comunicação horizontal mais conhecida por GOOSE,
15
estabelece canais de comunicação entre os diferentes IED’s presentes na subestação, enquanto a
comunicação vertical (RCB) estabelece as ligações de troca de dados entre os IED’s e a UC
(Unidade Central). Embora ambos os tipos de comunicação sejam de extrema relevância, o presente
documento incide a sua abordagem unicamente sobre o nível de comunicação vertical dos IED’s.
A Figura 10 pretende representar graficamente os dois tipos de comunicação atrás mencionados.
Delineado a cor vermelha encontra-se representado o canal destinado à comunicação vertical, por
outro lado, as ligações a azul representam o canal destinado à comunicação horizontal.
Figura 10 - Comunicação vertical e horizontal no SPCC [10]
Da mesma forma que o já referido SGCB, também o RCB se assume como um bloco funcional
prioritário, sendo a partir desta funcionalidade que o operador de sistema consegue configurar
previamente quais os atributos da subestação a que deseja ter acesso sob a forma de um relatório.
Ou seja, é através da parametrização do RCB que se torna possível configurar a comunicação
vertical. No entanto, existe uma relação entre os dois níveis de comunicação, dado que através da
comunicação vertical, é possível configurar a comunicação horizontal.
Na secção 2.3 respeitante ao LLN0 foi criada uma lista com todos os CB’s previstos na norma. No
que diz respeito ao RCB existem duas entradas na lista, mais especificamente:
BRCB (Buffered Report Control Block)
URCB (Unbuffered Report Control Block)
As duas entradas listadas acima também podem ser observadas na estrutura interna no Logical Node
class representada na Figura 6. No entanto, os atributos que se desejam comunicar verticalmente
não são parametrizados directamente nos BRCB e URCB, dado que para este efeito foi criada pela
norma uma variável auxiliar denominada “DataSet”, igualmente com representação na Figura 6. É
nesta variável que podem ser organizados todos os atributos que se pretendem comunicar, sendo
possível criar diversas instâncias desta variável. Para finalizar o processo de parametrização do RCB
é apenas necessário associar instâncias do tipo “DataSet”, a instâncias do tipo RCB.
16
2.7 Ferramentas de Engenharia
A generalidade dos fabricantes de protecções começou a adaptar os seus equipamentos às
necessidades impostas pela norma. Este processo de adaptação envolve a criação de ferramentas
de engenharia que paralelamente à configuração dos IED’s consigam criar e lidar com os diferentes
formatos de ficheiros SCL. Este procedimento torna possível lidar com os seus IED’s no ambiente da
norma IEC 61850 ao nível da ferramenta de configuração de IED’s e ao nível da ferramenta de
configuração de sistema. Chegada a fase de configuração da subestação, é requerido que estes dois
níveis de ferramentas estabeleçam canais de comunicação entre si.
A norma IEC 61850 não prescreve como são realizados internamente os nós lógicos nem o que
fazem. Logo, e como consequência, os IED’s não têm de ser alterados em função da norma,
exceptuando a sua formatação que tem de ser normalizada de acordo com a mesma. Esta
normalização não requer a alteração dos IED’s, dado que as ferramentas de configuração
intermediárias passam a ser as verdadeiras interfaces dos IED’s perante a norma.
As ferramentas de configuração de sistema têm de ser capazes de importar e exportar ficheiros de
configuração na linguagem SCL, com base nas regras definidas na parte 6 da norma IEC 61850 [5].
Estas ferramentas têm de ser dotadas da capacidade de importar tantos ficheiros de configuração de
IED’s, quantos aqueles que se desejem instalar num determinado projecto de uma subestação. Estes
ficheiros descritivos dos IED’s têm de ser gerados pelas respectivas ferramentas de configuração de
IED’s. Posteriormente, o configurador de sistema tem de gerar um ficheiro com a configuração da
subestação, que tem de ser recepcionado pelas ferramentas de configuração de IED’s, de modo a
que todas as configurações sejam devidamente percepcionadas por todos os IED’s constituintes da
subestação.
Na Figura 11, encontra-se descrito genericamente o método segundo o qual terão de ser geridos os
formatos de ficheiros SCL que estão directamente envolvidos na comunicação de dados entre as
diversas ferramentas de engenharia, mais concretamente, ICD e SCD.
Figura 11 – Diagrama funcional da comunicação de ficheiros SCL entre ferramentas de engenharia
ICD
SCD
Ferramenta de
configuração de
IEDs
Ferramenta de
configuração de
sistema
17
No desenvolvimento do trabalho foram utilizadas ferramentas proprietárias de dois fabricantes de
protecções, a Efacec e a Siemens. Contudo, não se recorreu apenas a ferramentas criadas pelos
próprios fabricantes, tendo sido também consideradas ferramentas de terceiros, sem uma relação
directa com o fabrico de unidades de protecção, como é o caso da ASE (Applied Systems
Engineering, Inc) e da Helinks LLC. O uso destas ferramentas desenvolvidas fora do contexto dos
próprios fabricantes de protecções, é um factor decisivo para a configuração de uma subestação
reutilizável, visto que o processo de construção destes softwares deve ter seguido um princípio de
universalidade de utilização, não devendo depender dos fabricantes que se pretendem utilizar no
projecto. Este facto é preponderante para este trabalho, onde se deseja chegar a uma configuração
da subestação, pautada pela imparcialidade em relação aos fabricantes considerados. Em última
análise, nunca vai ser possível contornar completamente a necessidade de recorrer às ferramentas
dos fabricantes, mas vai-se tentar reduzir-se ao máximo esta necessidade.
As ferramentas de configuração de sistema utilizadas durante as fases de teste foram as seguintes:
o Visual SCL (fabricante: ASE)
o Helinks STS (fabricante: Helinks LLC)
o DIGSI (fabricante: Siemens)
As ferramentas de configuração de IED’s utilizadas durante as fases de teste foram as seguintes:
o WinSettings (fabricante: Efacec)
o DIGSI (fabricante: Siemens)
Os procedimentos que vão ter lugar durante as fases de teste, têm por base a filosofia de
configurações permitida pelo software de configuração de sistema, Helinks STS. Esta ferramenta foi
escolhida em detrimento do Visual SCL, dado que após extensa utilização de ambos os programas, o
Visual SCL revelou alguns problemas de fundo que vão ser relatados nos próximos capítulos.
2.7.1 Ferramentas de Configuração de Sistema
Tanto o Visual SCL como o Helinks STS possuem uma interface gráfica forte que permite ao
utilizador criar, configurar, visualizar e editar todos os elementos de uma subestação e todos os
modelos de dados a ela associados.
O DIGSI é uma ferramenta mista, dado que funciona tanto como configurador de IED’s como de
sistema. Contudo, enquanto ferramenta de configuração de sistema é relativamente diferente das
restantes. Embora também permita a importação de ficheiros descritivos de IED’s de outros
fabricantes, e consiga exportar um ficheiro SCD com todos os IED’s associados, não possibilita a
18
construção do esquema unifilar da subestação e o posterior mapeamento de IED’s aos diversos
painéis da subestação.
Qualquer uma das ferramentas facilita a interacção com a norma ao nível da linguagem SCL, dado
que permite ao utilizador configurar subestações e criar todos os tipos de ficheiros SCL sem possuir
qualquer conhecimento da linguagem XML.
2.7.2 Ferramentas de Configuração de IED’s
De forma a obter todos os dados de uma unidade de protecção da Efacec, é necessário recorrer a
uma ferramenta de configuração de IED’s específica do fabricante desta protecção, o WinSettings.
Esta ferramenta apresenta uma interface de alto nível robusta e amigável das unidades de protecção
e controlo da Efacec da gama 420. O WinSettings é composto por vários módulos que permitem a
parametrização de cada protecção, sendo também possível comparar parametrizações entre relés
diferentes e copiar dados de um relé para outro.
O DIGSI constitui o programa de configuração das unidades de protecção da Siemens. Através deste
software é possível configurar e implementar alguns dos aspectos práticos mais importantes da
norma IEC 61850.
19
3 Projecto-Tipo da EDP
O Projecto-Tipo da EDP é constituído por extenso conjunto de documentos técnicos com um espectro
muito abrangente de áreas de actuação, onde se estabelecem as características técnicas que a
subestação tipo AT/MT deverá contemplar na sua instalação.
Os objectivos prioritários que se pretendem atingir na implementação de um projecto desta natureza,
são os seguintes:
Projecto normalizado que consiga articular as diferentes áreas técnicas de uma subestação:
o Construção Civil
o Equipamentos
o SPCC
Solução modular e flexível com capacidade de adaptação às necessidades específicas da
rede que não ponha em causa o acompanhamento da evolução tecnológica;
Simplificação das soluções técnicas aplicadas nas diferentes áreas projecto, bem como a
consequente optimização do espaço necessário para a sua implementação;
Redução dos prazos e custos de projecto e posterior construção;
Melhoria dos níveis de continuidade e qualidade de serviço;
De todas as áreas funcionais listadas o presente documento incide a sua análise apenas na temática
relacionada com o SPCC.
A título de curiosidade achou-se interessante referir as localizações típicas de aplicação do projecto
da subestação. Este destina-se a ser implementado em instalações localizadas em áreas rurais,
urbanas ou semi-urbanas da rede de distribuição. Os níveis de tensão previstos são: 60/30 kV, 60/15
kV ou 60/10 kV para uma potência de transformação máxima de 2 x 40 MVA.
O esquema unifilar da subestação tipo para uma relação de transformação de 60/30 kV encontra-se
representado na Figura 12, onde foram contornados a vermelho os painéis segundo o nível de tensão
que têm associado.
20
Figura 12- Esquema Unifilar da Subestação 60/30 KV [6]
3.1 Arquitectura e Organização Funcional do SPCC
Tal como o nome indica o SPCC é a entidade responsável pela protecção, comando e controlo de
todos os órgãos da subestação, a sua arquitectura interna é constituída por vários módulos de
processamento de informação cuja interligação permite desempenhar todas as funções necessárias
para o correcto funcionamento da subestação, nomeadamente:
Arquitectura e configuração de princípio do sistema;
Conjunto de funções por painel que garantam o correcto funcionamento da subestação:
o Funções de comando;
o Funções de protecção;
o Funções de automatismo;
o Encravamentos;
Aquisição e gestão de informações dos processos;
Interface humano-máquina necessária para o comando e supervisão local da instalação;
Suportes de comunicação e protocolos associados;
21
Funções de supervisão e controlo à distância da subestação (p. ex. – Teleparametrização);
A arquitectura funcional do SPCC encontra-se dividida em três níveis hierárquicos interligados entre
si, tal como está representado na Figura 13:
Nível 0 – Processo (constituído pelos equipamentos AT/MT da subestação com os quais o
SPCC interage);
Nível 1 – Unidade de painel / IED;
Nível 2 – UC:
o PCL (Posto de Comando Local);
o CC (Centro de Condução);
o CER (Centro de Engenharia Remoto);
Figura 13- Arquitectura e Organização Funcional do SPCC [7]
22
A comunicação de dados entre os diferentes níveis do SPCC efectua-se através das duas LAN (Local
Area Network), mais concretamente o “Bus de processo” e o “Bus da subestação”, cujo esquema de
ligações está representado na figura anterior. A “Bus de processo” estabelece uma ligação de dados
física entre os equipamentos de AT/MT e os IED’s, da mesma forma a “Bus da subestação”
estabelece a comunicação entre os IED’s e a UC. Interessa referir que embora exista a noção
conceptual de “Nível 0” este ainda não se encontra em funcionamento nas subestações da rede de
distribuição.
3.2 Esquema Unifilar da Subestação
O esquema unifilar da subestação representa graficamente todos os componentes essenciais da
instalação eléctrica da subestação (Figura 12). No caso vertente do Projecto-Tipo de subestações
AT/MT, a subestação tipo é constituída por vários painéis com funções distintas, interligados entre si
através de linhas e barramentos. O interior dos painéis é constituído por equipamentos eléctricos, tais
como, disjuntores, seccionadores, entre muitos outros. Os tipos de painéis de AT e MT e a sua
respectiva função são definidos de seguida:
Painéis AT
o Linha AT/Transformador de Potência AT/MT – assegura a ligação directa entre a
linha de distribuição de AT e o primário do transformador de potência AT/MT;
o Linha AT – assegura a ligação entre o barramento AT e a respectiva linha de
distribuição de AT;
o Transformador de Potência AT/MT – assegura a ligação entre o barramento AT e o
primário do transformador de potência AT/MT;
o Potencial de Barras AT – assegura a ligação entre o barramento AT e os
transformadores de medida de tensão do barramento;
o Interbarras AT – assegura a ligação de dois barramentos entre si;
Painéis MT
o Chegada Transformador de Potência – assegura a ligação entre o secundário do
transformador de potência AT/MT e o barramento do quadro metálico;
o Linha MT – Assegura a ligação entre o barramento do quadro metálico e a respectiva
linha de distribuição de MT;
o Bateria de Condensadores – Assegura a ligação entre o barramento do quadro
metálico e a bateria de condensadores de MT;
23
o Transformador de Serviços Auxiliares e Reactância de Neutro – Assegura a ligação
entre o barramento do quadro metálico e o transformador MT/BT de serviços
auxiliares e a reactância de criação de neutro artificial;
o Potencial de Barras MT – Assegura a ligação entre o barramento do quadro metálico
e os transformadores de medida de tensão do barramento;
o Interbarras MT – Assegura a ligação de dois barramentos entre si;
o Ligação de Barras – Assegura a ligação de cada barramento à cela de interbarras;
3.3 Definição das funcionalidades presentes no SPCC
Na secção 3.1 quando foi introduzido o SPCC foi relatada a existência de dois tipos de funções, as de
protecção e as de automação.
As funções de protecção têm o objectivo de assegurar a detecção dos defeitos na rede e a sua
posterior eliminação no menor espaço de tempo possível, de modo a garantir uma exploração segura
e ao mesmo tempo uma elevada continuidade e qualidade de serviço. Seguidamente consideram-se
algumas das funções de protecção utilizadas no Projecto-Tipo da subestação AT/MT:
Máximo de Intensidade de Fase;
Máximo de Intensidade Homopolar;
Máximo de Tensão;
Mínimo de Tensão;
Mínimo de Frequência;
…
As funções de automação garantem uma optimização da segurança e disponibilidade do sistema,
reduzindo ainda de forma significativa o tempo de interrupção a que os consumidores podem estar
sujeitos. Estas funções actuam de forma distribuída, nas várias unidades de painel mencionadas na
secção 3.2. Na listagem que se segue foram consideradas todas funções de automatismo utilizadas
no Projecto-Tipo de subestação AT/MT:
Comutação automática de disjuntores BT;
Religação rápida e/ou lenta de disjuntores;
Pesquisa de terras resistentes;
Deslastre e reposição por tensão;
Deslastre e reposição por frequência;
24
Regulação automática de tensão;
Comando automático de bateria de condensadores;
3.4 Compatibilização com a norma IEC 61850
Um dos pontos mais importantes do trabalho, passa por analisar a adequação da linguagem SCL ao
projecto estruturado pela EDP, indispensável para que todas as configurações da subestação sejam
implementadas com sucesso.
Numa análise comparativa entre os requisitos do Projecto-Tipo e os modelos definidos na norma IEC
61850, é evidente a correspondência quase natural entre os mesmos. A arquitectura da subestação
definida pelo Projecto-Tipo pode ser facilmente implementada recorrendo aos modelos especificados
na norma IEC 61850. Por exemplo, as funções de protecção assumem uma correspondência directa
com a noção de nós lógicos.
A vocação da norma IEC 61850 é claramente direccionada para tópicos relacionados com as funções
de protecção, pelo que as funções de automação têm de ser configuradas com base noutras normas,
por exemplo, através da lógica programável definida na norma IEC 61131 ou na IEC 61449.
3.5 Correspondência entre funções do SPCC e nós lógicos
Na parte 7-4 da norma IEC 61850 [3] são apresentadas todas as classes de nós lógicos que estão
definidas presentemente. Torna-se assim indispensável fazer a correspondência directa entre as
funcionalidades previstas no Projecto-Tipo, e as respectivas classes de nós lógicos em que se
enquadram segundo os modelos definidos na norma. Posteriormente, será necessário analisar quais
os fabricantes de protecções que dispõem de IED’s onde tenham sido disponibilizados os nós lógicos
necessários para a implementação do Projecto-Tipo.
Na Tabela 1, encontra-se representada a associação entre as funções de protecção previstas pelo
Projecto-Tipo para o painel de linha de AT e os respectivos nós lógicos que as implementam segundo
os modelos definidos na norma IEC 61850 [11].
Painéis de AT Classes de nós lógicos
Funções
Linha de AT
Distância PDIS
Diferencial de linha /cabo (opcional) PDIF
Máximo de Intensidade de Fase PIOC, PTOC
Máximo de Intensidade Homopolar Direccional PIOC, PTOC
Máximo de Intensidade Homopolar de Terras Resistentes PIOC, PTOC
Power Swing Detection RPSB
25
Weak End Infeed MSQI
Ligação sobre defeito PTUV, PTUC
Condutor Partido MSQI, PTOC, PTUC
Teleprotecção PSCH
Verificação de Sincronismo RSYN
Monitorização do Disjuntor XCBR
Localização de Defeitos RFLO
Registo de acontecimentos RBDR, RDRE
Osciloperturbografia RADR, RBDR, RDRE
Tabela 1- Correspondência entre funcionalidades do SPCC (Painel de Linha AT) e classes de nós lógicos
Na secção 1 dos anexos encontram-se representadas as tabelas que fazem a correspondência entre
as funcionalidades dos restantes painéis da subestação e as respectivas classes de nós lógicos, mais
especificamente a Tabela 6 para os painéis de MT, e a Tabela 7 para os painéis de AT.
3.6 Configurações de uma subestação segundo a norma
IEC 61850
Neste capítulo são descritos os procedimentos básicos de configuração de uma subestação segundo
a norma IEC 61850, não sendo abordados os métodos de configuração de serviços relacionados com
a comunicação vertical. Para este tipo de configurações foram dedicados capítulos próprios, como é o
caso particular da configuração da comunicação vertical descrita na secção 4.4.
O método de configuração aplicado, rege-se pelas quatro fases que se seguem:
1. Desenho do esquema unifilar da subestação (Secção 3.6.1).
1. Associação de nós lógicos genéricos aos painéis da subestação (Secção 3.6.2).
2. Importação dos ICD’s dos fabricantes dos IED’s a instalar na subestação (Secção 3.6.3).
3. Mapeamento dos IED’s aos painéis que estes vão proteger na subestação (Secção 3.6.4).
3.6.1 Desenho do esquema unifilar da subestação
O desenho do esquema unifilar da subestação começa com a criação das várias estruturas que vão
conter as diversas aparelhagens. Mais especificamente, tem de ser criada uma estrutura descritiva da
subestação (Substation) e dentro desta as estruturas dos dois níveis de tensão (VoltageLevel).
Dentro de cada um dos níveis de tensão é necessário incluir os diferentes painéis de AT e MT (Bays)
considerados no Projecto-Tipo. Nesta fase interessa ainda definir a localização dos barramentos (Bus
Bar). Interessa salientar que a norma IEC 61850 não exige a elaboração do desenho do esquema
26
unifilar da subestação dado que este não constitui a descrição da subestação, sendo apenas uma
representação gráfica da subestação permitida pelas ferramentas.
Todos as estruturas mencionadas no parágrafo anterior podem ser analisadas na Figura 14,
descritiva do menu de configurações do Helinks STS que permite desenhar as estruturas básicas da
subestação. Na mesma figura os dois últimos itens (Electrical Connection, Connectivity Node), dizem
respeito aos objectos que permitem estabelecer as conexões físicas entre os diversos aparelhos
constituintes da subestação.
Figura 14 – Estruturas previstas para o desenho do esquema unifilar da subestação no Helinks STS
Após discriminar todos os painéis da subestação (Bays) já é possível começar a associar os
equipamentos eléctricos (Power Equipment) aos respectivos painéis de acordo com as
especificações que o Projecto-Tipo define para cada painel. Também os equipamentos disponíveis
para aplicação no esquema estão normalizados pela norma IEC 61850, e são disponibilizados pelo
Helinks STS no menu esquematizado na Figura 15.
Figura 15 – Equipamentos previstos para o desenho do esquema unifilar da subestação no Helinks STS
A aplicação e interligação de todos os conceitos descritos neste capítulo, permite obter o esquema
unifilar da subestação (Figura 16), tal como está definido no Projecto-Tipo (Figura 12).
27
Figura 16 – Esquema unifilar da subestação no Helinks STS
28
3.6.2 Associação de nós lógicos de protecção genéricos
aos painéis (Bays) da subestação
Após o desenho do esquema unifilar da subestação devem ser associados a todos os painéis (Bays)
os nós lógicos correspondentes às funções de protecção que estão definidas no Projecto-Tipo.
Optou-se por demonstrar a associação de nós lógicos para o caso concreto do painel de linha de AT,
dado que na Tabela 1 já foram previamente descritos todos os nós lógicos a considerar para este
painel. Centrou-se abordagem no nó lógico de maior importância relacionando com o referido painel,
mais especificamente o nó lógico PDIS responsável pela aplicação da “Protecção de Distância”.
Embora se centre a abordagem no nó lógico PDIS, os restantes nós lógicos associados ao painel de
linha de AT (Tabela 1), são maioritariamente assegurados pela unidade de protecção SIPROTEC
7SA522 da Siemens [12]. Esta unidade de protecção foi configurada com a descrição IED_0010.
Doravante, a unidade de protecção responsável pelo nó lógico PDIS será mencionada como
IED_0010.
O Helinks STS disponibiliza na sua base de dados interna todas as categorias de nós lógicos
considerados na parte 7-4 da norma IEC 61850 [3], tal como demonstrado na Figura 17. Os nós
lógicos encontram-se seccionados por áreas funcionais, sendo que para exemplificação do método
de em análise foi escolhida a área “P – Protection Functions”. Tal como o nome indica, a área
funcional referenciada compila todos os nós lógicos respeitantes às funções de protecção.
Figura 17 – Lista das áreas funcionais de Logical Nodes considerados no Helinks STS
Na Figura 18 encontra-se representada a bay respeitante ao painel de chegada da linha de AT. Na
referida figura além de se poder analisar todos os aparelhos associados e as suas interligações, é
29
também visível no canto superior esquerdo da imagem uma indicação respeitante ao nó lógico PDIS.
Esta indicação pretende salientar que a esta bay se encontra associada a função de protecção de
distância. Para uma correcta definição do esquema unifilar da subestação, a associação de funções
de protecção a painéis da subestação, deve ser replicada para toda a escala da subestação.
Figura 18 - Bay representativa do painel de chegada de AT no Helinks STS
3.6.3 Importação dos ICD’s dos fabricantes dos IED’s a
instalar na subestação
Após a execução da fase de configuração descrita no capítulo anterior, têm se ser associados à
subestação os IED’s responsáveis por garantir a aplicação das funções de protecção dos painéis da
subestação. Por outro lado, e dado que são equipamentos comunicantes recai sobre os mesmos
todas as tarefas de transmissão e recepção de dados.
A associação dos IED’s ao ficheiro de configuração da subestação (formato SCD) é conseguida
recorrendo à importação do ficheiro descritivo dos IED’s (formato ICD) que na generalidade dos
casos pode ser recolhido através da ferramenta de configuração de IED’s de cada fabricante.
Na Figura 19 pode ser analisada a estrutura que reúne todos os IED’s associados à subestação.
Neste caso particular podem ser analisados os dois IED’s mencionados na Tabela 2.
30
Figura 19 – IED’s associados à descrição de uma subestação no Helinks STS
Nome do IED Fabricante
IED1_lab Efacec
IED_0010 Siemens
Tabela 2 – Correspondência entre os nomes dos IED’s e respectivos fabricantes
Tal como já foi referido anteriormente, a importação dos ficheiros ICD permite a associação dos IED’s
ao ficheiro descritivo da subestação. Mais concretamente, o procedimento de importação permite
descarregar para as secções, “Logical Node Types” e “Data Types” representadas na Figura 19, a
estrutura interna de todos os nós lógicos e respectivas variáveis.
3.6.4 Associação dos IED’s aos painéis que estes vão
proteger na subestação
Na secção 3.6.2 foi exemplificado um método de associação de nós lógicos genéricos aos painéis da
subestação e no capítulo 3.6.3 a associação dos ficheiros ICD, representativos dos IED´s capazes de
implementar na prática esses nós lógicos. Logo, nesta última fase do projecto de configuração só
falta fazer a associação entre os nós lógicos associados à descrição da subestação e os painéis que
foram considerados. No desenvolvimento do Projecto-Tipo procura-se explorar a possibilidade de,
para cada tipo de painel, todos os nós lógicos estarem contidos nos mesmos PD/IED. Mas a estrutura
dos ficheiros ICD da Siemens revela que os vários dispositivos lógicos poderiam perfeitamente ser
implementados, em dispositivos físicos diferentes, visto cada LD ter o seu próprio LLN0.
Na Figura 20 encontra-se representado o menu do Helinks STS onde é possível concretizar a
associação dos IED’s aos painéis da subestação. Na coluna mais à esquerda da referida figura são
dispostos todos os nós lógicos previstos para os diferentes painéis da subestação, e nas duas
colunas mais à direita são expostas as instancias dos IED´s que estão associados ao projecto da
subestação. Para mapear um IED a um determinado painel, basta apenas marcar com um sinal de
certo, tal como se pode observar na Figura 20.
31
Figura 20 – Correspondência entre os nós lógicos previstos e os disponibilizados pelos IED’s (Helinks STS)
Desejavelmente o IED que é associado a um determinado painel, deve conseguir implementar todos
os nós lógicos que foram definidos para esse painel. Porém, este facto pode não se verificar, e é
nesse sentido que o Helinks STS põe ao dispor do utilizador uma simbologia própria, descrita na
Tabela 3. Nesta tabela podem observar-se dois símbolos, consoante o nó lógico esteja ou não,
disponível no IED que foi mapeado para o painel.
Símbolo Designação
Lnode disponível no IED mapeado
Lnode não disponível no IED mapeado
Tabela 3 – Simbologia seguida pelo Helinks STS
A exemplificação da aplicação desta simbologia pode ser analisada na Figura 20 para o painel “Bay
V1Q1”, onde se pode observar a presença de ambos os símbolos previstos pelo programa. No caso
concreto deste painel, o IED_0010 consegue implementar os nós lógicos PDIS e XSWI, mas não
consegue implementar o ZSAR.
32
4 Configuração reutilizável do Projecto-Tipo
O processo de comunicação entre ferramentas de engenharia distintas, assume um papel de extrema
importância no contexto do Projecto-Tipo. Dado que este engloba a presença de diversos fabricantes
de protecções cada um com o seu software proprietário, interessa garantir que através de uma
ferramenta de engenharia de cariz universal é possível lidar com os ficheiros resultantes de cada um
destes softwares de modo a criar um ficheiro compatível entre todos eles.
No presente capítulo foram executados testes, sobre os processos de comunicação entre os
softwares proprietários da Siemens (DIGSI) e da Efacec (WinSettings) e as ferramentas de
configuração de sistema (Helinks STS e Visual SCL).
As ferramentas de engenharia que estão preparadas para lidar com a norma IEC 61850 têm
obrigatoriamente de respeitar os formatos e estruturas dos ficheiros SCL definidos na norma.
Contudo, no decorrer dos processos de teste o entendimento que ficou subjacente reflecte que no
caso de algumas ferramentas de engenharia existem incompatibilidades que põem em causa o
processo de configurações. Mais concretamente, o Visual SCL revelou algumas limitações, pelo que
todas as configurações de CB’s vão ser demonstradas utilizando o Helinks STS que se revelou
bastante mais eficiente e robusto.
4.1 Estruturas de Dados Distintas entre IED’s de Diferentes
Fabricantes O Visual SCL permite a construção de um ficheiro descritivo de uma subestação (formato SCD), onde
podem ser criadas variadas instâncias dos diversos IED’s de diferentes fabricantes, cuja instalação
está projectada para a subestação tipo. O ficheiro final pode ter configurações de IED’s de diferentes
fabricantes, sendo assim do maior interesse verificar como é que esta grande quantidade de
informação vai ser gerida e integrada num único ficheiro.
Interessa ainda salientar que embora a norma IEC 61850 estabeleça um método padrão para as
estruturas de dados dos IED’s, os fabricantes conferem aos seus IED’s pequenas particularidades ao
nível das suas estruturas internas que podem ser problemáticos quando surgir a necessidade de
comunicação entre ferramentas de engenharia. Logo também se reveste de especial interesse a
verificação do método segundo o qual a ferramenta de configuração do sistema interpreta um ficheiro
que embora seja do mesmo formato, tem definido no seu código XML dispositivos de diferentes
fabricantes, com todas as diferenças de conteúdos e estruturas que isso implica.
4.1.1 Procedimentos
Neste capítulo vão ser analisadas as diferenças entre ficheiros SCL provenientes dos dois fabricantes
de protecções cujas unidades de protecção estão presentes no laboratório, Efacec e Siemens.
33
A evolução dos procedimentos de testes nesta fase permitiu comprovar que apesar da existência de
alguns pontos comuns entre as estruturas dos IED’s, também se verificam pontos divergentes. As
diferenças mais evidentes encontram-se relacionadas com a estrutura segundo a qual os dois
fabricantes organizam os seus nós lógicos dentro da instância do LD, e ainda com a noção de LLN0.
Para conseguir analisar as estruturas internas dos IED’s através de uma ferramenta de configuração
de sistema é necessário descarregar os ficheiros SCL descritivos dos IED’s (formato ICD). Foram
assim descarregados quatro ficheiros ICD para o Visual SCL, tal como se pode verificar na figura que
se segue.
Figura 21 – Associação de IED’s a uma subestação no Visual SCL
Na figura anterior é possível analisar que o software interpretou com sucesso a presença das quatro
unidades. Desta forma os dispositivos IED_0010, IED_0013 e IED_0018 representam os IED’s da
Siemens e o dispositivo IED1_lab o IED da Efacec.
Tal como era esperado o programa actualiza todos os restantes campos com os conteúdos dos IED’s
dos dois fabricantes, nomeadamente as secções correspondentes às instâncias dos “Data Type
Templates”, que podem ser analisadas na Figura 22. Na referida figura pode ainda observar-se que
esta instância é constituída por diversos campos, nomeadamente: “Lnode Types”, “Data Types”,
“Attribute Types” e “Enum Types”.
Figura 22 – Estrutura hierárquica dos Data Type Templates no Visual SCL
Por exemplo, para a secção “Lnode Types” (Figura 23), podem ser observados todos os nós lógicos
passíveis de ser implementados pelos quatro dispositivos, onde os nós lógicos do IED_0010,
IED_0013 e IED_0018, são nomeados com base no endereço do dispositivo e na subsecção em que
se inserem. Por outro lado, os nós lógicos do outro IED são nomeados com base no prefixo “EFA_”
seguido pela sigla representativa da função de protecção. Embora diferente do método seguido pela
34
Siemens, a definição dos nós lógicos pela Efacec não vai contra a norma IEC 61850, dado que nesta
está prevista a associação de prefixos e sufixos à descrição dos nós lógicos. Enquanto a Efacec opta
por recorrer a prefixos, a Siemens recorre frequentemente a sufixos, como se pode verificar para o nó
lógico IED_0010/PROT/PDIS, que pode ser finalizado com o número “1” ou com o número “2”, tal
como se pode observar na quinta e sexta linha da Figura 23.
Figura 23 – Associação de Lnode Types no Visual SCL
Também poderia ter sido utilizada uma abordagem semelhante à que acabou de ser realizada para o
“Lnode Types”, para fazer uma análise detalhada de todos os “Data Type Templates”, mas devido à
grande quantidade de dados seria complicado mostrar com detalhe o conteúdo de todas as
instâncias. Contudo, foram analisadas todas as instâncias que fazem parte do “Data Type
Templates”, tendo-se concluído que o software incorpora correctamente os dados referentes a todos
os IED’s que foram adicionados.
35
4.1.2 Organização do Logical Device
É ao nível da organização do LD que se situa a grande generalidade das diferenças entre as
estruturas dos dois fabricantes em análise. Tal como referido Na secção 2.4, existem várias filosofias
que podem ser seguidas para estruturar os nós lógicos dentro de uma instância de um LD.
Recorrendo à Figura 24, pode analisar-se que o “LDevice” do IED_0018 (Siemens) é constituído por
cinco instâncias, onde se encontram organizados os nós lógicos de acordo com a sua área funcional.
Mais concretamente, as cinco instâncias são:
PROT - Protection
MEAS - Measurement
DR - Disturb Rec
CTRL - Control
EXT – Extended
Figura 24 – Comparação entre ficheiros no Visual SCL (lado esquerdo: Efacec, lado direito: Siemens)
36
Na estrutura do IED_0018 os nós lógicos não estão imediatamente dispostos dentro de cada uma das
instâncias listadas anteriormente, dado que ainda existem outras duas ramificações, mais
especificamente, “LLN0” e “LNs”. É dentro da instância “LNs” que se encontram discriminados todos
os nós lógicos. Relativamente ao IED1_lab também representado na Figura 24, pode analisar-se que
o “LDevice” embora discrimine da mesma forma os nós lógicos dentro da instância “LNs”, não os
organiza em dispositivos lógicos, optando apenas por os listar todos na mesma ramificação.
A outra instância existente no dispositivo lógico (“LLN0”) vai ser analisada no capítulo que se segue.
4.1.3 Organização dos Logical Node Zero (LLN0)
Figura 25 – Comparação entre ficheiros no Visual SCL (lado esquerdo: Efacec, lado direito: Siemens)
A análise da Figura 24 também se revelou muito útil no que diz respeito ao LLN0. A importância deste
nó lógico é vital, dado que é através dele que são parametrizados todos os aspectos relacionados
com as comunicações, tanto horizontal (GOOSE) como vertical (RCB).
37
Relativamente a este ponto também surgem diferenças evidentes entre a estrutura seguida pela
Siemens e pela Efacec. Como os IED’s da Efacec são caracterizados por apenas uma listagem de
nós lógicos, só dispõem de uma instância do nó lógico LLN0, contra as cinco instâncias da Siemens
(uma instância para cada uma das listagens de nós lógicos das cinco áreas funcionais).
Tal como descrito anteriormente, é no LLN0 que são parametrizadas as comunicações, interessando
particularmente nesta fase as configurações do RCB. Para parametrizar completamente um RCB é
preciso configurar duas das instâncias que podem ser analisadas na Figura 25 para qualquer um dos
IED’s. Os atributos que vão ser comunicados são especificados na instância “Data Sets”, sendo que
esta secção é posteriormente referenciada dentro da instância “Report Controls” onde também têm
de ser definidas outras características respeitantes aos RCB’s.
A estrutura interna do nó lógico LLN0 é a mesma para qualquer um dos fabricantes, sendo que a
única coisa que varia são os nomes que são atribuídos às instâncias que o constituem. Por exemplo
para os “Data Sets”, a Efacec opta por fazer desde logo uma associação entre um determinado “Data
Set” e o respectivo RCB através da composição do nome. Ou seja, “DSforbRCBA” quer dizer “Data
Set for Buffered Report Control Block A”. Por outro lado a Siemens opta apenas por chamar
“DataSet1”, e só faz a associação deste “Data Set” com o respectivo RCB numa fase posterior de
parametrizações do mesmo.
Apesar da existência de alguns pontos comuns entre as estruturas dos IED’s, também se verificam
pontos divergentes que se podem revelar problemáticos quando surgir a necessidade de exportar
ficheiros. Mais à frente neste capítulo, irá ser testado todo o processo de exportação e importação de
ficheiros SCL entre as diversas ferramentas de engenharia, onde alguns dos aspectos referidos ao
longo do presente capítulo poderão ser da máxima relevância.
4.2 Interacção entre o DIGSI e o Visual SCL
No decorrer deste capítulo foram realizados extensos procedimentos experimentais, que se
encontram devidamente discriminados no capítulo 2 dos anexos. Nos capítulos que se seguem foram
descritos os métodos de teste seguidos, bem como os resultados principais que foram obtidos
durante a realização dos mesmos. Durante a sequência de testes que foram efectuados foi
necessário proceder à transferência de ficheiros entre softwares de diferentes fabricantes que podem
eventualmente efectuar alterações comprometedoras nos ficheiros, impossibilitando a sua posterior
importação.
4.2.1 1ª Fase - Exportação do DIGSI vs Importação DIGSI
Embora os problemas surjam essencialmente na troca de ficheiros entre softwares diferentes,
considerou-se da maior conveniência garantir que imediatamente após a exportação do DIGSI o
38
ficheiro resultante é importável por este mesmo programa. A execução do presente teste, permite
despistar facilmente futuros erros que possam surgir em processos relacionados com a troca de
dados entre ferramentas.
A execução do teste não revelou qualquer problema na exportação do ficheiro SCD através do DIGSI.
A posterior importação do mesmo ficheiro, também decorreu com sucesso e tal como era expectável
não surgiu qualquer problema. Interessa salientar que o ficheiro SCD que está na base dos testes
engloba no seu interior tanto IED’s da Siemens como da Efacec.
4.2.2 2ª Fase - Leitura e Salvaguarda do ficheiro SCD no
Visual SCL
Na presente fase dos ensaios interessa aferir qual o grau de intervenção que o Visual SCL tem sobre
um ficheiro SCL para uma situação em que não interessa alterar o ficheiro original, sendo apenas
requerido que a ferramenta abra o ficheiro original e de seguida o guarde sem efectuar qualquer tipo
de intervenção sobre o mesmo.
Os problemas começam a surgir precisamente nesta fase dos ensaios, nomeadamente quando se
torna necessário importar para o DIGSI um ficheiro que foi salvo no Visual SCL, é retornado um
extenso relatório de erros. A análise e resolução dos referidos erros encontram-se realizadas na
próxima fase dos procedimentos de testes.
4.2.3 3ª Fase - Método de Resolução dos Erros Resultantes
Na fase de testes anterior, foi relatado o retorno de um extenso relatório de erros resultante da
interacção entre ferramentas distintas. Embora extensa, a lista apresenta uma repetição sistemática
de dois tipos de erros. A lista discrimina ainda, quais as situações problemáticas que se verificam
para cada erro em particular, pelo que a resolução dos erros não apresentou nenhum tipo de
dificuldade acrescida.
Os dois tipos de erros retornados, reflectem situações problemáticas ao nível da sintaxe e da
estrutura do código. Nomeadamente, as duas situações concretas prendem-se com a inexistência de
um campo lnClass e com a existência de um espaço adicional entre dois caracteres. Ambas as
situações se verificaram perturbadoras no processo de interpretação do código por parte do DIGSI.
No sentido de corrigir esta situação procedeu-se à rectificação dos campos referenciados através de
um editor de código XML, de forma a ficar idêntico à situação ideal (ver secção 2 dos anexos).
Após o processo de rectificação de todas as situações problemáticas, a compilação e posterior
importação do ficheiro por parte do DIGSI, decorreu de forma bem sucedida.
39
4.2.4 4ª Fase – Explicação técnica dos bugs pela ASE
No anexo 0 referente a esta fase de testes, foi dado especial ênfase à diferença de espaço em disco
que o ficheiro originário do DIGSI sofria após ser guardado pelo Visual SCL sem serem efectivadas
alterações. Esta questão foi posta á ASE, cuja resposta declara que a situação era perfeitamente
normal, explicando que quando o Visual SCL salva um ficheiro modifica-o sempre de modo a este se
adaptar ao Visual SCL schema. Esta estrutura pré definida que a ASE apelida de Visual SCL schema
encarrega-se de moldar a estrutura final do ficheiro.
As ferramentas de engenharia que estão preparadas para lidar com a norma IEC 61850 devem
respeitar os formatos e estruturas dos ficheiros SCL definidos na mesma, mas também as estruturas
dos fabricantes. Contudo, no caso do Visual SCL e do DIGSI existem diferentes interpretações de
alguns pontos da linguagem SCL, caso contrário a aplicação do Visual SCL schema ao ficheiro
originário do DIGSI não causaria modificações inibidoras da sua posterior transferência.
Interessa sublinhar que o Visual SCL reconhece e interpreta correctamente a estrutura do ficheiro
originário do DIGSI embora este não esteja inicialmente de acordo com o Visual SCL schema, no
entanto quando salva o ficheiro adapta-o ao seu esquema padrão que não é reconhecido pelo DIGSI.
Portanto, comprova-se que não se trata de um problema de má interpretação da norma, mas sim de
um problema de interoperabilidade entre ferramentas.
O 1º tipo de erro encontrado refere-se a uma unidade da Efacec e encontra-se esquematizado na
Figura 26. Como se pode analisar na referida figura, a sintaxe exigida pelo DIGSI parece á primeira
vista similar à verificada no Visual SCL, porém, existe um espaço entre os símbolos “ e / que foi
adicionado após o ficheiro ter sido salvo no Visual SCL. Este espaço irá ser detectado pelo software
de validação da Siemens impossibilitando a sua importação pelo DIGSI.
Figura 26 – 1ª Diferença de sintaxe entre Visual SCL e DIGSI
Relativamente ao 2º tipo de erro, a compreensão do problema requer mais conhecimentos técnicos
da norma. Quando o DIGSI gera o código XML referente ao ficheiro SCL associa à linha directora do
nó lógico LLN0 uma secção denominada InClass que reforça que este nó lógico pertence à classe
LLN0 (Figura 27).
40
Figura 27 - 2ª Diferença de sintaxe entre Visual SCL e DIGSI
No entanto e segundo a ASE, o Visual SCL ao encontrar a secção “InClass=”LLN0” para o nó lógico
LLN0 encara esta informação como uma redundância, que de acordo com o Visual SCL schema não
deveria estar presente, eliminando consequentemente a referência a esta secção. Esta opção tomada
pelo Visual SCL vai interferir novamente com o processo de validação da Siemens.
Numa primeira análise desta problemática parece que apenas o Visual SCL está origem dos erros,
visto que a aplicação da sua estrutura standart (Visual SCL schema) quando salva um ficheiro gera
alterações face ao ficheiro original. Por outro lado provou-se que o Visual SCL consegue interpretar
ficheiros cuja estrutura divirja da sua, embora quando os salve altere essa estrutura. Seria também
interessante que o DIGSI fosse dotado de capacidades semelhantes, através das quais
reconhecesse que a estrutura proveniente do Visual SCL não está de acordo com a sua, mas que
pudesse interpretá-la e alterá-la posteriormente para a estrutura desejada. Desta forma, não é
sensato apontar nenhuma das ferramentas como originadora dos erros encontrados, podendo
apenas ser ilustrado que a interoperabilidade falhou.
4.3 Interacção entre o DIGSI e o Helinks STS
No decorrer deste capítulo foram realizados extensos procedimentos experimentais, que se
encontram devidamente discriminados nos anexos (capítulo 3). Nos capítulos que se seguem foram
descritos os métodos de teste seguidos, bem como os resultados principais que foram obtidos
durante a realização dos mesmos.
4.3.1 1ª Fase - Exportação do DIGSI vs Importação DIGSI
A 1ª Fase é em tudo idêntica à interacção demonstrada para o Visual SCL na secção 4.2.1. O ficheiro
SCD que foi utilizado para testar o Helinks STS é exactamente o mesmo ficheiro que tinha sido
previamente utilizado para testar o Visual SCL. Como era esperado a execução desta fase do teste
não revelou qualquer problema, tendo-se mais uma vez verificado que o DIGSI consegue exportar e
importar ficheiros SCD. No entanto, o que realmente interessa provar é que o DIGSI consegue
importar ficheiros SCD que tenham sido modificados pelo Helinks STS, tal como vai ser demonstrado
nos capítulos que se seguem.
41
4.3.2 2ª Fase - Leitura e Salvaguarda do ficheiro SCD no
Helinks STS
Como se demonstrou na secção 4.2.2 os problemas encontrados para o Visual SCL começaram a
surgir precisamente nesta fase, devido à aplicação do Visual SCL schema. Contudo, para o presente
caso em que o ficheiro é guardado recorrendo ao Helinks STS não é retornado nenhum erro no
processo de importação no DIGSI, pelo que se deduz que o software em análise apenas se limita a
interpretar os dados do ficheiro SCD, não exercendo sobre eles qualquer alteração.
O resultado obtido prova que o Helinks STS não apresenta os mesmos problemas que o Visual SCL.
Este resultado foi preponderante para a escolha da ferramenta de engenharia utilizada para realizar
os procedimentos que se seguem. Doravante, o Helinks STS foi a ferramenta escolhida para as
configurações da subestação.
4.4 Report Control Block
A Siemens possibilita a construção e configuração do RCB através de dois métodos distintos, que
estão disponíveis em dois softwares, DIGSI e SICAM PAS.
O SICAM PAS assume-se como uma maneira alternativa de criar os RCB´s, permitindo ao servidor
configurar em tempo real quais os dados que deseja receber a partir de qualquer IED. A Siemens
chama a este método Dynamic Creation version, onde o servidor pode definir de forma dinâmica e em
qualquer momento quais os atributos que pretende receber tendo como remetente uma lista de
atributos fornecida por todos os IED’s presentes na subestação.
Tendo em conta a linha orientadora do Projecto-Tipo onde se procura encontrar uma solução de
configuração reutilizável, independente de fabricantes, aparte o facto de os IED’s deverem conter os
mesmos nós lógicos relevantes para o Projecto-Tipo, facilmente se conclui que o método
apresentado não se enquadra nesse âmbito.
A Siemens possibilita no entanto uma alternativa com um princípio de actuação que permite
configurar completamente o RCB através de uma ferramenta de configuração de sistema de carácter
universal, não sendo necessário recorrer a uma ferramenta de engenharia fornecida por um
fabricante dos IED’s. A Siemens apelida este método de System Configurator.
O software da Efacec (WinSettings) permite a configuração dos RCB através de um método em tudo
idêntico ao que acabou de ser referido para a ferramenta da Siemens.
Pretende-se analisar quais as capacidades que ambos os fabricantes conferiram às suas ferramentas
relativamente à configuração dos RCB e de que forma se processa a comunicação entre estas
ferramentas e o Helinks STS. Após a realização dos testes, pode-se concluir que a este nível a
adaptação de ambos os fabricantes à norma IEC 61850, foi muito bem conseguida. A comunicação
42
entre as ferramentas proprietárias dos fabricantes e o Helinks STS também se revelou um sucesso,
sendo que os resultados obtidos comprovam ser possível configurar externamente ao DIGSI e
WinSettings todos os parâmetros relativos ao RCB tendo como garantia que, posteriormente, é
possível importar todas as configurações para os mesmos.
4.4.1 Procedimentos
4.4.2 Configuração básica do RCB no DIGSI
Na ferramenta DIGSI foram associados ao ícone da subestação dois IED’s, um da Siemens e outro
da Efacec. O IED da Efacec foi adicionado através da importação de um ficheiro ICD onde a
configuração do RCB foi conseguida recorrendo à ferramenta de configuração de IED’s proprietária
da Efacec (WinSettings). Dado que o IED da Siemens pertence ao mesmo fabricante do software em
utilização foi bastante mais fácil de adicionar à descrição da subestação, visto ser directamente
adicionado a partir da base de dados da ferramenta.
Acedendo ao objecto que simboliza a subestação (no DIGSI) é já possível observar a correcta
associação dos dois IED’s (Figura 28):
Figura 28 – IED’s considerados dentro da descrição de uma subestação no DIGSI
A correspondência entre os IED’s representados na figura anterior e os respectivos fabricantes
encontra-se descrita na tabela que se segue.
Nome do IED Fabricante
IED_0010 Siemens
IED2_lab Efacec
Tabela 4 - Correspondência entre os nomes dos IED’s e respectivos fabricantes
O Projecto-Tipo não menciona quais os atributos que devem ser reportados por cada um dos nós
lógicos presentes na subestação, pelo que para a realização dos testes se optou por escolher os
atributos responsáveis pelos dados de maior importância para a monitorização do sistema.
Procedeu-se de seguida à configuração dos RCB de ambos os IED’s. Os RCB’s respeitantes ao IED
da Efacec podem ser logo configurados no WinSettings, sendo que o processo de criação do ficheiro
ICD desta ferramenta associa a este ficheiro a configuração dos RCB’s. Logo quando se importa para
o DIGSI o IED da Efacec, este já pode ter parametrizado na sua estrutura interna a instância de RCB.
43
Este procedimento foi tomado para esta fase de testes, tendo sido parametrizados no WinSettings um
BRCB com alguns atributos (Op, Mod e Beh) respeitantes ao nó lógico PTUV.
Na Figura 29 é possível visualizar a parametrização do RCB do IED da Efacec no DIGSI. Pode ser
analisada a atribuição de um campo denominado “DSforbRCBA” (Data Set for BRCB A) na secção
esquerda da imagem, e ainda a descrição de quais os atributos que estão disponíveis neste RCB na
secção direita da imagem.
Figura 29 – Estrutura interna da instância de RCB do IED2_lab no DIGSI
No caso da configuração do RCB do IED da Siemens, o processo de configuração foi efectuado
através de uma aplicação de drag and drop onde está à disposição do operador de sistema uma lista
dos atributos disponibilizados pelo IED para efeito de Reports. Para este IED foi parametrizado no
DIGSI um BRCB com alguns atributos (Str e Op) respeitantes ao nó lógico PTOC.
Na Figura 30 é possível visualizar a parametrização do RCB da Siemens no DIGSI. Pode ser
analisada a atribuição de um campo denominado Reportapplication1 na secção esquerda da imagem,
com a descrição na secção direita da imagem de quais os atributos que estão disponíveis neste RCB.
Figura 30 - Estrutura interna da instância de RCB do IED_0010 no DIGSI
Após se ter configurado um ficheiro descritivo da subestação (formato SCD) no DIGSI, onde já vêm
configuradas duas instâncias de RCB (Efacec e Siemens), já é possível proceder à sua importação
pela ferramenta de configuração de sistema, Helinks STS. A importação decorreu sem qualquer
problema como se pode observar na Figura 31.
44
Figura 31 - IED’s associados à descrição de uma subestação no Helinks STS
Na Figura 32 (representativa do IED2_lab) e na Figura 33 (representativa do IED_0010) encontra-se
representada a informação dos RCB’s com visualização no Helinks STS. Através de comparação com
a parametrização inicial dos RCB’s definida respectivamente na Figura 29 e na Figura 30, conclui-se
que todas as configurações estabelecidas no DIGSI foram correctamente interpretadas e associadas
aos IED’s a que se destinavam.
Figura 32 - Estrutura interna do IED2_lab no Helinks STS
45
Figura 33 - Estrutura interna do IED_0010 no Helinks STS
4.4.3 1º Teste - Exportação do RCB do Helinks STS para o
DIGSI
De modo a testar a compatibilidade da transferência de ficheiros SCL entre o Helinks STS e o DIGSI,
utilizou-se o ficheiro descritivo da subestação configurado no capítulo anterior. Note-se que o referido
ficheiro já possui na sua estrutura interna a parametrização de duas instâncias de RCB.
O teste que vai ser realizado nesta fase consiste em abrir o referido ficheiro no Helinks STS, e apagar
todos os atributos que estavam definidos dentro das instâncias de RCB. Na fase seguinte o ficheiro
onde foram efectivadas as referidas alterações volta a ser importado pelo DIGSI a fim de verificar se
este tem a capacidade de interpretar correctamente as modificações efectuadas sobre os dados.
46
Na Figura 32 e na Figura 33, encontram-se representados os atributos que constituem os RCB’s, do
IED2_lab e do IED_0010. Os atributos que podem ser analisados nas figuras mencionadas, estão
também listados de seguida:
IED2_lab
o PTUV.Mod
o PTUV.Beh
o PTUV.Op
IED_0010
o PTOC.Str
o PTOC.Op
São precisamente estes atributos que vão ser apagados do respectivo ficheiro SCD através do
Helinks STS. Os resultados deste procedimento encontram-se descritos na Figura 34 para o
IED2_lab, e na Figura 35 para o IED_0010. Nas figuras podem ser facilmente comprovadas as
alterações, visto que já não estão presentes na estrutura dos IED’s os campos: Data Set e Report
Control.
Figura 34 - Estrutura interna do IED2_lab no Helinks STS
47
Figura 35 - Estrutura interna do IED_0010 no Helinks STS
Na tabela que se segue foi feita uma correspondência entre os resultados iniciais e finais da estrutura
interna dos dois IED’s, e as respectivas figuras onde estes podem ser analisados.
IED Situação Original Situação Final
IED2_lab Figura 32 Figura 34
IED_0010 Figura 33 Figura 35
Tabela 5 – Correspondência entre os nomes do IED’s e os resultados experimentais obtidos
Para finalizar este teste, o ficheiro resultante do Helinks STS foi importado no ícone descritivo da
subestação presente no DIGSI, tendo-se verificado que todos os atributos associados aos RCB’s
tinham sido apagados, tal como era esperado. Este resultado pode ser observado na Figura 36, e
comparado com a situação inicial representada na Figura 29 para o IED2_lab, e na Figura 30 para o
IED_0010. As instâncias dos diferentes RCB’s que podiam ser visualizadas nas referidas figuras,
estão agora em branco.
48
Figura 36 – Aplicação DIGSI system configurator para a descrição de uma subestação
Para facilitar a explicação dos resultados a Figura 36 foi seccionada e numerada recorrendo a três
rectângulos vermelhos. No 3º rectângulo pode-se observar que este ficheiro é constituído pelos
mesmos dois IED’s que haviam sido configurados inicialmente, logo e ainda numa primeira análise
nota-se que o DIGSI está a interpretar correctamente este ficheiro.
Caso o IED2_lab ainda tivesse atributos associados a uma instância de RCB, estes deveriam estar
evidenciados na árvore que compõe o 1º rectângulo (tal como na Figura 29), logo conclui-se que para
este IED em particular o DIGSI interpretou correctamente as alterações.
Por último, caso o IED_0010 ainda tivesse atributos associados a uma instância de RCB, estes
deveriam estar evidenciados dentro do campo Reportapplication1 presente no 1º rectângulo (tal como
na Figura 30), porém a análise do 3º rectângulo reflecte imediatamente que este campo não tem nada
definido no seu interior pelo que também se conclui que para este IED o DIGSI interpretou
correctamente as alterações.
4.4.4 2º Teste - Exportação RCB do Helinks STS para o
DIGSI
O teste realizado no capítulo anterior destacou-se por ter chegado a uma solução que comprova a
possibilidade de comunicação entre as diferentes ferramentas de engenharia em teste, porém apenas
foi testado para um problema básico em que se pretendia apagar as referências de um determinado
RCB. Para uma aplicação prática é também de interesse demonstrar se é possível modificar e criar
49
outras instâncias de RCB na ferramenta de configuração de sistema, que não venham definidas a
priori da ferramenta do fabricante.
Para demonstrar como se pode concretizar a criação de novos atributos num RCB recorrendo ao
Helinks STS, optou-se por estabelecer dois atributos que se pretendem associar a uma referência de
RCB já existente num ficheiro SCD proveniente do DIGSI. Após se proceder no Helinks STS à
correcta associação dos novos atributos, o ficheiro resultante vai ser importado pelo DIGSI a fim de
verificar se este consegue interpretar com sucesso as alterações efectuadas e actualizar
correctamente a sua estrutura de modo reflectir as modificações.
Para este teste utilizou-se o ficheiro descritivo da subestação configurado na secção 4.2, dado que
este ficheiro já possui na sua estrutura interna a parametrização de duas instâncias de RCB. Neste
ficheiro estão definidos dois atributos para o IED_0010 da Siemens na ReportApplication1, e três
atributos para o IED2_lab da Efacec. Mais especificamente os atributos de ambos os IED’s
encontram-se listados de seguida:
IED2_lab
o PTUV.Mod
o PTUV.Beh
o PTUV.Op
IED_0010
o PTOC.Str
o PTOC.Op
Tal como já foi mencionado anteriormente os procedimentos desta fase de teste, consistem em
adicionar recorrendo ao Helinks STS novos atributos às instâncias de RCB de ambos os IED’s. Os
atributos que vão ser adicionados encontram-se listados de seguida:
IED2_lab
o XCBR.Pos
o XCBR.Mod
IED_0010
o PDIS.Str
o PDIS.Op
A estrutura interna dos ficheiros SCL segue numa organização hierárquica, onde os vários níveis vão
sendo consecutivamente aprofundados nas ramificações de uma árvore. Na Figura 32 pode ser
analisado o nível hierárquico onde está definido o campo referente ao Data Set, cujos “filhos” são os
atributos configurados dentro desse Data Set.
Nesta fase interessa adicionar mais atributos a este Data Set, logo vão ter de ser criados novos
“filhos”. A realização deste procedimento no Helinks STS é fácil, bastando apenas entrar no nível que
se quer ramificar e carregar na opção “New Child”. Desde logo surge uma janela idêntica à
50
representada na Figura 37, expondo todos os atributos disponibilizados pelo IED para poderem ser
adicionados como atributos a um Data Set.
Figura 37 – Associação de atributos a um DataSet no Helinks STS
O procedimento mencionado no parágrafo anterior tem de ser repetido tantas vezes quantos os
atributos que se queriam adicionar. A comparação entre os resultados iniciais e finais encontram-se
representados na Figura 38 para o IED2_lab (Efacec), e na Figura 39 para o IED_0010 (Siemens).
Em ambas as figuras, na secção esquerda pode ser analisada a configuração inicial dos Data Sets e
na secção direita a sua configuração final.
Figura 38 – Estrutura interna do IED2_lab no Helinks STS (lado esquerdo: original; lado direito: final)
Como era esperado, a configuração final de cada uma das instâncias de Data Sets é composta pelos
atributos definidos inicialmente no ficheiro, mais os novos atributos que foram adicionados. Ou seja:
IED2_lab
o PTUV.Mod
o PTUV.Beh
51
o PTUV.Op
o XCBR.Pos
o XCBR.Mod
Figura 39 - Estrutura interna do IED_0010 no Helinks STS (lado esquerdo: original; lado direito: final)
IED_0010
o PTOC.Str
o PTOC.Op
o PDIS.Str
o PDIS.Op
Como já foi explicado anteriormente, os Data Sets estão directamente associados a instâncias de
RCB. Logo, como o objectivo do teste era apenas adicionar atributos a um Data Set já existente, não
foi preciso fazer a associação entre o Data Set e o RCB dado que está já existia. Esta associação
pode ser confirmada recorrendo às propriedades internas das instâncias de RCB’s, para o IED2_lab
através da Figura 40, e para o IED_0010 através da Figura 41. Em ambas as figuras é possivel
observar que nas propriedades do RCB é sempre preciso mencionar os dados do Data Set que lhe
está associado.
Figura 40 – Estrutura interna da instância de RCB do IED2_lab no Helinks STS
52
Figura 41 - Estrutura interna da instância de RCB do IED_0010 no Helinks STS
Após o processo de associação dos atributos aos Data Sets estar completo, o ficheiro resultante foi
guardado e importado pelo DIGSI, onde foi sujeito ao processo de validação que decorreu com
sucesso. Abrindo no DIGSI a descrição da subestação, pode-se desde logo observar a associação
dos novos atributos. O resultado deste procedimento revelou-se bastante positivo, sendo possível
analisar a correcta associação dos novos atributos do IED da Efacec na Figura 42, e dos atributos do
IED da Siemens na Figura 43.
Figura 42 - Estrutura interna da instância de RCB do IED2_lab no DIGSI
Figura 43 - Estrutura interna da instância de RCB do IED_0010 no DIGSI
53
4.5 Setting Group Control Block
Embora a norma IEC 61850 tenha previsto um serviço que permite parametrizar o SGCB, os
fabricantes das unidades de protecção presentes no laboratório não exploram todo o potencial
oferecido a este nível. A possibilidade de parametrizar e gerir os diferentes cenários apenas pode ser
executada recorrendo às ferramentas de configuração de IED’s (DIGSI e WinSettings), visto que a
informação incluída nos ficheiros SCL relativa ao CB em estudo se revela insuficiente perante o
grande número de possibilidades. Esta opção dos fabricantes compromete o processo de
configuração da subestação via norma IEC 61850 dado que não dotando os seus ficheiros SCL dos
dados relativos ao SGCB, impossibilitam que uma ferramenta de configuração de sistema consiga
configurar e parametrizar as funções de protecção de forma autónoma. Contudo, analisando um nó
lógico concreto, por exemplo o PTOC (Figura 5) verifica-se que todos os atributos que foram previstos
para o SGCB, e que se encontram agrupados dentro de uma estrutura denominada Settings,
apresentam uma FC (Functional Constraint) representada pela letra O, ou seja, optional. Esta
opcionalidade de considerar determinados atributos verifica-se para todas as classes de nós lógicos,
pelo que apenas se pode afirmar que os fabricantes não estão a tomar uma medida contra a norma,
estando apenas a aproveitar uma possibilidade da mesma para incorporar menos funcionalidades
nos seus equipamentos.
O método seguido para testar as potencialidades dos IED’s no que concerne ao SGCB consistiu
essencialmente na exportação de um ficheiro SCD do DIGSI. O referido ficheiro foi exportado com
base na descrição de uma subestação criada nos softwares dos fabricantes onde tinham sido
parametrizados a priori um conjunto de quatro cenários de actuação. Na referida descrição da
subestação também se encontrava definido qual o cenário que estava em vigor. Posteriormente este
ficheiro foi visualizado recorrendo a duas ferramentas, um editor de código XML e uma ferramenta de
configuração de sistema (Helinks STS). Em ambos os softwares foi possível analisar com rigor qual a
estrutura segundo a qual o SGCB foi organizado e se as configurações efectivadas no DIGSI e
WinSettings foram devidamente incluídas no ficheiro SCL.
4.5.1 Procedimentos
4.5.1.1 Configuração do SGCB no DIGSI
A ferramenta de configuração de IED’s da Siemens (DIGSI) permite para um determinado SGCB,
configurar quatro instâncias de parametrizações e de estabelecer qual das instâncias está em vigor
num determinado instante. Este procedimento pode ser efectuado de forma bastante intuitiva, tal
como se pode observar na Figura 44. Nesta figura estão definidos para a SIPROTEC 7SA522
(IED_0010) os Setting Group A, B, C, D, além de um campo Change Group onde está definido qual o
cenário activo. O Change Group nesta fase do trabalho estava definido como sendo o Setting Group
A (Figura 45).
54
Figura 44 – Menu principal de configuração de um IED específico no DIGSI
Figura 45 – Menu que permite trocar o Change Group de um determinado SGCB no DIGSI
Como a unidade de protecção onde se estão a efectuar os testes, está incluída dentro da descrição
da subestação definida no DIGSI, todas as alterações que se efectuarem na sua configuração serão
imediatamente reconhecidas pela descrição da subestação. Desta forma, quando se proceder à
exportação do ficheiro SCD através do DIGSI todas as configurações internas de cada uma das
unidades serão incluídas no ficheiro resultante.
Figura 46 – IED’s considerados dentro da descrição de uma subestação no DIGSI
55
Nesta fase do trabalho estão incluídas dentro da subestação as unidades que podem ser analisadas
na Figura 46, mais especificamente, as unidades IED_0010 (Siemens) e IED2_lab (Efacec).
4.5.1.2 1º Teste – Teste do SGCB recorrendo ao Helinks
STS
No DIGSI é possível configurar se o SGCB está activo, ou seja, se vai ser possível ao operador de
sistema dispor de vários cenários de parametrização. Caso este serviço esteja activo (Enabled) como
se representa na Figura 47, vão estar disponíveis quatro cenários de actuação possíveis (Figura 44).
Caso contrário (Disabled), vai estar disponível apenas um cenário de actuação, como se pode
observar na Figura 48.
As opções de configuração que foram mencionadas, dizem apenas respeito aos IED’s da Siemens. A
configuração do SGCB do IED da Efacec tem de ser realizada no WinSettings.
Figura 47 - Menu de activação das funcionalidades disponíveis num determinado IED através do DIGSI
Figura 48 - Menu principal de configuração de um IED específico no DIGSI
56
Com base numa configuração onde se activaram os quatro cenários de actuação, procedeu-se à
exportação do ficheiro descritivo da subestação do DIGSI, e à sua posterior importação no Helinks
STS.
No Helinks STS, a estrutura interna do IED_0010 apresenta um campo denominado “Setting Control
SGCB”, tal como se pode analisar na Figura 49. A presença deste campo, transmite a ideia que a
informação do SGCB está a ser incorporada pelo DIGSI nos ficheiros SCL. Por outro lado, a estrutura
interna do IED2_lab não apresenta nenhum campo onde seja feita referência ao SGCB pelo que se
conclui facilmente que o WinSettings não incorpora nos ficheiros SCL que exporta, nenhum dado
relativo ao SGCB.
Figura 49 - Estrutura interna do IED_0010 no Helinks STS
Nas propriedades do campo “Setting Control SGCB”, associado ao IED_0010, surge informação
relativa à existência de quatro cenários, “NumOfSG = 4”, e ainda a atribuição do valor “1” ao campo
onde se define qual o cenário actualmente em vigor, “ActSG”, como se pode visualizar na Figura 50.
Figura 50 – Estrutura interna da instância de SGCB do IED_0010 no Helinks STS
57
Numa primeira análise está tudo certo, visto que no DIGSI é possível parametrizar tanto o número de
SGCB’s, como o cenário que está em vigor num determinado instante de tempo. Logo, esta
informação deverá estar a ser correctamente interpretada pelo Helinks STS. Contudo, optou-se por
realizar um teste adicional onde foi alterado o campo “ActSG” para o valor “2” (Figura 51).
Figura 51 - Estrutura interna da instância de SGCB do IED_0010 no Helinks STS
Caso este campo esteja efectivamente presente na estrutura original do ficheiro SCL proveniente do
DIGSI, será de esperar que esta alteração seja devidamente interpretada pelo DIGSI no momento da
importação do ficheiro, alterando o campo “Change Group” de A para B. Contudo o referido campo,
continua a apresentar o dado A, ou seja, manteve-se inalterado.
Este resultado sugere que o campo “Setting Control SGCB”, que o DIGSI associa aos ficheiros SCL
que gera, é estático, ou seja, não é influenciado pelas configurações. A confirmação dos factos
verificados neste teste revela que tanto a Siemens como a Efacec, não implementaram nos seus
IED’s as funcionalidades previstas pela norma para o SGCB. Dada a grande responsabilidade
inerente a uma declaração como esta, optou-se por realizar um segundo teste recorrendo a uma
ferramenta construída unicamente com o propósito de editar código XML e sem qualquer vínculo à
norma IEC 61850, tendo como objectivo verificar quais os dados que passam do DIGSI para os
ficheiros SCL que este gera.
4.5.1.3 2º Teste – Teste do SGCB recorrendo a um editor
de texto XML
Este método de análise do ficheiro SCL revelou-se ligeiramente mais complexo do que recorrendo ao
Helinks STS. Utilizando este método, todas as análises necessárias têm de ser efectuadas sobre
código XML ao invés de uma representação gráfica, tornando assim todo o processo mais moroso e
de mais difícil análise dada a extensão dos ficheiros.
Na Figura 52 podem ser analisados no editor de código XML, os dois IED’s que foram considerados
dentro da subestação, o IED_0010 e o IED2_lab.
58
Figura 52 – Visualização de um ficheiro SCD no XML Copy Editor
Foi efectuada uma análise criteriosa de toda a estrutura de ambos os IED’s, com especial cuidado
nas secções de código respeitantes ao SGCB. Contudo, a única referência no código a este CB,
resume-se a uma linha para o IED_0010, tal se pode analisar na Figura 53.
Figura 53 – Estrutura interna do IED_0010 no XML Copy Editor
59
De todos os atributos constituintes da SGCB class (Figura 9), o único que está presente no ficheiro
SCL originado pelo DIGSI é o “NumOfSG” ao qual foi atribuído o valor 4. Este valor faz todo o
sentido, visto que, este atributo representa o número de cenários disponíveis na subestação, e na
secção 4.5.1.1 tinha sido configurada a existência dos Setting Group A, B, C, D.
Como referido anteriormente, a possibilidade de parametrização dos cenários existentes diz respeito
a um serviço que compõe a classe SGCB, porém nenhum destes serviços se encontra disponível no
ficheiro SCL.
No capítulo anterior tinha-se obtido um resultado negativo para configuração do atributo “ActSG”,
relativo ao cenário que estava em vigor (Figura 45). Após este segundo teste é esclarecida a razão
do insucesso verificado anteriormente, visto que o atributo em causa é inexistente no ficheiro SCL
exportado pelo DIGSI, sendo o valor “1” atribuído como um valor padrão (pelo Helinks STS). Logo, o
DIGSI não tem capacidade de interpretar este atributo e alterar o cenário de parametrizações que
vigora.
4.6 Ferramenta de conversão de ficheiros SCL entre
fabricantes
O Projecto-Tipo da EDP tem na sua génese a construção de uma subestação tipo onde todos os
processos de parametrizações e configurações consigam ser baseados num procedimento possível
de replicar para a generalidade das subestações.
Contudo, os fabricantes de protecções criaram os seus softwares próprios para lidar com a linguagem
SCL, acrescendo ainda o facto de a interpretação da norma IEC 61850 ser ligeiramente distinta entre
os diversos fabricantes. A solução permitida pela norma IEC 61850 para este problema resume-se à
utilização de ferramentas de engenharia universais capazes de lidar com as diferentes estruturas dos
ficheiros SCL apresentadas pelos fabricantes.
O Visual SCL e o Helinks STS utilizados laboratorialmente fazem parte da lista de ferramentas
universais. Contudo, e tal como já foi relatado previamente as ferramentas disponíveis e as diferentes
estruturas de apresentação de dados seguidas pelos fabricantes não permitem a completa
interoperabilidade dessas ferramentas. Por outro lado, para um determinado nível de tensão as
subestações assumem na generalidade dos casos uma topologia idêntica, pelo que todas as
configurações das unidades de protecção vão ter de ser repetidas sempre que se queira construir
uma nova subestação. Este método de configurações além de ser extremamente exaustivo para o
operador responsável pelas parametrizações, introduz uma grande probabilidade de erro humano
durante o extenso processo.
Foi assim proposto pelo orientador da Tese e demonstrado neste trabalho um método que permite
resolver os problemas de interoperabilidade encontrados, permitindo ainda uma configuração da
60
subestação totalmente reutilizável, recorrendo para tal, a um algoritmo programado de modo a operar
as configurações da norma IEC 61850 com base num procedimento único.
4.6.1 Objectivos
A solução adoptada para automatizar todas as configurações de serviços relacionados com a norma
IEC 61850 consistiu no desenvolvimento de um programa na linguagem de programação C++, que
permite a leitura e edição de ficheiros SCD, explorando o formato XML que serve de base à
linguagem SCL.
O programa que será denominado Conversor SCL explorou a extensa lista de bibliotecas já
existentes que permitem a interacção com ficheiros XML, bem como a facilidade de criação de um
ficheiro executável que possa ser executado num computador com o sistema operativo Windows.
O Conversor SCL não elimina a necessidade de uma ferramenta de configuração universal nem das
ferramentas proprietárias dos fabricantes. A função do programa é reduzir a quantidade de tempo e a
complexidade das operações entre o operador de sistema e as diversas ferramentas verificadas com
o método de configuração “manual”, resolvendo os problemas de interoperabilidade verificados
quando se tentam usar os grupos de dados.
De uma forma simplificada o programa permite a recepção de ficheiros SCD onde podem estar
inseridos IED’s genéricos, ou seja, IED’s cuja estrutura interna não está definida segundo a
interpretação de um determinado fabricante de protecções. A estrutura deste IED genérico depende
apenas da ferramenta de configuração de sistema utilizada, neste caso o Helinks STS.
A criação de um ficheiro SCD no Helinks STS com base nestes IED’s genéricos origina um ficheiro
cujos serviços e dados, não representam nenhuma unidade de protecção real de algum fabricante de
protecções em particular. O que o Conversor SCL realiza é o reconhecimento desse IED genérico, e
a sua conversão para a estrutura de um determinado fabricante em particular. Assim, será possível
parametrizar toda uma subestação com base em entidades genéricas e posteriormente converter
para a estrutura de um determinado fabricante, cada uma destas entidades.
O algoritmo referido encontra-se ilustrado graficamente na Figura 54. Nesta figura pode ver-se que
tanto a entrada como a saída do Conversor SCL são ficheiros com formato SCD. Para o caso
representado na figura atrás mencionada, a diferença está no facto de na entrada o ficheiro descritivo
da subestação ser constituído por um IED da Siemens e um genérico, enquanto na saída o ficheiro
passa a ser constituído por um IED da Siemens e um da Efacec. Ou seja, o programa reconheceu a
existência de uma entidade genérica e perguntou ao utilizador se este pretendia adjudicar esta
entidade a um determinado fabricante, sendo que neste caso se assumiu que o utilizador pretendeu
utilizar uma entidade da Efacec. Por outro lado, todas as entidades do ficheiro de entrada que não
sejam reconhecidas como genéricas permanecem inalteradas no ficheiro de saída.
61
Figura 54 – Diagrama funcional do Conversor SCL
No parágrafo anterior foi mencionada a adaptação de um IED genérico para um do fabricante Efacec,
porque este foi o único fabricante inserido na base de dados a que o Conversor SCL recorre.
Contudo, o método estudado pode ser extrapolado para qualquer fabricante do mercado que
implemente nas suas unidades de protecção as funcionalidades previstas na norma IEC 61850.
4.6.2 Funcionamento Geral
A linguagem de programação C++ utilizada para a construção do Conversor SCL foi escolhida em
detrimento das muitas outras linguagens, porque possui uma biblioteca preparada para a interacção
com as estruturas definidas nos ficheiros XML. Esta biblioteca denominada tinyXML, possui funções
pré definidas que permitem uma série de funcionalidades na análise dos ficheiros.
O código fonte do Conversor SCL foi construído segundo as linhas gerais da organização do código
em linguagem de programação C++, i.e., primeiro foram definidas todas as variáveis e estruturas
necessárias. De seguida, foram programadas todas as funções necessárias para o correcto
funcionamento do programa, e posteriormente foi construída a secção do código principal que
estabelece a interacção entre todas as funções construídas de modo a realizar os objectivos a que o
programa se propõe. No capítulo 4 dos anexos estão representadas algumas linhas do código fonte
do programa.
A compilação do código fonte gera um ficheiro executável (formato EXE) que interage directamente
com dois ficheiros: o ficheiro que constitui o input do Conversor SCL e ainda com o ficheiro XML
estático denominado “base_de_dados.XML” onde foi definida a estrutura dos ficheiros SCL da
Efacec. É com base neste ficheiro XML que os IED’s genéricos serão adaptados.
O programa foi seccionado nos cinco módulos principais listados de seguida. Para a realização das
funcionalidades principais de cada um destes módulos, foram criadas variadas funções. A interacção
entre todos os módulos foi realizada através de uma função principal que corre em sequência todas
as funções de cada um dos módulos.
1. Interacção com o utilizador
2. Análise das entidades de IED’s genéricos presentes no ficheiro de input
3. Interacção com a base de dados do programa
62
4. Análise da estrutura do novo IED e respectiva adaptação
5. Salvaguarda de todos os dados e geração do ficheiro de output
De seguida, são descritos todos os módulos e respectivas funcionalidades consideradas no seu
âmbito de actuação.
1. Interacção com o utilizador
Recepção do ficheiro SCD de input
Procura de IED’s genéricos no ficheiro SCD
Questionamento do utilizador no sentido de percepcionar se este deseja adaptar a
entidade de IED genérica encontrada a uma outra presente na base de dados do
programa
Interacção com o utilizador para recolher os dados necessários para a adaptação do IED
genérico (nome do novo IED, nome do fabricante desejado e serial number do novo IED)
2. Análise das entidades de IED’s genéricos presentes no ficheiro de input
Análise das estruturas XML referentes aos IED’s genéricos, à procura do seu nó lógico
LNN0
Análise das estruturas XML do nó lógico LNN0, à procura de instâncias de RCB
Análise das estruturas XML do nó lógico LNN0, à procura de instâncias de DataSets
Análise das estruturas XML referentes às instâncias de DataSets à procura de atributos
Gravação de todos os dados recolhidos (RCB, DataSets e atributos) numa estrutura
interna do programa
3. Interacção com a base de dados do programa
Interacção com um ficheiro XML externo chamado “base_de_dados.XML” que constitui a
base de dados associada ao programa, a fim de verificar se o fabricante escolhido pelo
utilizador está disponível nas bibliotecas do programa.
Eliminação de todas as linhas do código do ficheiro SCD respeitantes ao IED genérico
Transcrição das estruturas XML do IED do novo fabricante definido na base de dados,
para a antiga localização do IED genérico
4. Análise da estrutura do novo IED e respectiva adaptação
Análise das estruturas XML referentes ao novo IED à procura dos campos onde está
descrito o nome e o serial number do IED, alterando estes dados de acordo com as
informações recolhidas do utilizador
Análise das estruturas XML do nó lógico LNN0 do novo IED à procura de instâncias de
RCB, DataSets e atributos, alterando estes dados de acordo com as informações
recolhidas do IED genérico
5. Salvaguarda de todos os dados e geração do ficheiro de output
Geração de um ficheiro de output com a efectivação da adaptação dos IED’s genéricos
definidos no ficheiro de input
63
Interessa ainda referir, que esta sequência de interacção entre os diversos módulos é repetida pelo
Conversor SCL tantas vezes quantas as entidades de IED’s genéricos definidas no ficheiro de input.
4.6.3 Fluxograma
O fluxograma do Conversor SCL encontra-se representado na Figura 56. Nesta figura é possível
observar duas formas ovais delineadas a vermelho representativas do input e output do programa. Da
mesma forma, os blocos rectangulares representam os subsistemas onde se actua directamente no
ficheiro, e os losangos os subsistemas onde surge a necessidade de uma tomada de decisão.
Um dos pontos fundamentais para uma correcta percepção do programa construído passa pela
clarificação do conceito de uma entidade nova, que se denominou de IED genérico. Tal como já foi
visto anteriormente, as ferramentas de configuração de sistema permitem a associação de IED’s,
através da importação dos ficheiros .ICD que lhes estão associados. Contudo, estas ferramentas
permitem outro método de associação destas entidades, onde o operador pode facilmente criar um
novo IED através de um ícone “New IED”. Imediatamente após a associação desta entidade, o
objecto que o caracteriza é apenas constituído pela raiz da estrutura hierárquica que define o modelo
de um IED com base na norma IEC 61850. Esta estrutura genérica, pode ir sendo consecutivamente
ramificada consoante as configurações que se desejam efectuar no IED. A Figura 55 esquematiza
todas as ramificações necessárias para configurar as estruturas da comunicação vertical,
apresentando ainda, todos os nós terminais (a vermelho) necessários para uma correcta definição do
IED genérico.
Figura 55 – Esquema das ramificações a implementar no modelo de um IED genérico
Todas as ramificações que foram esquematizadas anteriormente, podem ser transcritas para o
Helinks STS, obtendo-se um resultado semelhante ao exemplificado na Figura 60.
DataSet1
LD_generico
AP1
IED_generico IED
Acess Point
Server
Logical Device
LN0
Data Set
FCDA
Report Control
Lnodes
64
Figura 56 – Fluxograma do Conversor SCL
Percorre o ficheiro
.scd à procura de um
IED genérico
Não efectua
nenhuma alteração
sobre o ficheiro
Caso encontre Caso não encontre
Não
Pergunta ao
operador qual o
nome que deseja dar
ao IED e qual o seu
serial number
Recolhe dados do
IED genérico
Substitui a estrutura
do IED genérico pela
do fabricante e
insere os dados
pedidos ao utilizador
Verifica se o IED genérico
tem DataSet’s e RCB’s
Actualiza o ficheiro
.scd inicialNão tem
Do template do IED do
fabicante recolhe todos
os Lnodes
disponibilizados e
respectivos atributos
internos
Tem
IED do fabricante tem Lnodes
e atributos descritos no
DataSet do IED genérico
Adiciona ao template
do IED os DataSet e
RCB, de acordo com
o modelo desse
fabricante
Avisa o operador
que não existem
disponiveis no IED
todos os dados
Não
Operador deseja
continuar a conversão
dos restantes
Não
Sim
Sim
Ficheiro SCD
Operador quer trocar o IED
genérico por um de um
fabricante
Sim
Ficheiro SCD
65
4.6.4 Procedimentos
O objectivo principal da execução dos procedimentos que se seguem, consiste em provar que é
possível desenvolver configurações reutilizáveis para uma subestação, que conseguem ser
devidamente convertidas um projecto particular através da interacção com uma nova ferramenta de
engenharia.
Na sequência de testes que se segue, foram associados à descrição da subestação dois IED’s, um
pertencente a um fabricante específico e o outro seguindo o conceito de IED genérico, explicado no
capítulo anterior. A associação do IED de um fabricante específico não acrescenta valor aos testes,
permitindo apenas ilustrar que esta entidade não entra em conflito com a entidade genérica. É
precisamente nesta entidade genérica que se centra a experiência, dado que é com base em
entidades semelhantes que se quer provar a hipótese de reutilizar as configurações de uma
subestação. A descrição da subestação com base nestes dois IED’s vai interagir com o software
desenvolvido, de modo a demonstrar que este permite converter as especificações reutilizáveis numa
configuração que represente um caso particular.
Os procedimentos realizados foram organizados com base nas quatro fases principais listadas de
seguida:
1ª Fase - Importação e parametrização de um IED da Siemens no Helinks STS
2ª Fase - Associação e parametrização de um IED genérico no Helinks STS
3ª Fase - Interacção entre o ficheiro SCD resultante e o Conversor SCL
4ª Fase a) - Importação do ficheiro SCD gerado no Conversor SCL para o Helinks STS
4ª Fase b) - Importação do ficheiro SCD gerado no Conversor SCL para o DIGSI
O ficheiro SCD que constitui a entrada do Conversor SCL (3ª Fase) tem associado na sua estrutura
interna dois IED’s, um da Siemens (parametrizado na 1ª Fase) e um genérico (parametrizado na 2ª
Fase). Tal com já foi mencionado anteriormente, todos os IED’s do ficheiro de entrada que não sejam
reconhecidos como genéricos deverão permanecem inalterados no ficheiro de saída, ou seja, o IED
da Siemens que foi associado ao ficheiro não deverá sofrer qualquer tipo de alterações.
Relativamente ao IED genérico que está presente no ficheiro, o Conversor SCL irá proceder à
adaptação da sua estrutura para que este esteja de acordo com as especificidades de um fabricante
específico, neste caso a Efacec. A compatibilidade do ficheiro que constitui o output do programa, irá
ser verificada tanto para o Helinks STS [4ª Fase a)], como para o DIGSI [4ª Fase b)].
Tal como foi previamente mencionado na secção 4.4, o Projecto-Tipo não refere quais os atributos
que devem ser reportados por cada um dos nós lógicos presentes na subestação. Desta forma no
decorrer dos testes que se seguem, escolheram-se alguns dos atributos disponibilizados sem grande
66
preocupação com a informação que lhes esta associada, visto que se pretende apenas exemplificar o
princípio de funcionamento do programa em análise.
4.6.4.1 1ª Fase - Importação e parametrização de um IED
da Siemens no Helinks STS
A 1ª fase dos procedimentos começa com a associação de um IED ao ficheiro descritivo da
subestação, através da importação de um ficheiro SCL com o formato ICD, tal como descrito na
secção 3.6.3. Na Figura 57, já pode ser observada a associação de um IED à subestação, mais
concretamente o IED_0010 da Siemens.
Figura 57 – IED’s considerados dentro da descrição de uma subestação no Helinks STS
O ficheiro ICD que deu origem à instância de IED representada na figura anterior, foi gerado pelo
DIGSI. As estruturas responsáveis pela comunicação vertical deste IED (DataSets e RCB), podem
ser previamente criadas no DIGSI antes da exportação do ficheiro ICD (através do método explicado
na secção 4.4.2), ou então, podem ser criadas directamente no Helinks STS após importação do
ficheiro (através do método explicado na secção 4.4.4).
Optou-se por efectuar as configurações através do Helinks STS, tendo-se obtido o resultado
demonstrado na Figura 58. Nesta figura, pode-se analisar que foi criada uma instância de “Data Set”,
onde foram associados três atributos, mais especificamente:
PDIS.Str
PTOC.Op
XCBR.Mod
67
Figura 58 – Estrutura interna do IED_0010 no Helinks STS
4.6.4.2 2ª Fase - Associação e parametrização de um IED
genérico no Helinks STS
Nesta fase dos procedimentos vai ser associada uma instância de um IED genérico no mesmo
ficheiro descritivo da subestação onde já foi configurado o IED_0010. O resultado deste procedimento
pode ser analisado na Figura 59, onde é evidente a presença dos dois IED’s.
68
Figura 59 – IED’s considerados dentro da descrição de uma subestação no Helinks STS
O ficheiro SCD resultante de todas as configurações que tiveram lugar, vai ter de ser interpretado
pelo Conversor SCL. Os nomes dos níveis criados durante a ramificação da estrutura do IED
genérico têm de ser criteriosamente atribuídos, dado que é através deles que o Conversor SCL
consegue percepcionar a existência de um IED genérico e respectivas estruturas constituintes. Desta
forma, os nomes de todos os objectos relevantes para o correcto funcionamento do programa foram
pré definidos, encontrando-se representados na secção lateral esquerda da Figura 55. Todas as
ramificações esquematizadas nesta figura, foram transcritas para o Helinks STS, tal como se pode
observar na Figura 60. Numa análise criteriosa desta figura, pode verificar-se a correspondência
directa entre os nomes atribuídos aos objectos, e os nomes pré definidos que foram dispostos na
Figura 55.
Figura 60 – Estrutura interna do IED_generico no Helinks STS
69
Na figura anterior pode ser analisado que foi criada uma instância DataSet, denominada “DataSet1”
onde foram definidos os três atributos listados de seguida.
XCBR.Pos
XCBR.BlkOpn
RREC.BlkRec
Este DataSet foi associado a uma instância de RCB denominada “Report Control URCB”, cujas
propriedades podem ser verificadas na Figura 61.
Figura 61 - Estrutura interna da instância de RCB do IED2_lab no Helinks STS
4.6.4.3 3ª Fase - Interacção entre o ficheiro SCD
resultante e o Conversor SCL
A presente fase de testes, começa com a importação do ficheiro proveniente da fase anterior para o
Conversor SCL. O referido ficheiro tem definido na sua estrutura interna dois IED’s, um pertencente
ao fabricante Siemens e outro genérico.
O Conversor SCL ao recepcionar o ficheiro, se detectar a presença de um IED genérico gera
automaticamente uma interface de comunicação com o utilizador, representada na Figura 62.
Figura 62 – Interface de comunicação com o utilizador do Conversor SCL
70
O programa requer a interacção do utilizador, para responder às quatro perguntas listadas de
seguida:
Encontrar IED genérico. Substituir? [s/n]
Inserir nome do IED que vai ser substituir o genérico:
Inserir fabricante do IED que vai substituir o genérico:
Inserir número de série:
Na Figura 62 foram delineadas a vermelho as respostas que foram fornecidas para este caso
concreto. Tal como se pode observar na referida figura, o utilizador optou por proceder à substituição
do IED genérico, por um da Efacec, com o nome IED2_lab e o número de série, 903016. Todas as
informações prestadas ao programa vão ser integradas na estrutura interna do ficheiro SCD
resultante.
O Conversor SCL, é executado com base num ficheiro com o formato EXE, e o ficheiro resultante
denominado “output.scd” é gerado na mesma directoria onde se situa o ficheiro executável.
4.6.4.4 4ª Fase a)- Importação do ficheiro SCD gerado no
Conversor SCL para o Helinks STS
Nesta fase do teste, o ficheiro que constitui o output do Conversor SCL já pode ser analisado com o
objectivo de se verificar se as alterações efectuadas pelo programa estão de acordo com os modelos
SCL definidos.
Para a análise do ficheiro “output.scd”, recorreu-se em primeira instância ao Helinks STS. Tal como
se pode observar na Figura 63 o ficheiro já considera um IED da Siemens e de um da Efacec, em vez
de um IED da Siemens e de um genérico (Figura 59).
Figura 63 – IED’s considerados dentro da descrição de uma subestação no Helinks STS
Ainda nesta fase de teste, interessa verificar se as configurações do “Data Set” e do RCB, também
foram correctamente descritas no ficheiro “output.scd”. Os referidos campos podem ser analisados na
estrutura interna do IED2_lab, representada na Figura 64. Nesta figura é possível observar que o
71
campo “Data Set” foi parametrizado com todos os atributos que tinham sido previamente definidos na
Figura 60:
XCBR.Pos
XCBR.BlkOpn
RREC.BlkRec
Figura 64 – Estrutura interna do IED2_lab no Helinks STS
Os resultados obtidos nesta fase de teste, comprovam que o Conversor SCL está a cumprir os
objectivos para o qual foi construído, dado que confirmam ser possível uma ferramenta de
configuração de sistema importar o ficheiro resultante do programa, interpretando correctamente a
sua estrutura interna e respectivas configurações. Contudo, em última análise o ficheiro “output.scd”
tem de ser importado com sucesso pela ferramenta de configuração de IED’s em utilização (DIGSI),
situação que vai ser testada na fase seguinte.
72
4.6.4.5 4ª Fase b)- Importação do ficheiro SCD gerado no
Conversor SCL para o DIGSI
Na fase de teste anterior, provou-se que o ficheiro “output.scd” foi correctamente interpretado pelo
Helinks STS. Contudo, para provar que o Conversor SCL cumpre a sua função a todos os níveis,
ainda é preciso demonstrar que a importação do ficheiro para o DIGSI também decorre sem
problemas.
Para proceder à importação no DIGSI, foi criado um novo ícone descritivo de uma subestação e
descarregado o ficheiro “output.scd”. Como a subestação criada ainda não tinha nenhum IED
associado, o relatório da importação indica que tanto o IED_0010 como o IED2_lab, ainda não
estavam presentes na subestação, pelo que surgem os dois warnings que podem ser analisados na
Figura 65.
Figura 65 - Relatório da importação de um ficheiro SCD para o DIGSI
Os warnings retornados pelo relatório de importação não são problemáticos, apenas avisam o
utilizador que as instâncias de IED’s que se estão a importar ainda não estavam definidas dentro do
ícone descritivo da subestação. Se o utilizador desejar continuar com a importação, a descrição da
subestação é actualizada em função do ficheiro SCD, sendo retornado um novo relatório. Este novo
relatório já não denota qualquer tipo de problema (Figura 66).
Figura 66 - Relatório da importação de um ficheiro SCD do DIGSI
73
Após o ficheiro ter sido importado com sucesso, interessa aferir se o DIGSI reconhece a presença
dos dois IED’s, e se para cada deles interpreta correctamente as configurações efectuadas. Na
Figura 67 é possível analisar que o DIGSI reconheceu a associação dos dois IED’s no ficheiro
descritivo da subestação.
Figura 67 – IED’s considerados dentro da descrição de uma subestação no DIGSI
Para o IED_0010, foi configurado no capítulo 4.6.4.1 um RCB com os seguintes atributos:
PDIS.Str
PTOC.Op
XCBR.Mod
A Figura 68 reflecte a interpretação que o DIGSI faz das configurações do IED_0010 realizadas no
Helinks STS. Comparando os atributos definidos na figura, com os atributos que foram listados,
confirma-se que o DIGSI está efectivamente a interpretar com sucesso as configurações.
Figura 68 - Estrutura interna da instância de RCB do IED_0010 no DIGSI
O Conversor SCL apenas exerce efeito sobre IED’s genéricos, ou seja, dos dois IED’s presentes no
ficheiro SCD que constituiu o input do programa apenas o IED2_lab foi sujeito a alterações, pelo que
o resultado positivo para o IED_0010 era completamente esperado. Por outro lado, a configuração do
IED2_lab reveste-se de relevância acrescida.
Para o IED2_lab, foi configurado na secção 4.6.4.2 um RCB com os seguintes atributos:
XCBR.Pos
XCBR.BlkOpn
RREC.BlkRec
74
As configurações que haviam sido efectuadas no Helinks STS para o IED2_lab, foram devidamente
interpretadas pelo DIGSI, tal como se pode observar na Figura 69. A analogia entre os atributos
definidos na figura, e os atributos que foram listados, revela que o DIGSI está efectivamente a
interpretar com sucesso as configurações.
Figura 69 - Estrutura interna da instância de RCB do IED2_lab no DIGSI
Este resultado confirma o sucesso total do Conversor SCL como uma ferramenta de engenharia,
demonstrando a sua compatibilidade com as especificidades dos modelos SCL definidos na norma
IEC 61850. Com base nos procedimentos de testes efectuados confirma-se que o programa criado
tem a capacidade de converter o modelo de um IED genérico para a estrutura de um fabricante
específico, não comprometendo a possibilidade de este ficheiro ser importado pela ferramenta de
configuração de IED’s numa fase posterior de configurações.
75
5 Conclusões
5.1 Conclusões Principais
O advento da norma IEC 61850 e dos seus princípios de interoperabilidade e livre alocação de
funções trouxe novas perspectivas, no que se refere à concepção e configuração de sistemas de
automação. Neste contexto, o presente documento relata uma serie de procedimentos experimentais
e elabora algumas propostas de desenvolvimento de novas soluções ao nível das ferramentas de
engenharia que permitam lidar com a SCL. Desta forma, ao longo dos trabalhos laboratoriais foi
explorada a interacção de várias ferramentas de engenharia e da sua adequação e cumprimento dos
padrões estabelecidos pela norma, ou seja, a uma adequação da estrutura dos ficheiros SCL a fim de
garantir uma engenharia de configuração o mais fiável possível.
A ferramenta de configuração de sistema, Visual SCL, reconhece e interpreta sem qualquer problema
os ficheiros SCL provindos do DIGSI, porém, o processo de validação da ferramenta de configuração
proprietária da Siemens (DIGSI) aos ficheiros provenientes do Visual SCL retorna uma extensa lista
de erros de cariz sistemático. Quando o Visual SCL recebe um ficheiro e encontra esta sintaxe que
não é a sua, opta por alterar o ficheiro original apagando informações que na sua óptica
correspondem a redundância de dados. Esta estrutura de dados padrão que rege o Visual SCL é
denominada de Visual SCL schema, tendo-se comprovado que aplica ao ficheiro originário do DIGSI
modificações inibidoras da sua posterior transferência.
O processo de resolução dos erros decorreu de forma simples, sendo apenas necessário analisar
qual o formato standart que o DIGSI necessita e corrigindo as respectivas linhas do ficheiro SCL de
forma a moldar o formato dos dados de acordo com uma estrutura padrão. Embora este processo
tenha sido testado com sucesso provando que resolve os erros, é evidente que consiste em contornar
uma situação problemática, não a resolvendo para futuras transferências de ficheiros.
No que diz respeito à outra ferramenta de configuração de sistema testada, Helinks STS, não foi
verificado qualquer tipo de situação anómala, quando se submeteu a ferramenta aos testes que já
haviam sido ensaiados no Visual SCL. Conclui-se então, que ao nível da compatibilidade entre
algumas das ferramentas de engenharia exploradas ainda se encontram alguns problemas, porém
este processo revela desde já um caminho promissor provando ser perfeitamente exequível a
transferência de ficheiros SCL com as configurações dos IED’s e das subestações entre softwares de
diferentes fabricantes.
A norma IEC 61850 define a existência de uma série de blocos funcionais, o agrupamento de todos
estes blocos funcionais chama-se “Control Blocks”. Dentro deste bloco analisaram-se exaustivamente
o RCB e o SGCB. A configuração do RCB no DIGSI não apresentou qualquer problema. Também o
processo de transferência de ficheiros SCL entre o DIGSI e o Helinks STS e vice-versa, decorreu sem
a ocorrência de erros.
76
Um dos serviços definidos pela norma IEC 61850, consiste na possibilidade de parametrização das
funções de protecção, ou ainda, ao nível dos atributos o número do cenário que está activo e o
número total de cenários configurados. Tal como é esperado de uma ferramenta de configuração de
IED’s o DIGSI permite nos seus menus a edição de todos estes dados. Porém quando se pede ao
DIGSI para criar o ficheiro SCL descritivo da subestação seria de esperar que este englobasse no
respectivo ficheiro todos os dados relativos á parametrização dos cenários e respectivos atributos
previamente configurados. Visto que o DIGSI não está preparado para incluir nos seus ficheiros SCL
grande parte da informação respeitante ao SGCB, todo o processo de configuração da subestação
vai ficar limitado. Tendo em conta que o objectivo era a exportação da informação para uma
ferramenta de configuração de sistema, pode-se constatar facilmente que a parametrização das
funções de protecção e dos respectivos cenários na referida ferramenta ficam comprometidas. A
parametrização das funções de protecção e respectivos cenários de actuação pode ser unicamente
configurada recorrendo ao software de configuração do DIGSI, sendo que todos estes dados são
guardados posteriormente como ficheiros de configuração sem qualquer relação com os ficheiros
SCL.
Fazendo uma analogia com as potencialidades dos programas demonstradas nos testes do RCB,
fica-se com a sensação que o tópico dos SGCB podia ter sido explorado de forma a possuir
características de maior interactividade com a norma IEC 61850.
Para finalizar, o documento incidiu a sua abordagem na construção de um software com
funcionalidades específicas que permitissem uma interacção com ficheiros SCL. O algoritmo da
ferramenta de engenharia construída, actua no sentido de uma cooperação com as ferramentas de
engenharia já exploradas durante o trabalho, com a finalidade de importar ficheiros SCL com IED’s
genéricos, exportando posteriormente um ficheiro SCL com uma descrição da subestação com base
em IED’s reais. Este objectivo foi atingido com sucesso, tendo sido comprovado que a ferramenta em
questão cumpre todos os resultados a que se propunha.
5.2 Direcções de Investigação
No sentido de conseguir chegar a um ficheiro SCL descritivo de uma subestação, onde sejam
consideradas todas as principais potencialidades da norma IEC 61850, a direcção de investigação
tem de passar obrigatoriamente pela configuração da comunicação horizontal, os GOOSE. Para o
estudo dos GOOSE deverão ser exploradas novamente todas as ferramentas de engenharia no
sentido de verificar se a sua interacção consegue lidar correctamente com este novo serviço. De uma
forma global, todos os procedimentos laboratoriais relatados neste documento para os RCB, podem
ser replicados para o estudo dos GOOSE, dado que a estrutura das variáveis de configuração
associadas aos CB não varia muito de serviço para serviço. Ainda no sentido da configuração dos
GOOSE, seria muito interessante fazer a actualização da ferramenta de engenharia criada, para que
esta conseguisse cumprir os objectivos para a qual foi construída, mas agora conseguindo não só
configurar a comunicação vertical mas também a horizontal.
77
O trabalho desenvolvido recaiu apenas sobre um painel específico da subestação tipo. Desta forma,
os métodos que foram analisados podem ser replicados com a devida adaptação aos restantes
painéis da subestação.
O Conversor SCL recorre a uma base de dados com as estruturas SCL típicas dos dois fabricantes
considerados no decorrer do trabalho. Como desenvolvimento futuro também seria interessante a
actualização da base de dados com os restantes fabricantes de protecções que já adaptaram as suas
unidades de protecção à norma IEC61850.
78
6 Referências Bibliográficas
[1] IEC TC 57, “IEC 61850-7-1: Communication Networks and Systems in Substations, Part: 7-1:
Basic communication structure for substation and feeder equipment – Principles and Models“
[2] IEC TC 57, “IEC 61850-7-2: Communication Networks and Systems in Substations, Part: 7-2:
Basic communication structure for substation and feeder equipment – Abstract communication service
interface (ACSI)”
[3] IEC TC 57, “IEC 61850-7-4: Communication Networks and Systems in Substations, Part 7-4: Basic
communication structure for substation and feeder equipment – Compatible logical node classes and
data classes”
[4] IEC TC 57, “IEC 61850-5: Communication Networks and Systems in Substations, Part 5:
Communication requirements for functions and device models”
[5] IEC TC 57, “IEC 61850-6: Communication Networks and Systems in Substations, Part 6: Part 6:
Configuration description language for communication in electrical substations related to IEDs”
[6] EDP – Conjunto de informação relativa ao Projecto-Tipo de subestações AT/MT
[7] Pedro Filipe Moreira Dias, “Projecto estruturado de Sistemas de Automação em Subestações
segundo a norma 61850”, Tese de mestrado, IST, 2009
[8] John McDonald, J., Udren, E. and Strabbing, W., “IEC 61850”, KEMA, Sep. 2005
[9] Alexander Apostolov, Damien Tholomier, Simon Richards, AREVA T&D Automation, “Simplifying
the Configuration of Multifunctional Protection Relays”
[10] Carl Öhlén, “Um IED com conceito modular e prova de futuro”, Rio de Janeiro, April 23-25, 2006
[11] Rui Bernardo, “Projecto de Configuração de Subestações da EDP D de acordo com a IEC 61850,
Fase 1, EDP Distribuição/DTI/TIID”
[12] Manual da SIPROTEC 7SA522, Distance Protection, V4.61 and higher
79
Anexos
1. Correspondência entre funções do SPCC e nós lógicos
Painéis de MT Classes de nós lógicos
Funções
Chegada do TP AT/MT
Máximo Intensidade de Fase PIOC, PTOC
Minimo de Tensão PTUV
Máximo de Tensão PTOV
Minimo de Frequencia PTUF
Monitorização do Disjuntor XCBR
Registo de acontecimentos RBDR, RDRE
Osciloperturbografia RADR, RBDR, RDRE
Bateria de Condensadores
Desequilibrio de Neutro PIOC, PTOC
Máximo Intensidade de Fase PIOC, PTOC
Máximo Intensidade Homopolar PIOC, PTOC
Máximo de Tensão PTOV
Monitorização do Disjuntor XCBR
Registo de acontecimentos RBDR, RDRE
Osciloperturbografia RADR, RBDR, RDRE
Linha MT
Máximo de Intensidade de Fase PTOC
Máximo de Intensidade Homopolar Direccional PIOC, PTOC
Máximo de Intensidade Homopolar de Terras Resistentes PTOC
Condutor partido MSQUI, PTOC, PTUC
Presença de tensão RSYN
Função de monitorização disjuntor XCBR
Registo de acontecimentos RBDR, RDRE
Osciloperturbografia RADR, RBDR, RDRE
TSA+RN
Máximo Intensidade de Fase PIOC, PTOC
Máximo Intensidade Homopolar PIOC, PTOC
Máximo Intensidade Homopolar de Terras Resistentes PIOC, PTOC
Monitorização do Disjuntor XCBR
Registo de acontecimentos RBDR, RDRE
Osciloperturbografia RADR, RBDR, RDRE
Tabela 6 - Correspondência entre funcionalidades do SPCC (Painéis de MT) e classes de nós lógicos
80
Painéis de AT Classes de nós lógicos
Fu
nçõ
es
Linha de AT
Distância PDIS
Diferencial de linha /cabo (opcional) PDIF
Máximo de Intensidade de Fase PIOC, PTOC
Máximo de Intensidade Homopolar Direccional PIOC, PTOC
Máximo de Intensidade Homopolar de Terras Resistentes PIOC, PTOC
Power Swing Dtection RPSB
Weak End Infeed MSQI
Ligação sobre defeito PTUV, PTUC
Condutor Partido MSQI, PTOC, PTUC
Teleprotecção PSCH
Verificação de Sincronismo RSYN
Monitorização do Disjuntor XCBR
Localização de Defeitos RFLO
Registo de acontecimentos RBDR, RDRE
Osciloperturbografia RADR, RBDR, RDRE
Potencial de Barras AT
Diferencial PDIF
Minimo de Tensão PTUV
Verificação de Sincronismo RSYN
Registo de acontecimentos RBDR, RDRE
Osciloperturbografia RADR, RBDR, RDRE
TP AT/MT
Diferencial PDIF
Máximo Intensidade de Fase PIOC, PTOC
Monitorização do Disjuntor XCBR
Registo de acontecimentos RBDR, RDRE
Osciloperturbografia RADR, RBDR, RDRE
Tabela 7 - Correspondência entre funcionalidades do SPCC (Painéis de AT) e classes de nós lógicos
81
2. Interacção entre DIGSI e Visual SCL – Procedimentos
2.1 1ª Fase - Exportação (DIGSI) vs Importação (DIGSI)
Na Figura 70 pode observar-se um ícone denominado IEC 61850 station, onde foram definidos três
IED’s da Siemens e um IED da Efacec (Figura 71). O referido ícone permite a exportação do ficheiro
SCD descritivo da subestação.
Figura 70 – DIGSI manager
Figura 71 – IED’s considerados dentro da descrição de uma subestação no DIGSI
A exportação do ficheiro SCD foi efectuada do DIGSI com sucesso, tal se demonstra na Figura 72.
Nesta fase do teste foram anotadas as propriedades do ficheiro, nomeadamente o tamanho em disco
que este ocupa, que tal como se pode verificar na Figura 73 é de 544Kb. Presentemente esta
informação pode não parecer de grande utilidade mas vai-se revelar de extremo interesse para
perceber algumas situações que futuramente irão surgir.
82
Figura 72 – Relatório da exportação de um ficheiro SCD do DIGSI
Figura 73 – Propriedades do ficheiro IEC 61850 station
Após a exportação do ficheiro do DIGSI, procedeu-se à sua importação novamente neste, a fim de se
verificar se o programa está a funcionar correctamente. Tal como era expectável não surgiu qualquer
problema, pelo que foi retornada uma mensagem de sucesso (Figura 74).
Figura 74 - Relatório da importação de um ficheiro SCD do DIGSI
83
2.2 2ª Fase - Leitura e Salvaguarda do ficheiro SCD no
Visual SCL
Para esta fase recorreu-se ao ficheiro SCD exportado pelo DIGSI, e procedeu-se à sua abertura no
Visual SCL (Figura 75).
Figura 75 – Visualização de um ficheiro SCL no Visual SCL
Não foi realizada qualquer alteração ao ficheiro, este foi apenas aberto e guardado no Visual SCL.
Após fechar o programa foram novamente analisadas as propriedades do ficheiro resultante, num
processo análogo ao que havia sido realizado no capítulo anterior (Figura 73).
Contrariamente ao que era esperado, o tamanho que o ficheiro SCD ocupa no disco é agora de
448Kb (Figura 76), que contrasta com a situação inicial quando saiu do DIGSI onde ocupava 544Kb,
ou seja, após ser salvo pelo Visual SCL o ficheiro parece ter perdido informação.
84
Figura 76 – Propriedades do ficheiro IEC 61850 station
Prosseguiu-se no entanto a análise do ficheiro recorrendo ao Visual SCL, embora o resultado obtido
anteriormente seja premonitório de algum insucesso quando for necessário exportar o ficheiro para o
DIGSI.
Os problemas começaram a surgir precisamente na fase dos ensaios que se segue, nomeadamente
quando se torna necessário importar para o DIGSI um ficheiro que foi salvo no Visual SCL, é
retornado um extenso relatório de erros (Figura 77). O relatório de erros vai ser analisado no capítulo
que se segue, tendo como objectivo a exploração de um método que culmine na resolução de todas
as situações problemáticas.
Figura 77 – Relatório da importação de um ficheiro SCD para o DIGSI
85
2.3 3ª Fase – Método de Resolução dos Erros Resultantes
A primeira página da lista de erros encontra-se representada na Figura 78. Embora a lista apresente
um total de quatro páginas, os tipos de erros verificados resumem-se a dois, que foram sublinhados a
amarelos, e a vermelho.
Figura 78 – Erros do relatório de importação de um ficheiro SCD para o DIGSI
Após analisar criteriosamente a lista verificou-se que os dois tipos surgem sempre associados, sendo
que no total do documento existem catorze grupos de erros que englobam sempre estes dois erros,
perfazendo um total de vinte e oito erros.
Dado que quando um erro é identificado, o programa de validação refere em que linha do código este
se encontra foi possível verificar individualmente as linhas problemáticas recorrendo a um editor de
código XML. Comparando as referências das linhas onde os erros ocorrem com as linhas do ficheiro
problemático (Figura 79), é possível concluir que os erros se distribuem por todos os IED’s presentes
no ficheiro.
86
Figura 79 – Visualização de um ficheiro SCD no XML Copy Editor
De forma a descobrir a causa originadora dos erros recorre-se ao 1º grupo de erros com a intenção
de verificar o que estava detalhado na linha do código. Para o 1º tipo de erro encontra-se
representado na Figura 80 o que consta no ficheiro que saiu directamente do DIGSI (esquerda), e o
ficheiro salvo no Visual SCL (direita).
Figura 80 – Comparação entre ficheiros no editor de código XML (lado esquerdo: DIGSI; lado direito: Visual SCL)
No relatório dos erros está descrito que este erro se deve à inexistência de um campo “InClass”, cuja
ausência realmente se verifica. Para tentar corrigir esta situação adicionou-se a informação relativa
ao campo referenciado de forma a ficar idêntico à situação ideal.
Voltou-se de seguida ao software que valida o ficheiro e verificou-se que a alteração efectuada teve o
efeito esperado, resolvendo não só o problema da linha 148 mas também o da linha 180, ou seja ao
corrigir o erro do 1º tipo o erro do 2º tipo desaparece automaticamente.
Este procedimento foi repetido para todas as linhas de código onde se verificava o erro do 1º tipo,
nomeadamente: 148, 566, 781, 843, 1476, 1827, 2047, 2109, 2701, 4646, 4782, 5120, 5182, 5344.
Após a correcção de todos os erros, a lista ficou apenas resumida a uma referência. Esta situação
problemática refere-se a um IED da Efacec onde o tipo de erro não parece ser idêntico aos
anteriores.
Embora à primeira vista a comparação da linha problemática entre o ficheiro originário do DIGSI e o
ficheiro salvo no Visual SCL pareça igual, comprova-se que existe um espaço adicional entre dois
87
caracteres. Este espaço que foi adicionado após o ficheiro ter sido salvo no Visual SCL está na causa
do erro apontado e a sua eliminação resulta na extinção do mesmo.
Após reparar todas as situações problemáticas o relatório de erros fica efectivamente “limpo”, tal
como está descrito na Figura 81.
Figura 81 – Relatório de importação de um ficheiro SCD para o DIGSI
88
3. Interacção entre o DIGSI e o Helinks STS –
Procedimentos
A 1ª Fase é em tudo idêntica à interacção demonstrada na secção 2.1, pelo que não se achou
importante repetir todo o processo já descrito.
3.1 2ª Fase - Leitura e Salvaguarda do ficheiro SCD no
Helinks STS
Para esta fase recorreu-se ao ficheiro SCD exportado pelo DIGSI, e procedeu-se à sua abertura no
Helinks STS (Figura 82). Comparando com a visualização do ficheiro no Visual SCL (Figura 75)
consegue-se comprovar que o ficheiro que está a ser utilizado para testar o Helinks STS contem na
sua estrutura interna exactamente os mesmos IED’s do ficheiro que foi utilizado para testar o Visual
SCL.
Figura 82 - Visualização da organização dos IED’s considerados num ficheiro SCL no Helinks STS
Não foi realizada qualquer alteração ao ficheiro, este foi apenas aberto e guardado no Helinks STS.
No caso da interacção com o Visual SCL os problemas começaram a surgir precisamente nesta fase
dos ensaios, nomeadamente quando se torna necessário importar para o DIGSI o ficheiro
previamente guardado no Visual SCL. Contudo para o caso vertente em que o ficheiro é guardado
recorrendo ao Helinks STS não é retornado nenhum erro no processo de importação no DIGSI
(Figura 83).
Este resultado positivo é muito importante, visto que comprova a existência de uma ferramenta de
configuração sistema que consegue interagir com robustez com as ferramentas de configuração de
IED’s testadas.
89
Figura 83 - Relatório de importação de um ficheiro SCD para o DIGSI
90
4. Aspecto do código fonte do Conversor SCL
Figura 84 – Aspecto do código fonte do Conversor SCL
