The Flow Historian Simulator

What it is for#

Learning. Every tutorial in this knowledge base can be worked through against the simulator, with no historian and no plant.

Demonstrations. A model built on the simulator runs anywhere. It can be exported and imported into any instance and will work immediately, because its data source travels with the product.

Testing modelling patterns. Prove an OEE calculation, a Pareto analysis, or a template fleet against simulated data before the real tags exist. This is particularly valuable during a project's design phase, when the plant network is not yet available.

Proving an installation. Because it needs nothing external, a working simulator connection proves the plugin framework, the engine, and the deployment chain are all functioning. It is the cleanest first test after installing Infohub.

Setting it up#

Create a connection of type Flow Historian Simulator. Its tag definitions come from a file installed with the product:

%ProgramData%\Flow Software\Flow\Config\Simulator

The defaults are correct for a standard installation, so in practice you name the connection, save it, and browse the tags.

What it simulates#

The shipped configuration models a juice factory — boilers, mixers, fillers, water, and power. The signals are shaped rather than random, which is what makes it useful: temperatures follow heating and cooling curves, totalisers climb continuously, and machine states cycle through realistic sequences.

The tag set covers the shapes a real model needs.

Analog process values — temperatures, pressures, flows, and levels, spread across several instruments so a model can have more than one of each:

Totalisers — registers that only ever climb, so you can practise the Counter aggregation properly:

State tags — discrete values for event triggers, state widgets, and enumerations:

That state tag is worth knowing about, because the distinct fault codes make it possible to build a genuinely realistic downtime Pareto — separate fault reasons, not one undifferentiated "stopped".

Building a realistic demonstration model#

The approach that works:

1. Decide the plant structure — areas, lines, equipment — and build the folder tree for it.
2. Map each measure you need to a simulator tag of the right shape. A kiln temperature gets a temperature tag; a clinker totaliser gets an integrator; a mill running state gets a state tag.
3. Build proper chains — Tag to Hourly to Daily, Counter on the totalisers, Sum above them.
4. Add the calculations that make it a real model: efficiency, specific consumption, utilisation.
5. Add event schemes on the state tags, so you get runs and stoppages with attributes.
6. Build the charts and dashboards an operator would actually want.
7. Deploy and let it run for a day or two so the aggregations have something to show.

Step 7 matters for demonstrations. A model deployed ten minutes before a meeting has one hour of data and no daily values, which looks broken rather than new.

Names and expectations#

If a simulated model will be shown to customers or used in training, use invented facility names — Atlas Cement Works, Riverside Water Reclamation — rather than real customer names, and make it obvious in the model that the data is simulated. A plausible dashboard of fictional data is easy to mistake for real reporting, and correcting that impression later is awkward.

Its limits#

Be clear about what the simulator does not do.

It is not a load test. Simulated tags are cheap to read. A model that performs well against the simulator tells you nothing about how it will perform against a historian over a slow network. Source latency dominates real retrieval, and the simulator has none.

Its history is not deep. It generates data as time passes rather than providing years of back-history, so long-range trend and year-on-year patterns cannot be demonstrated convincingly on a fresh instance.

Its signals are shaped, not real. They are good enough to exercise every modelling technique and to make a dashboard look right. They will not reproduce the awkwardness of real plant data — the sensor that fails for six hours, the meter that resets, the operator who enters yesterday's reading. Test those cases deliberately rather than assuming the simulator will present them.

Moving from simulator to real data#

When the real source becomes available, the model does not need rebuilding. Only the retrieved measures reference the connection, and everything above them is independent of where the data came from.

The path:

1. Create the real connection alongside the simulator one.
2. Repoint the retrieved measures at it, updating each tag to the real tag name.
3. Verify a sample of values against the source system directly.
4. Deploy, and confirm values arrive.
5. Leave the simulator connection in place, undeployed, if you still want it for testing.

The aggregations, calculations, limits, charts, and dashboards all carry over untouched. This is a good argument for building against the simulator during a project's design phase rather than waiting for network access — the modelling work is not wasted.

See also#

• Your First Model in 45 Minutes
• Choosing a Data Source
• How Infohub Retrieves Data