Improvement #6207
How to manage update of an IEDName or LDName for object references when valImport is false
0%
IEC 61850-6
Description
As per ObjectReference definition, the reference is including the IEDName or the ldName this mean two cases are possible:
LGOS.GoCBRef.setSrcRef <Val>’ldName’/LLN0.GoCB1</Val>
LGOS.GoCBRef.setSrcRef <Val>’IED Name + LD inst’/LLN0.GoCB1</Val>
When an SCT is updating IEDName or ldName, it has to maintain the ObjectReferences. But what if valImport is false?
First point, in which case do we have valImport set to false for ObjectReference?
Then, when it is set to false, it is the responsibility of the ICT to maintain the value, but how to identify the updates done in the SCD?
For this topic we need to consider the different cases involving ObjectReference (CDC ORG):
1/ LLN0.GrRef: identification of a parent LD, this is the responsibility of the IED/ICT to maintain it, surely valImport=false. Then, as it is a local reference, we may enforce usage of @ in SCL instead of IEDName to simplify the management?
2/ InRef: identification of an input of an LN. Usually related to ExtRef by IntAddr, but there is no strict rule for this assumption. What if valImport is false and not ExtRef is associated? the ICT/IED has no clue on the new IEDName/ldName. Do we forbid to have valImport=false for InRef without ExtRef? Then, we need to identify clearly also the rule to link InRef and ExtRef by intAddr. And when InRef valInport is true, how an SCT know the allowed Objects to be referenced? and what about
3/ BlkRef: identification of a blocking signal. Nothing is specifically designed in SCL to know which signal in SCD is used. ExtRef could be used also, but it is not mandated. We have the same issue as per InRef.
4/ GoCBRef/SvCBRef: identification a monitored GCB or SVCB. The referenced CB may be identified thanks to the ExtRef related to the supervised CB. But what if multiple CB names has been updated simultaneously? an algorithm may be able to recognize the correct supervised CB. But maybe not so easy.
Then we have also other cases like for statistics LN the ClcSrc refering to LN used for statitics calculation and InSyn to identify the external synchronization signal, and other cases.
Then, we also have to consider not only the setSrcRef/setSrcCB of the ORG which could be related to the ExtRef, but also setTstRef/setTstCB which are not configured by any other mean in SCL.
Considering all these cases, when valImport is false, the SCT is not able to maintain the ObjectReference regading update of any part of the reference even if the object is the same (IEDName, ldName, lnPrefix, CB name...) and the ICT may probably have an issue to recognize the Object in SCD after the update.
Do we allow valImport=false only for local references? with the @ which do not needs to be updated? and even in this case, what if an lnPrefix is updated for example?
And if we decide to force all valImport to true for ObjectReference, how to ensure that SCT is not providing wrong data? we do not have pDO/pDA as per ExtRef.
During a discussion in a small group of experts we do not fully agree on a solution. So we need to discuss the problem more widely.
Proposal descriptions
Recommendation from UF:
IEC 61850-6 Amendment 2.2 to include a written statement:
- ICT shall verify the coherency of the configuration
- SCT shall maintain all Object references with valImport=true when modifying the naming scheme
- Object reference involving external referencing are strongly recommended to implement valImport=true and to allow the SCT to maintain properly the referencing.
Also ED 2.2 will provide a way of using GUID inside Object Reference Val.
Updated by Carlos Rodriguez del Castillo almost 2 years ago
- Discuss in Upcoming Meeting changed from No to Yes
Updated by Carlos Rodriguez del Castillo almost 2 years ago
- Category set to Standard extension required
- Status changed from New to Resolved
- Discuss in Upcoming Meeting changed from Yes to No
- Proposal descriptions updated (diff)
Updated by Carlos Rodriguez del Castillo over 1 year ago
- Discuss in Upcoming Meeting changed from No to Yes
Updated by Carlos Rodriguez del Castillo over 1 year ago
- Discuss in Upcoming Meeting changed from Yes to No