Large Language Model Assisted Operational Monitoring for Battery Energy Storage System Integrated Power Distribution Networks

Azmeer Akhtar; Md Fazley Rafy; Anurag K. Srivastava

Source-linked AI summary

Large Language Model Assisted Operational Monitoring for Battery Energy Storage System Integrated Power Distribution Networks

Azmeer Akhtar, Md Fazley Rafy, Anurag K. Srivastava

arXiv:2608.15396v1Aug 15, 2026cs.AIcs.CLeess.SY

TL;DR

BESS-integrated distribution networks generate complex telemetry that creates a practical barrier between operator questions and structured engineering analysis. This paper connects natural-language queries to validated SQL and deterministic constraint checks, demonstrating successful query generation and identification of voltage violations, reactive-power overshoot, and active-power tracking performance.

Problem
SQL-based analysis can connect natural-language operator questions to structured BESS telemetry, but schema, query, and variable-definition requirements create a practical operator-facing barrier.
Method
A schema-constrained LLM interface generates validated read-only SQL for approved BESS telemetry views, followed by deterministic engineering constraint checks on retrieved measurements.
Results
The framework generated valid queries, retrieved operational information, and identified repeated voltage violations, reactive-power overshoot, and active-power tracking performance in case studies.
Takeaways & Limitations
LLM-assisted monitoring can connect structured grid telemetry with automated engineering assessment for BESS operation analysis.
Takeaways & Limitations
The evaluation did not include a formal operator-timing or usability study against deployed ADMS/DERMS dashboards.

Abstract

from arXiv · show

Battery energy storage systems (BESS) are increasingly used in distribution networks for voltage regulation and demand response, which increases the volume and complexity of operational telemetry available to grid operators. This paper presents an AI-enabled monitoring framework that connects a large language model (LLM) interface with a structured telemetry database for BESS-integrated distribution system analysis. Operator questions are submitted in natural language and translated into validated SQL queries using predefined database schema information and approved KPI views. Retrieved measurements, including bus voltages, state of charge, active power, and reactive power, are evaluated against engineering constraints for voltage limits, BESS operation, and demand response tracking. The framework is validated using hardware-in-the-loop co-simulation data from a BESS-equipped distribution feeder operating under reactive power-based voltage control and price-driven demand response. Case studies show that the framework generates valid database queries, identifies repeated voltage violations, detects reactive power overshoot, and evaluates active-power tracking performance. The results show that LLM-assisted monitoring can connect structured grid telemetry with automated engineering assessment for BESS operation analysis.

I. INTRODUCTION

DER- and BESS-rich distribution feeders generate complex, multi-variable telemetry that makes manual operator assessment increasingly inefficient. The paper addresses this gap with a schema-constrained LLM-to-SQL monitoring pipeline and engineering constraint assessment for structured grid telemetry.

Motivation: DER-rich feeders require simultaneous interpretation of active and reactive power, references, bus voltages, state of charge, operating mode, and event timing.Measurements span multiple nodes, phases, devices, and control intervals, increasing operator burden as cyber-physical telemetry and IoT integration expand.
Problem: Existing automated methods perform fixed-function forecasting or control assessment but do not translate natural-language operator questions into database operations.SQL-based analysis can connect operator questions with structured telemetry to retrieve time windows, aggregate measurements, rank violations, and compute tracking errors.
Problem: Without an LLM interface, operators must select KPI views, formulate SQL filters or joins, aggregate records, compare limits, and interpret numerical results manually.The process becomes slower when questions combine voltage violations, reactive-power overshoot, and active-power analysis.
Contribution: The proposed pipeline converts natural-language questions into validated read-only SQL queries restricted to predefined KPI views for BESS-integrated distribution telemetry.It also assesses retrieved measurements against voltage regulation, active-power tracking, reactive-power tracking, state-of-charge, and demand-response limits.

II. SYSTEM ARCHITECTURE AND METHODOLOGY

The framework links natural-language operator queries to structured BESS telemetry in PostgreSQL through separate translation, database execution, and engineering constraint-evaluation functions.

Architecture: The architecture connects operator-facing natural-language queries with structured BESS telemetry stored in a PostgreSQL database.This provides the data pathway for BESS operational monitoring.
Architecture: Three separated functions perform natural-language translation, database execution, and engineering constraint evaluation.The separation structures the monitoring workflow into distinct processing stages.
Methodology: The separation prevents the language model from directly interpreting raw telemetry without database validation or power-system constraint checks.This combines database validation with engineering assessment before operational conclusions are formed.

A. Operational Constraint Framework

