Skip to main content
Version: Next

What are Interventions and how do they work?

Once constraints are identified, the HCM allows operators to explore strategies to resolve them through the Intervention Module. This module models changes to both system-wide and local conditions, enabling comparative analysis of mitigation options against the base case. The Intervention Module is a separate module within the Energy Workbench platform, designed to work seamlessly with the HCM. Contact Zepben to enable this module.

For a practical walkthrough of the parent work package requirements, configuration, and common pitfalls, see How to run an Intervention Work Package.

note

The Intervention Module is intended to run either on a single year or a range of contiguous years, not on multiple non-contiguous years. Attempting to do so will not result in an error, but will likely produce unexpected results.

For example:

  • Valid: {2026}, or {2026,2027,2028,2029,2030}
  • Invalid: {2026,2030}

The Intervention Module produces results using the same framework as the core HCM, allowing direct comparison of constraint patterns before and after applying mitigation strategies.

Systemic Interventions​

Systemic interventions are applied across the entire network. Examples include:

  • Phase rebalancing (phaseRebalanceProportions)
  • Load reshaping (loadReshaping) - e.g. controlled load power shifting, tariff redesign
  • Dynamic voltage management (dvms)

Local Interventions​

Local interventions are targeted at specific locations. Examples include:

  • Installation of community batteries (COMMUNITY_BESS)
  • LV STATCOMs (Static Synchronous Compensators) (LV_STATCOMS)
  • Off-load tap optimisation (DISTRIBUTION_TAP_OPTIMIZATION) - static, once-per-year tap changes on distribution transformers based on historical voltage patterns from the parent work package
  • Distribution transformer OLTC retrofit (DISTRIBUTION_TX_OLTC) - installation of on-load tap changers on distribution transformers, enabling dynamic voltage regulation at the LV level
  • Thermal line upgrade (THERMAL_LINE_UPGRADE) - conductor replacement on overloaded lines, sized to the catalogue
  • Voltage line upgrade (VOLTAGE_LINE_UPGRADE) - lower-impedance conductor replacement to reduce voltage swing
  • Thermal transformer upgrade (THERMAL_TRANSFORMER_UPGRADE) - transformer replacement sized to the catalogue for overloaded transformers

Why Use Each Intervention​

For full configuration options and worked examples, see Interventions Options.

LOAD_RESHAPING​

Use LOAD_RESHAPING when the problem is about when customers use energy, not a specific piece of network. Shifting demand or generation off peak (through tariff reform or controlled load hot water, for example) can relieve a constraint with no equipment installed. It's the one intervention that changes customer behaviour rather than the network, so it's worth trying before or alongside asset-based reinforcement.

Expected impact: shifting load off the targeted period reduces thermal loading and voltage movement during that period, but can push both up at whatever time the load or generation lands instead, as it moves the problem in time rather than removing it.

COMMUNITY_BESS​

Use COMMUNITY_BESS over LV_STATCOMS when the problem is thermal (or a mix of thermal and voltage), or when shifting energy in time would help more than just correcting voltage on the spot. A battery can charge through a solar-driven voltage rise and discharge into the evening peak, covering both without needing two separate interventions.

Expected impact: reduces thermal and voltage excursions at the battery's location, though the operating mode (peakshave, time, profile, etc) decides when it actually charges and discharges, so the wrong mode for the load pattern can mean little real impact.

LV_STATCOMS​

Use LV_STATCOMS over COMMUNITY_BESS when the problem is voltage only, not thermal, and a faster, cheaper fix than a battery will do. STATCOMs correct voltage instantly through reactive power, but they don't store or shift energy, so thermal overloads are outside their reach. They also only work where the network's X/R ratio is high enough for reactive power to actually move the voltage (see minimum_x_r_ratio below). On a short, resistive LV cable a STATCOM has little effect, and BESS or a line upgrade is more appropriate.

Expected impact: moves voltage back toward nominal at the installed location (sourcing VArs raises it, sinking them lowers it) with no effect on thermal loading, since only reactive power is involved.

DVMS​

Use DVMS when voltage issues span a whole zone substation's service area rather than sitting on one or two LV feeders, and continuous, real-time correction is needed rather than a static yearly adjustment. It's the most responsive of the three tap-control interventions (DVMS, DISTRIBUTION_TAP_OPTIMIZATION, DISTRIBUTION_TX_OLTC), but also the most expensive computationally, since it solves the network one time step at a time. Use DISTRIBUTION_TAP_OPTIMIZATION or DISTRIBUTION_TX_OLTC instead when the issue is confined to specific distribution transformers, or rolling out DVMS is not feasible.

