Choosing the Right Aggregation Type

The question that decides it#

Is the value below you a rate, a total, or a state?

Nearly every aggregation in a working model is one of these four. The rest exist for specific analytical needs.

Average — for rates and readings#

If the underlying value is per unit time or is simply a reading of a condition, the summary over a longer period is its average.

A flow meter reading 40 m³/h for the first half of an hour and 60 m³/h for the second half averages 50 m³/h. Summing those readings would give 100 m³/h, which is not a quantity that exists.

Use Average for temperature, pressure, flow rate, speed, current, level, concentration, efficiency percentages, and utilisation percentages.

Infohub's average is time-weighted#

This is the most common reason an Infohub average disagrees with one worked out by hand, and it is worth understanding before concluding something is wrong.

Infohub does not average the sample values. It weights each value by how long it was in force. A value that held for ten minutes counts ten times as much as one that held for one minute, so a burst of closely spaced readings cannot drag the average toward itself.

Each point's value is held until the next point arrives — a step, not a straight line between readings — and the sum of value × duration is divided by the period's duration:

average = Σ (value × milliseconds that value held) ÷ total milliseconds

A historian that logs on change, as most do, produces points at irregular intervals. Under a plain sample average those points would each count equally, so the answer would depend on how chatty the instrument was rather than on what the process did. Time weighting is what makes the number a property of the process.

Two consequences follow:

• A hand-calculated average will differ unless you weight it the same way. Dividing the sum of the readings by the number of readings is not what Infohub did, and the gap widens the more irregular the logging is.
• Filtering changes the denominator, not only the numerator. Where a filter excludes part of the period, the average is taken over the time that remained — so a measure filtered to "running only" averages across running time, not across the clock.

If a period contains no points at all, the last known value carries forward, scaled by how much of the period it covered.

Sum — for quantities#

If the underlying value is a quantity that happened during its interval, the longer period is the total of those quantities.

Bottles filled per hour sum to bottles filled per day. Kilowatt-hours per day sum to kilowatt-hours per month. Tonnes per shift sum to tonnes per week.

The test: if you doubled the length of the interval, would you expect roughly double the number? If yes, it is a Sum.

Counter — for totalisers that only ever climb#

This is the one people miss, and it is worth learning properly because totalisers are everywhere.

Many instruments do not report "how much this hour". They report a register that only ever increases — cumulative cubic metres since the meter was installed, or lifetime kWh. The value at 09:00 might be 1,284,551 and at 10:00 might be 1,284,796.

You do not want the average of that register, and you certainly do not want its sum. You want the difference: 245 units during that hour. Counter does exactly that, and it handles the two things that make totalisers awkward:

• Rollover. When a register reaches its maximum and wraps back to zero, a naive difference produces an enormous negative number. Counter recognises the wrap.
• Resets. When an instrument is replaced or its register is manually cleared, the same problem appears.

The pattern that follows from this is worth memorising:

Cumulative Flow        Tag       Retrieved
  +-- Volume Hourly    Hourly    Aggregated — Counter    < difference across each hour
        +-- Volume Daily  Daily  Aggregated — Sum        < now it is a quantity, so Sum

Counter converts a register into a per-period quantity. From that point up the chain, the values are quantities, so everything above uses Sum. Using Counter twice in a chain is a bug: the second one takes the difference between two quantities, which is meaningless.

Last and First — for states#

Some values are not quantities at all. The active recipe, the current product code, the tank in service, a setpoint. There is no meaningful sum or average of "Recipe B".

Last takes the final value in the period, and is the usual choice — the state a period ended in is normally the state you want to report it under. First takes the opening value, which is occasionally what a batch or shift record needs.

Last is also right for slow-moving numeric values where the closing position is the point: tank level at end of shift, stock on hand, a meter's closing register when you want the register itself rather than its increment.

The rest, and when they earn their place#

The remaining types answer narrower questions.

Maximum deserves a mention because electricity billing depends on it. Peak demand charges are based on the highest demand reading in the month, so that measure must be Maximum all the way up the chain — Maximum of hourly maxima is the monthly maximum, which works correctly.

For variance and standard deviation, pick Population when the interval's values are the whole thing you care about, and Sample when they are a sample standing in for a larger process. Population is the usual choice for process data, where you genuinely have every reading the historian logged.

Diagnosing a wrong choice#

Aggregation mistakes have recognisable signatures.

The fastest check is to put the measure and its parent on the same chart at two intervals and see whether the relationship between them is the one you intended.

What to read next#

For the complete list with exact behaviour, see the Aggregation Type Reference. If the number you need cannot be expressed by any single type, you want a Calculated Measure instead.

See also#

• Measure Reference: Intervals, Retrieval, and Aggregation Types
• Aggregated Measures
• The Measure Hierarchy
• Diagnosing Missing Data