Trip & Overspeed Testing Procedures

Verification, Not Assumption

Modules 5.1 through 5.3 covered what protection systems do. This module covers how their actual reliability gets verified — because a protective device that hasn't been tested recently is a protective device whose real-world reliability is genuinely unknown, no matter how sound its design looks on paper.

Offline vs. Online Overspeed Testing

An offline overspeed test runs the turbine — disconnected from the grid — up to actual test overspeed (Module 5.1's ~103-105% tier), verifying that overspeed trip devices genuinely activate at the correct real speed. This is the most direct and complete verification possible: actually reaching real overspeed and confirming real trip devices respond. But it requires taking the unit offline, carrying real operational cost, and can typically only happen during planned outages or specific test windows.

An online (simulated) test injects a simulated speed signal into the trip logic while the turbine remains synchronized and at normal operating speed, verifying that the trip logic itself responds correctly to a signal indicating overspeed — without ever actually taking the machine to genuine overspeed. This avoids the operational cost of going offline, but it specifically tests the electronic logic and signal path (Module 5.1's electronic overspeed protection) — not necessarily every purely mechanical component, like an older-style mechanical overspeed bolt, that only responds to genuine centrifugal force.

Testing the Rest of the System

A stop valve exercise test periodically partially strokes each stop valve, without a full trip, to verify the valve moves freely and isn't sticking — a valve that hasn't moved in a long time risks seizing exactly when a real trip needs it to move fast. This connects directly to Module 3.4's fail-safe design discussion: a fail-safe mechanism is only as reliable as its actual physical condition, and periodic exercising is how that physical readiness gets verified rather than assumed based on the design alone.

Testing extends to every process trip covered in Module 5.3 as well — a low lube oil test, for example, typically simulates a low pressure signal or, during a planned outage, actually reduces lube oil pressure in a controlled way to verify the trip activates at the correct setpoint. The same testing philosophy — periodic verification rather than assumed reliability — applies across every protective function, not just overspeed.

Balancing Test Frequency

Different trip functions follow different test schedules based on criticality, likelihood of undetected failure, and practicality of testing. This represents a genuine trade-off: testing too infrequently risks a genuine failure going undetected for a long time, while testing too frequently adds operational cost and wear from the testing process itself. Test schedules are calibrated to balance these competing concerns for each specific function — overspeed testing might follow a specific outage-based schedule, while some online-testable functions might be verified more frequently.