Expected impact: shifts customer voltages across the whole zone substation's service area toward the configured target band, boosting where too low and bucking where too high. It has no thermal effect, since it's only changing tap ratio, not current.

PHASE_REBALANCING​

Use PHASE_REBALANCING when the constraint comes from uneven loading across phases A, B and C, not from voltage magnitude or thermal overload on its own. Rebalancing can improve voltage as a side effect of evening out the phases, but it won't address a thermal or voltage problem that exists independently of phase imbalance.

Expected impact: reduces phase voltage imbalance directly, and can ease thermal loading on whichever phase was carrying the most, as a side effect of spreading customers more evenly - but it doesn't reduce total network load or generation, so it won't help a thermal or voltage problem that's already balanced across phases. It targets customer count, not load, so an even customer split doesn't guarantee an even load split.

DISTRIBUTION_TAP_OPTIMIZATION​

Use DISTRIBUTION_TAP_OPTIMIZATION over DISTRIBUTION_TX_OLTC when the existing transformers don't need new hardware and a cheaper, once-a-year static tap adjustment is enough to correct a persistent (not transient) voltage bias. It works with the tap changer already there rather than retrofitting anything, so it's the cheaper option whenever the bias is consistent enough for a yearly correction to keep up.

Expected impact: moves the transformer zone's voltage toward nominal (boost or buck, depending on which tail of the voltage distribution dominates) with no thermal effect, since it's only changing tap ratio. Because it only changes once a year, it won't help a voltage issue that varies significantly within the year.

DISTRIBUTION_TX_OLTC​

Use DISTRIBUTION_TX_OLTC over DISTRIBUTION_TAP_OPTIMIZATION when a transformer's voltage issues vary too much within a year for one static setting to handle, and dynamic, load-responsive tap control is worth the cost of retrofitting an OLTC. It sits between DISTRIBUTION_TAP_OPTIMIZATION (static, no new hardware) and DVMS (dynamic, but at the zone substation rather than the transformer).

Expected impact: moves the transformer's downstream voltage toward nominal, much like DISTRIBUTION_TAP_OPTIMIZATION but responding continuously to load instead of once a year. It has no thermal effect.

THERMAL_LINE_UPGRADE​

Use THERMAL_LINE_UPGRADE when the study shows one or more lines can't carry the modelled load or generation without exceeding their normal thermal rating. A thermal overload caps how much demand or distributed generation the network can host, and repeated overloads usually mean the conductor is no longer adequate for the forecast.

The intervention tests a practical fix: replacing the conductor with a compatible item from conductor_catalog. It ranks lines by the greatest weighted thermal overload exposure, then sizes the replacement so peak current stays under the configured target loading percentage.

Expected impact: reduces the line's thermal loading toward targetLoadingPct. Any change to voltage movement is a side effect of the new conductor's different impedance, not something the sizing targets. The conductor is applied to the original CIM line asset or assets, not just the simplified study object, and the benefit is estimated from the parent work package. Since changing one line can shift flows elsewhere, rerun and compare against the parent to confirm the resulting network loading.

How much of that impact you actually get depends on conductor_catalog. Every overloaded line produces a candidate, but only candidates with a compatible catalogue row are applied, and the rest are skipped. If the catalogue dosn't have entries at the ratings your network needs, you will not see the full benifit of this intervention.

VOLTAGE_LINE_UPGRADE​

Use VOLTAGE_LINE_UPGRADE when customers in a transformer measurement zone see excessive voltage movement, and line impedance is a likely part of the cause. Long lines, and lines carrying changing load or generation, can drag voltage down on import and push it up on export. A lower-impedance conductor can reduce that movement along the affected path.

The intervention estimates which line replacements would help most by combining the zone's voltage problem with each related line's observed movement. It's a way to compare reinforcement options across a feeder, not a guarantee of a particular voltage result before you rerun.

