Category: Energy

SAREF4WATR & SAREF4GRID Join Smart Data Models: 89 Candidate Models for Water and Smart Grid Metering

  By ,

Smart Data Models’ Candidates repository now includes two more ETSI SAREF extensions, both built around smart metering: saref4watr and saref4grid, together contributing
89 candidate models — the largest pair in this translation round. Both ship the full Candidates artifact set — a JSON Schema, an NGSI-LD @context, and all four example serializations — validated against its own schema.

SAREF4WATR — 49 models

SAREF4WATR (ETSI TS 103 410-10) spans the entire water domain: natural water bodies (rivers, lakes, aquifers, glaciers), the infrastructure that moves and treats water (distribution systems, treatment plants, gauging stations, hydroelectric plants), individual field assets (pipes, valves, pumps, fire hydrants, manholes), and smart water meters with their tariff models.

Category Models
Natural water bodies Water, Aquifer, Estuary, Glacier, Lagoon, Lake, Ocean, River, Sea
Water infrastructure DistributionSystem, StorageInfrastructure, MonitoringInfrastructure, TreatmentPlant, HydroelectricPowerPlant, GaugingStation
Assets — transport/storage/devices Channel, Intake, Main, Manhole, Pipe, Pit, Vent, Tank, Reservoir, FireHydrant, Pump, Valve, WaterMeter
Meter/tariff model Tariff, ConsumptionBasedTariff, ThresholdBasedTariff, TimeBasedTariff
Property-grouping / controlled-vocabulary AcceptabilityProperty, BacterialProperty, ChemicalProperty, MicrobialProperty, WaterFlowProperty, WaterUse

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4watr

SAREF4GRID — 40 models

SAREF4GRID (ETSI TS 103 410-12) is SAREF’s extension for smart electricity metering, explicitly designed to mirror DLMS/COSEM (IEC 62056) so its classes map cleanly onto real meter data — every COSEM object carries an OBIS code (hasObis), the same identifier engineers use on the wire. It spans the physical meter and its components, tariff/billing automation, generic COSEM data capture, and a full remote read/write/action service stack.

Category Models
Device & device management GridMeter, Firmware, NetworkInterface, Clock, BreakerState
Tariff/billing automation ActivityCalendar, SeasonProfile, DayProfile, ScriptTable, Script
Data capture ProfileGeneric
Power-line / meter property kinds EnergyAndPowerProperty, QualityProperty, MeterProperty, PowerLine
COSEM remote services & operations GetService, SetService, ActionService, plus 16 related operation/input/output models

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4grid

Translation notes

  • Measurable quantities kept as open vocabularies, not exploded into entities. Both standards express specific measurable properties (water quality parameters, ActiveEnergy, Voltage, Current, ReactivePower…) as named individuals of a handful of grouping classes rather than as classes in their own right. Each group class was
    modeled once, with an enum closed to its own named-individual set (plus a broaderPropertyType/taxonomic field where the source ontology defines a broader/narrower relationship) — giving full fidelity to every named individual without near-duplicate entity types.
  • DLMS/COSEM alignment preserved. SAREF4GRID’s OBIS-coding convention is carried through to the candidate schemas via hasObis, keeping the translation directly usable against real meter data rather than an abstraction that loses the wire-level identifier.
  • Inheritance flattened, not duplicated, following this repo’s established Gaia-X precedent — SAREF4WATR’s deep taxonomy of water-body and asset “kinds” each still gets its own candidate model, documenting its taxonomic role rather than repeating inherited properties.
  • No naming collisions found against existing official Smart Data Models subjects for SAREF4GRID; SAREF4WATR’s Water entity does conceptually overlap with the already-published WaterQualityObserved model — flagged, not resolved, for reviewers to reconcile at promotion time.

Try it, and tell us what’s missing

These are Candidates — first, carefully-sourced translations, not yet promoted to official Smart Data Models subjects. The Water / WaterQualityObserved overlap above is the main open item before promotion.

Browse the models, open an issue, or send a PR:

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4watr
https://github.com/smart-data-models/Candidates/tree/master/standards/saref4grid

