Retrieved Measures
The measures that actually read your plant — how retrieval works, and why most of them should be at the Tag interval.
A retrieved measure is the only kind that touches an external system. Everything else in an Infohub model is derived from these, which makes them a small minority of the measures in a model and by far the most consequential ones to get right.
What a retrieved measure needs#
| Setting | What it does |
|---|---|
| Connection | Which configured connection to read through |
| Tag or query | What to read — a tag name, a query, an endpoint path, depending on the connector |
| Interval | The interval the retrieved values land on |
| Aggregation | Only when retrieving at an interval — how the source should summarise |
| Unit | The unit the source reports in |
| Format | How values display |
The connection carries everything about how to reach the system — server, credentials, database, authentication. The measure carries only what to read. That separation is why one connection serves thousands of measures.
Retrieve at Tag interval, then aggregate#
Infohub lets you retrieve at any interval. Given the choice, retrieve at the Tag interval and aggregate upward in Infohub.
A Tag-interval measure stores the source's raw values at the times the source recorded them. From there you build the interval chain — hourly, daily, monthly — inside Infohub.
The alternative is asking the source to aggregate: configure the measure at the Hourly interval with an aggregation of Average, and the connector asks the historian for hourly averages directly.
Retrieving at Tag and aggregating in Infohub is usually better for three reasons.
You keep the raw data. When a number is questioned, you can see the values it came from. With source-side aggregation, the raw detail was never stored and the audit trail stops at the hourly figure.
The chain stays consistent. Every level above derives from one place, so the numbers reconcile by construction.
The aggregation rules are Infohub's and are uniform. Historians differ in how they weight values, handle gaps, and treat quality. Aggregating in Infohub means a hundred measures across four historians all behave the same way.
When source-side aggregation is the right call. Retrieve at an interval when the raw data volume is genuinely prohibitive — a very fast tag you only ever need hourly — or when the source has a specialised aggregation Infohub does not offer at measure level, such as Time in State or a Custom Expression. Those exist on the connector side and not as measure-level aggregation types.
The two aggregation lists#
This catches people. The aggregation dropdown on a retrieved measure comes from the connector, and it is a different list from the one on an aggregated measure.
Connector lists typically include Count, Time in State, and Custom Expression, which have no measure-level equivalent. They also vary between connectors — a historian that cannot compute variance will not offer it. See Measure Reference and Connection Property Reference.
Tag interval measures are not on the interval grid#
A Tag-interval measure has no interval. Its values sit wherever the source put them.
Consequences worth knowing before you build:
- Interval charts refuse it. Every interval-based chart rejects a Tag measure. Chart the hourly or daily derivation instead.
- You cannot skip to Daily. Aggregate Tag to an interval first — usually Hourly — then upward.
- Limits and most consumers expect intervals. They operate on interval measures.
This is not a limitation to work around; it is the reason the chain exists. Retrieve raw, derive intervals, use the intervals.
Quality#
Retrieved values carry a quality code from the source. Infohub stores it alongside the value and propagates it through aggregation, so a daily figure built from questionable hours can be identified as such.
Quality is available in expressions as .Quality, which allows a calculation to exclude bad values:
Measure_1043.Quality >= 192 ? Measure_1043.Value : (double?)null
Quality conventions are the source's, not Infohub's — OPC-style codes where 192 and above mean good are common but not universal. Confirm against the system you are reading.
Scaling, offsets, and conversions#
Where a source reports in the wrong unit or scale, you have three options, in order of preference.
Fix it at the source. If a historian is configured to log in the wrong unit, correcting it there fixes every consumer of that tag, not just Infohub.
Convert with a calculated measure. Retrieve raw, then a calculation converts. This keeps the raw value visible and makes the conversion explicit and reviewable.
Convert in the source query. SQL-based connectors let you scale in the query itself. Concise, but the conversion is buried in a query property where nobody will look for it.
Avoid the fourth option — quietly labelling the measure with the unit you wish it had. That is how a model ends up with a tag in kW displayed as MW.
Naming#
Name a retrieved measure for what it is, not for the tag it comes from. Steam Flow, not 010-FT-001. The tag name is a property; the measure name is what appears in every chart, report, and limit for years afterwards.
Keep the tag reference discoverable — it is on the measure, and the CLI can list it — but do not make readers decode instrument numbering to understand a report.
Diagnosing a retrieved measure with no data#
Work down this list in order.
- Is the connection deployed? Saving a connection does not activate it. See Deploying Configuration.
- Is the measure deployed? Same rule.
- Does the tag exist, exactly? Browse the connection's namespace and compare character for character. Trailing spaces and case differences are common.
- Does the source have data for the period? Query the historian directly for the same window. If the source is empty, Infohub is behaving correctly.
- Is it a permissions difference? A connection tested in Flow Config runs as you; deployed, it runs as the
Flow Bootstrapservice account. This is a frequent cause of "works in Config, fails deployed". - Is the Platform hosting the connection running? The connection is hosted on a Platform, and Bootstrap claims a Platform by host name.
- Check the
Flowevent log. Connector errors are recorded there.
See Diagnosing Missing Data for the full procedure.
Cost awareness#
Retrieved measures are the expensive part of a model, because each one is a query against an external system.
Two habits keep that cost down. Do not retrieve the same tag twice — if two metrics need the same tag, one retrieved measure can feed both through the chain. And do not retrieve what you can derive: retrieving hourly, daily, and monthly versions of the same tag separately triples the query load and invites the three to disagree.