This states that in the scenario some external non-61850 device without an appropriate LN model "not predefined by the groups S, T, X, Y, or Z" and needs to be represented in the SCL, this would currently be the CORRECT USE of GGIO (did I actually say that GGIO does have a useful purpose??? ..... but read on ....)
However now we have Namespace possibilities to create private LNs
In this scenario it is possible to define your own LN name under your own Namespace - so a push button input for example could be named SBUT with SBUT.Alm1 and hence have more meaningful semantics than GGIO24343635.Alm12431243124
So can we see the end of GGIO???
Proposal
Add an extra sentence to the first para as follows:
"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. However it is recommended that wherever possible "proprietary LNs" are created for these requirements with appropriate semantics under a proprietary NameSpace (IEC 61850-7-1 Ed1 Cl 14) with the requirement that the IED Configurator allows Systems Integrators to be able to rename generic GGIO accordingly. If needed, ......
Discussion
Created
Status
Decision confirmed. Efforts will be started in WG10.
08 Mar 13
In Force (green)
WG10 editors confirm the need to improve the description reg. the use of GGIO. That will be an issue for edition 3 of part 7-4.
07 Feb 13
Ballot Period
I agree with Henry. If a manufacturer provides generic IO, GGIO is the only way to make it accessable, as its purpose is not known at this stage. If the purpose is known but currently not standardized, manufacturer / customer extensions can be used. The critical issue here is: shall we force that an IED / IED tool allows to override its basic model (GGIO / GAPC) with a model supplied by the system configurator? What are the limits / minimum requirements (CDC change from two SPS to DPS)? This needs some rules how to do this, and may lead to more costly (low cost) IEDs.
24 Aug 12
Future Improvement
I fully agree with the proposal to re-visit the GGIO-issue.
Here are some brief comments:
1. We should not talk about "private" models – we can extend the models -> we get extended models (which may be defined by a person, a company, a country, users-group, other standardization group, …).
Private means: nobody outside can understand the definition! Our extended models allow to define the syntax and semantic very precisely - so that everybody can understand it.
2. We should implement a mechanism to allow to publish private namespaces on the IEC or UCAIUG website (if the owner agrees). This would allow to re-use reasonable extended models ... and we can decide later to add them into the IEC "catalog" of LNs and DOs.
3. We should come up with a public available description HOW to build extended models.
4. Before people build extended models they should have a possibility to check which models are available !! This is an issue for the webbased access to the models ... hopefully available by end of 2012 !!