About QEMOPS
QEMOPS started from a plain observation: process plants are drowning in data and short on explanation. Historians record everything and explain nothing, and the gap between the two is filled by whoever on shift has seen it before. We thought that knowledge deserved to be written down properly — and then computed.
Where it came from
Years of operating and engineering experience on gas treating and carbon capture units, working alongside people whose profession is the science of absorption, solvent chemistry and process diagnostics. Neither group builds this alone. The plant people know what breaks and when. The academics know why, and can put it in equations that hold outside the range you happened to observe.
Before a line of the platform was written, the unit was documented: 26 equipment items, 161 sensor tags, 22 faults, 19 root causes, 54 indicators and 247 mapped causal edges between them. The software is a way of using that knowledge base. Without it there would be nothing to compute, and no way to explain an answer once computed.
The indicator set went through expert review and came back changed. Most indicators moved from relative statistical anchoring to fixed engineering-unit states, so a plant that is slowly getting worse cannot quietly redefine normal. One fault rule was removed entirely because it was reading the operator's own antifoam dose back as evidence of foaming. That review is the reason we trust the output.
Every figure on this site comes from a calibrated model of an operating amine train, with thirteen days of one-minute history behind it. Calibration is fitted on the training history; single-point diagnoses run on data the model has never seen. The separation is enforced in the code, not asserted in a brochure.
What we are building towards
An engineer should be able to open any fault, read the evidence, and either agree or point at the indicator that is wrong. That is the standard we hold ourselves to, and it is why every call shows the indicators that fired, the ones that corroborate and the ones that would have ruled it out.
The two hard parts of an optimiser already exist here: a validated plant model and an objective function denominated in money. Scoring candidate operating points automatically, rather than one at a time, is the next step.
An operator training simulator built on the same reference model and the same fault library, so a crew meets a fault in a rig before they meet it at three in the morning. The model already knows what healthy looks like and what twenty-two failures look like — that is most of a simulator.
The method — a physics reference model, residuals against expected-healthy, graded indicators, costed consequences — is not amine-specific. Extending it to another unit is calibration work rather than a new platform. We will do that when the first family is genuinely proven, and not before.
Where we stand today
We are not going to describe one calibrated train as a global install base. Here is the actual position, and every line of it is countable in the delivered system.
How we work
The quickest way to find out whether the model fits your plant is to send us a tag list and a datasheet. We will tell you honestly either way.
Get in touch