Every MES rollout of the last decade modeled the same things: work orders, routings, equipment states, quality holds, OEE. Nobody modeled kilowatt-hours. Compressed air flow got a gauge on the wall, not a tag in the historian. Now CSRD phase-in and customer sustainability scorecards are asking plants to report energy and emissions at the same granularity as production data — by line, by shift, sometimes by batch — and manufacturing teams are discovering their equipment hierarchy has nowhere to put it.
This is not a reporting problem. It’s a data architecture problem, and it’s landing on the desks of MES administrators and controls engineers who didn’t sign up to be carbon accountants. The good news: if you already have a reasonably disciplined ISA-95 equipment hierarchy and a unified namespace, you don’t need to rebuild anything. You need to extend it. The bad news: most teams are about to do the opposite — bolt on a standalone sustainability platform that talks to nobody, and spend years trying to reconcile it with the real production record.
Why energy data never made it into the hierarchy in the first place
MES equipment models get built around what drives OEE and genealogy: work centers, resources, operations. Energy was somebody else’s problem — usually facilities or EHS, running on utility billing data and annual spreadsheets. That data lived at the meter-room level, aggregated monthly, disconnected from any specific work order. It was accurate enough for a utility bill and useless for anything else.
The metering that does exist in most plants is also lopsided. You’ll find revenue-grade meters at the utility entrance and maybe at a few high-draw processes — furnaces, compressors, large motors — because those were justified by demand-charge management or energy-efficiency rebates, not by any intent to attribute consumption to a specific product or batch. Compressed air is usually the worst-instrumented utility in the building despite often being among the most expensive per unit of useful work delivered. Submetering stops well short of the line or cell level almost everywhere.
So when a customer scorecard or a CSRD disclosure requirement asks for product carbon footprint or energy intensity per unit produced, the honest answer at most mid-market plants is: we don’t actually have that data at that resolution. What follows is either a rough allocation based on run hours and nameplate ratings — defensible for an internal estimate, shaky under third-party assurance — or a scramble to add metering.
Treat energy and carbon as a tag set, not a separate system
The instinct to stand up a dedicated “sustainability platform” is understandable and, in my view, usually a mistake for mid-market operations. It creates a second source of truth that has to be manually reconciled against production volumes, shift calendars, and downtime records that already live in the MES. Every reconciliation cycle becomes an argument about whose numbers are right. And because the sustainability tool was never wired into the equipment hierarchy, nobody can actually drill from “this batch has a high carbon intensity” down to “this compressor ran unloaded for six hours on second shift.”
The better move is to model energy and emissions as another tag set hanging off the same equipment nodes you already use for OEE — the same ISA-95 area/line/cell/equipment structure, published through the same unified namespace using MQTT Sparkplug B or OPC UA, landing in the same historian. A kWh reading from a line-level submeter is not conceptually different from a cycle-count tag or a temperature setpoint. It has a source, a timestamp, a quality code, and an equipment context. Treat it that way and it inherits everything you’ve already built for contextualization, alarming, and long-term storage.
Where to actually put meters
You don’t need to instrument everything at once, and you shouldn’t try to. Prioritize by where allocation is currently weakest and where the reporting requirement actually bites:
- Line-level electrical submeters ahead of the work centers that drive your highest-volume or highest-margin products — these are what let you attribute energy to work orders instead of guessing from run time.
- Compressed air flow metering at the branch level feeding major consumers, not just at the compressor house. Air is fungible across the plant, which makes it the easiest utility to misattribute and the hardest to defend under audit.
- Thermal metering — steam, hot water, natural gas — on any process where heat is a major cost and emissions driver, particularly combustion equipment that CSRD’s Scope 1 disclosure will ask about directly.
- Existing utility meters you already have but never connected to anything besides a monthly bill. A surprising amount of “new” metering is really just an unused Modbus or pulse output on equipment that’s already installed.
Where submetering isn’t yet justified, model an allocation node in the hierarchy anyway — even a calculated tag that apportions a higher-level meter reading by run-hours or by production count. It’s not as good as a direct measurement, but it puts a placeholder in the right architectural spot, which matters more than people expect when you eventually add the real meter and don’t want to rebuild the mapping logic.
Mapping utility data to work orders without rebuilding the historian
The genealogy problem is the real work here, and it’s where teams either get this right or end up with numbers nobody trusts. You already have the mechanism: MES equipment states and work order execution records carry start/stop timestamps and equipment associations. Energy and emissions tags need the same time-series alignment.
Concretely, that means: publish energy tags at the equipment node that corresponds to the work center in your routing, at a scan rate fine enough to resolve product changeovers (this is usually a matter of a few minutes, not milliseconds — you’re not doing SCADA control here). Then let your MES or MOM layer do what it already does for OEE — join equipment-state intervals to work order execution — and extend that join to sum or integrate the energy tag over the same interval. If your UNS is structured properly with consistent equipment paths, this is a modeling exercise, not a new integration project. If it’s not structured properly, that’s the actual problem to fix, and it was always going to bite you eventually regardless of sustainability reporting.
Avoid the temptation to solve this with a nightly batch export to a spreadsheet or BI tool that “does the math offline.” It works for a pilot. It does not survive an audit trail requirement, and CSRD assurance is explicitly pushing toward auditable, traceable calculation methods rather than year-end estimates.
What this means for 2026 planning
If energy and carbon tags aren’t in your capital and IT planning conversations yet, they’re about to be, driven by disclosure deadlines and by customers pushing scorecard requirements down their supply chains regardless of whether a given plant is directly in scope for CSRD. The plants that handle this well won’t be the ones that buy the flashiest carbon-accounting software. They’ll be the ones that already have a clean equipment hierarchy and unified namespace, and treat this as an extension of infrastructure they understand — not a new discipline bolted on beside it.
The plants that struggle will be the ones that let sustainability reporting get owned entirely by EHS or a compliance vendor, built on its own data model, with its own definition of “line” and “shift” that doesn’t match what’s in the MES. That gap doesn’t show up in year one. It shows up when an auditor or a customer asks why the numbers from two systems don’t agree, and nobody in the building can explain the discrepancy because the two systems never shared a namespace to begin with.
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.
