--- title: "Open Canonical Energy Telemetry Standard" subtitle: "Normative Architecture and Information Model for Vendor-Independent Energy Telemetry Platforms" version: "1.1" status: "Architecture Review Candidate" release: "July 2026" identifier: "OCETS-CORE-1.1" --- # Open Canonical Energy Telemetry Standard **Document:** 1 of 5 **Type:** Normative Standard **Version:** 1.1 **Status:** Architecture Review Candidate **Release:** July 2026 **Compatibility:** Reference Implementation 1.x ## 1. Purpose The Open Canonical Energy Telemetry Standard (OCETS) defines a vendor-independent information model for acquiring, validating, storing, and consuming telemetry from energy systems. OCETS standardizes the semantic shape of observations and events: identities, metrics, units, labels, timestamps, quality, provenance, topology, registry requirements, security, and lifecycle behavior. It does not standardize a particular software stack or vendor integration method. ## 2. Scope This document specifies: - normative terminology; - the canonical information model; - identity scope and label semantics; - canonical metric and unit rules; - role-based power sign convention; - controlled vocabularies; - measurement point, asset, device, and plant modeling; - Plant Registry requirements; - timestamp semantics; - telemetry health; - downsampling semantics; - governance and conformance rules. - canonical observations, events, quality, and provenance; - organizations, portfolios, relationships, and topology; - Registry API interoperability and a normative security baseline. This document does not specify implementation details such as collector configuration, transport topics, storage deployment, dashboard construction, vendor register maps, polling templates, or transformation scripts. Those topics belong to the Reference Implementation Guide. OCETS v1.1 is telemetry-only. A `controls` relationship describes topology; it does not authorize or define a write operation. ### 2.1 Architecture Constraints OCETS intentionally does not standardize: - control systems, SCADA commands, setpoints, dispatch, or actuator writes; - optimization algorithms or forecast-generation models; - market communication, billing, settlement, or tariff calculation; - asset-management, maintenance-management, ERP, or procurement workflows; - vendor register maps, protocol configuration, dashboards, or a specific database. Externally generated forecasts MAY be represented as observations with `origin=forecast`, but SHALL include both `issued_at` and `valid_at`. Their generation, model lifecycle, confidence model, and revision policy remain outside OCETS v1.1. ### 2.2 Reference Architecture ```text Organization / Portfolio / Plant Registry | v Configuration Generator | Field Device -> Edge or Central Collector -> Transport -> Storage -> API -> Grafana | | | +------ Observations --------+-----------+ +------ Events / Health / Quality / Provenance ``` Every component MAY be replaced independently if it preserves the canonical contracts defined by OCETS. ## 3. Normative Language The key words `SHALL`, `SHALL NOT`, `SHOULD`, `SHOULD NOT`, and `MAY` are to be interpreted as normative requirement levels. - `SHALL` indicates a mandatory requirement. - `SHALL NOT` indicates a mandatory prohibition. - `SHOULD` indicates a recommended requirement that may be waived only with documented rationale. - `MAY` indicates an optional capability. ## 4. Terminology | Term | Definition | |---|---| | Plant | A physical or operational site that produces, consumes, stores, converts, or measures energy. | | Asset | A physical energy-system component within one Plant. | | Device | A logical telemetry-producing or telemetry-relevant function within one Plant. | | Measurement Point | A semantic location where a Metric applies. | | Metric | A canonical physical or operational quantity identified by metric name only. | | Capability | A declared ability of a Device or Measurement Point to provide one or more canonical Metrics. | | Registry | The authoritative schema-enforced declaration of Plants, Assets, Devices, Measurement Points, Capabilities, and relationships. | | Label | A bounded metadata field attached to telemetry to identify context without changing the Metric name. | | Organization | A tenant and governance boundary that owns Plants and Portfolios. | | Portfolio | A named grouping of Plants within one Organization. | | Observation | A metric value with identity, acquisition time, quality, and provenance. | | Event | A point-in-time or interval occurrence with lifecycle, severity, source, and correlation. | | Relationship | A stable, typed connection between registered objects. | | Topology | A versioned graph of Relationships for one Plant and one topology kind. | ## 5. Architectural Principles ### 5.1 Semantic Before Technical The platform SHALL standardize physical and operational concepts rather than protocol objects, register names, addresses, hostnames, or vendor terminology. Vendor-specific telemetry SHALL be mapped into canonical concepts before it is stored as OCETS telemetry. ### 5.2 Stable Identity Telemetry identity SHALL be independent of network addresses, collector placement, gateway topology, source file layout, and deployment topology. Logical identities SHALL remain stable throughout the lifecycle of the platform. Replacing a collector, gateway, protocol adapter, or physical communication path SHALL NOT require a semantic identity change. ### 5.3 Canonical Representation Every physical quantity SHALL have one canonical metric name, one canonical engineering unit, and one semantic definition. The canonical metric representation is the metric name itself, such as `active_power`, `voltage`, or `state_of_charge`. OCETS telemetry SHALL NOT require or add a redundant `metric` label to restate the metric name. Multiple canonical representations of the same physical quantity SHALL NOT coexist in the canonical model. Domain-specific metric names SHALL be used only where the domain concept changes the meaning of the quantity. ### 5.4 Separation of Concerns The following concepts SHALL remain independent: - Plant; - Asset; - Device; - Measurement Point; - Metric; - Capability. No concept SHALL implicitly define another. For example, `active_power` defines what is measured; the Measurement Point and labels define where and in what role it is measured. ### 5.5 Declarative Configuration The platform SHALL be described by an authoritative Plant Registry. Operational configuration SHOULD be generated from the registry. Manual duplication of plant, asset, device, measurement point, and label definitions SHOULD be avoided. ### 5.6 Acquisition Independence The canonical model SHALL NOT depend on where telemetry acquisition takes place. Central acquisition, edge acquisition, and hybrid acquisition are conformant if they emit identical canonical telemetry for identical measurements. ### 5.7 Operational State Is Telemetry Operational health SHALL be represented explicitly. Device health, communication health, collector health, timestamp synchronization, freshness, and validation health SHALL NOT be inferred only from process values. ## 6. Canonical Information Model The canonical information model defines the semantic structure of telemetry: ```text Plant -> Asset -> Device -> Measurement Point -> Metric ``` The ownership and grouping model is: ```text Organization -> Portfolio -> Plant ``` The telemetry model produces two distinct records: Observations and Events. Relationships form versioned physical, electrical, and telemetry Topologies around registered objects. ### 6.1 Plant A Plant is a physical or operational site that produces, consumes, stores, converts, or measures energy. A Plant SHALL have a globally unique stable identifier. ### 6.2 Asset An Asset is a physical energy-system component, such as an inverter, meter, battery system, transformer, gateway enclosure, or switchgear cabinet. An Asset SHALL belong to exactly one Plant. An Asset identifier SHALL be unique within its Plant. ### 6.3 Device A Device is a logical telemetry-producing or telemetry-relevant function. A physical Asset MAY expose more than one Device. A Device SHALL belong to exactly one Plant and SHALL have an identifier unique within that Plant. ### 6.4 Measurement Point A Measurement Point is a semantic location where a Metric applies. Examples include: - grid connection; - inverter AC output; - inverter DC input; - PV string; - MPPT channel; - battery DC bus; - site load; - transformer secondary. A Measurement Point SHALL belong to exactly one Plant and SHALL have an identifier unique within that Plant. ### 6.5 Metric A Metric is a canonical physical or operational quantity. Examples include `active_power`, `energy_import`, `voltage`, `current`, `frequency`, `state_of_charge`, `device_available`, `communication_status`, and `timestamp_skew`. Raw vendor register names, dashboard aliases, protocol field names, and implementation-specific source names SHALL NOT be treated as canonical metric names. ## 7. Identity and Label Model The canonical identity of a telemetry series is the combination of: - canonical metric name; - `plant`; - `asset`, where applicable; - `device`, where applicable; - `measurement_point`, where applicable; - additional allowed labels required to disambiguate the measurement, such as `phase`, `string`, `mppt`, or `direction`. The `plant` label value SHALL be globally unique. `asset`, `device`, and `measurement_point` label values SHALL be unique within a Plant. Labels SHALL use controlled values where this standard or the Plant Registry Specification defines a vocabulary. Labels SHALL NOT encode multiple concepts in one field when separate fields are defined. Implementation labels MAY exist outside the canonical model, but they SHALL NOT be required to interpret OCETS telemetry semantics. ## 8. Controlled Vocabularies OCETS v1.1 defines the following controlled vocabularies. The Plant Registry Specification may add stricter schema placement rules for these values. ### 8.1 Role Allowed `role` values: | Value | Meaning | |---|---| | `grid` | Grid interconnection or utility-facing measurement. | | `load` | Consumer or site load measurement. | | `pv` | Photovoltaic generation measurement. | | `battery` | Electrical storage measurement. | | `inverter` | Power conversion device or measurement. | | `meter` | Metering device or measurement. | | `transformer` | Transformer device or measurement. | | `busbar` | Electrical busbar or bus section. | | `collector` | Telemetry acquisition or collection component. | | `environment` | Environmental sensing component. | ### 8.2 Energy Form Allowed `energy_form` values: | Value | Meaning | |---|---| | `electricity_ac` | Alternating-current electricity. | | `electricity_dc` | Direct-current electricity. | | `thermal` | Thermal energy or temperature-related telemetry. | | `environmental` | Environmental conditions. | | `operational` | Platform or equipment health telemetry. | ### 8.3 Status Allowed `status` values: | Value | Meaning | |---|---| | `planned` | Defined but not yet commissioned. | | `active` | In normal service. | | `maintenance` | Temporarily under maintenance. | | `disabled` | Intentionally disabled. | | `retired` | No longer active but retained for history. | ### 8.4 Phase, Direction, and Lifecycle Allowed `phase` values are `l1`, `l2`, `l3`, `n`, and `total`. Allowed `direction` values are `import`, `export`, `charge`, `discharge`, `generation`, `consumption`, and `bidirectional`. Allowed metric lifecycle values are `active`, `proposed`, `deprecated`, and `removed`. ## 9. Power Sign Convention OCETS v1.1 uses a role-based sign convention for instantaneous power metrics. For `active_power`, `reactive_power`, and `apparent_power`: | Role or Measurement Context | Positive Value Means | Negative Value Means | |---|---|---| | `pv` generation or export | Generation/export from the PV source | Reverse flow into the PV source, if measured | | `load` or consumer | Consumption by the load | Reverse export from the load context, if measured | | `battery` | Charging into storage | Discharge/export from storage | | `grid` | Import from grid into the plant | Export from plant to grid | | `inverter` | Direction defined by the associated Measurement Point role | Opposite of the associated Measurement Point role | Implementations SHALL apply this convention before canonical storage. Where the physical source exposes only unsigned values, the Measurement Point role and `direction` label SHALL make the interpretation explicit. Energy counters SHOULD use direction-specific metrics such as `energy_import`, `energy_export`, `energy_charged`, and `energy_discharged` rather than signed accumulated counters. ## 10. Canonical Metrics Canonical metrics SHALL be defined in the Canonical Metric Catalogue. Each canonical metric definition SHALL include: - metric name; - canonical unit; - value type; - aggregation semantics; - semantic definition; - allowed labels; - source class; - lifecycle status. - immutable definition version; - introduction, deprecation, removal, and replacement versions where applicable. Generic electrical metrics SHALL be preferred wherever possible. For example, battery power is represented as `active_power` at a battery Measurement Point, using the role-based sign convention. Domain-specific metric names are reserved for true domain concepts such as `state_of_charge`. ## 11. Canonical Units Each physical quantity SHALL use one canonical storage unit. Unit conversion SHALL occur before canonical storage unless the source value is already in the canonical unit. Reference canonical units include: | Quantity | Canonical Unit | |---|---:| | Active power | kW | | Reactive power | kvar | | Apparent power | kVA | | Energy | kWh | | Voltage | V | | Current | A | | Frequency | Hz | | Temperature | degC | | Ratio | percent | Dashboards and downstream systems SHOULD NOT apply corrective unit conversion to canonical telemetry. ## 12. Plant Registry The Plant Registry SHALL be the authoritative source for: - plants; - assets; - devices; - measurement points; - capabilities; - relationships; - lifecycle status; - canonical labels. The registry SHALL be schema-enforced. Registry data SHALL be validatable before generated configuration or documentation is produced. Collectors, dashboards, alert rules, deployment artifacts, and implementation configuration SHOULD derive from the registry. ## 13. Acquisition Topologies OCETS supports three acquisition topologies: | Topology | Description | |---|---| | Central acquisition | Central systems acquire telemetry from plants. | | Edge acquisition | Plant-local systems acquire and forward telemetry. | | Hybrid acquisition | Edge and central systems share acquisition responsibilities. | All acquisition topologies SHALL emit canonical telemetry with identical identity, units, metrics, labels, and timestamp semantics for the same physical measurement. ## 14. Time Model Telemetry timestamps SHALL represent acquisition time. Processing time, transport time, receive time, storage write time, and dashboard render time SHALL NOT replace acquisition time. All stored timestamps SHALL be represented in UTC. Acquisition systems SHALL synchronize against a centrally managed platform time service or an equivalent redundant time source. ## 15. Telemetry Health Telemetry health SHALL be modeled explicitly. Health telemetry SHOULD include: - device availability; - communication status; - collector status; - last successful acquisition; - timestamp skew; - pipeline status; - data freshness; - validation errors. Missing values SHALL NOT be silently converted to zero. Stale values SHALL NOT be presented as fresh measurements. ### 15.1 Edge Collector Observability Profile The Edge Collector Observability Profile is an optional OCETS conformance profile for plant-local systems that acquire, buffer, or forward telemetry. Implementations that claim this profile SHALL represent the edge collector as a stable Device with `role=collector` and `energy_form=operational`. The profile SHALL expose: - `device_available` for independently observed collector availability; - `collector_status`, `pipeline_status`, and upstream `communication_status`; - `data_freshness` as the age of the latest successful acquisition; - `time_sync_status` and `timestamp_skew`; - `buffer_utilization` and `buffer_oldest_age`; - `storage_utilization` and `storage_status`; - `transport_error_count`, `collector_restart_count`, `mapping_error_count`, and `validation_error_count`. An implementation MAY additionally expose `cpu_utilization`, `memory_utilization`, and `host_temperature`. Where suitable power-monitoring hardware exists, it MAY expose `external_power_available`, `backup_power_status`, and `backup_power_runtime`. Unsupported optional metrics SHALL be absent, not reported as zero or a healthy state. A required metric that cannot currently be determined SHALL use its defined `unknown` state where the metric type permits it. Hostnames, IP addresses, operating-system interface names, mount paths, and hardware serial numbers SHALL NOT form canonical identity. Edge Collector Observability conformance SHALL NOT be required from central-only deployments or from implementations that do not claim the profile. ## 16. Data Lifecycle and Downsampling Telemetry SHALL progress through the following lifecycle: ```text Acquisition -> Validation -> Canonical Mapping -> Storage -> Downsampling -> Long-Term Retention -> Consumption ``` Each lifecycle stage SHALL preserve semantic correctness. Downsampling SHALL respect metric semantics. The aggregation behavior for each metric SHALL be defined in the Canonical Metric Catalogue. Missing values SHALL NOT be converted to zero during downsampling. Retention durations are reference policy, not normative OCETS v1.1 requirements. A conforming implementation MAY choose different retention durations if it preserves the normative downsampling semantics of each metric. ## 17. Canonical Observation Model An Observation is the logical, implementation-independent representation of one telemetry value. Every Observation SHALL be resolvable to: - canonical metric name and catalogue version; - value and the canonical unit implied by the metric definition; - Plant and, where applicable, Asset, Device, and Measurement Point; - `acquired_at` in UTC; - quality; - provenance. The logical model MAY be stored as one record, multiple fields, or coordinated series. A storage implementation SHALL preserve or reconstruct every required property. Quality, provenance, catalogue version, calculation identifiers, and source references SHALL NOT be encoded as unbounded TSDB labels. Forecast-origin Observations SHALL additionally contain `issued_at` and `valid_at`. Derived or calculated Observations SHOULD identify the calculation definition and source Observations or source series. ## 18. Quality Model Every Observation SHALL carry or inherit exactly one quality value: | Value | Meaning | |---|---| | `GOOD` | Valid according to all applicable acquisition and validation rules. | | `BAD` | Known to be invalid and unsuitable for normal consumption. | | `UNCERTAIN` | Available, but validity cannot be established completely. | | `ESTIMATED` | Produced by an estimation method instead of direct acquisition. | | `SUBSTITUTED` | Replaced by an approved alternate value. | | `MISSING` | An explicit gap marker; it SHALL NOT contain a fabricated numeric zero. | | `SIMULATED` | Produced by a simulation rather than the physical process. | Downsampling SHALL report `GOOD` only when every contributing Observation is `GOOD`. Otherwise the conservative precedence from worst to best is `BAD`, `MISSING`, `UNCERTAIN`, `SUBSTITUTED`, `ESTIMATED`, `SIMULATED`, `GOOD`. Implementations MAY retain additional contributing-quality detail. ## 19. Provenance Model Every Observation and Event SHALL declare one origin: | Origin | Meaning | |---|---| | `device` | Directly acquired from a physical or logical Device. | | `calculated` | Deterministically calculated from other data. | | `forecast` | Produced externally as a prediction. | | `estimated` | Inferred because a direct value was unavailable or incomplete. | | `manual` | Supplied or corrected by an authenticated human workflow. | | `simulated` | Produced by a simulation or test environment. | Provenance SHALL identify the originating Device, calculation, model, or authenticated actor as applicable. Manual changes and substitutions SHALL be auditable. Provenance describes origin; quality describes confidence or usability, and neither SHALL replace the other. ## 20. Canonical Event Model Events are not Metrics and SHALL NOT be modeled as ordinary time-series samples. A canonical Event SHALL include: - globally unique `event_id`; - canonical `event_type` and `severity`; - typed source reference to a registered object; - `begin_at` and optional `end_at`, in UTC; - lifecycle state `open`, `acknowledged`, `closed`, or `cancelled`; - quality and provenance; - optional `correlation_id` and `causation_id`. Severity values are `info`, `warning`, `minor`, `major`, and `critical`. Initial event types are `alarm`, `warning`, `fault`, `maintenance`, `restart`, `firmware_update`, and `grid_failure`. Acknowledgement SHALL record actor, timestamp, and optional comment without overwriting event history. Re-delivery or update of an `event_id` SHALL be idempotent. `end_at` SHALL NOT precede `begin_at`. Event payloads MAY contain bounded type-specific attributes but SHALL NOT contain secrets. ## 21. Relationship and Topology Model A Relationship SHALL have a stable ID, Plant, Topology, type, typed `from` and `to` endpoints, lifecycle status, and validity interval. Allowed relationship types are: - `contains`; - `feeds`; - `connected_to`; - `measures`; - `controls`; - `powered_by`. `contains`, `feeds`, `measures`, `controls`, and `powered_by` are directed. `connected_to` is symmetric and SHALL NOT be duplicated in reverse order. A `controls` Relationship records semantic responsibility only and SHALL NOT imply command authorization or OCETS control conformance. A Topology is an immutable versioned graph for exactly one Plant. Its kind SHALL be `electrical`, `physical`, or `telemetry`. Grid connections, transformers, busbars, inverters, batteries, loads, collectors, Devices, and Measurement Points SHALL be represented using registered objects rather than topology-only identifiers. `contains` Relationships SHALL be acyclic. Electrical networks MAY be meshed; cycles in `feeds` and `connected_to` are permitted. Topology versions SHALL have non-overlapping validity intervals when they claim to be the active version of the same topology. ## 22. Multi-Tenancy An Organization is the tenant, ownership, authorization, and governance boundary. An Organization SHALL have a globally unique stable ID. A Portfolio SHALL belong to exactly one Organization. A Plant SHALL belong to exactly one Organization and MAY belong to zero or more Portfolios of that Organization. Canonical Plant identity remains globally unique and SHALL NOT depend on an Organization or Portfolio name. Relationships and Topologies SHALL NOT cross Organization boundaries. Cross-organization analysis MAY occur in an authorized consumer but SHALL NOT create cross-tenant registry ownership. Organization and Plant metadata MAY declare a data residency region. Such metadata informs deployment policy but does not replace applicable law or operator policy. ## 23. Registry API Profile A conforming Registry API SHALL provide authenticated, read-only HTTP/JSON access under `/api/ocets/registry/v1` to: - service metadata and available Registry revisions; - Organizations, Portfolios, Plants, Assets, Devices, Measurement Points; - Relationships, Topologies, Metric Definitions, and Event Types; - one consistent bulk snapshot; - changes since a retained Registry revision. Collections SHALL support opaque cursor pagination, a bounded `limit`, and filters for tenant, lifecycle status, and `updated_since`. Every response SHALL identify one immutable Registry revision. Implementations SHALL support `ETag` and `If-None-Match`; pagination across one traversal SHALL remain snapshot-consistent. Errors SHALL use a JSON object containing stable `code`, human-readable `message`, and `request_id`. Resource absence SHALL be distinguishable from lack of authorization without leaking cross-tenant existence. Mutation, approval, and deployment APIs are outside this profile. ## 24. Security Model OCETS implementations SHALL: - use distinct identities for people, services, collectors, and Devices; - authenticate every non-public Registry API and telemetry connection; - encrypt telemetry and Registry traffic in transit; - apply default-deny authorization by Organization, resource, and action; - prevent credentials, private keys, tokens, and other secrets from entering Registry data, labels, Events, or logs; - protect sensitive data at rest according to its classification and residency policy; - audit Registry changes, manual provenance, Event acknowledgement, authorization changes, and security-relevant access; - support credential and certificate rotation without semantic identity changes. Network location alone SHALL NOT establish trust. Service and collector permissions SHALL follow least privilege. Audit records SHOULD be tamper-evident and retained under governed policy. Security incidents and credential compromise SHALL have documented revocation and recovery procedures. ## 25. Governance OCETS uses semantic versioning. Governance roles are Maintainer, Architecture Review Board, and Extension Owner. Normative changes SHALL have an identified owner, review record, compatibility assessment, and, when architectural, an ADR. Version 1.x releases MAY add canonical metrics, labels, capabilities, optional registry fields, event types, and non-breaking clarifications. Version 2.0 is required for changed identity semantics, changed canonical units, removed required fields, incompatible timestamp rules, or incompatible metric meanings. Metric definitions SHALL record `definition_version`, `introduced_in`, `deprecated_in`, `removed_in`, and `replaced_by` where applicable. A released definition is immutable. Deprecation SHALL provide a replacement or rationale and remain supported for at least one subsequent minor release before removal. Local extensions SHALL use `x--` namespaces and SHALL NOT redefine canonical names or controlled values. Released catalogue and conformance-profile versions SHALL remain retrievable. Security reports SHALL have a documented confidential disclosure and remediation process. ## 26. Conformance Core OCETS v1.1 conformance requires an implementation to: - implement the canonical information and Observation models; - use canonical metric names, units, quality, and provenance; - use the role-based power sign convention and OCETS timestamp rules; - expose telemetry health and enforce the Security Model; - validate Registry data against a schema or equivalent enforceable contract; - satisfy all mandatory `SHALL` requirements and preserve implementation separation. Event, Topology, Multi-Tenancy, Registry API, and Edge Collector Observability are claimable conformance profiles. An implementation SHALL satisfy every mandatory rule of each profile it claims. Representing only one Organization does not waive tenant isolation requirements if the Multi-Tenancy profile is claimed. Conformance does not require a specific software stack, control capability, or preservation of legacy and vendor-specific names.