OSIsoft Pi System — now AVEVA PI System since the AVEVA acquisition — remains the dominant time-series historian in North American grid operations. A large majority of utility-scale renewable asset operators and grid control rooms have Pi System infrastructure somewhere in their data architecture, making it the most common integration target for forecast delivery in the energy sector.
Integrating external forecast data into Pi System is not inherently complex, but there are specific architectural decisions that determine whether the integration performs reliably at the 6-hour update cadence that operational forecasting requires. This post walks through the connector approach we use, the tag naming conventions we've settled on, and the operational considerations that determine whether forecast data is accessible to Pi Vision dashboards and downstream EMS workflows the way operators expect.
The two delivery patterns: push via PI Web API vs. pull via PI AF
For external forecast delivery into Pi System, there are two primary architectural patterns. The push pattern uses PI Web API — specifically the batch endpoint — to write forecast values as time-series data against pre-configured PI points (tags). The pull pattern uses PI Asset Framework (PI AF) with a data reference that calls an external REST endpoint on-demand when PI Vision or an AF-connected application requests the data.
The push pattern is more appropriate for operational forecasting because it pre-populates the historian with forecast values on the update cycle, making the data immediately accessible to any Pi System consumer without requiring a live call to the forecast API at read time. This is important for control room operators who may be viewing Pi Vision dashboards in a degraded network environment where latency to external APIs is unacceptable.
The pull pattern (AF data reference to external endpoint) has an apparent simplicity advantage — no data is written to the historian, so there is no storage overhead and no stale data to manage. But in practice, it introduces a runtime dependency on external connectivity that makes it unsuitable as the primary integration path for production grid operations where availability requirements are stringent. We use the pull pattern for supplementary display elements — live forecast confidence band indicators — but not for the core production forecast time series that feeds reserve commitment calculations.
PI tag design for P10/P50/P90 forecast delivery
Each forecast asset requires a set of PI tags: one per quantile level per interval output type. For a standard solar production forecast delivery, this means three tags per asset for instantaneous power (kW or MW), and optionally additional tags for cumulative energy (MWh per interval) if downstream energy accounting workflows require it.
We use a tag naming convention structured as:
SITE.ASSET_ID.SOLAR_FCST_P10_MW_15MIN
SITE.ASSET_ID.SOLAR_FCST_P50_MW_15MIN
SITE.ASSET_ID.SOLAR_FCST_P90_MW_15MINWhere SITE is a customer-defined prefix matching their existing tag naming convention and ASSET_ID is the unique plant identifier in their asset register. The quantile suffix and resolution suffix are appended consistently to avoid ambiguity when a Pi Vision display is pulling multiple time series for comparison against SCADA actuals.
This is worth specifying explicitly because Pi System tag names are permanent after creation in most enterprise configurations — renaming requires coordination with the PI administrator and can break downstream AF element templates and Pi Vision displays that reference the old tag name. Agreeing on a naming convention upfront prevents the kind of tag proliferation and naming inconsistency that makes historian archives difficult to navigate after several years of accumulated integrations.
Time convention alignment: the timestamp trap
Pi System stores time-series data with timestamps representing the data value's valid time. GFS and ECMWF output timestamps use interval-end convention: a 15-minute interval running from 14:00 to 14:15 is timestamped 14:15. Depending on the Pi historian configuration and the EMS system consuming the data, interval-start (14:00) or interval-midpoint (14:07:30) conventions may be expected.
This matters because Pi Vision trend displays and Pi AF event frame analysis typically show the timestamp as the x-axis position. A P50 forecast value timestamped at 14:15 for the 14:00–14:15 interval will display one interval shifted to the right relative to a SCADA actual value timestamped at 14:00 for the same production interval. To a dispatch engineer viewing the comparison overlay, this looks like the forecast is consistently 15 minutes behind actuals — a phantom latency artifact driven entirely by timestamp convention mismatch.
We align our output timestamps to the convention used by the customer's existing SCADA tags in Pi, verified during the pre-integration scoping review. The PI Web API batch write accepts arbitrary timestamps, so the convention conversion is a configuration parameter in our delivery pipeline rather than a code change.
Handling forecast updates: future data replacement
At each 6-hour update cycle, the new forecast run replaces prior forecast values for the future intervals. Pi System handles this naturally: writing a new value to a PI point for a future timestamp overwrites the prior forecast value stored at that timestamp. This is the expected behavior and is correct for operational forecast delivery.
Where operators sometimes encounter confusion is in the display of historical forecast accuracy. If a forecast for 14:00 tomorrow was issued at 00:00 today with a P50 value of 185 MW, and was then updated at 06:00 with a new P50 value of 162 MW, the original 185 MW forecast is overwritten and is no longer accessible in the standard Pi historian. For operators who want to evaluate how forecast accuracy evolved across update cycles — useful for post-event analysis of a ramp event miss — this overwrite behavior means the forecast revision history is lost.
The solution we implement is a forecast archive tag set alongside the operational forecast tags. Archive tags receive the forecast value at issuance time with a composite timestamp encoding both the valid time and the issue time, enabling reconstruction of the full forecast revision history. This is stored as event-frame data in PI AF rather than as additional time-series tags, which keeps the tag count manageable and uses the data structure that Pi AF event frames are designed for.
Pi Vision display configuration
For operations-facing dashboard displays in Pi Vision, the typical configuration is a trend overlay showing P50 as a solid line, P10 and P90 as dashed band boundaries, and SCADA actuals in a contrasting color as actuals arrive in the production window. The band fill between P10 and P90 is a Pi Vision calculated data reference that requires a simple subtract operation, which is supported natively in Pi Vision via the attribute formula data reference type.
One configuration detail that consistently needs adjustment: Pi Vision's default time axis auto-scale will set the y-axis range to the range of all visible data. When P10 is 0 MW during nighttime hours and the display spans a full 24-hour window, the auto-scale compresses the interesting daytime production range into the upper portion of the y-axis. Setting a fixed y-axis floor at 0 and a ceiling at 110% of nameplate capacity, with auto-scale disabled, produces a more operationally readable display.
The connector architecture described here — PI Web API push, six-hour update cycle, P10/P50/P90 tag set, forecast archive in event frames — is the pattern we've settled on across deployments that run Pi System historians as the primary data bus. It is not the only valid design, but it is one we can deploy, validate, and hand over to the customer's PI administrator without requiring ongoing maintenance access to the historian configuration.