335 Clearing of Bufovfl

Created: 29 Jun 2006

Status: In Force (green)

Part: Part 7-2 (2003)

Links:

Page: 085

Clause: 14.2.3.2.2.8

Paragraph:

Category: Issue may impact interoperability of implementations of Edition 1

Issue

The clause does not describe when the BufOvl flag is to be cleared. This ambiguity has lead to "compliant" devices that support clearing of the BufOvl flag only by the client setting the PurgeBuf bit. However, the purge buffer command can lead to loss of unreported events.

It doesn't make sense for a client wanting to maintain an accurate SOE log to have to set the PurgeBuf bit following a buffer overflow.

Proposal

The specification should add the following sentence. The BRCB
shall clear the BufOvl flag after the BRCB is able to buffer new unreported events, which generally occurs immediately after the BRCB sends a report.

Discussion	Created	Status
changed to green. The 7-2 clauses for reporting and logging ( Edition 1) 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 revised model in TISSUE 453 for dealing with the buffer overflow. move to final proposal	14 Dec 06	Ballot Period
Addressed this issue indirectly in the resolution of Tissue 278.	18 Oct 06	Not Applicable
Herb is right. Conceptually a BufOvl tag DOES NOT EXIST. It is just an indication, that the client asks for events which are not / no longer in the buffer.	30 Jun 06	Not Applicable
The buffer overflow bit should only be sent on the first report after enable. I believe that BUFOVL should only be set on the first report after Ena=TRUE if the EntryID that was "resynched to" by the client was not found. For a full description/discussion, see tissue 329 of 7-2	29 Jun 06	Discussion (red)

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1