← Back to overview Architecture

Where OmniPath sits, and how it gets there

One layer, one output path. Models train in the cloud, pass through a security DMZ as signed artifacts, and run inference on a ruggedized GPU at the asset site. From there OmniPath writes setpoints into the regulatory control layer — and nowhere else.

Station optimization levers

Your controllers optimize units. Nobody optimizes the station.

Anti-surge and governor controllers do their job well: they protect and regulate individual machines, fast. Load-sharing balances the units that happen to be online. But nothing in the conventional stack decides how many units should be running, which ones, at what split, or what station discharge pressure minimizes total fuel under today's ambient and tomorrow's nominations. Those decisions are made by operators, by rule of thumb, against yesterday's conditions. That's the layer OmniPath occupies.

Station-level optimization levers, and why the conventional control stack leaves each one unowned
Lever What it decides Why the existing stack leaves it Typical contribution
Unit sequencing How many units online, and which — machines are not identical, with different maps, fouling states, and driver efficiencies Load-sharing balances units already online; staging is an operator judgement call Largest single lever on a 3–5 unit station
Non-equal load split Allocates flow to minimize total station fuel rather than to equalize a distance-to-surge proxy The regulatory layer has no economic objective function 2–5%
Speed vs. recycle Finds the operating point that meets discharge pressure without opening recycle No controller in the stack prices recycled gas Directly attacks the recycle KPI
Ambient and composition re-optimization Re-solves as driver output and compressor maps shift with ambient temperature and gas composition This is precisely the drift that degrades static models Continuous, seasonal
Anticipatory staging Starts and stops ahead of a nomination change or upstream swing rather than reacting to it Nobody owns the forecast-to-setpoint path today Avoids the worst transients entirely

The control stack

Every element in this diagram except one is already in your station. The single filled block is ours.

OmniPath sits above the existing control stack and writes setpoints only A monochrome layered control-architecture diagram following the Purdue model, drawn top to bottom. Level 4 is cloud training: reinforcement-learning pipelines, a model registry and a signed artifact store, drawn as a dashed outline. Below it a dashed security DMZ box provides one-way transfer, signed-boot verification and auditability; a thin arrow leads down into it from the cloud. At Level 3 there are two boxes side by side. On the left, drawn as the only solid filled block in the diagram, is OmniPath: supervisory optimization covering unit staging, load split, and speed and pressure setpoints, executing on a supervisory cadence of seconds to minutes. A signed-models arrow arrives into it from the DMZ. On the right, outlined, is any existing APC or MPC system, which coexists with OmniPath or is retained as the fallback target. Below Level 3 is the Level 2 and 1 DCS regulatory control layer: PID, cascade, ratio and override control with operator HMI and historian, on platforms such as DeltaV, Experion PKS, CENTUM VP, System 800xA and PlantPAx, executing modules every 100 milliseconds to 1 second, and marked unchanged. Exactly two arrows connect OmniPath to this layer: one downward arrow labelled setpoints only, and one thinner upward arrow labelled process data, read. Beneath a hairline rule, separated from everything above it, sits an independent Level 1 protection layer of three boxes, all marked unchanged and all connected to nothing: the safety system, comprising SIS, ESD, fire and gas, and HIPPS; anti-surge and governor turbomachinery control, working to the surge control line with recycle; and machinery protection monitoring vibration and temperature per API 670. Protective response times are 10 to 50 milliseconds. There is no line, arrow or connector of any kind between OmniPath and the protection layer: it is an independent protection layer with no write path from OmniPath. Below a second hairline rule is Level 0, the process itself: compressors, drivers, valves and transmitters. In summary, OmniPath writes setpoints to the regulatory layer only, and protective functions are independent, unchanged, and retain full authority at all times. LEVEL 4 DMZ LEVEL 3 LEVEL 2 / 1 LEVEL 1 LEVEL 0 signed models setpoints only process data (read) seconds → minutes supervisory cadence 100 ms – 1 s module execution 10 – 50 ms protective response Cloud training RL pipelines · model registry · signed artifact store Security DMZ one-way · signed-boot verification · auditable Existing APC / MPC where present — coexists or is retained as the fallback target DCS regulatory control PID · cascade · ratio · override — operator HMI and historian DeltaV · Experion PKS · CENTUM VP · System 800xA · PlantPAx Safety system SIS · ESD · fire & gas HIPPS Anti-surge & governor turbomachinery control surge control line · recycle Machinery protection vibration · temperature API 670 The process compressors · drivers · valves · transmitters UNCHANGED UNCHANGED UNCHANGED UNCHANGED Independent protection layer. No write path from OmniPath. OmniPath writes setpoints to the regulatory layer only. Protective functions are independent, unchanged, and retain full authority at all times. OmniPath supervisory optimization — unit staging, load split, speed and pressure setpoints
  1. Level 4Cloud trainingRL pipelines, model registry, signed artifact store. Delivers downward into the DMZ only.
  2. DMZSecurity DMZOne-way, signed-boot verification, auditable.
  3. Level 3 — supervisory · OmniPathOmniPathSupervisory optimization — unit staging, load split, speed and pressure setpoints. Supervisory cadence of seconds to minutes. Receives signed models from the DMZ; reads process data; writes setpoints down into the regulatory layer and nowhere else.
  4. Level 3 — where presentExisting APC / MPCCoexists with OmniPath, or is retained as the fallback target.
  5. Level 2 / 1 — unchangedDCS regulatory controlPID, cascade, ratio and override, with operator HMI and historian. DeltaV, Experion PKS, CENTUM VP, System 800xA, PlantPAx. Modules execute every 100 ms to 1 s. Receives setpoints and retains full manual override.
  6. Level 1 — independent · unchangedProtection layerThree independent functions, none of them connected to OmniPath: the safety system (SIS, ESD, fire and gas, HIPPS); anti-surge and governor turbomachinery control, working to the surge control line with recycle; and machinery protection for vibration and temperature per API 670. Protective response is 10–50 ms. There is no write path from OmniPath.
  7. Level 0The processCompressors, drivers, valves, transmitters.
