Pakistan is running one of the fastest consumer-led solar transitions anywhere. According to the Federal Minister for Power, close to 38,000 MW of rooftop solar has been installed, mostly by households and businesses. The result is a classic duck curve: grid demand collapses at midday and spikes after sunset.

Storage is following. About 4.5 GW of battery equipment was imported in the first half of 2026, and the government has announced four 10 MWh utility pilots in distribution-company (DISCO) areas, with a national steering committee overseeing storage and NEPRA reported to be treating batteries as regulated assets.

The engineering question I want to focus on is not which battery to buy but how to prove it worked. That is fundamentally a data and software problem, and one that developers and data engineers are well placed to help solve.

Why nameplate capacity is a poor metric

A battery has two ratings:

•           Power (MW): how fast it can deliver energy.

•           Energy (MWh): how much it stores.

A 10 MWh system at 5 MW gives roughly two hours; at 2.5 MW, four. If a feeder’s evening peak lasts four hours, a two-hour battery shifts the overload rather than removing it. Three other factors decide real-world value, and none appear in the MWh figure:

1. Location: a battery only relieves the transformer it actually offloads at the critical hour.
2. Control strategy: peak shaving, voltage support, frequency response and backup compete for the same state of charge.
3. Environment: at 45°C, lithium-ion systems derate and age faster. So the right question is: what did it measurably change?

Six KPIs, defined as computable quantities

Every pilot should publish a pre-installation baseline and then report these against it:

A minimal KPI calculator

Here is a simple starting point in Python using pandas. It assumes two hourly DataFrames of equal length and comparable season: one for the baseline period and one for operation with the battery.

import pandas as pd

def battery_kpis(df: pd.DataFrame, baseline: pd.DataFrame,
                 peak_hours=range(18, 23)) -> dict:
    """
    df, baseline: hourly DataFrames with a DatetimeIndex and columns
      feeder_mw     - net load on the feeder/transformer (MW)
      bess_mw       - battery power (+ discharge, - charge); zeros in baseline
      curtailed_mwh - solar energy curtailed that hour
      outage_min    - customer-facing outage minutes that hour
    """
    def daily_peak(frame):
        p = frame[frame.index.hour.isin(peak_hours)]
        return p["feeder_mw"].resample("D").max()

    peak_win = df[df.index.hour.isin(peak_hours)]
    discharging = peak_win["bess_mw"] > 0

    discharged = df["bess_mw"].clip(lower=0).sum()
    charged = -df["bess_mw"].clip(upper=0).sum()

    return {
        "avg_peak_reduction_mw": daily_peak(baseline).mean() - daily_peak(df).mean(),
        "avg_peak_hours_discharging": discharging.resample("D").sum().mean(),
        "curtailment_avoided_mwh": baseline["curtailed_mwh"].sum() - df["curtailed_mwh"].sum(),
        "outage_minutes_change": df["outage_min"].sum() - baseline["outage_min"].sum(),
        "round_trip_efficiency": discharged / charged if charged else float("nan"),
    }

This is deliberately naive. A production version needs:

•           Weather and demand normalisation: a hot week will raise peaks regardless of the battery. Regress load against temperature and calendar features, or use a counterfactual model, before attributing changes.

•           Proper reliability indices: SAIFI and SAIDI require customer counts per interruption, not just outage minutes.

•           Auxiliary consumption: cooling loads in Pakistani summers can be significant and belong in round-trip efficiency measured at the meter.

•           Degradation tracking: periodic capacity tests to report usable MWh over time.

Where AI and ML genuinely help

This is the part of the energy transition where software engineers can add real value:

•           Feeder-level forecasting: predicting next-day solar output and evening load so batteries charge only from genuine surplus and discharge when the peak actually arrives.

•           Counterfactual baselines: ML models that estimate what load would have been without the battery, which is far more defensible than before/after comparisons.

•           Dispatch optimisation: scheduling that balances peak relief against cycling degradation.

•           Fleet coordination: Pakistan’s millions of home batteries mostly charge and discharge independently. With digital meters and the right tariffs, aggregation software could turn them into a grid resource.

Engineering gotchas worth knowing

•           Batteries are not automatic backup. Most grid-connected systems use grid-following inverters and trip on grid loss. Islanded operation needs grid-forming control, coordinated protection and reserved state of charge.

•           No double-counting. The same stored energy cannot be promised to the evening peak and held as outage reserve. Model state-of-charge allocation explicitly.

•           Charging is not free. Log the charging source; a battery charged from fossil-heavy hours delivers little system value.

•           Compare alternatives. Sometimes a wire wins: the World Bank’s US$375.9 million grid project uses voltage-support equipment to unlock 640 MW of curtailed wind.

Open data would accelerate everything

The four pilots are small, which makes them ideal experiments. If their specifications, baselines, telemetry (at sensible granularity) and costs were published in a common open format, researchers and developers could build and validate evaluation tools, and regulators could compare configurations before scaling.

Announcing battery capacity is not the same as proving its value. Proving it is a data pipeline.

Over to you

If you work on energy data, forecasting or grid software: what would you add to this KPI set, or to the calculator? I would welcome pull-request-style suggestions in the comments.

About the author

Dr Habib Ur Rahman Habib (SMIEEE, MIET) is a UK-based energy innovation scientist. With over 16 years of international academic, research, and teaching experience across Pakistan, China, Europe, and the UK, his expertise spans power systems, power electronics, HVDC, renewable-energy integration, energy storage, intelligent grids, and AI-enabled energy systems. He is a Pakistan Engineering Council Professional Engineer and an HEC-approved PhD supervisor. He can be reached at habib_rahman_habib786@yahoo.com.