SAREF4ENER & SAREF4ENVI Join Smart Data Models: 116 Candidate Models for Energy Flexibility and Environment

  By ,

Smart Data Models’ Candidates repository now includes two new candidate standards translated from ETSI’s SAREF (“Smart Applications REFerence”) ontology family: saref4ener and saref4envi, together contributing 116 candidate models. Both are official ETSI Technical Specifications, each with a normative PDF and a published Turtle/JSON-LD/RDF-XML ontology, and both ship the full Candidates artifact set — a JSON Schema, an NGSI-LD @context, and all four example serializations (NGSI-v2 and NGSI-LD, key-values and normalized) — validated against its own schema.

SAREF4ENER — 61 models

SAREF4ENER (ETSI TS 103 410-1) is the SAREF extension for energy flexibility and demand-response: the vocabulary behind smart appliances, batteries, and loads that can shift or modulate their power consumption in response to grid signals or incentives. It covers seven distinct “flexibility profile” shapes (power-envelope, power-limit, fill-rate, incentive-table, demand-driven, operation-mode…), the request/offer/instruction messages exchanged between a flexibility provider and a grid operator, load-control events and states, and the generic data-point/time-series building blocks used throughout.

Category Models Examples
Flexibility profiles & elements 14 PowerEnvelopeProfile, FillRateProfile, IncentiveTableProfile, OperationModeProfile
Instructions (one per profile type) 10 OMBCInstruction, FRBCInstruction, PEBCInstruction, DDBCInstruction
Flexibility communication 3 FlexRequest, FlexOffer, FlexibilityInstruction
Load control 4 LoadControlEventData, LoadControlStateData, LoadControlEventAction
Power/energy constraints & limits 8 PowerConstraint, PowerLimit, FailsafePowerLimit, ContractualPowerLimit
Data & scheduling 7 DataPoint, TimeSeries, GaussianDataPoint, Slot, Timer
Core & other 15 Device, Storage, PowerSequence, Role, Incentive

Branch: saref4ener-candidates — PR not yet opened.

SAREF4ENVI — 55 models

SAREF4ENVI (ETSI TS 103 410-2)
covers two distinct worlds under one ontology: a lighting/light-pollution domain (lampposts, light points, illuminance/sky-brightness observations) and a full waste-management lifecycle — from a resident’s bin, through collection rounds, to treatment, disposal, and the emissions and secondary resources that treatment produces.

Category Models Examples
Buildings/urban 9 Building, City, Neighbourhood, CollectionOfBuildings
Waste treatment devices 14 Composter, AnaerobicDigester, IncineratorWithRecovery, Sorter
Collection 6 CollectionPoint, Depot, Itinerary, WasteCollectionVehicle
Treatment tasks & functions 8 WasteTreatmentTask, WasteDisposalFunction
Lighting 4 Light, LightPoint, Lamppost, ShieldedLamppost
Waste core / resources / emissions 11 Waste, FinalWaste, Resource, Emission
General 3 DigitalRepresentation, CommunicationInterface, CommunicationProtocol

A rich object-property graph (accepts, isProducedBy, isDepositedIn, becomes, followsItinerary…) is translated throughout as NGSI-LD Relationships between these models.

Branch: saref4envi-candidates — PR not yet opened.

Translation notes

  • Open vocabularies stay open. Both ontologies lean heavily on abstract “Kind” classification classes (WasteKind, ContainerKind, EmissionKind…) whose members are a small, fixed vocabulary rather than independently-instantiable things. Rather than creating dozens of near-empty entity types, these were folded into open/enumerated string attributes on the entities that actually reference them (e.g. Container.acceptedWasteKinds, Emission.emissionKind).
  • Names preserved verbatim. SAREF4ENVI’s own class and property names were already PascalCase/camelCase and needed zero renaming. SAREF4ENER’s profile/instruction naming (OMBCInstruction, FRBCInstruction, …) is kept exactly as the ontology defines it.
  • Inheritance flattened, not duplicated. Following the precedent set by this repo’s Gaia-X candidate, a subclass’s schema lists only its own attributes; inherited ones are documented in its description instead of repeated (e.g. SAREF4ENVI’s House/NonResidentialBuilding point back to Building/Perimeter).
  • License recorded exactly as found. Both ontologies’ dcterms:license resolves to ETSI’s own software license terms (BSD-3-Clause for SAREF4ENVI) — recorded in each standard’s standard-metadata.yaml for confirmation before promotion out of Candidates.

