Para aplicações de gateway, onde é necessário o envio dos dados deste driver 61850 para outros protocolos (como o DNP 3.0 ou IEC 104), é possível ocorrer situações onde, em caso de reinício da aplicação ou chaveamento para uma aplicação redundante (Hot Standby), há uma perda ou duplicação de eventos.
Isto pode ocorrer quando um evento foi recebido pelo driver 61850 e repassado adiante, mas ainda não foi recebido pelo mestre remoto do outro protocolo. Exemplo:
Aba Reports
A imagem acima mostra que é possível termos eventos sendo transferidos e pendentes de transmissão nos diversos componentes (61850 Server, 61850 Client, DNP Slave e DNP Master). Esta fila de eventos pendentes pode ser maior ou menor a depender das configurações desses componentes e da arquitetura de rede, dentre outros fatores.
Quando ocorre um chaveamento do Gateway A para o Gateway B, por exemplo, os eventos que estavam pendentes de transmissão podem tanto serem perdidos ou serem duplicados, dependendo da configuração da aplicação. Isto porque o protocolo 61850 permite que sejam recebidas novamente as mensagens de reports buferizados, a partir da programação do campo EntryID de cada report, que é um identificador único de cada mensagem enviada.
Este driver já possui um recurso de geração de arquivos com o último EntryID de cada report, que é utilizado para habilitação dos reports quando o driver inicia novamente. Entretanto, estes EntryID´s são atualizados com base no instante de recepção das mensagens pelo driver 61850, e não pela recepção de fato do dado em um elemento externo, no caso do exemplo acima, no centro de controle.
Desta forma, ao habilitar o recurso de Gateway pela opção "Wait for Gtw Ref on Startup", o driver espera que a aplicação E3 informe um string que representa o endereço de um tag 61850 dentro de um outro driver (ex: DNP ou IEC 104). Quando este outro driver receber a confirmação que um evento foi entregue ao centro de controle (DNP ou IEC 104 Mestre) ele pode informar o driver 61850 sobre este evento, e desta forma o driver 61850 pode posicionar os controles de EntryID à frente, para que caso haja um novo chaveamento, que o fluxo de eventos continue a partir deste último ponto - evitando assim ao máximo a perda ou repetição de eventos.
Gerenciamento de EntryIDs
Os passos para a configuração deste recurso são os seguintes:
1 - Habilitar as opções "Check BRCB Entry ID", "R/W Entry ID File (.EID)", "Wait for Gtw Ref on Startup". Além disto, caso o IED utilize os mesmos reports para os dois gateways, deve-se avaliar o uso de uma lista fixa de reports - "User Defined Report List", evitando assim que a aplicação redundante tente habilitar outros reports que não são os esperados.
2 - No driver 61850, crie o tag "FinishedGtwRef", e os blocos "GatewayRef" e "GatewayEventOK" conforme imagem abaixo. Estes 3 tags estão descritos na aba Referência de Tags - Tags Internos.
3 - Tomando o driver DNP Slave como exemplo, deve ser criado um bloco N2=-22 que recebe no script OnRead uma lista com todos os eventos confirmados pelo mestre. Consulte a documentação do driver DNP para mais detalhes.
4 - Os tags no driver DNP Slave devem receber links dos tags 61850. Na imagem abaixo é possível um exemplo onde o tag AI_0 (objeto DNP 3205 índice 0) está sendo alimentado por uma corrente da fase A vinda do 61850.
5 - A aplicação ao iniciar, deve fazer uma inicialização das referências, passando um texto que representa o endereço DNP para cada tag 61850 que for necessário realizar o controle de EntryID. Porém esta escrita só pode ser realizada no momento que o driver estiver com os Logical Devices criados, caso contrário a escrita falha. Para solucionar este problema, o exemplo abaixo mostra um tag interno que tenta enviar a configuração a cada 5 segundos, a partir do momento que obteve sucesso, ele não tenta mais. Ao final do processo é escrito o tag "FinishedGtwRef".
Também neste exemplo, o string de referência foi obtido através da união do objeto e variação do tag DNP, mais o seu índice. No driver DNP Slave estes valores são obtidos no parâmetro N3 e N4 respectivamente.
Valor inicial do Tag InitGateway: TRUE (Boolean)
Evento WhileNotOK: Expressão: Value Repetir o Evento a cada 5000 ms
Sub InitGateway_WhileNotOK()
Set DNPSlave = Application.GetObject("DNPSlave")
Set Ref = Application.GetObject("IEC61850").Item("GatewayRef")
bFirst = FALSE
for each tag in DNPSlave
if TypeName(tag) = "IOTag" Then
if tag.N2 = 1 Then
Source = tag.Links.Item("Value").Source
Set s = Application.GetObject(Source)
arr = Split(s.ParamDevice,":")
Ref.Item("IEDName").Value = arr(0)
Ref.Item("LDName").Value = arr(1)
Ref.Item("Object").Value = s.ParamItem
Ref.Item("Ref").Value = CStr(tag.N3) + ";" + CStr(tag.N4)
if NOT bFirst Then
bFirst = Ref.Write(1) 'sync
if NOT bFirst Then Exit Sub
Else
Ref.Write 2 'async unconfirmed
End If
End If
End If
Next
res = Application.GetObject("IEC61850").Item("FinishedGtwRef").WriteEx(2) 'async unconfirmed
if res Then Value = FALSE
End Sub
6 - Quando o Bloco "EventOK" for lido no driver DNP Slave, significa que um novo evento foi recebido pelo DNP Master. O Script abaixo obtem as informações deste evento e repassa ao driver 61850. No caso específico do DNP Slave, este bloco retorna algumas informações sobre o evento, como objeto e variação, índice, classe DNP, valor, timestamp válido e timestamp. Enviamos todos esses parametros para o 61850 via escrita no bloco GatewayEventOK, exceto a classe DNP, que não é relevante.
Sub EventOK_OnRead()
Set IECBlock = Application.GetObject("IEC61850.GatewayEventOK")
IECBlock.Item("Ref").Value = CStr(Item("ObjVar").Value) + ";" + CStr(Item("Index").Value)
IECBlock.Item("Value").Value = Item("Value").Value
IECBlock.Item("TSValid").Value = Item("TSValid").Value
IECBlock.Item("Time").Value = Item("Time").Value
IECBlock.Write 2 'async
End Sub
7 - Neste momento o driver irá posicionar os EntryID´s para o próximo evento pendente. Para sincronizar os EntryID´s com o computador redundante, é necessário seguir os passos indicados na seção Redundância - Utilizando Arquivos EID.
8 - Para posicionar os EntryID´s, o driver utiliza a seguinte metodologia:
- Quando um novo report 61850 é recebido, verificamos se algum objeto teve uma variação de valor ou qualidade. Se houver, um novo evento é adicionado à uma lista interna individual por objeto 61850.
- Quando um evento é quitado pelo driver externo e recebido pelo bloco "GatewayEventOK", a lista interna é comparada com o evento removido da seguinte forma:
- Se o timestamp não é válido (o tag no DNP/IEC104 não está usando timestamp), todos os eventos são removidos da lista;
- Se o timestamp é válido, os eventos são removidos se forem iguais ou mais antigos que o evento recebido.
Para evitar processamento desnecessário, recomenda-se que apenas sejam adicionadas referências de tags que não podem ter mudanças perdidas ou duplicadas, tipicamente tags digitais ou de estados simples/duplos com timestamp. Também recomendamos que neste caso, os Datasets associados aos reports sejam separados por tipos de tags (ex: Não colocar no mesmo dataset tags digitais e analógicos), de forma a evitar a recepção de valores analógicos antigos sem necessidade.