O Elipse Gateway provê um gateway via software que dispensa a necessidade de hardwares adicionais e garante a eficiência da transmissão de dados. Esta solução pode ser utilizada por subestações ou unidades de geração para reportar dados para centros de controle e órgãos de gestão de energia, ou simplesmente para a troca dados entre dois sistemas.
A estrutura do Elipse Gateway é a seguinte:
Para criar um gateway de comunicação entre os dois drivers (mestre e escravo) na mesma aplicação, siga os procedimentos vistos a seguir neste artigo.
Configurações Básicas
Para garantir que todos os tags envolvidos neste gateway estejam sempre em comunicação, é preciso configurar a propriedade AdviseType com o valor 0 – AlwaysInAdvise em todas as variáveis utilizadas no gateway, tanto no driver mestre como no escravo.
Driver Escravo Elipse
Dependendo da ordem de ativação dos objetos instanciados na aplicação, é possível que o driver escravo seja ativado antes do driver mestre, e com isto o primeiro valor de cada variável não será recebido nos tags do driver escravo. Com isto, será preciso criar um script de ‘reinicialização’ dos tags do driver escravo.
Para isto, acesse o driver escravo, e crie um script no evento AfterStart para ativar e desativar todas as tags existentes no driver.
NOTA: No caso de pastas dentro do driver, é necessário apenas desativá-las e reativá-la, não sendo necessário varrer internamente cada uma das pastas.
Tags de Comunicação
Variáveis de leitura
Nas situações em que um valor recebido pelo driver mestre da Elipse necessite ser disponibilizado para o sistema externo, é preciso criar uma associação simples nos tags do driver escravo que receba o valor lido pelo driver mestre.
Além disto, é preciso também configurar as variáveis do driver mestre para que permitam leitura (propriedade AllowRead), e os tags do driver escravo para que permitam apenas escritas (propriedade AllowWrite).
Variáveis de escrita
1. Escrita simples de valor
Utilizada quando o sistema externo precisa fazer uma escrita simples ou enviar o valor de um setpoint no equipamento, por exemplo. Dependendo do equipamento, esta escrita deve ser feita na mesma variável de leitura do status, ou em uma segunda variável criada especificamente para este fim.
1.1. Mesma variável para escrita e leitura
Neste caso, crie uma associação bidirecional nos tags do driver escravo para o driver mestre.
Além disto, é preciso também configurar os respectivos tags dos drivers escravo e mestre para que permitam leitura e escrita.
1.2. Variável exclusiva para escrita
Já neste caso, crie uma associação reversa nos tags do driver escravo, enviando o valor ao driver mestre.
2. Escrita envio de comando
Quando comandos precisam ser enviados ao equipamento pelo sistema externo, é preciso criar scripts que interpretem este comando e repassem-no ao driver mestre Elipse.
Por exemplo: o sistema externo foi configurado para enviar o valor 65 (em determinada variável) para indicar que determinado disjuntor deve ser fechado; porém, o equipamento em campo espera pelo valor 1 para executar o comando Fechar. Deste modo, o Elipse Gateway precisa converter este valor antes que ele seja enviado ao equipamento de campo.
Este script deve ser criado segundo as informações contidas no manual do driver escravo sendo utilizado. Isto pode ser feito de forma centralizada ou distribuída, isto é, o script pode ser criado em um único lugar ou diretamente em cada driver. Além disto, é preciso desabilitar a propriedade EnableDeadBand nos tags que vão receber os comandos externos para que toda escrita recebida pelo driver escravo seja tratada pelo driver.
2.1. Script centralizado
Neste cenário, é criado apenas um script para atender a todos os envios de comando. O driver possui um evento OnTagRead que é disparado sempre que qualquer tag do driver recebe uma nova leitura (a opção EnableDriverEvent deve estar configurada). Este evento recebe como parâmetro o tag que recebeu a leitura, permitindo verificar em qual variável deve-se prosseguir com o envio do comandos. Com isto, é possível definir neste evento o tratamento dos comandos recebidos, todos em um único lugar.
DICA: o ideal é que o script seja gerado de forma mais genérica possível, para que ele não possua muitas situações com If/End If ou Select Case. Pode-se definir uma regra para o nome dos tags de comunicação, e com isto criar o script para simplesmente aplicar esta regra para chegar ao tag do driver mestre Elipse.
A seguir, um exemplo simplificado de como este script poderia ser criado. Ele tem a função de repassar ao driver mestre (cujos tags possuem os mesmos nomes dos tags no driver escravo) o mesmo valor recebido pelo driver escravo:
Sub DriverEscravo_OnTagRead(Tag)
TagDriverMestreName = Replace(Tag.PathName, “DriverEscravo”, “DriverMestre”)
set TagDriverMestre = Application.GetObject(TagDriverMestreName)
TagDriverMestre.WriteEx Tag.Value
End Sub
2.2. Script distribuído
Neste cenário, é criado um script em cada um dos tags que recebem os comandos externos. No evento OnRead do tag está o script responsável por interpretar a solicitação de comando e enviá-la para o tag no driver mestre Elipse desejado. No exemplo a seguir, uma escrita é gerada no driver mestre a cada novo comando recebido pelo driver escravo, ambos com o mesmo valor.
Sub PosicaoDisjuntor_Abre_Operate_OnRead
Application.GetObject(“DriverMestre.DJ5201.Comandos.PosicaoDisjuntor_Abre_Operate”).WriteEx Value
End Sub
Particularidades dos Drivers
DNP 3.0 Escravo
Recebimento de Comandos
O driver DNP Escravo possui três modos de tratamento de comandos recebidos pelo sistema externo (opção Command Response Profile):
- Deny Always: todos os comandos recebidos serão respondidos negativamente. Basicamente, este modo força o driver a não tratar nenhum comando externo.
- Accept Always: todos os comandos recebidos são aceitos e repassados ao tag de comunicação, e o próprio driver informa ao sistema externo que o comando foi aceito. A única responsabilidade da aplicação é tratar o valor e decidir o que fazer com o comando.
- Wait for Application Response: esta é o modo manual de recebimento de comandos. Eles serão tratados pela própria aplicação, que é reponsável por receber, verificar a aceitação, efetuar as escritas em outros drivers (quando necessário), e enviar o retorno ao sistema externo.
Na figura abaixo, está ilustrada de forma simplificada o tratamento de comandos quando este é totalmente realizado pela aplicação. Consideramos que quando o sistema externo envia o valor 65 para o tag Externo_CMD_DJ, o driver deve escrever o valor 2 no tag CMD_DJ.
Maiores informações sobre os procedimentos/scripts para receber comandos podem ser verificadas no manual do driver de comunicação.
IEC 870-5-101/104 Escravo
Recebimento de Comandos
Da mesma forma que o driver anterior, o driver IEC 101/104 também permite escolher as formas de tratamento de comandos, e possui as mesmas três opções de trabalho. Esta configuração é feita na aba IEC 870, sub aba Slave, opção Select/Execute command:
- Disabled: todos os comandos recebidos serão respondidos negativamente. Basicamente, este modo força o driver a não tratar nenhum comando externo.
- Handle automatically: todos os comandos recebidos são aceitos e repassados ao tag de comunicação, e o próprio driver informa ao sistema externo que o comando foi aceito. A única responsabilidade da aplicação é tratar o valor e decidir o que fazer com o comando.
- Pass to the application: esta é o modo manual de recebimento de comandos. Eles serão tratados pela própria aplicação, que é reponsável por receber, verificar a aceitação, efetuar as escritas em outros drivers (quando necessário), e enviar o retorno ao sistema externo.
Na figura abaixo, está ilustrada de forma simplificada o tratamento de comandos quando este é totalmente realizado pela aplicação. Consideramos que quando o sistema externo envia um comando Execute para o tag Externo_CMD_DJ, o driver deve escrever o valor 2 no tag CMD_DJ.
NOTA: O COT = 71 indica que não foi possível prosseguir com a execução da ativação/execução do comando.
Maiores informações sobre os procedimentos/scripts para receber comandos podem ser verificadas no manual do driver de comunicação.
Inicialização Modo Escravo
Além do que foi discutido no item Driver Escravo Elipse, quando trabalhamos nos protocolos IEC 101/104 no modo escravo, pode-se primeiro efetuar todas as configurações necessárias ao driver escravo e somente então fazer sua inicialização. Isto garante que o driver somente estará disponível para receber conexões e para trocar valores quando ele já estiver totalmente configurado.
Para isto, acesse a aba IEC870, sub aba Properties, e configure a propriedade Link Layer Starts com o valor Disabled:
Crie então um novo tag na aplicação, com a seguinte configuração: N1=0, N2=996, N3=0, N4=0, de nome ActiveLinkLayer (exemplo).
No evento OnAfterStart, após todos os tags do driver terem sido desativados e reativados, escreva o valor 1 neste tag.
Anexos:
