Context
In an energy IoT environment, data does not arrive from one system or at one speed. Field devices, sensors and measurement points continuously produce state, event and time-series data. Device descriptions, geographical and network relationships, and information from other source systems provide its surrounding context.
The same measurement can create value in several situations. Operations teams look for current state and anomalies, analysts examine patterns over time, reporting requires comparable metrics, and future automated solutions depend on a reliable and understandable data foundation.
The challenge was therefore not simply to store a large volume of readings. What was needed was a shared data journey that treated fast events and long-term relationships as parts of the same system.
A sensor value on its own is only a signal. The device, location, time and network context make it meaningful.
The architectural question
The central question was how to connect the event-driven field environment to the structured, historised data required for analytics.
This meant handling several needs together:
- different measurement structures arriving from many types of device;
- near-real-time events alongside batch processing;
- multiple time resolutions for the same measurement;
- relationships between devices, ports, measurement points and network assets;
- missing data, delays and invalid values;
- and different expectations across operations, reporting and analytics.
The platform could therefore be understood neither as a time-series store nor as a reporting database alone. Devices, telemetry and business meaning had to be organised into one information architecture.
Constraints
Several connected conditions shaped the design:
- a device landscape and set of measurement types that would grow gradually;
- data arriving through different protocols and source systems;
- high-frequency, timestamped measurements;
- the possibility of network interruptions and late-arriving events;
- raw and aggregated data at different resolutions coexisting;
- different lifecycles across operational systems and the analytical platform;
- and the need for traceability and long-term extensibility.
The architecture had to accept new sources while keeping the meaning of existing data flows and user views stable.
Approach
The device first, then the measurement
The shared model centred on physical and logical devices rather than individual reports. Device type, function, port, measurement point, location and network relationship formed separate but connected parts of the context.
Current, voltage, power, state and quality measurements were attached to this foundation. The same device context could therefore be used consistently across several measurement domains and forms of consumption.
Two speeds, one data journey
Event-driven ingestion served the need for fresh state and rapid response. In parallel, a persistent, historised layer preserved relationships over time and made reprocessing possible.
These were not separate platforms. Shared identifiers, time handling, metadata and quality rules connected them, allowing current signals and historical analysis to rely on the same meaning.
The semantic model before the report
A shared analytical model was established before the user interfaces. Facts linked to device and time dimensions enabled consistent filtering, comparable metrics and navigation across several measurement domains.
Reports were therefore not built as isolated queries. They became different views of one shared model: from asset overview and data quality to time-series curves, threshold monitoring and anomaly investigation.
Architecture
The platform organised the data journey into four connected stages:
- 01Field devices and sensors
- 02Edge ingestion and event handling
- 03Streaming and persistent historical storage
- 04Shared asset and measurement model
Ingestion close to the field separated device communication from the internal operation of central processing. Event distribution provided a scalable and observable path for fresh data, while persistent storage retained the history of raw and processed measurements.
The shared asset and measurement model added meaning to this foundation. Operational overviews, time-series and data-quality analysis, management reporting and later advanced analytical uses could all build on it.
Key decisions
Separate lifecycles for asset data and telemetry
A device description, its relationships and location change at a different pace from its measurements. Separating the two provided a clearer model and more controlled change management, while stable identifiers kept them connected.
Resolution as a property of the data
Raw and aggregated measurements at different frequencies were not given separate meanings. Resolution became an explicit property of the measurement, allowing short periods to be examined in detail and longer periods in aggregated form using the same concepts.
Data quality as operational information
A missing reading, stale asset record, invalid coordinate or unknown unit is not merely a technical defect. The platform treats these as visible states because the usability of the data and the reliability of decisions depend on them.
Visualisation shaped around the user journey
The first view provides an overview of assets and their state, from which the user can move towards detailed device, port and measurement data. Reporting therefore follows the user’s reasoning: first identify what is happening and where, then examine the associated signals over time.
Outcome
The resulting platform approach organised asset and measurement data that had previously been viewed from different perspectives into one shared structure.
- Field ingestion and analytical processing were separated into clear layers.
- Devices, ports, functions and measurements became available in a shared context.
- The same semantic foundation could support several measurement types and user views.
- Fresh events and historical analytics became complementary capabilities rather than competing approaches.
- Data quality moved from a background check to visible operational information.
- New sensors and forms of use could connect through repeatable patterns.
The value did not reside in one dashboard or measurement curve. It came from a shared data journey capable of supporting several current and future uses.
Lessons learned
The most important building block of an IoT data platform is not the sensor reading itself. Lasting value comes from the context that explains which device measured what, where, when and under what conditions.
When event-driven operation, historical data management and shared semantics are connected from the beginning, the same data can support operations, analytics and future automated decisions at the same time.