DLMS/COSEM–CIM Semantic Information Model
Vendor neutrality is a data-modelling problem. One canonical model of measurements, events, assets and topology — authored once, valid across every vendor in the estate.
Standards alone do not make an estate comparable
Vendor neutrality is easy to claim and hard to build. The hard part is not connecting to two head-end systems — it is making the data behind them mean the same thing. DLMS/COSEM gives the industry a standard for what a meter exposes, and IEC CIM gives the enterprise a standard for how assets, networks and customers relate. Neither, on its own, lets you ask one operational question across a mixed estate.
smoc.cloud maintains a semantic information model that binds the two. OBIS codes, register profiles and event catalogues from each device type are mapped onto a CIM-aligned model of devices, assets, locations, networks and customers. Queries, rules, SLAs and reports are written against that model — once — and remain valid as vendors, firmware versions and head-ends change underneath.
What the model binds together
Six mapping disciplines, maintained per device type and per firmware version.
- 01active
OBIS register mapping
Per device type and firmware version: energy, demand, instantaneous, load profile and diagnostic registers mapped to canonical measurement definitions with units, scaling and interval semantics preserved.
01activeOBIS register mapping
Per device type and firmware version: energy, demand, instantaneous, load profile and diagnostic registers mapped to canonical measurement definitions with units, scaling and interval semantics preserved.
- 02active
Event and status catalogue
Vendor event codes, tamper and quality flags, and communication statuses normalised to a common catalogue with operational severity, so alert rules are vendor-independent.
- 03active
CIM-aligned asset model
Devices bound to assets, locations, feeders, sites, service points and customers using IEC CIM concepts, so metering data joins the enterprise view of the network.
03activeCIM-aligned asset model
Devices bound to assets, locations, feeders, sites, service points and customers using IEC CIM concepts, so metering data joins the enterprise view of the network.
- 04active
Multi-utility measurements
Electricity, gas, water and heat modelled in one framework: differing units, cumulative and interval semantics, and utility-specific quality rules, without four separate systems.
- 05active
Firmware-aware profiles
The model is versioned against firmware, so a register that changes meaning after an upgrade does not silently corrupt a trend or a settlement input.
05activeFirmware-aware profiles
The model is versioned against firmware, so a register that changes meaning after an upgrade does not silently corrupt a trend or a settlement input.
- 06active
Protocol coverage beyond DLMS
Where an estate includes non-DLMS or proprietary devices, they are mapped into the same canonical model rather than being handled as exceptions outside it.
Protocol and vendor coverage
The mapping layer is where multi-vendor estates stop being exceptional cases and become ordinary operations.
Why the model is the vendor-neutrality guarantee
Every claim about multi-vendor operation elsewhere on this site depends on this layer holding.
Comparable vendor performance
Because measurements and events mean the same thing, comparing two manufacturers or two head-ends becomes an arithmetic exercise rather than an argument about definitions.
See the model applied to the hardest domain
Telecommunications intelligence combines the correlated timeline and the semantic model to determine root cause across bearer, network, head-end, integration and meter.
See your estate in smoc.cloud.
A demo walks through your utility types, your vendors and your compliance obligations — not a generic slide deck.