(*) Av. Joaquim Porto Villanova, n˚ 201 – Prédio E2A – Sala 102 – CEP 91.410-400 Porto Alegre, RS – Brasil Tel: (+55 51) 3382-4455 – Email: robertos@ceee.com.br
XXI SNPTEE SEMINÁRIO NACIONAL DE PRODUÇÃO E TRANSMISSÃO DE ENERGIA ELÉTRICA Versão 1.0 23 a 26 de Outubro de 2011 Florianópolis - SC GRUPO - V
GRUPO DE ESTUDO PROTEÇÃO, MEDIÇÃO, CONTROLE E AUTOMAÇÃO EM SIST. DE POTÊNCIA (GPC)
IMPLEMENTAÇÃO DO PROTOCOLO IEC61850 NO COSD DA CEEE-D PARA TELECONTROLE DIRETO DE IED’S
Roberto Schönhofen Ribeiro(*) José Aurélio Sá Brito Porto Carlos Frederico Maciel Silveira CEEE-D Spin Engenharia Spin Engenharia
RESUMO
Este informe técnico apresenta o desenvolvimento e aplicação do software MMS cliente, conforme previsto na norma IEC 61850, para a comunicação vertical. O centro de operação da CEEE-D empregou uma arquitetura onde os concentradores de comunicação foram eliminados, e o software cliente recebe todas as informações e envia comandos diretamente aos IED’s, distribuídos nas diversas subestações. Também é mostrado aqui o emprego da funcionalidade de “reporting”, previsto na parte 7 da norma, como uma ferramenta muito versátil e eficaz para o recebimento de eventos analógicos e digitais, e os benefícios obtidos de uma correta aplicação.
PALAVRAS-CHAVE
IEC 61850, Telecontrole, Operação, TCP/IP, Report. 1.0 - INTRODUÇÃO
A área de automação da CEEE-D escolheu como característica principal para a arquitetura de comunicação de seu centro de operação (COSD), a troca direta de informação entre o SCADA e os IED’s (Intelligent Electronic Devices) presentes nas diversas subestações, sem a utilização de concentradores ou “gateways” de protocolos. Esta escolha decorreu das facilidades trazidas pelo protocolo TCP/IP (Transport Control Protocol / Internet Protocol) e a infra-estrutura de meios de comunicação digitais existentes nos dias de hoje.
Antes do advento da norma IEC 61850, já estavam em operação várias subestações utilizando esta arquitetura, empregando “terminal servers” com protocolos seriais encapsulados em TCP/IP. O COSD conectava-se diretamente com cada um dos IED’s, através de centenas canais de comunicação configurados no software SCADA. Mais recentemente, a CEEE-D padronizou, para as novas subestações, a utilização de sistemas que empregam a norma IEC 61850. Esta decisão se baseou no aumento da oferta comercial e queda de preços dos IED’s compatíveis.
A parte 7 da norma especifica a funcionalidade de “reporting”, que possui diversas potencialidades para a aquisição de dados analógicos e digitais pelo centro de operação, lado cliente. Para obter o melhor desempenho desta ferramenta alguns cuidados devem ser dispensados durante sua instalação.
2.0 - ORIGEM DA ARQUITETURA DO SISTEMA
A arquitetura original empregada nas subestações que utilizam protocolos seriais, tais como IEC 60870 e DNP 3.0, era composta por unidades terminais remotas ou concentradores de comunicação. Estes equipamentos, devido a sua complexidade, apenas inseriam mais um ponto de falha no sistema de comunicação com o centro de operação.
A partir do ano de 2004 a área de automação da CEEE-D iniciou a substituição gradual destes concentradores de comunicação por “terminal servers” viabilizando a aquisição de dados e envio de comandos diretamente aos IED’s localizados nas subestações. Imediatamente foi verificada a melhoria de desempenho do sistema quanto à velocidade de resposta e a confiabilidade, posto que o “terminal server” não possui a necessidade de programação e seu hardware é suficientemente robusto.
O desempenho do hardware e do software empregado no centro de operação não sofreu qualquer impacto, quanto à utilização de recursos como processamento, memória ou rede, frente ao grande número de conexões TCP/IP – uma para cada IED – em comparação com o sistema então em operação que possuía apenas uma conexão para cada subestação. A partir deste momento ficou evidente que a conexão direta em TCP/IP entre o centro de operação e cada IED é perfeitamente viável, necessitando apenas de um protocolo suficientemente padronizado para assumir o lugar dos protocolos seriais.
A norma IEC 61850 supriu a potencialidade proporcionada pelo sistema de comunicação, já então com grande capacidade de absorver inúmeras conexões com velocidades da ordem de dezenas de Megabits por segundo. Os IED’s compatíveis tornaram-se gradualmente bastante atrativos do ponto de vista de custo de aquisição e aplicação, conduzindo a uma escolha praticamente obrigatória.
3.0 - PRIMEIRA SUBESTAÇÃO UTILIZANDO A NORMA 3.1 Planejamento e Testes
O projeto elétrico da subestação Porto Alegre 3 já possui todas as facilidades proporcionadas pelo novo padrão. A fiação elétrica foi reduzida ao mínimo possível, sendo substituída por fibra óptica. Toda a troca de informação entre os diversos equipamentos é executada exclusivamente com o emprego de GOOSE (Generic Object Oriented Substation Event). Estas modificações redundaram em uma simplificação enorme para o projeto, inspeção e comissionamento de painéis de controle e proteção.
Para utilizar estas facilidades, era imperativo obter a certeza de que a troca de informação horizontal dentro da subestação fosse isenta de falhas ou incertezas de qualquer ordem. Testes exaustivos em laboratório foram executados simulando o ambiente da subestação. Disto resultou a constatação de que não existe falha de transmissão ou de recepção de dados, além de que a incerteza temporal é totalmente desprezível tomando-se como base de comparação os tempos envolvidos nos processos de proteção elétrica.
Durante os testes de desempenho horizontal, foi utilizado o cliente SISCO para verificar a conexão vertical, conexão esta a ser empregada num segundo momento no centro de operação. O desempenho dos testes mostrou-se satisfatório para a recepção de dados através de pergunta e resposta, bem como com a funcionalidade de “reporting”, prevista em norma (3). Os comandos simples e duplos também foram testados durante esta fase. 3.2 A Implentação da Primeira Subestação
A CEEE-D utiliza em seu centro de operação o sistema supervisório produzido pela Spin Engenharia de Automação, o software ActionView. De maneira a manter a arquitetura de comunicação pretendida, ou seja, o centro de operação conectado diretamente aos IED’s, um módulo de comunicação nativo deveria ser desenvolvido para suportar o protocolo vertical definido pela norma IEC 61850.
Para tal a CEEE-D contratou um projeto P&D ANNEL com o CDT-Unb (Centro de Desenvolvimento Tecnológico da Universidade de Brasília) para o desenvolvimento de um módulo de comunicação e ferramentas para a configuração da base de dados.
Durante este projeto foram feitos estudos da norma IEC61850 e do protocolo MMS (Manufacting Message Specification) baseado na norma ISO 9506-2 (8), utilizado preferencialmente para o mapeamento dos serviços e objetos do IEC 61850, para a camada de aplicação do protocolo. Também, como atividade do projeto, foram estudadas as bibliotecas fontes que implementam este protocolo e estão disponíveis comercialmente. Foi escolhida a biblioteca da TMW (Triangle Microworks – USA) (10) pela sua facilidade de utilização, documentação satisfatória, e serviços complementares de suporte.
A partir de exemplos disponíveis no pacote da biblioteca foi iniciado o desenvolvimento de aplicativos, arquivos do tipo “.dll”, compatíveis com o padrão da interface do ActionView. Inicialmente para a ferramenta “IEC 61850 Browser” que é empregada para mapear objetos de dados e a seguir para o módulo de comunicação em tempo real. A seguir, foram feitos testes de laboratório empregando os relés da Siemens, Areva, SEL e GE com o objetivo de aprimoramento do software, e confirmação da correta funcionalidade do sistema frente aos requisitos da norma. Após foi instalado um gateway provisório MMS / DNP3.0, empregando o software desenvolvido, como cliente IEC 61850 e servindo o centro de operação da CEEE-D em DNP 3.0. Esta etapa foi prevista com a intenção de não
alterar o supervisório que se encontrava em produção no centro de operação. Este “gateway” permitia telecomandar e receber estados e medições analógicas da SE Porto Alegre 3, servindo como base de teste para o aprimoramento do software. Durante esta fase foi melhorado o desempenho do software nas conexões TCP/IP, amostragem de dados, comandos e a manipulação de reports.
4.0 - DESENVOLVIMENTO E FUNCIONALIDADES DO SOFTWARE 4.1 Módulo de Configuração
Para o cadastramento de pontos existentes em um servidor IEC61850, papel desempenhado pelos IED’s, foi desenvolvido no projeto, o “IEC 61850 Browser”. Esta janela, visualizada no aplicativo de configuração de pontos, é constituída de dois quadros apresentados lado a lado, ver a Figura 1. No quadro da esquerda é apresentada uma lista hierárquica, em forma de árvore, com os dados do IED. No quadro da direita serão listados os objetos de dados pertencentes ao ramo selecionado. Estes nomes de objetos podem então ser transferidos para as tabelas de mapeamento que relaciona os pontos do supervisório com os objetos de dados dos IEDs.
FIGURA 1 – O “IEC 61850 Browser”
Os tipos de dados, definidos na norma, e disponíveis em um determinado IED podem ser tão simples como um objeto de dados que representa uma informação digital ou analógica, ou podem ser estruturas complexas como as que formam um “data set” ou um “control block”.
Os mapas de dados de cada IED pode ser obtido através de uma conexão em rede direta ou através da leitura de um dos tipos de arquivos suportados pela linguagem SCL (Substation Configuration Language) (1). Estes arquivos, que contem a especificação da configuração dos IEDs, em formato XML, podem ser do tipo:
- ICD (IED Capability Description);
- SCD (Substation Configuration Description); - CID (Configurated IED Description).
Para estabelecer uma comunicação direta, será necessário estabelecer uma conexão em TCP/IP entre o centro de operação e o IED que será lido, para tal apenas o endereço IP deverá ser informado. Alternativamente poderá ser utilizado um arquivo do tipo SCL para prover estes dados. A origem dos objetos de dados pode ser verificada na janela do “IEC61850 Browser” como mostrado na Figura 2.
Na árvore de dados, estão disponíveis os ramos com os “logical nodes”, “reports” (buffered e unbuffered) e os “data sets”, ver Figura 3. Um “data set” é um objeto que contém uma lista de nomes de objetos de dados. Os “data sets” são normalmente pré-configurados nos IEDs, durante sua parametrização. Além da configuração de objetos de dados, a janela IEC61850 Browser permite a configuração para o tratamento de “data sets”, “reports” e o ajuste de parâmetros de “control blocks”, empregados na definição do comportamento dos “reports”, por exemplo.
FIGURA 3 – “Logical Nodes”, “Reports” e “Data Sets” 4.2 Módulo de Comunicação de Tempo Real
O módulo de comunicação do sistema ActionView, implementa o modo cliente para comunicação com um IED, servidor do protocolo IEC 61850. A conexão em TCP/IP pode ser feita com múltiplos IEDs simultaneamente, em paralelo, sem acarretar qualquer prejuízo no desempenho do sistema por sobrecarga de recursos.
A leitura de objetos de dados pode ser executada de forma individual através de solicitação, retornando o valor do dado, a estampa de tempo e sua qualidade. Além disto, é possível a leitura de “data sets”, por solicitação, com a alternativa de ajuste de períodos de varredura diferenciados para diferentes conjuntos de dados.
O software pode ainda obter informações dos IED’s com o emprego da funcionalidade de “reporting”. “Reports” são ações de envio de dados não solicitados, iniciadas pelos IED’s servidores, em direção aos clientes que os subscreveram. Cada “report control block” possui em sua configuração atributos que definem a forma e comportamento do “reporting”, um deles é o nome do “data set” a ser enviado, por exemplo. Cada vez que ocorrer pelo menos uma variação de estado de um dos objetos de dados do “data set” associado, um novo “report” será enviado ao cliente.
O envio de comandos pelo software segue as estruturas de dados previstas em norma, e estão disponíveis para emprego os comandos simples, os comandos do tipo “selected before operate” (SOB), e os do tipo “selected before operate with value” (SBOw).
4.3 Emprego de Reports no COSD
O emprego da funcionalidade de “reporting” para a aquisição de dados pelo centro de operação trouxe uma série de vantagens que, se adequadamente aplicadas, podem resultar em economia de recursos, usualmente escassos, nos sistemas de controle e supervisão.
O “reporting” está especificado na parte 7-2 da norma IEC 61850. As estruturas de dados que constituem o controle de um “reporting”, e formatam seu comportamento quando ativos são chamados “control blocks”. Além do controle está especificado também o formato do “report” enviado ao cliente, cada vez que algum dado configurado no seu conjunto de dados (data set) sofre alteração no valor ou qualidade.
4.3.1 Economia na Utilização de Banda
O “reporting”, após ativo pelo cliente, consome pouca banda nos canais de comunicação, porque funciona de forma espontânea, enviando um “report” somente quando ocorre uma alteração no conjunto de dados a ele anexado. Desta forma, se corretamente configurado durante sua implementação em campo, a quantidade de pacotes enviados pelo servidor (IED) ao cliente (centro de operação) é minimizada, liberando o canal de comunicação para outros serviços. As grandezas digitais são, por natureza, bastante estáveis em uma subestação, gerando pouca carga de “reporting”. Por outro lado, as grandezas analógicas são por natureza muito dinâmicas, podendo levar a uma taxa de “reporting” excessivamente alta. Este aspecto deverá ser contornado com um ajuste correto, durante o
comisssionamento da SE, da banda morta de cada uma das variáveis analógicas anexadas ao “data set” associado. Deverá ser aplicada uma faixa maior de banda morta para as variáveis mais dinâmicas, e nas variáveis mais estáveis esta banda morta poderá ser reduzida.
Cada “report” enviado pelo servidor possui uma formatação segundo a especificação da norma. Durante a configuração do seu “control block”, poderão ser feitos ajustes que redundarão em diminuição do tamanho do pacote de dados remetido ao cliente, cada vez que um “report” é gerado. Desta forma poderemos, por exemplo, abstrair da estrutura de dados do “report” o nome de cada um dos objetos enviados através do “data set” associado. Podem também ser eliminados do pacote de dados de um “report” outros atributos, que se criteriosamente escolhidos, não prejudicam o correto entendimento por parte do cliente da funcionalidade associada a este “reporting”.
4.3.2 Inteligência Associada ao Processo de “Reporting”
O bloco de controle, conforme definido na norma, fornece ao integrador um conjunto de ferramentas para configuração de suas funcionalidades bastante extensa, permitindo o emprego de estratégias para a aquisição de eventos pelo cliente, de forma a garantir a correta recepção de dados.
A ativação de um determinado report é feita sempre que o canal de comunicação entre o cliente e o servidor estiver integro, garantindo a continuidade do serviço de “reporting” enquanto houver condições adequadas para a troca de dados. Com este esquema os eventos gerados na SE sempre terão a possibilidade de chegar instantaneamente ao centro de operação, a menos que o meio de comunicação não o permita.
Como o serviço de “reporting” funciona baseado em eventos, deverá ser prevista a consistência da base de dados de tempo real entre cliente e servidor em intervalos de tempo regulares, ou durante uma reinicialização do software. Para isto pode ser empregado a “Interrogação Geral” pelo lado cliente ou a “Integridade” pelo lado servidor. Estes esquemas geram um “report” com valores atuais de todas as variáveis “definidas no “data set”. O tempo previsto entre uma consistência e a próxima deverá ser longo o suficiente para não impactar na utilização do canal de comunicação.
Durante um evento de falha na comunicação entre o cliente e o servidor, todos os “reports” que não puderam ser imediatamente remetidos ao cliente ficarão guardados internamente no IED. Ao retornar o canal, o “reporting” é imediatamente reativado, tendo a oportunidade de enviar todos os “reports” guardados na memória de forma seqüencial, do mais antigo para o mais recente.
A capacidade de recuperação de valores analógicos e digitais com a estampa de tempo associada, após uma queda no canal de comunicação, permite a remontagem adequada dos valores guardados no centro de operação em histórico. A partir do momento em que os eventos memorizados no servidor sejam reenviados para o cliente, o software possui a capacidade de analisar a estampa de tempo e inserir o valor do dado recebido na posição adequada da base de dados de histórico de eventos e medidas, ver Figura 4. Com este esquema serão eliminados da base de histórico os valores, armazenados de forma estática erroneamente, durante um evento de falha na comunicação.
Caso a quantidade de eventos originados na SE seja muito grande, de forma que a capacidade do servidor de enviar “reports” em direção ao cliente não consiga vencer a quantidade de eventos que chegam ao seu “buffer”, então esta memória deverá ser apagada, evitando a sobrecarga permanente deste sistema, com a utilização inadequada de recursos computacionais do servidor e do canal de comunicação. Deverá ser imediatamente verificada dentro da SE a causa da quantidade excessiva de eventos. Normalmente esta área de memória não necessita de cuidado especial, ficando a cargo do software cliente as tratativas para que apenas as partes ainda não recebidas adequadamente dos “reports” memorizados no servidor sejam remetidas no evento de uma nova reativação.
5.0 - CONCLUSÃO
O software já está implantado no centro de operação da CEEE-D, tendo sido bastante testado em funcionamento operacional, comunicando diretamente com 44 IED’s na SE PAL3 da CEEE-D, permitindo a supervisão e telecomando desta subestação, que já está energizada a 1 ano, e com sua operação monitorada a partir do COSD a aproximadamente 10 meses.
Na arquitetura final, a comunicação direta do centro de operação com os IED’s possibilitou a eliminação de possíveis pontos de falha produzidos pela utilização de concentradores de comunicação, produzindo ganhos relevantes na confiabilidade, integridade e segurança dos dados, pontos cruciais, nos dias de hoje, para todo sistema de tecnologia de informação. Possibilitou ainda, o monitoramento mais completo, simplificado e rápido dos IED’s, pela leitura direta dos seus pontos configurados para telecontrole, estados e medição, utilizando esquemas previstos na norma, tais como ”reporting” e comandos. Tais esquemas, quando corretamente aplicados podem resultar em grande economia de recursos computacionais, aliado a benefícios operacionais.
Comparativamente aos protocolos antigos, o paradigma IEC 61850 apresentou uma diminuição da complexidade do arranjo físico e instalação dos painéis e canaletas das subestações, já que toda troca de informação agora se baseia em duas redes redundantes de fibras ópticas, em contraste com as várias redes e mídias anteriormente utilizadas. Indicativos mostraram um significativo ganho de velocidade de resposta do sistema como um todo, sem a necessidade de melhoria de qualquer espécie nos computadores empregados no COSD. Além disto, a linguagem SCL possibilitou ganho de tempo e mitigação dos erros de configuração da base de dados do sistema supervisório.
6.0 - REFERÊNCIAS BIBLIOGRÁFICAS
(1) IEC 61850-6 2004-03 - Communication networks and systems in substations Part 6: Configuration description language for communication in electrical substations related to IEDs.
(2) IEC 61850-7 2003-05 - Communication networks and systems in substations Part 7-1: Basic communication structure for substation and feeder equipment – Principles and models.
(3) IEC 61850-7 2003-5 - Communication networks and systems in substations Part 7-2: Basic communication structure for substation and feeder equipment – Abstract communication service interface (ACSI).
(4) IEC 61850-7 2003-5 - Communication networks and systems in substations Part 7-3: Basic communication structure for substation and feeder equipment – Common data classes.
(5) IEC 61850-7 2003-5- Communication networks and systems in substations Part 7-4: Basic communication structure for substation and feeder equipment – Compatible logical node classes and data classes.
(6) IEC 61850-8 2004-5 - Communication networks and systems in substations Part 8-1: Specific Communication Service Mapping (SCSM) – Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3.
(7) ISO 9506-1 / Second Edition 2003-07-01 – Industrial automation systems – Manufacturing Message Specification -Part 1: Service Definition.
(8) ISO 9506-2 / Second Edition 2003-07-01 – Industrial automation systems – Manufacturing Message Specification - Part 2: Protocol Specification.
(9) Spin Engenharia de Automação Ltda – Versão 8 - 00048 – 01 - Dez 2010 - ActionView – SpinGateway – Módulos e Protocolos de Comunicação – Manual de referência.
7.0 - DADOS BIOGRÁFICOS
Roberto Schönhofen Ribeiro
Nascido em Porto Alegre, RS no dia 06 de agosto de 1961.
Mestrado (2002) em Engenharia da Computação na UFRGS e graduado (1986) em Engenharia Elétrica ênfase Eletronica na PUC-RS.
Empresa: Companhia Estadual de Distribuição de Energia Elétrica. Atua como engenheiro eletricista na área de automação de subestações.
José Aurélio Sá Brito Pôrto
Nascido em Bento Gonçalves, RS no dia 05 de julho de 1951.
Mestrado (1977) em Ciências da Computação na UFRGS e graduado (1974) em Engenharia Mecânica na UFRGS. Empresa: Spin Engenharia de Automação Ltda.
Consultor em sistemas de supervisão e controle de processos, coordenador de desenvolvimento de software e sócio diretor técnico da Spin Engenharia.
Carlos Frederico Maciel Silveira
Nascido em São Luis, MA no dia 09 de novembro de 1982. Graduação (2006) Engenharia Mecatrônica na UNB. Empresa: Spin Engenharia de Automação Ltda.
