1987 GSEControl / SampledValueControl IEDName element may point to an LN
- Created
- 04 Aug 2025
- Status
- Discussion (red)Open for discussion while the solution is worked out. Any signed-in reader may comment. Show the workflow
- Part
- Part 6 (2025; Edition 2.2)
- Links
- None
- Page
- 130
- Clause
- Table 28
- Paragraph
- 9.3.10
Issue
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 |
|---|---|
|
Discussion (red)
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 |
10 Oct 25 |
| Accepted to discuss | 10 Oct 25 |