AME Portal

The problem

Dew point surprises are expensive.

Liquid dropout, hydrate risk, off-spec penalties, custody-transfer disputes — they all trace back to the same gap: the chromatograph tells you the composition, but nobody turns it into a trustworthy, continuous, alarmed dew point at line conditions. Spreadsheets after the fact don't protect a delivery contract. A single off-spec event can cost more than years of monitoring done right.

The engine inside

The physics is ours, and it is citable.

AME Portal doesn't rent its thermodynamics. Underneath sits our own .NET calculation library: standards transcribed digit-for-digit from their published sources, every coefficient traceable, and every result carrying its own validity range and uncertainty statement. It is a zero-dependency component — which is why the same physics can run on an edge box, in the portal, or embedded in someone else's software.

• Water dew point

  ISO 18453, with the aqueous anchor that keeps the first-forming liquid from being missed.

• Gas quality

  ISO 6976:2016 — calorific value, Wobbe index and relative density, exact on the standard's own reference examples.

• Compressibility & density

  GERG-2008 (ISO 20765-2) and AGA8-Detail (ISO 12213-2), transcribed from the reference sources and agreeing with each other to 1.2×10⁻⁴.

• Hydrocarbon dew point

  Peng-Robinson / SRK two-phase flash with Michelsen stability — plus cricondentherm and cricondenbar as named solvers, not chart readings.

• Hydrate formation

  Munck 1988 with SRK, including methanol and MEG inhibitor depression — the operating question, not just the textbook curve.

• Phase envelope

  Predictor-corrector envelope tracing — and where the trace cannot close the whole curve, the result says so, instead of pretending it did.

• 441,072 paired whole-mixture dew points against the commercial reference engine: mean 0.3418 K across eight base mixtures — an agreement corpus, and the number moved against us when the campaign was completed, because that is what a corrected figure looks like.
• Water dew temperature agrees to 13 mK mean and water saturation content to 0.037 % — with zero solver failures across every campaign.
• Agreement with another program is not accuracy: hydrates are validated against laboratory data — 5.64 % on pure methane, 1.85 % on CO₂, 2.92 % on mixtures, 6.25 % on real natural gases — and methanol inhibition matches experiment from 10 to 50 wt%.
• Validated out-of-sample on primary-source data: five of six never-before-seen 1946 reference gases fall within the model's published accuracy class — and the sixth is disclosed as a known miss, not hidden.

Try the engine

Compute a dew point. Right here.

This is the shipped ISO 18453 engine, not a demo re-implementation — computed live as you type. Never a bare number: every answer arrives with its convergence, its residual, and a plain-language warning when you leave the standard's fitted range.

How it works

From field signal to defensible trend, automatically.

1. 01

   Connect what you have

   AME Portal reads your GC, RTU and transmitters over Modbus, IEC 104 or MQTT. No new field hardware — configuration, not engineering.

2. 02

   Compute, honestly

   Each analysis cycle becomes one quality-checked composition, then water dew point and gas quality to ISO 18453 and ISO 6976 (hydrocarbon dew point on the roadmap). Suspect data is flagged, never silently used.

3. 03

   See it, prove it, act on it

   Live dashboard and historical trends in any browser. Alarms with hysteresis fire before a contract limit is crossed — by webhook today, with email, SMS and Telegram coming.

Freedom of physics

Your dew point, your choice of engine.

Most systems weld you to one calculation engine forever. AME Portal treats the thermodynamics as a replaceable component: run AME's own validated engine, or the industry classic GasVLe — selected per measurement point, even both on the same stream, side by side.

Operator screens

Designed for a control room, not a dashboard.

Most industrial software is decorated. These screens follow high-performance HMI practice — grounded in the High Performance HMI Handbook, ANSI/ISA-101, ANSI/ISA-18.2 / IEC 62682 and EEMUA 191 — and the rules are written down, reviewed against, and pinned by tests rather than left to taste.

• Colour is a scarce resource

  Normal running state is greyscale; colour is spent only on what is abnormal or actionable. A screen where everything is green teaches the operator that colour means nothing.

