Duarte Filipe Reves Martins. Dissertação para obtenção do Grau de Mestre em. Engenharia Electrotécnica e de Computadores. Júri

Transcrição

1 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

2 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 i

3 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 proporcionado 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 desenvolvimento 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 proporcionaram 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, revelandose 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. ii

4 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 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, denominadas 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 relacionados 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 Linguagem SCL - Substations Configuration Language Sistemas de Automação e Protecção iii

5 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 Automation and protection systems for EDP substations, using the organization for objects and SCL language set in IEC 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 addition 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 SCL Language - Substations Configuration Language Automation and Protection Systems iv

6 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 ENQUADRAMENTO OBJECTIVOS ORGANIZAÇÃO DA DISSERTAÇÃO NORMA IEC HIERARQUIA FUNCIONAL DOS IED S LOGICAL NODE CLASS LOGICAL NODE ZERO (LLN0) ORGANIZAÇÃO FUNCIONAL DE NÓS LÓGICOS LINGUAGEM SCL CONTROL BLOCK S (CB S) Setting Group Control Block (SGCB) Report Control Block (RCB) FERRAMENTAS DE ENGENHARIA Ferramentas de Configuração de Sistema Ferramentas de Configuração de IED s PROJECTO-TIPO DA EDP ARQUITECTURA E ORGANIZAÇÃO FUNCIONAL DO SPCC ESQUEMA UNIFILAR DA SUBESTAÇÃO DEFINIÇÃO DAS FUNCIONALIDADES PRESENTES NO SPCC COMPATIBILIZAÇÃO COM A NORMA IEC CORRESPONDÊNCIA ENTRE FUNÇÕES DO SPCC E NÓS LÓGICOS CONFIGURAÇÕES DE UMA SUBESTAÇÃO SEGUNDO A NORMA IEC Desenho do esquema unifilar da subestação Associação de nós lógicos de protecção genéricos aos painéis (Bays) da subestação Importação dos ICD s dos fabricantes dos IED s a instalar na subestação Associação dos IED s aos painéis que estes vão proteger na subestação CONFIGURAÇÃO REUTILIZÁVEL DO PROJECTO-TIPO ESTRUTURAS DE DADOS DISTINTAS ENTRE IED S DE DIFERENTES FABRICANTES Procedimentos Organização do Logical Device Organização dos Logical Node Zero (LLN0) INTERACÇÃO ENTRE O DIGSI E O VISUAL SCL ª Fase - Exportação do DIGSI vs Importação DIGSI ª Fase - Leitura e Salvaguarda do ficheiro SCD no Visual SCL ª Fase - Método de Resolução dos Erros Resultantes ª Fase Explicação técnica dos bugs pela ASE INTERACÇÃO ENTRE O DIGSI E O HELINKS STS v

7 ª Fase - Exportação do DIGSI vs Importação DIGSI ª Fase - Leitura e Salvaguarda do ficheiro SCD no Helinks STS REPORT CONTROL BLOCK Procedimentos Configuração básica do RCB no DIGSI º Teste - Exportação do RCB do Helinks STS para o DIGSI º Teste - Exportação RCB do Helinks STS para o DIGSI SETTING GROUP CONTROL BLOCK Procedimentos Configuração do SGCB no DIGSI º Teste Teste do SGCB recorrendo ao Helinks STS º Teste Teste do SGCB recorrendo a um editor de texto XML FERRAMENTA DE CONVERSÃO DE FICHEIROS SCL ENTRE FABRICANTES Objectivos Funcionamento Geral Fluxograma Procedimentos ª Fase - Importação e parametrização de um IED da Siemens no Helinks STS ª Fase - Associação e parametrização de um IED genérico no Helinks STS ª Fase - Interacção entre o ficheiro SCD resultante e o Conversor SCL ª Fase a)- Importação do ficheiro SCD gerado no Conversor SCL para o Helinks STS ª Fase b)- Importação do ficheiro SCD gerado no Conversor SCL para o DIGSI CONCLUSÕES CONCLUSÕES PRINCIPAIS DIRECÇÕES DE INVESTIGAÇÃO REFERÊNCIAS BIBLIOGRÁFICAS ANEXOS CORRESPONDÊNCIA ENTRE FUNÇÕES DO SPCC E NÓS LÓGICOS INTERACÇÃO ENTRE DIGSI E VISUAL SCL PROCEDIMENTOS ª Fase - Exportação (DIGSI) vs Importação (DIGSI) ª Fase - Leitura e Salvaguarda do ficheiro SCD no Visual SCL ª Fase Método de Resolução dos Erros Resultantes INTERACÇÃO ENTRE O DIGSI E O HELINKS STS PROCEDIMENTOS ASPECTO DO CÓDIGO FONTE DO CONVERSOR SCL vi

