OpenPDC to OpenPDC communication


#1

Good afternoon,

I am attempting to connect two OpenPDC systems together. The goal is have all PMUs connected to each PDC forwarded to the other. For example PMUs A,B&C are connected to PDC1 and PMUs D,E&F are connected to PDC2. I would like to share PMUs A,B&C with PDC2 and PMUs D,E&F with PDC1. Is this possible and how would I do it?

Thanks in advance for any and all help!

Tyler


#2

Hello Tyler,

Before you begin, go to “Actions > Manage Custom Actions” and uncheck the checkbox in the “Enabled” column in the “INTERNAL!DATAPUBLISHER” row. Make sure to click the checkbox that is in the “Enabled” column, not the checkbox that is explicitly labeled “Enabled”. This will prevent PDCs from connecting to each other during the configuration process as the steps you are about to follow will inherently cause a feedback loop in the middle of the process. It may not be entirely necessary to do this, but it will make the whole process safer.

Here is a document that describes the process to create bi-directional communications between SIEGate and openPDC.

In this scenario, we need to pretend that both of the PDCs are SIEGates connecting to a PDC. In other words, we need to use port 6165 and “Receive Internal Metadata”. In addition, we need to add one additional step to prevent feedback loops when we re-enable the internal data publisher.

After we save the internal subscription and are given the opportunity to fill in more specific details about the connection, modify the connection string to set the “Internal” flag to False. By doing this, the data coming from the other PDC will not be marked as internal and will not be forwarded back to its source.

Connection String:
interface=0.0.0.0; compression=false; autoConnect=true; securityMode=None; server=172.21.4.212:6165; internal=False; receiveInternalMetadata=True; receiveExternalMetadata=False; outputMeasurements={FILTER ActiveMeasurements WHERE Protocol = ‘GatewayTransport’}

After changing the “Internal” flag to false, you can click the “Save” button as it says to do in the instructions. Note that you will not be able to see data flowing because we turned off the internal data publisher so you can simply move on to the next PDC. Once you have finished all the steps for both PDCs, you can go back to the custom actions page and re-enable the data publishers. At this point, both PDCs should begin making connections and exchanging data.

Thanks,
Stephen


#3

Hi Stephen,

Thanks for the answer! I believe this is along the right path of what I am attempting to accomplish. I do run into a few issues with this process though. If I follow the steps outlined in your answer + the guide you linked exactly (i.e. setting the systems to receive internal meta data and internal = False) The systems do not connect. In the run-time statistics for the connection I simply see “False” and no data is being streamed between the two PDCs.

I attempted to remedy this by setting receiveInternalMetadata=False and receiveExternalMetadata=True (as the guide in the link you posted suggests for external facing devices) and I get the same issue.

Any thoughts on what is causing this? Thanks in advance!

Tyler


#4

First, a bit of explanation for internal versus external. The way we are modeling this, on each PDC the data that is coming directly from PMUs will be internal and the data coming from the other PDC will be external. Therefore, when asking for data from another PDC, it’s important to ask only for its internal metadata. We need to make sure NOT to ask it for its external metadata or else we will get our own data back. For this reason, we need to use receiveInternalMetadata=True and receiveExternalMetadata=False.

Next, for connectivity. After following the steps, PDC1 should now have a data subscriber that is connecting to PDC2’s data publisher and vice-versa. It’s worth noting that the openPDC Manager also connects to the data publisher in order to display data and statistics. If you are seeing any values at all in Run-Time Statistics on PDC1, that means PDC1’s data publisher is working. If instead you see a bunch of “–” characters where values are supposed to be, that would mean PDC1’s data publisher is not running.

The first thing I’d like you to verify is whether both data publishers are running. It’s possible that PDC1’s data publisher is running and PDC2’s data publisher is not running, which would show you “False” for the connection in PDC1 and “–” for the connection in PDC2.

If both data publishers are running and displaying the same thing in Run-Time Statistics, then this could be a networking issue. Check that you are using the correct IPs and that there are no firewalls in place between the devices. There may be some errors in the error log that may provide some insight. Open ErrorLog.txt located in the openPDC installation directory and scroll all the way to the bottom for the most recent errors.

Thanks,
Stephen


#5

