149   Comprehensive log entries

Created: 02 Apr 2005

Status: In Force (green)

Part: Part 7-2 (2003)

Links:

Page:

Clause: 14.3

Paragraph:

Category: Issue for edition 2 of this part

Issue

Sometimes it may be required to log additional information with an event. As an example, if a protection function operates, it might be of interest to log the active setting group.

The issue was raised at the Editor meeting in Ann Arbor in the context with Tissue #103

Proposal

Provide a solution

Discussion Created Status
Editor Meeting April 2008 - see IEC61850-7-1, IEC61850-7-2 and IEC61850-7-4 - CDV - Ed2
Comprehensive Logging is achieved with the use of the LN GLOG.
Extension of reason code are necessary for the log. 		28 Mar 09 In Force (green)
Editor meeting December 11:
One solution for the problem could be the following:
(1) a new attribute InclAll (Include All) is added to the report and log control block; if this attribute is set to TRUE, a report triggered by a trigger option dchg or qchg will not only include the member of the dataset that triggered the report or log but it shall include ALL members of the dataset (similar to e.g. trigger option integrity).

This approach needs as well an extension of the SCL.

This solution should not provide backwards compatibility issues; from a protocol viewpoint, there is no change.
(a) assume a client is not supporting this feature, that means he can not configure this attribute. If through SCL a (new) server is configured to send all data, the (old) client has from a communication viewpoint no problems receiving more data than expected.
(b) assume an old server and a new client. In that case, the client will see in the data model of the server, that the attribute InclAll is not present.
(c) assume an old server and a new system configuration tool. The schema reference of the .icd file from the old server points to the old schema; therefore, the system configuration tool knows, that the server is not supporting that feature. 		11 Dec 05 Discussion (red)
Proposal aggreed in Klaus: add a new attribute in the report/log control blocks. This attribute (boolean) when set to true, would enable the control block to send instead of only the report/log of the changed FCDA of the DataSet all the FCDA. The Reason-for-include would therefore be either d-chg, q-chg, or d-upt for the FCDA that triggered the report/log, and 0 for the other that are reported/logged for consistancy purpose.
05 Sep 05 Future Improvement

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1