8 Lista de Figuras Figura 1 - Modelo do IED segundo a norma IEC [8]... 5 Figura 2 Hierarquia Funcional do IED segundo a norma IEC [9]... 6 Figura 3- Estrutura interna genérica de um nó lógico segundo a norma IEC [1, Figura 3] 7 Figura 4 - Constituição da classe Common Logical Node segundo a norma IEC [3, capítulo 5.3.3]... 8 Figura 5- Constituição da classe PTOC segundo a norma IEC [3, capítulo ]... 8 Figura 6- Constituição da classe Logical Node segundo a norma IEC [2, Tabela 15] Figura 7- Interface de comunicação de ficheiros SCL entre ferramentas de engenharia Figura 8- Definição de SGCB segundo a norma IEC [2, Figura 17] Figura 9 Constituição da classe SGCB segundo a norma IEC [2, Tabela 22] Figura 10 - Comunicação vertical e horizontal no SPCC [10] Figura 11 Diagrama funcional da comunicação de ficheiros SCL entre ferramentas de engenharia Figura 12- Esquema Unifilar da Subestação 60/30 KV [6] Figura 13- Arquitectura e Organização Funcional do SPCC [7] Figura 14 Estruturas previstas para o desenho do esquema unifilar da subestação no Helinks STS Figura 15 Equipamentos previstos para o desenho do esquema unifilar da subestação no Helinks STS Figura 16 Esquema unifilar da subestação no Helinks STS Figura 17 Lista das áreas funcionais de Logical Nodes considerados no Helinks STS Figura 18 - Bay representativa do painel de chegada de AT no Helinks STS Figura 19 IED s associados à descrição de uma subestação no Helinks STS Figura 20 Correspondência entre os nós lógicos previstos e os disponibilizados pelos IED s (Helinks STS) Figura 21 Associação de IED s a uma subestação no Visual SCL Figura 22 Estrutura hierárquica dos Data Type Templates no Visual SCL Figura 23 Associação de Lnode Types no Visual SCL Figura 24 Comparação entre ficheiros no Visual SCL (lado esquerdo: Efacec, lado direito: Siemens) Figura 25 Comparação entre ficheiros no Visual SCL (lado esquerdo: Efacec, lado direito: Siemens) Figura 26 1ª Diferença de sintaxe entre Visual SCL e DIGSI Figura 27-2ª Diferença de sintaxe entre Visual SCL e DIGSI Figura 28 IED s considerados dentro da descrição de uma subestação no DIGSI Figura 29 Estrutura interna da instância de RCB do IED2_lab no DIGSI Figura 30 - Estrutura interna da instância de RCB do IED_0010 no DIGSI Figura 31 - IED s associados à descrição de uma subestação no Helinks STS Figura 32 - Estrutura interna do IED2_lab no Helinks STS Figura 33 - Estrutura interna do IED_0010 no Helinks STS Figura 34 - Estrutura interna do IED2_lab no Helinks STS Figura 35 - Estrutura interna do IED_0010 no Helinks STS Figura 36 Aplicação DIGSI system configurator para a descrição de uma subestação Figura 37 Associação de atributos a um DataSet no Helinks STS Figura 38 Estrutura interna do IED2_lab no Helinks STS (lado esquerdo: original; lado direito: final) Figura 39 - Estrutura interna do IED_0010 no Helinks STS (lado esquerdo: original; lado direito: final) Figura 40 Estrutura interna da instância de RCB do IED2_lab no Helinks STS Figura 41 - Estrutura interna da instância de RCB do IED_0010 no Helinks STS 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 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 Figura 46 IED s considerados dentro da descrição de uma subestação no DIGSI Figura 47 - Menu de activação das funcionalidades disponíveis num determinado IED através do DIGSI vii

