Support #412
There is a general issue that when we have signals connected to generic inputs, typically it is not possible to associate these
0%
June 2014: First draft of a recommendation has been provided by Pierre; need to continue work including a recommendation.
May 2015: ENTSO-E Issue #5:
There is a general issue that when we have signals connected to generic inputs, typically it is not possible to associate these signals to a LN other than GGIO in the vendor tools.
Recommendation:
The IED configuration tool should allow the user to reconfigure the data model to match the semantic of the connected input.
The resulting models shall be correct (e.g. mandatory data are present).
The implementation of this functionality is facilitated thanks to the machine processable format (IEC 61850-7-7).
Use case 1: the signal is coming from an external equipment (e.g. a fan or a transducer)
NSD files contain the IEC 61850 object models in an XML format. They are published by the IEC and are classified by their namespace identifiers, version and revision numbers.
They can be used by an IED configuration tool to create the IED data model. It is assured then that the implementation of the data model follows the rules from the standard definitions of IEC 61850-7-2, IEC 61850-7-3, IEC 61850-7-4 or any other application domains (like IEC 61850-420, DER).
Thus by means of the IED configuration tool, the user can create/modify the data model of the device. The only limitations are the name spaces and their content supported by the device, in particular the CDCs. It is even possible for the user to create its own name space provided that the naming conventions from IEC 61850-7-2 and the strict use of IEC 61850-7-3 (i-e no extension of CDCs) are followed by the user. It is recommended that these rules be enforced by the IED configuration tool.
Use case 2: the signal is a proxy of a function in a legacy device (e.g. an external gas density monitor or a conventional protection device)
This can be handled by grouping the signals in logical nodes whose definitions come from the NSD files (similar to use case 1).
It must also be possible to identify that the functionality associated with the LN is not realised in the device itself. This can be handled by grouping the LNs in dedicated logical devices that declare to be proxies (ref. IEC 61850-7-1).
It would be recommended, that the IED configuration tool allows to the user to reconfigure the data model to match the semantic of the connected input.
There are two cases to differentiate:
- the signal is coming from an external equipment (e.g. a fan or a transducer)
- the signal is a proxy of a function in a legacy device (e.g. an external gas density monitor or a conventional protection device)
While the first case is not critical, we just would expect the IED configuration tool to allow reconfiguration of the signal name, for the second case it must somehow be possible to dientify, that the functionality associated with the LN is not realised in the device itself. This can e.g. be handled by putting all these logical nodes in a dedicated logical device that declares to be a proxy.
It needs as well consideration, if it shall be possible that the user can create his own namespace. And finally, we need to make sure that the resulting models are correct (i.e. mandatory data are present.
Description
There is a general issue that when we have signals connected to generic inputs, typically it is not possible to associate these signals to a LN other than GGIO in the vendor tools.