PaperlayerView exact revision on arXiv

Source-linked AI summary

PMU Foundation Model Bridge: A Tool for Connecting Synchrophasor Streams to Time Series Foundation Models

Haozong Wang, Jiahui Yang, Yuru Wu, Chujie Zeng, Qian Liu, Yan Wen, Yayu Yang, Muhammad Umar Afzaal, Yilu Liu

arXiv:2610.33387v1eess.SYcs.SEcs.SY

TL;DR

Online PMU/PDC forecasting must contend with data-handling and model-execution challenges such as out-of-order or invalid measurements and variable inference latency. PMU Foundation Model Bridge connects those streams to TSFMs with configurable preprocessing and outputs; tests demonstrate live-stream execution and local transmission within the selected one-second forecast lead during the laboratory run.

  • Problem

    Online PMU/PDC forecasting involves out-of-order, incomplete, or invalid data, variable inference latency, forecast timing and channel mapping, and maintaining responsiveness during slow inference or interrupted input.

    Source: §I · p. 1

  • Method

    PMU Foundation Model Bridge connects online PMU/PDC streams to TSFMs with configurable channel selection, preprocessing, local inference, and file or network output.

    Source: §I · p. 1, B. Preprocessing · p. 2

  • Results

    During the laboratory run, computation finished 0.39–0.69 s after reference times (median 0.60 s), and local TCP transmission finished 0.41–0.76 s after them (median 0.64 s); all sends preceded targets by the one-second forecast lead.

    Source: B. Laboratory PMU Stream · p. 4

  • Takeaways & Limitations

    Tests with virtual PMU and laboratory PMU data demonstrate online model execution and output generation, supporting research on integrating synchrophasors with TSFMs.

    Source: §V · p. 4

Abstract

from arXiv · show

This paper presents PMU Foundation Model Bridge, an open source tool that connects online phasor measurement unit (PMU) or phasor data concentrator (PDC) streams to publicly available time series foundation models (TSFM). Through a desktop interface or command line interface, users can select measurement channels, define preprocessing, choose TSFMs, and configure outputs. In the initial release, 4 publicly available TSFMs were supported, including Chronos-2, TimesFM 2.5, Timestral, and TimesFM-3. The tool supports both file and synchrophasor streaming outputs, therefore enabling both offline use and integration into C37.118-based online workflow applications. In addition to supporting raw synchrophasor data, the framework provides a preprocessing layer for deriving customized additional quantities for forecasting. The tool is validated using a virtual PMU and real-time laboratory measurements from a frequency disturbance recorder (FDR). The tool aims to support community research on combining synchrophasor technology with TSFMs.

I. INTRODUCTION

Synchrophasors provide synchronized measurements for forecasting faster grid dynamics, while time series foundation models offer reusable temporal patterns across domains. PMU Foundation Model Bridge connects online PMU/PDC streams to selected TSFMs through configurable interfaces and outputs.

I. INTRODUCTION

  • Synchrophasor measurements support prediction of future system states when communication delays leave measurements unavailable and prediction of dynamics following disturbances.They provide synchronized voltage, current, and frequency measurements.Source: §I · p. 1
  • TSFMs learn reusable temporal patterns across domains and can forecast new series without training for each specific task.Traditional and deep-learning forecasting methods are generally tailored to particular tasks.Source: §I · p. 1
  • Online integration must handle out-of-order, incomplete, or invalid measurements, variable inference latency, forecast timing and channel mapping, and responsive operation during slow inference or interrupted input.Source: §I · p. 1
  • PMU Foundation Model Bridge connects online PMU or PDC streams to four TSFMs and offers channel selection, optional Python preprocessing, local inference, and file or network output.Users configure it through a desktop interface or CLI; the paper describes functional verification with virtual PMU and laboratory streams.Source: §I · p. 1

II. MODEL INPUTS, OUTPUTS, AND TIMING