9 Figura 48 - Menu principal de configuração de um IED específico no DIGSI Figura 49 - Estrutura interna do IED_0010 no Helinks STS Figura 50 Estrutura interna da instância de SGCB do IED_0010 no Helinks STS Figura 51 - Estrutura interna da instância de SGCB do IED_0010 no Helinks STS Figura 52 Visualização de um ficheiro SCD no XML Copy Editor Figura 53 Estrutura interna do IED_0010 no XML Copy Editor Figura 54 Diagrama funcional do Conversor SCL Figura 55 Esquema das ramificações a implementar no modelo de um IED genérico Figura 56 Fluxograma do Conversor SCL Figura 57 IED s considerados dentro da descrição de uma subestação no Helinks STS Figura 58 Estrutura interna do IED_0010 no Helinks STS Figura 59 IED s considerados dentro da descrição de uma subestação no Helinks STS Figura 60 Estrutura interna do IED_generico no Helinks STS Figura 61 - Estrutura interna da instância de RCB do IED2_lab no Helinks STS Figura 62 Interface de comunicação com o utilizador do Conversor SCL Figura 63 IED s considerados dentro da descrição de uma subestação no Helinks STS Figura 64 Estrutura interna do IED2_lab no Helinks STS Figura 65 - Relatório da importação de um ficheiro SCD para o DIGSI Figura 66 - Relatório da importação de um ficheiro SCD do DIGSI Figura 67 IED s considerados dentro da descrição de uma subestação no DIGSI Figura 68 - Estrutura interna da instância de RCB do IED_0010 no DIGSI Figura 69 - Estrutura interna da instância de RCB do IED2_lab no DIGSI Figura 70 DIGSI manager Figura 71 IED s considerados dentro da descrição de uma subestação no DIGSI Figura 72 Relatório da exportação de um ficheiro SCD do DIGSI Figura 73 Propriedades do ficheiro IEC station Figura 74 - Relatório da importação de um ficheiro SCD do DIGSI Figura 75 Visualização de um ficheiro SCL no Visual SCL Figura 76 Propriedades do ficheiro IEC station Figura 77 Relatório da importação de um ficheiro SCD para o DIGSI Figura 78 Erros do relatório de importação de um ficheiro SCD para o DIGSI Figura 79 Visualização de um ficheiro SCD no XML Copy Editor Figura 80 Comparação entre ficheiros no editor de código XML (lado esquerdo: DIGSI; lado direito: Visual SCL) Figura 81 Relatório de importação de um ficheiro SCD para o DIGSI Figura 82 - Visualização da organização dos IED s considerados num ficheiro SCL no Helinks STS Figura 83 - Relatório de importação de um ficheiro SCD para o DIGSI Figura 84 Aspecto do código fonte do Conversor SCL viii

10 Lista de Tabelas Tabela 1- Correspondência entre funcionalidades do SPCC (Painel de Linha AT) e classes de nós lógicos Tabela 2 Correspondência entre os nomes dos IED s e respectivos fabricantes Tabela 3 Simbologia seguida pelo Helinks STS Tabela 4 - Correspondência entre os nomes dos IED s e respectivos fabricantes 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 Tabela 7 - Correspondência entre funcionalidades do SPCC (Painéis de AT) e classes de nós lógicos ix

11 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 x

12 1 Introdução 1.1 Enquadramento O advento da norma de comunicações IEC (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 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 interoperabilidade, permite evitar que avalanches de informação recaiam unicamente sobre as entidades responsá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 engenharia e manutenção. As vantagens da aplicação da norma também se situam ao nível dos processos 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 manipular todos estes dados. Desta forma, conclui-se que a eventual aplicação da norma IEC às subestações de energia eléctrica nacionais trará benefícios operacionais e financeiros, o que promove 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 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, tornando 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 presente documento centrou a sua abordagem. 1

13 1.2 Objectivos O presente documento contempla uma breve descrição dos objectivos da norma IEC e da linguagem SCL (Substation Configuration Language), e de como ambos os conceitos devem ser trabalhados 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 no Projecto-Tipo foram executados extensos procedimentos 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, proporcionando a elaboração de ensaios experimentais no sentido de testar a comunicação entre as ferramentas 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 interessante 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 especificidades da norma IEC 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, 2

14 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 Mais especificamente, a análise do documento recaiu sobre o SPCC. É ainda apresentado um exemplo da configuraçã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 pormenorizadamente 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 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. 3

15 2 Norma IEC A norma IEC 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 interoperabilidade 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 diferentes, trocarem dados com vista a uma cooperação entre aparelhos dentro da subestação. A norma IEC apresenta-se ao mercado dos fabricantes de protecções como uma inevitabilidade 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 ainda não está complemente assegurada, visto que os equipamentos e softwares IEC 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 é 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 funcionamento de uma subestação podem estar alocadas num IED específico ou distribuídas pelos diversos 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 4

16 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 revestese 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 o define. Como se pode reparar o modelo apresenta uma estrutura hierárquica onde se vão consecutivamente 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 funcionalidades possíveis de implementar pelo IED. Figura 1 - Modelo do IED segundo a norma IEC [8] A figura anterior pretende apenas dar uma visão conceptual da estrutura de um IED. Embora conceptualmente seja fácil percepcionar o modelo do IED, a extensa quantidade de funcionalidades previstas pelos fabricantes para estes dispositivos requer uma estrutura mais cuidada onde sejam devidamente acautelados todos os dados indispensáveis para uma correcta aplicação prática da norma IEC

17 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 [9] O grande número de nós lógicos que podem ser incluídos dentro de um determinado LD pode rapidamente 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 analisadas 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. 6

18 o Por exemplo: PTOC, PTUV, PTOV, etc. Settings: Os DO s são utilizados para modelizar individualmente os settings de um determinado 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 [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 [1, Figura 3] Todas as classes de nós lógicos previstas pela norma IEC são especializações efectuadas sobre a classe Common Logical Node, que se encontra descrita na Figura 4. 7

19 Figura 4 - Constituição da classe Common Logical Node segundo a norma IEC [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 Corrente). 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 [3, capítulo ] 8

20 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 (Setting 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 configuração da subestação. Na Common Logical Node class (Figura 4) é importante notar que não foram apenas definidos atributos, estando também presentes na estrutura algumas secções adicionais, tais como Data Sets, Control Blocks e Services. Segundo a Parte 7-2 da norma IEC [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 9

21 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 horizontal. 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 [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 10

22 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 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. 11

23 A norma IEC 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 configurado. Na Figura 7 encontra-se descrito o método básico de interacção entre os ficheiros SCL e as ferramentas de engenharia. Ferramenta de configuração de IEDs Ferramenta de configuração de sistema Ferramenta de configuração de IEDs 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. 12

24 2.6 Control Block s (CB s) A norma IEC 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 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 [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. 13

25 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 [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 Report Control Block (RCB) Na norma IEC é 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, 14

26 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. 15

27 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 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 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 [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. Ferramenta de configuração de IEDs ICD Ferramenta de configuração de sistema SCD Figura 11 Diagrama funcional da comunicação de ficheiros SCL entre ferramentas de engenharia 16

28 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 o o Visual SCL (fabricante: ASE) Helinks STS (fabricante: Helinks LLC) DIGSI (fabricante: Siemens) As ferramentas de configuração de IED s utilizadas durante as fases de teste foram as seguintes: o o WinSettings (fabricante: Efacec) 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 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 17

29 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 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

30 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 o o Construção Civil Equipamentos 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. 19

31 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 o o o Funções de comando; Funções de protecção; Funções de automatismo; 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; 20

32 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 o o PCL (Posto de Comando Local); CC (Centro de Condução); CER (Centro de Engenharia Remoto); Figura 13- Arquitectura e Organização Funcional do SPCC [7] 21

33 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 o o o 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; Linha AT assegura a ligação entre o barramento AT e a respectiva linha de distribuição de AT; 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; Potencial de Barras AT assegura a ligação entre o barramento AT e os transformadores de medida de tensão do barramento; Interbarras AT assegura a ligação de dois barramentos entre si; Painéis MT o o 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; Linha MT Assegura a ligação entre o barramento do quadro metálico e a respectiva linha de distribuição de MT; Bateria de Condensadores Assegura a ligação entre o barramento do quadro metálico e a bateria de condensadores de MT; 22

34 o o o 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; 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; Interbarras MT Assegura a ligação de dois barramentos entre si; 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; 23

35 Funções Regulação automática de tensão; Comando automático de bateria de condensadores; 3.4 Compatibilização com a norma IEC 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 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 é 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 ou na IEC Correspondência entre funções do SPCC e nós lógicos Na parte 7-4 da norma IEC [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 [11]. Painéis de AT Linha de AT Distância Diferencial de linha /cabo (opcional) Máximo de Intensidade de Fase Máximo de Intensidade Homopolar Direccional Máximo de Intensidade Homopolar de Terras Resistentes Power Swing Detection Classes de nós lógicos PDIS PDIF PIOC, PTOC PIOC, PTOC PIOC, PTOC RPSB 24

36 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 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) 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 não exige a elaboração do desenho do esquema 25

37 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). 26

38 Figura 16 Esquema unifilar da subestação no Helinks STS 27

39 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 [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, é 28

40 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 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. 29

41 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 Associação dos IED s aos painéis que estes vão proteger na subestação Na secção 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 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

42 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. 31

43 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 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 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 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. 32

44 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 33

45 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. 34

46 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) 35

47 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 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). 36

48 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 ª 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 37

49 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 ª 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 ª 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. 38

50 ª 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 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). 39

51 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 ª 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 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. 40

52 4.3.22ª Fase - Leitura e Salvaguarda do ficheiro SCD no Helinks STS Como se demonstrou na secção 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 41

53 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 Procedimentos 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. 42

54 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

55 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 44

56 Figura 33 - Estrutura interna do IED_0010 no Helinks STS º 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. 45

57 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 46

58 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. 47

59 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 º 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 48

60 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 à 49

61 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 50

62 o o o PTUV.Op XCBR.Pos 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 51

63 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 52

64 4.5 Setting Group Control Block Embora a norma IEC 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 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 Procedimentos 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). 53

65 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 54

66 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) º 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 55

67 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 56

68 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 º 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. 57

69 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 58

70 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 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 ser ligeiramente distinta entre os diversos fabricantes. A solução permitida pela norma IEC 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 59

71 subestação totalmente reutilizável, recorrendo para tal, a um algoritmo programado de modo a operar as configurações da norma IEC com base num procedimento único Objectivos A solução adoptada para automatizar todas as configurações de serviços relacionados com a norma IEC 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. 60

72 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 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 61

73 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 62

74 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 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 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. IED_generico AP1 IED Acess Point Server LD_generico Logical Device LN0 Lnodes DataSet1 Data Set Report Control FCDA 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

75 Ficheiro SCD Percorre o ficheiro.scd à procura de um IED genérico Caso encontre Caso não encontre Operador quer trocar o IED genérico por um de um fabricante Não Não efectua nenhuma alteração sobre o ficheiro Sim Recolhe dados do IED genérico Pergunta ao operador qual o nome que deseja dar ao IED e qual o seu serial number Substitui a estrutura do IED genérico pela do fabricante e insere os dados pedidos ao utilizador Ficheiro SCD Verifica se o IED genérico tem DataSet s e RCB s Não tem Actualiza o ficheiro.scd inicial Tem Do template do IED do fabicante recolhe todos os Lnodes disponibilizados e respectivos atributos internos Não IED do fabricante tem Lnodes e atributos descritos no DataSet do IED genérico Não Avisa o operador que não existem disponiveis no IED todos os dados Operador deseja continuar a conversão dos restantes Sim Adiciona ao template do IED os DataSet e RCB, de acordo com o modelo desse fabricante Sim Figura 56 Fluxograma do Conversor SCL 64

76 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 65

77 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 ª 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 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 66

78 Figura 58 Estrutura interna do IED_0010 no Helinks STS ª 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. 67

79 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 68

80 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 ª 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 69

81 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, 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 ª 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 70

82 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. 71

83 ª 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 72

84 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 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 um RCB com os seguintes atributos: XCBR.Pos XCBR.BlkOpn RREC.BlkRec 73

85 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 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. 74

86 5 Conclusões 5.1 Conclusões Principais O advento da norma IEC 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 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. 75

87 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 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. 76

88 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 IEC

89 6 Referências Bibliográficas [1] IEC TC 57, IEC : 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 : 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 : 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 : Communication Networks and Systems in Substations, Part 5: Communication requirements for functions and device models [5] IEC TC 57, IEC : 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 [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 78

90 Funções Anexos 1. Correspondência entre funções do SPCC e nós lógicos Painéis de MT Classes de nós lógicos 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 79

91 Funções Painéis de AT Classes de nós lógicos 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 80

92 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 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. 81

93 Figura 72 Relatório da exportação de um ficheiro SCD do DIGSI Figura 73 Propriedades do ficheiro IEC 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 82

94 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. 83

95 Figura 76 Propriedades do ficheiro IEC 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 84

96 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. 85

97 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, 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 86

98 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 87

99 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 ª 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. 88

100 Figura 83 - Relatório de importação de um ficheiro SCD para o DIGSI 89

101 4. Aspecto do código fonte do Conversor SCL Figura 84 Aspecto do código fonte do Conversor SCL 90