Category: Issue may impact interoperability of implementations of Edition 1
Issue
In IEC 61860-6, clause 9.3.8, the type of RptId is tName, meaning that RptId’s name cannot be empty.
In IEC 61860-8-1, clause 14.2.2.4 says “The attribute RptID shall be the client-specified report identifier of the BRCB that has caused the generation of the report.
If the report identifier value of the BRCB is NULL, then the instance name (the whole path-name) of the BRCB shall be reported as the report identifier.”
There are two issues related to these clauses :
-Parts 6 and 8-1 are not clear if the value of the attribute RptId can be empty or not.
-In an ICD file, the optional datSet attribute may be absent. With no datSet specified, the client-specified report identifier of the report could not be set accordingly.
Proposal
Consider in part 6 to change the type of RptId from tName to xs:normalizedString
Discussion
Created
Status
To make the setting of a NULL value respective the non-setting in SCL completely clear, this shall be indicated by not specifying the rptID attribute at all, instead of using the empty string value.
21 Aug 07
In Force (green)
Note: if the RptID is defined in SCL, and is an empty-string or the Client sets it to an empty string, the the result must be the same as if the RptID was not defined.
So I suggest the empty-string for the RptID is equivalent to a NULL value, otherwise the Client may not have the "actual name" replacement by the "the whole path-name".
20 Aug 07
In Force (green)
Note: this solution will, like a few more error corrections, not be forward compatible (i.e. 'new' files' might not be understood by 'old' tools). Therefore this should already now be considered at tool development.
25 Apr 07
In Force (green)
The issue has already been taken up within WG10. The solution is not to change the type of rptID, instead the next SCL version makes rptID an optional attribute. If it is not used (i.e. missing in the SCL file), then this configures a rptID value NULL. The handling of this value at stack level is as described below by Herb.
27 Oct 05
In Force (green)
The 8-1 statement in clause 17.2.1 clearly differentiates between the value of the "control block RptID value" and the MMS data that represents the AccessResult (e.g. the value reported).
The statement is: "if the control block RptID value is NULL.." (e.g. has not been written by a client or set via SCL)"...the MMS data shall contain the...". This creates a default value that can be sent.
8-1 is clear in this regard.
The next question, regarding 8-1 is what happens if there is no datSet specified. 17.1.1.2 states "A V-Put or RptEna shall fail if the value of datSet is NULL" (e.g. has not been set by a client or SCL).
The issue of allowing a NULL RptID in SCL is a topic that may merit further discussion.