Why process design data should stay on your own servers

A process design package is more than drawings. It is the most complete description a company has of how it makes money: reaction conditions, conversion and yield, heat integration, equipment sizes, control philosophy and the reasoning behind each choice.

That is why the question of where design software runs is not an IT detail. It decides who can see that description, and under what terms.

What sits inside a design package

A typical package built from DOE through to detailed design contains:

• Experimental data and the response models fitted to it
• Simulation cases with full stream compositions, temperatures and pressures
• Process flow diagrams with heat and material balances
• P&IDs, instrument lists and control narratives
• Equipment datasheets and sizing calculations

Anyone holding this set can reproduce, or improve on, the process. Many licensors and clients write that into contracts: technology licence and confidentiality agreements commonly restrict where the data may be stored and who may process it.

What changes when data leaves the site

Sending design data to an external service is not automatically unsafe. But it changes three things.

Control of access. Your data now sits in systems your IT team does not administer, protected by policies you did not write.

Control of retention. Once uploaded, it can be hard to prove when, or whether, every copy has been deleted.

Exposure to someone else's incidents. A breach at a provider becomes your problem, even if your own network was never touched.

Some sites remove the question entirely: plant and engineering networks are often isolated from the internet, and software that needs an outbound connection simply cannot run there.

What "on-premise" should actually mean

The term gets stretched. For design software, it should mean all of the following:

| Question | What to look for | |---|---| | Where does it run? | On hardware your organisation controls | | How do engineers reach it? | A browser on your internal network | | Does it call home? | No outbound connection needed to work | | How do updates arrive? | As packages your team installs when it chooses | | How is it licensed? | A licence tied to your organisation, not to a cloud account |

If any answer depends on "a small amount of data" being sent out, the software is not fully on-premise.

The honest trade-offs

Running software yourself has costs. Your IT team maintains the server. Updates are deliberate rather than automatic, so someone has to schedule them. Hardware has to be sized for the workload.

For most process companies these are familiar costs, the same ones they already accept for plant historians and control systems. The alternative, handing the most valuable data they own to a third party, is usually the harder sell to their own leadership.

How Ardsol approaches it

Ardsol is built on-premise first. It ships as an installer for your own server, engineers use it from a browser on your network, and process data, simulations and drawings stay inside it. Updates arrive as offline packages, and each installation is licensed to your organisation.

If you are assessing design software for a site with strict data rules, talk to us about your environment.