I confirmed that both publishers are running, I see “False” in the “Subscriber Connected” section and 0’s in everything else. Save the “Subscriber Authenticated” section which also reads “False” on both PDCs. It is likely you are right that this is a networking issue, the error log has the same error over and over again which displays as follows:

"Data subscriber encountered an exception while attempting command channel publisher connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond"

I am on the same network with both PDCs…so a firewall shouldn’t be the issue…

Thanks,
Tyler


#6

That error actually does suggest that there is a firewall blocking the connection. This doesn’t necessarily mean that there is a firewall between the two PDC systems if IPs or routing tables are wrong. However, there is a firewall that exists by default on every Windows system. You may want to check the Windows Firewall on each of the PDC systems. You can open it up by creating an inbound rule to allow connections to either openPDC.exe or TCP port 6165.


#7

This worked perfectly! The PDCs are now connected and I can see a real-time graph of PMUA connected to PDC1 on PDC2. I cannot however use the historian playback utility to generate a file from PDC2 from the data colleceted from said PMUA. Any thoughts?

Thanks
Tyler


#8

Internal subscriptions are not configured to archive data by default. All you should need to do is edit the device configuration for the internal subscription and set the historian. For example, in the openPDC Manager on the system running PDC1…

  1. Navigate to “Inputs > Browse Input devices”.
  2. Locate PDC2 in the list and click on its acronym to be taken to the Manage Device Configuration page.
  3. Go to the fourth input field in the column on the right and select a historian from the combo box located there.
  4. Click the “Save” button at the bottom right.

Thanks,
Stephen


#9

I completed the steps above, and this fixed the issue. Thank you!

I had another inquiry. If, let’s say, I have 4 PMUs connected to PDC1 (PMUs A-D) and I only want PMUs A-C to report through to PDC2. Is there a way to facilitate this?

Thanks
Tyler


#10

Yes, there are two ways to facilitate this.


The first way is to keep the metadata, but cut off the data flow. This will stop the real-time data from PMUD while still making it possible to browse to the PMUD device and see its measurements. Normally, if you don’t want the data, you probably don’t want the metadata either, but this can be useful if you’re frequently changing the data stream to receive only the data that is relevant to the task at hand. To do this, you would modify the OutputMeasurements parameter in the connection string. For example…

Connection String:
interface=0.0.0.0; compression=false; autoConnect=true; securityMode=None; server=172.21.4.212:6165; internal=False; receiveInternalMetadata=True; receiveExternalMetadata=False; outputMeasurements={FILTER ActiveMeasurements WHERE Protocol = ‘GatewayTransport’ AND Device NOT IN (‘PDC1!PMUD’, ‘PDC1!PMUE’) }

You can also change the query to specify only the list of devices from which you want to receive data.

Connection String:
interface=0.0.0.0; compression=false; autoConnect=true; securityMode=None; server=172.21.4.212:6165; internal=False; receiveInternalMetadata=True; receiveExternalMetadata=False; outputMeasurements={FILTER ActiveMeasurements WHERE Protocol = ‘GatewayTransport’ AND Device IN (‘PDC1!PMUA’, ‘PDC1!PMUB’, ‘PDC1!PMUC’) }


The second way tells the server not to send the metadata across. The subscriber will be effectively unaware that the device exists. Its data won’t be transmitted to the subscriber, and you won’t be able to browse to it in the openPDC Manager on the subscriber system. For this method, you need to add a metadataFilters property to the connection string.

Connection String:
interface=0.0.0.0; compression=false; autoConnect=true; securityMode=None; server=172.21.4.212:6165; internal=False; receiveInternalMetadata=True; receiveExternalMetadata=False; outputMeasurements={FILTER ActiveMeasurements WHERE Protocol = ‘GatewayTransport’ }; metadataFilters={ FILTER DeviceDetail WHERE Acronym NOT IN (‘PMUD’, ‘PMUE’) }

Likewise, this syntax can be modified to specify only the devices you would like to receive data from.

Connection String:
interface=0.0.0.0; compression=false; autoConnect=true; securityMode=None; server=172.21.4.212:6165; internal=False; receiveInternalMetadata=True; receiveExternalMetadata=False; outputMeasurements={FILTER ActiveMeasurements WHERE Protocol = ‘GatewayTransport’ }; metadataFilters={ FILTER DeviceDetail WHERE Acronym IN (‘PMUA’, ‘PMUB’, ‘PMUC’) }


