Ontology Primer¶

BetterFleet starts from real-world domain nouns before product screens or service boundaries.

The product domains and sub-domains are the top-level drivers. They describe the durable problem spaces. The core ontology concepts explain the shared nouns that appear across those spaces. The physical-world objects anchor those concepts in assets, sites, and energy flows.

The minimum operating model is:

• work: the demand placed on the fleet
• fleet: the set of vehicles managed together
• vehicle: the physical asset that performs work and consumes energy
• energy requirement: the energy outcome needed for work, including reserve and deadline
• energy system: the supply side, including grid, site, microgrid, chargers, storage, generation, limits, and live state
• charging: the mechanism that allocates energy from the energy system to vehicles

Physical Reality¶

The physical system has hard constraints:

• a vehicle has a battery, a location, a duty, a deadline, and a charging interface
• a charger has one or more physical outlets or connectors
• a site has electrical topology, grid import limits, local load, and often metering constraints
• a grid or DERMS actor may set an operating envelope for a site or subtree
• a charging session transfers energy over time and produces meter evidence

OCPP 2.0.1 makes the charger-side physical model explicit:

classDiagram
  direction TB

  class ChargingStation {
    physical charging system
    one CSMS connection
  }

  class EVSE {
    independently managed supply point
    can charge one EV at a time
  }

  class Connector {
    socket or cable outlet
    physical connection option
  }

  ChargingStation "1" --> "1..*" EVSE
  EVSE "1" --> "1..*" Connector

OCPP 1.6 uses a flatter charge point + connector model. OCPP 2.0.1 inserts EVSE as the controllable charging point between the station and connector. That distinction matters when a piece of hardware has several connector types but can only charge one vehicle at a time.

Operational Reality¶

The operations model asks different questions:

• What work must be done?
• Which vehicle can do it?
• How much energy does that vehicle need?
• Which charger, connector, site capacity, and time window can supply it?
• What happens if the charger, vehicle, site, schedule, or external grid signal changes?

flowchart TB
  Schedule["Schedule / work plan"]
  Policy["Operating policy<br/>reserve, target SoC, priority"]
  Vehicle["Vehicle facts<br/>battery, SoC, location, capability"]
  Requirement["Energy requirement"]
  Allocation["Charging allocation"]
  Execution["Charging execution"]
  Readiness["Vehicle readiness"]

  Schedule --> Requirement
  Policy --> Requirement
  Vehicle --> Requirement
  Requirement --> Allocation
  Allocation --> Execution
  Execution --> Vehicle
  Vehicle --> Readiness
  Schedule --> Readiness

This is why a charging session is more than a protocol transaction. It is evidence that a vehicle moved from one energy state to another under a set of operational decisions.

Commercial Reality¶

The commercial model adds access and money:

• Who is allowed to charge?
• Which party owns the charger network?
• Which party owns the driver or fleet customer relationship?
• Which tariff applies?
• Who receives the charge detail record?
• Who invoices, pays, or settles?

Commercial state must stay separate from operational truth. A CDR or invoice depends on the physical session and tariff context, but it has its own meaning: it proves what should be billed or settled.

BetterFleet Product Domains¶

The product ontology uses these domains:

• Smart Charging: Charger Control; Load Management; Protocol & Interoperability
• Energy & Cost Management: Site Energy & Infrastructure; Advanced Energy & Grid
• Operations & Dispatch: Fleet & Vehicle Management; Depot & Integration; Dispatch & Scheduling
• Roaming & Shared Charging: Network Access & Interoperability; Commercial Settlement & Shared Charging
• Incidents & Notifications: Alerting; Detection; Incident & Resolution Management
• Reporting & Insights: Fleet & Charging Analytics; Operational Dashboards; Cost, Carbon & Compliance
• Resilience & Security: Platform Reliability & Safety; Security & Access Control
• Accessibility & Usability: User Experience; Onboarding & Support

The key practice is to place a concept by its real-world decision boundary. For example, a charger status signal may originate in OCPP, trigger an incident, change smart-charging allocation, appear in reports, and affect roaming availability. The ontology keeps those meanings separate.

Domain Classification Pattern¶

Use this pattern when a new concept or feature seems to belong everywhere:

1. Name the physical object or evidence feed.
2. Name the decision being made.
3. Pick the domain that owns that decision.
4. Pick the sub-domain that best narrows the problem.
5. List secondary domains that read or react to the state.

Example: a site power limit is a physical grid or circuit constraint. Energy & Cost Management owns the meaning of available supply and site constraints. Smart Charging reacts by reducing charger allocation. Reporting reads the result for capacity and compliance analysis.