Initial situation: I am receiving PMU data in openPDC from a third-party PDC software, via a C37.118 stream at 50 fps. This stream includes both PMUs with a native resolution of 50 fps and PMUs with a native resolution of 100 fps that are downsampled to 50 fps by the third-party software. I have only one concentrator device in openPDC (PDC-50) receiving this 50 fps stream, which contains all the PMUs. The data from this openPDC concentrator is sent to openHistorian via STTP and is received in a single concentrator device (HISTORIAN). All the data are shown in Grafana.
Target situation: In the third-party software, I have created a second stream with a resolution of 100 fps, which I send in C37.118 format to openPDC, in addition to the initial 50 fps stream. I created a second concentrator device (PDC-100) in openPDC dedicated to this new stream. In the third-party software, I distributed the PMUs between the two streams according to their native resolution, 50 or 100 fps. In openPDCâs GUI under âMonitoring > Graph Measurementsâ, I can see all my PMUs displaying data, divided into two groups based on their respective concentrators: PDC-50 and PDC-100.
Issue: I expected that the STTP stream would be able to send data from both concentrators to openHistorian while preserving their native resolutions. However, I still only have a single concentrator in openHistorian (HISTORIAN) that contains all the PMUs (which might be normal; Or the 100 fps PMU are still there due to the fact that they previously were in the initial stream ?). Nevertheless, both in openHistorian and Grafana, the 100 fps PMUs do not display any data: their status is grey in the Monitoring> Graph measurements GUI in openHistorian ; and marked as âunknownâ or âunrecognizedâ in Grafana (i.e., they are not detected as being in fault in terms of data validity, but rather as âabsentâ or âunknownâ).
I suspect that STTP (which lacks a dedicated GUI for configuring content filtering or for adding/removing a second STTP stream) may be the cause of this issue.
How should I configure the STTP connection between openPDC and openHistorian so that the data from both concentrators, PDC-50 and PDC-100, are properly sent, received, archived, and available in Grafana, while preserving their respective resolutions of 50 fps and 100 fps?
Does this imply having two separate concentrators in openHistorian?
Thank you in advance for any help you can provide.
Kind regards.
PS : to illustrate (note that the red dot is ânormalâ because the PMU itself has an issue ; but the âredâ dot implies that at least the status data of the PMU are received imo) : in openPDC :
On the Graph Measurements screen, the color red is applied to a PDC or direct-connected PMU if its statistics indicate that it is not receiving any frames. The statistic it checks is Total Frames (Signal Reference: *!IS-ST1). If the value of that statistic is zero, it sets the color to red. The color red is applied to child devices of a PDC only if its parent device is red.
Therefore, in your first screenshot, the openPDC isnât receiving any data frames from the upstream PDC, as indicated by the red color. But it is receiving statistics generated by the input adapter, which only indicates that the openPDC is trying to connect to the upstream PDC despite not receiving any frames. Given that the openPDC is not receiving any data frames from the upstream PDC, it would logically follow that it is not receiving any data (status or otherwise) from the upstream PMU at all.
In the case of openHistorian, the STTP connection is green so it wouldnât apply the red color to the child device. But since openPDC isnât receiving any data from the upstream PDC, openHistorian naturally would also not be receiving any data for that PMU.
This is indeed normal. Downstream systems donât receive much information about upstream PDCs. They only retain information about the upstream PMUs. Therefore, openHistorian wonât be able to differentiate between an openPDC that receives its data from upstream PDCs versus an openPDC that receives its data directly from PMUs. This means that it canât tell if two devices from the same openPDC were received via different communication paths so it just lumps them together under the same parent device.
You have already configured the STTP connection correctly. It will automatically receive all the data at its native resolution, so long as openPDC is receiving the data from the PMUs. The issue in this case appears to be that the openPDC is not receiving any data from that PMU.
Thank you very much for the detailed informations provided.
One more question :
My STTP stream have 50 fps PMUs and (at least for the moment) one 100 fps PMU. Does the following paramter âFrame per secondâ of the HISTORIAN concentrator (which is set to STTP protocol) is important ?
My goal is to store both 50 fps and 100 fps PMU data in the same openHistorian âPPAâ archive.
Iâm concerned that if I keep this setting at 50 fps, I will lose half of the data from my native 100 fps PMU; and if I change the setting to 100 fps in openHistorian, I will double the amount of stored data for my native 50 fps PMUs (which would cause my storage to âexplodeâ).
Is the objective Iâm trying to achieve possible with a single PPA archive? How can I achieve it (specifying the âframe per secondâ parameter for each PMU received in openHistorian for example ?)
That parameter is typically not very important on the STTP stream itself. By default, STTP uses âunsynchronizedâ subscriptions which do not perform concentration on the input data. There are options for âremotely synchronizedâ subscriptions (concentration by the publisher) and âlocally synchronizedâ subscriptions (concentration by the subscriber) which would require you to provide the framerate at which concentration should be performed, but this is a pretty atypical use-case for STTP. (EDIT: This is only an option for GEP subscriptions. Synchronized subscriptions were so atypical that they were entirely dropped when creating the STTP standard, to reduce complexity.)
There is one other place where that Frames Per Second field comes into play on the child devices, where it will be used to compute Expected Measurements Per Second for the purposes of logging statistics for Completeness reports. Other than that, STTP ignores the field completely.
Thank you, Stephen, for this very thorough response.
Based on the information you provided, I was able to identify the cause of the problem: the 100 fps C37.118 âserverâ configured upstream in my third-party software currently contains only one PMU that is faulty (due to an unreliable time base). As a result, this third-party software refuses any incoming TCP connection to that C37.118 server (even though its status shows as âactiveâ).
I temporarily added f/df datapoints from another 50 fps PMU to this stream (which I intentionally ignore on the openPDC side), so that it would technically include at least one âvalidâ measurement. This allowed me to successfully connect openPDC to it.
Once the connection between the two components was established, I could see the data (or rather the lack of measurement data, since the PMU is faulty) from the 100 fps PMU appearing correctly in openPDC and openHistorian â the status does get transmitted, and the indicator appears in yellow in both applications instead of grey or red.
Your explanation regarding how STTP and archiving work is also reassuring â itâs good to know the software behaves as I expect.
Thank you again for the speed, quality, and relevance of your responses.
