The Problem With SCADA Data Is Not the Data
Every substation in a modern electric utility generates a continuous stream of operational telemetry. Voltage readings, current measurements, frequency deviations, breaker states, fault indicators — the data exists, it is rich, and it is largely inaccessible to the kind of real-time intelligence that modern grid operations require.
The reason is not the sensors. It is the layer between the sensors and anything useful.
SCADA systems were designed in an era when "real-time" meant polling every thirty seconds, when data lived in historian databases that were never meant to be queried at scale, and when the idea of running machine learning models against live substation telemetry would have seemed like science fiction. The protocols those systems speak — Modbus, DNP3, IEC 61850, OPC-UA — are purpose-built for reliability and determinism in electrically noisy industrial environments. They are not purpose-built for cloud integration.
This is the architectural problem HOP Sensors was built to solve. Not by replacing existing SCADA infrastructure — that is a decade-long capital project — but by building an ingestion layer that speaks industrial protocols natively and translates them into a cloud-native data pipeline in real time.
Design Principles
Before describing the architecture, it is worth being explicit about the constraints that shaped it. These were not arbitrary choices — they reflect the operational realities of deploying software inside electric utility environments.
No disruption to existing operations. Any system that touches operational technology in an electric utility must be deployable without affecting normal grid operations. HOP Sensors connects to SCADA data streams as a read-only observer. It does not write to SCADA systems, does not issue control commands, and does not insert itself into any control path.
Protocol agnosticism as a first-class requirement. A utility operating infrastructure built across three decades will have substations speaking Modbus, others speaking DNP3, and newer installations speaking IEC 61850 or OPC-UA — sometimes in the same substation. The ingestion layer must handle all of them without requiring custom integration work for each deployment.
Latency budgets that match operational requirements. A threshold alarm that fires thirty seconds after a fault has already started a cascade is not useful. The architecture is designed around a five-second telemetry refresh cycle and an end-to-end alert latency target of under 50 milliseconds from sensor reading to operator notification.
Security posture compatible with critical infrastructure requirements. The ingestion layer must operate within — or alongside — the security boundaries that utility OT networks require. This shapes the deployment model significantly.
The Protocols We Support
Each industrial protocol has its own characteristics, strengths, and quirks. The HOP Sensors ingestion layer handles all of them through a common internal representation.
Modbus TCP/RTU
The most widely deployed industrial protocol in existence. Simple, reliable, and ubiquitous in legacy substations. HOP Sensors polls Modbus registers at configurable intervals, normalizes the register map to our internal schema, and handles the byte-order and data-type quirks that vary by device manufacturer.
DNP3
The dominant protocol for electric utility SCADA in North America. DNP3's event-based model — where devices report changes rather than waiting to be polled — maps cleanly to our streaming ingestion architecture. We handle unsolicited responses, integrity polls, and time synchronization natively.
IEC 61850
The modern standard for substation automation, built around a rich object model and two distinct communication services: MMS for control and GOOSE for fast protection signaling. Our IEC 61850 connector handles both, with particular attention to the microsecond-level timing requirements of GOOSE messages.
OPC-UA
Increasingly common in newer installations and the preferred protocol for connecting SCADA systems to higher-level applications. OPC-UA's built-in security model and information architecture make it the cleanest integration path where it is available. We support both subscription-based and polling-based OPC-UA connections.
The Ingestion Architecture
The full stack from field device to operator dashboard spans five layers, each with a distinct responsibility and a defined interface to its neighbors.
Edge Connector
A lightweight process deployed within the utility's OT network, typically on a hardened industrial PC or existing data concentrator. Speaks native industrial protocols to field devices. Performs local buffering to handle network interruptions. Forwards normalized telemetry to the cloud ingestion endpoint over an encrypted, authenticated tunnel. Read-only by design — it never issues commands to field devices.
Cloud Ingestion Service
Receives normalized telemetry from edge connectors, validates schema, applies per-substation calibration offsets, and fans out to downstream consumers via an internal message bus. Designed for horizontal scalability — a single ingestion cluster handles hundreds of concurrent substation connections without configuration changes. Stateless by design; all state lives in downstream storage.
Time-Series Storage
All telemetry is written to a purpose-built time-series database optimized for high-cardinality sensor data. Schema is organized around the substation-measurement-timestamp hierarchy that utility data naturally follows. Retention policies tier data from high-resolution recent storage to compressed long-term archival, matching regulatory requirements without unbounded storage growth.
ML Anomaly Engine
Consumes the live telemetry stream and runs per-substation anomaly models in real time. Each substation has its own model, trained on that site's historical baseline, refreshed continuously as new data arrives. The engine produces a continuous anomaly score for each substation — a normalized value between 0 and 1 that represents deviation from learned normal behavior.
Alerting & Dashboard Layer
Consumes anomaly scores and raw telemetry, applies per-utility alert routing rules, and delivers notifications to operator dashboards, mobile devices, and configured integrations within 50 milliseconds of the triggering event. The geo-spatial substation map is rendered from live telemetry at this layer, giving operators a continuously updated geographic view of network health.
The Edge Deployment Question
The part of this architecture that generates the most questions from utility engineers is Layer 1 — the edge connector. Specifically: what does it run on, how is it deployed, and how does it fit within OT network security requirements?
The edge connector is a deliberately minimal process. It requires no specialized hardware — it runs on any Linux-capable industrial PC, existing data concentrator, or dedicated small-form-factor compute that the utility is comfortable operating in its OT environment. It has no inbound network listeners; it makes outbound connections only, to a fixed set of cloud endpoints over TLS 1.3 with certificate pinning.
For utilities operating strict data diode or unidirectional gateway architectures, we support a deployment variant where the edge connector writes to an intermediate buffer on the IT side of the security boundary, and a separate forwarder process — running in the IT network — handles the cloud connection. This keeps the OT-facing component entirely within the OT security boundary.
What This Means for Utility Operators
The practical implication of this architecture is that deploying HOP Sensors does not require a capital infrastructure project. The substations you operate today, speaking the protocols they already speak, become observable in real time without modification.
What changes is what you can do with the data they generate. The same telemetry that currently flows into a historian and surfaces as a static dashboard snapshot becomes a live, ML-scored, geo-spatially rendered view of your network — with alerts that fire in under 50 milliseconds when something starts to go wrong.
That is the architectural bet we made: that the right place to modernize is not the field device, not the SCADA system, but the intelligence layer that sits above them. The grid infrastructure that utilities have invested decades and billions in building is not the problem. The visibility layer on top of it is.
We built that visibility layer. Request a demo and we will walk you through how it connects to your specific environment.