Skip to main content
Version: Next

What Are HCM Scenarios

HCM scenarios are named collections of input assumptions that define how distributed energy resources (DER) and demand growth will be distributed across the network in future years.

Why Scenarios Matter​

Scenarios enable "what-if" analysis by allowing network operators to compare different DER adoption trajectories, test various technology mixes, and assess network constraints under different growth patterns. Rather than planning for a single predicted future, operators can explore multiple plausible futures and design networks that perform well across various conditions.

Data Architecture​

HCM scenarios follow a hierarchical data structure that flows from detailed behavioural patterns up to high-level scenario definitions:

Profiles: Individual Behaviour Patterns​

At the foundation are profiles - time-series data that capture how different DER technologies behave:

  • PV Profiles define solar generation patterns with technical specifications like panel tilt, orientation, and inverter sizing
  • EV Profiles capture charging patterns that vary by vehicle class, charger type, and usage patterns
  • BESS Profiles model battery charge/discharge cycles with efficiency characteristics and control strategies

Each profile contains normalized power arrays (typically 17,520 intervals representing 30-minute data for a year) plus technical metadata about phases, capacity, and efficiency.

Allocations: Grouping with Rules​

Allocations group multiple profiles for each DER type and define the rules for how they get distributed across the network:

  • Probability weighting allows mixing different profile configurations (e.g., 60% of installations use 5kW single-phase systems, 40% use 10kW three-phase systems)
  • Locking mechanisms control whether profiles can be used flexibly or must match specific years or feeders
  • Mathematical constraints ensure probability weights sum to 1.0 per feeder for valid distributions

Forecasts: Capacity by Location and Time​

Forecasts specify how much DER capacity will be installed where and when:

  • PV Forecasts define megawatts of solar capacity by network area and year
  • EV Forecasts specify numbers of electric vehicles by class and location
  • BESS Forecasts set energy storage targets in megawatt-hours
  • Demand Forecasts project background load growth with uncertainty levels

Forecasts can be specified at different network hierarchy levels, from individual feeders up to entire regions.

Scenario Configuration: Mix and Match​

Scenario configurations are where operators mix and match the building blocks above to create specific futures:

  • Each scenario references specific allocation strategies for each DER type
  • Scenarios can combine different forecast assumptions (high solar + low batteries, moderate EVs + high demand growth)
  • Different scenarios can use different network aggregation levels and uncertainty assumptions

Profile Allocation Concepts​

Profile allocation determines how behavioural patterns get distributed across network locations. Two key mechanisms control this distribution:

Probability Weighting enables realistic technology diversity. Instead of assuming all solar installations behave identically, allocations can specify that 60% follow one behavioural pattern while 40% follow another, representing different system sizes, orientations, or control strategies.

Locking Mechanisms control allocation flexibility:

  • Year locking restricts profiles to specific time periods, useful for modelling technology evolution
  • Feeder locking ensures location-specific characteristics are preserved, important for geographic differences

These mechanisms allow scenarios to balance computational efficiency with realistic representation of technology diversity across time and space.

How PV is allocated in a scenario​

Step 1: Check if the target is already met

The amount of PV needed for the year and feeder is extracted from the input table pv_forecasts, either through pv_panel_capacity (MW, DC) (primary method — if both values are non-null this will be used) or inverter_capacity (MW, AC) (used only if pv_panel_capacity is null). The total current PV capacity on the feeder is calculated by summing the ratings of all existing PV systems in the network model (in DC if using pv_panel_capacity and AC if using inverter_capacity).

The deficit is calculated as the difference between current PV capacity on the feeder and the forecast target. If the deficit is zero or negative, no PV will be added and the process stops. No PV is ever removed, even if the forecast target is lower than current capacity.

Step 2: Build the initial candidate pool

The initial candidate pool consists only of consumers with no existing solar. If no candidates exist, a warning is logged and the process stops.

Step 3: Select and install

A consumer is selected at random from the candidate pool and assigned a PV system drawn from a weighted profile pool. The profile determines system size and phase configuration (single or three-phase). The proportion of three-phase installs can be controlled via the max_percent_multiphase parameter. The consumer is then removed from the pool and the process repeats until either the target is met or the pool is exhausted.

Step 4: Pool exhausted, target not met

Once all consumers without solar have been allocated, the candidate pool is rebuilt to include consumers with existing PV systems where the DC capacity is below pvUpgradeThreshold (default 5kW). This captures pre-existing real-world installs that are small enough to be realistic upgrade candidates.

  • If new candidates are found, return to Step 3.
  • If the pool is still empty, proceed to Step 5.