The framework converts retrieved telemetry into deterministic engineering assessments using predefined power-system operating bounds rather than subjective language-model judgment. It evaluates voltage regulation and BESS active-power tracking by comparing measurements with defined references and limits.

Constraint evaluation: Retrieved telemetry is converted into engineering assessments through deterministic constraint logic.The assessments use predefined power-system operating bounds rather than subjective language-model judgment.
Voltage regulation: Voltage regulation is assessed by comparing bus voltage with the allowable per-unit operating range.
Active-power tracking: Active-power tracking is assessed by comparing measured BESS active power, Pmeas, with the active-power reference, Pref.The comparison is made during demand-response operation.

B. LLM-Assisted Query Pipeline

The pipeline uses deterministic LLM-based SQL generation to translate operator questions into validated database queries. Retrieved results are evaluated against engineering constraints and returned as concise operational assessments or visual outputs.

LLM-assisted query generation: The implementation uses gpt-4o-mini with deterministic decoding to reduce variability during SQL generation.Access was limited to gpt-4o-mini or legacy gpt-3.5-turbo because of free-tier account restrictions.
Query validation: The validation stage rejects unsafe or out-of-scope SQL, including multiple statements, unsupported joins, and unapproved query patterns.Validated SQL is then executed against the PostgreSQL database.
Engineering assessment and outputs: Retrieved measurements are evaluated by an engineering constraint layer before being formatted as concise operational assessments for operators.The framework can return results as text, dashboards, or plots and tables.

III. CYBER-PHYSICAL CO-SIMULATION SETUP

The framework is evaluated with synchronized time-series data from a real-time cyber-physical co-simulation coupling feeder power-flow analysis, edge-controller communication, and HIL-based BESS inverter emulation. The setup records operating measurements and commands needed for LLM-assisted monitoring and engineering assessment.

Co-simulation architecture: The evaluation uses synchronized BESS operating measurements generated by a real-time cyber-physical co-simulation rather than static records.The environment couples feeder-level power-flow analysis with edge-controller communication and HIL-based inverter emulation.
Co-simulation architecture: OpenDSS solves feeder power flow and updates network voltage response under changing BESS injections.The telemetry includes bus voltage, active-power response, reactive-power response, SOC, reference commands, and event-status records.
LLM-assisted monitoring workflow: The monitoring workflow receives a natural-language question, generates SQL, validates it against approved views and permitted command types, and executes it against PostgreSQL.The retrieved result set is then evaluated to produce a textual assessment and dashboard visualization.
Co-simulation architecture: HIL represents the localized BESS inverter response and returns measured inverter outputs corresponding to controller references.Raspberry Pi edge controllers exchange voltage measurements, active- and reactive-power setpoints, measured BESS responses, synchronization signals, and device-level records through MQTT.

IV. CASE STUDY AND RESULTS

The case study compares the proposed framework functionally with manual monitoring and evaluates it using hardware-in-the-loop telemetry from a BESS-integrated distribution system. The framework automates query formulation, retrieval, and constraint assessment while retaining read-only database access.

Functional comparison: The framework automates KPI query formulation, telemetry retrieval, and engineering constraint assessment that manual monitoring requires operators to perform.Manual monitoring involves selecting KPI views, nodes, devices, and time windows; modifying SQL filters; aggregating records; comparing limits; and interpreting results.
Study scope: The comparison is functional rather than time-based, with formal operator-timing and usability evaluation against deployed ADMS/DERMS dashboards deferred to future work.The study does not establish time savings or deployed-dashboard usability.
Evaluation setup: Evaluation uses hardware-in-the-loop co-simulation telemetry from a BESS operating under reactive power-based voltage control and price-driven demand response.The evaluation comprises a batch prompt suite testing SQL validity and additional assessment components described in the case study.

A. Case A: Voltage Stability Duration Assessment

The framework identified Node 56 as the most voltage-vulnerable location, with sustained undervoltage below the acceptable 0.95–1.05 pu range. It quantified the violation duration and worst observed voltage during the run.

Voltage-limit assessment: The framework queried the v_voltage_violations view to collect timestamps outside the 0.95–1.05 pu operating range.The query supported the voltage-limit duration assessment for the most vulnerable node.
Voltage-limit assessment: 1,125 timestamps of violations identified Node 56 as the network’s most voltage-vulnerable location.The violations were associated with all three phases at Node 56.
Voltage-limit assessment: 0.9302 pu was the worst observed undervoltage at 2026-04-01 21:42:45 UTC, 0.0198 pu below the 0.95 pu lower limit.The engineering assessment labeled the condition vulnerable.
Voltage-limit assessment: About 1,000 seconds (≈16.7 minutes) were spent outside the acceptable voltage limits at Node 56.Figure 2 shows sustained undervoltage excursions below the 0.95 pu lower operating bound during the evaluated run.

