There is much argument and variation of the use of GGIO. This generally stems from certain vendors insisting that all incoming signals to a device are mapped through GGIO.
The start of modelling is in Part 5. It says clearly in 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…)."
This is clearly telling us this is some sort of interface LN between the physical world and the virtual world which has not been defined in the other LNs.
It certainly does not give scope for it being used as a proxy in a virtual-to-virtual world.
It seems evident that GGIO is not foreseen [allowed] to represent anything to do with a Pxxx LN for a start.
As for the XCBR end, well, we already have an XCBR which models the CB so again by definition GGIO is not foreseen [allowed] to act as a 'proxy' for an XCBR signal.
If we then jump to Part 7-4, it clearly says under 5.7.3:
"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.""
Note the use of the words "only" and "process devices" - again it is not allowed to represent a Panything. And again it must not be used as a proxy for a XCBR since that is already defined.
Since GGIO is clearly stated as an interface to the process world, it cannot appear in the signal flow between two LNs.
So in theory if a vendor makes GGIO a mandatory requirement in the signal flow between 2 LNs example between PTRC and XCBR, it could well be argued that they should not be granted compliance (IMHO). Unfortunately the certification process doesn't assess the "appropriateness" of the choice of LNs or how the comms maps the signal flow between them.
Proposal
Include a compliance assessment criteria for allowing direct mapping from external LNs to the internal LN InRefs without use of GGIO being a pass, and requiring GGIO as a fail.
Discussion
Created
Status
To be discussed at WG10 in Houston
23 Oct 12
Future Improvement
Can this TISSUE be changed to Green Status? Or is it Yellow and need resolution at WG10 next week?
There seems to be agreement that the forced mapping of Data Set elements (i.e. as messages between Logical Nodes) through GGIO is against the principles of interoperability.
It therefore seems that it should be accepted that Part 10 be modified to include a certification step to verify that GGIO is not required for mapping GOOSE into or out of an IED. Where such requirements are found to exist, Compliance Certification to 7-4Ed2 should be refused.
-------- I was asked to clarify a use case where GGIO affects interoperability and therefore is a concern for product certification as an indication that the IEDs may be able to be used interoperably. Interoperability is a property of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation. (http://en.wikipedia.org/wiki/Interoperability) A simplified example of loss of interoperability is an InRef to XCBR in IED2 subscribing to a PTRC.Tr from IED1. The forced mapping via GGIO leads to this situation: 1. IED1 has PTRC.Tr mapped to GGIO55.Alm72 2. IED1 creates DataSet1, Element5 = GGIO55.Alm72 and sends GOOSE1 3. IED2 subscribes to GOOSE1 4. IED2 maps DataSet1, Element5 to InRef for GGIO921.Alm46 5. IED2 has GGIO921.Alm46 mapped as the InRef to XCBR
If a different vendor’s IED is used, there may or may not be a GGIO requirement and the actual instance number of the GGIO and/or instance number of the Alm Data Object may be different. Any of these would require re-engineering of the communication chain which need only have been XCBR InRef directly subscribing to the PTRC.Tr
23 Oct 12
Triage
1.Modelling with generic is clearly restricted by the part 7-4 Ed2
1.1 GAPC: This node shall be used only (!) to model in a generic way the processing/automation of functions that are not predefined by one of the groups A, C, M, P, or R.
1.2 GGIO: 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.
1.3 This modelling approach is clearly visualized in Fig.7 and Fig.8 of part 5Ed1 which will be the same in part 5Ed2.
2. The services have to follow the model and are not allowed to change the modelling.
2.1 In part 7-2Ed2 Clause 13.1 it is written "A data-set is an ordered group of ObjectReferences". This is valid als for the GOOSE data sets. Therefore, there is no need to introduce GGIOs for GOOSE messaging only.
2.2 All data sets are described by SCL
3. Since the value of IEC 61850 is mainly in his high level semantics, which simplifies by the way any system engineering, the proposoal of Rod regarding conformance testing should be considered. Nevertheless, remember that we have opened a creative platform for modelling in the informative parts part 7-500 repectively in 7-5xx being in progress.
07 Aug 12
Triage
For GOOSE publishing, it's well understood that GGIO is not a good choice since it lost all the semantics which is one of the pillar of IEC 61850.
For GOOSE subscription however there used to be confusion that whether GOOSE subscription shall be modelled with GGIO. The decision finally is using either InRef(ExRef), or private SCL, because GOOSE subscription and internal mapping is LOCAL issue which doesn't needed to be exposed to the network anyway. But, it actually clear the air for IED vendors as well, and help (3rd party) software vendors if the standard could (at least) recommend explicitely even though the standard does not intend to cover local issues.
Thus, I agree with Rodney that to include a compliance assessment criteria, using GGIO for GOOSE publishing is not recommended, for GOOSE subscription/mapping to internal signals is a fail.
31 Jul 12
Triage
IEDs forcing users to use (exclusively) GGIOs in order to configure GOOSE signals make every reasonable IEC6815 System design obsolete This justifies the ENTSOE statement to its full extend. WG10 should react stronger than just plea to vendors to follow the standards spirit.
28 Jul 12
Triage
I disagree with the statement from Bruce, that GGIO has traditionally been allowed in Edition 1 devices. The right statement would be that GGIO has been traditionally used by vendors in Edition 1 devices, making these devices in reality non compliant to IEC 61850-7-4, Ed 1, chapter A.1.1. Unfortunatly, with Edition 1, conformance to IEC 61850-7-4 was never verified. If this can be improved with Edition 2, it will be a sigbificant benefit to the market and the usage of IEC 61850.
28 Jul 12
Triage
Just to clarify. In 7-4 Edition 1 it said "device processes" In 7-4 Edition 2 it says "process devices" - a subtle but VERY important difference that is the basis of my TISSUE.
At this stage we do not have a Part 10 Edition 2 but this TISSUE should still apply for vendors claiming IEDs comply to 7-4 Ed2. I am led to believe that this 'vendor-forced' use of GGIO in ALL signal flow is one of the biggest issues affecting the potential for tools to be able to produce vendor-independant SSD and SCD files that can be the basis of Reusable Engineering. We can't continue to have to cater for different ways that for example a FdrPTOC.St blocks an upstream IncPTOC If GGIO continues to be allowed to be forced by the vendor to be involved we have the potential that one vendors requirement is: IncPTOC has BlkRef = GGIO63425.Alm whilst another vendor requires IncPTOC has BlkRef = GGIO1.Alm92387 a) there is no semantics and b) it changes with every different IED type, potentially at either end if fixed datasets are involved.
Conceptually there is no advantage in using the GGIO compared to the obvious intent of the Standard that it should be simply IncPTOC BlkRef = FdrPTOC.Str This is clearly vendor-independent and Reusable Engineering! I believe/suspect the change in 7-4 Ed2 specifically deals with this issue (intentionally or not) and so conformance compliance must reflect this.
An additional [controversial but important] question is whether any vendors who have been granted compliance to 7-4Ed2 but force use of GGIO in this way should have the certification revoked?
28 Jul 12
Triage
There is a mis-quote from teh requestor from 61850-7-4. The standard does NOT specify "... model in a generic way process devices ...", the words are "... model in a generic way device processes ...". This is a major difference in context.
Use of GGIO has traditionally been allowed in Edition 1 devices. All of the major device manufacturers have somehow managed to interoperate even when signals from GGIO are used.
Some devices are designed to intercept subscribed GOOSE messages and re-cast them as GGIO signals (for example, analog values with limits defined by the subscriber are converted to binary signals in GGIO).
I see no reason for any action at this time except perhaps for a plea to vendors to make stronger attempts at following the "spirit" of the standard.