Expected impact: reduces voltage swing (the gap between the zone's highest and lowest section voltage), sized toward targetVoltageSwingPu. It's not sized for a thermal outcome, though a lower-impedance conductor can incidentally raise current-carrying capacity too. The conductor change is applied to the original CIM line asset or assets mapped to the candidate simplified line - the simplified line is just evidence for the candidate, not what's ultimately modified - and since the estimate is path-based, it can involve more than one original line.

Candidates are ordered by estimated value recovered per metre upgraded, so the highest-ranked candidate is the most efficient reinforcement rather than necessarily the worst voltage problem on the feeder. Read the ranking as a prioritised work list, not a severity list.

The value being apportioned is the zone's combined voltage-and-thermal value at risk, the same measure used to rank community batteries. A zone only becomes eligible by failing a voltage test, but once eligible, one that is also thermally overloaded carries more value than one with the same voltage problem alone - so it tends to rank higher. If you are using this intervention to target voltage specifically, check each candidate's voltage figures rather than relying on rank order alone.

THERMAL_TRANSFORMER_UPGRADE​

Use THERMAL_TRANSFORMER_UPGRADE when a distribution transformer is the asset capping how much load or generation can connect downstream. The intervention looks for transformers exceeding their normal thermal rating in the parent study and tests a larger, compatible transformer from transformer_catalog.

It's a targeted capacity reinforcement: more apparent-power headroom, not a change to customer demand, generation, or controls. Most useful when the transformer itself is the bottleneck identified by the study.

Expected impact: reduces the transformer's thermal loading toward targetLoadingPct. It's sized for thermal capacity only, so it won't by itself fix voltage swing, voltage-limit, or downstream line constraints - those need the relevant voltage or line intervention, and should be checked in the rerun. The replacement transformer is applied to the original CIM transformer behind the overloaded simplified OpenDSS one.

How Candidate Generation and Allocation Works​

Local interventions use a two-stage process to identify and deploy solutions at problem locations: candidates are generated from the parent work package's results, then allocated subject to a yearly limit.

The description below covers COMMUNITY_BESS, LV_STATCOMS, DISTRIBUTION_TAP_OPTIMIZATION and DISTRIBUTION_TX_OLTC, which select candidates using measurement-zone metrics and (except for DISTRIBUTION_TAP_OPTIMIZATION) the intervention_candidate_criteria table.

The three asset upgrade types - THERMAL_LINE_UPGRADE, THERMAL_TRANSFORMER_UPGRADE and VOLTAGE_LINE_UPGRADE - follow the same generate-then-allocate shape but differ in two ways: they read the asset level summary tables rather than intervention_candidate_criteria, and allocation has to find a compatible row in conductor_catalog or transformer_catalog, so a candidate can be generated and then not applied. See Interventions Options for how each one selects and sizes its replacement.

Process Flow​

Base Work Package Results
         ↓
Does location exceed thresholds (as defined in intervention_candidate_criteria)? ──No──> Skip
         ↓ Yes
      Candidate Created (stored in intervention_candidates)
      (location, year, severity)
         ↓
      Ranked by Severity
      (most severe constraints as per criteria = rank 1, next = rank 2, etc.)
         ↓
      Allocated by Year
      (up to limit per year, as per intervention config `allocationLimitPerYear`)
         ↓
      Rerun Work Package with changes made
         ↓
Intervention Work Package results

How It Works​

1. Candidate Generation

  • Reads the parent work package's results from the database, so the base must have been written with writerType=POSTGRES - a Parquet parent yields no candidates for any intervention type
  • Analyzes parent work package results for each measurement zone and year
  • Creates candidate if location exceeds ALL specified thresholds in intervention_candidate_criteria (DISTRIBUTION_TAP_OPTIMIZATION is the exception - its thresholds come from the work package config values rather than the intervention_candidate_criteria table, see Interventions Options)
  • Tags candidate with the earliest year the threshold is exceeded

2. Ranking

  • COMMUNITY_BESS: Sum of gen_exceeding_normal_thermal_voltage_cecv + load_exceeding_normal_thermal_voltage_vcr
  • LV_STATCOMS: Sum of gen_exceeding_normal_voltage_cecv + load_exceeding_normal_voltage_vcr
  • DISTRIBUTION_TX_OLTC: Sum of gen_exceeding_normal_voltage_cecv + load_exceeding_normal_voltage_vcr (same as LV_STATCOMS)
  • DISTRIBUTION_TAP_OPTIMIZATION: Weighted score from voltage deviation percentiles and hours outside limits
  • THERMAL_LINE_UPGRADE and THERMAL_TRANSFORMER_UPGRADE: Weighted overload energy, importValue * overload_kwh_import + exportValue * overload_kwh_export
  • VOLTAGE_LINE_UPGRADE: Estimated value recovered per metre of line upgraded, so ranking reflects efficiency of the reinforcement rather than severity alone
  • Lower rank number = more severe = higher implementation priority (for VOLTAGE_LINE_UPGRADE, higher value per metre)

3. Allocation

  • Deploys interventions to highest-ranked candidates first
  • Respects allocationLimitPerYear constraint
  • Phases deployment across years based on available capacity

Example​

Candidates found:
- Location A: 2026, severity 150 → Rank 2
- Location B: 2027, severity 200 → Rank 1
- Location C: 2026, severity 100 → Rank 3

With allocationLimitPerYear = 2:
- 2026: Install at A, C (B not yet eligible; 2026 limit filled)
- 2027: Install at B

Key Points:

  • Candidates are generated from parent work package analysis (not discovered during solve)
  • Worst problems addressed first within yearly deployment constraints
  • Year assignment determines when intervention becomes active in simulation

How DVMS Control Logic Works​

DVMS runs two sequential control loops per time step. Loop 1 runs first; loop 2 only runs if loop 1 made no tap change attempt.

Control Loop 1 - Customer count outside voltage limits​

Loop 1 always moves the tap one position at a time.

For each time step:

  1. Solve the network model.
  2. Retrieve the per-unit voltage from each load with a base voltage under 1000 V.
  3. Read the voltage at the configured lowerPercentile and upperPercentile and compare each against lowerLimit/upperLimit.
  4. If either percentile reading is outside its limit:
    1. If only one side is breached, estimate whether a one-step tap change in the corresponding direction would reduce the total count of customers outside limits, and apply it if so.
    2. If both sides are breached at once, estimate both a one-step increase and a one-step decrease, and apply whichever one is a genuine improvement (fewer customers outside limits than both the current state and the other direction) - if neither qualifies, no change is made this iteration.
    3. Retrieve updated load voltages after any applied change. If the total count of customers outside limits has increased, revert the tap change and re-solve.
    4. Repeat from step 1 up to maxIterations. On the very first time step, DVMS is allowed extra iterations to find a good starting tap position - the initial tap isn't always a sensible starting point, so this lets it settle in properly before normal operation begins. Once within limits, or the iteration cap is reached, finalise the time step. DVMS logs an internal warning if the tap position is at a mechanical limit and a further change is attempted, and then proceeds to the next step.

Control Loop 2 - Average voltage deadband regulation​

Loop 2 simulates a basic deadband regulator targeting the average load voltage. It is skipped if loop 1 attempted any tap change during that time step, including changes that were subsequently reverted.

  1. If the average voltage across all loads (base voltage < 1000 V) is outside the regulator deadband, attempt a tap change.
  2. Estimate the effect of the proposed tap change on the number of customers outside the DVMS voltage limits.
  3. If the customer count outside limits does not increase beyond acceptable levels (see allowPushToLimit), apply the tap change and re-solve the time step.
  4. Repeat until the average voltage is within the deadband, or until a tap change would worsen the customer count beyond acceptable levels, or until the number of tap changes per time step reaches the limit set by maxTapChangePerStep. If a tap change unexpectedly increases the count, revert and finalise.

Notes​

  • Loop 1 and loop 2 each separately track the tap direction they last moved in. If either loop's estimated direction reverses during its own iterations within a single time step, that loop stops and the time step is finalised.
  • allowPushToLimit: When True, control loop 2 permits tap changes that improve the average voltage even if they move a small proportion of customers outside the DVMS voltage limits. This allows the regulator to make progress in networks where any tap change affects some customers adversely.
  • Multi-phase loads: DVMS treats each phase voltage of a load as a separate customer measurement. On feeders with predominantly multi-phase customers, this multiplies the effective customer count and may affect percentile-based calculations.

For DVMS configuration parameters, see DVMS in Interventions Options.

How Distribution Tap Optimization Decides Tap Changes​

Note: p.n. stands for per-unit-in-nominal-LV, which is 400V phase-to-phase or 230V phase-to-ground for Australia.

CASE 1: voltage_delta_avg (in volts) > averageVoltageSpreadThreshold (significant voltage swing detected):

a) Both under and over limit hour thresholds exceeded:

  • Compute: tapWeightingFactor = (|V99_avg - 1.0| * hours_over_limit) - (|V1_avg - 1.0| * hours_under_limit)
    • If tapWeightingFactor < tapWeightingFactorLowerThreshold: adds 1-step boost candidate
    • If tapWeightingFactor > tapWeightingFactorUpperThreshold: adds 1-step buck candidate
    • Otherwise: no candidate (voltage issues are roughly balanced)

