How to Add Asset Condition to an Industrial Energy Review

A compressed air system gets flagged in the annual energy review for rising specific power. Production volume is flat, the dryer setpoints have not changed, and the report closes the finding as an operator behavior issue with a recommendation to "reinforce shutdown discipline on weekends." Three months later the same unit trips on high motor temperature and a technician finds a failing coupling and a dry bearing. The energy variance was mechanical the whole time.

Adding asset condition to an industrial energy review means treating condition data as a relevant variable rather than a separate workstream. In practice: for every significant energy variance you identify, pull the vibration, temperature, motor current, and lubricant evidence for the same time window, check maintenance history and operating context, and only then assign a cause. The deliverable of this article is an auditable four-step investigation workflow plus the data layers it depends on.

Set the scope honestly. This workflow does not promise a savings percentage. What it produces is better diagnosis and findings that survive technical review, which is usually the thing blocking an energy report from turning into funded work. Building the financial case for that work is a separate exercise, and our guide to predictive maintenance ROI walks through the cost categories, payback, and sensitivity analysis from your own baseline.

The Energy Finding That Was Actually a Bearing

Take the compressed air scenario apart. The energy analyst did nothing wrong by the normal rules of the exercise. The meter showed kWh per hundred cubic feet climbing over nine months. Production counts were stable. Ambient temperature was normalized. Nothing in the available dataset explained the drift, so the finding defaulted to the explanation that always fits a slow drift with no other cause: human behavior.

The reliability team held the missing evidence the entire time. The quarterly vibration route on that compressor showed a rising overall velocity trend with a developing peak at the coupling frequency. Nobody cross-referenced it, because the vibration route lives in the condition monitoring record and the energy review lives in a spreadsheet owned by a different department.

This is the structural failure. Energy reviews read meters and production counts. They rarely open the condition monitoring record, the work order history, or the lubricant analysis file. When a mechanical fault increases input power without changing output, the review has no vocabulary for it, so the variance gets attributed to whatever soft cause is nearest at hand.

The cost of that mistake is not only the wasted energy. It is a reliability event that arrived unplanned, a correct signal that went unused, and an energy report that technical reviewers learn to distrust.

What an Energy Review Normally Sees, and What It Misses

An energy review in the ISO 50001 sense asks two questions: where does energy actually go, and which variables drive consumption at each of those uses. The standard inputs are well established and most teams collect them competently.

• Utility and submeter data, including interval kWh, demand peaks, gas and steam flows
• Production output, by line, product, and shift
• Ambient conditions, usually dry bulb temperature and humidity
• Setpoints and schedules, pulled from SCADA screens or operator logs
• Known events, such as shutdowns, trials, and commissioning periods

The blind spots are equally consistent. Bearing degradation, misalignment, worn impellers, fouled heat exchangers, belt slip, valve bypass, failed steam traps, plugged filters, and refrigerant charge loss all raise energy input without touching any variable the energy review tracks. A fouled intercooler on a two-stage compressor will not appear in a production count. It appears in discharge temperature and in kW.

The gap is organizational before it is technical. The energy team owns meters and utility bills. The reliability team owns vibration routes, oil sample results, thermography, and the CMMS. Those two datasets rarely sit in the same review meeting, and when they do, nobody has defined how a condition signal gets weighed against a load explanation.

The reframe is simple and worth saying out loud in your next review: asset condition is a relevant variable. If you are normalizing for production rate and ambient temperature but not for mechanical degradation, your baseline model is carrying an unexamined assumption that the equipment is as healthy as it was on day one.

The Five Data Layers You Need Before You Draw a Conclusion

Before anyone writes a cause into a finding, five layers of evidence should be on the table. Missing layers are not a reason to stop; they are a reason to label the finding as evidence-limited.

Layer 1, utility and submeter data. Interval kWh, demand, gas and steam flows. Document the meter boundary explicitly. Half the arguments in energy reviews come from a meter that covers more equipment than people assume, or a submeter that was swapped and never rescaled.

Layer 2, operating load and process context. Production rate, throughput, product mix, setpoint changes, recirculation, batch versus continuous operation. This comes from the historian or SCADA layer: AVEVA PI System, Ignition, or whatever sits above your PLCs. Treat the data path and its security boundaries deliberately rather than pulling ad hoc exports from control networks ^[4].

