Redes IEC-61850 – Estudo de Protocolo e Exemplo de Aplicação (Parte I)

Oii pessoal, tudo bem com vocês?

O artigo de hoje vai falar sobre Redes IEC-61850. Este artigo é de autoria do Tecnólogo em Automação Industrial Eduardo Leopoldo da Silva, projetista de software na WEG Automação, e será dividido em duas partes. Na primeira, será feita uma introdução sobre o assunto e em seguida será explicada a norma IEC-61850. Já na segunda parte, será falado sobre DNP-3 x IEC-61850, será dado um exemplo de aplicação e, por fim, a conclusão.

Então… vamos lá!

Resumo: Este artigo visa apresentar um estudo sobre uma tecnologia de redes de comunicação de vanguarda que vem simplificando, aumentando a confiabilidade e a economia dos sistemas de proteção em geral. Além disso, esse protocolo está permitindo uma interoperabilidade entre IEDs (do inglês Inteligent Electronic Devices) de diferentes fabricantes como jamais foi visto, permitindo que esses equipamentos troquem informações entre si, sem a necessidade de conversores de protocolos ou ligações físicas que aumentam em muito as despesas com cabeamentos e projetos.

Palavras-chave: IEC-61850, Redes, IEDs, Supervisórios, Subestações.

 

1 INTRODUÇÃO

Para que dois IEDs diferentes troquem informação entre si, faz-se necessário o emprego do que chamamos “Protocolo de Comunicação”. O protocolo de comunicação é o conjunto de regras estabelecido e seguido pelos dispositivos inteligentes que determina o tipo de mensagens e a ordem que as mesmas devem seguir. Esse conjunto de regras permite que equipamentos de diferentes fabricantes e com arquiteturas internas distintas passem a trocar informações importantes para o correto funcionamento e monitoramento do sistema como um todo (VAZQUEZ, 2007). Antigamente (até 1995), como não havia um conjunto de regras claras para definição dos protocolos de rede, cada fabricante adotava um protocolo específico, tornando o seu equipamento “incomunicável”, dificultando a troca de informações entre IEDs. Então eram empregados equipamentos chamados de conversores de protocolo, ou então, nos piores casos, essa troca de informação ocorria fisicamente, via cabo de cobre. Lacerda comenta que essa utilização de gateways acabou se tornando inviável quando se fala em sistemas que dependem de atuações imediatas, na casa de ms (milissegundos), como ocorre nas subestações, uma vez que esses equipamentos provocam um atraso na rede de comunicação. Com isso podem ocorrer atuações indevidas e alarmes fora do tempo real, podendo até provocar problemas no fornecimento de energia.

Devido a esse panorama, surgiu a necessidade de se estabelecer um padrão aos diferentes tipos de protocolos que integravam cada um dos diferentes IEDs que formavam uma subestação. Na década de 90, o EPRI (do inglês Electric Power Research Institute) deu início a um protocolo denominado UCA (Utility Communications Architecture). Esse protocolo já visava uma interoperabilidade entre os protocolos de rede existentes e foi muito utilizado até o fim da década passada. A partir de 1995 a IEC (International Eletrotechnical Commision) reconheceu que era necessário definir normas para os diferentes IEDs existentes no mercado. Então, com a fusão dos grupos de trabalhos EG10, WG11 e WG12 foi fundado o Comitê Técnico TC57 da IEC (composto por mais de 60 membros em vários países), já que tanto a IEC quanto a EPRI buscavam o mesmo objetivo. Por fim, em 2004 teve origem o padrão internacional de Redes de Comunicação em Sistemas e Subestações IEC-61850.

 

2 A NORMA IEC-61850

Esta norma é dividida em 10 partes principais (Figura 1), sendo que cada uma das partes representa um documento que regulamenta o uso do protocolo.

 

Segundo Gurjão, a IEC-61850 é um modelo de dados padronizado totalmente focado nos conceitos de orientação a objetos. Para isso, emprega funções e atributos de dispositivos físicos (IEDs) encontrados em uma subestação ou usina. As funções e suas respectivas instâncias formam o que se chama de “Nó Lógico”, sendo que um conjunto de “nós lógicos” forma um “dispositivo lógico”, que por sua vez reside internamente em um IED. A figura 2 exemplifica essa arquitetura.

 

