GGIO Logical Nodes have become the bane of IEC 61850 implementations.  I have raised three TISSUES which defectively mean GGIO should be able to be eliminated from system implementations.  They remain as valid LNs for default configurations of IEDs as supplied by vendors initially prior to any application context for real world interfaces (digital or analogue I/O)

https://iec61850.tissue-db.com/tissue/864 Status: Yellow - pending TC 57 decision

https://iec61850.tissue-db.com/tissue/880  Status: Green - accepted and solved

https://iec61850.tissue-db.com/tissue/900 Status: Green - accepted and solved

#864 Refusing Conformance Certification if GGIO is forced mapping for GOOSE 

GGIO should ONLY be used where a LN is not able to represent a physical real world quantity by definition of LN in Part 7-4 (Ed2)

Ed1 said "This node shall be used to model in a generic way device processes"
Ed2 said "This node shall be used only to model in a generic way process devices"

The term "device processes" in Ed1 could be validly interpreted as sending or receiving a message by any IED.
The term "process devices" in Ed2 clearly refers to the real world interfaces ONLY.
Hence continued use of GGIO for any virtual signals (GOOSE, Reports ..) between devices is non-conformant.

Some vendors insist that all messages are routed in/out of GGIO but this serves no purpose:

This TISSUE would be a dramatic requirement that direct publishing and subscribing is the only mechanism to be permitted in order to prevent problems of interoperability and re-engineering when different vendors products are used. 

However, this should NOT be taken as implying the Standard is directed towards interchangeability - in fact this is specifically not the case as discussed here.

#880 Renaming GGIO for relay contact inputs as 'proxy' Pxxx LN

There are many instances where equipment only provides wire based inputs or outputs but must be interfaced into the IEC 61850 environment.  In some instances these external functions do have equivalent Logical Nodes if the device was IEC 61850.  This includes such items as relay contacts which represent a protection operation otherwise as a Pxxx,Op

Simple modelling of this external function would use a GGIO, but of course this has no semantics relative to the Pxxx function it truly represents. This is an allowed use of GGIO under the restrictions defined in Part 7-4 Ed2 : "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."  i.e. modelling of protection functionality is not excluded.

On the other hand renaming the GGIO as a Pxxx (see below #900) would suggest that certain mandatory Data Objects are available either as part of the specific Pxxx data model or the common LN data objects and/or certain ACSI commands such as SetDataValue.  However some of the implied functionality of finding a Pxxx in the SCL files would therefore possibly not be the case leading to misapplication of the SAS.

It is therefore necessary to be able to indicate where a Pxxx LN is merely a proxy representation of a physical external contact input, and therefore limited data and controls are associated with it.

Using devices such as the SystemCORP CFE-41Cube Controller and its Configuration tool, or any other IED which permits renaming of the GGIO, would resolve the problem of semantics in the applications as below.  The additional 'proxy' Data Object would add clarity during operation, maintenance and future augmentations, refurbishments or replacements of the SAS system

#900 Renaming GGIO with your semantics

GGIO though is a valid Logical Node in its own right - the vendors have no information on what the physical inputs and outputs of their IEDs are going to be connected to so they need a generic Logical Node to be used 'as the IED leaves the factory'. 

Thereafter, the Systems Integrator has to take responsibility for providing meaningful semantics in the engineering process.

GGIO carry no semantics - what is the meaning of:
GGIO453436.Alm167 = true  ?
GGIO453436.Alm432 = true  ?
The use of Namespaces allows the definition of private LNs which CAN carry semantics - the vendors default GGIO needs only to be able to be renamed in devices such as the SystemCORP CFE-41 and its Configuration tool, or any other IED which permits renaming of the GGIO according to the context of the application:

Extra Notes:

Interchangeability is the capability to directly swap two IEDs without any additional engineering effort.

In a system, context this requires many accepts to be supported as a minimum by the new IED, some of which may be handled more easily as a result of IEC 61850.

Refer discussion here: