Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[IED Plugin] Filters are not reactive when having IEDs sharing the same name (SPECIFICATION case) #1601

Open
michelguerin opened this issue Nov 19, 2024 · 6 comments
Assignees

Comments

@michelguerin
Copy link

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:

  1. Import SCD with functions
  2. Create virtual IEDs (via plugin menu)
  3. Go to IED plugin
  4. Filters on of the SPECIFICICATION named IED
  5. The same IED is always rendered

Expected behavior
Having multiple S-IEDs, one should be able to filter and rendered all of them.

Screenshots
Image
Image
Image

@michelguerin
Copy link
Author

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.

@JakobVogelsang
Copy link
Collaborator

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 desc field and search for IED[desc="..."] when name is SPECIFICATION
  • Introduce own namespace <IED: eown:id="..." ...> ... </IED> where eown is the prefix of the own namespace. eown could be e... instead.
  • use the Private element 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.

@illia-solovei-s1
Copy link

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.

@michelguerin
Copy link
Author

michelguerin commented Nov 25, 2024

@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>

@danyill
Copy link
Collaborator

danyill commented Nov 25, 2024

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>

@michelguerin
Copy link
Author

Oups, I skipped this part, thanks @danyill :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress
Development

No branches or pull requests

4 participants