Exemplificando, pode-se citar o caminho para encontrar uma variável analógica. Neste caso utilizaremos a frequência. Acessando-se o dispositivo físico (ou IED) através do seu endereço de rede, temos acesso em princípio ao “Dispositivo Lógico”. Este, uma vez acessado disponibiliza a localização de vários tipos de “Logical Devices”, que podem ser proteções, comandos, retornos digitais, configurações do próprio IED e o que nos interessa nesse exemplo, que são os tags analógicos (MET). Em seu interior estão os “Nós Lógicos”. O nó a ser utilizado será o MMXU. Ali é possível visualizar cada uma das classes que compõe o referido “nó lógico”, para em seguida, encontrar o dado que se está procurando. Na Figura 3, é possível perceber de forma mais clara como essa arquitetura é ilustrada, utilizando-se o caractere “$” como separador de camadas.

 

A norma classifica o tipo de mensagens a ser trocadas entre os dispositivos que compõem a rede conforme a importância dessas mensagens para a rede. No quadro 1 é possível verificar qual a importância dada a cada uma das mensagens que trafegam pela rede.

 

a. Protocolo MMS

São mensagens do tipo unicast, enviadas a um consumidor apenas e que em geral pode ser um supervisório, um cartão IEC-61850 ou, como veremos mais a frente, a um conversor de protocolo (Relab). As mensagens MMS (Manufacturing Message Specification) são utilizadas para troca de informações como sinais analógicos ou digitais, porém, com o único intuito de indicar o status de um determinado equipamento. Como esse protocolo emprega o modelo TCP, ele acaba não se tornando rápido o suficiente para identificar a atuação de uma proteção, por exemplo, pois sua concepção emprega um mecanismo de tratamento de erros. Na tabela da figura 4, encontram-se no tipo 2, 3 e 5 quando configurado para ler através de exceção (reports), ou seja, o valor do tag altera apenas quando há uma mudança superior ao valor de banda-morta programado. Já quando a comunicação é feita pelo modo pooling, os valores são capturados pelo mestre de tempos em tempos, aumentando assim consideravelmente o tráfego de informações na rede. Dessa forma as mensagens passam a pertencer ao tipo 4 da tabela.

b. Protocolo GOOSE

Ao contrário das mensagens MMS, as mensagens GOOSE (Generic Object Oriented Substation Event) são mensagens do tipo multicast que carregam informações entre os IEDs. São responsáveis apenas pelo tráfego de mensagens que informam sobre a atuação de qualquer proteção ou sinal digital. Tais mensagens conseguem ser mais rápidas do que a própria atuação física de uma proteção de um relé para outro. Tudo isso por empregarem em sua concepção o padrão UDP, ou seja, não faz a verificação para saber se houve erro na transmissão da mensagem. Dessa maneira, mesmo que um pacote de dado seja perdido, outro pacote idêntico ao que foi perdido já foi enviado novamente até que uma confirmação de recebimento seja recebida, garantindo assim o recebimento da mensagem. Para evitar colisões, a cada novo pacote enviado dobra-se o tempo de espera pela confirmação até que o tempo máximo de espera (Time Allowed to Live) seja atingido. Caso essa confirmação não chegue após o tempo programado, o IED entende que a conexão foi encerrada e o outro dispositivo encontra-se off-line. Na tabela da figura 4, compreende os tags localizados nos tipos 1 e 1A.

c. Protocolo SV

O protoloco SV (Sampled Variables) é responsável pelo tráfego das leituras analógicas da subestação. Através desse protocolo, TPs e TCs conseguem enviar suas medições para os relés através de leituras digitais pela própria rede ethernet. Os relés, por sua vez, com um conversor AD incorporado, tratam esse dado e o utilizam em suas proteções. Por esse motivo, pertencem ao tipo 1 da tabela da figura 4.

d. SCL (Substation Configuration Language)

Este aspecto da norma estabeleceu um padrão para o formato dos arquivos de configuração de subestações. Do inglês Substation Configuration Language, foi baseado na estrutura XML (eXtensible Markup Language) e criou uma padronização que permitiu o compartilhamento de informações entre equipamentos e ferramentas de software de engenharia. Com isso, cada fabricante possui um arquivo .SCL que deve ser fornecido junto com o equipamento, assim como acontece em outras redes industriais (Profibus e Devicenet). Há 4 diferentes tipos de arquivos aceitos pela norma:

• SSD (System Specification Description) – descreve as funções de energização do sistema, contendo o diagrama unifilar com as funções de cada relé;
• SCD (Substation Configuration Description) – determina onde os dados se encontram e para onde devem ir, ou seja, a configuração da subestação;
• ICD (IED Capability Description) – determina quais os dados disponíveis em cada IED;
• CID (Configured IED Description) – determina as informações que o IED irá disponibilizar na rede.

e. GATEWAY IEC-61850

