Refinery Planning and Blend Optimization Software: Why the Plan and the Tank Never Agree

Why the plan is right and the blend is still wrong

The planning and economics manager builds the month in PIMS: crude slate chosen, unit yields modelled, margin per barrel agreed with the commercial team. Two weeks later a blender on nights is filling tank 214 with regular gasoline. The recipe on his screen came from the plan. The reformate tank has drifted a point and a half in octane since the last certificate of analysis, the butane line is running warmer than usual, and he has one number in his head that matters more than any of it: he is not going to be the person who makes an off spec batch. So he trims the recipe. A little more reformate, a little less naphtha. The blend certifies at 88.4 research octane against an 87 minimum and it ships.

That 1.4 is quality giveaway and it is invisible in the plan. The plan says the blend hit 87. The lab says 88.4. Nobody reconciles the two because they live in different systems and different departments. Multiply a few tenths across every blend in a month and the number gets serious in a business where margin is quoted per barrel.

The stack around this is usually AspenTech PIMS or Haverly for the LP, a scheduling tool or a large spreadsheet for movements, a tank gauging system, a LIMS holding lab results, a DCS with some online analysers, and Honeywell or AVEVA software on the blend headers if the site invested there. Each is competent inside its own boundary. None owns the object that matters: a specific blend event with its planned recipe, its actual draws, the real properties of the tanks it drew from, the resulting certificate and the giveaway against spec. That object exists in no system, which is why nobody manages it.

Problem 1: the LP is a monthly economic model, not a Tuesday night instruction

PIMS and Haverly do what they were built for extremely well: choose a crude slate, set unit targets, evaluate a purchase. They work in periods and averages. Blending happens in events, against specific tanks, with specific heels, at a specific temperature, on a specific night.

The gap is structural rather than a vendor failing. An LP that assumed reformate at a pool average octane cannot tell the blender what to do when the actual tank is a point off, and the LP will not be rerun for one blend. So the site fills the gap with a spreadsheet and an experienced operator, and the operator solves for safety rather than economics, exactly as any sensible person would when the downside is a reprocessed tank and an unhappy commercial team.

What a custom build does: a blend layer that sits between the plan and the control system. It takes the plan targets as constraints, pulls current measured properties for each component tank from LIMS and any online analyser, applies proper blending behaviour where properties are non linear, and solves for the cheapest recipe that meets spec with a defined confidence margin. Octane does not blend linearly and vapour pressure blends by index rather than by volume, so a naive linear recipe is wrong before the pump starts. The output is a recipe the blender can accept, plus an explicit statement of what margin it is carrying and why.

Problem 2: giveaway is created by uncertainty, so measure the uncertainty

A blender pads the recipe because the property data is old. If reformate was last sampled 40 hours ago and the unit has been swinging, padding is rational. The way to reduce giveaway is not to tell operators to stop padding. It is to make the padding smaller by shrinking the uncertainty and making it visible.

What a custom build does: track property age and confidence per tank alongside the value. Show the blender that reformate octane is measured, four hours old, and stable across the last three samples, so the required margin is two tenths rather than a point. Where the site has online near infrared analysers on the blend header, feed them back mid blend and re optimise the remaining volume, which is the single most effective giveaway control in the plant. Without analysers, close the loop afterwards: every certificate corrects the property model for that stream, so next month it is less wrong. In our delivery experience the reporting alone changes behaviour, because giveaway that is measured per blend and per blender stops being invisible.

Problem 3: tank inventory truth is worse than anyone admits

Blending assumes you know what is in the tank. The reality includes heels of the previous grade, water bottoms, stratification after a slow fill, a gauge that reads differently from the manual dip, and the component tank someone drew from during a swing without telling the scheduler.

Movement scheduling tools and the LP both assume clean inventory. Nothing in a standard stack reconciles book inventory against gauges continuously, so discrepancies accumulate until month end and are written off as measurement loss. That write off is where blend errors hide.

What a custom build does: a movements ledger that records every transfer, tank to tank, unit to tank, tank to ship or rack, with source, destination, volume, temperature correction and the properties carried across. Book inventory is derived from the ledger, gauge readings are reconciled against it on a schedule, and a drift beyond your tolerance raises an exception the same day rather than at month end. Off spec and quarantined tanks are first class states, so nothing can be drawn from a quarantined tank into a blend, which is a mistake most sites have made at least once.

