tIED: removeIeds behaviours with LNodes #121

Activity

1. danyill

   added

   enhancementNew feature or requestNew feature or request

   on Dec 5, 2024
2. JakobVogelsang commented on Dec 5, 2024

   

   JakobVogelsang

   on Dec 5, 2024

   Contributor

   More actions

   Hi Dan, I would propose to add an option to removeLNode.
3. JakobVogelsang commented on Dec 5, 2024

   

   JakobVogelsang

   on Dec 5, 2024

   Contributor

   More actions

   Would you mind it being a default false?
4. danyill commented on Dec 5, 2024

   

   danyill

   on Dec 5, 2024 via email

   CollaboratorAuthor

   More actions

   Let's do that, I shall prepare a PR

   …

   On Thu, 5 Dec 2024, 21:48 Jakob Vogelsang, ***@***.***> wrote: Would you mind it being a default false? — Reply to this email directly, view it on GitHub <#121 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFEXX5IGHC634THWQASFG32EAHNTAVCNFSM6AAAAABTB4BY22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJZGY2DKOBXGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>
5. danyill commented on Jan 9, 2025

   

   danyill

   on Jan 9, 2025

   CollaboratorAuthor

   More actions

   I think having a default of false is appropriate for an updateIED function (for a single IED). Although it could pose a problem there if there was already a iedName of None and matching other attributes.

   If we had an updateIEDs function I'd use true because otherwise we would likely break schema validity (or need to check and remove as necessary) if we had multiple LNodes with matching attributes across multiple IEDs.

   That posits a little challenge because the user should not see different behaviour when removing one IED vs. more than one IED. So I'd like to propose a default of true.
6. JakobVogelsang commented on Jun 5, 2025

   

   JakobVogelsang

   on Jun 5, 2025

   Contributor

   More actions

   This is very reasonable. Let's got with true then :)

   👍React with 👍1Reacted by Daniel Mulholland
7. ca-d commented on Apr 27, 2026

   

   ca-d

   on Apr 27, 2026

   Contributor

   More actions

   I would have guessed that someone removing an IED would want one of these two:

   1. Remove all LNodes pointing into this IED entirely without any substitute
   2. Virtualize all LNodes pointing into this IED by setting iedName=“None”, in which case duplicate LNodes in the same place are always to be avoided.
      In particular, I cannot see a need for ever generating duplicate LNodes and thereby invalidating the file.

   @JakobVogelsang @danyill Am I getting the situation wrong? If so, in what way?

   ❤️React with ❤️2Reacted by Stee and Daniel Mulholland
8. JakobVogelsang commented on Apr 29, 2026

   

   JakobVogelsang

   on Apr 29, 2026

   Contributor

   More actions

   Hi you all, Stephen has triggered me today with this issue. I have another proposal for discussion @danyill @ca-d:

   If an LNode element has no lnType then we remove the LNode element.
   If an LNode element HAS a lnType then we do not remove but set the iedName to None.
