For most of the last two decades, energy data lived in a different building than production data — sometimes literally. Facilities owned the utility meters, sustainability owned the carbon spreadsheet, and MES owned OEE. Three teams, three systems, three timestamps that never quite lined up. That arrangement was tolerable when electricity was cheap and nobody outside facilities cared about kWh. It’s not tolerable anymore. Industrial power costs have been climbing in most regions, demand-response and time-of-use tariffs are getting more aggressive about when you’re allowed to run heavy loads, and Scope 2 emissions reporting requirements are moving from “nice-to-have sustainability report” to something finance and legal actually sign off on. Energy has become a variable that shows up on the same P&L line as scrap and downtime, so it needs to sit in the same data model.
The good news is that you don’t need a rip-and-replace to get there. Most of the hard part isn’t hardware — it’s modeling and context. If you already have a Unified Namespace or are building toward one, energy is just another equipment-scoped data stream that’s been sitting outside the tent.
Why energy has been siloed, and why that’s no longer defensible
The historical separation wasn’t laziness — it made a certain amount of sense. Utility metering was installed and owned by facilities for billing verification and equipment protection, not for production analytics. The meters spoke Modbus RTU over a serial network that terminated in a facilities PC running vendor software nobody else had credentials for. Production data, meanwhile, lived in the PLC/SCADA/historian stack that controls engineers owned. Different owners, different protocols, different reasons for existing.
That separation breaks down the moment someone asks a question like “what did it cost us in energy to make the scrap we made on line 3 last shift.” Nobody can answer that today in most plants, because the answer requires joining a energy time series to a production time series, and those two datasets were never designed to be joined. If you’re being asked for kWh-per-good-part, cost-per-unit inclusive of energy, or facility-level Scope 2 attribution by product line, and your current answer is “we’d have to pull that manually from two systems and reconcile it in Excel,” you already know the current architecture doesn’t work.
Model energy as an OEE-adjacent metric, not a separate KPI
The single most useful mental shift is to stop treating energy as its own dashboard and start treating it as a dimension of the same equipment context you already use for OEE. In ISA-95 terms, a meter is just another piece of equipment hanging off a work center, and its readings deserve the same equipment-hierarchy addressing as a cycle counter or a reject sensor.
Concretely, that means:
- kWh-per-good-part as a computed metric alongside availability, performance, and quality — not bolted on afterward, but built from the same job/work-order context so it’s sliced by product, shift, and line the same way OEE is.
- Cost-per-unit that pulls in the actual tariff rate active during production, not a blended annual average. If you’re on a time-of-use or demand-response tariff, a part made during a peak-rate window genuinely costs more to produce than the identical part made at 2 a.m., and that’s a number operations should be able to see.
- Energy intensity during non-productive states — idle draw, changeover draw, startup draw. This is often the most actionable number in the whole exercise, because it’s frequently invisible today. A press that draws close to full load while sitting idle between jobs is a maintenance and scheduling conversation, not just a sustainability footnote.
None of this requires a new KPI framework. It requires attaching energy tags to the same equipment nodes and job context you already use for downtime and quality, so the numbers can be joined without a data engineering project every time someone asks a question.
Where to actually place the tags
Meter placement is where most energy-integration efforts either succeed or quietly fail. Whole-facility metering at the utility entrance is what you need for the utility bill and for a corporate carbon report, but it’s nearly useless for tying energy to production events — too much aggregation, too many loads mixed together, no way to isolate a line or a work center.
For MES-relevant energy data, you want submetering at the work-center or line level at minimum, and ideally at the equipment level for anything energy-intensive: compressors, ovens, chillers, induction heating, large motors. Many plants already have some of this in place for power-quality or preventive-maintenance reasons and just haven’t connected it to anything beyond a local trend screen. Check what you already own before you buy anything new — a decent fraction of “we need energy monitoring” projects turn out to be “we need to connect the metering we already installed.”
For protocol, modern submeters and power monitors increasingly support Modbus TCP or native OPC UA, which makes them straightforward to bring into an MQTT/Sparkplug B-based UNS through the same edge gateway pattern you’d use for any other Modbus device — poll the register map, map it to a UNS topic under the relevant equipment node, publish on report-by-exception or a defined scan rate. If you’re stuck with older serial meters, a Modbus RTU-to-TCP gateway is a small, well-understood piece of hardware, not a project.
Getting the time granularity right
This is the part people get wrong most often. Utility billing data is typically interval data — 15-minute or hourly averages, because that’s what tariffs are billed on. Production events — a part completing, a fault occurring, a changeover starting — happen on the order of seconds. If you try to join 15-minute energy intervals directly to second-level production events, you get misleading correlations: a demand spike gets attributed to whatever job happened to be running at some point during that 15-minute window, even if the actual spike came from an unrelated compressor cycling on.
The fix isn’t to force everything to one granularity — it’s to carry both and let the analytics layer align them deliberately. Keep the native interval data for billing and tariff reconciliation. For OEE-adjacent analysis, aggregate production events up to matching windows, or better, capture instantaneous power draw at a higher resolution where the meter supports it (many modern power monitors can report kW at a few seconds’ resolution even though billing data is quarter-hourly) and align that against job start/stop timestamps. The point is to be honest about resolution mismatch rather than paper over it with a chart that implies more precision than the data supports.
The mistake to avoid: another silo, just prettier
The failure mode showing up now isn’t “we ignored energy data” — it’s “we bought an energy dashboard.” Plenty of energy-monitoring platforms will happily ingest your meter data, apply nice visualizations, calculate carbon intensity, and generate a sustainability report. That’s genuinely useful for the sustainability team’s deadline. It does nothing for the plant floor if it lives in its own application with its own login and no connection to the downtime and quality data already in your historian or MES.
If energy data isn’t addressable in the same namespace as production data — same equipment hierarchy, same time-series backbone, joinable without an export-and-reconcile step — you’ve just built a second silo with better charts. The whole point of pulling energy into the UNS is that a controls engineer troubleshooting an availability problem and a sustainability analyst building a Scope 2 report should be querying variations of the same underlying data, not two disconnected systems that happen to describe the same plant.
Where to start if you’re not there yet
You don’t need every meter on day one. Start with the equipment where energy cost or intensity is both significant and variable — compressors, thermal processes, anything with meaningful idle draw — and get that submetered and published into the UNS under the correct equipment node. Build kWh-per-good-part for that one line before you try to do it plant-wide. Once the model works for one work center, extending it is mostly repetition, not redesign.
The plants getting real value out of this aren’t the ones with the most elaborate energy dashboards. They’re the ones where an operations review can pull up a line’s OEE and its energy cost per unit on the same screen, from the same query, without anyone having to go ask facilities for a spreadsheet.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
