Case study 05 / 17Node Back-End
Diagnostic engine that separates sensor faults from process faults
Scores signal trust, checks each segment against hydraulics and sends every new fault signature to human review before operators see it.
Stack
- TypeScript
- Node.js
- Next.js
- React
- MongoDB
- InfluxDB
- ECharts
01 · How it works
- TodaytoChanged in this work
- Data flow
What it does
I designed and built a rule-based diagnostic engine that runs beside the monitoring platform's data poller. On every poll it rates how far each signal can be trusted, compares each segment with what hydraulics predicts, and reduces it to a fingerprinted state that selects the scenario and its recommended action.
Read more
A super administrator approves each new fingerprint once; after that, the case reaches operators with its evidence and two charts.
6 connections· select a part to trace it
- Data poller to Confidence gate: readings every 10–15 s
- Confidence gate to State vector: passes if confidence ≥ 0.6
- State vector to Fingerprint catalog: looks up its fingerprint
- Fingerprint catalog to Review queue: new or changed: proposes
- Review queue to Fingerprint catalog: approved once
- Fingerprint catalog to Operators' panel: approved: goes direct
02Results
- R01Lower is better
Proposals closed before review (of 68)
Before 41, after 0, eliminated. Lower is better.BeforeAfter - R02Higher is better
Noise samples per false leak alarm, 5σ → 10σ
Before 900, after 44,000, 49× higher. Higher is better.BeforeAfter - R03Lower is better
Slowest panel repaint, p95
Before 414 ms, after 21 ms, 20× lower. Lower is better.BeforeAfter
What it achieved
- Diagnosis: alarms on raw thresholds → signal trust first, then hydraulics, then a fingerprinted scenario with its recommended action
- Human oversight: 41 of 68 proposals closed unreviewed in a day → 0; only a decision clears one
Read more
- Reviewer load: 68 cards → 44, one per fingerprint
- False leak alarms on noise: one every ~900 samples → one every ~44,000
- Consistency: six definitions of the same condition → two, with 0 differences in a 6 h replay
The challenge
A full day of alarms showed the real problem: most described the instrumentation, not the process. About two-thirds were frozen-signal alarms hitting every station of a channel at once, a single shared communication link failing rather than many sensors. On one pipeline a steady discrepancy between two flow meters held a confirmed-leak alarm on all day; a plain threshold rule would have kept alarming for 14 hours.
Read more
Some configured thresholds could never fire, and missing readings were stored as zero, which is exactly the condition that triggers a partly-empty-pipe alarm. Even the first review queue failed silently: proposals closed themselves after ten minutes unseen.
What I learned
Discover scenarios; do not enumerate them. A pipe segment has 81 possible state vectors and a channel segment 243, yet thousands of real samples produced only nine, so the catalog grows only from what actually occurs.
Read more
The same symptom can require different actions, so pipe cleaning is recommended only after other causes are ruled out and the trend holds for days. I proposed a 5σ limit, measured it against noise and shipped 10σ. A recorded replay now fails if the math changes.
Stack
- TypeScript
- Node.js
- Next.js
- React
- MongoDB
- InfluxDB
- ECharts
Skills
- Rule engine design
- Anomaly detection
- Hydraulic modeling
- Human-in-the-loop review
- Replay regression testing
