The IEDName definition contains attributes related to the destination LN.
This definition is incorrect because the destination of message published by a control block is a communication stack on the subscriber IED, while the LN on the subscriber IED is subscribing the signal(s) conveyed by the dataSet associated to the GSEControl (rep. SampledValueControl).
The destination LN is already specified because the configuration of the destination LN is realized inside its Input section indicating wihch signal(s) (over which GGOOSE message resp SMV message) will be subscribed.
Proposal
Deprecate the usage of the IEDName attributes:
-ldInst,
-prefix,
-lnClass,
-lnInst,
-ldUuid,
-lnUuid.
Discussion
Created
Status
I do not understand why it is a relevance for the enigneering perspective, as LNs do not subscribe GOOSE or SMV Telegrams but signals that are convey by a message: LN Input.
The IED communication stack on a give access point subscribe to the GOOSE resp SMV Telegram.
01 Dec 25
Discussion (red)
the destination LN in IEDName may be related to the ExtRef location, allowing a bidirectionnal definition, helping the ICT to find which data of the dataset are consumed.
I agree these attributes are not required for a communication perspective, but for an engineering perspective, il make sense to keep them