Why Alert Latency Is an Operational Variable, Not a Technical Footnote
In grid operations, the relationship between detection latency and incident severity is not linear — it is exponential. A fault that is detected and acted on within five seconds of onset presents a fundamentally different response scenario than one detected thirty seconds later. The physics of grid propagation mean that cascades that could have been contained become irreversible as each second passes.
This is why the HOP Sensors latency target — under 50 milliseconds from sensor reading to operator notification — is not a marketing number. It is an operational specification derived from the response time windows that make a difference in real grid incidents. This document presents the methodology and results behind that specification.
Test Methodology
Test Environment
- Simulated Modbus and DNP3 data sources generating telemetry at 5-second intervals per measurement point
- Edge connector deployed on an Intel NUC (comparable to industrial field hardware) connected via 100Mbps LAN to the cloud ingestion endpoint
- Cloud ingestion service running on a single-region deployment with no CDN acceleration
- Latency measured as wall-clock time from sensor reading timestamp to dashboard event render
- Each scenario run for 72 hours; figures represent p50, p95, and p99 percentiles
- Stress tests inject synthetic measurement bursts at 10× normal rate to simulate simultaneous multi-site anomaly events
All measurements use monotonic clock sources on both the edge and cloud sides, synchronized via NTP with a maximum observed drift of 2ms over the 72-hour test window. Latency figures include the full pipeline: protocol read → edge normalization → encrypted tunnel → cloud ingestion → anomaly scoring → alert routing → dashboard render.
Baseline Results: Normal Operating Conditions
The following results represent normal operating conditions — steady-state telemetry ingestion with no anomaly events in progress.
| Deployment Scale | Substations | Measurements/sec | p50 Latency | p95 Latency | p99 Latency |
|---|---|---|---|---|---|
| Small | 3 | ~180 | 11ms | 18ms | 24ms |
| Medium | 10 | ~600 | 14ms | 22ms | 31ms |
| Large | 50 | ~3,000 | 19ms | 34ms | 47ms |
Across all three scales under normal conditions, end-to-end latency remains well within the 50ms target. The increase from 3-substation to 50-substation deployments is primarily attributable to anomaly scoring time — the ML engine processes more substation models per cycle as the deployment grows. The ingestion and transport layers contribute less than 8ms of the total latency budget at all scales tested.
Stress Test Results: Simultaneous Multi-Site Events
The more operationally relevant test scenario is simultaneous anomaly events across multiple substations — exactly the condition that precedes a cascade failure. When multiple substations enter anomalous states simultaneously, the platform must process and route multiple high-priority alerts without degrading latency for any of them.
The most demanding scenario tested — 50 substations, 10 simultaneous anomaly events, with a 10× telemetry burst injected to simulate sensor flooding — produced a p95 latency of 44ms, still within the 50ms target. The p99 for this scenario was 61ms, representing the tail latency under extreme simultaneous stress.
The critical observation from stress testing is that latency degrades gracefully. There is no cliff — no point at which the system falls over and alert delivery becomes unreliable. Latency increases proportionally with load, reaches a ceiling, and recovers as burst conditions subside.
Latency Budget Breakdown
Understanding where time is spent in the pipeline is as important as the aggregate figure. The following breakdown represents the 50-substation, normal-conditions scenario.
| Pipeline Stage | p50 Time | Notes |
|---|---|---|
| Protocol read + edge normalization | 3ms | Includes Modbus/DNP3 frame parsing and schema mapping |
| Encrypted tunnel transport | 5ms | TLS 1.3, measured to US-West cloud region |
| Cloud ingestion + validation | 2ms | Schema validation, calibration offset application |
| Time-series write | 1ms | Async write; does not block alert path |
| ML anomaly scoring | 6ms | Per-substation Z-score computation against running baseline |
| Alert routing + notification | 2ms | Rule evaluation and delivery to dashboard websocket |
| Total end-to-end | 19ms | p50, 50-substation deployment, normal conditions |
Storage and Throughput Characteristics
Beyond latency, utility deployments require confidence in the platform's data durability and throughput characteristics. The following figures are from the same 72-hour test runs.
| Metric | 3 Substations | 10 Substations | 50 Substations |
|---|---|---|---|
| Measurements stored / day | ~1.6M | ~5.2M | ~26M |
| Raw storage / day (uncompressed) | ~380 MB | ~1.2 GB | ~6.1 GB |
| Compressed storage / day | ~28 MB | ~89 MB | ~445 MB |
| Zero-drop ingestion rate | 100% across all test runs | ||
Time-series compression ratios for SCADA telemetry are favorable — sensor readings over steady-state operating periods compress at approximately 14:1, significantly reducing long-term storage requirements relative to raw data volumes.
Conclusions and Deployment Guidance
The benchmark results support three operational conclusions for utility deployments.
The 50ms alert latency target is achievable and maintained under stress. Even under the most demanding conditions tested — 50 simultaneous substations with a 10× telemetry burst — p95 latency remains within the target. Utilities can plan operational workflows around sub-50ms notification delivery with high confidence.
Latency scales predictably with deployment size. There is no architecture discontinuity between small and large deployments. A utility that starts with 10 substations and grows to 50 will see latency increase by approximately 20ms at p50 — not by an order of magnitude. This predictability matters for operational planning.
Storage overhead is manageable. A 50-substation deployment at 5-second telemetry resolution generates approximately 445 MB of compressed data per day. A year of history for that deployment requires roughly 160 GB of compressed storage — well within the range of cost-effective cloud storage, and compatible with multi-year regulatory retention requirements.
These benchmarks represent the current state of the platform. We publish updates as the architecture evolves. If you have specific performance requirements for your deployment scenario, contact us and we will model your environment directly.