265   Quality extension

Created: 29 Nov 2005

Status: Ballot Period

Part: Part 7-3 (2003)

Links:

Page: 11

Clause: 6.2.1

Paragraph:

Category: Issue for edition 2 of this part

Issue

In the implementation guideline for IEC 61850-9-2, the quality specification was extended with a new element "derived". This is used to indicate, if the value is a value that is directly based on process information, or if it is derived from several other process information. There are two typical applications for this:
(1) as used in the implementation guideline: As an example, the current of phase neutral can either be measured (i.e. derived=FALSE) or can be calculated based on the three phase currents (i.e. derived=TRUE).
(2) another example is the example of a combined disconnector - earthing switch. That would be modeled as two logical nodes XSWI - one represneting the disconnector, the other representing the earthing switch. In that case, the position information of these two logical nodes would also be flagged as "derived=TRUE", since it is not directly determined from the process.

Proposal

extend the quality definition as proposed.

Discussion Created Status
Editor meeting - Zug
The derived property is a configuration property and not a dynamic property.
It is already available via SCL using the attribute virtual in the equipment definition.
No aditional bit is necessary in the quality bit.
An additional DataObject (SPG) in the interfacing logical nodes could be used/defined in 7-4 in order to provide the information in online modus of the MU.
03 Mar 10 Ballot Period
I agree fully - however there is a subtle difference between a neutral current measured, and one calculated from the phase currents - especially in case of a fault (Example 1 below). But this difference has nothing to do with the value quality as such, just with the way you got the result, i.e. the 'calculation method'. By the way, this special example should meantime be solved in 7-3 by having attribute neut for the measured value, and res for the calculated one.... Example 2 would better be solved by having a common EEName value for all XSWI instances. 26 Jun 08 Discussion (red)
Whatever is the value provided by the process it provides it on its own.
The fact it is a measured value or a calculated (derived) value has no relation with the quality or anything, even you do not know about. It is purely a vendor implementation feature and a local issue. 		26 Jun 08 Discussion (red)
Just as an element for discussion and engaging only my own opinion, I feel "derived" implementation is not utterly in the scope of the "quality", but rather on the process' duty.
The way the process delivers a value for a data is on its own, and the calculation of the associated quality bit as well.
Not anything prohibits the process to calculate a "derived quality" combining the internal quality items used for the "derived value" calculation, using only the already existing quality bits.
The fact the Server wants the Client to know about the value is "derived" or not, seems to be more like an extension attribute than of the nature of a quality of the attribute.
The fact "derived" has been put in guideline for IEC 61850-9-2 may indicate I am wrong! 		14 Aug 07 Discussion (red)
Derived is definitly not comparable to a substitution. A substitution takes place, when normally a process value is available, but for some reason, it is temporarly not available and a substituted value is provided.

Derived is used, when a value is never available directly from the process, but when it is calculated based on other process values.

As mentioned, the topic shall be discussed during the next meeting. The proposed approach from Wolfgang, to use the calculation method and a reference to tha calculation source can be a alternate solution; but in that case, it must be possible to refer to more than one source LN! 		09 Aug 07 Discussion (red)
As Wolfgang I am not in favor of changing quality bits.
I think this "derived" does not intend to reflect a quality, but a value substitution; thus the "substitute" value of source bit shall be used. 		09 Aug 07 Discussion (red)
TISSUE has been reopened during WG10 meeting in Seoul. Unfortunatly, the progress in the WG 19 concerning harmonization of quality codes is not yet at the point to have produced useful results.

The proposed solution can create backwards compatibility issues with regard to the interpretation of the received quality bitstring in old clients.

Conclusion is, to discuss the TISSUE at the next WG meeting in September 2007. 		21 Apr 07 Discussion (red)
TISSUE currently on hold; will be finally solved within Edition 2 and in the context of harmonisation of quality codes 27 Mar 06 Future Improvement
Editor meeting December 11, 2005
The proposed change shall only apply for Edition 2 of the standard and shall be considered as well in the context of the harmonisation of quality codes discussed in WG19.
In the meantime, the bit 13 shall be considered as reserved for 8-1 mapping and it can be used in the 9-2 mapping. 		11 Dec 05 Discussion (red)
I fully agree with Christoph proposal.

This identifier will be used for time critical SV exchange between sensors and protections. In that context the derived indication could be considered as an ‘online’ indication. There is no time left for a relay to initiate a slow client / server exchange to determine the good algorithm to use with each merging unit.

There is only 12 bits defined in quality, I think there is enough space to add a single derived bit.
30 Nov 05 Discussion (red)
I am against adding new quality bits. The meaning of quality bits is to show an 'online' state. If a value is calculated or not, does not change 'online', but only by configuration. For this we have already some methods to indicate: the 'virtual' tag in SCL shows if a primary equipment (e.g. CT in Example 1) is real or virtual, where the last means that any values attached to it are somehow derived.
Further, we currently introduce data calculated by some calculation method, meant mainly for statictical calculations. This could be another way to show that a value is calculated per configuration, which allows even to link to the data sources and specify the calculation algorithm. 		30 Nov 05 Discussion (red)
I am in favor of the proposal. The following text shall be added as clause 6.2.6:

derived

This identifier shall be set to FALSE, if the value is based on a real sensor in the process (optionally including some additional calculations behind, e.g. for a RMS calculation). If the identifier is set to TRUE, it is meant that there is no physical sensor within the system to determine the value, but the value is derived from a combination of values from other physical sensors.

EXAMPLE 1 – There may be a CT used to measure the neutral current. In that case, the identifier derived shall be set to FALSE. If the neutral current is calculated from the phase values, the identifier shall be set to TRUE.

EXAMPLE 2 – A disconnector and an earthing switch may be combined to one physical switch having multiple positions. In that case, the position values for the disconnector and the earting switch – each modeled in a logical node XSWI – would have the identifier derived set to TRUE.
29 Nov 05 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1