358   Descrition text for range attribute values (normal, high, low, ...)

Created: 13 Aug 2006

Status: In Force (green)

Part: Part 7-3 (2003)

Links:

Page: 28 / 55

Clause: 7.4.2 / 8

Paragraph: Tables 22 and 23 / 48

Category: Issue for edition 2 of this part

Issue

The current range definition provides an enumeration value (normal, high, low, ...).

In the domain of condition monitoring (e.g., IEC TC 88 PT 61400-25-6) there is a need to asign text to these enumerated values, e.g.:

- Good (for normal value)
- Maintenance request (for high value)
- Maintenance demand (for high high value)
- Failure (for high high & reaching Max value)

Where do we want to asign these text? in additional "d" values or just in the SCD file? or not at all?

Proposal

Depends ...

Discussion Created Status
29 May 07 In Force (green)
WG10 Members present at meeting in Seoul conclude that the TISSUE shall not be accepted. (see all the previous comments on that TISSUE)

This is an application issue and independent from substation automation. 		19 Apr 07 Ballot Period
An additional thought on this topic: the range attributes have been intended for a generic range supervision. As soon as a specific functional behavior is behind a supervision function, this function should be modeled in a domain specific logical node. We have many examples for that from substation automation - just to mention two:

The LN PTOC supervises the current to exceed a certain limit. This could as well be modelled with a data for the current and some specific interpretations of ranges normal, high, etc.

The LN SIMG supervises the gas densitiy of an insulating media for its insulating behavior. Again, we could have modeld this using the attribute for the gas density and some specific interpretation of normal, high, etc. We have instead used specific data like InsAlm or InsTrip, etc

So my recommendation would be, to use specific data within LNs as soon as we need to standardise on the semantic meaning of a limit supervision result. 		15 Apr 07 Discussion (red)
For my understanding this is an issue for the HMI devices, not an communication one. A client with HMi functon what receives a data could create a real text. Only if you have applications like web browsers /thin clients in your mind, you need the full text.

We should discuss if IEC61850 should support in the substation automation domain namespace such a function. This should happen within WG10 together with other WGs and TCs. 		15 Sep 06 Discussion (red)
Wolfgang,

That statement may be true for substation AUTOMATION! But there are other domains that want to have this information either online available or - at least - configured with the information model instances.

This is whay we may get many new common data classes: We have the substation AUTOMATION in our scope and may not support requirements from other application. As a result other groups define their own CDCs.

I think that the CDCs in future should be understood and maintained as classes for use in substations and far beyond substation automation. 		14 Aug 06 Discussion (red)
Where is a need to assign a text? This is probably an interpretation of process data at some application, therefore the configuration of this texts is a private issue of this application, and not one of the communication related model. And application standardization is outside the scope of 61850. 14 Aug 06 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.3.6.1