Try it, and tell us what’s missing

These are Candidates — first, carefully-sourced translations, not yet promoted to official Smart Data Models subjects. A few things are open and would benefit from community input before that step: license confirmation for the specific v2.1.1 releases, and a check for overlap with existing official subjects (dataModel.Device, dataModel.Environment,
dataModel.WasteManagement-adjacent models).

Browse the models, open an issue, or send a PR:
👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4ener
👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4envi

No comments

New data model for battery. StorageBattery

  By ,

There is a new data model StorageBattery

The storage battery data model is intended to describe the technical characteristics of the battery and the charging and discharging conditions of the energy. The charging functionalities apply from a power source which can be an ‘on-board system, solar panel, wind turbine, generator, power supply’. Hydraulic sources are not included in this version. The discharge functions apply to all types of the system requiring energy consumption from a storage battery. *Remark* This Data Model can be used directly as the main entity to describe the device *Battery Storage* or as a sub-entity of the Data Model *DEVICE* using a reference by the *refDevice* attribute.

No comments

New harmonized data models

  By , , , , , , ,

Harmonization repository is dedicated to those data models that are mostly accepted and only requirements of consistency, complete documentation and examples availability.

Here there is a list of coming data models in different domains:

Battery
StorageBattery
StorageBatteryDevice
StorageBatteryMeasurement

Energy
ACMeasurement
InverterDevice
PhotoVoltaicDevice
PhotovoltaicMeasurement

Environment
ElectroMagneticObserved
PhreaticLevel
RainFallRadarObservation

Ports
BoatAtuthorized
BoatPlacesAvailable
BoatPlacesPricing
SeaportFacilities

Smart cities
CityWorks
StationDescription

No comments

New data models on Energy

  By ,

There are two data models coming for the Energy domain (ACMeasurement and InverterDevice). You can submit an issue on it if interested.

Once harmonized with the contributors and checking the interaction with other data models they will be incorporated into the Energy repository inside the domain of Smart Energy.

ACMeasurement

The Data Model intended to measure the electrical energies consumed by an electrical system which uses an Alternating Current (AC) for a three-phase (L1, L2, L3) or single-phase (L) and neutral (N). It integrates the initial version of the data Modem [THREEPHASEMEASUREMENT], extended to also perform single-phase measurements. it includes attributes for various electrical measurements such as power, frequency, current and voltage.

Additional Information about Attributes : For some attributes such as current and voltage the value is a structured value with properties for the Single-Phase (L) or three different phases (L1, L2 and L3). For some measurements such as the different power types (active, reactive and apparent power) there is an attribute for the total from all phases. The rules are defined as below : – Three Phase – Total = L1 + L2 + L3 – Single Phase – Total = L.

For most of the attributes, there are various ways they can be actually measured. For this purpose the measurementType Meta Data Attribute can be used. It can have the following values:

When using the values [average, rms, minimum, maximum], another metadata attribute called measurementInterval should be used to give the length of the measurement period in seconds. Also the Meta Data timestamp attribute should be the end time of the measurement period.

InverterDevice

The Data Model is intended to describe the mechanical, electrical characteristics of an Inverter according to DC – Direct Current Information supplied as input and AC – Alternating Current Information returned as output.

Additional Information about Data Model: This Data Model can be used directly as the main entity to describe the device [INVERTER] or as a sub-entity of the Data Model [DEVICE] using a reference by the refDevice attribute.

No comments

Subscribe to the data models you are interested

  By , , , , , , , , , , ,

If you are not a developer (But if you are you can also use it) we have created a page for being updated about the last news of your domain of interest

Check the 10 mail lists available, one per domain. Click in the image to access it.

It is also available in the main menu in the option Subscribe