← Engineering Examples

Condition Monitoring · Engineering example

Pump Health Monitoring

See changes in pump performance while there is still time to investigate. Connect equipment signals and maintenance findings so every alert has context and every intervention teaches the operation something.

A cutaway industrial pump with vibration, temperature, current, flow, and pressure monitoring connected to a diagnostic review

The operating challenge

A pump can be running and still be failing the process.

A running indicator confirms that a motor is on. It does not tell a team whether the pump is delivering the flow the process needs, whether its condition is changing, or whether the same problem keeps returning after maintenance. Those answers are often scattered across operator observations, controller screens, service notes, and utility records.

Performance changes quietly

Flow falls or the pump needs more energy for comparable duty. The issue is noticed when production, cooling, water delivery, or another dependent service is affected.

Alarms lack context

A vibration or temperature alert arrives without the operating mode, related measurements, or recent service history needed to decide what it means.

Findings do not close the loop

A technician corrects a condition, but the inspection result never returns to the monitoring record. The next alert cannot benefit from what the team learned.

Why modernize: Give operators and maintenance staff a trustworthy view of change, a better handoff, and a record of what actually happened. The goal is not to replace their judgment with a health score.

Illustrative operating example

A cooling-water pump begins to lose performance.

The asset and events below are illustrative. They are not a claim about a completed customer installation or a diagnosed failure.

Imagine pump P-204 supplying a cooling-water loop. It still starts and runs, so a simple status dashboard shows green. Over time, the delivered flow is lower at a comparable speed and operating condition. A vibration trend has also changed. Neither observation alone proves that the pump is failing: a valve position, strainer condition, process demand, sensor problem, or mechanical issue could explain part of the picture.

  1. Establish comparable operation.Identify P-204, its motor, duty, speed, running state, and recent maintenance. Compare like operating conditions rather than every reading against one fixed number.
  2. Validate the evidence.Check that flow, pressure, vibration, and relevant electrical measurements are fresh, plausible, correctly associated with the asset, and not affected by a known sensor or network fault.
  3. Recognize a sustained change.An explainable rule compares the current condition with the approved baseline. A persistent departure, supported by more than one trustworthy signal, becomes a review request rather than an automatic diagnosis.
  4. Hand off a useful record.The operator or maintenance reviewer sees the trend, operating state, corroborating and conflicting evidence, and recent work. The responsible team decides whether to inspect and when.
  5. Record the outcome.The inspection finding, action, and post-work measurements return to the asset history. If the issue was a sensor or process change, that result is just as important as a mechanical repair.

What the reviewer would see

P-204: condition review requested

Cooling-water service. No shutdown or equipment command has been issued by the monitoring layer.

Evidence
Lower delivered flow under comparable operation, with a sustained change in vibration trend.
Data checks
Asset identity, timestamps, range, freshness, and operating mode checked. Any failed check would make the conclusion uncertain.
Finding
Unknown until an authorized person investigates. Possible hydraulic, process, instrumentation, and mechanical causes remain open.
Next step
Review the evidence and decide whether an inspection or maintenance request is appropriate.

Other high-priority situations

The same approach answers different operating questions.

Is the standby pump really ready?

A critical standby unit may look available because its last status was healthy. A proof-test record can connect the test request, actual start, pressure or flow response, elapsed time, and any exception. Fixed rules can flag missing or unsuccessful evidence. AI can help summarize recurring exceptions for review, but it does not substitute for a qualified test or authorize a start.

Useful report: last verified test, incomplete tests, exceptions, and owner of the next action.

Why is pumping using more energy?

When installed power measurement, flow, pressure, speed, and operating context are available, a team can compare energy per useful delivered volume at comparable duty. A worsening trend suggests a system investigation, not a diagnosis. The cause could involve a strainer, valve, operating point, pump condition, or measurement error. A human team evaluates any physical or control change.

Useful report: comparable operating periods, change in energy intensity, inspection finding, and verified post-change performance.

What a modernization would connect

Build around the existing equipment and the decision it must support.

The first design question is not which model to buy. It is which condition matters, what trustworthy evidence is available, and which existing system owns the resulting decision. A monitoring retrofit can begin read-only while the qualified local controller keeps its present authority.

Required operating evidence

  • Stable pump, motor, location, and service identity
  • Operating state, speed, load, and runtime
  • Available flow, suction and discharge pressure, vibration, temperature, and electrical measurements
  • Maintenance events, inspected condition, intervention, and outcome

Signal availability and placement are checked for each installation. Missing values remain missing.

Connected technical layers

  • Pump, motor, sensors, and approved local control
  • Read-only acquisition, edge validation, and local buffering
  • Historian or time-series store with asset and operating context
  • Maintenance-management workflow with acknowledgement and finding

