The drum level keeps swinging and early live checks flagged a possible feedwater supply problem. Is the supply failing, or is the level and feedwater control doing its job?
The answerNo feedwater supply problem. The level controller answers every change in drum level at once, the feedwater flow follows its setpoint to within 0.002, and every time the level dipped below its limit the feedwater was at its highest. Steam flow is close to zero: the boiler is idling. The swings are the disturbance the loop is correcting.
An alarm on one signal is a question, not an answer. InduQT read the whole control loop and found the supply healthy: when the level dipped, the feedwater was already at full stretch.
Replay the data
Every reading below came in live through InduQT’s OPC UA connector from the public OPC UA sample server at opcua.demo-this.com (Sample boiler #1), and this is InduQT’s own replay of it: press Play, or click a numbered marker to jump to that moment. Times are UTC.
Replay of the real readings. Press Play, drag the slider, or click a numbered marker. Zoom into the close-up to see 5-second readings. Times are UTC.
Each strip is one signal (click its name to show its trend):stronger = more (level further from setpoint, controller working harder, feedwater off its setpoint, steam load)drum level beyond its ±1.5 limitthe 5-second close-up
A single 5-second reading of −1.70 crosses the drum-level limit. In the same reading the feedwater flow is 0.72, its highest: the loop is already pushing water in.
Static charts of the same readings
What happened, minute by minute
- 16:30 Five tags mapped from the OPC UA server: drum level, feedwater flow, flow setpoint, level controller output, steam flow.
- 18:37 Drum level reads −1.70, past its −1.5 limit. In the same 5-second reading, feedwater is at 0.72, its highest.
- 18:47 An early live check sees the level fall and flags a possible feedwater supply problem.
- 19:40 With more data, live checks call it a process upset to watch, with no alarm.
- 20:08 Highest 40-second average of the evening: drum level +0.73.
- 22:00 InduQT’s diagnosis on the full 5½ hours: supply problem unlikely, decision normal.
What the data shows
The control chain is tight
The level controller output moves with the drum level at once (correlation −0.93, no lag), the flow setpoint follows the controller (0.995), and the feedwater flow stays within 0.002 of its setpoint for the whole 5½ hours.
When the level dipped, feedwater was already pushing
Every time the drum level went below −1.5 in the 5-second readings, the feedwater flow was at or near its highest (around 0.7). A supply problem looks the other way round: level and feedwater falling together.
The boiler is idling
Steam flow stays between 0.001 and 0.01 (scaled) all evening. There is no load swing for the loop to chase.
Fast swings, small averages
Reading by reading the drum level jumps between −1.8 and +1.9, but 40-second averages stay within ±0.8. Real drum water cannot move that fast while feedwater holds steady; this is transmitter noise in the simulation, and the reason single readings tripped the early checks.
Likely causes and the check for each
Level disturbance corrected by a working control loop
Controller, setpoint and feedwater all respond correctly and at once; the level returns to its average every minute or so.
Check: On a real boiler: compare the drum level transmitter with the gauge glass, and confirm the swings are visible on both.
Loop tuning
The level still swings around its setpoint. On a real boiler this would be worth a look once the load is known.
Check: A small step test on the feedwater valve, comparing the response with the controller’s tuning.
Feedwater supply problem
Feedwater never fell below its setpoint and was at its highest whenever the level was lowest.
Check: If alarms repeat: feed pump discharge pressure and current, and the deaerator level.
Data, decision, judgement
Three different jobs, and InduQT does each one deliberately.
Browse the OPC UA server, map five tags, done
InduQT connected to a public OPC UA server, browsed its address space and mapped drum level, feedwater, setpoint, controller output and steam flow: the whole control chain, not just the alarm point. Every reading is kept, down to 5-second detail.
Early checks asked; the full picture answered
When a single reading crossed the drum-level limit, early live checks flagged a possible feedwater supply problem. As the data built up they eased to “process upset, watch” with no alarm. InduQT’s diagnosis on the full evening rated a supply problem unlikely and the decision engine classed the period normal: no call-out for a pump that was working.
The engineer sees the loop working in seconds
In the replay, controller output, setpoint and feedwater move together with the drum level. One look at the close-up shows feedwater rising whenever the level dips, which is the loop doing its job. The diagnosis’s next check, look at the steam demand, settles the rest: the boiler is idling.
InduQT’s answer, in its own words: “The control system is actively responding; a direct feedwater supply problem is unlikely (low likelihood) and the decision engine classed the period as normal. Next check: the steam demand profile and the gauge glass against the measured drum level.”
What this case made better
- Live checks now only call something a fault when they can show the cause behind it; otherwise they report “insufficient data” and the check to run.
The moral of the story
- An alarm on one signal is a question. Read the whole loop: level, controller, setpoint, flow and load.
- Supply problems and control swings look different: in a supply problem level and feedwater fall together; here feedwater rose every time the level fell.
- Ask whether a change is physically possible. Water in a drum cannot jump from −1.8 to +1.9 in five seconds while feedwater holds steady.
- Data, decision and judgement: early checks can ask, the full analysis answers, and the engineer confirms it in the replay.
Watch this feed liveTroubleshoot your own feeds with Claude
Data: the public OPC UA sample server at opcua.demo-this.com (Sample boiler #1), public test server, OPC Labs. The readings shown are a saved copy taken when this case was written, so the page stays complete after live data is purged. The boiler is a simulation on a public OPC UA test server, so its values are scaled and its noise is the simulator’s. The method is the one InduQT uses on real boilers.