RJKSolutions

Future data in PI

Discussion created by RJKSolutions on Jun 13, 2011
Latest reply on Feb 9, 2012 by MvanderVeeken

Some time ago I sat down and thought about how future data from the PI servers perspective would work after numerous conversations about how to implement a temporary solution for future data until we see it as standard functionality from PI.  Below is a very basic concept drawing I did at the time so thought I may as well share it to see how everyone else imagines they will be working with future data and PI - seen as though it is a hot topic right now.

 

future_5F00_subsystem.jpg

 

There are elements to this concept that miss out some details but what I had in my visiion was:

 

- Future data is stored in standard archive files.
- A new subsystem manages these archives, there shouldn't be any overhead to administrators.
- Archives aren't created by an administrator, a time rule tuning parameter is set (e.g. *+6 months) and the subsystem handles everything else - self tunes!!
- Snapshot subsystem remains relatively untouched except when future data arrives, it passes the event to the future subsystem.
- When the future subsystem has events in its future archives that become current, it passes them back to the snapshot subsystem as if they just arrived impersonating the interface/application that originally sent the data.
- Implement some form of tag security versioning.  For example, to cater for future data written 6 months ago but then 1 month ago security changes (e.g. PI Identity for the interface node).
- Toggle exception/compression settings on/off for the future subsystem without effecting snapshot or archive subsystems.
- Client tools would have to be explicit and ask to show future data, even then it displays differently to current data.  For example, in trends the trend background is darker or has a subtle pattern.  In datalink text colour changes etc.

 

Ideally there would be some form of SSB (minimum of system state data; ideally to include event data) where the collective members communicate, for example, when new future archives are going to be created they collectively agree to create the archive rather than doing it in isolation. 

 

When I get some more time I will also start a discussion on Interfaces to the AF system rather than the PI system, like we see in the newer PI AMI interfaces.

Outcomes