329   Reporting and BufOvl

Created: 01 Jun 2006

Status: In Force (green)

Part: Part 7-2 (2003)

Links:

Page: 085

Clause: 14.2.3.2.2.8

Paragraph: 1

Category: Issue may impact interoperability of implementations of Edition 1

Issue

The specification of setting BufOvl=TRUE is ambiguous and needs to be refined. The basic issue is what constitutes a buffer overflow.

Take the following example, a set of buffered reports with EntryIDs 5,6,7,8

A new event/report is buffered and 5 is discarded so the remaining IDs are 6,7,8,9.

There are four interesting use cases:

a). a client resyncs by writing EntryID 6.

In this case, the reporting would start with EntryID 7. Thus, even though 5 was lost, it is of no concern to the client and I believe that the buffer overflow bit should not be set.

b). a client resyncs by writing EntryID 5.

5 is no longer in the "buffer" so 6 will be reported. I believe that in this case, the buffer overflow should be set.

c). a client resyncs by writing EntryID 0 (e.g. give me everything in the buffer).

6 should be sent with a buffer overflow set.

d). a client resynce by writing EntryID 0, receives report 6, then disables/enables reporting again resyncing with EntryID 0. Should 6 be sent with buffer overflow? I don't think so...



Proposal

7-2 should be revised to specify that the buffer-overflow bit should only be True:

if the Resync EntryID is not found in the buffer and buffered information has been discarded prior to resync/enabling of reporting.

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 TISSUE 453 for revised model
The setting of BufOvl has been clarified. Use Cases have been added.
14 Dec 06 Ballot Period
See resolution of tissue 278. 18 Oct 06 Discussion (red)
COncerning the detailed use cases, the proposal can also be misinterpreted, so a more detailled statement is still needed.
Concerning the use cases: To b): if entryID 5 is written, this has been received by the client. So, if then entryID 6 can be sent, this is NO buffer overflow for the client.
To c): writing a NULL value (to be clarified what this really means for the octett string entryID) means I want everything in the buffer, starting with its first event (whose number I do not know) - again a buffer overflow tag is not needed, might be misleading in interpretation.
13 Jun 06 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1