Condition Monitoring · Engineering example

Automated Maintenance Escalation

Turn persistent equipment-condition evidence into a traceable maintenance request. Define who verifies the signal, who acknowledges the request, and who authorizes service, while keeping alarms and machine-safety controls independent of the workflow.

The operating challenge

An alert is not a completed maintenance response.

A rising bearing temperature, recurring drive fault, or blocked filter can be visible in a control system yet never become a specific, owned work request. Operators may acknowledge a message, maintenance may hear about it by phone, and a later shift may assume someone else has acted. Conversely, a noisy signal can generate duplicate tickets and consume attention without improving reliability.

Signal versus condition

A single sample can be a bad sensor, a process transition, or an actual equipment problem. Persistence, operating state, and corroborating evidence matter before creating a request.

Alert versus work

An operator alarm calls for a timely operational response. A maintenance request captures inspection or repair work. The two can be related, but neither substitutes for the other.

Dispatch versus authorization

A ticket can identify the right asset and priority. It must not start a repair, bypass isolation procedures, or command a machine to stop or restart on its own.

Why modernize: Reduce lost handoffs and repetitive ticket entry while giving maintenance a useful history of what was observed, who reviewed it, what was done, and whether the condition returned.

Illustrative operating example

A transfer pump warns twice, but no one owns the follow-up.

This transfer-pump situation is illustrative. It is not a claim about a completed customer installation, measured savings, or a verified failure prediction.

Imagine a duty pump supplying a production line. Its motor temperature rises during normal load and a vibration trend also changes. The local system raises an operator alarm and continues to apply its existing protective logic. A technician hears about the issue at a shift change, but the ticket created later lacks an asset number, trend window, and operating context. The next crew sees an acknowledged alarm and assumes maintenance has already scheduled the inspection. The useful automation is not an AI instruction to repair the pump. It is a controlled, auditable path from a persistent condition to an acknowledged inspection request.

Validate the observation.Confirm pump identity, sensor freshness, running state, load, and the approved persistence or corroboration rule. A failed sensor becomes a data-quality case, not a bearing diagnosis.
Keep the operator response separate.The existing alarm and local protective controls remain in place. Operations follows its own response procedure and records what it observed.
Create one work request.If the eligible condition persists, create a uniquely keyed request in the maintenance system with asset, timestamps, trend excerpt, rule version, and operator context. Repeated events update or link to that request rather than opening duplicates.
Require acknowledgement.A named maintenance role accepts, reclassifies, or rejects the request with a reason. If acknowledgement is overdue, a defined human escalation path notifies the next responsible role.
Close the evidence loop.The technician documents the finding and corrective action; an authorized reviewer confirms the outcome. The condition is monitored afterward, and recurrence is linked to the earlier work.

What the reviewer would see

Transfer Pump P-4: condition to work

One traceable request, with the operational alarm kept distinct.

Condition: Temperature and vibration changed under comparable running load; data freshness and rule version recorded.
Request: Asset P-4, trend window, current operating state, priority proposal, and deduplication key.
Ownership: Assigned maintenance role, acknowledgement time, due window, and overdue escalation.
Outcome: Technician finding, approved service record, return-to-service authority, and follow-up trend.

Other high-priority situations

Different failure modes need different workflows.

Recurring drive fault with short resets

A conveyor drive restarts repeatedly after a fault. Group related events by asset, fault code, run hours, and operator action. A threshold can propose inspection before a more disruptive stop, while operations retains immediate control of the line.

Useful report: recurrence interval, linked tickets, verified cause, and post-repair behavior.

Filter pressure rises only at high flow

A differential-pressure reading should be assessed against flow and equipment state. A sustained deviation can lead to a scheduled inspection, not an indiscriminate replacement based on one peak.

Useful report: comparable-load trend, inspection result, replacement decision, and avoided duplicate work.

What a modernization would connect

Connect condition, ownership, and verified outcome.

The design needs more than sensor thresholds. It needs approved asset identity, clear rules for when an observation is eligible for a request, a reliable interface to the maintenance system, and a response path that still works when either system is unavailable.

Required operating evidence

Asset hierarchy, location, service criticality, and current operating state
Timestamped observations, engineering units, sensor health, and data freshness
Approved persistence, hysteresis, corroboration, and suppression rules
Operator alarm state and notes, without treating acknowledgement as repair
Work-request ID, owner, status, priority, due time, and change history
Inspection finding, corrective action, closure approval, and recurrence

Show unknown sensor or integration state explicitly; never silently infer that an unobserved condition has cleared.

Connected technical layers

Read-only data from the existing historian or control interface
Versioned condition-evaluation and duplicate-suppression rules
CMMS or work-order integration with idempotent request creation
Role-based acknowledgement, overdue escalation, and audit trail
Independent local alarm, safety, and equipment-control systems

