Sumário

Nome do Módulo: IEC 61850 Client Communication Protocol
Current Version: 9.2
Implementação DLL: T.ProtocolDriver.IEC61850.dll
Protocolo: IEC 61850 Edition 2
Interface: TCP/IP
Descrição: O Action.NET implementa a parte da norma IEC 61850 responsável pelo núcleo de servicos ACSI, como definido na seção 8-1 da referida norma. Utiliza encapsulsamento da camada de transporte ISO/OSI em camada de transporte TCP/IP. Realiza comunicação com IEDs (intelligent Eletronic Devices), RTUs(Remote Terminal Units) e IO devices compatíveis com este protocolo, atuando como estação Cliente.
Requisitos do Sistema: Uso do software Action.NET

Max number of nodes: user defined
Observação: Este módulo de comunicação foi re-escrito para a versão an-2016.2, passando a utilizar uma biblioteca diversa da anteriormente utilizada, tendo sido feitas também alterações nos procedimentos de configuração de canais, nodes e points. O item a seguir oferece notas para auxiliar na migração de projetos que já utilizavam o módulo da versão anterior.

Tag Providers e Canais de comunicação

Existem 2 maneiras independentes de usar este protocolo. Usando uma configuração TagProvider, ou como um Device-Channel.

TagProvider permite conectar-se diretamente com dados em dispositivos, sem criar tags locais, usando a definição de nome no dispositivo remoto.

Device-Channel permite mapear tags no projeto para endereços de dados externos, dando mais flexibilidade nas convenções de nomes e gerenciamento de blocos de dados.

Este documento contém informações específicas sobre a configuração do dispositivo em ambos os métodos. Para uma explicação genérica sobre TagProviders, ou sobre o Módulo de Dispositivo, Canais, Nós e Pontos, consulte o guia do usuário de referência.

Migração

Os usuários do Action.NET que utilizam o módulo de comunicação da edição 1, necessitam atualizar o cadastro de canais, nós e pontos do projeto. A migração deve ser feita seguindo os passos abaixo:

1. Copiar todos os pontos referentes à nós do Módulo de comunicação 61850 do projeto para uma planilha do Excel.

2. Apagar todos os pontos referentes à nós do Módulo de comunicação 61850 do projeto.

3. Copiar os nomes dos nós e canais do projeto para o bloco de notas.

4. Apagar todos os nós.

5. Apagar todos os canais.

6. Criar os canais com os nomes previamente copiados no passo 3. Configurando cada canal de acordo com a sessão 2 - CONFIGURAÇÃO DE CANAL

7. Criar os nós com os nomes previamente copiados no passo 3. Configurando cada nó de acordo com a sessão 3 - CONFIGURAÇÃO DE NÓS

8. Colar os pontos previamente copiados no passo 1.

