A journal bearing failure on a steam turbine rarely announces itself with a dramatic alarm; it announces itself with a slow, almost boring climb in temperature and vibration over days or weeks, the kind of gradual change that's easy to dismiss as normal variation until the trend finally forces a trip. Thrust bearings behave similarly, with axial position drift that operators often attribute to instrument noise long after it's actually telling them something real about wear. The pattern that AI-based bearing monitoring is good at catching is exactly this kind of slow, multivariate drift, correlating vibration, temperature, and oil condition together rather than watching any single reading in isolation. If a recent bearing trend on your unit has you second-guessing whether it's real or just noise, our engineers can walk through it with you during a free bearing data review.
Journal Bearings vs. Thrust Bearings: What Each One Actually Does
Both bearing types support the rotor, but they resist load in different directions, and that distinction shapes what a developing failure actually looks like in the data. Understanding the difference is the starting point for interpreting any bearing trend correctly, and it also explains why a monitoring approach tuned for one bearing type doesn't automatically transfer well to the other without some adjustment.
The Three Signals That Actually Matter
Common Failure Modes and Their Signatures
Different failure mechanisms produce different combinations of vibration, temperature, and progression speed, and recognizing which pattern is unfolding helps prioritize how urgently a response is needed. The table below summarizes the failure modes most commonly seen across journal and thrust bearings on steam turbines.
| Failure Mode | Primary Signal | Typical Progression | Bearing Type |
|---|---|---|---|
| Oil film wiping | Sudden vibration spike | Fast, hours to days | Journal |
| Babbitt fatigue cracking | Gradual vibration rise | Slow, weeks to months | Journal or thrust |
| Thrust pad wear | Axial position drift | Slow, weeks to months | Thrust |
| Oil contamination | Rising particle count | Variable | Journal and thrust |
| Misalignment-induced wear | Vibration at 1x and 2x running speed | Slow, months | Journal |
Why Single-Threshold Alarms Miss So Much
Most plant control systems still alarm bearings on fixed vibration or temperature thresholds set at commissioning, and those thresholds work reasonably well for catching a bearing that's already in serious trouble, but they're poorly suited to catching the slow drift that precedes failure by weeks. A bearing can climb steadily from a healthy baseline reading toward the alarm threshold over a period of months without ever technically triggering an alarm, all while the underlying wear mechanism continues progressing unaddressed. By the time the threshold finally trips, the bearing may already be close to a condition that forces an unplanned trip rather than allowing time to plan a controlled repair during the next available outage window. The fix isn't necessarily lowering the threshold, which risks nuisance alarms from normal operational variation, but rather tracking the rate of change and the correlation between multiple signals simultaneously, which is exactly the kind of pattern recognition that trained models handle far more consistently than a human reviewing individual trend charts across dozens of bearings on a busy shift. It's worth noting too that fixed thresholds are typically set once at commissioning and rarely revisited, meaning a threshold calibrated for a brand-new bearing may no longer be well matched to a unit that's accumulated years of normal, gradual wear, further widening the gap between what the alarm catches and what's actually happening mechanically.
How AI Models Learn Bearing-Specific Baselines
A model is only as useful as the baseline it's measuring against, and building an accurate, bearing-specific baseline is where most of the actual engineering work happens before a model is ever trusted to generate live alerts. The sequence below is roughly consistent across deployments, though the specific data available and the length of historical record varies from unit to unit.
Reading a Bearing Trend the Way an Experienced Engineer Would
Before AI models became practical for this kind of continuous monitoring, the task of catching a developing bearing problem early fell almost entirely on experienced reliability engineers who had built up an intuitive sense for what a concerning trend looked like versus normal operational noise, usually from years of reviewing the same bearings across the same fleet. That intuition is valuable, but it doesn't scale well across a large fleet of units, and it's vulnerable to the simple problem of turnover, when an experienced engineer retires or moves on, that accumulated pattern recognition often leaves with them rather than staying documented anywhere the next person can access. A trained model effectively captures and formalizes that same pattern recognition, learning from the plant's own historical bearing events rather than a generic industry rule of thumb, and it doesn't forget what it learned or need years of tenure to build up the same depth of judgment. This isn't a replacement for experienced engineering judgment so much as a way of extending it consistently across every bearing on every unit, all the time, rather than concentrating that attention on whichever units happen to get the closest manual review in a given week.
Integrating Bearing Alerts Into the Maintenance Workflow
A model that generates accurate early warnings only creates value if those warnings actually reach the right person and translate into a planned action rather than sitting unreviewed in a dashboard nobody checks regularly. The most successful deployments treat bearing alerts as an input to the existing maintenance planning process rather than a separate system operators have to remember to check independently, routing flagged trends directly into the CMMS as a recommended inspection task with the supporting data attached, so the planner reviewing it has immediate context rather than having to go dig up trend charts separately. Alert severity should also scale sensibly: a mild, slow-developing trend might simply get logged for review at the next scheduled outage, while a rapidly accelerating trend on a critical bearing should escalate to a more immediate notification that reaches an on-shift engineer directly. Getting this workflow integration right is often what separates a monitoring system that actually changes maintenance outcomes from one that generates technically accurate alerts nobody acts on in time, and it's worth investing planning time in this integration step just as much as in the underlying model accuracy itself.
What This Looks Like in Practice
Consider a journal bearing that starts showing a slow increase in 1x vibration amplitude over six weeks, still comfortably below the fixed alarm threshold and easy to dismiss as sensor drift on a quick glance. A trained model comparing that trend against the bearing's own historical baseline, and correlating it against a simultaneous, smaller rise in drain oil temperature, can flag the combination as a developing condition well before either signal alone would justify concern. That earlier flag gives maintenance planners real options: schedule a borescope inspection at the next minor outage, order a replacement bearing proactively so it's on hand if needed, or simply increase monitoring frequency to confirm whether the trend continues. None of those options are available once the bearing has progressed to the point of tripping the fixed alarm threshold, at which point the only remaining option is usually an unplanned forced outage, often with less time to source the correct replacement parts than a planned repair would have allowed. The value of earlier detection isn't just avoiding the failure itself, it's preserving the ability to choose how and when the repair happens.
Building an Oil Analysis Program That Complements Vibration Monitoring
Vibration monitoring tends to get the most attention because it's continuous and reacts quickly to developing mechanical issues, but oil analysis provides a distinct and complementary line of evidence that vibration alone can't offer. Particle counting and metal-specific analysis can identify which bearing is actually generating wear debris even when vibration signatures from adjacent bearings are difficult to separate, and can sometimes detect a developing issue before it produces enough vibration change to register clearly. Building a periodic or continuous oil analysis program alongside vibration monitoring, rather than treating oil sampling as an occasional afterthought, gives a model considerably more to work with when trying to confirm whether a vibration trend represents genuine bearing wear or something else, like a temporary process upset or a sensor calibration issue. Plants that have integrated both data streams into a single monitoring view report far fewer false positives than plants relying on vibration data alone, since the combination of evidence is simply more conclusive than either signal by itself.
The practical challenge most plants run into is that oil analysis, unlike vibration, is often still collected on a manual sampling schedule rather than continuously, which limits how quickly a developing trend in oil condition can be correlated against real-time vibration and temperature data. Moving toward more frequent sampling, or online particle counting where the investment is justified, closes that gap and makes the correlation between oil condition and mechanical signals considerably tighter. Even without online oil monitoring, simply digitizing lab results as they come in and feeding them into the same trending system as vibration and temperature data, rather than keeping oil analysis reports as a separate paper or spreadsheet record, meaningfully improves how quickly a correlated pattern across all three signal types can be recognized.
