Support #429
Input configuration: IEDs shall support ExtRef entries pointing to Data Objects as well as to DataAttribute with all possible le
0%
Discussion June 2014:Suggest to use ExtRef as mechanism for Engineering, but extend with some capabilities (e.g. to differentiate between Blocking, Input or unknown signal). Further work needed:- do we need to standardize inputs with semantic?- how does an ID declare how many ExtRef are needed per LN?- do we need to put ExtRef on all LNs or can we assume if ExtRefs are on LLN0 they are valid for all underlying LNs?- consider removal of ConfSigRef in service sectionThe ExtRef issue have been solved by many IOP 2013 and IOP 2015 issues. And by 7-1 Ed. 2.1 and annex H of part 6 Ed. 2.1
We assume that this is mandatory. The use of it being optional in the schema (because we may not want to refer to a DA) does not mean that it is optional to support the usage (if we want to refeetr to DA). This should be clarified and verified by conformance testing. Herb and Christoph to prepare proposal based on the following IOP conclusion: There are several different mechanisms that could be used in 61850-6 to subscribe to a GOOSE. However, the IOP group decided to use ExtRef. The standard should be revised to make this the only mechanism.
IEC 61850-6/7-1
Description
Input configuration: IEDs shall support ExtRef entries pointing to Data Objects as well as to DataAttribute with all possible levels.
Updated by Carlos Rodriguez del Castillo about 3 years ago
- Short Proposal changed from We assume that this is mandatory. The use of it being optional in the schema (because we may not want to refer to a DA) does not mean that it is optional to support the usage (if we want to refeetr to DA). This should be clarified and verified by conformance testing. Herb and Christoph to prepare proposal based on the following IOP conclusion: There are several different mechanisms that could be used in 61850-6 to subscribe to a GOOSE. However, the IOP group decided to use ExtRef. The standard should be revised to make this the only mechanism. to We assume that this is mandatory. The use of it being optional in the schema (because we may not want to refer to a DA) does not mean that it is optional to support the usage (if we want to refeetr to DA). This should be clarified and verified by conformance testing. Herb and Christoph to prepare proposal based on the following IOP conclusion: There are several different mechanisms that could be used in 61850-6 to subscribe to a GOOSE. However, the IOP group decided to use ExtRef. The standard should be revised to make this the only mechanism.
- Standard(s) set to IEC 61850-6/7-1
- WG10 Proposal changed from Discussion June 2014: Suggest to use ExtRef as mechanism for Engineering, but extend with some capabilities (e.g. to differentiate between Blocking, Input or unknown signal). Further work needed: - do we need to standardize inputs with semantic? - how does an ID declare how many ExtRef are needed per LN? - do we need to put ExtRef on all LNs or can we assume if ExtRefs are on LLN0 they are valid for all underlying LNs? - consider removal of ConfSigRef in service section The ExtRef issue have been solved by many IOP 2013 and IOP 2015 issues. And by 7-1 Ed. 2.1 and annex H of part 6 Ed. 2.1 to Discussion June 2014:Suggest to use ExtRef as mechanism for Engineering, but extend with some capabilities (e.g. to differentiate between Blocking, Input or unknown signal). Further work needed:- do we need to standardize inputs with semantic?- how does an ID declare how many ExtRef are needed per LN?- do we need to put ExtRef on all LNs or can we assume if ExtRefs are on LLN0 they are valid for all underlying LNs?- consider removal of ConfSigRef in service sectionThe ExtRef issue have been solved by many IOP 2013 and IOP 2015 issues. And by 7-1 Ed. 2.1 and annex H of part 6 Ed. 2.1
- Discuss in Upcoming Meeting set to No
Checking done.