1730   Polarity of neutral in WYE is unclear

Created: 28 Oct 2020

Status: Discussion (red)

Part: Part 7-3 (2020; Edition 2.1)

Links:

Page: 55

Clause: 7.4.6

Paragraph: CDC (WYE)

Issue

Figure 16 seems to request that Ineut = -(Ia + Ib + Ic). However in table 33, the definition of Ineut specifies the "algebraic sum of the instantaneous values of currents flowing through all live conductors."

Proposal

61850 shall define un-ambiguously the Neut both for Current and Voltage systems, so that it is clear what is the interpretation of the associated samples, espcially when coming to the instrument transformer communication and process bus.

Backward compability shall consider potentially a polarity setting in order to change the polarity of neutral over the ethernet based on the utility philosphy for wiring.

Discussion Created Status
The only good definition we have in this context is the statement in table 33, saying that IN shall be the "algebraic sum of the phase values".
This is also what has been assumed for 9-2LE and has been implemented in the SV publisher test procedures and used in all MU certifications so far.
For the sake of interoperability, it is necessary that two MUs applied at the same measurement point deliver equivalent IN values, regardless if IN is derived or measured. There is no point to deliver 3I0 in one case and -3I0 in the other.
Sadly, the figures disturb our picture, since they suggest IN=-3I0. We would have been better off if we had named the fourth current just I4 and not IN, removing this connection to a physical model. This IN=-3I0 is deeply embedded in the thinking of the protection engineers (although there is no issue with accepting UN=3U0). It is questionable if the SVs should be seen as a digital twin of this schematic. Also, the formulas in the figures (somehow) suggest that there is a CT in the N line, which is typically not the case anyway. The "IN" is measured either through a Holmgreen circuit or a dedicated residual current CT (often also called zero sequence CT!), which both deliver 3I0 in the first place. Note that the "derived" case corresponds to the Holmgreen circuit. The "desired direction" is then achieved by connecting this in the appropriate way at the relay.
The SVs are a communication protocol and what is in the fourth current can be defined as +3I0 without restrictions for the applications. A MU needs to have a setting to deliver this, independent of the actual wiring of the residual current CT.
So I propose to stick with IN=3I0 and make the documents (in particular the figures) consistent with this.
The other option (which I do NOT recommend) would be to go for IN=-3I0 and change the current wording "algebraic sum of the phase values" and the SV publisher test procedures and waiving interoperability of all MUs certified until now. And I do not see that we would define UN=-3U0 just to make this consistent with IN=-3I0.
13 Nov 20 Accepted
A PIXIT entry is never a good solution for something that may create interoperability issues, as a PIXIT is not machine processable.

I think we agree that the TISSUE as such is relevant - so I progress the TISSUE to accepted.
03 Nov 20 Accepted
UCAIug test is presently intentionally vague on the polarity of neutral values.
I am unsure if a data object specifying neutral polarity could be enforced, but a PIXIT entry could be created to specify the polarity.
If a data object was present then the PIXIT entry could be verified against the PIXIT entry as a conditional test (condition=presence of the new data object)
02 Nov 20 Triage
This question is important and, as mentioned in the proposal, affect interoperability, not only for WYE.
Neutral U and I could be transmitted in 9-2 SV frames, especially for 9-2LE compatible frames.
As the UCAIUG test procedure for 9-2 LE publishers (V1.1) has a test case for calculated neutral values that check that Un=UA+UB+UC and In=IA+IB+IC, I would suggest to generalize those formulas, according to table 33, to limit interoperability issues with existing SV publishers.
02 Nov 20 Triage

 

Privacy | Contact | Disclaimer

Tissue DB v. 21.8.20.1