In gateway applications, in which it is necessary to send data from this Driver to other protocols, such as DNP 3.0 or IEC 104, there may have situations, in case of restarting an application or switching to a redundant application, or Hot-Standby, in which there is a loss or duplication of events.
This may occur when an event was received by this Driver and forwarded, but it has not been received yet by the remote master in another protocol, according to the example on the next figure.
Gateway configuration
The previous image shows that events being transferred and pending of transmission in several gateway components (61850 Server, 61850 Client, DNP Slave, and DNP Master) may exist. This queue of pending events may change its size depending on the configuration of these components and network architecture, among other factors.
When there is a switch-over from Gateway A to Gateway B, for example, the events pending transmission can be either lost or duplicated, depending on the application's configuration. This occurs because the 61850 protocol allows receiving again Buffered Report messages, by programming the EntryID field of each Report, which is a unique identifier of each message sent.
This Driver already provides a feature to generate files with the last EntryID of each Report, which is used to enable Reports when this Driver starts again. However, these EntryIDs are updated based on the moment the messages are received by this Driver, and not by the real reception of data in an external system, in the case of the previous example, the control center.
This way, when enabling the Gateway feature using the Wait for Gtw Ref on Startup option, this Driver waits for an Elipse Power application to inform a String representing the address of a 61850 Tag inside another Driver, such as DNP or IEC 104 Slave. When this other Driver receives the confirmation that an event was delivered to the control center, DNP or IEC 104 Master, it can inform back this Driver about this event, so this Driver can position EntryID controls forward so that, in case of a new switching, the flow of events continue from this point on, thus avoiding event loss or repetition.
Management of EntryIDs
The steps to configure this resource are the following:
1.Enable the options Check BRCB Entry ID, R/W Entry ID File (.EID), and Wait for Gtw Ref on Startup. Also, if the IED uses the same Reports for both gateways, users must evaluate using a fixed list of Reports in the User Defined Report List option, thus avoiding that a redundant application tries to enable unexpected Reports.
2.On this Driver, create the FinishedGtwRef Tag and the GatewayRef and GatewayEventOK Block Tags, according to the next figure. These Tags are described on topic Tag Reference - Internal Tags.
Tags created in this Driver
3.Taking the DNP Slave Driver as an example, create a Block Tag with the N2 parameter equal to -22, which receives on the OnRead event a list with all events confirmed by the Master. Please check DNP Driver's documentation for more information.
Block Tag on the DNP Slave Driver
4.The Tags on the DNP Slave Driver must receive Links from the Tags of this Driver. The next image shows an example in which the AI_0 Tag, a 3205 DNP object with index 0 (zero), is fed by a phase A current from this Driver.
Tag properties
5.The application, when starting, must initialize its references, passing a text that represents the DNP address for each Tag of this Driver needed to perform a control of EntryIDs. But that writing can only be performed at the moment this Driver has its Logical Devices created, otherwise the writing fails. To solve this problem, the next example shows an Internal Tag that tries to send the configuration every 5 (five) seconds. If that operation is successful, it stops trying. At the end of this process, the FinishedGtwRef Tag is written.
6.Also in this example, the reference String was retrieved by joining the object and variation from the DNP Tag plus the index. On the DNP Slave Driver, these values are retrieved from the N3 and N4 parameters, respectively.
•Initial Value of the InitGateway Tag: True (Boolean)
•WhileNotOK event: Expression: Value Repeat event every 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
7.When the EventOK Block Tag is read on the DNP Slave Driver, it means a new event was received by the DNP Master. The next script retrieves information from this event and forwards it to this Driver. In the specific case of a DNP Slave Driver, this Block Tag returns some information about that event, such as object and variation, index, DNP class, value, valid timestamp, and timestamp. All these parameters are sent to this Driver by writing to the GatewayEventOK Block Tag, except the DNP class, which is not relevant.
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
8.At this moment, this Driver positions the EntryIDs at the next pending event. To synchronize the EntryIDs with the redundant computer, users must follow the steps indicated on topic Redundancy - Using EID Files.
9.To position the EntryIDs, this Driver uses the following methodology:
•When a new Report is received, checks if any object had a variation in value or quality. If positive, a new event is added to an internal individual list per object.
•When an event is confirmed by an external Driver and received by the GatewayEventOK Block Tag, the internal list is then compared with the removed event as follows:
•If the timestamp is not valid, that is, a Tag on a DNP or IEC 104 Driver is not using a timestamp, all events are removed from the list
•If the timestamp is valid, events are removed if they are equal or older than the informed event
To avoid unnecessary processing, it is recommended to only add Tag references that cannot have lost or duplicated changes, typically Digital or simple or double state Tags with timestamp. It is also recommended that, in this case, the Datasets linked to Reports be separated by type of Tag, such as not placing Digital and Analog Tags on the same Dataset, to avoid receiving old and unnecessary analog values.