As OPC UA spreads across a plant, a new problem appears: too many servers. Line 1 has its PLC UA server, the packaging line another, the power meters a third, and the building management a fourth. Clients — SCADA, MES, historians — would need a connection per source, per namespace, with different certificates and different data models. The OPC UA aggregation server (also called an aggregating server or UA gateway) solves this by acting as a single UA server in front of many others, merging their address spaces into one coherent namespace.
What an Aggregation Server Does
An aggregating UA server connects as a client to multiple downstream UA servers and presents their data to its own clients as one address space:
- Namespace mapping — each downstream server's namespace appears under a defined prefix or folder, preserving identity and avoiding node-id collisions.
- Connection management — the aggregator maintains sessions and subscriptions to downstream servers, handles reconnects, and buffers data during outages.
- Transparent browsing — clients browse the combined tree exactly as they would browse a single server.
- Selective forwarding — the aggregator can expose a filtered subset (only the tags the plant-wide clients need), hiding internal details and reducing client complexity.
- Policy enforcement — downstream credentials, access rights, and certificate trust are handled centrally — one place to operate security instead of dozens.
Examples: PTC's KEPServerEX with UA aggregation features, Siemens' and Rockwell's gateway products, and OPC Foundation reference aggregating server implementations.
Architecture Patterns
| Pattern | Structure | Typical use |
|---|---|---|
| Star aggregation | One aggregator in front of N servers | Plant-wide SCADA/MES data hub; central certificate and tag management. |
| Hierarchical aggregation | Aggregators per area, then a top aggregator | Large sites with area autonomy; each area owns its aggregator, the plant level sees one namespace. |
| Redundant aggregation | Two aggregators serving the same merged namespace | Mission-critical data paths with client failover. |
| Edge aggregation | Aggregator at the edge, publishing to cloud | Industrial-to-cloud: one edge gateway terminates all plant servers and publishes MQTT/UA Pub/Sub. |
Design Considerations
- Node identity — downstream node ids must be remapped (the aggregator creates new node ids while preserving browsing context). Clients that cache node ids must be re-pointed after a re-aggregation; version the aggregated namespace.
- Semantics preservation — the aggregator should pass through quality, timestamps, and data types unchanged; any transformation (unit conversion, deadbanding) must be explicit and documented.
- Performance — aggregation multiplies data flow: one downstream subscription per source, re-published to many clients. Buffer design, publish rates, and the number of clients determine load; measure with the aggregator's own diagnostics before scaling.
- Failure semantics — when a downstream server is unreachable, the aggregator must decide: keep the old value with bad quality, mark the node unavailable, or drop it. Define the policy per data class — a monitoring dashboard and a control client need different behavior.
- Security — the aggregator holds credentials for all downstream servers; protect it accordingly (hardened host, restricted network, strong authentication), and use dedicated service accounts with least privilege per downstream system.
- Alarm and event forwarding — not all aggregators forward events/alarms with full condition semantics; if plant-wide alarming is the goal, verify Part 9 support explicitly.
When to Use (and Not Use) Aggregation
Aggregation shines when many sources must reach a few consumers with consistent security and naming — plant dashboards, MES integration, cloud gateways. It is overkill when a client needs data from one server, and it can hide problems: a silent aggregator failure looks like a slow server. Keep the source servers' direct access available for diagnostics, and monitor the aggregator's per-source connection status as a first-class health indicator.
Summary
OPC UA aggregation servers turn a web of point-to-point connections into a managed plant data hub: one namespace, one security posture, centralized operations. Choose the pattern (star, hierarchy, redundant, edge) to match the site's autonomy and scale, preserve data semantics, define failure behavior per data class, and monitor the aggregator itself. Aggregation is the right answer when the problem is many-to-many connectivity with a need for order.