b) voltageOverLimitHoursThreshold exceeded (but not voltageUnderLimitHoursThreshold) AND V99_avg > 1.1 p.n.:

  • Adds 1-step buck candidate

c) voltageUnderLimitHoursThreshold exceeded (but not voltageOverLimitHoursThreshold) AND V1_avg < 0.94 p.n.:

  • Adds 1-step boost candidate

CASE 2: voltage_delta_avg (in volts) ≤ averageVoltageSpreadThreshold (smaller voltage swing):

a) V1_avg > 1.0 p.n. AND V99_avg > 1.1 p.n. (voltages predominantly high):

  • If voltageOverLimitHoursThreshold exceeded but voltageUnderLimitHoursThreshold not exceeded: adds 2-step buck candidate
  • If both thresholds exceeded: uses tap weighting prioritization

b) V1_avg in [0.97, 1.0] p.n. AND V99_avg > 1.1 p.n. AND voltageOverLimitHoursThreshold exceeded but voltageUnderLimitHoursThreshold not exceeded:

  • Adds 1-step buck candidate

c) V1_avg < 0.91 p.n. AND V99_avg < 1.075 p.n. (voltages predominantly low):

  • If voltageUnderLimitHoursThreshold exceeded but voltageOverLimitHoursThreshold not exceeded: adds 2-step boost candidate
  • If both thresholds exceeded: uses tap weighting prioritization

