PaperlayerView exact revision on arXiv

Source-linked AI summary

Explainable Post-Disaster Grid Observability Recovery Using Human-Oversight Agentic LLMs

Biswas Rudra Jyoti Arka, Sadman Sakib, Md. Zahidul Islam, Shamsun Nahar Edib

arXiv:2609.16774v1eess.SYcs.SY

TL;DR

Post-disaster PMU outages impair observability when operators need to make restoration decisions, while limited resources require sequential repairs. This paper uses an LLM to coordinate validated restoration tools and support operator review and interaction. Simulations report observability recovery comparable to MILP-based restoration, with step gaps varying by failure rate and budget.

  • Problem

    Post-disaster PMU outages reduce grid observability, while existing restoration methods often provide limited explanation, traceability, and operator interaction.

    Source: §I · p. 1

  • Method

    An agentic LLM orchestrates backend restoration tools, explains their plans, and supports operator review and context-aware questions during restoration.

    Source: §I · pp. 1–2, 2) Guarded Tool Calling with Human… · p. 4

  • Results

    Observability recovery is comparable to MILP-based restoration; at a 90% PMU failure rate, the average step gap is 7.76% across budgets of 1–4 PMUs per step.

    Source: §V · p. 7, 1) Comparison with MILP-Based Baseline · p. 7

  • Takeaways & Limitations

    The framework provides tool-grounded explanations, interactive operator support, and human oversight before restoration actions are applied.

    Source: §V · p. 7

    Incomplete runs and step gaps occur mainly under tight budgets, especially with many zones; generation limits and failure to improve observability can also interrupt completion.

    Source: 1) Comparison with MILP-Based Baseline · p. 7

Abstract

from arXiv · show

Post-disaster phasor measurement unit (PMU) outages reduce power-system observability and degrade operator situational awareness, requiring sequential restoration under limited resources. Existing PMU restoration methods based on optimization or heuristics can generate restoration schedules, but they often provide limited support for explanation, traceability, and operator interaction. This paper proposes an agentic tool-calling framework orchestrated by a large language model (LLM) for post-disaster PMU restoration and grid observability recovery. In this framework, the LLM does not directly solve the restoration optimization problem; instead, it coordinates validated backend tools required for post-disaster restoration, including observability assessment, restoration planning, state updates, and operator verification. The framework also maintains a structured tool-call history and execution context that keep restoration decisions traceable and explainable, while enabling context-aware operator question answering during the restoration process. Simulation results on IEEE 30-bus and IEEE 57-bus systems show that the proposed framework achieves observability recovery comparable to a mixed-integer linear programming (MILP) solution, while providing tool-grounded explanations, interactive operator support, and human-overseen execution.

I. INTRODUCTION

Post-disaster PMU outages impair operator visibility just as restoration decisions are critical, and limited resources make restoration sequential. The paper proposes an agentic LLM workflow to coordinate restoration tools while supporting explanation, traceability, and operator interaction.

I. INTRODUCTION

  • Outages can leave operators with limited visibility when restoration and corrective decisions are most critical, while constrained crews, devices, and communications make restoration order determine recovery speed.PMU restoration is therefore a sequential decision problem under resource constraints.Source: §I · p. 1
  • MILP, greedy, and heuristic methods can compute restoration sequences, but their standalone implementations offer limited explanation and interaction for operators examining priorities or applying expertise.The paper identifies a need for an operator-facing workflow that makes restoration traceable, explainable, and interactive.Source: §I · p. 1
  • Direct LLM use in critical power-system decisions is limited by nondeterminism and unsupported numerical or procedural outputs, while prior agentic power-system studies had not addressed sensor restoration.Agentic AI can coordinate external tools and structured outputs across multi-step workflows.Source: §I · p. 1
  • The proposed framework uses an LLM to orchestrate modular restoration operations and explain tool-generated plans, with operator inspection and context-aware questions about restoration state, priority zones, and observability gaps.The workflow supports human oversight before restoration actions are applied.Source: §I · pp. 1–2

II. PROBLEM STATEMENT

The paper frames PMU restoration as a resource-constrained sequence of decisions, then describes an LLM workflow that coordinates deterministic restoration tools and operator review. Its backend includes rolling-horizon planning and zone-aware resource allocation.

II. PROBLEM STATEMENT

  • Restoration must choose failed PMUs at each step to improve observability while preserving active PMUs and respecting limited resources; PMU locations are predefined in the paper’s scope.The stated inputs include installed PMU locations, failures, grid topology, and restoration resources; the output is a restoration sequence.Source: §II · p. 2

III. PROPOSED FRAMEWORK

  • The workflow uses user instructions to invoke backend optimization tools, explains the resulting plan, and lets an operator review, approve, or modify it before the approved action updates system state.The framework maintains context memory for traceability, interactive question answering, and operator-facing explanations; state update assumes field implementation.Source: §III · p. 2

