Multi-Site Architecture

The shape#

                    +---------------------+
                    |  Central instance   |
                    |  group reporting    |
                    |  template library   |
                    +------+------+-------+
                    ^      ^      ^
        replication |      |      |
              +-----+--+ +-+----+ ++------+
              | Site A | |Site B| |Site C |
              | own    | |      | |       |
              | model  | |      | |       |
              +----+---+ +--+---+ +---+---+
                   |        |         |
              historians, SQL, MES per site

Two flows in opposite directions, and both matter:

Data flows up. Each site replicates its standardised KPIs to the centre using the Flow consumer.

Standards flow down. The centre publishes templates that sites derive from, so the models are genuinely comparable.

A deployment with only the upward flow ends up comparing numbers that were calculated differently at each site. That is the most common failure in group reporting, and it is not discovered until someone questions a comparison.

Why not one central instance?#

Reading every site's historians from one central instance is simpler to draw and worse in practice.

A network outage stops everything. With site instances, a plant keeps collecting and reporting through a WAN failure; the central instance catches up when the link returns. With central-only, an outage is a permanent hole in that site's data.

Raw tag traffic across a WAN is expensive. Replicating a few hundred site KPIs is a fraction of reading tens of thousands of raw tags remotely.

Operators need local response. A control room dashboard served across a WAN is slow, and it is unavailable exactly when the site most needs it.

Historians are rarely reachable centrally. Plant networks are usually deliberately isolated, and getting historian protocol traffic across that boundary is a harder security conversation than Flow-to-Flow HTTPS.

The exception is a genuinely small estate — two or three sites on one good network, with modest models — where the operational simplicity of one instance may outweigh the resilience argument.

What belongs where#

The division that works:

The rule of thumb: if only the site cares, it stays at the site. The central instance should be small and focused. A central instance that has accumulated every site's full model is unnavigable and slow, and nobody uses it for what it was built for.

Standardise the replicated subset#

The measures crossing the boundary must mean the same thing at every site. This is the hard part, and it is organisational as much as technical.

Practical approach:

1. Agree the group KPI set. A few dozen measures: production, availability, quality, energy per unit, cost per unit. Written down, with definitions — what counts as scheduled time, what counts as good product.

2. Template them centrally. Build the group KPI structure as templates, publish them from a template server, and have every site derive from them. That is what makes the calculations identical rather than merely similarly named.

3. Give it a dedicated home at each site. A Group Reporting folder containing exactly the replicated measures. The contract becomes visible and auditable, and the namespace filter has something clean to point at.

4. Replicate only that folder.

Regional rollups#

Where the group is large, a middle tier helps: sites replicate to a regional instance, regions to a group instance.

Worth doing when there are enough sites that one central instance becomes a bottleneck, or when regions have genuine reporting autonomy. It adds a hop, another instance to license and maintain, and another place for staleness to hide — so do it when the organisation actually has regions, not speculatively.

Practical matters that get forgotten#

Every instance needs its own licence. Each site, each region, and the centre. Also test, training, and disaster recovery instances. Budget and request them together — a rollout that licenses the centre and forgets the sites stalls at the worst moment. See Licensing Infohub.

Server keys expire. Every replication link and every template server link has a credential with an expiry. Across twenty sites that is a lot of dates. Keep a register, and rotate ahead of expiry.

Time zones. A group spanning time zones needs an explicit decision about what "yesterday" means in a group report. Usually each site reports on its own calendar and the group aggregates the site's own daily figures — which is why replicating the site's already-calculated daily value is better than replicating raw data and recalculating centrally.

Version skew. Sites will not all upgrade on the same day. Understand which combinations you are prepared to run, and upgrade the centre in step with a policy rather than ad hoc.

Monitoring staleness#

The failure that matters most in a multi-site deployment is a site quietly stopping replication, because the central instance keeps reporting its last received values as current.

Build this deliberately at the centre:

1. A measure per site tracking how recently its values arrived.
2. A limit on it.
3. A notification when a site goes quiet.

This is the single most valuable monitoring in the architecture. Without it, the group report is confidently wrong and nobody knows for days.

Onboarding a new site#

With the pattern established, a new site is largely mechanical:

1. Install Infohub and create the database. Licence it.
2. Link it to the central template server and derive the group KPI templates.
3. Instantiate them into a Group Reporting folder.
4. Build the site's own local model — connections, detailed measures, dashboards.
5. Configure the Flow consumer to the centre, filtered to Group Reporting, with a server key issued for that site.
6. Verify at the centre that values arrive against the intended measures.
7. Add the site to staleness monitoring.
8. Add the site to the group reporting dashboards.

Steps 2 and 3 before step 4 is deliberate: get the group contract in place first, then build the site's own model around it.

Diagnosing#

See also#

• Flow-to-Flow Replication
• Template Servers and Federation
• Infohub Architecture at a Glance
• Licensing Infohub