What is Intrinsic Hosting Capacity Mode and why is it useful?

Paid Feature - Only available for some customers

This feature is only available to certain customers. If you are interested in using this feature, please contact Zepben for more information.

What is Intrinsic Hosting Capacity Mode?

Standard hosting capacity modelling answers the question: given a specific DER deployment scenario, does the network have problems? Intrinsic Hosting Capacity Mode inverts that question: how much additional load or generation can the network actually support before hitting a limit?

It starts from a chosen network state and systematically adds synthetic load or generation - in configurable increments - to every relevant injection point simultaneously, re-solving the power flow after each step. The search continues until a configured voltage or thermal constraint is breached, at which point the last valid state defines the hosting capacity.

The Australian Energy Regulator (AER) defines intrinsic hosting capacity as "the base level of DER export hosting capacity that a distribution network already provides because assets built to supply customer load have some inherent ability to support reverse power flow without additional investment".

Two Sub-modes

LV Hosting Capacity

This sub-mode answers: how much additional export or import capacity is there for customers under each distribution transformer?

The network is divided into capacity groups - one per distribution transformer. Load or generation is added to all customers within each capacity group simultaneously, and the search finds the maximum addition that keeps the whole group within limits. Because the whole group grows together, the result reflects coupled, simultaneous growth across all its customers, not any single connection point tested in isolation.

The primary output is headroom_kw_per_customer in the lv_group_hosting_capacity table - a per-transformer figure representing how much additional capacity each customer under that transformer can absorb before the network is constrained.

HV Hosting Capacity

This sub-mode answers: how much additional capacity could be connected at specific HV locations?

Rather than looking at the LV customers under a transformer, this tests the HV network itself. HCM finds all qualifying HV nodes in the selected feeders, then tests them one at a time: it adds generation or load at that node, increments until a constraint is found, resets back to zero, and moves to the next node.

The injection is applied directly at the HV node itself, not behind any particular transformer. So the result reflects what the surrounding HV network (conductors, upstream transformers, voltage) can support at that point - it can be larger than the nameplate rating of whatever transformer happens to be installed there today, because it's answering "what could I connect here," not "what's left on the transformer that's there now."

The primary output is available_headroom_kw in the hv_node_headroom table - the available headroom at each HV node location.

Because each HV node is tested independently (not in parallel), run time scales with the number of nodes. A feeder with many qualifying HV nodes will take proportionally longer. The per-node iteration limit controls the maximum depth of the search at each location.

How the Search Works

Both sub-modes use the same core loop:

1. Load the network at a chosen initial state (a specific timestamp, peak import/export period, fixed load, or zero load).
2. Add a configurable increment of load or generation to all relevant injection points.
3. Solve the power flow.
4. Check all configured voltage and thermal constraints.
5. If no constraint is breached, repeat from step 2. If a constraint is breached, record the last valid state as the hosting capacity for that location.

In LV Hosting Capacity, each capacity group is handled independently within the shared solve: when a group breaches a limit it is locked at its last valid level and rolled back, while the other groups keep growing. The search ends when every group is locked, an HV (feeder-level) constraint stops it (when configured to), or the iteration limit is reached.

The step size (stepKwPerCustomer for LV, stepKwPerNode for HV) sets the precision of results: smaller steps are more precise but take longer. The maximum iterations (maxSteps / maxStepsPerNode) is a safety limit. Together they cap the largest addition the search can find at step size x maximum iterations (e.g. 0.5 kW x 200 steps = 100 kW per customer).

Avoid large steps for LV Hosting Capacity. The step is applied to every customer in a group at once, so on a large group even a modest-looking step (e.g. 3 kW per customer) adds a big block of load or generation in one go. That can breach a limit on the first step and report 0 headroom, even though the network could take some additional capacity.

Choosing the Initial State

The initial state determines the baseline load and generation conditions from which the search begins. Results from different modes answer different questions, so don't compare them directly without accounting for what each starting point represents.

Selector Mode	What it represents
PEAK_FEEDER_EXPORT	The interval with the highest feeder export (e.g. peak solar). Most conservative for solar or other generation assessments.
PEAK_FEEDER_IMPORT	The interval with the highest feeder import (e.g. evening peak). Most conservative for EV charging or load growth assessments.
FIXED_TIME	Actual load and generation at a specific timestamp. Useful for reproducing or comparing results at a defined network state.
FIXED_LOAD	A uniform per-customer load/generation baseline. Gives comparable results across feeders regardless of metered data.
ZERO_LOAD	An empty network (no existing load or DER). Typically gives the highest headroom - useful as a theoretical upper bound.

The peak modes select a single real interval within the startTime to endTime window, where the feeder as a whole has its highest net export or import. They do not combine each customer's individual peak.

Match the initial state to the direction being tested

For new load (IMPORT_LOAD), use PEAK_FEEDER_IMPORT. For new generation (EXPORT_GENERATION), use PEAK_FEEDER_EXPORT. The opposite pairing starts from the most favourable moment and overstates headroom.

Check the load data behind a peak selection

Because the peak modes pick the single highest interval, one bad meter reading (e.g. a one-off spike) can become the selected peak. If results look implausible, such as a very high total_base_net_import_kw or widespread undervoltage before anything is added, check that feeder's load data for outliers. Validating source load data is the responsibility of whoever manages timeseries ingestion.

Adjusting the Existing Load and DER

For the modes FIXED_TIME, PEAK_FEEDER_IMPORT, PEAK_FEEDER_EXPORT, four optional fields control how the existing network state is built before the search begins:

Field	Effect
includeLoads	Whether existing customer load (consumption) is included. Defaults to true. Set to false to set all consumption to zero.
includeExistingDer	Whether existing customer export is included (not the effect of all existing DER — see note below). Defaults to true. Set to false to set all export to zero. If true, the search probes for headroom on top of that export, reflecting real network conditions and generally yielding less available headroom. If false, measured net export is stripped out before the search begins, yielding more apparent headroom.
loadScalingFactor	Multiplier on included load. Defaults to 1.0 (as measured). Set higher to test with more load, lower for less.
derScalingFactor	Multiplier on included existing export. Defaults to 1.0 (as measured). Set higher to test with more export, lower for less.

On the name includeExistingDer

Despite the name, includeExistingDer acts on existing net export, not on all behind-the-meter generation. A customer whose solar only offsets their own consumption — reducing load without crossing into export — shows up as reduced import, not as export. That self-consumed generation is therefore captured in the (lower) load figure and is governed by includeLoads / loadScalingFactor, not by includeExistingDer. Only generation large enough to push the meter into net export is treated as "existing DER" here.

What Can Constrain the Search?

Any of the configured voltage or thermal limits can stop the search:

• LV voltage limits - minimum and maximum voltage in volts at LV nodes (e.g., 216 V to 253 V). By default any single phase voltage outside the limits is a breach. Alternatively, the limits can be checked against the 1st and 99th percentile voltages of each capacity group - see Constraints Config.
• HV voltage limits - minimum and maximum voltage in per unit at HV nodes (e.g., 0.95 pu to 1.05 pu).
• LV thermal limits - loading as a percentage of the normal or emergency rating on LV assets.
• HV thermal limits - loading as a percentage of the normal or emergency rating on HV assets.

Constraint checks are all-or-nothing per class: each enabled limit is applied to every monitored asset of its type and cannot be narrowed to a chosen subset of nodes or buses. For HV Hosting Capacity this means a breach anywhere on the feeder stops the search for the node being tested, even if it is not downstream of that node.

Existing violations give 0 headroom for every HV node

HV Hosting Capacity first solves the feeder at its initial state. If any enabled constraint is already breached anywhere on the feeder, or that solve does not converge, every HV node is reported with 0 headroom. Check constraint_violations for that run to find the breach. If it reflects a real network condition, the 0 result is correct.

When a constraint is first breached, the details are recorded in the constraint_violations table and linked to the corresponding capacity group or HV node result via binding_id. This lets you trace which specific asset or voltage limit stopped the search.

Key Outputs at a Glance

Table	What it answers
lv_group_hosting_capacity	How much additional capacity (kW per customer) is available under each distribution transformer?
hv_node_headroom	How much headroom (kW) is available at each HV node location?
constraint_violations	Which specific asset or voltage limit stopped the search, and at which iteration?
binding_constraints	Links each capacity result to its binding constraint violation.
customer_allocations	How many kilowatts were allocated to each individual customer at the point the constraint was hit?

Understanding the Results

Starting point: lv_group_hosting_capacity

Each row in lv_group_hosting_capacity represents one distribution transformer. The two most important columns:

• headroom_kw_per_customer - the maximum additional kW per customer that could be added simultaneously across the group before a constraint was breached. A value of 3.5 kW means every customer under that transformer could add 3.5 kW of solar simultaneously without hitting a voltage or thermal limit.
• total_kw_added - the aggregate kW added across the whole group at the binding point. Roughly headroom_kw_per_customer x included_customer_count, adjusted for any scaling.

Check headroom_direction (export or import) to confirm which direction of capacity you are looking at.

When addition_kw_scaling_applied is true, the per-customer figure reflects the headroom for the highest-weighted customer rather than a uniform value - see the output tables reference for detail.

Interpreting headroom values

Low headroom (e.g. 0-2 kW per customer) means the network is already near its voltage or thermal limit at the chosen initial state. The binding constraint can be traced via binding_id -> binding_constraints -> constraint_violations.

Headroom equal to stepKwPerCustomer x maxSteps means the search exhausted its iteration limit without finding a binding constraint. The network could support more than the reported figure - the result is a lower bound, not the true limit. Increase maxSteps or stepKwPerCustomer to explore further.

Headroom of 0 usually means a constraint was already breached at the initial state before any addition was made. For HV Hosting Capacity this applies to every node on the feeder - see What Can Constrain the Search?. A step size that is too large can also give 0.

Starting point: hv_node_headroom

Each row in hv_node_headroom represents one HV node tested. The key column is available_headroom_kw — the maximum additional kW that can be injected at that node before any configured limit is breached.

Unlike LV capacity groups, HV nodes are tested one at a time in isolation. The headroom at each node assumes only that injection is added; no simultaneous additions occur elsewhere on the feeder. The same headroom interpretation rules apply: a result equal to stepKwPerNode × maxStepsPerNode means the search exhausted its limit and the true headroom is higher.

asset_name and location_type identify the node. headroom_direction confirms whether the result is for export (generation) or import (load).

Understanding what constrained the result

For any transformer or HV node where headroom is low, join through binding_constraints to constraint_violations to see what stopped the search.

The metric column identifies the constraint type (voltage or thermal). violating_value and constraint_limit show how far over the threshold the network was at the binding iteration. conducting_equipment_mrid identifies the specific asset - join this to your network model to locate it.

Per-customer detail

For per-customer allocations and connection-point voltages at the binding state, see customer_allocations. This table is large (one row per customer per run) - use it for diagnostic investigation of specific transformers, not for bulk analysis.