A. Tool-Callable PMU Restoration Functions

  • Restoration-specific operations are implemented as deterministic callable functions with structured inputs and outputs, separating power-system computation from LLM orchestration.The connectivity matrix encodes whether each PMU candidate can observe each bus under the stated rule that a bus is observable if it or a neighbor has a PMU.Source: A. Tool-Callable PMU Restoration… · pp. 2–3
  • The propose_restoration function solves a rolling-horizon MILP for each zone, considering H future steps but proposing only the first step for operator inspection.The formulation preserves active PMUs and constrains newly restored PMUs by the available budget; the horizon advances and the problem is re-solved after state updates.Source: A. Tool-Callable PMU Restoration… · pp. 2–3
  • Zone importance and current observability inform dynamic priority scores and budget allocation, while observability checks guide whether restoration continues and whether inter-zone tie-lines are observable.Simulation can generate random failure scenarios, whereas real operation would use PMU availability data; network partitioning uses k-medoids over shortest-path distances.Source: A. Tool-Callable PMU Restoration… · p. 3

B. Agentic Tool-Calling Framework for PMU Restoration

The framework exposes restoration tools through a structured interface and uses an executor-mediated context to coordinate tool use and human review.

B. Agentic Tool-Calling Framework for PMU Restoration

1) Tool-Calling Interface and Executor Context:

The tool-calling interface routes LLM requests through an executor to deterministic backend functions, while maintaining message history and structured restoration context. Validated outputs update that context and support traceable operator review.

1) Tool-Calling Interface and Executor Context:

  • Each tool declaration specifies a function name, natural-language description, JSON input-parameter schema, and required arguments.The executor mediates access to deterministic backend functions, which perform numerical computation, MILP solving, observability checks, and state updates.Source: 1) Tool-Calling Interface and Executor… · p. 3
  • The executor validates LLM tool calls, fills missing fields from stored context when available, runs the corresponding backend function, and returns its JSON result.Tool outputs are appended to the LLM-visible history and used to update the executor-side context.Source: 1) Tool-Calling Interface and Executor… · p. 3
  • Function outputs are task-specific: observability checking reports zone-level and grid-wide status, while restoration planning returns an MILP-based plan.The ordered message history appends tool outputs as the executor context is updated.Source: 1) Tool-Calling Interface and Executor… · pp. 3–4
  • The structured executor context stores run parameters and restoration states, including budgets, failure rates, zone weights, PMU states, plans, and observability status.The separate LLM-visible message history stores instructions, user requests, tool-call requests, and returned outputs.Source: 1) Tool-Calling Interface and Executor… · p. 4
  • The execution history records tool names, inputs, outputs, explanations, restoration updates, and observability changes for traceability.Operators can review or modify the proposed plan before implementation.Source: 1) Tool-Calling Interface and Executor… · p. 4

2) Guarded Tool Calling with Human Approval:

System instructions constrain the LLM to admissible tools and define execution rules, tool-call order, stopping conditions, grounding, and reporting. The executor validates and records tool calls, while a human can review or modify each proposed plan before implementation.

2) Guarded Tool Calling with Human Approval:

  • The system instruction limits the LLM to admissible restoration tools and sets the tool-call order, stopping condition, grounding requirement, and final-report format.The user task prompt starts the specific restoration case.Source: 2) Guarded Tool Calling with Human… · p. 4
  • Table III presents a representative tool-call trace for a restoration proposal.The trace separates the MILP tool's restoration action from the LLM's output-grounded rationale for operator review.Source: Table III · p. 4, 2) Guarded Tool Calling with Human… · p. 4
  • Before a PMU state update, the operator can review or modify the proposed restoration plan.The executor records outputs and updates context; observability is reevaluated after the state update, and restoration continues until full observability is achieved.Source: 2) Guarded Tool Calling with Human… · p. 4

3) Context-Based Explanation and Interaction:

The framework grounds explanations in tool outputs and stored context, then records them alongside the corresponding decisions. The same context supports operator questions during or after restoration.

3) Context-Based Explanation and Interaction:

  • Each restoration-step rationale uses stored context and tool outputs, and the execution history links explanations to the corresponding tool call and decision.The final report summarizes restored PMUs and their order, final observability, and unresolved gaps.Source: 3) Context-Based Explanation and… · p. 4
  • Operators can ask about observability, priority zones, remaining gaps, and earlier decisions during or after restoration.This provides context-aware support beyond a one-shot optimization result.Source: 3) Context-Based Explanation and… · p. 4

IV. CASE STUDY

The case study validates the framework on IEEE 30-bus and IEEE 57-bus systems across varied failure rates, budgets, and zone counts. Its agent-layer demonstration evaluates capabilities beyond the deterministic MILP restoration tool, with tables identified for operator interaction and rationale consistency.

IV. CASE STUDY

  • The framework is tested on IEEE 30-bus and IEEE 57-bus systems, with failure rates of 30%, 50%, 70%, and 90%, budgets from 1 to 4, and zone counts from 1 to 4.The MILP prediction horizon is H = 3, and the tested LLM is GPT-4o mini.Source: §IV · p. 4

