MAS suite · Monitor
Four records carry a signal from the historian to a work order
IBM Maximo Monitor in production: a tag binding, a baseline band, an anomaly record and a work request in Manage. Each has an owner and one way of breaking. All four are taken apart below.
The operating envelope
What the ingest and alerting path actually does
- Under 5 min
- Signal outside its band to an open anomaly
- 1 s to 15 min
- Sample rate range, set per tag
- Tens of thousands
- Historian points one asset class offers
A five-minute historian poll plus the detection window. Anything shorter is work at the source.
The rate the source sustains under duty, fixed at binding rather than on a dashboard.
We bind the subset that answers a maintenance question, not the whole point list.
How condition reaches the plan today
Operational tagging and asset numbering were built by different teams
Both conventions are internally consistent. Joining them was never anybody's job.
The signal exists and nobody owns it
The historian has held the trend for months and an operator noticed it. The planner who could have scheduled the work never heard, because no route runs between the two screens.
Tag names no asset record answers to
OT tag naming and the Manage numbering convention grew up years apart under different owners, and neither joins to the other without a person who knows both.
Condition travels by conversation
The evidence arrives as a screenshot in an email. By the time it is a work order the trend is attached to nothing, so the argument runs again at the next planning review.
What gets paid for is the second diagnosis, the deferred job that became a breakdown, and evidence nobody could find when the plan was challenged.
The teardown
Four records, in the order the data moves
Equipment is illustrative. The fields are the ones we populate, and every record names an owner.
- 01
The tag binding record
Source path: the historian identifier, with unit and sample rate. Bound to: one asset record in Manage, at asset level. Owner: a named reliability engineer, reviewed whenever tag or asset changes. Breaks when it binds to a parent location: triage becomes a walk round the station.
- 02
The baseline band
Normal range: the band for this class under its actual duty. Exceptions: seasonal behaviour and start-up transients that would alert every spring. Agreed by: the supervisor and engineer who act on it. Breaks when operations never signed it: the first false alert spends the credibility the second needed.
- 03
The anomaly record
Asset: the bound asset, with criticality, parent, PM schedule and last work orders beside it. Window: the departure range, trend retained. Rule: which rule fired against which band, so it can be questioned. State: open, reviewed or dismissed, with a person on each transition.
- 04
The work request in Manage
Raised against: the asset the signal was bound to, so findings return to the evidence. Justification: the anomaly and its trend window, attached rather than pasted. Requested by: whoever reviewed it. Monitor does not appear in that field. Breaks when evidence is typed into a description and the deferral is later argued from memory.
The write path
Monitor states the condition, a named person decides the work
One trend on a raw water pump, from band crossing to work request. Anything consuming crew time passes through a person.
Signal, person, record
- Signal
- Drive-end vibration on raw water pump 2 crosses the band agreed at baselining, nine days into a rising trend.
- MAS Monitor
- Anomaly opened against the bound asset, trend window retained, detection rule recorded.
- Reliability engineer
- Checks the operating log for a duty change, finds none, and confirms the departure is real.
- Reliability engineer
- Rejects the call-out route and requests a bearing inspection at the next planned window.
- Maximo Manage
- Work request written against pump 2, anomaly attached, requester and rejected option recorded.
The prerequisite, shown
The same trend read on two asset hierarchies
One asset class, corrected before the tags were bound. Nothing about the OT estate changed.
Anomaly A-4417, raw water pump 2
4 of 4 fields changed
| Field | Before | After | Set by |
|---|---|---|---|
| bound_to | Pumping station location, covering four pumps | Pump 2, at asset level | Reliability lead, at the binding review |
| triage | Walk the station to find which unit moved | One trend and one operating log, reviewed at a desk | Named triage owner per shift |
| work_raised | Work order against the station | Work request against pump 2, trend attached | Reliability engineer who reviewed it |
| finding_lands | On a record that cannot say which asset degraded | On pump 2, beside the signal that raised it | Close-out in Manage |
Remediation is narrow: correct one class, bind at asset level, prove the loop, widen after. We quantify that in the readiness assessment rather than in month four.
Boundaries
Four limits on anomaly detection
It does not control anything
SCADA runs the plant and the OT team owns it. Monitor reads operating signal and issues no control action.
It cannot invent an asset record
An anomaly lands only where the asset exists in Manage under the right parent. Data work into Maximo closes that gap.
It states condition rather than probability
Monitor reports against the agreed band. Failure probability belongs to Predict, estate-wide ranking to Health.
It needs a triage owner per shift
With nobody accountable for reviewing an anomaly within a shift, the output is a queue. We design that role into the rollout.
IBM Maximo Monitor, frequently asked questions
- What does IBM Maximo Monitor do?
- Monitor ingests operating signal from SCADA, historians and edge gateways, scores it against the baseline band agreed for that asset class, and opens an anomaly against the bound asset record in MAS. A named reviewer decides whether work follows.
- How is this different from a SCADA screen or a BI report?
- SCADA runs real-time control in the OT estate. A BI report describes what already happened. Monitor scores operating signal against the asset, criticality and work history held in Manage, which is what lets a planner act on it.
- Which asset class should be first?
- The class where the signal is already reliable, the asset records are clean enough to bind a tag at asset level, and unplanned downtime costs more than seeing it sooner. A well-instrumented population of thirty beats the whole estate.
- Does Monitor raise work orders automatically?
- It can write to Manage, and the pattern we deliver keeps a named person in the path for anything that consumes crew time. That boundary is what makes the work request defensible at the next planning review.
- Where does the OT cybersecurity boundary fit?
- It is the binding constraint on every engagement. We design across the boundary with the OT team, normally through an edge or DMZ component. The zone by zone detail sits on IoT and OT connectivity, and sector constraints on Monitor for utility networks.
Bring one asset class and its tag list.
Name the equipment costing you unplanned downtime. We test whether those tags bind at asset level today, what the OT integration involves, and whether Monitor earns its licence on that class.
Bring this to the first call
- The asset class, and roughly how many units you run
- A tag list or historian point export for a handful of them
- The Manage numbering convention, and where it duplicates
- Who owns the OT boundary, and what they have declined
- The last unplanned outage on that equipment, and what it cost