How Infohub Retrieves Data

Connections and measures#

The split is consistent across all 31 connectors.

The connection carries everything about how to reach a system: address, port, credentials, database name, authentication mode, timeouts. Configure it once.

The measure carries only what to read: a tag name, a query, an endpoint path. Thousands of measures share one connection.

That is why a credential change is a one-line edit rather than a model-wide sweep, and why moving a model between instances requires the connections to be recreated but not the measures.

Plugins#

Connectors are plugins, packaged separately from Infohub and loaded at runtime from:

%ProgramData%\Flow Software\Flow\Config\Packages

Two practical consequences.

New connectors can be added without upgrading Infohub. A historian released after your Infohub version can still be supported.

Plugin versions matter when moving configuration. A plugin declares its own property set. If a destination instance has older plugin assemblies than the source, properties the older plugin does not recognise can be lost during an import or a template push — silently. When a query or property appears to vanish after a transfer, compare plugin versions first.

The tag namespace#

Most connectors can enumerate what the target system offers — a namespace you browse when configuring a measure.

Always browse rather than typing tag names from a spreadsheet. Browsing proves three things at once: the connection works, the credentials work, and the tag exists exactly as named. Typing proves nothing, and trailing spaces and case differences are the two most common reasons a measure returns nothing.

Some connectors cannot enumerate — a REST API has no list of everything it could return — and there you supply the address directly.

Custom namespaces: your own shortcuts into a source#

You are not limited to the tree the source exposes. Right-click in the whitespace below a data source's namespace and you can add your own folders and items alongside it.

The usual use is a shortcuts folder — call it My Favourites — holding the forty tags this model actually cares about, out of the eighty thousand the historian offers. Browsing a curated list beats searching a namespace every time you add a measure, and it is self-documenting for whoever inherits the model.

Custom items are also where a reusable definition can live rather than being retyped: define the item once, reference it from many measures.

This is purely a Flow-side convenience. It does not change anything in the source system, and it does not move data.

"Please create a tag first"#

Drag an item from certain data sources straight onto a measure's retrieval, an event attribute or an event trigger, and Infohub refuses:

Cannot configure measure retrieval directly from this data source. Please create a tag first and then use that tag in the retrieval configuration.

This is not a fault, and it is not about that particular item. It happens on connectors that can both return raw values and offer custom expression examples — 13 of them, including the Canary, OPC UA, OPC HDA, Wonderware, Siemens Process, Netilion, eWon and Web Service connectors, and the Historian Simulator.

For these sources Infohub wants an explicit tag in between, rather than binding a measure directly to a source item. The tag becomes the named, reusable thing the model refers to: several measures, attributes and triggers can share it, and changing where it comes from is then one edit rather than many. Create the tag, then reference the tag.

What the engine asks for#

When a retrieved measure is due, the Data Engine asks the connector for that measure's data for a specific period. The connector's job is to answer for exactly that window.

This is why period placeholders exist. In query-based connectors, the query is a template and Infohub substitutes the window:

SELECT Value, Quality FROM History
WHERE TagName = 'Boiler1.Steam'
  AND DateTime >  [PeriodStart]
  AND DateTime <= [PeriodEnd]

[ModelAttribute(...)] is what makes queries templatable — one query serving many measures, each resolving its own unit number. See Model Attributes.

Retrieval at Tag interval versus at an interval#

A measure retrieves either raw values (the Tag interval) or an aggregate the source computes (any other interval, with an aggregation).

Prefer raw. You keep the underlying data for auditing, all your aggregation rules are Infohub's and are uniform across sources, and the chain reconciles by construction.

Retrieve at an interval when data volume is genuinely prohibitive, or when the source offers an aggregation Infohub does not have at measure level — Count, Time in State, and Custom Expression exist on the connector side only. See Retrieved Measures.

Quality#

Connectors return a quality code with each value, and Infohub stores and propagates it. Quality is available in expressions as .Quality, so a calculation can exclude suspect values.

Quality conventions belong to the source, not to Infohub. OPC-style codes where 192 and above mean good are common but not universal — confirm against the system you are reading.

Deadband, scaling, and rollover#

Several connectors expose per-measure processing that happens on the way in:

Availability varies by connector — see the Connection Property Reference.

Use these deliberately. A deadband set too wide silently discards real movement, and scaling applied here is invisible to anyone reading the model later. Where a conversion needs to be obvious, do it in a calculated measure instead.

Overlap: reaching outside the period#

Most historian connectors expose Forward Overlap and Backward Overlap on each measure. They extend the query window beyond the period being retrieved.

This matters for slow-moving tags. If a tank level was last logged at 03:00 and you are retrieving the 08:00 hour, a query bounded strictly by that hour returns nothing at all — not because the level is unknown, but because it has not changed. Backward overlap lets the connector reach back and find the last known value, so the period gets the value that was actually in force.

Set backward overlap generously on state tags and slow analogs; a value logged once a shift needs an overlap measured in hours, not seconds. Leave it small on fast-changing tags, where a wide window costs query time for no benefit.

Conditional retrieval with a filter tag#

Several historian connectors let a measure's retrieval be gated by another tag:

This retrieves a value only while some other condition holds — a quality reading only while the line is running, a temperature only while the vessel is in service, a flow only while the pump is on.

It is a genuinely useful way to keep noise out of a model at source. The alternative — retrieving everything and filtering in a calculation — stores values you will always discard and makes every downstream average wrong until it is filtered. Where the condition is a simple tag comparison, the filter is the better place for it. Where it is genuinely a production context with a start, an end, and attributes, use an event scheme instead.

Concurrency and load#

Connectors expose limits on how hard they will push a source — a maximum concurrent request setting is common.

Two symptoms tell you the limit needs lowering: the source system's administrator complains, or retrieval starts timing out under load. Raising concurrency speeds up collection right up to the point where the source becomes the bottleneck, after which it makes things worse.

Prune the custom expression item list#

A custom expression is given its tags as a wide query — every tag in the item list becomes a column of one result set — and historians normally return rows on delta, meaning a row whenever any of those tags changes.

Those two facts combine badly. Add a chatty tag to the item list and leave it unused, and every one of its changes still produces a row, each carrying repeated values for every other column. The expression does the same work it always did, on a result set several times larger.

So remove tags from the item list once the expression stops referring to them. It costs nothing and it is invisible until a trigger evaluation starts timing out, at which point the cause is not remotely obvious — the expression looks simple and the tag it is choking on is not even mentioned in it.

The service account matters#

A connection tested in Flow Config runs as you. Once deployed, it runs as the Flow Bootstrap service account.

For any source using Windows integrated security — OPC, several historians, SQL with trusted connections — that difference is the single most common cause of "it works in Config and fails when deployed". Grant the service account the same access you have, or configure explicit credentials on the connection.

Where connections run#

A connection is hosted on a Platform. If a source is only reachable from inside a plant network, put the connection on a Platform whose Bootstrap runs on a machine in that network. Firewall rules then only need to allow Flow-to-Flow traffic rather than exposing the historian.

See Infohub Architecture at a Glance.

Diagnosing retrieval#

In order:

1. Is the connection deployed, and not showing Different or Faulted?
2. Can you browse its namespace right now?
3. Does the tag exist, character for character?
4. Does the source have data for that period? Query it directly and compare.
5. Is the Platform hosting the connection running?
6. Would the service account have the access you have?
7. What does the Flow event log say?

See Diagnosing Missing Data.

See also#

• Choosing a Data Source
• Retrieved Measures
• Connection Property Reference
• Diagnosing Missing Data