733 ExtRef GOOSE source ambiguous
Created: 24 May 2011
Status: Not Applicable
Part: Part 6 (2009-12; Edition 2)
Category: No impact on this part
Prior to Edition 2 there was no mechanism for specifying which GOOSE messages were subscribed by a particular LN. With the addition of the ExtRef element in Ed.2 there is now an explicit mechanism for specifying the source of external signals.
For GOOSE messages, the identification of the source of these signals appears to rely solely on the GOOSE Control Block name. Part 8 (18.1.1) specifies that the GSEControl appID rather than the control block name shall be included in the MMS GCB. The usage between Control Block Name and appID is ambiguous.
GOOSE messages are identified by the publisher using a combination of destination MAC Address, ETHERTYPE APPID and GSEControl name/appID.
The intended use of destination MAC Address, ETHERTYPE APPID and GSEControl name and/or appID in the design of GOOSE-based applications should be clearly explained, and examples given of how the constituant messages of an application may be published and subscribed.
All the information needed to configure the GOOSE identification is available by solving all the references in the GOOSE ExtRef element: e.g. the sourceCB name points to the source CB, which contains the GoID as AppId and the data set name, and is linked to the APPID and MacAddr etc in the Communication section. It is an IED / IED tool private matter in which format it brings this into the IED, i.e. if the IED can resolve these references in an SCL file, or a tool writes this into an IED Private section in the CID or even an IED private file to be loaded to the IED. SCL was NOT meant to define an optimal format for loading onto an IED, it is for information exchange between tools.
||20 Jan 12
Further to this issue, it has been stated (in the discussion of Tissue 815) that "the only purpose of a CID is to configure an IED". Granting that this is true, and assuming that the subscription of GOOSE messages is reasonably included as part of the IED configuration, I would like to reopen this discussion.
The configuration of GOOSE message publication includes elements which are not currently accessible by the Inputs/ExtRef elements; these include the ETHERTYPE APPID, MAC address, GSEControl appID and confRev. In addition, the ExtRef element does not contain sufficient information to allow binding of the external data to items in the DataSet.
Regardless of the scheme utilized by a particular device to identify incoming GOOSE messages during operation, there is a minimum amount of information required to configure subscription of messages by the device which, at the present time, is not available.
I propose that the same information used to configure publication of a GOOSE message should also be available to configure the subscription of it in another (or even the same) device.
|19 Jan 12
There is a difference between defining the source of data to be received at engineering time and identifying an incoming message online. SCL cares about the first, and the ExtRef control block reference identfies uniquely the kind of service to be used, and the data set to be used.
For online identifying incoming GOOSE the global (per SCD file / system project)identification of the data set is relevant - which can easily be used, because the data set reference is contained in each GOOSE message. All the other parameters are from standard point of view not necessarily unique, i.e. they can be used for data flow filtering, or need additional non standard (private, non interoperable) rules, if somebody wants to use them.
|09 Jun 11
Privacy | Contact | Disclaimer
Tissue DB v. 188.8.131.52