Refinery Planning and Blending Software Problems: The 7 That Cost Real Money and How to Avoid Them

Why does the plan to replace the planning model happen so often?

The biggest scope failure in this category is a project that starts as blend execution and grows into a replacement for the economic linear program. It happens because the two look adjacent on a slide. Planning chooses the crude slate and sets unit targets, blending turns those targets into a recipe, and someone reasonably asks why they are separate systems.

They are separate because they answer different questions on different timescales. AspenTech PIMS and Haverly carry decades of embedded economic modelling for crude selection and monthly planning, working in periods and averages. Blending happens in events, against specific tanks with specific heels, at a specific temperature, on a specific night. An estimate that quietly includes rebuilding the economic model will be wrong by a large multiple, and the result will be worse than the tool you already own.

The fix is a boundary agreed before anyone quotes. The linear program stays and continues to set the targets. What you build is the layer beneath it: a blend optimiser that takes plan targets as constraints, reads measured component properties rather than pool averages, respects real tank and header constraints, and returns a recipe with an explicit statement of the margin it carries. If a proposal describes replacing the planning model as a phase, ask what it adds beyond what PIMS already does, and expect the answer to be thin.

What goes wrong when tank and laboratory data is brought in?

Every blend build depends on two data sets that are messier than anyone admits before the project starts: what is physically in each tank, and what its properties actually are.

Tank truth is compromised by heels of the previous grade, water bottoms, stratification after a slow fill, temperature correction, a gauge that reads differently from the manual dip, and the component tank somebody drew from during a swing without telling the scheduler. Most sites reconcile at month end and write the difference off as measurement loss, which means blend errors have somewhere to hide for four weeks.

Laboratory data is compromised differently. Sample point naming in the laboratory information management system, whether that is LabWare, SampleManager or something bespoke, is rarely consistent enough to join automatically to a tank. The same physical draw point may appear under three names accumulated over a decade of shift habits, and nobody has needed them reconciled until now.

The fix is to do the reconciliation as explicit project work rather than as a mapping table produced in a hurry. Build a movements ledger recording every transfer with source, destination, volume, temperature correction and the properties carried across, derive book inventory from it, and reconcile against gauges on a schedule so drift beyond tolerance raises an exception the same day. Make quarantined and off spec tanks first class states so nothing can be drawn from one into a blend. And budget time for a laboratory technician and a process engineer to agree the sample point mapping, because a wrong mapping puts the right number on the wrong tank, which is worse than no number at all.

Why do the plant integrations break after launch?

Four connections carry a blend system, and each has its own failure behaviour once the plant is running normally rather than during a quiet commissioning window.

The laboratory system breaks when a result arrives late or is revised. A certificate corrected the following morning has to propagate to anything that used the earlier value, and a build that treats laboratory results as immutable facts will show a recipe justified by a number that no longer exists.

The historian breaks on tag changes. Instrumentation gets replaced, tags get renamed during a turnaround, and a system reading tags directly starts returning stale values without failing loudly. Every reading needs an age, and a value older than its tolerance should degrade the confidence rather than be presented as current.

Online analysers break on availability. Near infrared analysers on the blend header are the single most effective giveaway control available, and they are also equipment that drifts, gets taken out for calibration and occasionally disagrees with the laboratory. The system needs an explicit policy for what happens when the analyser and the certificate disagree, decided by your process engineers, not inferred by a developer.

Any path toward blend control breaks on change management, which is correct and should be planned for. Writing anything toward a distributed control system brings control engineering, their testing regime and their approval cycle into scope. Sites that budget this as a line item ship. Sites that assume it is an interface discover it during commissioning.

What happens when the annual compliance position is not covered?

Fuel specifications include obligations that are portfolio wide rather than per batch. In the United States, Tier 3 gasoline carries an annual average sulfur standard with a higher per batch cap, and highway diesel is capped at 15 parts per million sulfur. Vapour pressure limits change seasonally by region. Renewable fuel obligations are accounted separately again.