B. Case B: Identification of the Most Voltage-Vulnerable Node

The framework identified Node 56 as the feeder’s most voltage-vulnerable node, with 621 violation events, all undervoltage, and recommended investigating local voltage-support conditions.

B. Case B: Identification of the Most Voltage-Vulnerable Node: Node 56 voltage ranged from 0.9302 pu to 0.9499 pu, with a mean of 0.9455 pu and maximum deviation of 0.0198 pu.All 621 recorded events were undervoltage, with zero overvoltage events.
B. Case B: Identification of the Most Voltage-Vulnerable Node: Node 56 recorded 621 voltage violation events, all undervoltage and spanning 3 phases, making it the most vulnerable monitored node.The framework ranked monitored buses by total violation count and returned one summary row per node.
B. Case B: Identification of the Most Voltage-Vulnerable Node: The assessment labeled Node 56 vulnerable and recommended investigating feeder or transformer tap settings, local reactive power support, and conductor or loading conditions.Suggested support measures included capacitor or VAR control near Node 56.

C. Case C: Reactive Power Overshoot Detection

During Volt-VAR control, reactive power overshoot coincided with voltage violations at four nodes. Node 56 was most affected, while the constraint layer labeled the overall condition stable.

Reactive Power Overshoot Detection: The framework identified four nodes where reactive power overshoot coincided with voltage violations during Volt-VAR control.It matched node and time across approved voltage-control and voltage-violation views, requiring max_q_overshoot > 0 and an active voltage-violation flag.
Reactive Power Overshoot Detection: 621 overlapping events made Node 56 the most affected, with a maximum voltage drop of 0.0198 pu.Node 56 had the largest observed voltage deviation among the affected nodes.
Reactive Power Overshoot Detection: Node 13 had 285 overlapping events and a maximum drop of 0.0102 pu, followed by Node 1 with 186 events and 0.0075 pu.These values ranked Node 13 and Node 1 behind Node 56 by coincident-event count and voltage deviation.
Reactive Power Overshoot Detection: Node 57 was least impacted, with 33 coincident events and a maximum deviation of 0.0025 pu, and the overall condition was labeled stable.The constraint layer judged the voltage changes insufficient to indicate severe instability.

D. Case D: Demand Response Active-Power Tracking

The framework evaluated demand-response active-power tracking across 50,000 samples and found large, sustained deviation between commanded and delivered power. The run was classified as vulnerable, prompting review and retuning of the active-power control loop and limit handling.

Case D: Demand Response Active-Power Tracking: The framework queried the v_kpi_run_summary view and returned one summary row covering 50,000 samples from 2026-04-01 12:00:00 UTC to 2026-04-02 05:21:35 UTC.The query collected overall active-power tracking results for all Demand Response times.
Case D: Demand Response Active-Power Tracking: 0.8529 average DR tracking error exceeded the severe threshold of 0.1, indicating large and sustained deviation between requested and active power.The constraint layer marked the condition as vulnerable.
Case D: Demand Response Active-Power Tracking: The framework assessed that the BESS did not track the active-power reference well during demand response and labeled the condition vulnerable.The assessment recommended reviewing and retuning the active-power control loop and limit handling.
Case D: Demand Response Active-Power Tracking: Figure 4 compares Pref with Pmeas across the full DR dispatch window, illustrating the sustained tracking deviation identified by the framework.The reference command and measured BESS response were compared over the evaluated run.

V. CONCLUSIONS

The paper presents an AI-enabled monitoring framework that integrates an LLM with a PostgreSQL telemetry database for BESS operation analysis. It demonstrates schema-constrained monitoring feasibility while identifying user-efficiency comparisons and live-feeder deployment as future work.

Contributions: The framework integrates an LLM with a PostgreSQL telemetry database, translating operator questions into SQL and applying validation and deterministic constraint checks.The LLM provides a natural-language interface, while the database and checks control numerical and engineering content.
Contributions: The study demonstrates the technical feasibility of schema-constrained LLM-assisted monitoring for BESS operation analysis.
Future Work: Future work will compare user efficiency with conventional dashboards, manual SQL workflows, and ADMS/DERMS interfaces, and implement the system on live distribution feeders.The planned live deployment would allow operators to query telemetry as it is generated.