This project has moved. For the latest updates, please go here.

Range Alarms on Phase Angles (VPHA/IPHA)

Sep 13, 2013 at 6:16 PM
I have had high/low alarms on phase angle measurements, with the setpoints of 180, -180 respectively (hysteresis = 18). This (I believe) used to work. But now I am getting alarms for high values (GREATER THAN 180), but the ValueWhenRaised are all negative. Is there now some wrapping logic interfering with my alarms? Or...
Sep 13, 2013 at 7:12 PM
Yes, we modified the AdjustedValue property of phasor measurements so that it would wrap to the -180 to 180 range for phase angles. It seems that the alarming engine is using the Value property, rather than the AdjustedValue property, to query a measurement's value for testing. So the actual value of the measurement is outside of your specified range, but the value displayed on the Manager is the AdjustedValue which is wrapped.

It seems to me that it may be useful to define alarms that can be tested against AdjustedValue as well. At the very least, ValueWhenRaised should match the value it tested. Thoughts?

Sep 13, 2013 at 7:53 PM
As it is, range testing phase angles seems impossible; what are the unwrapped SetPoints for the min/max tests? and yes, ValueWhenRaised must match the value tested, but I'd prefer that ValueWhenRaised should match the wrapped value that is displayed, and then tested.

Patrick Pentz
Sep 13, 2013 at 8:04 PM
I suppose that my real question is what a work-around might be in this case, without waiting for a patch to openPDC v1.5 SP1. Is there such a work-around, or should I simply disable all phase angle range alarms?

My particular problem is that I put a history of the alarms into the database, and these alarms are raised and cleared over and over; thus my tables require constant purging. If I were to put the alarm measurements into the PPA historian (currently I'm using a Virtual historian), would this provide a similar historical store of alarms?
Sep 13, 2013 at 8:22 PM
Edited Sep 13, 2013 at 8:24 PM
Maybe I'm confused. The value that is range tested should be the original value of the measurement. The value that is displayed should be the wrapped value. Therefore, the behavior you're describing (alarms raising and clearing constantly) should not have changed as a result of the wrapping logic. The only thing that should have changed is ValueWhenRaised, which should now be wrapped to the -180 to 180 range.

I don't see the point of defining alarms to range test angles at all, unless your goal is to test the original value to determine whether the device that transmitted the measurement is properly providing a value within a specified range. So my first question to you would be, what are you attempting to accomplish by defining range tests for wrapped angles?

As for your second question, the answer is yes. Putting alarm measurements into the PPA historian will archive them alongside all your other measurements. Their values will be either 1 for raised or 0 for cleared. The notion was to be able to store the alarms along with the measurements being tested, then correlate the timestamps to determine what the value was when the alarm was raised or cleared.

Sep 13, 2013 at 8:34 PM
the point of the alarms is just that: to ensure that the devices are sending valid data. A worry is that field engineers might incorrectly wire the measuring devices; we have seen this in the past. All of our alarms for for this and similar purposes: to see if the data arriving is reasonable, and in some cases we do more complex tests when measurements have related constraints, such as that between frequency deviation against phase angle slope. The simple range test for phase angles wasn't one of the important ones, but the change in behavior was a surprise.

As for the raising and clearing of phase angle range alarms, I am certainly seeing this recently. Are you implying that my current alarms should work as I expected, except for the unexpected ValueWhenRaised?

Sep 13, 2013 at 8:59 PM
Yes, that would be my expectation. I can't say for sure because ValueWhenRaised is not going to be very useful so long as it's displaying the wrapped angle. The other problem is, as Ritchie just informed me, the value in the historian is also the AdjustedValue. In your case, this is a bad thing because now you won't be able to recover the original value as it was reported by the device unless it happened to already be within the -180 to 180 range.

I do have a solution that does not involve any patching, but it could be a lot of work. The idea would be to write an action adapter that extracts the original, unwrapped value from the phase angle measurements and maps it to a new measurement that preserves the original value. You would have to remap all of your phase angle tests to use the new mapped measurements instead of the ones coming from your input stream. You would also need to add new mapped measurements each time a phase angle is added to your input stream.

The other, quicker option would be a patch that would turn angle wrapping on or off as a global setting in the system. Neither of these sounds ideal, so I'm going to leave it up to you for which solution you prefer. Suggestions are welcome.

Sep 14, 2013 at 12:50 AM
I'm not in favor of any global settings, but perhaps a parameter to the alarm (like those for action adapters), that would control these issues.

In the meantime, I have disabled these alarms, and will see if my masters care.

Sep 16, 2013 at 3:15 PM
The most important tests in my application use the results of two action adapter: one that creates a one second average phase angle from voltage phase angles, and another that creates a one second average of the slope from voltage phase angles. Both of these adapters treat the original signal as a wrapped phase angle, and then unwrap the phase angle (using the sequence of values over one second). The phase angle used (the 'original' value) is that in 'inMeasurement.Value', which you state is 'unwrapped'. However, I must be confused, since you seem to imply that only the AdjustedValue has been changed, and the Value is as before. Hopefully this is true, and my adapters are returning the correct values.
Sep 16, 2013 at 3:33 PM
To be clear, the angle wrapping code is in the AdjustedValue property of ChannelValueMeasurement. As such, it only affects code that retrieves the AdjustedValue property of phase angle measurements that are created by the PhasorMeasurementMapper (most input devices). The Value property should remain unwrapped. Here is the code starting on line 234 of TVA.PhasorProtocols.ChannelValueMeasurement.
        /// <summary>
        /// Gets the adjusted numeric value of this measurement, taking into account the specified <see cref="Adder"/> and <see cref="Multiplier"/> offsets.
        /// </summary>
        /// <remarks>
        /// Note that returned value will be offset by <see cref="Adder"/> and <see cref="Multiplier"/>.
        /// </remarks>
        /// <returns><see cref="Value"/> offset by <see cref="Adder"/> and <see cref="Multiplier"/> (i.e., <c><see cref="Value"/> * <see cref="Multiplier"/> + <see cref="Adder"/></c>).</returns>
        public virtual double AdjustedValue
                double adjustedValue = m_parent.GetCompositeValue(m_valueIndex) * m_multiplier + m_adder;

                // Convert phase angles to the -180 degrees to 180 degrees range
                if (m_parent is PhasorValueBase && m_valueIndex == (int)CompositePhasorValue.Angle)
                    adjustedValue = Angle.FromDegrees(adjustedValue).ToRange(-Math.PI, false).ToDegrees();

                return adjustedValue;
Sep 16, 2013 at 3:37 PM
Also note that when I talk about wrapping angles, I am talking about the act taken by the openPDC of explicitly forcing the angle between the range of -180 to 180. If your angles are always coming into the system between the values of -180 to 180, then the angle wrapping code should have no effect on the value.
Sep 16, 2013 at 4:02 PM
Frankie Zhang stated:

This “wrapping” feature is mostly dealing with the “Adders” to phase angles.

Angles are all wrapped to (-180 to 180 degrees) when they arrive openPDC. Then openPDC puts a user defined “Adder” to the value to become “Adjusted Value”. So, even in earlier versions, it was still “wrapped” but only became (-180+adder to 180+adder). Now they puts another wrapping function just to make the “Adjusted Value” back to (-180 to 180).

So, I wouldn’t anticipate any changes to your slope calculation, because they are all wrapped anyway, thus need to be unwrapped anyway. But let’s keep an eye on it.