1129   Rules for extending nameplate information

Created: 30 May 2013

Status: In Force (green)

Part: Part 7-1 (2011; Edition 2)

Links:

Page:

Clause: 14

Paragraph:

Category: Issue for edition 2 of this part

Issue

The basic nameplate information for devices and conducting equipments can be found respectively in the LPHD.PhyNam and XXXX. EEName data. There is a need to add rules defining how the nameplate information can be extended by owners of other domains (e.g. IEC 62271-3 or IEC 61869-9).

Proposal

Add the following rules:

Nameplate information can be extended by owners of other domains by adding additional data whose common data class is VSG (Visible String Setting) and the dataNs attribute value set to the owner's namespace.

The new data can be added either to the LPHD LN or to any LNs containing the data EEName.

Attachments:
    Note: To see attachments you have to log-in first.

Discussion Created Status
Based on Tissue #1189 (7-3), add text and an example in clause 14 about extending nameplate information.

Proposal: Create a new CDC VSD - visual string descriptive Information.

VSD class
val VISIBLE STRING255 DC M
d VISIBLE STRING255 DC O
dU UNICODE STRING255 DC O
cdcNs VISIBLE STRING255 EX AC_DLNDA_M
cdcName VISIBLE STRING255 EX AC_DLNDA_M
dataNs VISIBLE STRING255 EX AC_DLN_M

08 Jan 14 In Force (green)
I agree with the proposal that nameplate extensions should be handled by adding new data objects to the LN where the nameplate applies. This can be a LN that typically has as well a data object EEName (so a LN that directly represents Information from a process Equipment like a TCTR, a TVTR, an XCBR, etc).

I strongly suggest that such extensions are not just a encoded String; such extensions should be a number of individual data objects for each of the Parameters of the Name plate.

As a commmon data class, since this is namplate Information (which has the functional constraint DC), we should not (mis)use Settings (VSG) or Status Information (VSS) (as mentioned in the comment from Pierre, the Information is not writable and not settable). So I suggest to create a new CDC VSD - for Visual String Descriptive Information.
21 Nov 13 Discussion (red)
IEC TC 38 WG 37 is preparing the FDIS 61869-9, thus requires clear WG 10 guidance on how to change the nameplate extension modeling as currently outlined in the CDV.
IEC 62271-3 CDV (TC 17C) is being circulated at the NCs. Their CDV contains even an own CDC for the very same purpose!

Therfore, it is quite urgent to get a WG 10 resolution on this. The topic was discussed some time ago among WG 10 members, but never resolved. I will ask Christian Frei to add attachments (I cannot) showing the history:
1) initial proposal by Wolfgang Wimmer: IEC61869PltModel.pdf
2) feedback Thierry et al: nameplate info in 61869-9.pdf
3) feedback Henry et al: Re DO replacement for LPL_EIT and DPL_EIT in 61869-9.pdf
4) feedback David McGinn (WG 37): DO replacement for LPL_EIT and DPL_EIT in 61869-9.pdf
18 Oct 13 Discussion (red)
Nameplate extensions should be dealt with by adding data of CDC VSG as by definition, a nameplate object contents information on the form of static text to be read by machines/users (not writable, not settable).

As an example, in 61869-9, the extensions variant=F4800S2I4U4,F1440S6I4U4;fr=50,60;Uar=80-300 dc, 100-250 ac;hold=60;delay=1.5 actually apply to the MU IED and therefore should be added in LPHD.
30 May 13 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 21.10.16.1