Now live: a hybrid process digital twin for amine gas sweetening — it names the fault and the root cause, not just the alarm. Request a demo →

QEM & OPS logo

Run

Put a working model of the plant behind every reading.

Run is the grey-box process digital twin. You give it the boundary conditions and it returns the value every monitored point should have if the train were healthy. The gap between that and reality is where every diagnosis on this platform starts.

13Modelled process blocks
26Equipment items covered
~100Live fields on the P&ID
0Meters required for soft sensors

MVPEvery figure above is counted in the minimum viable product: the amine train modelled for gas sweetening and post-combustion carbon capture.

What it does

Four things it does that a dashboard does not.

01

Physics first, data second

Kremser absorption factors for the absorber. Counter-current ε-NTU and LMTD for the exchangers. Performance curves for the pumps. Energy balances across the reboiler and the column profiles. The fitted parameters are health parameters — UA, cleanliness, stage efficiency — so when one drifts it means something physical, not something statistical.

02

An expected-healthy value for every tag

The model returns what each monitored response should read under the current boundary conditions. A fault then shows up as a residual — actual minus expected — instead of as a fixed alarm limit that has to be re-tuned every time the plant changes load.

03

Soft sensors where no meter exists

Rich-amine flow to the lean/rich exchanger has no meter anywhere on the train. Run computes it from the lean circulation, the acid gas absorbed between the feed and treated analysers, and the filter side-stream. Exchanger fouling is published the same way, as a live UA and cleanliness factor.

04

The P&ID is the interface

Every box that carries a live value is marked in the drawing itself. The engineer works on the plant diagram, not a spreadsheet, and the picture cannot drift out of step with the calculation.

How it works

The pipeline, end to end.

  1. 1

    Calibrate once, offline

    Each block is fitted against the training history and the equipment datasheets. The result is baked into a calibration file. This is the slow step, and it runs rarely.

  2. 2

    Take the boundary conditions

    Feed rate and pressure, inlet analysers, solvent strength from the laboratory, steam and cooling-water conditions. Everything the operator can actually set or observe.

  3. 3

    Solve block by block

    Absorber, stripper and reboiler, lean/rich exchanger, inlet conditioning, overhead condenser, filters, pumps, drums, system inventory. The absorber and regenerator loops close against each other.

  4. 4

    Return the healthy plant

    Every response tag, plus the soft sensors and the health parameters. No refitting happens at query time — the baked calibration is reused, so a single point runs in seconds on unseen data.

  5. 5

    Hand the residuals on

    The difference between expected and actual becomes the input to Detect and Prognose. One model, three tools.

Where it applies

Built for amine systems today. Not limited to them by design.

The platform is focused on acid gas removal — gas sweetening and post-combustion carbon capture — because that is where the model is calibrated and where the fault library is real. The method underneath is not amine-specific: a physics reference model, residuals against expected-healthy, fuzzy diagnosis over graded indicators, and costed consequences. Extending it to another unit means new datasheets and a new calibration, not a new platform.

  • Gas sweeteningLive today
  • Post-combustion carbon captureLive today
  • Other acid gas removalMethod applies
  • Wider process unitsFuture

The fastest way to judge this is to open it.

The platform runs on a real amine train with thirteen days of one-minute history behind it. Nothing on these pages is a mock-up.

Open the platform