Here was the outcome of this investigation:
Apply CFG-3 phasor magnitude scaling factor to phasor values by StephenCWills · Pull Request #160 · GridProtectionAlliance/gsf (github.com)
I have copied the relevant conversion below for convenience.
Note that all GPA synchrophasor applications, e.g., openPDC, SIEGate, openHistorian, etc., handle these values properly. However, the PMU Connection Tester does not show the scaled CFG3 values in real-time.
We are considering an update for these real-time displays and have added the scaled values for visualization in the “Protocol Specific” tab for detailed frame analysis.
Thanks,
Ritchie
I have reviewed this. The implementation for the IEEE C37.118.2-2011 configuration frame 3 (CFG3) adjustments all properly exist - however, they were all implemented as adder / multiplier adjustments to mapped device input measurements when device configuration is translated to the host application. I’ll describe the thinking here that occurred during implementation and reading through the updated standard.
For the CFG3 the phasor magnitude now has a multiplier, and the phasor angle now has an adder. The first consideration is that if the input coordinates are rectangular, you must convert to polar before application of these linear adjustments. Another consideration was the fact that if the current mode was floating point, instead of scaled integer, the values must default to 1.0 and 0.0 respectively. This differed from the original configuration frame 2 (CFG2) which has a similar notion with a conversion factor for phasors, but the conversion factor was for scaled integer only, i.e., the conversion factor value was ignored for floating point in CFG2. Also, when the mode was for integer scaled rectangular values, the conversion factor was applied a for a consistent range of -32,767 to +32,767 where the signed 16-bit integer minimum value of -32,768 is used to indicate missing data. However, when the mode was for integer scaled polar values, the magnitude had a range of 0 to 65,535 (unsigned 16-bit integer) and the angle, in radians only, fixed scale of 10 to the 4th, range of –31,416 to +31,416 (signed 16-bit int).
With this fixed logic for the conversion factor, which is applied in the base phase class, I did not want to change how the CFG2 conversion factor operated, leaving everything there in place as it had always worked. In addition to CFG3 having a new phasor magnitude multiplier and phase angle adder, analog values also now have a multiplier and adder for linear value adjustment. Since the time-series implementations of the Grid Solutions Framework have always included linear value adjustment options, I considered this a viable option for application of these scaling adjustments. That is, instead of applying the adjustment to the values before they left the synchrophasor API, we could leave this as a linear adjustment applied at a higher-level during configuration mappings. The implication here is that any CFG3 real-time values being displayed directly from the synchrophasor API, e.g., raw values on display in the PMU Connection Tester, might need to be adjusted manually for user convenience (which has not happened).
Although I realized during development that leaving outgoing values from CFG3 implementations from the synchrophasor API unscaled was a slight behavioral deviation exception as compared to CFG2, there was much more CFG3 data that affected host mapped configuration for metadata that needed to be considered. This new extended metadata in the CFG3 includes a pre-defined device GUID, longitude, latitude, elevation, phase type (A, B, C, +, -, 0), various new bit flags indicating any changes applied to source values (like up sampling, down sampling, filtering, adjustments, etc.), service class, window length and group delay. With this much metadata churn in host application needing management and implementation, the addition of an adder and multiplier to metadata., which applies all adjustments to the host application as needed, just seemed like a logical / simple addition.
Although whether the implementation for the new CFG3 adder / multiplier scalars should be handled in the synchrophasor API or handled through host metadata is debatable – and we can certainly change the implementation in the future if deemed desirable – today this is handled through host application metadata. What follows is a technical implementation summary of how the CFG3 code was implemented and some reasonings that were considered during development:
For the PhasorDefintion3 class, the scale and offset values are translated on the device measurement mapping to be standard Measurement.Adder / Measurement.Multiplier values. Since phasor values are “visualized” in real-time in the PMU Connection Tester, we may want to show the scaled adjustment there for user convenience, however, this does not affect any time-series host application showing the value since UI’s consistently use the Measurement.AdjustedValue which applies any linear scaling.
In this PR I went ahead and added scaled angle / magnitude values that will visualize when the associated definition is PhasorDefintion3 and the user selects the “Protocol Specific” tab in the PMU Connection Tester.
For the AnalogDefinition3 class, as with the phasor values, the scale and offset values are translated on device measurement mapping to be standard Measurement.Adder / Measurement.Multipler values. Currently the only way to visualize Analogs in the PMU Connection Tester is from the “Protocol Specific” tab and opening a DataCell.
In this PR, I went ahead and added an “analog value scaled” property that will visualize when the associated definition is AnalogDefintion3 and the user selects the “Protocol Specific” tab in the PMU Connection Tester.
For the DigitalDefinition3 class, the normal and current valid inputs are just bits that an application can use to determine to determine if current digital value is normal and/or currently valid. Future UIs that show digital value states, or adapters using digital values as inputs, should take this into account - but the bits do not directly affect source value. Also, “Protocol Specific” details on these values from the definition already exist and can been seen from the PMU Connection Tester when the associated definition is a DigitalDefiniton3.
In the original PR, overriding the ConversionFactor property to match the MagnitudeMultipler does make the phasor magnitude value come out properly in the synchrophasor API for scaled integer values. However, the new AngleAdder would need to be added as well – and this does not have a simple application in the PhasorDefinitionBase class for override. I think this would need custom application in the IEEEC37_118.PhasorValue class. Additionally, if adders and multipliers are ever applied consistently at the synchrophasor API level, then adjustments would need to be made to the analog implementation as well. Plus, all the existing time-series CFG3 metadata adjustments for adders and multipliers would need to be removed. For now, this ConversionFactor override has been removed so that the adjustment will not be applied twice.