In this case, we have an interface that is picking up sub-second (synchrophasor) data and writing it to a PI Server. Some users (external) cannot see the data in real time but to complete the analysis that is necessary of this data, the delayed data must come in at the same frequency. The set of tags (or a separate PI Server) could have security enabled such that some users only see these tags, i.e. the group allowed access to only the delayed data.
We are looking for the best way to delay the data in real time. Our best option to date is a custom program that signs up for snapshot updates for the real time tags (a small set, <200) of subsecond (about 60 events per second), read these points, keeps them in a small, 24 hour buffer, and then writes the data after it ages 24 hours, into a separate set of tags (same PI Server or different).
Has anyone write such a program? It would basically need a set of points (likely by point sources), sign up for updates on these points and keep their snapshot values in a 24 hour buffer, then write them to a separate set of tags in sequence after the 24 hour delay has occurred.
If you're not aware of a program that exists, do you have another idea? We've considered things like moving archives after 24 hours, starting/stopping PI-to-PI in history recover mode, but neither will keep the data coming in in natural frequency (60 hertz) to the snapshot with a constant 24 hour delay. We also considered a PE with *-24h but we don't believe that PE will keep up with the frequency of data in a smooth means, i.e. continuous at a similar frequency. Using the delay in AF won't work either since in this particular case, the data will need to come directly from the tag, i.e. not via AF.