One pilot-scale methanol-to-jet reactor campaign produces approximately 240 to 280 measured variables in each production cycle. Running 14 production cycles yields roughly 80,000 to 100,000 data points. Generic distributed control system software records all of them. It does not show which variables explain most yield variance or recommend parameter changes for the next cycle.
We designed our software for the space between collecting data and providing usable process guidance. This article sets out the requirements we identified, where conventional DCS falls short in this application, and the three priorities that guided what we built.
What Generic DCS Software Handles Well
We are not discounting conventional process control systems. A properly configured DCS delivers dependable setpoint control, alarm handling, historian logging, and an operator interface. Those functions can suffice for steady-state operation of a well-characterized process. Most commercial chemical plants rely on DCS infrastructure refined over decades, for good reason.
In methanol-to-jet production, the DCS performs its intended tasks: holding temperature setpoints within a defined band, regulating feed rate, managing pressure, and alarming when parameters leave range. That is the proper role of a control system, and it performs it reliably.
The limitation emerges with questions outside the DCS's design brief. Which operating-condition combination across the last 14 production cycles delivered the highest C9 to C14 selectivity? How did yield change during the 6 hours after a feed rate adjustment? Does rising pressure drop in stage 2 indicate early catalyst deactivation, or does it remain within normal variation? A DCS historian can present raw data for a process engineer. It cannot automatically analyze those data and turn the result into a recommendation for the next run.
The Interdependency Challenge in MtJ
Methanol-to-jet production is harder for generic process control because its three reaction stages are tightly linked. The composition leaving the MTO stage feeds oligomerization, while oligomerization selectivity determines the feed entering hydrogenation. Optimizing stage 1 therefore changes the constraints on stages 2 and 3.
Because the stages interact, changing one setpoint at a time and measuring the result is a slow, incomplete optimization method. The MtJ response surface includes cross-stage effects that univariate analysis misses. Raising MTO temperature may improve initial olefin yield but reduce oligomerization selectivity if the olefin distribution shifts toward shorter chains that are less suitable for the next step.
To understand cross-stage effects, we need multivariate analysis of campaign history alongside a physical model of the links between stages. That is not a DCS historian query. It is a modeling task requiring another kind of tool.
Campaign History as a Learning Asset
Every completed production cycle is a structured experiment, whether planned that way or not. Its operating conditions, setpoint deviations, yield, and quality results create a dataset describing the process response surface.
After one or two cycles, the dataset is too small for useful statistics. With 10 to 20 cycles in a reasonably consistent operating regime, patterns start to appear. At 40 to 50 cycles with deliberate operating-condition variation, the model covers enough of the operating space to predict conditions it has not directly encountered.
Software using this history must separate signal from noise. Measurements include sensor error, feedstock variation, and transient effects outside the underlying process model. Simple pattern matching on noisy campaign data gives unreliable recommendations and quickly weakens operator trust. The statistical method must explicitly represent measurement uncertainty and process variability rather than treating every data point as equally informative.
Three Design Priorities
Our analysis of MtJ production produced three software design priorities.
Priority 1: Campaign-specific modeling. Data from another reactor geometry, catalyst formulation, or feedstock composition cannot transfer without retraining. Reactor characteristics such as heat distribution, packing-density variation, and local flow patterns are specific to the hardware. Literature models can provide physical priors, but not deployable process models. Each installation must learn from its own campaign history.
Priority 2: Explainability at the recommendation layer. Process engineers will not use an optimizer that gives a setpoint without explaining its basis, since they must apply professional judgment before accepting it. The system must identify the historical data points and variable interactions behind each recommendation in terms an engineer can assess against reactor state and feedstock batch characteristics.
Priority 3: DCS-agnostic integration. Methanol-to-jet facilities use control platforms from multiple vendors. The software must read from existing infrastructure and write setpoint recommendations to it without replacing the DCS, an excessively disruptive and costly step for an operating facility. We standardized on OPC-UA because all major DCS and historian platforms support it, and it supplies the data types and timestamp precision needed for run-history analysis.
Integration in Practice
An OPC-UA client reads historian data from the plant DCS at configurable polling intervals, passes it to the process model, and returns recommended setpoints to the DCS as advisory values. The operator sees a suggested change with confidence bounds and a short explanation citing supporting historical runs, then confirms or rejects it before implementation.
We deliberately selected an advisory model instead of closed-loop automated control. During current pilot validation, the recommendation model is still gathering campaign history, and confidence bounds are wide for novel operating conditions. Process-engineer judgment about catalyst state, feedstock batch variation, and maintenance history also includes information absent from sensor data. Closed-loop automation would discard that judgment; the advisory model retains it.
The advisory approach is also easier for process engineers to accept. A system that explains its suggestions is simpler to assess and trust than one acting autonomously. Confidence grows when accepted recommendations produce their predicted outcomes. This is the appropriate sequence for introducing the tool into an operating facility.
What We Are Not Replacing
We are not saying process engineering judgment can be automated away; we are saying it remains essential. In our first pilot campaign, an experienced process engineer identified a temperature-zone anomaly while reading historian data. The software flagged it, but the decision to check thermocouple calibration before changing setpoints required engineering judgment the software could not make.
In this domain, process control software manages information complexity and speeds learning; it does not replace process engineering expertise. A pilot-scale MtJ facility's 280 variables across 14 production cycles contain more information than a person can comfortably analyze manually and quickly. The software finds patterns, while the engineer interprets them using knowledge of the process and equipment.
Our intended division of labor is clear: software recognizes patterns and compresses information; the engineer supplies context and assesses process risk. That arrangement is deployable in the near term, before campaign history is deep enough to support high-confidence autonomous recommendations for new operating conditions.
We are not trying to replace process engineers. We want each campaign to teach us more than the previous one, allowing a new MtJ facility to learn faster than unguided trial and error would allow.