OmniPath is the only layer in this diagram that is ours. Exactly one arrow leaves it, and it terminates in the regulatory layer — labelled setpoints only. The protection layer sits below a hairline with nothing connecting it to us: independent, unchanged, and holding full authority at all times.

What OmniPath does not do

We do not modify or replace your safety instrumented system. We do not modify or replace your anti-surge controller. We do not change your surge control line. We do not write to your ESD, fire and gas, or machinery protection systems. We do not require new safety-rated hardware. We do not require the regulatory control layer to be retuned. If your incumbent controllers were removed from service, OmniPath would have nothing to write to — that is the correct relationship.

Works with your existing stack

No controller firmware changes, no I/O changes, no safety system changes.

OmniPath reads from the historian and writes setpoints through OPC UA to Emerson DeltaV, Honeywell Experion PKS, Yokogawa CENTUM VP, ABB System 800xA, and Rockwell PlantPAx. Where an existing APC or MPC layer is present, OmniPath either coexists with it or is retained above it as the fallback target — the incumbent is never removed to make room for us.

Why the compute is at the station

Edge inference is usually justified by latency. That is not the reason here — a supervisory cycle of seconds tolerates a cloud round trip easily, and edge and cloud sit within a few thousand dollars a year of each other. There are three real reasons, and they compound.

The workload is a physics solver.

A dynamic formulation — one that accounts for line pack, batch interfaces and anticipatory staging — solves the network once per rollout step, not once per candidate. An 8-unit station with line pack is roughly 4.4 TFLOP per supervisory decision. A coordinated three-station liquids line is 104 TFLOP. On a CPU those are 88 seconds and 35 minutes respectively, which does not fit inside any usable cycle.

Calibration lives in high-rate local data.

A solver is only as good as its parameters, and they drift: friction factors, fouling, wear-ring clearance, and on liquids the density and viscosity that step-change at every batch interface. Keeping them current means continuous reconciliation against 1 Hz data. At the station that data is free. Shipping it costs real money on cellular and is impractical on satellite — and a model calibrated on twenty-minute-old data is solving the wrong pipeline once a batch interface has passed.

A cloud write path is a conduit worth avoiding.

A cloud-hosted optimizer writing setpoints requires a persistent bidirectional path from the internet into Level 3, on every cycle. Under IEC 62443 that is a conduit demanding continuous justification, and it is the trusted IT-to-OT pattern the TSA pipeline directives exist to prevent. One-way signed artifact delivery is a conduit a security review can approve.

Compute time per supervisory decision, edge GPU compared with CPU
Per supervisory decisionEdge GPUCPU
Gas, 8-unit station, 20-step horizon0.05 s4.8 s
Gas, 8-unit + line pack, 60-step horizon0.9 s88 s
Liquids, 6-unit station, batch tracking, 4 h1.6 s159 s
Liquids, 3-station coordinated line21 s~35 min

Scroll the table sideways for the CPU column →

The GPU is required where the stations are large and the lines are coordinated. On a two-unit station a CPU would do — and we will tell you that rather than sell you a box you do not need.

This is why the compute lives at the edge on a GPU, and it isn't about control frequency. A control loop with a real valve in it has about a second of dead time; running a policy at ten milliseconds buys nothing and wears out packing. What a GPU buys is depth of search per decision: at every supervisory cycle, OmniPath evaluates thousands of candidate staging and load-split trajectories against an ensemble of learned unit models under ambient and demand uncertainty, and returns the one with the lowest expected fuel cost and the lowest probability of approaching a constraint. That is a planning problem, and it is the one thing a DCS controller structurally cannot do.

Inside one decision

Full physics enumeration over the candidate space is not affordable at any station size. Screening it with a learned model and verifying only the shortlist is — about a thousand times cheaper, and it means every setpoint that leaves the box has been checked against a real model first.