The integration may create a request, but it cannot authorize energized work or modify the safety logic.

Validated conditionEligibility ruleOne work requestHuman acknowledgementVerified outcome

If the CMMS is unavailable, retain the event for retry and surface the failure to a responsible human. A missing acknowledgement is not a completed handoff.

Where automation and AI fit

Automate the handoff, not the maintenance authority.

Deterministic automation

Evaluate approved thresholds with state and persistence checks, attach a bounded evidence window, deduplicate requests, and track acknowledgement deadlines. Record every rule version and status transition.

Analytical methods

Compare similar-load trends and prior verified failures to prioritize review. A model can suggest that a pattern deserves inspection, but confidence and sensor limitations must accompany the suggestion.

Evidence-linked AI assistance

An approved assistant can summarize recent alarms, maintenance history, and relevant procedures with source links. It may draft a technician briefing or identify a missing fact, not issue an unreviewed repair instruction.

Human operating authority

Operations owns immediate response. Maintenance accepts and performs work. Authorized personnel apply energy isolation and approve return to service under site procedure.

How we examine a proposed solution

AI advisors review the handoff before it is automated.

These Adaptiv Stratum AI advisory roles support bounded design review. They do not monitor the plant as a live safety system or assign maintenance work themselves.

Argus

Checks sensor identity, timestamps, freshness, and the alarm-to-request evidence chain.

Hephaestus

Examines pump failure modes, maintenance access, and how the existing control system behaves.

Pythia

Tests whether prediction adds value beyond transparent persistence and trend rules.

Aegis

Challenges duplicate creation, missed acknowledgements, integration outages, and false confidence.

Clio

Defines how a pilot will compare alerts, accepted requests, completed inspections, and recurrence.

Themis

Reviews decision rights, safety boundaries, and evidence retained for audit.

What becomes visible

Follow the entire request, not just the alert count.

A useful dashboard lets operations see whether the condition is still active and who has accepted follow-up. Maintenance can see workload and repeat causes. Managers can tell whether the automation improves handoffs without hiding nuisance alerts or delayed work.

Per-condition record

Asset, location, observation window, operating state, and signal quality
Rule version, threshold or trend, and corroborating evidence
Operator alarm, acknowledgement, and response recorded separately
Linked work request, owner, priority, due time, and escalation history
Finding, action, return-to-service approval, and recurrence

Program view

Eligible conditions versus requests actually created
Duplicate suppression, false alerts, and missing-signal cases
Time from condition to request, acknowledgement, inspection, and closure
Overdue or orphaned requests by responsible role
Repeat condition after work and verified defect rate
Integration failures and manual recovery actions

Ticket volume alone is not success. The important measures are timely ownership, useful inspection findings, fewer missed follow-ups, and reliable closure evidence.

Operating safeguards

Keep the maintenance workflow subordinate to site safety.

Local protective controls and operator alarms remain independent
Approved asset, signal, and rule versions before live request creation
Persistence and hysteresis to prevent repeated noise
Idempotent request creation and visible integration failures
Role-owned acknowledgement and explicit overdue escalation
Sensor faults and missing data shown as unknown
Authorized personnel follow site-specific isolation and service procedures
No AI-generated machine commands or automatic return-to-service approval

A practical first phase

Prove one condition-to-work path on one asset class.

Select a recurrent condition.Choose a pump or drive issue that has real maintenance value and a known operator response, not the most dramatic unverified model alert.
Map current handoffs.Review alarm, shift log, CMMS, ownership, and service procedure with operations and maintenance.
Run in shadow mode.Evaluate condition rules and proposed tickets without creating live requests. Compare against technician judgments and note missing context.
Enable a bounded workflow.Create one deduplicated request for eligible events, require human acknowledgement, and test CMMS outages and overdue escalation.
Review outcome and expand carefully.Inspect false alerts, missed issues, response times, findings, recurrence, and safety observations before adding assets or AI assistance.

Begin with a handoff question

Which condition is noticed but not reliably owned?

One asset class, its alarm history, and maintenance records can define a practical first test.

Discuss a maintenance handoff →

Evidence and further reading

Distinguish monitoring, alarms, and maintenance decisions.

These primary sources inform the design. The transfer-pump situation is illustrative, not an Adaptiv Stratum customer case study.

NIST: Enhancing Maintenance Strategies for Manufacturing Operations describes equipment observations alongside human-maintained work-order records.
ISA: Alarm Management Questions That Everyone Asks explains why an actionable operator alarm needs rationalization and a defined response.
U.S. Department of Energy: Operations and Maintenance Best Practices, CMMS chapter describes connecting monitored conditions with maintenance work and keeping decisions with maintenance management.