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.

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.

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 is there at specific HV connection points?

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 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.

The step size (stepKwPerCustomer for LV, stepKwPerNode for HV) directly controls the precision of results. Smaller steps give finer resolution but require more iterations.

The maximum iterations (maxSteps / maxStepsPerNode) acts as a safety limit. If the configured number of steps completes without hitting a constraint, the result is recorded as unconstrained up to that point.

Choosing the Initial State

The initial state determines the baseline load and generation conditions from which the search begins.

Selector Mode	When to use it
PEAK_FEEDER_EXPORT	Find headroom at the most constrained export (e.g., high solar) moment. This is typically the most conservative and relevant for solar hosting capacity assessments.
PEAK_FEEDER_IMPORT	Find headroom at the most constrained import moment. Relevant for EV charging or load growth assessments.
FIXED_TIME	Start from a specific known timestamp. Useful for reproducing or comparing results at a defined network state.
FIXED_LOAD	Apply a uniform per-customer load/generation as the baseline. Useful for standardised comparisons across feeders.
ZERO_LOAD	Start from an empty network (no existing load or DER).

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).
• 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.

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 means a constraint was already breached at the initial state before any addition was made. The network was already over-limit at the chosen starting conditions.

How initial state mode affects results

The initial state mode has a large effect on headroom values and what the results represent:

• ZERO_LOAD - no existing load or generation. Headroom reflects the absolute network capacity (impedance and voltage rise only). Typically produces the highest headroom figures. Useful as a theoretical upper bound.
• FIXED_LOAD - uniform per-customer baseline. Produces consistent, comparable results across feeders regardless of actual metered data. Useful for standardised assessments.
• FIXED_TIME - snapshot of actual load and generation at a specific moment. Headroom is relative to that exact network state.
• PEAK_FEEDER_EXPORT - worst-case export (e.g. peak solar) moment in a time window. Most conservative for solar hosting capacity - represents the tightest conditions the network will see.
• PEAK_FEEDER_IMPORT - worst-case import (e.g. evening load peak) moment. Most conservative for load growth or EV charging assessments.

Results from different modes answer different questions and should not be directly compared without accounting for what the initial state represents.

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.