Para realização do link entre o sistema supervisório e o relé de proteção foi utilizado o software Relab OPC Console como gateway. Esse software converte o protocolo IEC-61850 lido do relé através da rede ethernet em OPC (Ole for Process Control). OPC é um protocolo de comunicação de redes industriais que emula um driver, permitindo que o sistema supervisório consiga se comunicar com qualquer equipamento, sem possuir um driver de comunicação específico. Dentro do Relab, é possível visualizar toda a estrutura IEC montada dentro do relé. Dessa maneira, basta ao programador selecionar os tags que serão utilizados na comunicação com o sistema supervisório, conforme foi feito na Figura 4.

Na figura acima, é possível encontrar o relé em questão (chamado neste caso de PMCC_16_1A) e toda a estrutura que há dentro dele. As primeiras variáveis são as variáveis de status do mesmo, onde é possível verificar se o relé está comunicando e o status da comunicação, a quantidade de mensagens recebidas e enviadas, os últimos erros detectados na comunicação entre outros. Logo abaixo, existem 5 pastas:

• ANN – neste local podemos encontrar status digitais como os leds frontais do relé, valor das entradas e saídas digitais, valor das memórias internas e outros parâmetros programados em função do estudo de seletividade do mesmo.
• CFG – nesta pasta encontram-se as configurações dos “reports” que serão utilizados e também tags com informações de Proxy e do ID do relé;
• CON – aqui ficam os tags utilizados como comandos para o relé, chamados de “Remote Bits”, além dos seus respectivos status;
• MET – nesta pasta encontram-se todas as medições analógicas feitas pelo relé. Nela é possível encontrar grandezas elétricas como corrente, tensão, frequência, fator de potência, energia (ativa e reativa) e em alguns relés até mesmo temperaturas;
• PRO – por fim, é nesta pasta que ficam os tags responsáveis pelas indicações de atuação das proteções do relé. Aqui, para correta interpretação de qualquer proteção, é importante consultar o manual do fabricante do relé. Nele deve conter a descrição completa de cada uma das proteções disponíveis para serem lidas no sistema supervisório.

Em certos momentos, devido a atuação muito rápida de uma determinada proteção e ao tempo de scan do sistema supervisório (cerca de 500 ms enquanto que a atuação da proteção se dá na casa de us), faz-se necessário utilizar o que comumente é chamado de offdelay. Para que isso ocorra, o programador do relé deve dizer que uma determinada proteção deverá atuar uma área interna chamada SV (SELogic Variable). Então, ao invés do sistema supervisório ler a proteção diretamente da pasta PRO, é preciso que seja acessada a pasta ANN e uma das subpastas SVGGIO3 ou SVTGGIO4. No exemplo da figura acima, na aba “OPC Server Adress Space” é possível verificar o relé, a pasta ANN aberta e dentro da mesma a pasta TLEDGGIO6. Dentro dessa pasta, encontram-se todos os tags que representam cada um dos leds frontais que o relé possui.

Referências Bibliográficas:

• http://www.energy.siemens.com/hq/pool/hq/energy-topics/standards/iec-61850/IEC61850_e.pdf. Acessado em 06/07/2012.
• http://www.ceb5.cepel.br/arquivos/artigos_e_documentos/artigos_bienal_2004/b5_110.pdf. Acessado em 06/07/2012.
• http://www.ceb5.cepel.br/arquivos/artigos_e_documentos/artigos_bienal_2004/b5_103.pdf. Acessado em 06/07/2012.
• IEC 61850 Communication Networks and Systems in Substation. http://www.61850.com. Acessado em 23/06/2012.
• LACERDA, Sérgio Louredo Maia & CARNEIRO, Greyce Hayana Ribeiro. Dispositivos Eletrônicos Inteligentes (IEDs) e a Norma IEC-61850: União que Está Dando Certo. João Pessoa – PB. 2008
• NOGUEIRA, Bruno Vazquez. Protocolo de Comunicação IEC-61850. Salvador – BA. 2007.
• GURJÃO E.C., SOUZA B.A. e CARMO U.A.. Aspectos de Comunicação da Norma IEC-61850. João Pessoa – PB. 2007

Bom pessoal…por hoje é isso. A continuação do artigo será publicada na próxima semana.

Gostaria de aproveitar para agradecer ao autor deste artigo, o Tecnólogo em Automação Industrial Eduardo Leopoldo da Silva, por ter cedido seu artigo para publicação no blog Automação Industrial. Este material está ajudando a enriquecer o conteúdo de temas publicados e com certeza será de grande utilidade para nossos amigos que acompanham o blog.