The architecture behind the operations console
The architecture underneath the operations console: one correlated event timeline, one semantic model of a multi-vendor estate, and the telecoms and security layers that span both.
Built to sit above any vendor, not beside one
smoc.cloud is not a dashboard bolted onto a head-end system. It is an operational intelligence platform with its own correlation engine, its own semantic information model, and its own multi-tenant security architecture — which is what allows it to sit above any combination of meters, head-ends, communications networks and enterprise systems you already operate.
Each layer below is independently useful and deliberately ordered. Correlation makes events comparable. The information model makes a multi-vendor estate queryable as one estate. Telecommunications intelligence applies both to the largest single cause of unresolved reads. Security architecture spans every layer, because a platform holding operational data for multiple utilities has to isolate them by design rather than by configuration.
Five layers, two cross-cutting disciplines
Telemetry is ingested from any network and any vendor, correlated onto one timeline, given consistent meaning by the semantic model, and only then used for prediction and simulation. Security spans every layer; telecoms intelligence draws on all of them.
The Utility Digital Twin Framework
A live, topology-aware model of the estate that bridges the field and the enterprise — so a field event is judged against what the estate should be doing, not only against what it reported.
- Smart meters
- Gas, water and heat
- EV charge points and PV generation
- Concentrators
- Bearers — RF, cellular, PLC
- 01 · Observe
Every device and every event ingested from any network, any head-end, any vendor — including devices you have not procured yet.
- 02 · Correlate
Field, network, head-end and enterprise events ordered onto one timeline per device and per population, so cause is derived rather than assumed.
- 03 · Model
Each device bound to its asset, feeder, site, service point and customer in the CIM-aligned semantic model.
- 04 · Mirror
A continuously updated twin of asset, topology and behaviour state, kept current as the estate is commissioned, replaced or reconfigured.
- 05 · Simulate
Expected-behaviour comparison and what-if analysis run against the real estate, not a spreadsheet approximation of it.
- HES — head-end system
- MDMS — meter data management
- ADMS — advanced distribution
- GIS — geographic information
- SIEM — security
- Billing / ERP
Nothing travels from a meter into an enterprise system as an isolated reading. Each event is resolved to a canonical device, placed on the correlated timeline and bound to its asset and topology — which is why the same twin can answer an operational question, a regulatory question and a network-planning question without being rebuilt for each.
The twin framework in detail
Coverage across meters, communications, distribution assets, customer premises and operational workflows — and what impact analysis, what-if modelling and predictive planning look like on top of it.
The layers in detail
Each area is documented on its own page, in dependency order. Correlation and the information model underpin everything above them.
See your estate in smoc.cloud.
A demo walks through your utility types, your vendors and your compliance obligations — not a generic slide deck.