Two-Axis Ontology Model¶

The training pack uses two coordinate axes:

1. Problem-domain orientation: the eight BetterFleet domains and their sub-domains. This is the main orientation.
2. Physical orientation: the physical reality being modelled: vehicles, chargers, EVSEs, connectors, sites, depots, grid connections, microgrids, meters, storage, generation, people, and time.

Everything else maps into this coordinate system: standards, services, screens, reports, commercial flows, events, integrations, and training examples.

BetterFleet's core problem is matching fleet work to available energy through time. The problem-domain axis explains why a capability exists. The physical axis explains what real-world objects the capability acts on or observes.

Model 1: Problem-Domain Orientation¶

The problem-domain orientation is the primary model. It groups work by the decision being made, rather than by protocol, service, screen, or physical asset.

Domain Driver Map¶

Model 2: Physical Orientation¶

The physical orientation is the second model. It names the real-world things BetterFleet models, controls, observes, or explains.

Coordinate Mapping¶

Every concept should have a coordinate:

• problem coordinate: domain plus sub-domain
• physical coordinate: physical anchor plus relevant time window

Examples:

Physical And Problem-Domain Overlap¶

The same physical object appears in several problem domains. The coordinate model keeps the meaning clear.

flowchart TB
  subgraph Physical["Physical world"]
    Vehicle["Vehicle"]
    Charger["Charger / EVSE / Connector"]
    Site["Depot / Site"]
    Grid["Grid / Microgrid"]
    User["Driver / Operator"]
  end

  subgraph Domains["Problem domains"]
    Smart["Smart Charging"]
    Energy["Energy & Cost Management"]
    Ops["Operations & Dispatch"]
    Roaming["Roaming & Shared Charging"]
    Incidents["Incidents & Notifications"]
    Reports["Reporting & Insights"]
    Trust["Resilience & Security"]
    UX["Accessibility & Usability"]
  end

  Vehicle --> Ops
  Vehicle --> Smart
  Vehicle --> Reports
  Charger --> Smart
  Charger --> Roaming
  Charger --> Incidents
  Site --> Energy
  Site --> Ops
  Grid --> Energy
  Grid --> Trust
  User --> Roaming
  User --> UX

  Smart --> Reports
  Energy --> Smart
  Ops --> Smart
  Roaming --> Reports
  Incidents --> Ops
  Trust --> Smart

Examples:

• A connector is physical hardware in Smart Charging, an availability signal in Incidents, a location resource in Roaming, and a meter evidence source in Reporting.
• A tariff is a commercial pricing object in Roaming, an energy-cost input in Energy & Cost Management, and a report dimension in Reporting.
• A vehicle is a physical asset in Operations & Dispatch, a charging target in Smart Charging, and a cost/carbon attribution point in Reporting.
• A grid constraint is an energy-system limit in Energy & Cost Management, an allocation constraint in Smart Charging, and a safety concern in Resilience & Security.

Definite Implementation Pattern¶

Each training module should implement the two-axis model in the same way:

1. Start with the problem-domain coordinate.
2. Name the physical-coordinate anchors.
3. Map standards and source signals onto those coordinates.
4. Explain the BetterFleet concept or behaviour.
5. Link to service, API, UI, or report implementation only after the ontology mapping is clear.

For example:

flowchart LR
  Problem["Problem coordinate<br/>domain + sub-domain"]
  Physical["Physical coordinate<br/>asset + location + time"]
  Evidence["Evidence and standards<br/>OCPP, OCPI, OICP, OSCP, OpenADR, VDV, ISO 15118, meters"]
  Concept["BetterFleet concept<br/>session, envelope, requirement, incident"]
  Implementation["Implementation<br/>service, API, UI, report"]

  Problem --> Concept
  Physical --> Concept
  Evidence --> Concept
  Concept --> Implementation

Ontology Stack¶

flowchart TB
  Outcomes["Business outcomes<br/>readiness, cost, carbon, uptime, settlement"]
  Domains["Product domains<br/>the problem spaces"]
  Concepts["Core ontology concepts<br/>work, fleet, vehicle, energy requirement, energy system, charging"]
  Physical["Physical reality<br/>vehicle, charger, EVSE, connector, site, grid"]
  Evidence["Evidence feeds<br/>OCPP, OCPI, OICP, OSCP, OpenADR, VDV, ISO 15118, telematics, meters, schedules"]
  Services["BetterFleet services and UI<br/>implementation boundary"]

  Outcomes --> Domains
  Domains --> Concepts
  Concepts --> Physical
  Physical --> Evidence
  Evidence --> Services
  Services --> Domains

Use this stack when classifying work:

1. Start with the business outcome.
2. Choose the problem-domain coordinate: domain and sub-domain.
3. Choose the physical coordinate: physical anchor and time window.
4. Name the core ontology concepts involved.
5. Name the standards, integrations, or evidence feeds.
6. Map to BetterFleet services, APIs, screens, and reports.

This avoids treating protocol messages or repo names as the domain model.