Skip to content
  • There are no suggestions because the search field is empty.

Energy Rails Documentation

Overview

LōD's Energy Rails system governs how energy market signals, demand response programs, and economic optimization logic control site load. Because large flexible loads may participate in multiple programs simultaneously, overlapping signals are common.

Energy Rails ensure deterministic behavior, grid-compliant automation, predictable conflict resolution, and safe restart logic.

An Energy Rail is an independent control pathway that can issue a START (energize load), STOP (curtail load), or POWER ADJUSTMENT (increase or decrease load to a defined setpoint) command. Each rail corresponds to a specific energy program or logic source. Rails operate independently but are reconciled through a defined arbitration model.


Rail Types

Dispatch Rail

The Dispatch Rail is used for ISO/RTO market participation. It handles real-time dispatch instructions, ancillary services deployment, and emergency grid directives.

Applicable markets include: ERCOT, PJM, AESO, IESO, MISO, and NYISO.

Common applications:

  • Ancillary services
  • Emergency market events

Platform signals used: Dispatch, Demand

Logic Behavior: The Dispatch Rail continues to enforce curtailment for up to 15 minutes after a dispatch window ends. This is configured using the "Stay Stopped for" setting in the rail setup, which holds devices off for a defined period before any restart is permitted. The "Then Start" option can be enabled to automatically re-energize once that window clears, but any restart attempt still remains subject to standard arbitration rules — meaning if another active STOP signal exists, the site will not re-energize regardless of the dispatch window ending.


Scheduling / Recurring Rail

The Scheduling Rail is used for time-based load control. It executes START, STOP, or POWER ADJUSTMENT commands strictly according to a configured schedule, with no extended enforcement window beyond the scheduled period.

Common applications:

  • Utility load blocks
  • Planned curtailment windows
  • Recurring peak avoidance

Platform signals used: Scheduled Action


LMP Rails

The LMP Rail drives economic dispatch decisions based on real-time and day-ahead energy pricing. It generates START, STOP, or POWER ADJUSTMENT commands according to margin thresholds and custom price triggers configured per site.

Unlike compliance-driven rails, when the LMP Rail triggers a STOP from a higher-priority or equal-priority compliance rail will override an LMP-driven START.

Common applications:

  • Bitcoin mining optimization
  • Behind the meter arbitrage

Platform signals used: LMP (5 min), LMP (15 min), LMP DAM, LMP + Ancillary, Breakeven LMP, Profit Margin, Breakeven Efficiency, CTM BTC


4CP / 5CP Rail

The 4CP/5CP Rail is used for coincident peak management. It issues STOP commands during forecasted peak intervals to minimize capacity cost exposure. Depending on site configuration, this rail may operate in an advisory mode or as automated enforcement.

Common applications:

  • Seasonal peak management
  • Utility peak programs

Platform signals used: CP Detection, Demand


Logic and Priority

Default Priority Configuration

All energy market and demand response rails default to Priority Level 5. No rail is treated as inherently superior to another. This prevents unintended implicit hierarchy between ISO dispatch, transmission curtailment, demand response, coincident peak programs, and price-based automation.

Priority is set per rail during configuration. A higher number means higher priority. For example, a rail set to Priority 6 will override a rail set to Priority 4 regardless of command type.


Conflict Resolution

When multiple rails issue conflicting commands, the following logic applies:

Step 1 — Compare Priority The higher priority rail overrides the lower, regardless of command type.

Step 2 — If Priorities Are Equal STOP overrides START. This STOP-dominant rule ensures conservative, grid-safe behavior during overlapping events.


Example Scenarios

Scenario A — Dispatch ends, but another curtailment is still active Dispatch Rail issues START. Transmission Rail issues STOP. Both at Priority 5. Result: STOP wins. Load remains curtailed.

Scenario B — Price signal indicates run, but a DR event is active LMP Rail issues START. Emergency DR issues STOP. Both at Priority 5. Result: STOP wins. Curtailment is enforced.

Scenario C — Higher-priority START overrides a lower-priority STOP Utility DR issues STOP at Priority 4. ISO Ancillary Deployment issues START at Priority 6. Result: Priority 6 overrides Priority 4. Load energizes. STOP dominance only applies when priorities are equal.


Restart Logic

A restart succeeds only when all of the following conditions are met:

  • No other STOP signal remains active
  • No higher-priority rail is blocking the restart

There is no unconditional restart window that overrides active curtailments. This prevents unintended energization during grid stress events.

The "Wait for" setting on each rail controls how long a condition must hold true before the action triggers, preventing false responses to short price spikes or brief demand events. This applies to both STOP and START actions.


Site-Specific Priority Adjustments

While all energy programs default to Priority 5, priority should be adjusted by you in the following circumstances:

  • A program carries high penalty exposure
  • A contractual obligation requires signal precedence

Summary

Rail

Primary Use

Platform Signals

Default Priority

Dispatch Rail

ISO/RTO market participation, ancillary services

Dispatch, Demand (ESD)

5

Scheduling / Recurring Rail

Time-based load blocks, planned curtailment

Scheduled Action

5

LMP Rail

Price-based economic optimization

LMP (5/15 min), LMP DAM, LMP + Ancillary, Breakeven LMP, Profit Margin, BTC Price

5

4CP / 5CP Rail

Coincident peak management

CP Detection, Demand

5


Parameter

Default Behavior

All market & DR programs

Priority 5

Conflict resolution

STOP overrides START when priorities are equal

Restart condition

All active STOP signals must clear

Post-dispatch enforcement

Configurable via "Stay Stopped for" — 15 min default for Dispatch Rail