Data collection · Data layer

Data collection from energy technology

Data collection from PCS, BMS, protection relays, inverters, meters and control systems — into one data model, with REST and webhook interfaces for downstream systems. Industrial IoT built so that the next device is a line of config, not another integration project.

Discuss the data platform System integration →

Unifying data across vendors

The most common problem in energy is not lack of data — there is plenty of it, but every vendor emits it differently. Data integration in energy means collecting streams from Modbus TCP on the PCS, IEC 61850 on relays, proprietary CAN on the BMS and REST API on the aggregator and transforming them into one model. Our approach:

  • Register maps as data — every register is described by a JSON document (address, type, unit, scale, alarm threshold). Adding a new device type is a new file, not new code.
  • Multi-protocol edge module — Modbus TCP/RTU natively, IEC 61850, OPC UA and MQTT via bridging. One container handles any combination of technology on the site.
  • Unified cloud data model — regardless of vendor, values land in the telemetry collection with a stable schema { deviceId, timestamp, data }.
  • Safe remote writes — data collection is read-only by default. Write scope is opt-in and always paired with audit, RBAC and rate limiting.

An energy data platform, end to end

Data collection alone isn't enough — there must be a path for a downstream system to turn data into decisions. The ECC data platform covers the full lifecycle:

Edge collection

Default 30 s polling (per-register configurable), batched reads for efficiency, offline SQLite buffer with catch-up.

Transport

AMQP over TLS to Azure IoT Hub, per-device authentication, IoT Edge with signed identity. Encrypted end-to-end.

Storage

Cosmos DB in MongoDB API mode, indexed on deviceId and timestamp. Scales horizontally with volume.

Processing and distribution

REST API, webhooks, streamed events to downstream systems (BI, EMS, dispatch, trading platform).

Industrial IoT on top of an established platform

Most industrial IoT projects in energy are built from zero for every engagement. Our offering shortens that timeline to weeks by having the tenant, edge module, cloud layer and dashboard already running in production:

  • Reference deployment at Poustka — 9 devices, 913 data operations every 30 seconds, edge module in production continuously. A live benchmark to point at.
  • Modular data layer — fits monitoring and dispatch alike. Not just ingest — also an output API for downstream systems.
  • Path to EMS and aggregators — the data layer is the entry point for forecasting, flexibility trading and integration with a trading platform.
  • NIS2-ready ingest — data transport and writes to devices both carry a cryptographically verifiable audit. Ready for a regulated operator.

Data collection and processing — technical detail

Specific technical properties that separate a serious data platform from an industrial "dump data to CSV" solution:

  • Send-on-change filtering — 10× volume reduction for static registers, with a guarantee that a full state re-broadcast follows an edge restart.
  • Hot-reloadable configuration — changing a polling interval or an alarm threshold via Device Twin, no container rebuild.
  • Blob-based large configurations — for sites with dozens of devices where config exceeds the Twin 32 KB limit and is served from Azure Blob.
  • Register map seed and sync — the DB register map is kept in lock-step with the edge configuration by a dedicated tool, no "stealth" divergence.

Frequently asked

What protocols does the edge module support?

Natively Modbus TCP and RTU. Via bridging: IEC 61850 (MMS, GOOSE), OPC UA and MQTT. Proprietary CAN and serial protocols are handled case-by-case.

How many devices and operations can one site handle?

Production today is 9 devices and 913 operations on a 30 s cycle. The architectural limit is the edge gateway hardware and Modbus TCP throughput, not the software.

How long do you keep data?

By default indefinite (Cosmos DB, retention per collection as configured). Typically a year of raw data plus five years of aggregates, negotiable individually.

Can we stream data into our own system?

Yes — either REST pull (polling with ETag), webhook push on critical events, or a direct Azure EventHub hook off the ingest pipeline.

Who owns the data?

Always the customer. Operations are delegated to us under SLA, ownership is the customer's. On contract termination we provide a full export.

DOC.99 — Contact REV.A

Thirty minutes, live platform.

Book a walkthrough