880   Modelling an E/M P function

Created: 03 Aug 2012

Status: In Force (green)

Part: Part 7-4 (2010; Edition 2)

Links:

Page: 22

Clause: 5.3.2

Paragraph:

Category: Issue for edition 3 of this part

Issue

This may start as just a question but may change to something for the Standard in some way.

Does the new Proxy Data Object deal with the case of modelling an electromechanical protection relay which has one trip contact that you want represented on the SAS LAN as its respective Pxxx LN – e.g. an electromechanical high impedance busbar diff as a hard wired input to an IEC 61850 IED (of any type) which publishes the status of the opto input as PDIF.Op

This is partly related to TISSUE 864 under Part 10 Ed1 regarding avoiding unnecessary/incorrect use of GGIO in a virtual-to-virtual signal world. TISSUE 864 makes the point that GGIO MUST NOT be used for virtual-to-virtual world signals, but clearly GGIO must also not be used for wire-to-virtual world interfaces where the wire-world is a non-IEC 61850 IED but doing a Pxxx function with a contact output

This is about the mechanism to reflect an external device operation via a hard wired input to a Pxxx.Op

What we want is to have the physical opto-input to the IED use that to be the InRef to a ‘proxy’ PDIF LN
That PDIF only has a .Op output

At the moment I get the feeling that the interpretation of “Proxy.stVal=true” is that all the values and controls etc are mirrors of values and controls that reside in another IED – perfect for a gateway.

What we have here is a “Physical Node” (to coin a phrase).

It is the same as the LN but has no inherent algorithm behind it, no setting ability etc – it is just an output Pxxx.Op

I guess it could have settings if we wanted to ‘reflect’ what it “should” be set on as part of the SCD “one-source-of-truth” of relay settings.

So I’m wondering whether we need a Data Object “PhyNode=true” to identify this is a valid source of status but with very limited data model – don’t ask it any questions, don’t send it any commands, don’t try to configure a dynamic data set with additional info of phase etc …– real people have to go look at the device.
It means that the IED and the engineering tools must be able to support giving each opto input a selectable LN name - this is one of the few times where you will see me accept that perhaps the default is a GGIO! :)

The question also relates to having a Logical Device in which the Physical Nodes reside since they can’t be controlled in the same way as a full LD/LN – i.e. you can’t put it into SIM mode etc

Proposal

Consider creating a Data Object "PhyNode" to distinguish between 'conventional LNs and this special Physical Node with the same name.

Establish a suitable term such as "Physical Node" to help in verbal and written exchanges