9. Ao iniciar o Módulo de comunicação. Validações de cadastros serão realizadas. Caso ocorra incorreções em definições de pontos, elas serão registradas no Log (Ver sessão 7.1 - Registros de operações e verifique como corrigi-las na sessão 4 - CONFIGURAÇÃO DE PONTOS.

Norma IEC 61850

Esse tópico tem como objetivo apresentar de forma sucinta algumas informações da norma IEC 61850, que interferem diretamente na definição e implementação deste módulo de comunicação.
Para mais detalhes e uma descrição formal, refira-se aos textos da norma ou à documentação dos IEDs servidores.
A norma é composta por dez partes, listadas na tabela abaixo.

No que diz respeito ao suporte para a comunicação de dados, entre computadores e IEDs, padronizado pela norma, são definidos os tipos de Mensagem, listados na tabela abaixo.

Um dos grandes diferenciais vantajosos introduzidas pela norma, na definição de seu protocolo de comunicação de dados, é o fato de que os pontos internos a um IED não são endereçados por números, como em outros protocolos, mas são considerados "objetos" e endereçados por nomes que são padronizados pela norma.
Internamente aos IEDs IEC61850 existe um mapa dos objetos, arranjados em uma estrutura hierárquica. Na comunicação entre um cliente (por exemplo, o Action.NET) e o servidor (por exemplo um Relé digital-IED) trafegam nas mensagens do protocolo estes nomes de objetos (pelo menos no estabelecimento inicial da comunicação).
Para se ter uma ideia geral sobre estes nomes de objetos apresenta-se aqui, de modo sucinto, a estrutura da hierarquia dos mapas de endereçamento do IEC61850.

LD – Logical Devices – São os dispositivos lógicos dentro deste servidor físico, que funcionam como "containers" de funções (Logical Nodes) ou mesmo como "gateways" entre LNs de LDs diferentes. Geralmente são usados os nomes internos do IED na parte inicial do nome (prefixos) e sufixos que indiquem a função principal do LD. São exemplos de sufixos CTRL, MEAS, etc.
LN – Logical Nodes – São objetos que implementam as funções básicas bem definidas dentro do Logical Device. Os nomes dos Logical Nodes são padronizados. Cada LN contém objetos, conjuntos de dados, definições de Reports, de Logs, de grupos de parâmetros e serviços que implementam objetos e funções. Por exemplo, uma chave seccionadora, seu estado, seu controle, como o com o nome "Q0CSWI1". O LN no caso é o CSWI – "Switch controller". Outros exemplos de LNs seriam os que executam funções de medição (MMXU), de transformador de tensão (TVTR), de proteção de sobre corrente (PTOC), de proteção térmica (PTTR). Uma lista completa de LNs para uso em IEDs de subestações e as regras de formação de seus nomes são apresentadas na norma IEC61850- Part 5.
FC – Functional Constraints – A função definida pelo LN conterá vários objetos que são distribuídos em categorias definidas como FC-Functional Constraints. Por exemplo "CO" que conterá objetos de comando, "ST" que conterá objetos de sinalização digital, "RP", para objetos do tipo Reports. A figura 4 apresenta objetos de medição que ficam na categoria "MX". A lista de FCs a seguir foi obtida na norma IEC61850 Part 7-2- 2003 – Tabela 18 – Na tabela original há mais detalhes sobre cada item.
ST Status information
MX Measurands (analogue values)
CO Control DataAttribute shall be operated (control model) and read
SP Setpoint DataAttribute shall represent a set-point: value may be controlled and read.
SV Substitution DataAttribute shall represent a substitution
CF Configuration DataAttribute shall represent a configuration
DC Description DataAttribute shall represent a description
SG Setting group Logical devices that implement the SGCB class
SE Setting group
EX xtended definition
BR Buffered report
RP Unbuffered report
LG Logging Attribute shall represent a log control
GO Goose control Attribute shall represent a goose control
GS Gsse control Attribute shall represent a goose control
MS Multicast sampled value control
US Unicast sampled value control
DO – Data objects – Os Data Objects são objetos, com nomes padronizados, que contém a informação propriamente. Estes objetos podem ser simples, como o objeto "Pos", que fornece a informação de posição do disjuntor. Há objetos mais complexos "A", que representa uma corrente trifásica. Ele é constituído, de quatro Data Attributes, cada um dos quais, com Data Attributes filhos informações de corrente de cada fase e de um neutro. Tem-se neste último caso, múltiplos níveis de Data Attributes na hierarquia abaixo de um Data Object.
São exemplos de DataObjects:
Beh – Behavior of LN
Health - state of the logical node related HW and SW.
Loc - switchover between local and remote operation
Mod – Mode and behavior: On, Blocked, Test, Test/Blocked, Off
Pos – Switch position
A – Current
neut – phase neutral
phsA, phsB,PhsC – phases A, B and C
Hz - Frequency
PPV - Phase to phase voltages.
PhV - Phase to ground voltages for Phases 1, 2, and 3, including Angle
DA – Data attributes -Cada objeto hierarquicamente abaixo de um Data Object ou de outro Data Attribute, no caso "ctlNum" ou uma fase da corrente como "phsC". Exemplos:
No caso de "Pos" pode-se ver quatro Data Attributes:
stVal – que contém o estado do disjuntor
q – a qualidade do dado
t – timestamp da amostragem
ctlNum - número de sequência de troca de status objeto de dados
No caso da corrente "pshC", além dela mesma ser um Data Attribute, esta contém ainda 4 Data Attributes abaixo de si:
cVal - a medida da corrente
instCval - a medida instantânea da corrente na última aquisição
q – a qualidade do dado
t – timestamp da amostragem.

Módulo de Comunicação

O módulo de comunicação (Módulo de comunicação) é composto por duas bibliotecas que trabalham em conjunto: Comunicação e Integração.

Biblioteca de Comunicação

A biblioteca de comunicação é desenvolvida na linguagem de programação C++ sendo responsável pela comunicação entre o Módulo de comunicação e equipamento. Foi projetada de acordo com a edição 2 da série padrão IEC 61850.

Objetos suportados

A tabela a seguir fornece uma visão geral dos objetos IEC 61850 suportados.

Serviços suportados

A tabela a seguir fornece uma visão geral dos serviços ACSI (Abstract Communication Service Interface) IEC 61850 suportados.

Biblioteca de Integração

A biblioteca de integração é desenvolvida na linguagem de programação C# e a biblioteca é responsável pela integração entre o Módulo de comunicação e o SCADA. Ela tem como objetivo transacionar as informações lidas e escritas entre o equipamento e o Action.NET.

Objetos implementados

A tabela a seguir fornece uma visão geral dos objetos IEC 61850 implementados. Os campos assinalados (✓) indicam a implementação do serviço.

Serviços implementados

A tabela a seguir fornece uma visão geral dos serviços ACSI (Abstract Communication Service Interface) IEC 61850 implementados. Os campos assinalados (✓) indicam a implementação do serviço.

Functional Constraints implementadas

A tabela a seguir fornece uma visão geral da propriedade Functional Constraint encontrada em cada atributo de um nó lógico. Os campos assinalados (✓) indicam a implementação da leitura ou escrita.

Funcionamento

O módulo de comunicação trabalha, de forma resumida, com a seguinte sequência de etapas.