Layer 3, condition signals. Vibration overall levels and spectra, bearing and motor winding temperature, lubricant analysis, motor current signature, and ultrasound for air leaks and steam traps. Modern condition monitoring stacks combine threshold rules with machine learning on vibration and temperature to flag abnormal machine states ^[7], and sensor platforms are built around exactly these two measurements plus an alert and technician feedback loop ^[1].

Layer 4, maintenance history. Work orders, failure codes, parts replaced, PM compliance, and any recent repair that changed machine behavior. A pump rebuilt eight months ago is a different machine than the one in your baseline window. Structured O&M program practice treats this history as a planning input, not an archive ^[5].

Layer 5, human knowledge. Operator rounds, technician notes, and the workarounds nobody documented. If an operator has been throttling a discharge valve to stop a pump from cavitating, that is both an energy finding and a reliability finding, and it will only ever appear in conversation.

The common failure across all five layers is the same: the data exists but is not timestamped to a shared window. Align everything to the same calendar before you compare anything.

A Four-Step Investigation Workflow You Can Audit Later

The point of a defined sequence is that someone can re-audit the finding a year later and follow the reasoning. Each step needs an owner, an evidence reference, a date, and a recorded decision.

Step 1: Establish the baseline and name the variables

Define the energy baseline model, the relevant variables, the normalization method, the data window, and any excluded periods. Write down why each exclusion was made. Measurement discipline matters more than model sophistication here, which is the recurring lesson in production measurement practice: get the metrics and their definitions right before you get clever ^[6]. Owner: energy engineer. Closure criteria: documented model with stated variables and exclusions.

Step 2: Isolate the variance

Identify when specific energy consumption diverged and classify the shape of the divergence. A step change usually points to metering, control, or a discrete event. A slow drift points toward fouling, wear, or leak growth. A load-correlated pattern points toward process and control. Owner: energy engineer. Closure criteria: dated variance window with a classified pattern.

Step 3: Test competing hypotheses in order

Work cheapest and most likely first: metering error, then process or load change, then control or setpoint change, then asset condition. Skipping to the mechanical hypothesis is how teams end up writing work orders against healthy machines. Owner: joint energy and reliability review. Closure criteria: each hypothesis marked supported, rejected, or untestable, with evidence cited.

Step 4: Confirm mechanically

Pull condition signals for the same variance window and look for a coincident trend inflection, then verify physically. A condition monitoring workflow exists precisely for this: readings produce an alert, someone investigates, corrective action follows, and the technician records what was actually found ^[3]. That recorded resolution is what makes the next investigation faster ^[8]. Owner: reliability engineer. Closure criteria: physical inspection or test result attached to the finding.

Matching Energy Symptoms to Likely Failure Modes

Energy symptoms are ambiguous by design. One symptom usually maps to several failure modes, so the workflow has to converge evidence rather than accept the first plausible cause. Use the table below as a hypothesis generator, not an answer key.

Two notes on using this. First, the confirming signal column is where most plants discover they do not have the measurement, which is useful information for a sensor plan. Second, if you want depth on the rotating equipment rows, the mechanics of trend interpretation are covered in our vibration analysis guide for rotating equipment.

Turning a Confirmed Finding Into Scoped Work

An energy report recommendation is not a work order. No planner can schedule "investigate compressor efficiency." That sentence has no craft, no duration, no parts, no access window, and no definition of done, so it sits in the backlog as a note until the next audit rediscovers it.

A condition-driven energy finding becomes schedulable when it carries the same fields as any other planned job:

• Asset ID and location, matching the CMMS hierarchy exactly, not a plain-language description
• Suspected failure mode, stated in FMEA language such as coupling wear or intercooler fouling
• Evidence summary with references, the variance window, the condition trend, and the inspection result
• Required craft and estimated hours, so the planner can slot it against capacity
• Parts and lead times, checked against stock before scheduling
• Access window, tied to production schedule or planned shutdown
• Verification test, the specific readings required to close the job

Here is what that looks like in practice as a work order body:

`Asset: CAC-02 rotary screw compressor, Utilities / Unit 3` `Suspected mode: intercooler fouling, secondary check on inlet filter dP` `Evidence: specific power +drift Mar to Nov (energy review EV-24-07); interstage discharge temp trend rising; vibration route stable` `Craft: mechanical, 6 h, 2 techs. Parts: gasket kit, inlet element` `Access: Sunday utilities window` `Close-out requires: interstage temp before/after, kW at 100 psi load point before/after, photo of cooler core`