Inside one supervisory decision A left-to-right funnel showing how one supervisory decision is computed at the station. It begins with 15,280 candidate operating plans, formed from 191 feasible staging vectors, 8 world-model ensemble members and 10 demand and price scenarios. These are screened in a single batched pass on the edge GPU against the learned surrogate model — the first of two filled blocks, marking where the GPU does its work. The screen narrows the field to the best 5 candidates, which are then verified on the edge GPU against the real hydraulic solver, the second filled block. Only a physics-verified plan proceeds to the shield and rate limits, which clamp it to the operator band, and then to a single setpoint written into the regulatory layer. A footer compares three approaches for a coordinated three-station liquids line: screen and verify takes 328 milliseconds on the edge GPU, full physics enumeration takes 21 seconds on the same GPU, and full enumeration on a CPU takes about 35 minutes, which does not fit a supervisory cycle. Inside one supervisory decision 15,280 candidate plans 191 feasible staging vectors × 8 ensemble members × 10 demand / price cases Edge GPU Surrogate screen every candidate, batched learned world-model ensemble ~60 GFLOP 5 best plans risk-ranked Edge GPU Physics verify real hydraulic solver, batched across the model ensemble locally calibrated, every cycle Shield & rate limits clamped to the operator band, slew-limited, watchdogged One physics-verified setpoint written to the regulatory layer Why it runs at the station The solver is only as good as its parameters — friction factors, fouling, wear, and on liquids the density and viscosity that step-change at every batch interface. Calibration needs high-rate local data. A model calibrated on twenty-minute-old data is solving the wrong pipeline. Coordinated 3-station liquids line, per decision Screen and verify: 328 ms on the edge GPU · full physics enumeration: 21 s · on a CPU: ~35 min
  1. Screen — every candidate plan evaluated on the learned world-model ensemble in one batched GPU pass. On an 8-unit station that is roughly 15,280 plans: 191 feasible staging vectors, across 8 ensemble members and 10 demand and price scenarios.
  2. Verify — the best five verified against the real hydraulic solver, batched across the ensemble, using parameters reconciled from local high-rate data. A candidate that fails verification is discarded.
  3. Clamp and write — the surviving plan is clamped to the operator band, slew-limited and watchdogged before a single setpoint reaches the regulatory layer. The verification result is logged with the action, and it is a pilot deliverable.
The two filled blocks are where the edge GPU earns its place. Everything else in this diagram is bookkeeping — the compute is the physics.

Cloud to edge

Training is central, inference is local, and the path between them is one-way and signed.

Cloud / AWS

  • Model training (RL/ML pipelines)
  • MLOps registry & CI/CD
  • Secure artifact store (S3/ECR)

DMZ

  • Validation & security gateway
  • Compliance & monitoring checks
  • Air-gapped staging for edge-ready models
  • Novel signed-boot model verification

Edge

  • Batched physics at the asset on an NVIDIA Jetson Orin edge GPU — thousands of candidate plans screened against a learned model, the shortlist verified against the real hydraulic solver, per supervisory decision
  • Ruggedized edge compute (NVIDIA Jetson Orin class) installed in the safe-area or Division 2–rated control building, outside the classified envelope — hardware selected per site electrical area classification
  • Local setpoint optimization + digital twin integration
  • Continuous model reconciliation against local high-rate data — friction factors, fouling, density and viscosity — so the solver stays calibrated to the pipeline as it is today

Resilient

Ruggedized Orin hardware built for harsh industrial environments, and no dependency on connectivity in the decision path. Loss of WAN costs model updates, never optimization.

Secure & Compliant

DMZ ensures one-way, auditable, signed-boot model deployment — aligned with OT/ICS security standards.

Scalable

Cloud-to-edge MLOps enables model updates without downtime.

Standards and change management

The documentation your security review will ask for is a pilot deliverable, not an afterthought.

Deployment follows IEC 62443 zone and conduit segmentation, with the edge node in its own zone behind an authenticated one-way conduit. Setpoint-writing scope is documented for management of change under the IEC 61511 / ISA 84 safety lifecycle. Architecture is designed to sit inside operators' TSA pipeline security directive obligations.

What the platform is

Moved off the homepage. The outcome is assets that are continuously re-optimized as conditions change, inside authority limits you set.

Adaptive Deep Reinforcement Learning Models

We train intelligent control models — per component, per site — that learn optimal responses to dynamic environments, reducing downtime and optimizing performance without frequent manual retraining.

Full-Fidelity 3D Collaboration & Visualization

Built on NVIDIA Omniverse and the OpenUSD standard: immersive, multi-user environments for engineering, analysis, and decision-making driven by live or simulated data.

Edge / DMZ Deployment

Signed models delivered through a security DMZ to edge GPUs, so the optimizer evaluates thousands of candidate operating trajectories per decision — locally, at the asset, with no cloud dependency in the control path.

Physics-Grounded Digital Twins

High-fidelity physics simulation — thermodynamics, fluid dynamics, and mechanical behaviour — grounds every agent in how the asset really works, not just how it was labelled.

Where OmniPath applies

Unlike legacy digital twins (static models, costly manual maintenance) and generic ML platforms (limited physics, no control actions), OmniPath delivers automated builds with physics + DRL out of the box — adaptive, edge-ready, and open-source hybrid.

Failure modes, MOC scope and data requirements — the controls-engineer FAQ →

Book a pilot call →