Platform
Putting a rating pass in the control room.
A process engineer already knows how to rate a heater. The problem is that it takes an afternoon, needs data nobody has, and by the time it is done the plant has moved. We made that calculation run every hour, on the tags you already record.
From your historian to a priced move.
Six stages. Each one is inspectable, and each one can be wrong in a way you can see.
- 01
Historian
Your tags, as recorded. We do not need a clean dataset and we do not expect one.
- 02
Clean and label
Sensor faults are found and dropped. Process excursions are kept, because those are real physics the twin has to learn rather than noise to filter out.
- 03
Soft sensors
Fouling and true excess air are inferred, since almost nobody measures either. Anything that cannot be inferred reliably is switched off rather than shipped.
- 04
Surrogate
A learned stand-in for the rigorous solve, fast enough to search a year of operation instead of a single point.
- 05
Optimiser
Constrained on CO, tube metal, acid dew point and draught. It finds the best safe move and reports which limit stopped it.
- 06
Operator card
The move, its price, the thing to watch, and the reason. Written to be acted on by the person holding the panel, not filed by an engineer.
The output is a sentence, not a dashboard.
Most tools in this space end at a chart and leave the interpretation to whoever is on shift. Ours ends at an instruction with a price on it, the limit that bounds it, and the physics that explains it.
An operator at three in the morning does not need a scatter plot. They need to know what to change, how far, what to watch, and when to stop.
- Efficiency
- 87.1 %
- Stack O2
- 3.73 %
- Stack temp
- 233 C
- CO
- 20 ppm
- Feed
- 189,546 kg/h
- Outlet
- 415 C
- Fouling
- 0.75
- Detected fault
- fuel_upset
Trim excess air 19.8 % to 9.9 % (stack O2 3.73 % to 2.08 %)
$45.44/h~$381,710/yr at this state
- +1.26 ptsefficiency
- −1.52 %fuel
- −0.617 t/hCO2
Watch Move in steps and hold. Stop if CO passes 100 ppm before the O2 target, or if the stack falls below 98 C.
Why +−
Every percent of excess air above what the burners need is nitrogen heated from 20 C to the 233 C stack and vented. Cutting stack O2 by 1.65 points removes that parasitic mass flow, which is why the stack falls 16 C and dry flue-gas loss drops with it. The duty is unchanged, so the whole of the recovered loss shows up as less fuel through the burners. The move stops where it does because CO 167 ppm at the 200 ppm limit.
How we build a twin for your unit.
Four stages, and the model has to survive each one before it moves to the next.
- 01
Scoping and geometry
We take your drawings, datasheets and a tag list. Firebox dimensions, coil layout, convection bank and burner arrangement become the model, not fitted parameters.
- 02
Model build and closure checks
The twin is solved and tested before it sees any of your data. The energy balance has to close, and the direct and indirect efficiencies, computed by independent routes, have to agree. If they do not, the model is wrong and we say so.
- 03
Calibration against your history
Now your tags come in. Soft sensors are fitted, the surrogate is trained on blocked time folds, and we report where the model and the plant disagree rather than tuning until they do not.
- 04
Shadow running
Recommendations are produced but not acted on, so you can watch it for a campaign before anyone touches a setpoint. Nothing writes to your control system.
The checks that run every time.
These test the calculation rather than the heater. A model that fails them is not shipped.
3.6e-9 GJ/h
The balance closes
Mean energy balance closure error across 696 solves. Energy in equals energy out to machine precision, and the direct and indirect efficiency routes agree to the same order.
Correct signs
The physics points the right way
- Fuel rises with excess air
- CO falls with excess air below the knee
- Efficiency falls with excess air
Source: thermotwin/artifacts/ml/ml_metrics.json, keys physics_residual and monotonicity. Asserted in the test suite rather than claimed here.
Speed is why this is possible at all.
The rigorous model is the truth. It is also far too slow to search with.
A single rigorous solve takes 1.75 seconds. Optimising a 120-day hourly history with the rigorous model directly would take 176 hours of compute. The surrogate does the same work in 388 seconds, a speed-up of 1,631x.
That is the whole argument for a surrogate. Not accuracy, which the rigorous model always wins, but the ability to ask the question at every operating hour instead of one convenient design point. We then re-solve a sample of the answers in the rigorous model to find out how much of the promised value is real.
Source: ml_metrics.json, key speed. Single core.
Deployment and security.
The first question every refinery asks, answered before you ask it.
Nothing writes to your control system. The twin reads history and produces recommendations. A setpoint changes when a person decides it changes. We are not asking for closed-loop control and we would not take it at this stage.
Read-only historian access. A tag export, or a read-only OPC or PI connection, is enough. We do not need write credentials to anything.
On your infrastructure if you want it. The model runs on a single machine. It can sit inside your VPC or on a box in your own network rather than in our cloud. For a first pilot, an offline tag export and a report is often the fastest way through your IT review, and we are happy to start there.
See it against your own unit.
The design point we model today is a 53.4 MW absorbed crude preheat heater. Yours will be different, and finding out where the model bends is the point of a first pilot.