164   Deadband on range limits

This tissue has following status: green

Created: 12 May 2005

Links:

Page: 17

Clause:

Paragraph: 6.5

Category: Issue for edition 2 of this part

Issue: rangeConfig defines ranges by means of limits as a means to calculate a range value. For the range to be accurate it should be based on an instantaneous value. In this case however an oscillation around a limit value might lead to a flood of range value changes.

Proposal: Add an optional limit hysteresis attribute limDb to rangeConfig as dead band value for the range value at a limit in that sense, that if a high limit is crossed, the range is reset to the lower value only if the instantaneous value is below the limit-limDb (on low limit: above limit+limDb).

Discussion Created Status
?
Ballot until Editor
set to green 12 Aug 05 green
Sent out for ballot 14 Jun 05 final proposal July 13, 2005
The final proposal is as follows:
A new optional component limDb will be added to the common data attribute type RangeConfig (Range Configuration). Attribute type: INT32U, value range 0 ... 100 000. The value is interpreted like db or zeroDb as a percentage value representing the percentage beetween max and min in 0.001%. The value is used to introduce a hysteresis in the calculation of range. Range is immediatly set to the higher value, when a high limit has been crossed (to the lower value, when a low limit has been crossed). However, range is only set back to the lower value, when the value of the high limit minus limDb has been crossed (to the higher value when the value of the low limit plus limDb has been crossed).
13 Jun 05 red
Christoph's suggestion with zeroDb is like mine for db. db is a filter around the last sent value (+-), zeroDb is a filter around zero (+-), and limHys is a filter around a limit (+ or -), which belongs to rangeConfig. In existing SCADA systems all three exist. The question: could in SA systems all three be reduced to one or two values? As long as nobody has experience/justification, we should take all three (optional) attributes. If at all, db and zeroDb could be one (+-) value... 17 May 05 red
With regard to Wolfgangs proposal: would it be possible to use zeroDb configuration parameter? The application there is in that way similar, that we want to supress the impact of noise, so the required value might be similar.

With regard to Herbs comment: Please be aware that we are not dicussing deadbanded change, but we are discussing range change. And the issue is, when our actual value is close to the range and with the noise of the value range changes would be reported. With a filter mechanism using the time, we would reduce the number of range changes, but we still may have some of them. The proposal from Wolfgang solves the problem by making the ranges a little bit less "narrow" ore more "inaccurate" (similar to what we are doing with the zeroDb). I have the feeling that this is closer to what we want to achieve.
12 May 05 red
The proposed type of hysteresis could lead to no reports at all. A better mechanism might be to have a configuration that specifies the amount of time beyond deadband before a dbchg is indicated. Another mechanism that might also augment this is the number of crossings within that period of time.

The use of these two types of parameters would allow a must better characterization of the hysteresis. Additionally, it would allow dbchg to be detected if there are multiple transitions over/under the deadband values in a short period of time.
12 May 05 red
In principle a measurand db value for a filtered measurand can be taken instead of a new configuration parameter. However, as the measurand db is used to tune background load, and might even dynamically be changed in certain situations where high accuracy is needed, it should functionwise be separated from the limit hysteresis. Suggestion: accept the proposal. 12 May 05 red

 

Privacy | Contact | Disclaimer