Note that using the first method, I specified device acronyms as they appear in the subscriber (PDC1!PMUA). Using the second method, I specified device acronyms as they appear in the publisher (PMUA). This difference was intentional because the MetadataFilters parameter gets transmitted to the publisher before being processed whereas the OutputMeasurements parameter is directly processed by the subscriber.


Bidirectional connection between two instances of OpenPDC with virtual PMUs
#11

Stephen,

Everything is working perfectly now! I very much appreciate all of your help with this project!

Tyler


#12

Stephen,

I am now encountering an issue with taking this project live. Previously I was working with a lab “proof-of-concept” version. I am now working with two field PDCs which are on separate networks.

The issue I am encountering is that PDC1 has full access to the data streams of PDC2 (and the devices connected directly to it). However, PDC2 does not see any data from PDC1. I see “True” in the subscriber connected however there is no data coming through. Any thoughts?

Thanks
Tyler


#13

Tyler,

It may be that the subscriber on PDC2 is encountering errors when processing data from PDC1. There is a file called ErrorLog.txt in the openPDC installation directory. Scroll all the way to the bottom of the file to find the latest errors.

Also, can you tell me whether PDC1’s devices can be viewed in the “Browse Input Devices” page of the openPDC Manager on PDC2?

Thanks,
Stephen


#14

Hi Stephen,

Thanks for the response. I can confirm that in the “Browse Input Devices” page PDC2 can in fact see the input device for PDC1. The status flags show that the subscriber is connected (Subscriber connected = True) however all other values read as 0s.

In the error log the following is the most recent error listed:

---- Stack Trace ----
GSF.Communication.TcpClient.ProcessConnect(connectState As ConnectState)
openPDC.exe: N 00171

(Outer Exception)
Date and Time: 8/17/2016 1:45:46 PM
Machine Name: redacted
Machine IP: redacted
Machine OS: Microsoft Windows NT 6.1.7601 Service Pack 1

Application Domain: openPDC.exe
Assembly Codebase: C:/Program Files/openPDC/openPDC.exe
Assembly Full Name: openPDC, Version=2.1.120.0, Culture=neutral, PublicKeyToken=null
Assembly Version: 2.1.120.0
Assembly Build Date: 7/30/2015 9:36:46 AM
.Net Runtime Version: 4.0.30319.18444

Exception Source:
Exception Type: System.InvalidOperationException
Exception Message: Data subscriber encountered an exception while attempting command channel publisher connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

In this, where “redacted” shows up I have edited that so as not to divulge our customers information. Any thoughts?

Tyler


#15

First thing is, that error is too old to be relevant. If that error were still occurring, the subscriber would be attempting to reconnect every 35 seconds or so. The fact that the most recent error is from several days ago indicates this is not still happening.

I’m guessing the subscriber is connected, but it’s simply not subscribing to anything. Check to make sure PDC1’s devices have measurements when you browse to them on PDC2. Also, have you modified the OutputMeasurements parameter of the connection string for this subscription? It’s possible to modify that filter in such a way that it returns no results, which would cause the subscriber to subscribe to nothing.

Thanks,
Stephen


#16

I didn’t even notice the error date, sorry about that. It is odd that the error has not been recurring, since the session still returns no measurements.

When I go to the “Graph Measurements” tab on PDC2 I can see that the PMU does have measurements (e.g. Frequency, Phase Angle, etc.) However they are all just returning 0s.

I have not modified the outputmeasurements parameter. I completed the setup as prescribed by our previous conversations on this topic. I am a little lost on what is happening now.

Tyler


#17

So it sounds like the subscriber is subscribing to data, but the data is all zeros? I’ve never heard of that happening before. Would you be able to provide screenshots of the Graph Measurements screen from both PDCs for comparison? Pick the same frequency measurement on both so we can see the difference.

Thanks,
Stephen


#18

I will get those for you shortly. Quick question…PDC1 does have database authentication and login credentials…would this impact it at all?

Tyler


#19

No, I don’t think that would make a difference.


#20

Stephen,

Here are the pictures of the graph measurements screen.

PDC1:

PDC2:

I have selected the station frequency as the measurement to be compared.