A Note on This Case Study
HOP Sensors is pre-revenue and actively seeking its first utility partnerships. This case study is a composite — built from detailed conversations with utility operations professionals, public post-incident reports, and the operational realities that engineers at regional utilities have described to us. It is not drawn from a single real deployment. It is drawn from the pattern we see repeatedly when we talk to the people who operate the grid.
We present it not as a claim of past success, but as an honest depiction of the problem we are solving and the outcome we are building toward.
The Situation: A Regional Utility With 38 Substations
Picture a regional electric cooperative serving a mixed residential and agricultural territory across three counties. Thirty-eight substations, roughly half of them built before 1990. A mix of Modbus RTU devices in the older substations and DNP3 in the newer ones. An OSIsoft PI historian that the operations team has used for years — good at storing data, not built for real-time intelligence.
The operations center runs 24/7 with a control room that looks the way utility control rooms have looked for decades: a wall of fixed-function displays showing a handful of key system metrics, a SCADA console that requires navigating through substation by substation to review any specific site, and an alarm system that generates hundreds of low-priority alerts on a normal day — enough that operators have learned, over years, which alarms to treat as signal and which to treat as noise.
The team is experienced, competent, and stretched thin. They know their network intimately. They know which substations run hot, which feeders are temperamental, which equipment is aging. That institutional knowledge is irreplaceable — and it is also the only anomaly detection system the utility has, because the alternatives have not been built.
What the Blind Spots Look Like
The blind spots in this environment are not obvious failures. The SCADA system works. The historian records data. The alarms fire when they are supposed to fire. The problem is subtler: there are things happening in the network that the existing systems cannot see, and some of those things matter.
A substation fifteen miles from the control center has been running slightly warmer than its historical norm for the past three weeks. Not warm enough to trigger a threshold alarm — but warm enough that if you could compare its current behavior to its behavior at the same time of year over the past three years, you would see a consistent drift upward. The transformer is developing a problem. Nobody knows, because nobody has a tool that makes that comparison automatically.
Two substations on the same feeder occasionally show correlated current deviations at the same time of day. The pattern has been present in the historian data for months. It suggests a developing issue somewhere between them. Nobody has found it, because querying the historian across multiple substations simultaneously requires writing custom reports — and the operations team does not have time to write custom reports.
These are the blind spots. Not catastrophic failures. Slow-developing conditions that, left undetected, eventually become the kind of event that appears in a post-incident report with the phrase: "anomalous readings were present in the data in the weeks prior to the event."
What Modernization Looks Like Without Infrastructure Replacement
The modernization path for this utility does not start with a capital project. It does not require replacing substations, ripping out SCADA systems, or migrating away from the historian that the operations team has built years of workflow around. It starts with connecting the data that already exists to an intelligence layer that can do something useful with it.
Edge Connector Deployment
A lightweight edge connector process is deployed on existing hardware in the operations network — in this case, a hardened industrial PC that already sits in the control room environment. It speaks Modbus RTU to the older substations and DNP3 to the newer ones, connecting to existing SCADA data streams as a read-only observer. No changes to the SCADA configuration. No disruption to normal operations. The connector begins forwarding normalized telemetry to the cloud ingestion layer over an encrypted, authenticated tunnel.
Baseline Accumulation
The platform ingests telemetry in observation mode, building per-substation baseline models across all 38 sites. No alerts are generated during this period — the system is learning what normal looks like for each substation, at each time of day, across a full month of operational data. By the end of six weeks, each substation has a calibrated baseline model and an anomaly score threshold tuned to that site's specific noise characteristics.
Live Anomaly Scoring and Alerting
Anomaly scoring activates. Operators gain access to the geo-spatial dashboard — a live map of all 38 substations, color-coded by current anomaly score, refreshed every five seconds. The experience of monitoring the network changes: instead of navigating substation by substation through a SCADA console, operators see the entire network at once, with deviations surfaced automatically rather than requiring active investigation to find.
What Changes When You Can See the Whole Network
The operational changes that follow from real-time network visibility are not always the ones that utilities expect when they start the conversation.
The expected change is faster incident response — alerts arrive in under 50 milliseconds, operators have more warning before a trip, they can take preventive action rather than reactive action. That change is real and measurable.
The less expected change is what happens to the slow-developing conditions that were previously invisible. With continuous anomaly scoring against a learned baseline, the transformer that has been drifting warm for three weeks shows up as a consistently elevated anomaly score weeks before it would have triggered a threshold alarm. The correlated deviations between the two substations on the same feeder are flagged as a multi-site pattern. The blind spots, which were previously invisible by definition, become visible.
The Honest Limits
A case study that does not acknowledge limits is not a case study — it is a brochure. There are things HOP Sensors does not change about a utility's operational environment.
It does not replace operator judgment. When an anomaly alert fires, a human operator still needs to evaluate it, understand what it means in the context of the specific substation and the current operating conditions, and decide what action to take. The platform surfaces the signal; the experienced operators interpret it.
It does not eliminate the cold start period. A newly connected substation takes 44 days to reach full calibration. During that time, detection sensitivity is lower than in a fully calibrated deployment. Utilities with urgent visibility needs should plan the deployment timeline accordingly.
And it does not replace physical inspections or predictive maintenance programs. An elevated anomaly score on a transformer is a flag that warrants investigation — not a diagnosis. The investigation still requires a field crew and a qualified engineer.
What it does is give your operations team the information they need to direct that investigation before the transformer fails, rather than after.
Is This Your Situation?
If you operate a regional electric utility with aging SCADA infrastructure, a historian full of data that nobody has the tools to analyze in real time, and an operations team that is very good at responding to incidents but has limited visibility into what is developing before an incident occurs — this is the problem we built HOP Sensors to solve.
We are looking for utility partners who want to be part of building the solution. Early partners get direct input on the roadmap, priority access to new features, and early-adopter pricing. We are not asking you to take a risk on an unproven platform — we are asking you to help us prove it, with your operational environment, your requirements, and your feedback.
Get in touch and we will set up a conversation with no sales pressure — just an honest discussion about whether what we have built is relevant to what you are trying to solve.