Why smoc.cloud

Not a generic IoT dashboard with smart-meter branding.

smoc.cloud wasn't built by people who simply understand smart metering protocols. It was built by people who have written and implemented them. That first-hand knowledge of DLMS/COSEM, CIM and MultiSpeak is engineered into the platform. smoc.cloud understands the devices, objects, events, relationships and operational context behind the data, turning information from across the complete device estate into actionable intelligence. Fewer tools. Faster diagnosis. Fewer surprises. Better operational decisions. And evidence you can confidently put in front of a regulator.

1
Operations platform for all four utilities
6
Vendor system classes on one platform — HES, MDMS, billing, GIS, ADMS and cellular connectivity
<5 min
From meter-off event to operator alert
100%
RLS-enforced tenant isolation — applied at the database layer, not in application logic
100%
Of writes captured in the audit log — every change attributable to an actor, tenant and timestamp
0
Spreadsheets left to maintain
ADV-01

Vendor-agnostic, unified operations

One platform integrates across the entire smart metering stack — HES, MDMS, billing, GIS, ADMS and cellular connectivity — ingesting real DLMS/COSEM, CIM and MultiSpeak traffic from multiple vendors at once. Adding a new MDMS or billing vendor is a connector, not a platform rewrite.

Elster
L+G
Itron
one estate
without
One console per vendor
with smoc.cloud
One estate model, any vendor
ADV-02

Real visibility, not vanity metrics

Read-success and online-percentage KPIs are computed from actual device-reporting data — never static or seeded numbers — backed by a configurable KPI catalogue, live SLA dashboards, escalation policies, breach tracking and a complete audit log. When the regulator asks, the evidence already exists.

SLA ✓
without
Spreadsheet assembled before the audit
with smoc.cloud
Live dashboards + audit trail
ADV-03

True multi-tenant isolation

Every table holding tenant data is protected by row-level security enforced at the database layer, not just in application logic — so one tenant's data genuinely cannot surface in another's queries, even if a route has a bug. Severity rules, KPI thresholds and roles are configured per tenant on one platform.

tenant_a
tenant_b
tenant_c
one platform
without
App-layer checks, per-customer forks
with smoc.cloud
Database-enforced RLS, one platform
ADV-04

Granular, auditable access control

A permission catalogue of 90+ distinct keys — not just admin/viewer — lets a tenant define exactly who can view a connector, who can acknowledge an exception and who can issue a command that changes something in the field. Consequential actions like remote disconnect and MDMS commission/decommission are deliberately separated from routine ones.

ops_admin · write
analyst · read
regulator · kpi_only
audit.log → actor · tenant · ts
without
Shared admin accounts, no trail
with smoc.cloud
90+ scoped permissions, attributable
ADV-05

Field-to-office continuity

Job dispatch, ticketing and escalation live in the same platform as connector and device data: alerts become triage cases, cases become field jobs, firmware findings become campaigns. Operators stop jumping between a monitoring tool and a separate work-order system.

alert→
case→
job→
closed
without
Monitoring tool + separate work orders
with smoc.cloud
Alert → case → job → closed
ADV-06

Global-ready out of the box

The UI supports 35 languages, including right-to-left, with tenant-level language restrictions — built for utilities and integrators operating across multiple countries, regions and regulatory regimes.

endefresar ←
without
English-only operator screens
with smoc.cloud
35 languages, RTL, per-tenant
ADV-07

Security built in, not bolted on

Secrets are managed through a dedicated vault with fail-closed behaviour — the system refuses to start rather than run with a required secret missing. Credentials are encrypted at rest, and every write against tenant data passes the same RLS and permission gate.

hes.api_keyencrypted
mdms.tokenencrypted
kafka.saslencrypted
secret missing → boot refused
without
Secrets in config, silent fallbacks
with smoc.cloud
Vaulted secrets, fail-closed startup
ADV-08

Built for scale and reliability

The architecture accounts for Kafka-based ingestion, connection-pool safety around outbound vendor calls, and a migration and RLS test discipline that catches tenant-isolation regressions before they ship.

devices
kafka
pool safe ✓migrations ✓rls tests ✓
without
Untested migrations, surprise regressions
with smoc.cloud
Kafka ingestion + RLS test gates
ADV-09

Fewer truck rolls, caught before they're needed

Per-device read-success and connector-health are computed continuously, so degraded meters surface on the estate heatmap and in alerts on day one — not three billing cycles later. Each field visit costs tens of pounds in technician, vehicle and scheduling overhead, so catching read failures early across a large fleet is one of the most directly quantifiable ROI levers a metering operations platform offers.

read_success 97.8%4 flagged → day-one dispatch
without
Found in billing, three cycles late
with smoc.cloud
Detected day one, one planned visit
Who it is for

Utilities, integrators and vendors.

Three kinds of organisation run smoc.cloud — for three different reasons.

Utilities

Electricity, gas, water and heat utilities replacing one-tool-per-utility with a single operations platform they can prove compliance from.

System integrators

Integrators who need an operations layer above the hardware and head-ends they deploy — configurable per client, isolated per tenant.

Meter and HES vendors

Vendors who want their devices and head-ends operated well alongside everyone else's, through standard DLMS, CIM and MultiSpeak interfaces.

technical_architecture

Every system in the stack, normalised into one operational picture.

Data arrives from the head-end systems, bearer management platforms, MDMS, ADMS, GIS, SIEM and billing systems already in your estate. smoc.cloud normalises all of it into a single overview, lets operations act on that overview, and records every action as evidence.

data flow architecture
Ingestion — HES, bearer management, MDMS, ADMS, GIS, SIEM and billing systems
L1
Normalisation — one estate overview, whatever the vendor or system of origin
L2
Operations — alert triage, remote actions, KPI evaluation, SLA dashboards
L3
Evidence — every operation recorded, audit trail and compliance exports
L4
every layer attributable to actor, tenant, timestamp
adoption_path

From vendor exports to one operations platform.

A staged route that starts with the head-ends you already run and ends with compliance you can prove from live data.

01

Connect the head-ends you already run

elsterlandis+gyritronsagemcom
02

Normalise devices, registers and events

dlms/cosemobiscimmultispeak
03

Run operations from one screen

alertscommandsfield_ops
04

Prove compliance from live data

kpi_slaaudit_trailsiem
Quantify it

ROI calculator

Model the annual field cost your estate can avoid with remote fault resolution.

Open the ROI calculator
next_step

See your estate in smoc.cloud.

A demo walks through your utility types, your vendors and your compliance obligations — not a generic slide deck.