Improvement #6207
Updated by Camille Bloch over 1 year ago
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: - 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: - 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: - 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: - 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.