What Infohub Is and How It Fits

What Infohub does#

Three things, in order.

It collects. Infohub connects to the systems that already hold your data — historians, SQL databases, OPC servers, MQTT brokers, REST APIs, spreadsheets — and reads values on a schedule you define. It does not replace those systems and it does not require them to change.

It calculates. Infohub puts the values it collects onto a calendar. Not "the last 24 hours", but your hours, your shifts, your production days, your financial months. It then aggregates and computes up that calendar: hourly averages, shift totals, daily yields, month-to-date consumption, OEE, cost per tonne. This is the part that is genuinely hard to do in a historian or a spreadsheet, and it is the reason Infohub exists.

It visualises and publishes. The results appear in a browser as charts, dashboards, tables, and forms; go out as scheduled reports; raise notifications when they cross a limit; and stream onward to other systems that want them — a data lake, a corporate SQL warehouse, an MQTT broker, another Infohub instance.

The idea that makes Infohub work#

Infohub's central idea is the model: a structured description of your plant, in your language.

A historian gives you a flat list of tag names like PLANT1_LINE2_FLW_003.PV. Infohub gives you a tree — Site, Area, Line, Machine — and hangs measures off it. Once that structure exists, everything else gets easier: a chart can be built once and pointed at any line; a template can be written once and instantiated for all twelve mixers; a report can loop over every site.

The unit of the model is the measure: a named series of values, one per interval, with a unit and a format. A measure might read a tag directly, summarise another measure over a longer period, compute an expression from several others, or accept a number typed in by an operator. Most of what modelling in Infohub means is deciding which measures you need and how they relate.

Where Infohub sits#

   Historians          Databases         Brokers / APIs        People
   Wonderware          SQL Server        MQTT, Kafka           Manual entry
   Canary, Ignition    Oracle, MySQL     REST, OPC UA          via forms
   OPC HDA/UA          PostgreSQL
        |                   |                  |                  |
        +-------------------+------------------+------------------+
                                    |
                            +-------v--------+
                            |      FLOW      |
                            |  model, engine |
                            |   calendar     |
                            +-------+--------+
                                    |
        +---------------+-----------+--------+------------------+
        |               |                    |                  |
   Dashboards       Reports           Notifications        Downstream
   in a browser     scheduled         email, Teams,        SQL, Snowflake,
                    PDF/Excel         Slack, SMS           MQTT, Kafka,
                                                           other Flow sites

Infohub reads from the left, models and calculates in the middle, and publishes to the right.

What Infohub is not#

Being clear about this saves time.

It is not a historian. Infohub stores the intervals it calculates, not a high-resolution archive of every tag change. Keep your historian; Infohub reads from it.

It is not a SCADA or control system. Infohub is a reporting and analysis layer. It reads from control systems and does not write setpoints back into them.

It is not a generic BI tool. A BI tool will happily chart any table you give it. Infohub's opinion — that data belongs on a production calendar, in a plant model, with defined units and aggregation rules — is the point, and it is why the numbers reconcile.

The pieces you will meet#

Infohub Architecture at a Glance explains how these fit together and which of them run where.

Two things that surprise newcomers#

Configuration is separate from activation. Building a measure in Flow Config does not make it start collecting data. You configure, then you deploy. This is deliberate — it lets you build and review a large change safely and turn it on in one step — but it catches everyone once. See Deploying Configuration.

The calendar is yours to define. Infohub does not assume a day starts at midnight or that a month is a calendar month. Shifts, production days, and financial periods are all things you define, and every aggregation respects them. See Interval Types and Time Schemes.

Where to go next#

If you want to understand the shape before installing anything, read Infohub Architecture at a Glance. If you have an instance already and want to build something, go straight to Your First Model in 45 Minutes.

See also#

• Infohub Architecture at a Glance
• Your First Model in 45 Minutes
• The Measure Hierarchy