[IED Plugin] Filters are not reactive when having IEDs sharing the same name (SPECIFICATION case)
Describe the bug In the IED plugin, the filter is not working when having multiple S-IEDs, as selected any of them rendered always the same.
To Reproduce Steps to reproduce the behavior:
- Import SCD with functions
- Create virtual IEDs (via plugin menu)
- Go to IED plugin
- Filters on of the SPECIFICICATION named IED
- The same IED is always rendered
Expected behavior Having multiple S-IEDs, one should be able to filter and rendered all of them.
Screenshots
SPECIFICATION naming comes from the standard, and the S-IED does not have any id to make it unique. We might need something to distinguish these S-IED that is not the name nor the manufacturer.
Elements in and SCL-like schema do not have unique identifiers at the moment. This is going to come with Ed3 where - most likely - an attribute uuid will be introduced. In my opinion this solves the problem partly, because uuid are not very human friendly as not readable. To solve this problem, the desc attribute can be used that exists on every SCL element. When creating such a specification IED, this could be a mandatory field. In my opinion, there are multiple option that we can use:
- use
descfield and search forIED[desc="..."]when name isSPECIFICATION - Introduce own namespace
<IED: eown:id="..." ...> ... </IED>whereeownis the prefix of the own namespace.eowncould bee...instead. - use the
Privateelement like so<Private type="OpenSCD_SPECIFICATION_ID">someId</Private>
I would propose to use the desc attribute in all the scenarios to have a better human-readable distinction between SPECIFICATION IEDs and if this necessary to use the Private element as user defined namespaces are often stripped in other tools. The later one knowing that there will be a uuid with Ed3.
We decided to make the description field mandatory in the S-IED creation step, so we can move forward with the first option. Thank you for the suggestion, @JakobVogelsang.
@JakobVogelsang I played around with the XSD files of the ed2 (2007 B4), can it be considered as transposition of the standard and thus a source of truth for our usecase ?
If so, it seems that the desc field is not part of the standard. Here is an extract of the XSD file, regarding IED :
<xs:complexType name="tIED">
<xs:complexContent>
<xs:extension base="tUnNaming">
<xs:sequence>
<xs:element name="Services" type="tServices" minOccurs="0"/>
<xs:element name="AccessPoint" type="tAccessPoint" maxOccurs="unbounded">
<xs:unique name="uniqueLNInAccessPoint">
<xs:selector xpath="./scl:LN"/>
<xs:field xpath="@inst"/>
<xs:field xpath="@lnClass"/>
<xs:field xpath="@prefix"/>
</xs:unique>
</xs:element>
<xs:element name="KDC" type="tKDC" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="tIEDName" use="required"/>
<xs:attribute name="type" type="xs:normalizedString" use="optional"/>
<xs:attribute name="manufacturer" type="xs:normalizedString" use="optional"/>
<xs:attribute name="configVersion" type="xs:normalizedString" use="optional"/>
<xs:attribute name="originalSclVersion" type="tSclVersion" use="optional" default="2003"/>
<xs:attribute name="originalSclRevision" type="tSclRevision" use="optional" default="A"/>
<xs:attribute name="originalSclRelease" type="tSclRelease" use="optional" default="1"/>
<xs:attribute name="engRight" type="tRightEnum" use="optional" default="full"/>
<xs:attribute name="owner" type="xs:normalizedString" use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
tUnNaming adds optional attribute desc.
<xs:attributeGroup name="agDesc">
<xs:attribute name="desc" type="xs:normalizedString" use="optional" default=""/>
</xs:attributeGroup>
<xs:complexType name="tBaseElement" abstract="true">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Text" type="tText" minOccurs="0"/>
<xs:element name="Private" type="tPrivate" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="tUnNaming" abstract="true">
<xs:complexContent>
<xs:extension base="tBaseElement">
<xs:attributeGroup ref="agDesc"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Oups, I skipped this part, thanks @danyill :)