Problem 4: regulatory specs are not just numbers on a spec sheet

Fuel specifications in the United States include obligations that are annual and portfolio wide, not just per batch. Tier 3 gasoline carries a 10 parts per million annual average sulfur standard with a per batch cap above it, 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.

An LP can carry these as constraints in aggregate. A blend control system enforces the batch limit. What falls between them is the running position: whether the sulfur average you are carrying so far this year gives you room to blend a cheaper high sulfur component tonight or whether you have already spent that room. Sites track this in a spreadsheet updated monthly, which is far too coarse for a decision made nightly.

What a custom build does: hold the running compliance position as live state, updated with every certified batch, and expose it as a constraint to the blend optimiser. The blender then sees how much annual room the site has left, which turns a compliance chore into an economic input. Have your own compliance team confirm the position, then encode it.

Problem 5: the plan is never scored, so it never improves

Almost no refinery compares what the plan said the month would earn against what the movements and certificates say it actually earned, in enough detail to identify where the difference came from. Feedstock, unit performance, blend giveaway, demurrage and off spec reprocessing all collapse into one variance number that the planning team explains in a meeting. A build that attributes the gap by blend, by component and by day separates the giveaway line from the yield line, and the argument about where margin went becomes a report instead of a debate.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this category takes a specific shape. A first release at $90,000 to $200,000 in 14 to 20 weeks covers the blend optimisation layer, live component property tracking from LIMS, giveaway measurement per blend and reconciliation reporting back against plan targets. That is a system your blenders use on the next shift, not a study. The full platform, adding the movements ledger and tank reconciliation, movement scheduling, analyser feedback and mid blend re optimisation, regulatory position tracking and crude evaluation support, runs $250,000 to $600,000 phased over 9 to 18 months.

What drives cost up in refinery planning and blending work:

• The number of blended products and grades, since every product has its own property set and correlation behaviour.
• LIMS integration, which varies enormously depending on whether you run LabWare, SampleManager or something bespoke, and how consistently sample points are named.
• Online analyser feedback and any write path toward the blend control system, which brings the control engineers and their change management into scope and should.
• Property correlation work for non linear properties, which is real engineering rather than software and often needs your own process engineers alongside ours.
• Multiple sites or a terminal network, where movement rules and custody transfer differ per location.

What keeps cost down: start with your highest volume blended product and one giveaway property. Gasoline octane or diesel cloud point usually pays for the whole first release on their own.

Build versus buy, and where the commercial tools genuinely win

Do not build a replacement for AspenTech PIMS or Haverly. The economic LP is decades of embedded modelling and you will not beat it, nor should you want to. If your problem is crude selection or monthly economics, buy, and buy the mainstream option.

If you have a fully commissioned Honeywell blending and movement installation with analysers feeding it and operators trusting it, your gap is probably reporting rather than optimisation, which is a much smaller project.

Build when two or more of these are true. Your blenders routinely trim recipes by hand and nobody measures the trim. Your component property data is old enough at blend time that padding is rational. You have no single record joining a blend event to its actual draws, its certificate and its giveaway. Your annual sulfur or vapour pressure position lives in a spreadsheet updated monthly while blend decisions are made nightly. Your planning variance meeting cannot separate giveaway from yield.

The tipping point 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 it, and disciplined lab scheduling plus better reporting is the cheaper answer. Above it, tenths of a unit compound into real money every single day, and the coordination between plan, lab and tank becomes the actual margin lever.

How to choose a developer for refinery planning and blending software

Ask them to explain how they would blend vapour pressure. If the answer is a volume weighted average, they have never done this and your recipes will be wrong in a way that quietly reintroduces giveaway. The correct answer involves blending indices, and a developer who knows that has sat with a process engineer before.

Ask how they treat property uncertainty. A build that carries a single number per property, with no age or confidence, cannot reduce padding, which is the entire point of the exercise. The data model should carry measured value, source, timestamp and confidence.

Ask what they have actually integrated in a plant environment. LIMS, tank gauging, the historian, and any path toward blend control are four different problems with four different failure modes. Names and versions, not the word integration.

Insist that your process engineers are in the room during design. A developer working alone will build something plausible and wrong, because the correlations and constraints are your knowledge and the build exists to encode them.

Ask who owns the code and get it written down before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit, and given how specific this modelling is to your site, owning it is not a formality.