Connectivity loss must be visible. It must not disable the existing qualified control system.

Pump and motorValidated measurementsOperating-state baselineReviewable conditionMaintenance finding

A rule may prepare a bounded inspection recommendation. Shutdown, isolation, work priority, repair, and return-to-service remain with the appropriate control system and authorized personnel.

Where automation and AI fit

Use the simplest reliable method for each job.

Deterministic automation

Check signal freshness and range, detect flatlines, separate operating modes, require a condition to persist, deduplicate alerts, and present a maintenance review record. These are understandable rules that can be tested before a predictive model exists.

Analytical models

After trustworthy operating states and maintenance outcomes exist, multivariable analysis may help spot unusual relationships among flow, pressure, load, vibration, and temperature. An anomaly is a reason to investigate, not a verified failure mode or a promised failure date.

Evidence-linked AI assistance

An approved assistant could summarize the relevant trend and cited service history, surface similar reviewed events, or draft a technician handoff. Its answer must show source records and uncertainty. It does not invent missing measurements or approve an action.

Human and control authority

Operators, maintenance staff, and qualified engineers evaluate the evidence against process needs, equipment requirements, and safety procedures. Existing protection and control remain separate from the analytical layer.

How we examine a proposed solution

Relevant AI advisors support the design; people approve the work.

These are Adaptiv Stratum AI advisory roles used for scoped research and analysis when relevant. They are not human employees, licensed engineers, or a claim that the named agents are installed on a customer's live equipment. The deployed monitoring system would have its own separately reviewed design and permissions.

Argus

Challenges sensor selection, timestamps, telemetry quality, and edge behavior.

Aegis

Maps actionable failure modes, maintenance history, and false-alarm risk.

Apollo

Defines comparable baselines, metric definitions, and reporting lineage.

Pythia

Tests whether multivariable analysis adds value beyond simpler rules.

Hephaestus

Reviews control hierarchy, separation, and permitted handoffs.

Themis and Clio

Challenge authority boundaries, testability, source quality, and unsupported claims.

What becomes visible

A report should connect each warning to an inspected outcome.

The asset view shows the operating context and why review was requested. The management view shows whether the program is helping, without hiding missing data or claiming savings that have not been measured.

Per-asset record

  • Asset, duty, operating mode, and time window
  • Measurements and baseline used, with units and data-quality status
  • Condition rule or analytical version and supporting trend
  • Who acknowledged it, inspection finding, action, and closure
  • Condition after intervention, including unresolved outcomes

Program-level measures

  • Valid-data coverage and sensor faults
  • Time from first valid warning to inspection or confirmed event
  • Reviewed alerts with verified findings, false alarms, and missed events
  • Unplanned downtime and repeat service events
  • Energy per useful delivered volume only for comparable duty and verified metering

A lower alert count is not automatically success; it could mean a broken sensor. A model score is not a maintenance finding. Reports should preserve both the supporting records and what remains unknown.

Operating safeguards

Trust starts with the failure cases.

The equipment, consequence, environment, and agreed scope determine the exact controls and acceptance checks. A failed sensor cannot become evidence of a failed pump. An unavailable network cannot silently make stale data appear current.

  • Range, flatline, freshness, calibration context, and cross-signal checks
  • Operating-state normalization before comparing trends
  • Persistence and deduplication so transient changes do not flood the team
  • Explicit unknown, sensor-fault, maintenance-mode, and disconnected states
  • False-positive review and inspection-outcome feedback
  • Authorized shutdown, energy isolation, and return-to-service outside the monitoring layer

A practical first phase

Start with one consequential asset and a testable question.

  1. Define the decision.Choose a pump where earlier awareness would change an inspection or maintenance decision. Record the process consequence and who owns the response.
  2. Audit what is already known.Confirm asset identity, existing instrumentation, control boundaries, maintenance history, and accessible data. Do not assume every listed measurement is available.
  3. Make the signals dependable.Check timestamps, units, sensor health, modes, and a baseline for comparable operation. Preserve original controller behavior.
  4. Run in observation mode.Test explainable conditions with operators and technicians, recording false alarms, missed conditions, and inspection findings before routing work automatically.
  5. Decide what earns expansion.Compare the evidence with the original business question. Add work-order integration or more advanced analysis only if it improves a reviewable decision without weakening safety or accountability.

Begin with the operating problem

What pump condition is costing you visibility?

A useful first conversation can start with one asset, its current measurements, recent maintenance findings, and the decision you wish you could make earlier.

Discuss a pump monitoring question →

Evidence and further reading

Engineering claims should be checkable.

These sources inform the approach. The scenarios above remain illustrative and are not case studies of Adaptiv Stratum customers.