A. Agent-Layer Capability and Value Demonstration

  • The agent-layer evaluation is framed as demonstrating capabilities and added value beyond the deterministic MILP-based restoration tool.Table IV is captioned as context-aware operator interaction during restoration.Source: A. Agent-Layer Capability and Value… · pp. 4–5, Table IV · p. 5
  • Table V is identified as an expert consistency check of LLM-generated rationales.The supplied case-study passages identify the evaluation scope but do not report its outcome.Source: Table V · p. 5

1) LLM tool-call and explanation trace:

The framework separates tool-generated restoration decisions from LLM explanations, supports questions using evolving restoration context, and evaluates whether its rationales match human references.

1) LLM tool-call and explanation trace:

  • The MILP tool produces each restoration action, and the LLM explains its returned plan for operator review.The representative IEEE 57-bus trace illustrates the separation between deterministic computation and language-based explanation.Source: 1) LLM tool-call and explanation trace · p. 5

2) Context-aware operator interaction:

  • Operators can ask follow-up questions about system state, restoration priorities, and remaining observability gaps using the evolving restoration context.The stored context includes active PMU states, zone observability and weights, previous actions, and remaining gaps.Source: 2) Context-aware operator interaction · p. 5

3) Expert rationale consistency evaluation:

  • Across evaluated iterations, LLM rationales follow human reference budget-allocation logic while avoiding unsupported restoration decisions.The two scenarios use IEEE 57-bus with 3 zones, budget 4, and 90% PMU failure, and IEEE 30-bus with 4 zones, budget 3, and 90% failure.Source: 3) Expert rationale consistency… · p. 5

B. Restoration Performance Evaluation

The evaluation tests restoration on IEEE 30- and 57-bus systems across failure scenarios, budgets, and runtime conditions. Observability rises through sequential restoration, with more budget requiring fewer steps and higher failure rates requiring more.

Restoration trajectory

  • For IEEE 30- and 57-bus systems with 4 zones, budget 3, and 90% failure, observability increases after each restoration step until full observability is achieved.The workflow updates the restoration state after each approved action and continues backend optimization calls.Source: B. Restoration Performance Evaluation · p. 6

Budget effects

  • As the available budget increases, fewer restoration steps are required to recover observability.The framework allocates available resources across zones based on priority.Source: B. Restoration Performance Evaluation · p. 6

Failure-rate effects

  • At a fixed budget, higher PMU failure rates require more restoration steps, with step counts also depending on system size and number of zones.Larger or more partitioned systems may require additional coordinated actions to recover full observability.Source: Figure 5 · p. 6, B. Restoration Performance Evaluation · p. 6

Runtime

  • The tested restoration steps take only a few seconds despite including LLM orchestration and explanation; field-crew execution time is excluded.Reported runtime includes backend optimization and was measured on a personal computer with an Intel Core Ultra 7 processor and 64 GB of RAM.Source: B. Restoration Performance Evaluation · p. 6, Figure 4 · p. 6

C. Comparative Study

The comparative study tests whether LLM orchestration coordinates the same restoration functions as a deterministic MILP baseline. Step gaps and incomplete runs are reported for the IEEE 57-bus system, alongside a completion result for IEEE 30-bus.

C. Comparative Study

1) Comparison with MILP-Based Baseline:

  • With zones and budgets varied from 1 to 4, the proposed framework’s average step gap is 7.76% at 90% PMU failure and 0% at 70%; at budgets of 3–4 PMUs per step, the 90% average gap is 3.57%.The step gap is the relative difference in restoration steps versus the deterministic MILP baseline; incomplete runs and gaps mainly occur under tight budgets with many zones.Source: 1) Comparison with MILP-Based Baseline · p. 7
  • Highly constrained runs may remain incomplete when budgets are insufficient, observability stops improving under the current allocation, or the LLM reaches its generation limit.For IEEE 30-bus, the framework achieves a 0% step gap with a 100% completion rate.Source: 1) Comparison with MILP-Based Baseline · p. 7

2) Comparison with LLM Variants:

The comparison finds that simplified LLM variants lack capabilities provided by the proposed framework, which achieves full observability with tool-grounded explanations and traceability. The conclusion reports recovery comparable to MILP-based restoration alongside operator support and identifies further scenarios and incomplete cases for future work.

2) Comparison with LLM Variants:

  • The one-shot prompt-only LLM can report full observability without tool-grounded verification, while the proposed framework achieves full observability with tool-grounded explanations and traceability.Iterative LLM variants remain limited without tool-based MILP optimization, context tracking, and structured verification.Source: 2) Comparison with LLM Variants · p. 7

V. CONCLUSION

  • The framework achieves observability recovery comparable to MILP-based restoration while providing improved traceability, explainability, and interactive operator support.Future work will examine diverse operating scenarios beyond static failures, incomplete cases, optimality gaps, and reducing LLM overhead.Source: §V · p. 7

Related papers

Loading 2609.16774v1…