Data Gap Recovery issues

GPA Products
1

I have managed to get the Data Gap Recovery working between 2 SIEGate’s using Authorized subscription.
As per the demonstration video on YouTube, if I pull the network cable on one of the boxes to simulate a loss of connection, this feature works fine.

However, if I pull the cable for 5 minutes simulating a lengthier network dropout, I get this … it happens every time, and no data is recovered.

[2/15/2019 1:12:10 PM] [151.142.SG] [DataGapRecoverer] Starting data gap recovery for period "2019-02-15 03:10:38.462" - "2019-02-15 03:11:40.534"...


[2/15/2019 1:12:10 PM] [151.142.SG] [DataGapRecoverer] Success code received in response to server command "Subscribe": Client subscribed as compact unsynchronized with a temporal constraint.


[2/15/2019 1:12:14 PM] [151.142.SG] [DataGapRecoverer] TSSC algorithm reset before sequence number: 1249


[2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:73 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration.


[2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:74 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration.


[2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:75 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration.


[2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:76 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration.


[2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:77 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration.


[2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:78 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration.


[2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:79 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration.


[2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:80 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration.


[2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:81 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration.


[2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:82 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration.


[2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:83 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration.


[2/15/2019 1:12:20 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:71 @2019-02-15 03:10:40.7660000. Data received out of order will not be archived, per configuration.


[2/15/2019 1:12:20 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:70 @2019-02-15 03:10:41.0000000. Data received out of order will not be archived, per configuration.


[2/15/2019 1:12:20 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:72 @2019-02-15 03:10:41.0000000. Data received out of order will not be archived, per configuration.

Any thoughts on how to correct this?

2

My suggestion would be to use the openHistorian 2.0 instead of the 1.0 local historian - is this a possiblity for your deployment?

3

What method would I use to be able to use the OpenHistorian 2.0 whilst still retaining SIEGate?

I tried a local subscription of a local OpenHistorian to a local SIEGate using Data Gap Recovery, but I guess that won’t work since the SIEGate it’s subscribing to is not the source of the unrecovered data. I have also tried OpenHistorian to OpenHistorian over the network using TLS but I can’t get that to work without giving errors (See previous post).

4

Actually, I would expect either method would work. The simple case, for example, is simply that a locally installed openHistorian would subsribe to SIEGate for its data. SIEGate would be in control of data gap recovery - however, like you say, this would not account for cases where the openHistorian might be down - just gaps as detected by SIEGate. In the case of openHistorian to openHistorian (bypassing SIEGate), this is also possible, just more tricky to get going…

5

Hi Ritchie
I got it working by following this post I found that you had made
https://github.com/GridProtectionAlliance/openHistorian/wiki/Migrating-to-openHistorian-2.0-in-other-GPA-Products
and it works great, I simulated a 15 min downtime between the 2 SIEGate over the network and all was recovered, and successfully passed on to the OpenHistorian then on to Grafana. Only caveat is that SIEGate doesnt support the OpenHistorian 2 input type, so I can’t modify the custom input for PPAReader. All that means is I can’t view History in SIEGate? which probably won’t be an issue since the data is getting passed to OpenHistorian anyway.

6

Right - in this mode SIEGate is just being used as pass-through to openHistorian