Charge Planning and Operations¶

Charge planning is the process of turning future work into charging decisions.

The concept applies to buses, logistics, service fleets, depot vehicles, and any fleet where vehicles have known or estimated future work.

In the two-axis model:

• problem coordinate: Operations & Dispatch -> Dispatch & Scheduling, with secondary links to Smart Charging -> Load Management
• physical coordinate: vehicle, battery, route, duty, block, depot, charger, site capacity, readiness deadline, and time

Generic Planning Model¶

flowchart LR
  Work["Work<br/>route, duty, block, delivery, shift"]
  Vehicle["Vehicle<br/>battery, current SoC, capability"]
  Policy["Policy<br/>reserve, priority, deadline"]
  Requirement["Energy requirement<br/>kWh, target SoC, deadline"]
  Site["Energy system<br/>chargers, grid, topology, limits"]
  Plan["Charging plan<br/>who charges, where, when, how fast"]
  Execute["Charging execution"]
  Ready["Ready for work"]

  Work --> Requirement
  Vehicle --> Requirement
  Policy --> Requirement
  Requirement --> Plan
  Site --> Plan
  Plan --> Execute
  Execute --> Ready

The main questions are:

• What work is coming?
• Which vehicle is expected to perform it?
• What energy will the vehicle need, including reserve?
• When must the vehicle be ready?
• Which chargers and site capacity are available?
• What other vehicles compete for the same capacity?
• What should happen when plans, vehicles, chargers, or site constraints change?

VDV 463 In The Model¶

VDV 463 gives a standards-based way for an upstream system and a charging/load management system to exchange planning context.

sequenceDiagram
  participant USS as Upstream system<br/>DMS / FMS / ITCS / planning
  participant CMS as Charging/load management system
  participant Site as Depot energy system
  participant Vehicle as Vehicle

  USS->>CMS: ProvideChargingRequests<br/>vehicle, target SoC, departure, request id
  CMS->>CMS: build or update charging plan
  CMS->>Site: allocate charger power within site limits
  Site->>Vehicle: charge
  CMS->>USS: ProvideChargingInformation<br/>depot, charging stations, points, processes, faults

The standard is bus-oriented, but the model is more general:

• vehicleId can represent any managed vehicle asset
• startTime, departure, or deadline can represent the next operational need
• target SoC can represent readiness level
• charging point status maps to charger or connector availability
• charging process status maps to charging execution state

VDV Standards In Different Domains¶

Use the specific VDV standard name when classifying work. The family spans planned schedules, real-time operations, and charging management.

flowchart LR
  Planned["Planned schedule and roster standards<br/>VDV 452, VDV 455, VDV 462, NeTEx"]
  Realtime["Real-time operations standards<br/>VDV 453, VDV 454"]
  ChargingVDV["Charging management standard<br/>VDV 463"]
  Work["work"]
  Activity["vehicle activity"]
  Requirement["energy requirement"]
  Charging["charging"]

  Planned --> Work
  Realtime --> Activity
  Work --> Requirement
  Activity --> Requirement
  ChargingVDV --> Requirement
  ChargingVDV --> Charging

Planning Horizons¶

Relation To Manage And Plan¶

Plan asks what could or should work before operations happen. Manage asks what is happening now and what must be controlled.

flowchart TB
  Plan["Plan<br/>simulation, route energy, schedule parsing"]
  Manage["Manage<br/>live depot, chargers, vehicles, dispatch"]
  Creator["Schedule Creator<br/>GTFS / TXC / schedule transforms"]
  Twin["Digital Twin<br/>scenario and operational simulation"]
  Core["Core operations<br/>charging, vehicle, depot state"]

  Creator --> Plan
  Creator --> Manage
  Plan --> Twin
  Manage --> Core
  Twin -. future alignment .-> Core

bf-schedule-creator is the shared parser and conversion boundary. It turns heterogeneous schedule formats into modelling-ready or operations-ready outputs. Because it is shared, schema changes can affect both Plan and Manage.

Domain Events To Look For¶

Charge planning becomes easier to reason about when phrased as events:

• work schedule imported
• vehicle assigned to work
• energy requirement calculated
• charging request created or updated
• charging plan generated
• charger or connector became unavailable
• operating envelope changed
• charging started
• charging completed
• readiness target met or missed
• dispatch allocation changed

These events cut across standards. VDV may carry a charging request. OCPP may carry session and meter evidence. OSCP may change the site envelope. The product ontology explains how these signals combine.