Step 5: Raise the upgrade threshold

The upgrade threshold is increased by 1kW and the candidate pool is rebuilt.

  • If candidates are found, return to Step 3.
  • If the threshold reaches 10kW, a warning is logged but allocation continues.
  • If the threshold reaches 30kW, the scenario is rejected as misconfigured. Note that this could cause issues in feeders where large PV systems are common and the forecast target is high.
  • Otherwise, repeat Step 5.

Step 6: Upgrading an existing system

Where a selected consumer already has a PV system, a new install is not created. Instead, the inverter capacity and DC/AC ratio are recalculated to represent the combined old and new system as a single upgraded install.

How BESS is allocated in a scenario​

Step 1: Check if the target is already met

The allocation target is extracted from bess_forecasts using capacity_mw (MW, AC), converted to VA internally. Note that capacity_mwh exists in the table but is not currently used. Current BESS capacity is calculated by summing the AC inverter ratings of all existing battery systems on the feeder.

If the deficit is zero or negative, the process stops. No BESS is ever removed, even if the forecast target is lower than current capacity.

Step 2: Build the initial candidate pool

Initial candidates must have no existing battery system and a PV system with an inverter rating greater than 5kVA. This reflects the real-world norm of BESS being paired with a reasonably sized solar installation. If no candidates exist, a warning is logged and the process stops.

Step 3: Select and install

A consumer is selected at random and assigned a BESS from a weighted profile pool, which determines system size and phase configuration. Three-phase installs can be capped via max_percent_multiphase in bess_forecasts (0.0–100.0). The consumer is removed from the pool and the process repeats until the target is met or the pool is exhausted.

Step 4: Pool exhausted, target not met

The pool is rebuilt with looser criteria, dropping the PV co-location requirement. The rebuilt pool includes:

  • Consumers with no existing battery system, regardless of PV.

  • Consumers with an existing BESS below bessUpgradeThreshold (default 5kW).

  • If new candidates are found, return to Step 3.

  • If still empty, proceed to Step 5.

Step 5: Raise the upgrade threshold

The threshold is raised by 1kW and the pool is rebuilt.

  • If candidates are found, return to Step 3.
  • If the threshold reaches 10kW, a warning is logged but allocation continues.
  • If the threshold reaches 30kW, the scenario is rejected as misconfigured. Note that this could cause issues in feeders where large BESS systems are common and the forecast target is high.
  • Otherwise, repeat Step 5.

Step 6: Upgrading an existing system

Where a selected consumer already has a BESS, no new unit is created. Instead, both inverter capacity and storage capacity are updated to represent the combined old and new system as a single upgraded install.

How EV is allocated in a scenario​

Step 1: Check if the target is already met

The allocation target is extracted from ev_forecasts using number_of_ev, rounded to the nearest integer. Current EV charger count is calculated by summing all existing EV charging units on the feeder.

If the deficit is zero or negative, the process stops. No EV chargers are ever removed, even if the forecast target is lower than the current count.

Step 2: Build the candidate pool

All consumers on the feeder are candidates for EV charger installation. If no consumers exist, a warning is logged and the process stops.

Unlike PV and BESS, there is no upgrade path for EV - existing charger data is not currently available at the level of detail required for upgrade modelling, so all installations are treated as new.

Step 3: Select and install

A consumer is selected at random and assigned an EV charger from a weighted profile pool, which determines charger size and phase configuration. Three-phase installs can be capped via max_percent_multiphase in ev_forecasts (0.0-100.0). Each charger always receives its own new connection, and the same consumer can receive multiple chargers. The process repeats until the target count is met.

Step 4: Safety limit

There is no pool exhaustion in the same sense as PV and BESS: consumers are not removed from the pool after selection. Instead, a warning is raised once the number of allocated chargers exceeds the total number of consumers on the feeder, and the scenario is rejected if allocations reach 1000 times the consumer count without meeting the target (which will basically never get met due to how absurbly high this threshold is set).

Scenario Execution​

Scenarios run independently within work packages.

For step-by-step guidance on configuring scenarios, see the How to Configure HCM Scenarios guide.

warning

Never name a custom scenario base. The system automatically includes a hardcoded base scenario representing current network conditions without additional DER uptake or demand changes. Naming your own scenario base will cause conflicts with this system baseline.

The base scenario can be called in the SYF config during work package configuration without needing to define it in the scenario_configuration table.