The Measure Hierarchy

Where measures live#

An Infohub model is a tree. Working from the top down:

Model
+-- Folder                     Site, area, or line — however you organise the plant
    +-- Folder                 Nested as deeply as you need
        +-- Metric             A thing you measure: "Boiler 1 Steam"
            +-- Measure        Steam Flow (Tag)
            +-- Measure        Steam Flow Hourly (Hourly, Average)
            +-- Measure        Steam Flow Daily (Daily, Average)
            +-- Measure        Steam Efficiency Daily (Daily, Calculated)

Folders carry no data. They exist to organise, and to give templates and model attributes something to attach to. Metrics group the measures that describe one physical or business thing. Measures are where data actually lives — each one holds a series of values, one per interval.

The metric is the unit people navigate by. When an operator opens a chart and picks "Boiler 1 Steam", they are picking a metric and then choosing which of its measures to look at.

The two axes of a measure#

Every measure is defined by two independent choices, and confusing them is the most common source of early frustration.

Retrieval type — where the measure's values come from. Infohub has five:

Interval type — the period each value covers. Infohub has nine:

These combine freely. A daily calculated measure and a daily aggregated measure are both daily; they differ only in how their values are produced.

Why the pyramid forms#

Consider one flow meter. You configure a single Retrieved measure to read the tag. Then the questions start arriving.

Production wants hourly throughput. Supervisors want it per shift. The daily report wants a daily total, plus a month-to-date total and a rolling seven-day average. Finance wants monthly and year-to-date. Someone wants last year's monthly figures beside this year's for comparison.

That is one tag and eight or more measures — and none of the extra ones read the historian again. Each summarises the one below it:

Steam Flow            Tag        Retrieved     < the only measure touching the historian
  +-- Hourly          Hourly     Aggregated (Average)
        +-- Daily     Daily      Aggregated (Average)
              +-- Monthly        Aggregated (Average)
              +-- MTD            Aggregated (Sum)

Multiply that by every tag in a plant and the shape is unavoidable: retrieved measures are a small minority of any real model, and aggregations are the largest group by a wide margin. A model where those proportions are reversed usually means someone has been configuring separate retrievals for each period instead of building a chain — which is slower, harder to maintain, and can disagree with itself.

Why chains beat repeated retrieval#

Reading the historian once and aggregating upward has three concrete advantages.

It is far cheaper. Historian queries are the slowest thing Infohub does. An aggregation reads values Infohub already has in its own database.

The numbers cannot disagree. If the daily total is derived from the hourly measure, it always equals the sum of those hours. Retrieve both independently and you invite the classic support call where the daily figure and the sum of the hours differ by a fraction of a percent.

Fixing one thing fixes everything. Correct a scaling error on the retrieved measure, and every measure above it recalculates correctly. Fix it in nine places and you will miss one.

Keep the chain contiguous#

Aggregations step up through the interval hierarchy. Build them in order — Tag to Hourly, Hourly to Daily, Daily to Monthly — rather than jumping from Hourly straight to Monthly.

Contiguous chains give you the intermediate periods people inevitably ask for later, and they make gaps obvious: if the monthly figure looks wrong you can walk down the chain and see exactly which day, and then which hour, went missing. A chain that skips levels hides the evidence.

Naming that survives contact with a real model#

Because a metric holds many measures at different intervals, the interval belongs in the measure name. Steam Flow Hourly, Steam Flow Daily, Steam Flow MTD are immediately readable in a chart legend, a limit list, or a CLI listing. A metric containing four measures all called Steam Flow is technically valid and practically unusable.

Keep the base name identical across the chain so the family sorts together, and put the qualifier at the end.

Name versus hierarchical name#

A measure has two names, and knowing which you are looking at removes a whole class of confusion.

The name is what you typed — DTD, Total Production. It only has to be unique within its parent, so a model can legitimately hold a dozen measures called DTD.

The hierarchical name is the full containment path — folders, metric and measure joined together. That is what identifies a measure across the model, and it is what Infohub falls back on wherever a bare name would be ambiguous:

Filler 1 · Total Production · DTD
Filler 2 · Total Production · DTD

Put both on one chart under their plain names and the legend says DTD twice.

Two consequences follow:

• A short name is fine when the tree around it supplies the context. DTD inside Filler 1 · Total Production reads perfectly well.
• Moving or renaming a folder changes the hierarchical name, because it is derived from the path rather than stored. Nothing breaks — references are by identity, not by name — but anything that quoted the old path, such as a document or a saved export, now names something that no longer exists.

What to read next#

Once the shape makes sense, the next decision is which summary each aggregation should use — and that choice causes more rework than any other in Infohub. Read Choosing the Right Aggregation Type before you build a chain in earnest.

See also#

• Retrieved Measures
• Aggregated Measures
• Choosing the Right Aggregation Type
• Interval Types and Time Schemes