mchristo27

Best Practices for Future Data in PI

Discussion created by mchristo27 on Feb 26, 2009
Latest reply on Jul 31, 2015 by hgunterman

Hey vCampus team,

 

We will be using PI to store operational data from in-home demand-management devices (such as controllable thermostats and relay/measure modules). These devices record temperature, power, voltage and the like and are also controllable for the purposes of targeted demand response. We have the capability to forecast the usage of energy-using devices in the home for which we have data, most notably HVAC systems and water heaters. We will be publishing these forecasts at regular intervals to a utility operator who makes day-ahead and hour-ahead operating decisions based on the forecasts.

 

Assume the day-ahead forecast is prepared at 2pm for the 36-hour period beginning at midnight the next day. Assume the hour-ahead forecast is prepared on the day-of every hour for the period beginning two hours in the future and ending at midnight (e.g., the forecast for 4pm - midnight today is prepared and stored in PI at 2pm). Both of these forecasts are 'rolling' in that they have regular overlapping periods with older forecasts. We want to retain all of these forecasts. In other words, we never want to overwrite any part of an older forecast with a newer one. All forecasts are done with timestamps at 15-min intervals.

 

We want to know what our options are for storing these time-series forecasts (i.e. future data) in PI, and what is considered to be current best practice? From my discussions with folks at OSI and reading through the discussion forums, I am aware of several possibilities:

 

1) Use primary and seconday tags, where the primary tag stores the value and the secondary tag stores a time offset that is added to the timestamp of the primary tag. Use programmatic logic to apply the offset and reconstitute the forecast when publishing it.

 

2) Use time scaling to compress the data into a time window well within the 10-min future time limit of PI. Use programmatic logic to uncompress the forecast when publishing it.

 

3) Use a second PI server with the system clock set in the future.

 

4) Use a relational database with the RDBMS interface and store the future data in a rdb table.

 

What else am I missing? What recommendations do you have? Thanks for your help!

 

Mike Christopher, GridPoint

Outcomes