475   Specialisation of data by use of the number extension

Created: 07 Mar 2007

Status: In Force (green)

Part: Part 7-4 (2003)

Links:

Page: 92

Clause: Annex A.3

Paragraph: all

Category: Issue for edition 2 of this part

Issue

There is a tendency to resolve the issue of missing data by duplicating existing ones, e.g EEHealth1, EEHealth2, ...

This will lead to a loss of semantics, thus cannibalizing a central aspect of IEC 61850.
Also, since implementations have to be aware of this scheme in any place, either the resource requirements for servers will increase or the performance of the servers may degrade.

The current main usage of the number extension is for data in GGIOs, where we have no semantics anyway.

Proposal

Emphasize on the indended use of the number extension (e.g. GGIOs) and limit it to that.
Recommend the extension of LNs with explicitly named custom data and the usage of name spaces (according to Annex A.6).

Discussion Created Status
solution in edition 2 17 Feb 10 In Force (green)
In the CDV of IEC 61850-7-1 (14.4.) is stated that data objects with no number extension in the model of part 7-4 shall not be extended. For all data objects where an extension "1" is given could be extended. 24 Jun 08 Ballot Period
I believe that 7-4 (ED2) is very explicit that only GGIO and GAPC have the multiple data attribute extension ability. The statement is specific in their respective clauses.

I agree that only optional attributes should have this capability and that the text should be changed to reflect this.

I also believe GSAL should have a similar statement. 		08 Jan 08 Ballot Period
Mandatory data are not extentible by numbering. Only optional ones.
See draft edition 2. 		24 May 07 Ballot Period
There is no general rule when the data will be extented by numbering (e.g. EEHealth1, EEHealth2,..) the orignal data (e.g. EEHealth) is the summary. This is a local issue.
Tissue #320: is there a rule if we could use the original data without number when extension is modelled?
I agree the semantic of the different data can be defined in the description field.
Semantic, numbering and use can be decribed in the SCL-file. 		10 Apr 07 Discussion (red)
I comment on the HV-CB alarms in the previous comment.

I agree, that there may be several warnings and alarms for HV CBs. Taking the example from the comment, we will have all the information listed as data of e.g. the common data class SPS (note that CB-N2-warning and CB-N2-alarm could as well be one data of the CDC INS with values "green", "yellow", "red", similar to EEHEalth):
- CB-heating-alarm (see tissue 477)
- CB-motor-alarm
- CB-N2-warning
- CB-N2-alarm
- CB-hydraulic-oil-alarm
- CB-pole-discrepancy-trip
In the descriptiona attribute d a short description of the semantic for that alarm can be provided.

The value of these data will have an impact on the EEHealth data (since EEHealth is the summary information about the behavior of the XCBR) for that LN XCBR (e.g., with CB-N2-alarm active, EEHEalth would get the value "red").

We may discuss, if we shall standardise these data or not. When we defined the standard, the experts form the switchgear manufacturers come to the conclusion, that this should not be standardised, since any kind of circuit breaker has diferent values that are supervised. The important information for the operation of the circuit breaker is the EEHealth, which is the summary information and tells, whether the circuit breaker may be operated or not. The details shall be modeled as equipment (vendor) specific extensions, using the d attribute to provide information about the detailed semantic. 		09 Apr 07 Discussion (red)
Like shown in the DKE GAK 15 modelling example the number extentions for EEHealth are used to model the different auxilliary circuit supervisions: DC1, DC2, AC1, AC2, AC3, ... in ZAXN. I agree that another data (that is currently not in the standard) may be a better solution. A worse solution would be to model a single Logical Node ZAXN for every single auxiliary circuit with all the redundant overhead information like Mode, Behaviour, Nameplate,...

Another example for multiple instances of EEHealth is the modelling of detailled health information, where related data in the standard is missing, for example for circuit breakers:

For every HV-CB:
- CB-heating-alarm (see tissue 477)
- CB-motor-alarm

For HV-CBs with hydraulic drive:
- CB-N2-warning
- CB-N2-alarm
- CB-hydraulic-oil-alarm
- CB-pole-discrepancy-trip

(These are all convetional alarms that have nothing to do with monitoring.)

I would like to find all needed information as standardised data instead of multiple instances of other data like EEHealth. But if these standardised data is missing there are only two possibilities:
1. number extensions or
2. new private data

I recommend not to try modelling the information by the use of some multiple instances of Logical Nodes or new Logical Nodes. This would blow up the model and move farther away from the practical process. 		03 Apr 07 Discussion (red)
I do not really see many applications, where extensions by numbering are required - at least not for data related to the operation. When would you use extension by instantiation of data and when extension by instantiating multiple logical nodes?

The example of a need to instantiate EEHealth data is obviously based on a misunderstanding of the specification. EEHealth is a summary information of the health of the equipment behind that logical node, where I do not see a reason, why I should have two of them. The details are user-specific, but not the summary information. There may be hundreds of user-specific sensors that supervise e.g. any elements of a circuit breaker; these sensors may have alarm data Alm, and you may call them Alm1, Alm2, etc or TrCoilAlm, HydrAlm or whatever. In the description attribute of that data, you can explain the nature of that Alarm. But all these alarms are summarized in EEHealth. And there can be only one EEHealth, because a circuit breaker has only one global Health.

I agree that it may be possible, to instantiate TmpAlm in a SIML twice, if one liquid insulation supervision has two temperature sensors. The question however could be here as well, if we should not focus the liquid level supervision to the liquid level, and add two of the from WG18 proposed logical nodes for temperature sensors. 		18 Mar 07 Discussion (red)
In my understanding creating private data is the worst way to model missing data, because only the vendor's IED who created this private data. Better is to standardize more and consistent data. We do so for Ed.2. But between Ed2 and Ed3 is the next long period, so I see the need to extent data by numbering them (not only for GGIO).
I support Wolfgang's and Jochen's comment. 		16 Mar 07 Discussion (red)
I support Jochens argument. using a 'numbered' DATA name gives at least a part of the intended semantics in standardized form, while a private data is only privately understandable. However, if common need arises, more DATA should be standardized. 09 Mar 07 Discussion (red)
Fact is, that the standardised data classes are often not complete to model a real project. So there is the need for additional data. Currently there are in general two possibilities to do that:

1. Use the standardised classes and add number extensions
2. Create new private class names

If the number extensions are limited to GGIO, this would blow up the use of GGIOs instead of the LNs that should be used instead. For example the LNs ZAXN, SIMG, SIML and many others are only usable, if data like EEHealth, Tmp, TmpAlm,... can be instanciated multiple times. One instance is mostly not enaugh. On the other hand it is nearly impossible to standardise all possibilities of EEHealth-messages, because they are user-specific.

I propose not to limit the number extensions to GGIO, but to add in general new data classes to the model, that minimize the need for number extensions.
09 Mar 07 Triage

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1