Eliminating use of GGIO

© Copyright Rod Hughes Consulting Pty Ltd
Rod Hughes Consulting
General Web Site
 
Applications
Home
Innovations and
Solutions Home

A bit about
Rod Hughes
 Link to this page...

The URL in the browser address bar is volatile and may be broken at any time.

To obtain a link to this page, click the <<Share>> button top-right of the screen.

  

Note - if the navigation pane on the left of this window is not visible, click the 2-pane icon on the top bar



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 Cube 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 Cube Controller and its Configuration tool, or any other IED which permits renaming of the GGIO according to the context of the application:



Contact Me

Skype: (ping even if showing offline)

Email Me

A phone call is nearly always welcome depending on the time of night wherever I am in the world.
Based in Adelaide UTC +9:30 hours e.g.

April-SeptemberNoon UK = 2030 Adelaide
October-March:Noon UK = 2230 Adelaide

  Office + 61 8 7127 6357
  Mobile + 61 419 845 253



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:

Disclaimer
No Liability:
Rod Hughes Consulting Pty Ltd accepts no direct nor consequential liability in any manner whatsoever to any party whosoever who may rely on or reference the information contained in these pages.  Information contained in these pages is provided as general reference only without any specific relevance to any particular intended or actual reference to or use of this information. Any person or organisation making reference to or use of this information is at their sole responsibility under their own skill and judgement.

No Waiver, No Licence:
This page is protected by Copyright ©
Beyond referring to the web link of the material and w
hilst the information herein is accessible "via the web", Rod Hughes Consulting Pty Ltd grants no waiver of Copyright nor grants any licence to any extent  to any party in relation to this information for use, copy, storing or redistribution of this material in any form in whole or in part without written consent of Rod Hughes Consulting Pty Ltd.