667   Receiving duplicated reports after restarting a client.

Created: 09 Aug 2010

Status: Not Applicable

Part: Part 7-2 (2003)

Links:

Page: 82

Clause: 14.2.2.15

Paragraph: All, revision also

Category: No impact on this part

Issue

Problem: Neither the old definitions on IEC_61850_7_2 14.2.2, neither the new proposed ones, solves the following question: At power on or restart of a client, it can not know what is the EntryID of the last properly received report. So, in that situation, the client will set an EntryID with all zeros and this will instruct the server, when going to the enabled state, to begin sending reports from the oldest one that is still buffered. This will cause the client to receive again a set of reports already received before it was restarted.

Proposal

That problem would be avoided if, while the BRCB is in the disabled state and before setting a new EntryID, the client could read the EntryId and the server informed the EntryID of the last report properly sent, and not "the last (i.e..newest) entry that has been entered into the buffer" as is proposed in the revision. In that manner, the client could resync the server to the oldest buffered report not yet sent.

That problem would also be avoided in a simpler way if the server keeps track of the reports already sent and, if not differently instructed by having a new EntryID set (i.e. if the client do not set a new EntryID value before enabling reports again), proceed sending reports from the oldest report not yet sent, as would be the case if the association would not be broken.

Discussion Created Status
As the server does never know what the last received and handled event entry of a client application was, it is always the clients's task to permanently store this, if he wants to use the features of buffered reporting. Else he must handle duplicated or missed events. 11 Aug 10 Not Applicable

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1