That last line is the one most teams skip. Without a verification reading, you never learn whether the diagnosis was right, and the next energy review starts from zero. This is also where tooling earns its place: an asset monitoring layer that carries the condition trend and the evidence package into the CMMS through CMMS integration keeps the finding attached to the asset record in SAP PM, Maximo, or Fiix instead of in a consultant's deck.

Frequently asked questions

Do we need new sensors to add condition data to an energy review?

Usually not for the first pass. Start with the vibration routes you already walk, motor current from the drives, operator round sheets, thermography images, and the submeters you already read monthly. Build the sensor business case from the gaps the first review exposes, which is a cleaner justification than a blanket deployment. Our condition monitoring guide covers which parameters to track for different asset types and how to set alert thresholds, which is the decision you face once the first review shows you where the measurement gaps are.

How do we handle assets with no condition data?

Mark them as evidence-limited and say so in the report. A finding that admits its evidence boundary is more credible than one that assigns a confident cause from a single meter. Evidence-limited assets also become your ranked list for instrumentation.

Who owns the finding when the cause is mechanical?

Split it cleanly. The reliability team owns the repair scope and execution. The energy team owns the verification measurement. Both sign the closure. Condition monitoring platforms formalize this by capturing what the technician actually found and resolved against the original alert ^[8], and the same principle applies whether your record lives in a sensor platform or a work order comment field.

What if production load explains the whole energy variance?

Record it and close the finding as explained. A well-documented null result is valuable, because it stops the same variance from being re-litigated in next year's review.

How often should a combined energy and condition review run?

Tie it to the energy review cycle you already have and to asset criticality ranking. Critical assets with high energy intensity get reviewed every cycle. Everything else gets a condition cross-check when a variance appears. Do not invent a new recurring meeting; attach the step to an existing one.

Does this workflow change if we use machine learning to flag anomalies?

The workflow holds, but you take on model governance. Condition monitoring systems that blend threshold logic with learned baselines still need measurement, management, and governance of their own risk ^[2], and anomaly flags still need the same hypothesis ordering before anyone writes a work order.

Start With One Significant Energy Use This Week

Pick the single asset with the largest unexplained energy variance in your last review. Pull its last twelve months of work orders alongside its condition trends for the same window and look for a coincident inflection. For one asset, this takes about half an hour, and it is the fastest way to find out whether your review process has been missing mechanical causes.

Then make two permanent changes to your energy review template. Add a field for condition evidence reviewed, with the trend reference. Add a yes or no field for evidence-limited. Those two fields change the conversation in the review meeting because an empty condition field becomes visible instead of invisible.

Start tracking one number this quarter: the percentage of energy review findings that close with a verified condition or mechanical root cause. If the answer is zero, your review is not reading the equipment. For a broader view of how condition signals connect to energy and emissions outcomes, see our work on predictive maintenance and sustainability.

Go back to the compressor from the opening. The coupling would have been found in the energy review if anyone had opened the vibration route for the same nine-month window the meter was flagging. The evidence existed. The workflow did not.

Hold the line on this standard: a finding without a named owner, an evidence reference, and a closure test is a note, not a result.

References

[1] AWS, "What is Amazon Monitron? - Amazon Monitron", AWS documentation. https://docs.aws.amazon.com/Monitron/latest/user-guide/what-is-monitron.html

[2] NIST, "AI Risk Management Framework | NIST", 2023. https://www.nist.gov/itl/ai-risk-management-framework

[3] AWS, "The Amazon Monitron workflow - Amazon Monitron", AWS documentation. https://docs.aws.amazon.com/Monitron/latest/user-guide/deployed-workflow.html

[4] NIST, "Guide to Operational Technology (OT) Security | CSRC", 2023. https://csrc.nist.gov/pubs/sp/800/82/r3/final

[5] U.S. Department of Energy, "Operations and Maintenance in Federal Facilities | Department of Energy", DOE guidance. https://www.energy.gov/cmei/femp/operations-and-maintenance-federal-facilities

[6] Google, "Rules of Machine Learning: | Google for Developers", Google developer guidance. https://developers.google.com/machine-learning/guides/rules-of-ml?hl=en

[7] AWS, "How Amazon Monitron works - Amazon Monitron", AWS documentation. https://docs.aws.amazon.com/Monitron/latest/user-guide/how-monitron-works.html

[8] AWS, "Understanding sensor measurements and monitoring machine abnormalities - Amazon Monitron", AWS documentation. https://docs.aws.amazon.com/Monitron/latest/user-guide/anom-monitoring-chapter.html