The Model Tree

The four levels#

Model
+-- Folder                 Site / Area / Line — organisation only, no data
    +-- Folder             Nest as deep as makes sense
        +-- Metric         One thing you measure: "Boiler 1 Steam"
        |   +-- Measure    Steam Flow            (Tag, Retrieved)
        |   +-- Measure    Steam Flow Hourly     (Hourly, Aggregated)
        |   +-- Measure    Steam Flow Daily      (Daily, Aggregated)
        +-- Event Scheme   Production Run — context, not values

Folders carry no data, and that is the point#

It is tempting to think of folders as containers and stop there. They do more:

• They are what people navigate. The tree is how a user finds a chart or a measure.
• They anchor model attributes. An attribute set on a folder is available to everything beneath it, which is how one templated expression serves many lines. See Model Attributes.
• They are template targets. Instantiating a template means creating its content inside a folder.
• They shape reporting scope. Report and form scope are expressed in terms of the tree.

So folder structure is not cosmetic. A structure that mirrors how the plant is actually organised makes everything downstream easier; one that mirrors the historian's tag naming makes everything harder.

Metrics group, they do not calculate#

A metric is a grouping level with no values of its own. Boiler 1 Steam is a metric; the numbers live in its measures.

The rule for deciding what is a metric: one metric per thing you would name in conversation. An operator says "boiler one steam" and means the whole family — the raw flow, the hourly average, the daily total. That family is a metric.

Two mistakes to avoid.

One metric per measure. If every metric contains exactly one measure, the level is doing no work and the tree is twice as deep as it needs to be.

One metric for a whole area. A metric called Boiler House containing sixty measures for four boilers is a folder wearing the wrong hat. Make it a folder with four metrics beneath it.

Measures are the only things with values#

Everything about a measure is covered in Measures & Calculations. For the tree, what matters is that a metric usually holds a whole chain — a retrieved measure and the aggregations above it — and that naming should make the chain readable:

Metric: Boiler 1 Steam
+-- Steam Flow            Tag
+-- Steam Flow Hourly     Hourly
+-- Steam Flow Daily      Daily
+-- Steam Flow MTD        Monthly

Same base name, interval as the suffix. The family sorts together and every chart legend reads correctly.

Event schemes sit alongside metrics#

An event scheme lives in the tree next to metrics, and it describes what was happening rather than what a value was. A production run, a batch, a stoppage, a CIP cycle, a shift.

Events do not tile the timeline the way intervals do — they start and stop, they can overlap, they can be absent for days. That is exactly why they are a separate concept. Anything with a start, an end, and attributes is an event scheme, not a measure and not a calendar.

Put an event scheme in the folder whose equipment it describes, so that the run and the measures it contextualises are found together. See Designing an Event Scheme.

How deep should it go?#

Deep enough to mirror the plant, shallow enough to navigate. Three to five folder levels is typical:

Site
+-- Area
    +-- Line
        +-- Machine
            +-- Metric

Below about six levels, users stop navigating and start using search, and charts become tedious to build. Above two, you lose the organisation that makes templates and attributes useful.

The test: could someone who knows the plant but not Infohub find a measure in under thirty seconds? If not, the structure describes something other than the plant.

What the tree should mirror#

Mirror the plant, not the historian. Tag naming conventions encode instrument numbering and control system topology. Neither is how anyone thinks about the plant.

Mirror the plant, not the org chart. Reporting lines change more often than equipment does. Model the physical reality and let reports slice it by responsibility.

Mirror the plant, not the dashboards you plan. Dashboards change constantly. A structure built around the first set of dashboards becomes wrong as soon as the second set is requested.

Templates and the tree#

Where the same structure repeats — twelve mixers, four boilers, eight lines — build it once as a template and instantiate it. The instances land as normal folders and metrics in the tree, and they stay linked to the template so improvements propagate.

This is worth planning for. A tree where repeated equipment sits in consistent, parallel positions is straightforward to template. One where each line was built by hand slightly differently is not, and retrofitting templates onto it is real work. See Templates: Concepts.

Locations: giving a folder a place on the map#

Infohub can place model content geographically, and there are two separate mechanisms for it.

A location is defined once and assigned to a folder, so every site folder referring to Durban Plant shares one definition — change the coordinates once and every reference follows. A metric's own coordinates are set directly on that metric, for the case where the thing being measured has a position the folder does not: a pump station on a pipeline, a borehole, a meter in the field.

Both feed the Map chart, which is what turns a tree into a picture — which site is underperforming, seen in place rather than as another row in a table. Flow Server's model API returns a metric's coordinates alongside it, so they are available to anything reading the model.

This earns its keep in one situation: geography that actually means something. A single-plant model gains nothing, and adding coordinates to it is busywork. A group with eleven plants, or a utility with metering points across a region, gains a view no folder tree can give.

Assign a location at the level that is the place — usually the site or plant folder, not the individual line beneath it, since eight lines in one building share one set of coordinates. Reach for per-metric coordinates only when the metrics genuinely sit in different places.

Moving and renaming#

Both are supported, and both have consequences.

Renaming is generally safe. Charts and limits reference measures by identity, not by name, so a rename does not break them. It will change chart legends and axis labels, which is usually what you wanted.

Moving changes which model attributes apply, because attributes are inherited down the tree. A metric moved into a different folder may resolve a different value for an attribute, which changes calculated results. Check what attributes the destination provides before moving templated content.

Starting a new model#

A workable order:

1. Sketch the folder structure on paper first — site, areas, lines, machines. Ten minutes here saves a rebuild later.
2. Create the folders, including ones you will fill later.
3. Identify what repeats. Anything appearing three or more times is a template candidate.
4. Build one instance by hand, completely — chain, calculation, limits, chart — and confirm it is right.
5. Turn it into a template and instantiate the rest.
6. Add the one-off equipment that does not fit a pattern.

The temptation is to start creating measures immediately. Half a day on structure repays itself many times over.

See also#

• Folder Structure Best Practices
• The Measure Hierarchy
• Model Attributes
• Designing an Event Scheme