Advanced process control keeps a unit stable and pushes against operating constraints, but it has no concept of which constraint is actually worth pushing against on any given day. That question — given today's crude assay, today's product prices, and today's equipment availability, what is the single most profitable combination of setpoints across every unit — is what Real Time Optimization exists to answer. RTO sits one layer above APC in the control hierarchy, using a rigorous nonlinear process model and an economic objective function to recalculate optimal setpoints as market and operating conditions shift, then hands those targets down to the APC layer to execute. Done well, RTO captures margin that APC alone structurally cannot reach because APC optimizes unit stability and constraint-pushing, not cross-unit economic trade-offs. Done poorly — with a stale model, unreliable data reconciliation, or an objective function nobody has revisited in years — RTO becomes expensive software that operators quietly route around. iFactory AI's RTO framework is built to keep the model, the data, and the economics aligned so the optimization layer keeps earning its place in the control hierarchy.
Where RTO Sits in the Control Hierarchy — and Why That Position Matters
RTO and APC solve different problems even though they're often discussed together. APC operates on a timescale of seconds to minutes, using dynamic process models to hold the unit stable and push manipulated variables toward constraints the optimizer has already decided are worth approaching. RTO operates on a timescale of hours, using a steady-state rigorous model — typically containing thousands of equations describing thermodynamics, kinetics, and equipment performance — to determine which constraints across the entire unit, or even across multiple interconnected units, deliver the most profit when pushed. Where APC pushes material and energy balances to increase feed and preferred products within one unit, RTO can trade yield, recovery, and efficiency among entirely different pieces of equipment by re-solving the economic optimization problem as conditions change. Book a Demo to see how the hierarchy applies to your specific unit configuration.
Building the Two Models RTO Actually Depends On
Every RTO problem rests on two distinct models working together, and the optimization is only as good as the weaker of the two. iFactory's framework treats both as living components that require ongoing attention, not a one-time build at commissioning.
The Rigorous Operating Model
A nonlinear steady-state process model describing the thermodynamics, kinetics, and equipment behavior of the unit, often built within equation-oriented modeling platforms containing thousands of equations. The model's constraints define what is physically and operationally feasible.
The Economic Objective Function
The function the optimizer maximizes or minimizes — typically a margin calculation built from current product prices, feed costs, and utility costs. An objective function running on stale pricing data will optimize toward a target the market has already left behind.
Steady-State Detection
Before any optimization run, the system must confirm the unit is actually at steady state — running an RTO calculation against transient data produces a recommendation that doesn't reflect real plant conditions and can drive setpoints in the wrong direction.
Data Reconciliation and Gross Error Detection
Raw plant measurements contain random noise and occasional gross errors from failed instruments. Data reconciliation adjusts measurements to satisfy mass and energy balances, while gross error detection flags instruments whose readings are unreliable before they corrupt the optimization.
Setpoint Calculation and Handoff to APC
Once the model is reconciled and the economics are current, the optimizer solves for the most profitable feasible setpoints and passes them down to the APC layer, which executes the transition while respecting dynamic constraints. Book a Demo to see this handoff modeled against your unit.
Mapping RTO Capabilities to Financial Outcomes
Every RTO capability exists to close a specific economic gap between current operation and the actual optimum. The matrix below outlines how each core function translates into margin capture across the refinery. Book a Demo for a custom RTO assessment of your unit.
| RTO Capability | Operational Function | Financial Impact | Target Beneficiary |
|---|---|---|---|
| Rigorous Process Model | Captures unit thermodynamics, kinetics, and equipment limits | Identifies feasible setpoints APC alone cannot evaluate | Process Engineers |
| Data Reconciliation | Adjusts noisy measurements to satisfy mass/energy balances | Prevents optimization on corrupted or unreliable data | Instrumentation & Control Teams |
| Gross Error Detection | Flags failed or drifting instruments before optimization runs | Avoids setpoint recommendations based on bad readings | Reliability Engineers |
| Economic Objective Refresh | Updates margin targets against current prices and feed costs | Keeps the optimizer chasing today's margin, not last year's | Refinery Economics & Planning |
| Cross-Unit Trade-Off Analysis | Evaluates yield and recovery trades between separate units | Captures margin invisible to single-unit APC optimization | Plant Managers |
Closed-Loop RTO: Where the Margin Gets Real, and Where the Risk Lives
Open-loop RTO presents recommended setpoints to an operator for review and manual implementation. Closed-loop RTO sends those setpoints directly to the APC layer without operator intervention between calculation and execution. Closed-loop deployment captures more of the available margin because it acts on every optimization cycle rather than only the cycles an operator chooses to action — but it also removes the human checkpoint that would otherwise catch a bad model output, a missed gross error, or an objective function running on stale pricing before it reaches the plant.
A closed-loop RTO system that pushes a setpoint change based on a corrupted measurement or an unreconciled model can drive a unit toward an infeasible or unsafe operating point before anyone notices. This is why robust steady-state detection, rigorous data reconciliation, and gross error detection are not optional refinements — they are the gating logic that determines whether closed-loop RTO is a margin engine or a liability. Refineries that skip this gating logic in pursuit of faster deployment consistently see the program quietly disabled by operations within the first year. Book a Demo to see how the gating logic is structured.
Budget Leakage: Where Underused RTO Programs Lose Margin
When auditing a refinery's optimization program, the most common finding is not that RTO failed to deliver value at commissioning — it's that the value eroded over time as the model, the data quality, and the economics drifted apart. These are the specific areas where margin leaks out of an existing RTO program.
"We had RTO running on our hydrocracker for years, but nobody could tell us whether it was still earning its keep. Once we audited the data reconciliation layer, we found three flowmeters feeding the model with readings nobody had cross-checked in over a year. Fixing the data quality and refreshing the objective function against current pricing recovered the majority of the margin we'd quietly lost without anyone noticing the decline." — Process Optimization Manager, Independent U.S. Refiner
Conclusion: RTO Earns Its Place Only When the Model Stays Honest
Real Time Optimization is not a feature you turn on once and forget — it is a continuous discipline of keeping a rigorous process model, a clean reconciled dataset, and a current economic objective function all pointed at the same target. When those three elements stay aligned, RTO finds margin that APC structurally cannot reach because it is solving a fundamentally different problem: not how to keep one unit stable near a constraint, but how to allocate yield, recovery, and efficiency across the entire economic picture of the refinery. When any one of those elements drifts — a stale price assumption, an unreconciled flowmeter, a model nobody has recalibrated since a catalyst change — the optimization quietly stops representing reality, and the program either drifts toward unsafe recommendations or gets quietly disabled by operators who no longer trust it.
iFactory AI's RTO framework is built around keeping that alignment continuous rather than treating it as a one-time deployment milestone — connecting data reconciliation quality, model accuracy, and current market economics into a single view so the optimization layer above APC keeps delivering the margin it was built to find.
Frequently Asked Questions: Real Time Optimization
What's the difference between RTO and APC?
APC uses dynamic models to keep a unit stable near its constraints on a seconds-to-minutes timescale. RTO uses a steady-state rigorous model and an economic objective function to recalculate the most profitable setpoints on a timescale of hours.
Why does RTO need data reconciliation before it can run?
Raw measurements contain noise and occasional instrument errors that violate mass and energy balances; reconciliation corrects for this so the optimizer isn't solving against corrupted data.
What's the difference between open-loop and closed-loop RTO?
Open-loop RTO presents setpoint recommendations for operator review; closed-loop RTO sends them directly to the APC layer without manual approval, capturing more margin but requiring more rigorous data gating.
How often does the economic objective function need to be updated?
Product prices and feed costs should be refreshed regularly enough to reflect current market conditions — an objective function running on outdated pricing optimizes toward a target the market has already moved away from.
Can RTO be deployed across multiple interconnected units at once?
Yes — one of RTO's core advantages over single-unit APC is its ability to trade yield, recovery, and efficiency across separate but interconnected process units within the same economic optimization problem.
