Capstone: Investigating a Trip Event
The Scenario
Unit 2 tripped at 0347 hours. Multiple alarms are logged around the event — an axial position trip, a low lube oil pressure alarm, and a high vibration alarm all appear in the log within a few seconds of each other. This module walks through the full investigation process using every tool from this track to determine what actually happened and whether the protection system performed correctly.
Step 1 — First-Out Data Identifies the True Initiator
Per Module 5.2, first-out annunciation is the single most important piece of data in any trip investigation. Here, it identifies the axial position/thrust trip as the actual initiating event — not the low lube oil or high vibration alarms, both of which appeared 2-3 seconds later. Without first-out data, an investigator might mistakenly chase those secondary alarms as independent root causes.
Secondary alarms appearing after a first-out event are frequently consequences of the trip and rapid deceleration itself — transient lube oil pump behavior during coastdown, vibration from rapid speed change — not separate, independent problems requiring their own investigation.
Step 2 — Ruling Out Instrumentation Problems
A review of the axial position sensor voting logic (Module 5.6) shows all three redundant probes agreed on the abnormal reading — a full 2-out-of-3 (in fact 3-out-of-3) agreement, not one outlier sensor overridden by two others. This strongly rules out a single faulty sensor or a common-cause sensor failure. Recent test history (Module 5.4) confirms the axial position/thrust trip function was tested and passed within the past month, ruling out a latent trip logic failure that happened to coincidentally align with a real problem.
Step 3 — Confirming a Genuine, Gradually Developing Condition
Reviewing historical axial position data reveals a gradual, steady shift beginning roughly three weeks before the trip — precisely the early warning trend pattern described in Module 5.5's failure progression: normal operation, gradual babbitt wear, a detectable and worsening axial shift. This is not the signature of a sudden instrumentation glitch; it's the signature of a genuine, developing mechanical condition.
Post-trip physical inspection closes the loop: babbitt wear was found consistent with exactly the progression the trend data predicted. The vibration/position data forecast a specific physical condition, and direct inspection confirmed it.
First-out data identifies the true initiator → sensor voting rules out instrumentation error → recent testing rules out a latent trip logic failure → trend data confirms a gradually developing physical condition → post-trip inspection physically confirms it. Every step of this investigation applies a specific tool or concept from this track.
Step 4 — What This Investigation Concludes
This was a genuine thrust bearing failure, developing gradually over roughly three weeks, correctly detected by axial position monitoring, and correctly stopped by the protection system before the failure could progress to rotor-to-stator contact (Module 5.5's worst-case outcome). The protection system — sensors, voting logic, trip architecture, and recent successful testing — all functioned exactly as designed throughout this event.
The appropriate follow-up is thrust bearing repair or replacement, along with investigating why the babbitt wear began in the first place (oil contamination, overload, or another root mechanism) — not questioning whether the trip itself was valid. This capstone demonstrates the full value of everything covered across this track: not just designing and building good protection systems, but correctly interpreting what they tell you after they've done their job.