Trane
SMART RESILIENT BUILDINGS - CONTROL TOWER
No changes
--
Configuration
Optimizer readiness
Building0%
Utility0%
1. GLOPi (LP relaxation) → 2. CP-SATi (MIP integer)
Complete all sections to run
Outcomes
Storage Used
Battery:-
Ice Tank:-
Current Electric $
-
Optimized Electric $
-
Current Gas $
-
Optimized Gas $
-
Total Baseline $
-
Total Optimized $
-
Savings
-
Building Identity
Building photo
Click to upload
Model stamp will appear after load.
Building Location
Enter ZIP
Utility Billing
Billing Cycle Start
of each month
Electric kWh * Peak kW Electric $ Gas Therms Gas $
Total 0 — $0 0 $0
Estimate
Estimated values: electric and gas variable charges are calculated from modeled load using the selected RateAcuity tariff basis. Fixed customer charges, taxes, and riders are excluded.
HVAC Equipment
Heating
Method:
AFUE:
Heating & Cooling
Cooling
OAT °FCOP
75
85
95
105
Storage
Utility Rate
1
Uses ZIP from Building tab automatically (no re-entry needed)
2
3
Energy Rate
—
Demand Charge
—
Fixed Monthly
—
Source
RateAcuity
Energy Rates ($/kWh)

Weekday — 12 months × 24 hours

Weekend
Demand Charges ($/kW)

Weekday — 12 months × 24 hours

Weekend
Digital Twin Mode (r20260601f): View
Ready
No optimizer results yet for this building.
Surface Plot
🧠 Self-Learning Load Model — Full Explanation

1. What this model does

It predicts how much electricity the building will use in an upcoming month, and it keeps that prediction honest over time by learning from every new utility bill. Two things drive a building’s energy: the weather (how much heating or cooling it needs) and who’s inside using it (tenants, lights, plug loads, equipment). The model separates those two so it can tell a hot summer apart from a new tenant moving in.

2. The formula

Em = α + βH · HDDm + βC · CDDm

In words: predicted energy for a month = a flat baseline, plus extra energy for heating when it’s cold, plus extra energy for cooling when it’s hot.

  • Em — the predicted electricity for month m, in kWh.
  • α (alpha) — the baseline: the weather-independent energy the building uses no matter the temperature (lights, plug loads, always-on equipment, occupancy). This is the number that self-learns when tenants change.
  • βH (beta-H) — the heating sensitivity: how much extra energy is used for each unit of cold weather.
  • βC (beta-C) — the cooling sensitivity: how much extra energy is used for each unit of hot weather.
  • HDD / CDD — Heating and Cooling Degree-Days: a simple score of how cold or hot a month was. A colder month has a bigger HDD; a hotter month has a bigger CDD. They come from real weather data for the building’s location.

3. How the numbers are found (the fit)

The model looks at the latest 12 utility billing periods alongside the weather for each period, and finds the values of α, βH and βC that best explain the actual bills. This is a standard best-fit calculation — think of it as drawing the line that passes as close as possible through all 12 bill observations.

4. Why it “self-learns”

The weather sensitivities (βH, βC) describe the building’s physical response to temperature — that stays fairly steady. But if a new tenant moves in, the building uses more energy even when the weather hasn’t changed. That extra usage can’t be explained by HDD or CDD, so it shows up in the baseline α. Each time a new bill is added and the model re-fits, α moves to reflect the new occupancy — so the building effectively teaches itself its current baseline.

5. How to update the model

The model does not retrain the instant you type in a bill. To update it manually:

  • Load the new past-month bill in the Utility Billing panel (it saves automatically).
  • Press Run. A single Run re-fits the load model from the latest 12 bills, applies the configured gentle-learning weight when the bill fingerprint changed, and then runs the optimizer on that fresh model.

So there is no separate “rebuild model” step — the one Run button does both.

6. Steady baseline — why we don’t chase every bill

Utility bills are often noisy in ways that have nothing to do with the building actually changing:

  • Estimated reads — the meter wasn’t physically read; the utility guessed, then corrects it later.
  • True-ups — a month is over- or under-billed, and a later bill fixes it.
  • Odd billing-day counts — a 28-day month next to a 34-day month looks like a usage change but isn’t.

Because of this, the intended behavior is for the baseline to ease in gently: a new bill nudges α a little rather than snapping it to the latest month. A real tenant change shows up as a sustained shift across several bills, which the baseline still picks up — it just shrugs off a single odd month. A steadiness setting controls how gently it eases in.

Live today: pressing Run re-fits from the latest 12 bills. If the bill fingerprint is unchanged, the effective learning weight becomes zero and α is retained; a changed bill set receives one gentle update before optimization.
Built & test-covered: the “ease-in” smoothing of the baseline is now implemented in the load-model fit — a new bill blends into the steady baseline as αused = (1−w)·αprev + w·αfit, with a steadiness weight w. The current Run pipeline requests w = 0.30; unchanged bills are internally reduced to w = 0. The automated refresh follows the configured utility billing-cycle boundary, not the first day of the calendar month.
Billing-Cycle Operations & Dispatch

1. The operating boundary is the utility bill cycle

The coordinator uses the building’s configured billing start day and local timezone. At a new cycle it rebuilds the tariff matrix, gently refreshes the learned load model, runs the annual optimizer, and commits the new peak target. Repeating the refresh for an already committed cycle is safely skipped unless an authorized force refresh is requested.

2. Learning is idempotent and auditable

αused = (1−w)αprevious + wαfit

A SHA-256 fingerprint identifies the bill values used by the fit. New bills receive one gentle update; unchanged bills use an effective w of zero, so repeated Runs cannot teach the same evidence twice. Model version, fit values, learning reason, fingerprint, and timestamp are retained in the model metadata and audit ledger.

3. Refresh is transactional

The rates, load matrix, metadata, and dispatch artifacts are backed up before refresh. They are committed together after a successful optimization; a failure restores the prior complete set and records the error. Mid-cycle initialization does not invent a zero peak: it requests meter-history backfill, while live readings accumulate a monotonic measured peak for the active cycle.

4. Annual GLOP chooses the economic plan

min [Σ renergy,tPgrid,tΔt + Σ rdemand,pPpeak,p + cdegradationEdischarge]

The annual linear program values both TOU energy arbitrage and billing-period peak shaving. Battery state of charge, power, efficiency, and equipment constraints determine what is physically available. A zero degradation cost permits marginal arbitrage; a realistic degradation cost should be configured when battery wear matters.

5. Daily CP-SAT creates the executable BMS schedule

The daily solver receives the annual plan’s realizable demand target. On a peak-threat day it minimizes slot-level energy cost while enforcing the target during demand-window slots, plus binary charge/discharge modes, minimum dwell, one charge and discharge run per day, power ramping, efficiency, and state-of-charge limits. If natural load is already below the target, storage is suppressed.

6. Always keep the tariff units separate

  • $/kWh energy rate prices every imported kWh and drives TOU charging and discharging.
  • $/kW demand rate prices the cycle’s measured peak in the applicable demand window.
Chart-reading rule: a ribbon changing from $77/kW to $46/kW does not prove the TOU energy price changed. Inspect the $/kWh series separately. Discharge below the demand cap can still be valid energy arbitrage when the high TOU energy period continues.

7. What the live widget proves

The Engineering View reports the active cycle, coordinator state, refresh status, model version, learning reason, planned peak target, measured peak, and meter-history status. These fields explain what the system decided; the model audit ledger preserves why the learning state changed.