I Stress-Tested The Energy Monitoring I've Been Recommending. Here's What It Misses

Lesia Yanytska is a Product Leader at Luxoft focused on digital manufacturing platforms, industrial AI and smart factory systems.

getty

​For the past few years, I've been making a fairly consistent argument in this space: that manufacturers should stop treating energy and carbon as a monthly reporting exercise and start monitoring them in real time, right inside the systems where production decisions actually get made. I still believe that. But I recently did something I'd encourage more of us who advocate for a technology to do: I tried to break it.

I built a detailed model of the exact monitoring approach I've been recommending, then ran it through thousands of fault scenarios to find out where it fails. Not where it shines in a demo, but where it lets a problem through. What the model told me was uncomfortable enough that I think it's worth sharing, because the blind spot it revealed is almost certainly sitting in monitoring systems that are running on factory floors right now.

The Reassuring Dashboard Problem

Here is the finding that matters most. The kind of real-time monitoring most factories deploy—and the kind most commercial systems ship by default—is very good at catching sudden problems and surprisingly bad at catching slow ones.

A compressed-air leak that opens up, a pump that fails, a machine left running through the night: in my scenarios, these were caught quickly, often within minutes, and the system could usually tell which part of the line was responsible. That's the satisfying part, and it's real.

The trouble is the other category. When a fault crept in gradually—such as a tool wearing down over a shift or an auxiliary system degrading by degrees—the monitoring tended to miss it entirely. The same kind of fault that got caught in minutes when it arrived suddenly went undetected when it arrived slowly. And it wasn't because the sensors were too coarse or the math too simple. It was for a more insidious reason: Most of these systems judge "normal" against a rolling recent average. A problem that arrives slowly enough gets absorbed into the definition of normal. The system learns the fault as the new baseline and stops seeing it as a fault at all.

That's the part worth considering closely. A slow degradation is exactly the kind of problem that compounds into real cost and real emissions over weeks. It's the problem you most want to catch early. And it's the one this style of monitoring is structurally built to overlook, while the dashboard stays green the entire time.

Why This Matters More Than It Sounds

It would be easy to file this under "no tool is perfect." But the specific shape of the gap is what makes it dangerous. A monitoring system that caught nothing would at least prompt healthy skepticism. A system that catches the dramatic, visible failures and silently passes on the gradual ones produces something worse than no information: false confidence. Leaders see alerts firing correctly for the obvious events and reasonably conclude the system works. The failures it can't see never announce themselves.

The Metering Trap

There's a related, more concrete problem that surprised me, and it sits upstream of everything above. The kind of coarse, utility-grade metering many plants already have—readings every 15 minutes or so—turns out to be far too slow for this style of monitoring to work at all. At that cadence, there simply isn't enough resolution for the system to distinguish a real anomaly from ordinary variation.

This is worth stating plainly to anyone evaluating a monitoring investment: If your energy data arrives that slowly, you don't have a tuning problem; you have a measurement-resolution problem. No amount of clever alerting on top of coarse data will fix it, and a vendor demo running on high-resolution data won't warn you about the gap.

A Few Honest Caveats

I want to be precise about what this is. It's a simulation—a careful one, grounded in real machine data and published engineering literature, but a model nonetheless. It characterizes how the monitoring mechanism behaves, not the real-world results at any specific plant. The natural next step is validating it against live industrial data.

What To Actually Do About It

The point of breaking your own approach isn't to abandon it. Real-time monitoring still catches a whole class of expensive, fast-moving problems that the monthly utility bill never will. The point is to stop expecting it to do a job it can't, and to pair it with methods that close the gap.

Two responses come out of this cleanly. The first is to stop measuring "normal" against a constantly sliding average and instead anchor it to known-good moments, such as a fresh tool change or a clean start after maintenance. A drift that develops slowly then accumulates against a fixed reference is more easily caught than one that disappears into a moving one.

The second is to add a complementary check that works on a different principle entirely: comparing the energy a machine actually draws against the energy its current job should require. A gradual divergence between those two shows up regardless of how slowly it develops.

Both approaches are well established, and most factories already have the production data needed to support them. The work isn't acquiring new technology; it's recognizing that the comfortable version of monitoring has a known weak spot and deliberately covering it.

The Bottom Line

If I'm going to encourage manufacturers to build real-time energy and carbon monitoring into their operations—and I am—then I owe them an honest account of where it falls short. The most widely deployed version of this monitoring is excellent at the failures you'd probably have noticed anyway and weakest at the slow, quiet ones you most need a machine to catch for you.

A green dashboard is not the same as a healthy factory. The most useful thing any monitoring system can tell you is what it cannot see. Most of them aren't telling you that. It's worth finding out for yourself.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?