Energy Management¶

Energy management is the domain that decides how physical energy, electrical limits, price, carbon, and grid obligations affect fleet charging.

In the two-axis model:

• problem coordinate: Energy & Cost Management -> Site Energy & Infrastructure or Energy & Cost Management -> Advanced Energy & Grid
• physical coordinate: grid connection, microgrid, meter, circuit, charger, EVSE, connector, storage, generation, site load, tariff, operating envelope, and time

In the ontology it sits around three concepts:

• energy system: the supply side and its constraints
• energy requirement: the demand side created by future fleet work
• charging: the allocation mechanism between demand and supply

Energy System Model¶

flowchart TB
  Grid["Grid connection"]
  Generation["Local generation"]
  Storage["Battery storage"]
  SiteLoad["Non-EV site load"]
  Microgrid["Microgrid<br/>topology, nodes, limits"]
  Chargers["Chargers / EVSEs / connectors"]
  Vehicles["Vehicles"]
  Metering["Meters and telemetry"]
  Envelope["Operating envelopes<br/>grid or DERMS constraints"]

  Grid --> Microgrid
  Generation --> Microgrid
  Storage --> Microgrid
  SiteLoad --> Microgrid
  Envelope --> Microgrid
  Microgrid --> Chargers
  Chargers --> Vehicles
  Microgrid --> Metering
  Chargers --> Metering

The energy system includes:

• energy sources: grid import, local generation, storage discharge
• energy resources: chargers, storage, controllable site assets
• topology: how grid connections, circuits, chargers, and site loads relate
• power state: current demand, available capacity, committed capacity, curtailed capacity
• energy state: stored energy and useful remaining energy
• constraints: grid limits, circuit limits, charger limits, policy limits, operating envelopes
• quality state: outage, stale telemetry, degraded control, derating, fallback mode

Demand And Supply¶

Energy management is useful only when it compares demand with supply.

flowchart LR
  Work["Future work"]
  Requirement["Energy requirement<br/>kWh, deadline, margin"]
  Demand["Charging demand<br/>vehicles competing for power"]
  Supply["Available supply<br/>capacity, cost, carbon, constraints"]
  Policy["Energy policy<br/>priority, safety, tariff, carbon"]
  Allocation["Charging allocation"]
  Outcome["Outcome<br/>readiness, cost, carbon, compliance"]

  Work --> Requirement
  Requirement --> Demand
  Supply --> Allocation
  Demand --> Allocation
  Policy --> Allocation
  Allocation --> Outcome

The same vehicle can be urgent from an operations view and expensive from an energy view. The product has to make that tradeoff explicit.

Energy Management Sub-Domains¶

Microgrid And Operating Envelopes¶

The microgrid model is the physical energy-system model. It represents the site as a rooted electrical-node tree and applies constraints at the right node.

An operating envelope is a time-bounded constraint that can come from an external party, such as a DERMS through OSCP. BetterFleet's design keeps OSCP outside the microgrid model. OSCP translates protocol messages into protocol-neutral operating envelopes.

sequenceDiagram
  participant DERMS as Grid / DERMS capacity provider
  participant OSCP as OSCP domain
  participant MG as Microgrid
  participant SC as Smart charging
  participant Charger as Chargers

  DERMS->>OSCP: capacity forecast for group
  OSCP->>OSCP: resolve group binding
  OSCP->>MG: submit operating envelope
  MG->>SC: effective capacity and constraints
  SC->>Charger: charging profiles or limits
  Charger->>SC: meter and status evidence
  SC->>MG: demand and measurements
  MG->>OSCP: measurements / compliance signals

Important rules:

• external protocol identity belongs in the adapter domain
• the microgrid owns physical topology and generic constraint state
• smart charging reads effective capacity and applies charger-level limits
• reports and support views need lineage from envelope to allocation to session outcome

Microgrid Topology And Constraint Evaluation¶

The microgrid is a rooted electrical tree. Limits can apply at the site root, a grid connection, a circuit, a charger group, or a charger/EVSE node. A safe allocation has to satisfy the target node and its ancestors.

flowchart TB
  Site["Microgrid<br/>depot electrical system"]
  GridA["GRID_CONNECTION<br/>import limit / envelope target"]
  GridB["GRID_CONNECTION<br/>second supply boundary"]
  CircuitA["Circuit / feeder<br/>node limit"]
  CircuitB["Circuit / feeder<br/>node limit"]
  ChargerA["Charger group<br/>allocation scope"]
  ChargerB["Charger group<br/>allocation scope"]
  EVSE1["EVSE / connector<br/>session demand"]
  EVSE2["EVSE / connector<br/>session demand"]
  SiteLoad["Non-EV site load"]
  Meter["Meter and telemetry point"]

  Site --> GridA
  Site --> GridB
  GridA --> CircuitA
  GridA --> SiteLoad
  GridA --> Meter
  CircuitA --> ChargerA
  CircuitA --> ChargerB
  ChargerA --> EVSE1
  ChargerB --> EVSE2
  GridB --> CircuitB

Constraint evaluation should answer these questions in order:

1. Which node does the command or envelope target?
2. Which ancestor limits also apply?
3. Is telemetry fresh enough to trust measured demand?
4. Which fallback demand should be used when telemetry is stale?
5. What allocation is still safe after the envelope, node limits, charger limits, and policy limits are combined?

Operating-Envelope Lifecycle¶

An operating envelope is time-bounded. It may be received before it is active, become active at a block boundary, expire, be withdrawn, or fall back under policy when the source is unavailable.

stateDiagram-v2
  [*] --> Received
  Received --> Pending: valid future window
  Received --> Active: valid now
  Pending --> Active: activation time reached
  Active --> Expired: validity window ended
  Active --> Withdrawn: source withdraws envelope
  Active --> FallbackEligible: primary source stale or offline
  FallbackEligible --> ActiveFallback: fallback policy applies
  ActiveFallback --> Active: fresh primary envelope received
  ActiveFallback --> Expired: fallback validity ended
  Expired --> [*]
  Withdrawn --> [*]

Degraded-control rules matter because smart charging must fail toward a safe allocation. The support and reporting views should expose whether a limit came from a fresh envelope, fallback envelope, static node limit, charger limit, or stale-data policy.

Cost And Carbon¶

Cost and carbon are energy-management concerns because they affect when and how charging should happen.

Utility tariffs and roaming tariffs are related, but they serve different jobs. A utility tariff explains what the site pays for energy. A roaming tariff explains what a user or partner is charged for a session.

Control Strategies¶

Energy management influences charging through strategies such as:

• keep total site load under a hard limit
• reserve capacity for non-EV site load
• prioritise vehicles with the nearest work deadline
• move non-urgent charging into lower-cost or lower-carbon windows
• reduce charging when a grid envelope tightens
• recover gracefully when telemetry is stale or a charger cannot accept a command
• publish measurements or compliance evidence to an external grid party

Relation To Product Domains¶

Energy management overlaps with several domains:

• Smart Charging applies the control decision to chargers and connectors.
• Operations & Dispatch supplies the work context and vehicle readiness need.
• Roaming & Shared Charging may add commercial access and pricing constraints.
• Incidents & Notifications explains when energy control degrades or fails.
• Reporting & Insights proves cost, carbon, capacity, and charging outcomes.
• Resilience & Security defines safe fallback when control or data is uncertain.