Condition-Based Cleaning Trigger¶
Control trigger — instantiates Interface Fouling Control
Launches cleaning when a fouling-load signal crosses a functional threshold, so service happens exactly when the interface needs it — not by the calendar.
A condition-based cleaning trigger is the decision rule that turns a measured fouling load into a clean/no-clean call. It watches a signal that tracks how occupied the interface is, holds a threshold that marks where occupation begins to cost real function, and fires the cleaning action the moment the signal crosses it. Its defining premise is demand-driven timing: it does not observe the interface itself and it does not perform the cleaning — it consumes a reading, compares it to a boundary priced in functional terms, and issues the go signal. Everything about it is the when, decided from evidence rather than habit.
Example¶
A power plant runs a gas turbine whose axial compressor slowly ingests airborne dust and oil mist that coat the blades, degrading the pressure ratio and quietly bleeding off output. Rather than wash the compressor on a fixed weekly schedule — sometimes too soon, sometimes far too late — the plant sets a condition-based trigger. It watches the compressor's performance signal (a fouling-corrected efficiency index derived from pressure and temperature readings) and holds a threshold set where the lost megawatts and extra fuel start to outweigh the cost and downtime of an online wash. When steady operation drives the index down past that line — after a dusty week it might arrive in days, after a clean spell not for weeks — the trigger schedules the wash. The threshold is priced, not aesthetic: it sits exactly where the cost of carrying the fouling exceeds the cost of clearing it, so the plant cleans neither too early nor too late.
How it works¶
The distinguishing method is a priced comparison that fires an action:
- Consume the load signal. Take a reading that stands in for interface occupation (pressure drop, efficiency loss, drag, energy draw) from whatever inspection or sensor supplies it.
- Hold a functionally-priced threshold. Set the trigger point where the occupation cost of waiting starts to exceed the cost and disruption of cleaning — not at "looks dirty."
- Fire on crossing. When the signal passes the threshold, issue the cleaning call; below it, do nothing.
- Balance, don't chatter. Use hysteresis or a dwell so the trigger keeps clearance matched to deposition without firing on every noisy blip.
Tuning parameters¶
- Threshold level — how far fouling is allowed to progress before firing. Higher tolerates more loss but cleans less often; lower cleans early but wastes service on light fouling.
- Signal choice and proxy quality — which measurement stands in for occupation; a poorly correlated proxy fires at the wrong times regardless of a good threshold.
- Hysteresis / dwell — the gap between the fire point and the reset, and how long the signal must hold; wider stops chatter but adds lag.
- Cost-ratio stance — how the carrying-cost-versus-cleaning-cost trade is priced into the threshold; a conservative stance cleans sooner and safer.
- Debounce window — how transient spikes are filtered so a momentary reading does not launch an unnecessary clean.
When it helps, and when it misleads¶
Its strength is that it spends cleaning effort exactly where and when it earns its keep: no wasted service on a still-clean interface, no silent decay past the point of easy recovery. It is the core of condition-based maintenance[1], and it shines when fouling pressure is variable — seasonal, load-dependent, weather-dependent — where a fixed cadence is always wrong in one direction.
Its failure mode is total dependence on the signal: a proxy that lags the true fouling, drifts, or decouples from function will fire too late or not at all, and a threshold set from optimism rather than cost lets occupation mature past the reversible regime. The classic misuse is trusting a single, uncalibrated sensor as ground truth — the trigger reports "all clear" while the interface fouls under a blind spot. The guarding discipline is to keep the signal honest against an independent check of the interface and to set the threshold from the priced cost of occupation, revisiting it as the deposit's behavior changes.
How it implements the components¶
functional_tolerance_threshold— it is the threshold logic: the boundary, set in functional terms, that separates tolerable occupation from occupation worth acting on.occupation_cost_model— the threshold is placed by weighing the cost of carrying the fouling against the cost of clearing it, so the trigger encodes the occupation cost.deposition_clearance_balance— by firing whenever load approaches the limit, it keeps clearance actions matched to the actual, varying deposition pressure.
It does not implement fouling_load_signal or post_cleaning_verification — producing the reading and confirming that a clean restored function is Visual or Sensor Fouling Inspection, which this trigger consumes; nor does it implement removal_or_shedding_pathway — performing the clean is Backflush, Purge, or Wash Cycle or Scheduled Cleaning or Scraping Protocol.
Related¶
- Instantiates: Interface Fouling Control — supplies the demand-driven timing rule that decides when clearing is warranted.
- Consumes: Visual or Sensor Fouling Inspection supplies the fouling-load reading the trigger compares against its threshold.
- Sibling mechanisms: Scheduled Cleaning or Scraping Protocol · Visual or Sensor Fouling Inspection · Backflush, Purge, or Wash Cycle · Chemical or Biological Fouling Treatment · Antifouling Coating or Surface Treatment · Flow-Shear or Self-Cleaning Geometry · Sacrificial Liner, Screen, or Filter · Design for Cleaning Access
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Launches cleaning when a fouling-load signal crosses a functional threshold, so service happens exactly when the interface needs it — not by the calendar, making its operative form a live operational control that automatically routes, enforces, adapts, or responds during execution.
Independent corroboration: The frozen evidence defines Condition-Based Cleaning Trigger as 'Launches cleaning when a fouling-load signal crosses a functional threshold, so service happens exactly when the interface needs it — not by the calendar', so its operative form is Control, Automation & Runtime.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Condition-based maintenance cohered service triggers tied to measured asset state rather than fixed calendar intervals.
Related originating lineages:
- Chemistry & Materials Science — Surface fouling, deposit growth, and threshold assays supply the cleaning-specific signal and functional boundary.
Review resolution: Condition-based and reliability-centered maintenance established servicing from measured asset state rather than calendar intervals. Surface chemistry supplies the cleaning-specific fouling signal and threshold, but the switching rule remains a single engineering-maintenance lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The sharpest contrast is with Scheduled Cleaning or Scraping Protocol: both decide when to clean, but the trigger fires on a measured crossing while the schedule fires on a predicted calendar. And it must not be confused with Visual or Sensor Fouling Inspection, which produces the reading — the trigger is only the rule that acts on it.
References¶
[1] Jardine, A. K. S., Lin, D., & Banjevic, D. "A review on machinery diagnostics and prognostics implementing condition-based maintenance". Mechanical Systems and Signal Processing 20(7), 1483–1510 (2006). Defines condition-based maintenance as making maintenance decisions from information collected through condition monitoring. registry ↩