9. danyill commented on May 1, 2026

   

   danyill

   on May 1, 2026

   CollaboratorAuthor

   More actions

   Hi you all, Stephen has triggered me today with this issue. I have another proposal for discussion @danyill @ca-d:

   If an LNode element has no lnType then we remove the LNode element. If an LNode element HAS a lnType then we do not remove but set the iedName to None.

   That seems incomplete to me... I think though it's heading in the right direction and the suggestion from @ca-d has merit.

   The uniqueness constraint in IEC 61850-6 is something like (for a LNode within a Function):

   <xs:element name="Function" type="tFunction" minOccurs="0" maxOccurs="unbounded">
   	<xs:unique name="uniqueLNodeInFunctionSS">
   		<xs:selector xpath="./scl:LNode"/>
   		<xs:field xpath="@lnInst"/>
   		<xs:field xpath="@lnClass"/>
   		<xs:field xpath="@iedName"/>
   		<xs:field xpath="@ldInst"/>
   		<xs:field xpath="@prefix"/>
   	</xs:unique>
   	<xs:unique name="uniqueChildNameInSubstationFunc">
   		<xs:selector xpath="./*"/>
   		<xs:field xpath="@name"/>
   	</xs:unique>
   </xs:element>

   Given we require uniqueness across multiple fields perhaps what we should implement is:

   If removing the iedName is sufficient to guarantee uniqueness within the appropriate location, then just do that, otherwise check all other uniqueness criteria and if they would be broken then remove the LNode.

   The standard requires:

   • For iedName != "None": (iedName, ldInst, prefix, lnClass, lnInst) unique across all Substation sections.
   • For iedName = "None": (ldInst, prefix, lnClass, lnInst) unique within the same substation container (Bay, VoltageLevel, or Substation).

   Perhaps something like this?

   import { type EditV2 } from '@openscd/oscd-api';
   
   /**
    * Build the edits required to detach all public LNode bindings to `iedName`
    * from the substation model, preserving each as a specification entry with 
    * (iedName="None") where possible.
    */
   export function detachLNodeBindings(
   	doc: XMLDocument,
   	iedName: string,
   ): EditV2[] {
   	const KEY_ATTRS = ['lnClass', 'lnInst', 'ldInst', 'prefix'] as const;
   	
   	const CONTAINER= 'Bay, VoltageLevel, Substation';
   
   	const lnodeKey = (ln: Element): string =>
   		KEY_ATTRS.map(a => ln.getAttribute(a) ?? '').join('|');
   
   	const isPublicSubstationLNode = (ln: Element): boolean =>
   		!ln.closest('Private') && ln.closest('Substation') !== null;
   
   	const candidates = Array.from(doc.querySelectorAll('LNode'))
   		.filter(ln =>
   			ln.getAttribute('iedName') === iedName &&
   			isPublicSubstationLNode(ln),
   		);
   
   	if (candidates.length === 0) return [];
   
   	const candidateSet = new Set(candidates);
   
   	const claimed = new Map<Element, Set<string>>();
   	for (const ln of Array.from(doc.querySelectorAll('LNode[iedName="None"]'))) {
   		if (candidateSet.has(ln)) continue;
   		if (!isPublicSubstationLNode(ln)) continue;
   		const cont= ln.closest(CONTAINER);
   		if (!cont) continue;
   		let keys = claimed.get(cont);
   		if (!keys) claimed.set(cont, (keys = new Set()));
   		keys.add(lnodeKey(ln));
   	}
   
   	const edits: EditV2[] = [];
   
   	for (const ln of candidates) {
   		const cont= ln.closest(CONTAINER);
   		if (!cont) {
   			edits.push({ node: ln });
   			continue;
   		}
   		const key = lnodeKey(ln);
   		let keys = claimed.get(cont);
   		if (!keys) claimed.set(cont, (keys = new Set()));
   
   		if (keys.has(key)) {
   			edits.push({ node: ln });
   		} else {
   			keys.add(key);
   			if (ln.getAttribute('iedName') !== 'None') {
   				edits.push({ element: ln, attributes: { iedName: 'None' } });
   			}
   		}
   	}
   
   	return edits;
   }

   This would be for a use case of:

   • You remove an instantiated IED but you wish its functional linkages to remain so you can instantiate another IED against them.
   • In this case something like the above would allow removing and re-instantiating a single IED but not probably more than one at the same time because of risk of conflicts.

   Even if we did this (as a default) I'd probably suggest that it was a valid use case to also say "I don't want this IED or the functions it represents so let's remove the whole lot" so it would be perhaps an additional flag. You either delete the LNodes or you retain them if possible ("virtualise the IED") so we should implement as an option.
10. danyill

    assigned

    stee-re

    on May 6, 2026
11. stee-re

    added a commit that references this issue on May 27, 2026

    fix: removeIED - prevent duplicate LNode's

    ...

    This issue will close once commit 4ef2497 is merged into the 'main' branch.

    4ef2497
12. stee-re commented on May 27, 2026

    

    stee-re

    on May 27, 2026

    Last edited by stee-re

    Collaborator

    More actions

    The fix for this was revised, based on the discussions here. I waas forced to create a new PR #147 for this (because of the repo transfer).
    The default behaviour now is LNodes bound to the IED being removed, are also removed. But a new optional flag "preserveLNodes" has been exposed, which will update the LNodes iedName to None if doing so won't cause a duplicate. If it would cause a duplicate, it is simply removed instead.
13. danyill

    added a commit that references this issue on Jul 12, 2026

    fix: removeIED - prevent duplicate LNode's (#147)

    ...

    This issue will close once commit 31c619f is merged into the 'main' branch.

    31c619f
14. danyill

    closed this as completedin #147on Jul 12, 2026