d) V1_avg < 0.94 p.n. AND V99_avg in [1.075, 1.1] p.n. AND voltageUnderLimitHoursThreshold exceeded but voltageOverLimitHoursThreshold not exceeded:

  • Adds 1-step boost candidate

Ranking (when allocationLimitPerYear is set)​

Candidates are ranked by the p.u. deviation of the relevant worst-case voltage percentile from nominal (1.0 p.u.):

  • Boost candidates: ranked by |V1_avg - 1.0| - greatest undervoltage deviation first
  • Buck candidates: ranked by |V99_avg - 1.0| - greatest overvoltage deviation first

For DISTRIBUTION_TAP_OPTIMIZATION configuration parameters and metric definitions, see DISTRIBUTION_TAP_OPTIMIZATION in Interventions Options.

Combining Interventions​

There are two distinct ways to combine interventions: chaining work packages via parentWorkPackageId, and stacking multiple intervention blocks within a single work package.

Chaining via parentWorkPackageId​

parentWorkPackageId can point at any prior work package, not just a non-intervention baseline. This means you can, for example, set parentWorkPackageId on an intervention work package.

Each work package's network model is built independently: the network is always sourced fresh (never inherited from another work package's simulated output), and only that work package's own applied intervention(s) are present in its simulation. Chaining parentWorkPackageId only carries forward metrics - if running an intervention work package off an existing intervention work package, the second work package only looks at the network_performance_metrics_enhanced results to decide where its own interventions should go. The first work package's actual applied changes (equipment placed, taps changed, etc.) are not present in the second.

This means:

  • Comparing independent interventions against the same baseline (supported): Each is a clean before/after comparison against a baseline non-intervention work package.
  • Chaining to target a second intervention at residual problems (supported, but not cumulative): The second work package will site its own intervention(s) using the first work package's post-intervention metrics, but its results only reflect its own intervention(s) applied to the base network - not the first work package's changes plus its own.

Stacking Interventions​

A single work package's intervention block can combine one candidate intervention (candidateIntervention) with any combination of phaseRebalanceProportions, dvms, and loadReshaping. All of the interventions set are applied to the same network and simulated together, giving a cumulative result, unlike chaining, which only carries metrics forward between separate simulations.

Two candidate interventions (e.g. COMMUNITY_BESS and LV_STATCOMS) cannot be stacked in the same work package, since candidateIntervention only accepts one. To combine two candidate interventions, chain them via parentWorkPackageId instead (not cumulative, see above).