VeraXTwin
A refinery at dusk with a wireframe VeraXTwin X overlaid, and a panel reading: MODEL DATA UNAVAILABLE. Data gap: 0 values not used. Reason: valve 4B maintenance.
Process control performance software

Software that tells you when it doesn’t know.

VeraXTwin measures how well a plant’s control and equipment actually perform — every loop, every valve, every advanced controller, the quality models on top of them, and the machines underneath. When a measurement cannot be taken, it says so and says why. It never fills the gap with a zero.

Request a walkthrough See what it covers
The platform

Five things a plant has to answer, in one place

Most sites answer them with five disconnected tools and a spreadsheet. These share one set of definitions and one archive, so a valve fault and a loop score are talking about the same equipment.

damping
01 · CLPM

Control loop performance monitoring

Continuous scoring of every regulatory loop, with the diagnosis behind the score rather than a bare number.

  • Oscillation, period and damping
  • Output saturation and windup
  • Operator intervention and mode
  • Data adequacy, stated before scoring
alarm apparent Cv at 45-55 % open
02 · Valves

Valve and transmitter diagnostics

Signature-based condition monitoring from the same historian data, graded against a state you accepted.

  • Stiction from the loop’s own signature
  • Erosion — apparent Cv drift at a fixed opening
  • Passing flow while commanded shut
  • Transmitter movement and flatline
limit CV1 CV2 CV3 CV4
03 · APC

Advanced control performance KPIs

What the multivariable controllers are actually delivering — service, constraint handling, benefit against a baseline you set.

  • Uptime and manipulated-variable service
  • Constraint and limit behaviour
  • Benefit against a captured baseline
  • Assessment and deployment tracking
input θ τ
04 · IQ

Inferential quality models

Soft sensors built from historian and lab data, with process dynamics identified per input rather than assumed away.

  • Dead time and lag identified per input
  • Feature selection by exhaustive search
  • Cross-validated scoring, one scorer throughout
  • Versioned model library with full history
threshold contributions
05 · APM

Equipment health and anomaly detection

Learned models of normal running for rotating equipment, scoring how far today sits from it — and naming the likely failure mode, from evidence.

  • Anomaly scoring against learned normal
  • Which tags drive the score, ranked
  • Fault diagnosis from an FMEA signature library
  • Operating-era and drift checks before trusting a model
How it behaves

The rules the software follows, without exception

Monitoring tools lose trust the first time a number turns out to be invented. These are the design rules that stop that happening, and they are enforced in tests rather than promised in a brochure.

absence ≠ zero
A measurement that could not be taken never renders as a zero or as “none detected”. A valve that never closed in the window has an unmeasured leak rate, not a clean bill of health.
refusal → reason
Every refusal carries its reason, in a sentence, in the place the number would have been. If a score is missing you are told what was missing and how much of it was needed.
supersede, never delete
Stored results are never rewritten. A revised model or a re-accepted baseline supersedes the old one; the old one stays readable, with the date and the reason it changed.
one definition
A number shown in two places is computed once. The score in a search table and the score in the finished model come from the same code path, so they cannot quietly disagree.
evidence, not narration
Fault diagnosis comes from a rule-based signature library built on rotating-equipment FMEA knowledge — not a language model. It is deterministic, auditable, works offline, and cannot invent a fault the evidence does not support.
traceable to rows
Every KPI names the window, the sample count and the exclusions behind it. A result you cannot audit back to the data is a result you should not act on.
Where it stands

In development, and being walked daily

VeraXTwin is built and tested against reference cases with known answers, so each diagnostic can be graded rather than believed. It is not yet generally available.

Stage

Active development. Working software across all five modules, walked and gated on every change.

Early access

Open to a small number of sites willing to run it against their own historian data and tell us what breaks.

Deployment

Runs on site, against your historian. Your process data does not leave your network.

Contact

Tell us about your loops

If you run a plant and recognise these problems — or you have data you would like graded — get in touch. A walkthrough takes half an hour.

info@veraxtwin.com