• Flashing means one thing

  An alarm nobody has seen yet. It is the only motion on any screen — and that rule is pinned by tests, not left to a comment in the code.

• Nothing disappears unseen

  An alarm that cleared before anyone looked stays outstanding until it is acknowledged — the ISA-18.2 returned-to-normal-unacknowledged state, carried through the database and the wire.

• Alarm classes are configuration

  Name, colour, letter, whether it must be acknowledged, whether it may be shelved — set per site, not compiled into the product.

• The alarm system measures itself

  A dedicated page judges the alarm system against the EEMUA 191 / ISA-18.2 metric set — rates, floods, standing alarms, the worst actors ranked. Every rate is honest about its denominator: a period with no data reads as NO DATA, never as a reassuring zero.

• When a device goes quiet, the reason is on screen

  A per-device diagnostics page answers “why is this device not reporting?”: the connection log, decoded protocol frames — Modbus, MQTT, IEC 60870-5-104 — and the retry coming next. Quiet is recorded as a fact of its own, distinct from never having reported at all.

• The operator's language

  The operator interface is localised: English and Italian are live; German and French are fully translated and ship visibly disabled until a native reviewer signs them off. Safety text nobody has reviewed does not ship enabled.

• Readable by everyone, always

  Colour never carries meaning alone: every state also has a letter, a shape and a word. Motion can be switched off without losing information, and missing data is drawn as missing — never as a zero.

Your data, open

A control room in your browser. A database you own.

The dashboard shows live dew points against contract limits, channel health and active alarms; trends go back years and load in seconds, and any set of measurement points can be overlaid on one chart — each series titled with its engine provenance. Underneath sits open PostgreSQL — not a proprietary vault. Your engineers can query it, Grafana can chart it. If AME disappeared tomorrow, your data would still be yours, in a format the whole world understands.

Built for real sites

Every site measured. One place to look.

Compressor stations, storage fields, border points — each gets a small AME edge unit speaking to the local instruments. All report to one central portal: one database, one interface, one audit trail. Lose the link to a site? The edge keeps measuring, computing and alarming for up to a week, then fills the history back in — no gaps, no manual recovery.

One store, every site

All your sites push to one database.

However many edges you run — a handful or hundreds — each pushes its results north into a single central database. Every edge keeps a durable local outbox, ingest is idempotent — exactly-once in effect — and a week-long link outage simply fills back in when the line returns. No per-site silos, no stitching exports together later: every snapshot from every site lands in one PostgreSQL + TimescaleDB store — one backup, one place to look.

Why AME Portal

Built for plants, not for demos.

• The C6+ split is an input, never an assumption

  How a C6+ lump is split changes the answer — three published splits move a cricondentherm by ~6 K on the same gas. So the split is declared configuration, and every stored result names the one it used.

• Numbers you can defend

  Every result carries its full pedigree: engine, method, standard edition, data quality. When a number is challenged, you answer with a record — not a shrug.

• Choose your physics

  AME's validated engine or GasVLe — per measurement point, even side by side. No vendor lock-in on the calculation that matters most.

• Your data stays yours

  Everything on your premises — Linux or Windows, VM or hardware, no cloud required. Open PostgreSQL storage your tools can read, forever.

• Survives bad networks

  Edge units keep measuring, computing and alarming through a week of lost connectivity, then reconcile automatically. Remote sites are first-class citizens.

• Alarms that mean it

  Hysteresis and delay built in, so a value hovering at a threshold doesn't page anyone twelve times at 3 a.m. Acknowledgments logged: who, when, what they said.

• Field-born, not lab-born

  Designed by people who commission gas plants for a living. It respects how sites actually work: flaky links, mixed vendors, audits, and operators who need answers at a glance.

• Outbound-only edge

  The edge only ever dials out — one connection it initiates to the portal, no listening sockets on site. It works straight through plant NAT and firewalls, with nothing exposed to attack.

• Keys you can revoke

  Each edge carries its own API key — hashed at rest, shown once, revoked live from the UI. Durable config is split from transient commands, which expire rather than pile up, and every action is audited.

