The case against threshold alarms is arithmetic: 10,000 rules, and 20% false alarms at Daqing

Liu Shouxin, founder of DGIOT, has published a post arguing that threshold-based industrial alarms fail for structural rather than tuning reasons, and he puts a number on it: 100 equipment types times 20 parameters times 5 thresholds is 10,000 rules to maintain ^[1][2]. The arithmetic is the strongest part of the argument; the return figure attached to it is the weakest.

Take the combinatorics seriously, because they are what operators actually feel. On that same basis, adding one equipment type adds 100 rules, and adding one monitored parameter across the fleet adds 500 ^[3]. No maintenance team reviews that surface area on a quarterly cadence, so rules ossify and thresholds drift out of agreement with the plant.

The consequence is the part worth quoting. At Daqing Oil Field, according to the post, false alarm rates exceeded 20 percent under the old rules-based system, and operators learned to ignore alarms ^[4][6]. That is more than one alarm in five being wrong ^[5], which is the point where an alarm stops being information and becomes a tax on attention.

The post's diagnosis of why is specific. A pump starting up briefly spikes to 82 degrees C against an 80 degree threshold, and the rule cannot distinguish warm-up from failure ^[7]. "Pressure low" means cavitation on a water pump and depletion on an oil well ^[8]. And because each plant tunes its own thresholds, nothing transfers between sites ^[9]. The last one is the real cost: it means every deployment is a new tuning project.

The proposed alternative is a 252-entity OWL ontology that models equipment structure, compiled down to Erlang pattern matches so that each axiom becomes native code ^[10][13]. The worked example: a pressure reading of 2.35 MPa is interpreted as a pump with a bearing, bearings fail by overheating, and combined with vibration the pattern matches "bearing wear stage 2", producing a recommendation to schedule maintenance within 14 days rather than an immediate alarm ^[11]. Whatever the modelling machinery, the meaningful shift is output format: a work order with a horizon instead of a klaxon.

Around it sits a four-layer stack and a per-device gen_statem digital twin that mirrors the device lifecycle ^[12][14]. That shadow process is described as holding state through a 30-second gateway dropout and retrying silently, evaluating contradictory readings before propagating them, and freezing and resuming across firmware updates ^[15]. The post claims 928 gateways at 99.9999 percent uptime with a 10-person team ^[16]. Six nines permits roughly 31.6 seconds of downtime per year ^[17], which is about the length of the gateway dropout the shadow is designed to absorb, so where in the stack that availability is measured determines what the number means.

Two things earn credit. DGIOT still ships a rules engine and limits the ontology claim to equipment with mechanical structure ^[18], and the platform is Apache 2.0 with the ontology engine in the repository ^[19]. The approach came from Liu's master's thesis at Zhejiang University, 22 years before it shipped ^[20].

What to watch: the post gives no post-deployment false alarm rate, no baseline alarm volume, and no method behind the estimated $2.3M first-year saving at Daqing ^[21][22]. Also unstated is how many of the 928 gateways are at Daqing ^[21]. The falsifiable test is transfer: whether the same ontology drives a second site without per-plant threshold retuning, since that is the failure the post says rules cannot fix ^[9].