The planning model can carry these in aggregate and the blend control system enforces the batch limit, so builds routinely leave out the piece in between: the running position. Whether the sulfur average carried so far this year gives you room to blend a cheaper high sulfur component tonight, or whether that room has already been spent, is a decision made nightly against a spreadsheet updated monthly.

Leaving this out has two costs. The obvious one is compliance exposure late in the year, when the room turns out to be gone and the remaining blends have to be made from expensive components. The less obvious one is the room you never used, because nobody knew it was there, which is margin left in the tank all year.

The fix is to hold the running position as live state, updated with every certified batch, and expose it to the optimiser as a constraint. The blender then sees how much annual room remains and it becomes an economic input rather than a compliance chore. Have your own compliance team confirm the position and the calculation basis before it is encoded, since the detail depends on your registrations and your product slate.

Should you build custom or configure what you already own?

Some refineries should not build, and the honest test is scale times frequency. Below roughly 30,000 barrels a day of finished blending, the giveaway a system recovers may not clear the cost of building and running it. Tighter laboratory sampling schedules plus a simple report showing certified results against specification for every blend will capture most of the available benefit, and that report can be built in weeks rather than months.

Configuring what you own is also right if you already have a fully commissioned Honeywell or AVEVA blending and movement installation with analysers feeding it and operators who trust it. In that case the gap is almost always reporting and reconciliation rather than optimisation, which is a far smaller project. Similarly, if the question you actually want answered is about crude selection or monthly economics, that belongs in PIMS or Haverly and should stay there.

Build when two or more of these hold. Blenders routinely trim recipes by hand and nobody measures the trim. Component property data is old enough at blend time that padding is rational. No single record joins a blend event to its actual draws, its certificate and its giveaway. The annual sulfur or vapour pressure position lives in a spreadsheet updated monthly while blend decisions are made nightly. Or the planning variance meeting cannot separate giveaway from yield, so the same argument repeats every month with no evidence on either side.

How do hidden costs get into the quote?

Estimates in this category move in a small number of well known places.

• Property correlation work. Getting non linear blending behaviour right is process engineering rather than software, and it needs your own engineers alongside the developer. Quotes that do not reserve their time are quoting half the job.
• Laboratory system integration. The variance here is enormous depending on the product, its version and how consistently sample points have been named over the years.
• Grade count. Every blended product has its own property set and its own correlation behaviour, so the second and third grades are real work rather than configuration.
• Any write path toward blend control. This brings control engineering change management into scope, correctly, and it should be a named line with their approval cycle in the schedule.
• Multiple sites or a terminal network. Movement rules and custody transfer differ per location, so a second site is not a copy of the first.
• Parallel running. Blenders will run the recommendation alongside their own judgement for a period and challenge it, which is exactly what you want and is also weeks of engineering time responding to objections.

What separates a build that works from one that fails here?

The builds that work encode uncertainty rather than hiding it. Every property carries a measured value, a source, a timestamp and a confidence, and the recipe states the margin it is carrying and why. That is what shrinks padding, because a blender who can see that reformate octane was measured four hours ago and has been stable across three samples will accept a smaller margin than one working from a number with no age on it.

They also close the loop. Every certificate corrects the property model for that stream, so next month is less wrong, and giveaway is measured and reported per blend. In our delivery experience the reporting alone changes behaviour, because giveaway that becomes visible stops being free.

The builds that fail are designed without process engineers in the room. A developer working alone produces something plausible and wrong, since the correlations and constraints are your knowledge and the whole purpose of the system is to encode them. The second failure pattern is a recommendation with no explanation: a recipe that arrives as a number, with no statement of which constraint bound or what margin it carries, gets overridden on the first shift and every shift afterwards.

Two tests before signing. Ask how they would blend vapour pressure, and listen for blending indices rather than a volume weighted average. Ask what they have integrated in a plant environment by name and version, covering the laboratory system, tank gauging, the historian and any path toward blend control, since those are four different problems with four different failure modes. Then settle ownership of the code and the correlations in writing, because this modelling is specific to your site and owning it is not a formality.