OpenPDC 2.9.315 - FREQ and DF are not automatically created when manually adding a new Device

GPA Products openPDC
1

Hello,
I’m trying to test an openPDC server on a ‘secured’ lan. When I use the ‘Add new device based input’ method to manually create the concentrator, then the PMU attached to it ; and finally add the V+ phasor to this PMU ; only the V+.ang and V+.mag measurements are created but not the .FREQ and .DF ones.
Using PMU connection Tester, I can see that F and DF are included in the flow ; but openPDC do not create the associated measurements as it usually does.

Note that it has worked well for the PMU of the first PDC I declared on it. The issue appears with the second PDC I have created (and all the others I’ve tried).

Would you have an idea of what could be the cause of this issue ?

Regards

2

I think I’ve found the cause :
When I create the PMU Device, because I attach it to the PDC Device I don’t fill in the ‘Protocol’ field (assuming that the protocol is the PDC Device one). If the C37.118 protocol is filled when creating the PMU device ; then it creates the previous missing Measurements.

I’ll do so ; but it could be great if those two measurements could be created even in the case the protocol would only be declared on the PDC device informations …).

Regards

3

Hello !

I have tested this further, and there is indeed a critical point to note when creating new PMU Devices that are linked to a PDC:
When creating a new PMU in the Manager, it is essential to specify the C37.118 protocol BEFORE linking it to the concentrator. If this step is done afterward, the protocol selection field becomes grayed out, leading one to incorrectly assume that it does not need to be specified (since the protocol then defaults to the one declared at the concentrator level). As I mentioned in my previous post, if the protocol is not specifically set for each PMU linked to the concentrator, the creation of the PMU in the Manager does not automatically generate the Frequency and Frequency Derivative measurements. Manually creating these two measurements is not as straightforward as declaring phasors because many more fields need to be filled in manually. This is not a blocking issue in the sense that once you are aware of it, you can pay special attention to it. However, for someone new to OpenPDC, this can raise questions.

Hope this can help,

Regards,

Stephane.

4

I hear you. It gets a little tricky since a device can technically be “any” kind of input protocol, like DNP3 or a CSV file reader - in these cases you would not need default frequency / dF/dt measurements.

However, I think an assumption could be made that if you are picking a parent PDC device, it could assume the protocol of its parent, which might alleviate this issue. I’ll see if we can get this added as an update.

We do not often find the use case of manually creating PMU definitions, most people use the wizard that reads and parses the configuration frame, so these manual operations are not as likely to get as much testing as the wizard might.

Note that in the case of frequencies (FREQ), dF/dt values (DFDT), status flags (FLAG), quality flags (QUAL), analogs (ALOG) and digitals (DIGI) - each of these would need to mapped to a device specific measurement, manually created if needed - as only the frequency and dF/dt are created automatically with a synchrophasor protocol selection - with an appropriate associated SignalReference field for proper parsing. Here are some examples:

PointTag SignalReference SignalTypeID
TVA_SHELBY:ABBS SHELBY-SF 8
TVA_SHELBY:ABBF SHELBY-FQ 5
TVA_SHELBY:ABBD1 SHELBY-DV1 9
TVA_SHELBY:ABBDF SHELBY-DF 6
TVA_SHELBY-BUS1:ABBV SHELBY-PM1 3
TVA_SHELBY-BUS1:ABBVH SHELBY-PA1 4
TVA_SHELBY-BUS2:ABBV SHELBY-PM2 3
TVA_SHELBY-BUS2:ABBVH SHELBY-PA2 4
TVA_SHELBY-CORD:ABBI SHELBY-PM3 1
TVA_SHELBY-CORD:ABBIH SHELBY-PA3 2
TVA_SHELBY-DELL:ABBI SHELBY-PM4 1
TVA_SHELBY-DELL:ABBIH SHELBY-PA4 2
TVA_SHELBY-LAGO:ABBI SHELBY-PM5 1
TVA_SHELBY-LAGO:ABBIH SHELBY-PA5 2

The SignalReference field is what “maps” a measurement to an IEEE C37.118 data frame. The suffix of the SignalReference identifies the data type and optional “order” of the value in the data frame.

See the documentation: openPDC/Source/Documentation/wiki/Developers_About_the_Signal_Reference.md at master · GridProtectionAlliance/openPDC (github.com)

Thanks!
Ritchie