191   BRCB: Integrity and buffering reports

Created: 20 Aug 2005

Status: In Force (green)

Part: Part 7-2 (2003)

Links:

Page: 078/81

Clause: 14.2.2.5/14.2.2.12

Paragraph: third/first

Category: Issue may impact interoperability of implementations of Edition 1

Issue

This tissue was sent in recently:

Part 7-2 says in 14.2.2.5 "Internal events as result of ...... (dchg), .... (qchg), and ... (dupd) shall be buffered.....".

I had assumed that all reports would be buffered, but this seems to
indicate the Integrity and GI reports should NOT be buffered. Was that the intention of this text?

Proposal

Do you think that most other users understand it that way?

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 453 for the revised chapter, inc. the GI state machine.

GI are not buffered except the last one, till the next GI request is received, then the previous GI is removed from the Buffer. Buffering the Last GI has been decided to avoid BufOflv and therefore transmission of the whole history.

Integrity reports are buffered, but a note has been added regarding to the memory limitation.

"The BRCB shall buffer entries based on the trigger options data-change, quality-change, data-update, and integrity during loss of association.
After the association is available again, after the client has set the EntryID, and enabled the BRCB, the BRCB shall start sending the reports of events that have been buffered. The BRCB shall use the sequence and subsequence numbers so that no gaps occur.
NOTE Since the buffer events based on the trigger option integrity are buffered by the BRCB, and the memory of the IED dedicated for the buffering is limited, it is recommended to use the trigger option integrity in the BRCB with great care, to avoid a BufOvfl, and keep a long historical of the events." 		13 Dec 06 Ballot Period
Added text to resolve tissue 275.

New text posted here and tissue 275: "GI changes 20061025.doc" 		25 Oct 06 Discussion (red)
Propose the attached modifications to the GI section.

Changed from yellow to red... 		17 Oct 06 Discussion (red)
A GI can only be generated while the connection is established and the report is enabled. The only use case I see, is that during the reporting of the GI a connection is loss. In that case, I guess that it doesn't make really sens to buffer the GI, since the client will start a new GI after the next connection to receive the updated object directory.
I disagree with Wolfgang with regard to the buffering integrity. DChange and DUpdate already offer a way to get the trace of what happened. "integrity reports for periodic generation of measurement trend or similar" will only lead to a buffer overflow since most IED will not have such a huge buffer that enable to follow the trend. The trend is already stored with the DChange trigger option.

Buffering the GI and Integrity can only lead to an overflow of the buffer, which means that historical data change/data update and quality change are lost.
06 Apr 06 Future Improvement
The purpose of buffered reporting is to loose no events in case of communication interruption. This works as long as no buffer overflow accurs. From this point of view buffering a GI as well as integrity reports for the purpose of integrity is nonsense. If however I use integrity reports for periodic generation of measurement trend or similar, then I want this buffered! A GI is only necessary at communication startup or after buffer overflow, so it is of no practical relevance if it is buffered or not. The simplest solution is probably to buffer all reports irregardless of the cause. 16 Feb 06 Ballot Period
It is agreed that GIs need to be buffered. However, it is questionable why we would use integrity reports as opposed to GI on demand with buffered reporting.

Text in 14.2.2.5 should be modified accordingly.

We might consider to add as well a note regarding the use of Integrity reporting and buffered reports. 		14 Feb 06 Ballot Period
One (obvious) interpretation of buffering could be: the server is always buffering reports (since the last start of the server).

enable reporting could simply mean: client wants to receive the "stream" of reports

disable reporting could simply mean: stop sending the "stream" of reports

This tissue needs further discussions. 		20 Aug 05 Discussion (red)
During the telephone conference of the editors' group (2005-08-18) we discussed the issue of buffering of integrity reports.

The current text says in 14.2.2.12 IntgPd – integrity period

"If TrgOp is set to integrity ... shall report the values of all members of the related DATA-SET."

It was proposed (in case of connection lost and IntgPd (>0) to discuss the possibility to buffer integrity reports only when there was a dchg, qchg or dupd during the last period. 		20 Aug 05 Discussion (red)
The buffering should also happen with Integrity: see

"14.2.3.2.3.6 Buffering events

The BRCB shall buffer events based on the trigger options data-change, quality-change, data-update, and integrity during loss of association."

I guess it does not make sense to buffer GI caused events, because GI is used to get a update of the current values. If the connection is down, then it would not make sense to store the some how old data ...

Clients may initiate a new GI when the connection is up again ... to get the actual update.
20 Aug 05 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1