The foundation model uses a recent history of selected signals to predict future values for each channel. Users configure the history length, forecast length, and interval between model calls.

II. MODEL INPUTS, OUTPUTS, AND TIMING

B. Key Times and Their Relationships

Forecast timing is defined relative to the last input measurement and the nominal sampling interval. Positive remaining lead at local send completion is necessary for a meaningful forecast, assuming aligned source and local clocks, but does not guarantee downstream receipt.

B. Key Times and Their Relationships

  • The reference time is the measurement time of the last input sample, and the kth predicted sample targets time tr + k∆.Here k runs from 1 to H, and k∆ is the forecast lead.Source: B. Key Times and Their Relationships · p. 2
  • Receiving data, waiting, computing, and sending reduce the time remaining before the target.The passage identifies computation completion and local transmission completion as timestamps in this timing sequence.Source: B. Key Times and Their Relationships · p. 2
  • Positive remaining lead at local send completion is necessary for a meaningful forecast, assuming aligned source and local clocks, but is not sufficient for timely downstream delivery.Source: B. Key Times and Their Relationships · p. 2

III. SYSTEM ARCHITECTURE

A common runtime coordinates measurement windows, preprocessing, model execution, and file and network outputs. The desktop interface and CLI configure the runtime and display its status.

III. SYSTEM ARCHITECTURE

  • A common runtime coordinates incoming measurements, historical windows, preprocessing, completed forecasts, and file and network outputs.Source: §III · p. 2
  • The desktop interface and CLI both configure the runtime and display its status.Source: §III · p. 2
  • Users select one of four model backends, which load once for successive forecasts and use adapters to return predictions in a common format.All four backends forecast each channel independently; covariates and joint multivariate forecasting are future work.Source: §III · p. 2

A. Historical Windows

Historical windows are buffered, ordered, and checked for timing, completeness, and quality before prediction. A preprocessing layer can also turn PMU measurements into study-specific quantities for forecasting.

A. Historical Windows

  • Samples are sorted by measurement time in a fixed-capacity buffer, with a short wait for out-of-order arrivals and a fixed sample count per window.Duplicate and excessively late samples are discarded and counted.Source: A. Historical Windows · p. 2
  • Windows with missing, nonfinite, invalid, or unsynchronized data are skipped by default, while limited missing-data repair can be enabled through preprocessing.Rounded timestamps are matched to expected times within a configured tolerance, with unique matches required.Source: A. Historical Windows · p. 2

B. Preprocessing

  • Preprocessing lets users derive customized quantities from PMU measurements and pass them to the foundation model as forecasting series.This supports tasks involving both reported measurements and study-defined quantities.Source: B. Preprocessing · p. 2
  • An optional Python function can create channels from selected historical data, with returned times, values, and channel mappings checked before prediction.An inverse function can restore predictions to original scale and units after normalization.Source: B. Preprocessing · p. 2

C. Handling Delays and Interruptions

The runtime handles slow inference and interruptions by prioritizing recent windows, monitoring worker execution, and separating input and output queues. Processing stages run in one worker, while file and network outputs share a forecast record.

C. Handling Delays and Interruptions

  • When inference outlasts the interval between model calls, only one eligible window waits; a newer window replaces it before submission to prioritize recent measurements.The replacement is recorded.Source: C. Handling Delays and Interruptions · pp. 2–3
  • Preprocessing, model inference, and an optional inverse transform run in one worker process, while file and network outputs use the same forecast record.Solid arrows in the architecture mark data flow; dashed arrows mark configuration and supervision.Source: Figure 2 · p. 3
  • The runtime monitors worker time and memory, terminates over-limit execution, and limits restart attempts; reconnection clears history, while source-configuration changes stop the run for channel remapping.Results from a previous source state are discarded.Source: C. Handling Delays and Interruptions · p. 3
  • Input reception, file writing, and network sending use separate fixed-capacity queues and can proceed independently; clients are disconnected if queues fill or sending exceeds its limit.File errors and dropped records are reported.Source: C. Handling Delays and Interruptions · p. 3