The honest comparison

What you're probably doing today.

Validation — engine vs engine

Two engines. The same gas. See for yourself.

We didn't just claim AME's engine is right — we ran it side by side with GasVLe 5.15, the industry's reference for decades, on the same compositions and pressures. Because AME Portal can host both, this isn't a slide — you can reproduce it on your own gas, any day.

Across the wet-gas cases both engines solved cleanly, AME agreed to within seventeen thousandths of a kelvin. On the hardest — natural gas at 60 bar with a trace of water — AME solved every one: without an aqueous anchor, a solver simply misses the first liquid to form and reports the hydrocarbon dew point instead, 13.5 K too cold.

ISO 18453 water dew point · 12 comparison cases · GasVLe 5.15 vs AME engine · full record on request

And the gas-quality figures? On the standard, to the digit.

Calorific value, Wobbe index and relative density to ISO 6976:2016 — AME lands exactly on the standard's own reference example, while matching GasVLe's long-established numbers to within a hundredth of a percent.

The numbers are indistinguishable. The engineering is not. AME's engine is modern .NET / C#, full double precision, Linux and Windows. GasVLe is a 2009 Fortran core behind a VB6 add-in — single precision, Windows-only, licence-locked ActiveX. Where the two ever diverge, it is usually GasVLe's single-precision arithmetic you are seeing, not the physics.

• Mostly within 3 mK — around a hundred times tighter than ISO 18453's own ±2 K uncertainty. The two engines are, for practical purposes, indistinguishable.
• AME's ISO 18453 interaction coefficients come back digit-for-digit identical to the reference engine's independent industrial database — the same physics, corroborated from two directions.
• The independent verdict: implementation-equivalent to the industrial reference on water dew point — and strictly more robust on wet natural gas at pressure.
• Re-proven inside AME Portal itself: the product's own GasVLe sidecar against licensed GasVLe 5.15 — 1.8 mK at line conditions, −0.9 to +3.2 mK across a 5–100 bar sweep, pinned as an automated acceptance test that recomputes AME's numbers on every build.

Touch the product

This is the job. Watch it happen.

This is not a mock-up: it is the AME Portal user interface itself — the same control library, the same screens, the same HMI rules — running the shipped AME engine over four simulated edge devices. Walk the nav rail: the fleet overview with its device faceplate, the trend with its fixed scale and contract limit, the alarm summary with ISA-18.2 states you can acknowledge, and the diagnostics. Only the plant is simulated.

Who it's for

Where gas quality is money.

• Transmission & storage

  Custody transfer points, border stations and storage facilities that live or die by contractual dew point limits.

• Gas treatment

  Dehydration and processing plants that need to see performance drift before it becomes an off-spec event.

• Industrial consumers

  Power, LNG and process plants protecting turbines and equipment from liquid carry-over and quality excursions.

Architecture

A cluster that heals itself.

Each site runs a small edge collector — industrial PC or virtual machine, the same binary. The central stack — ingest, gRPC services, notifications, the TimescaleDB time-series store and the Blazor UI — runs as VMs on a hyperconverged Proxmox cluster with Ceph storage: every disk kept in three copies across nodes. Patch a server by live-migrating its VMs away; lose one outright and the cluster restarts its VMs elsewhere on its own, in under a minute. No per-core licence, no single point of failure.

Resilience here is not an emergency feature — it is the normal state. Ceph keeps every disk replicated across the nodes, so the data a VM needs is never bound to the machine it runs on; and when a node is due for patching, its VMs live-migrate to another node before anyone touches it.

What happens when a node dies.

No pager at 3 a.m., no restore from backup: the cluster already holds three copies of every disk and keeps a majority standing — it brings the lost VMs back on another node and carries on.

And when a single disk dies.

The same logic reaches down into the disks themselves. When one dies, no VM stops and nothing is restored from backup: every block it held also lives on other disks on other nodes, so Ceph notices the loss and rebuilds the missing copies from the surviving replicas — on its own, until the pool is fully redundant again. Swapping the dead disk becomes routine maintenance, not a recovery.