Infohub (Flow)How-to

T02: Building an Aggregation Chain

Put raw values onto the interval grid — and learn the difference between a rate and a totaliser the hard way round.

Updated 15 Oct 2026Infohub Docs

What you will build: two aggregation chains — one for a rate, one for a totaliser — which are handled completely differently.

Time: about 30 minutes.

You need: T01 completed, with Steam Flow receiving values.

Step 1 — Aggregate the steam flow#

Steam flow is a rate — kilograms per second. The summary of a rate over a longer period is its average.

In the Steam metric, add two measures:

Name	Retrieval type	Interval	Aggregation	Source	Unit	Format
`Steam Flow Hourly`	Aggregated	Hour(s)	Average	`Steam Flow`	`kg/s`	`0.0`
`Steam Flow Daily`	Aggregated	Day(s)	Average	`Steam Flow Hourly`	`kg/s`	`0.0`

Two things to notice.

The daily measure aggregates from the hourly one, not from the tag. Chains step up one interval at a time. You could point the daily at the Tag measure and Infohub would let you — but then you have no hourly detail, no way to see which hour went wrong, and a second route to the same number if you ever add hourly later.

The unit does not change. An average of kg/s is still kg/s.

Wait a few minutes and check the hourly measure. You should see one value per hour, roughly in the middle of the tag's range.

Step 2 — Now do it wrong, deliberately#

Create a metric called Water under Boiler 1, and in it one retrieved measure:

Name	Retrieval type	Interval	Connection	Tag	Unit
`Water Meter`	Retrieved	Tag	`Simulator`	`020-FQ-001.PV`	`l`

Now add an aggregation the way you just did for steam:

Name	Interval	Aggregation	Source
`Water Wrong Hourly`	Hour(s)	Average	`Water Meter`

Let it run for an hour or two, then look at both.

Water Meter climbs continuously and never comes down — it might read 1,284,551 at 09:00 and 1,284,796 at 10:00. And Water Wrong Hourly reports a number in the millions, which is the average of the register, not the water used.

That is the mistake this tutorial exists to teach. 020-FQ-001.PV is a totaliser — a register that only ever increases. Its average is meaningless.

Step 3 — Do it right with Counter#

Add two more measures to Water:

Name	Interval	Aggregation	Source	Unit
`Water Used Hourly`	Hour(s)	Counter	`Water Meter`	`l`
`Water Used Daily`	Day(s)	Sum	`Water Used Hourly`	`l`

Counter takes the difference across each hour, turning the register into "litres used this hour". It also handles the two things that make totalisers awkward: a register that rolls over at its maximum, and one that is reset when an instrument is replaced.

Compare Water Wrong Hourly against Water Used Hourly. One reports a number in the millions; the other reports a plausible hourly consumption.

Then note what the daily measure uses: Sum, not Counter. After the Counter step, the values are quantities, so everything above sums.

Important

Counter appears exactly once in a chain. A second Counter would take the difference between two quantities, which means nothing. One Counter converts a register into a quantity; everything above it sums. If a consumption measure shows implausibly small values that look like differences of differences, look for a duplicated Counter.

Step 4 — Delete the wrong one#

Delete Water Wrong Hourly. It has served its purpose, and leaving a knowingly wrong measure in a model is how wrong numbers end up in reports.

Step 5 — Add a production count#

One more chain, to practise the pattern on a different shape of data.

Create a metric Filler 1 under a new folder Production, and add:

Name	Retrieval type	Interval	Aggregation	Source / Tag	Unit
`Bottle Counter`	Retrieved	Tag	—	`FL001.BottleCount`	`bottles`
`Bottles Hourly`	Aggregated	Hour(s)	Counter	`Bottle Counter`	`bottles`
`Bottles Daily`	Aggregated	Day(s)	Sum	`Bottles Hourly`	`bottles`

FL001.BottleCount is also a totaliser — a count that grows. Same pattern: Counter to convert, Sum above.

Set the format on the two derived measures to #,##0 — whole bottles, with thousands separators.

The decision, in one table#

You have now met the two commonest cases. This is the whole decision:

The source value is…	Example	Use
A rate or reading	flow in kg/s, temperature, pressure	Average
A quantity in that period	bottles this hour, kWh today	Sum
An ever-increasing register	cumulative litres, lifetime kWh	Counter, then Sum above
A state	current recipe, machine mode	Last

The test for a totaliser: chart the raw tag over a day. If the line only ever goes up, it is a totaliser and you want Counter.

What you have learned#

Chains step up one interval at a time. Tag to Hourly to Daily. Contiguous chains give you the intermediate periods people ask for later, and they make it possible to walk down and find which hour went wrong.

Reading once and aggregating beats retrieving repeatedly. Historian queries are the slowest thing Infohub does, and derived numbers cannot disagree with each other.

Rates average, quantities sum, registers need Counter. Getting this wrong produces a number that is plausible, stable, and consistently wrong.

Naming makes the chain readable. Same base name, interval as the suffix — Steam Flow, Steam Flow Hourly, Steam Flow Daily. They sort together and every chart legend reads correctly.

Try this before moving on#

Add a monthly measure above Water Used Daily, with Sum aggregation.

Then ask yourself: for Steam Flow, should the monthly measure aggregate from the daily average, or from the hourly? Aggregating from daily weights every day equally regardless of how many hours ran. Aggregating from hourly weights every hour equally. On a plant that does not run continuously, those give different answers — and the second is usually what people mean.

Next: T03: Manual Entry — capturing the numbers no system holds.