Category: Issue may impact interoperability of implementations of Edition 1
Issue
Tissue brought up by Pierre L. Martin:
In the BRCB, attributes EntryId and TimeOfEntry seem to be linked but are used differently. Attribute TimeOfEntry may not be written, and shows the time of the last entry added in the buffer. Attribute EntryId may not be written when the report is enabled. Logically, it should show the ID of the last entry added in the buffer, but this is not clarified in documents IEC61850-7-2 and IEC61850-8-1.
When the connection has been down, attribute EntryId is used by the client to set the ID of the last report received. It is also said that EntryId can be used to acknowledge the reception of reports or to resend them, but it may not be written when the report is enabled (so how can we acknowledge or ask to resend a report without disconnecting?).
Attribute EntryId seems to have 2 uses, one of which is to show the id of the last entry added in the buffer and the other, which is for the client to set the last entry received. So the value set by the client and the value shown are 2 different values. There is a difference between the last EntryId added to the buffer by the server and the last EntryId received by the client.
Proposal
I'll be pleased if you could clarify this.
Discussion
Created
Status
changed to green. The 7-2 clauses for reporting and logging can be found at ftp.sisconet.com. Username=wg10revision pw: iec61850. Passive FTP must be used for retrieval.
16 Feb 07
In Force (green)
see Tissue 49 for definition of TimeOfEntry and interaction with EntryID, and uniqueness within the system.
see Tissue 453 for chapter edition inc. the BRCB state machine.
EntryID in GetBCRBValues:
"The value of EntryID, returned in a GetBRCBValues response shall be defined as follows:
• When the BRCB state is disabled: a GetBRCBValues shall return the EntryID value that represents the last (i.e..newest) entry that has been entered into the buffer.
• When the BRCB state is resync: a GetBRCBValues shall return the value of the EntryID specified within the last SetBRCBValues.
• When the BRCB state is enabled: The value of EntryID, returned in a GetBRCBValues response, shall be the EntryID of the last set of events sent.
An EntryID value of all zeros(0) is reserved to indicate an empty buffer, no reported EntryID shall have a value of zero(0).
"
TimeOfEntry in GetBRCBValues:
"The value, returned in a GetBRCBValues response, shall provide the time stamp of the EntryID whose value is exposed in the control block. The value exposed for TimeOfEntry, when the value of EntryID is zero(0), is a local issue."
13 Dec 06
Ballot Period
I agree. Suggest fix to GetBRCBValues to allow gets of PurgeBuf and TimeOfEntry.
24 Oct 06
Discussion (red)
Neither GetBRCBValues Response+ nor SetBRCBValues Response+ have any timestamps which would 'represent the timestamp of the EntryID whose value is able to be gotten'. EntryTime is only associated with individual reports.
24 Oct 06
Discussion (red)
See the attached proposed text.
17 Oct 06
Discussion (red)
I disagree. There are several differrent values that EntryID can be used for.
Assume that RptEna=FALSE, but bufferring of events had been previously enabled. If the Get of EntryID returns the ID of the last sent, then it may not be in the "buffer". Therefore, EntryID in this case should represent the first EntryID that can be reported in the current buffer. This value should be provided for based upon the transition of RptEna TRUE->FALSE.
When EntryID is written, for resync purposes, a get of the value the written value should be possible, if the EntryID exists within the buffer. Otherwise, the first available EntryID should be returned.
Upon transition of RptEna from FALSE->TRUE, the EntryID should assume the value of the last EntryID that was queued for sending.
I believe that EntryTimeStamp should represent the timestamp of the EntryID whose value is able to be gotten.
17 Oct 06
Discussion (red)
The observation is correct.
However: the EntryId should NOT be the last entry in the buffer BUT it should be the "last entry sent"
The operation should be:
- server updates attributes as entries are sent
- as long as operations succeed (i.e., connection stays up) no client action is required.
As long as the TCP connection is open no messages should be lost ... so that there is no need to request "resending" reports (by setting the EntryId by the client).
- if connection stops, client sets EntryId to LAST one he RECEIVED.
The acknowledgement mentioned in 14.2.2.15 of 7-2 means: an implicit acknowledgement of all reports up to the one for which the client sets the value of EntryId in the server. This is NOT an acknowledgement of an individual report! This "acknowledgement" is only "required" after the connection was down, to acknowledge that the reports up to the one written in EntryId were received by the client.
Open question:
What happens to EntryTime Stamp between write by client of EntryId and next serve report?