D. Output Structure

Forecast records carry predictions and timing, channel, and model information, with separate file and C37.118 network output paths. Network frames map forecast leads to channels and publish only when required source fields are valid.

D. Output Structure

  • Each forecast record includes predicted values, channel descriptions, reference and target times, completion time, and model information; forecasts have unique identifiers and record median point forecasts.Unique identifiers allow successive forecasts for the same target time to be stored separately.Source: D. Output Structure · p. 3
  • File output stores the forecast sequence in CSV, with metadata for channel sources and units, model weights, and preprocessing script.Publication events track submission and local-send completion, separately from file-writing status.Source: D. Output Structure · p. 3
  • Network output uses a C37.118 synchrophasor stream, placing selected forecast leads in floating-point ANALOG channels with frame timestamp tr.A mapping record links each output channel to its name, unit, source, and forecast lead for downstream interpretation.Source: D. Output Structure · p. 3
  • Network frames carry source measurements in FREQ and DFREQ at the reference time and are published only when those required values are valid.A status flag marks modified data, and skipped publications are recorded as events.Source: D. Output Structure · p. 3

IV. VALIDATION

The virtual PMU test sent an online stream through local forecasting and downstream reception verification. Frequency predictions followed the main oscillation with some differences, and the three shown forecasts were computed and locally transmitted before their target times.

A. Virtual PMU Stream

  • The virtual PMU test covered measurement acquisition, local frequency forecasting, and downstream reception of configuration and forecast data frames.TimesFM 2.5 generated the frequency forecasts from the virtual PMU stream.Source: A. Virtual PMU Stream · p. 3
  • Predictions followed the recorded frequency's main oscillation, with differences in parts of the record when compared at aligned target times.A separate panel shows three predictions with a one-second lead, plotted at their target times.Source: A. Virtual PMU Stream · p. 3
  • Computation and local transmission both finished before the target times for the three forecasts shown.The test used an online virtual-PMU stream and verified reception of configuration and forecast frames downstream.Source: A. Virtual PMU Stream · p. 3

B. Laboratory PMU Stream

A live laboratory FDR stream was forecast with TimesFM 2.5 using 4 seconds of history at 10 samples/s. In a later network run, local sends completed before the one-second forecast targets.

B. Laboratory PMU Stream

  • The live FDR stream arrived at 10 samples/s; TimesFM 2.5 used 4 s of history to predict the next second, calling the model once per second.The tool forecast frequency, rate of change of frequency, voltage magnitude, and voltage angle.Source: B. Laboratory PMU Stream · p. 3
  • 0.39–0.69 s after reference times, computation finished; local TCP sends finished 0.41–0.76 s after reference times, leaving 0.24–0.59 s before one-second targets.The box plots summarize completion and local send times in a network run separate from the saved-window prediction run.Source: Figure 4 · p. 4, B. Laboratory PMU Stream · p. 4
  • Figure 3 depicts measured and predicted frequency alongside target, completion, and local send times for predictions with a one-second lead.Source: Figure 3 · p. 4

V. CONCLUSION

PMU Foundation Model Bridge connects online synchrophasor streams to publicly available TSFMs through a configurable workflow. Virtual PMU and laboratory tests demonstrate online execution and output generation; the conclusion identifies broader data validation and added forecasting capabilities as future work.

V. CONCLUSION

  • The tool combines channel selection, flexible preprocessing, local model execution, and file or network outputs in a shared runtime, supporting reported or calculated quantities across four models.Source: §V · p. 4
  • Virtual PMU and laboratory PMU tests demonstrate online model execution and output generation.Source: §V · p. 4
  • Future development may add covariates and joint multivariate forecasting and extend validation to a wider range of power system data.Source: §V · p. 4

Related papers

Loading 2610.33387v1…