Two failures can be equally serious and yet require completely different management, and the thing that separates them is simply whether anyone knows they have happened. A failure that announces itself gets fixed; a failure that stays silent waits patiently to catch you out. This distinction - revealed versus unrevealed - runs underneath nearly every decision in safety and reliability, from how often you test to how you value a diagnostic. This guide explains what makes a failure revealed or unrevealed, why unrevealed failures drive proof-test frequency and mean dead time, and how diagnostics and stroke testing turn the hidden into the evident.
Revealed vs Unrevealed Failure in one line: A revealed failure announces itself as soon as it occurs - through a spurious trip, a diagnostic alarm, or an obvious loss of function - so it can be repaired promptly. An unrevealed failure is hidden or dormant, giving no sign it has happened, and it typically only comes to light when the function is finally demanded or a test is run. Because unrevealed failures accumulate silently, they drive how often proof tests must be performed, whereas revealed failures are managed simply by repairing them.
The defining question is detectability. A revealed failure changes something a person or a system will notice: a transmitter fails and its reading goes to a fault value, a component fails safe and trips the plant, a diagnostic detects a fault and raises an alarm. In each case the failure carries its own notification, so the clock on getting it fixed starts the moment it happens. Revealed failures are, in a sense, the well-behaved ones - they may be inconvenient or costly, but they do not lie in wait.
An unrevealed failure gives no such signal. It is dormant: the component has failed in a way that will prevent it from doing its job, but because that job is only demanded occasionally, nothing exposes the failure in the meantime. A shutdown valve that has quietly seized still looks perfectly normal as long as it is not asked to close - it sits in its usual position, its status appears healthy, and only a demand or a test will show that it can no longer move. The failure is real from the moment it occurs, but it is invisible until something forces the issue.
This is why the same physical fault can be either revealed or unrevealed depending on the function and its detection means. A failed transmitter that drives a live control loop reveals itself immediately because the loop misbehaves; the same failure in a rarely-demanded protection function might stay hidden for months. Detectability is not just a property of the fault - it is a property of the fault together with whatever is watching for it.
Unrevealed failures are the reason proof tests exist. If every failure announced itself, you could simply wait for the alarm and repair the fault; there would be little need to periodically exercise a system to see whether it still works. But because some failures stay hidden, the only way to find them is to deliberately go looking - to test the function and see whether it still performs. The proof-test interval is, at its core, a decision about how long you are willing to let unrevealed failures remain undiscovered.
The cost of a long interval is measured by mean dead time - the average length of time an unrevealed failure sits undetected before a test or demand finds it. For a failure that could occur at any point between tests, that average is roughly half the interval. During that dead time the safety function is not actually available even though everything appears normal, and the probability that it will fail on a real demand is driven directly by how long these dormant failures are allowed to persist. Shorten the interval and you shrink the mean dead time; lengthen it and the function spends more of its life secretly compromised.
This is the whole reason proof-test frequency is such a central lever in reliability. It has almost nothing to do with revealed failures, which are handled by prompt repair, and almost everything to do with unrevealed ones, which accumulate in the dark. Choosing how often to test is really choosing how much unrevealed dead time you are prepared to tolerate against the cost and disruption of testing more often.
The most powerful way to reduce the burden of unrevealed failures is to make them reveal themselves, and that is exactly what diagnostics do. An automatic diagnostic watches a component for signs of a fault and raises an alarm when it detects one, converting a failure that would otherwise have hidden until the next test into one that is announced the moment it occurs. Every failure a diagnostic can catch is a failure moved from the unrevealed column into the revealed column, where prompt repair replaces long dormancy. Partial and full stroke testing do the same for valves, forcing a normally-dormant final element to demonstrate whether it can still move.
This conversion is why diagnostic coverage and online testing matter so much. They do not make components fail less often; they change how quickly a failure becomes known. A function rich in diagnostics spends far less of its life secretly compromised, because most of its failures announce themselves rather than waiting for a proof test. The remaining unrevealed failures - the ones no diagnostic can catch - are what the proof test is left to find, which is why better diagnostics and periodic testing work together rather than as alternatives.
Continuous monitoring is what makes a revealed failure actually get acted on. A diagnostic alarm only helps if someone sees it, and a stroke test only helps if its result reaches the people who plan maintenance. A cloud SCADA platform such as Merobix reads diagnostic status, valve position, stroke times, and test results from the controllers and presents them in a browser, so a failure the diagnostics have revealed raises an alarm an engineer notices at once, and a dormant device that a test has just exposed is flagged rather than buried in a local log. The monitoring layer turns a revealed failure into a repair order instead of an alarm nobody was there to see.
A revealed failure announces itself when it happens - through a spurious trip, a diagnostic alarm, or an obvious loss of function - so repair can begin at once. An unrevealed failure is hidden or dormant and gives no sign, typically surfacing only when the function is finally demanded or a proof test is run. The difference is detectability, and it decides whether a failure is managed by prompt repair or must be hunted for by testing.
Because an unrevealed failure stays hidden until a test or a real demand finds it, the only way to discover it is to deliberately test the function. The proof-test interval sets how long such failures are allowed to remain undetected, and the average time they sit hidden - the mean dead time - is roughly half that interval. Shorter intervals shrink the dead time during which a dormant failure leaves the function secretly unavailable, which is why proof-test frequency is driven by unrevealed failures.
A diagnostic continuously watches a component and raises an alarm the moment it detects a fault, so a failure that would otherwise stay hidden until the next proof test instead announces itself immediately. Partial and full stroke testing do the same for valves by forcing a normally-dormant final element to prove it can still move. Each failure that diagnostics or testing can catch moves from the unrevealed category to the revealed one, where prompt repair replaces long dormancy.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.