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

How data and the model become decisions

From Data to Decisions

From a tag reading to a decision the shift can act on.

Data goes in, the model runs, and what comes out is not one answer but several: what is wrong now, what is coming, what a change would do, and what any of it costs. Diagnosis is the first of those, not the whole of it. Every view reads the same audited output — because a number you cannot argue with is a number nobody acts on.

From data and model to a decision, in four stagesAn animated diagram. Plant history and the calibrated model meet in one run, which leaves expected values, residuals, indicators, faults and costs behind it. Several views — Detect, Prognose, Discover, OTS, Gage, Ask and ten more tools — put different questions to that same output, and what comes out the far end is a named action with evidence and a price on it.01Data and modelHistory in, physics on topone run, four stagesexpectedresidualfaults · cost02The runOne computation, four stagesDetectPrognoseDiscoverOTSGageAsk+ 10 more tools03The viewsOne output, many questionsDECISIONClean E-401 SundayFouling, 6 of 8 indicatorsBefore the next ramp€148 / hour saved04The decisionIn time, and on evidence
Twelve seconds, on a loop. Six of the sixteen tools are drawn; all sixteen run on the same output today.
Open the platform See what it does

The core run

Four stages, and what each one leaves behind.

This is the run everything else is built on. Every stage is inspectable, and every stage can be wrong in a way you can point at: the design goal is not accuracy alone, but accuracy you can challenge. The detail of each stage sits on the Run, Detect and Prognose pages.

  1. 1

    Predict the healthy plant

    The reference model takes the boundary conditions — feed, solvent, steam, cooling — and returns what every monitored tag should read. That expected picture is what every later stage argues against.

  2. 2

    Take the residual

    Actual minus expected, tag by tag, and only while the plant is steady. A fault shows up as a gap against physics rather than as a fixed alarm limit, which is why the same rules hold at 60% rate and at 100%.

  3. 3

    Name the fault and its cause

    The residuals are graded into indicators, matched against fault signatures and traced back to a root cause — so the answer is not only what is wrong but what made it go wrong.

  4. 4

    Price the consequence

    Each live fault carries a cost per hour. This is the stage that turns a finding into a decision: the shift can rank what to fix first without a meeting about it.

What comes out of it

One engine. Sixteen tools, around three questions.

The dashboard is laid out around the three questions a shift actually asks. Most tools read the core run directly; the rest put a different question to the same calibrated model. Either way, what reaches the control room is visibility rather than another alarm.

What the plant is doing

Run, Detect, Prognose and Discover. The healthy picture, what is wrong now, what is coming, and the trends behind every number.

Live today

What to do about it

Ask, OTS, Tune, Gage, Optimise and Control. Question the plant, rehearse a move, settle a loop, find the flow, save steam, and set the next set-point.

Live today

What to hand on

Log, Report, Plan, Verify, Compare and Research. The shift handover, the monthly page, the maintenance plan, the instrument check, the side-by-side and the written study.

Live today

Yours

The tool your unit needs and this list does not have. Built on the same output, the same knowledge base and the same data — which is why it is weeks of work rather than a second product.

Built on request

All sixteen run on the reference train today. The last tile is the point: the engine, the knowledge base and the calibration are shared, so a new tool is a new question put to an output that already exists.

How an answer is argued

Three kinds of evidence, and one of them can overrule the rest.

A fault is not declared because a number crossed a line. It is declared because a pattern of evidence held together and nothing present contradicted it — and the contradiction test is the part most tools leave out.

01

Primary evidence

The indicators whose behaviour is characteristic of this fault and few others. These raise the call. For foaming, that is differential pressure across the absorber rising while circulation and load stay steady.

02

Corroborating evidence

Indicators that are consistent with the fault but not unique to it. They move confidence rather than trigger a call — which is why a diagnosis can be reported as probable rather than certain, and why the tier is shown next to it.

03

Exonerating evidence

The indicators that, if present, say this is NOT the fault. A rising absorber differential with a matching rise in gas rate is hydraulics, not foaming. Exoneration is what keeps the list short enough to act on.

04

Confidence and tier

Every call carries both, and both are derived rather than assigned. Two faults can be live at once with different tiers, and the platform will say so instead of picking a winner to look decisive.

What it will not tell you

Where the honest answer is "we do not know".

  • Forecasting runs on the same output: slow-wear channels are fitted over a three-day look-back and projected six hours ahead, and deliberately no further. The back-test showed the fit has no skill beyond about half a day, so no days-to-failure number is produced. Most tools will give you one anyway.
  • Twelve blind spots are published for the reference train — places where no channel exists and the model will not estimate one. Each is listed with what to watch instead, because a declared gap is safer than a confident guess.

The method is easiest to judge from the output.

The platform runs on a real amine train with thirteen days of one-minute history behind it. Open a diagnosis and read the evidence for yourself.

Open the platform