Say No to GGIO

GGIO is a perfectly valid Logical Node but with specific purposes defined under IEC 61850 7-4.

However some vendors have also used GGIO as a Logical Node required to send or receive messages to other Logical Nodes. 
Arguably the vendors should have all realised that this was not the intent of the Standard due to the description in the guide to function modelling IEC 61850-5 Ed 1 - Part 5 being a fundamental a forerunner of understanding before attempting to do anything with specific LNs in IEC 61850-7-4. 
IEC 61850-5 Ed1 clause 11.5.6:
"Outputs such as analog outputs, auxiliary relays, etc. not covered by the above-mentioned switchgear related LNs are sometimes needed. In addition, there are additional I/O's representing devices not predefined such as horn, bell, target value etc. There are input and outputs from non-defined auxiliary devices also. For all these I/O's, the Generic Logical Node GIO is used to represent a generic primary or auxiliary device (type X…, Y… , Z…)."
Note there is absolutely no reference to the use of GGIO being used as some form of intermediary "proxy" between the output of one LN and the input of another.
Certainly any protection function output MUST be represented by the respective Pxxx.Op status.

The confusion arguably arose out of a possible "translation typo" of two words in the wrong order in IEC 61850-7-4 Ed1 clause 5.7.2:
"For a description of this LN, see IEC 61850-5. This node shall be used to model in a generic way device processes that are not predefined by the groups S, T, X, Y, or Z."

IEC 61850-7-4 Ed 2 corrects the sequence of these two words as:
"This node shall be used only to model in a generic way process devices that are not predefined by the groups S, T, X, Y, or Z. If needed, all data objects listed in Clause 6 can be used single or multiple for a dedicated application of LN GGIO. Data objects with proper semantic meaning should be preferred."
This subtle change clarifies that it is only to be used for external physical IO from devices in the process level "real" world that are not already represented by another LN semantic. 

Hence even if there is an electromechanical relay with a contact output connected as an input to an IED, that input must not be represented by any GGIO, but must be represented as one of the Pxxx.Op Data Objects. 

Where such mappings of GOOSE between two Logical Nodes have been forced by the Vendor, Reusable Engineering suffers because, apart from being unnecessary, this mapping is proprietary.  Hence if a different IED was to be installed, the GGIO mapping would need to be re-done.  Hence I have raised this TISSUE http://www.tissues.iec61850.com/tissue.mspx?issueid=864 as a recommendation for improvement of interoperability (being the ability of two functions to communicate with each other without particular vendor specific engineering on the part of the user) by not certifying IEDs where GGIO mapping is mandatory between two Logical Nodes.

Furthermore even correct use of the GGIO can lead to much difficulty in engineering and documentation (What is the meaning of GGIO24343635.Alm12431243124 = True?)
However as indicated in the two further TISSUES I have raised (see below), good engineering solutions on the part of the vendors and the System Integrators can eliminate the need and use of GGIO in deployed systems.
http://www.tissues.iec61850.com/tissue.mspx?issueid=880
http://www.tissues.iec61850.com/tissue.mspx?issueid=900

Click to enlarge

Copy this short permanent link to this page: https://rhconsult.tiny.us/3nyntzdc

Extra Notes: